personalization options

[bibliocoll]

1st iteration: a library-maintained list of journal lists that can be used as a filter
2nd iteration: add a one click default export action based on library maintained settings for each of the above
3rd iteration: some sort of user system with the ability to self-maintain the above settings
4th iteration: backend choices for the user system
...
fancy nfc-tag login

[krugar]

a lot of what JT does would be improved by using sessions for data storage between individual requests to the server. i intend to move into that direction for 0.4, a possible future user system should benefit from that move as well

[krugar]

can kicking has occured :S

on the bright side, one user has modded their JT installation with a postgresql database backed user system and has promised to share the code.
when that happens, i'd like to sprout a (PDO-based) database-backed branch with more functionality and a higher installation footprint.

[tzeumer]

Hmm, I'm wonder if personalization is something users are waiting for. I think people don't care about it unless it's some high productivity tool they are using (well, and even then most people most likely don't use more than the basics of e.g. their mail app :D). And even though I put some time into JournalTouch I never would consider it a tool I'd be using a lot - it's cool for some occasional browsing/"serendipity effect". But for current awareness? Not really...

Anyway, it doesn't hurt to have such features if time and resources permit their development. PDO sounds nice, since Postgress would be a killer (many libraries don't even have staff to manage their public terminals).

Without focusing on how (database or not), I'd say it would be much more important to make it easier to maintain, edit and enrich metadata quality of the journals list and tocs. Broken links/tocs and badly curated categories/tags are a real killer for a good user experience. If the users are not interested immediately and convinced of the quality, then personalization doesn't matter.

I just wonder what JournalTouch is supposed to be. Or what (realistic) use cases exist (besides a kiosk tool) :)

[krugar]

yep, we don't really have a clear vision or mission statement. i guess we can do ok in the kiosk department, and maybe edge into overview/landscape-of-journals and possibly related-articles territory. open for suggestions :)

i have two things that i'd like to have in JT at some point:

• a usable way to get results/pointers from a serendipity browsing session into whatever tools that make sense in that context.
• a move from the current display-reformatted-rss-feeds model to an internal data model that is fed from the feeds. this would make some kind of data storage mechanism (ie: PDO) mandatory, but i think it will make a lot of things easier in the long run.

a distance measure for journals would be a fun thing to have with regards to the landscape-of-journals stuff.

ps: i've been made aware of http://browzine.com/ last week, and we seem to be in the same general space (sans attached business model).

[tzeumer]

I saw Browzine a while ago and is pretty much the same as JournalTouch. It has some nice features (like good categories and the usage feels good). But I think JT (essentially) is not missing anything - but inspiration is always good :)

But I'm not so sure that JournalTouch will make much progress in development in the near future. And in the (not too) far future it will be obsolete anyway... ;)