Reading List / Genius
Continuing with the analogy of:
Zotero -> references, as iTunes -> music
Why not have a "reading list" functionality the way iTunes has a playlist/genius functionality. I'm not even talking about smart recommendations (though why not...) I'm talking about having a list which can be managed inside Zotero that represents an ordered list of articles/books to be read?
Something more than a collection... but not much more. Maybe a slightly tweaked collection.
Zotero -> references, as iTunes -> music
Why not have a "reading list" functionality the way iTunes has a playlist/genius functionality. I'm not even talking about smart recommendations (though why not...) I'm talking about having a list which can be managed inside Zotero that represents an ordered list of articles/books to be read?
Something more than a collection... but not much more. Maybe a slightly tweaked collection.
http://www.zotero.org/support/development_roadmap
Arbitrarily-sorted collections have been previously requested.
I intend to use Zotero's group stuff for a seminar in the Fall, and this will include reading list sort of stuff. But I'm quite happy to just use a collection and subcollections for that, and let Zotero sort the lists for display.
I can think of at least one good (for me at least) reason to be able to manually order lists - importance to the reader.
I am an undergraduate student and I need to do a lot of background reading. I gather all my references for a topic (in zotero) and decide which order I would like to read it in, starting with what I consider is the most important - in case I don't get time to read them all. When I get a spare half hour I read the next reference on my list.
At the moment I manually write down these lists, either by hand or in OneNote - the abiltiy to do this easily in zotero would be great.
So the current system offers a lot of power and flexibility.
Also, adding manual ordering imposes often unintended costs.
WRT importance: You could also just use tags or sub-categories for this (so just mark each one from "extremely critical" to "read if I'm really bored"). For articles, the specific order you read stuff in isn't usually crucial & you can probably manage to pick off what to read from a short list of stuff marked extremely critical fairly easily.
However, it may be worth noting that order sometimes does matter. This seems particularly true in literature, where you can't always rely on the original publication date (assuming that is even stored in your zotero database rather than a reprint date) to decide what to read next:
http://www3.sympatico.ca/n.rieck/links/cool_sci_fi.html#asimov-suggested-reading-order
@ bdarcus
I agree - priority tags are probably a better way to do this, I have been under-using tags as my library is clogged with useless imported tags - I guess I need to dive into my SQLite database and start tagging again from scratch.
Also I didn't realise there were technical costs associated with manual ordering, I can imagine that it might not be worth the hassle in this case.
Thanks.
- They're not granular enough when you have specific dependencies between individual items you want to read.
- From a human factors point of view, they're not as natural a metaphor for 'order' as, well, real order
I entirely accept that the costs may not be worth the small benefits in this case (which I don't feel strongly about). But those who are more interested in underlying data models than in ergonomics (ie. nearly all geeks and programmers) tend, I think, to the view that people should adapt to software facilities, rather than the other way around. Hence a tendency to prefer general and powerful mechanisms over highly specific, contextual features with a natural fit (and also to tell end users that they don't really need what they say they want, which may be both true and irrelevant).This has been highlighted for me recently by using Onenote. I'd never commit anything important to it long-term (for all the obvious reasons), but I have to say, it's a joy to use in many ways, and that's mostly a matter of human factors.
To explain why I originally wanted a manually ordered list: I just can't imagine it is worth my time investing in a system to automate (via tags, columns etc.) the order of a dozen or two articles which will change frequently over time.
It would be nice to have a list, where I can go in, add an item from my last meeting with my adviser to the top of the list, without having to demote all the other items on the list to 'class b', or figure out a unique non-intuitive numbering scheme.
I'm patient though. I love what Zotero's coders are doing so far!
(BTW totally support CB's comments! Well said... if a little blunt :-)
Adding order to a UI adds complexity, both to the underlying code and data, and to the user experience. When I mentioned "costs," then, I was referring as much to the latter as the former.
I have to say I find tags useful for creating rough overlapping categories, but every time I try to use them for anything further, the artificiality of the scheme ensures that it falls into disrepair.
I'm not sure I agree with you on the user experience complexity of ordering in UIs. One of the most ergonomically successful UI examples is the outline view in Word, and manual ordering is a crucial component of that. But I haven't given this much thought in the Zotero case; the barrow I'm pushing is human factors in general rather than this particular issue.
Things like priority are not fundamentally ordered; ordering is one convention by which this is denoted, but not the only one.
The cost to which I'm referring is simple: if my UI is ordered, I'm forced to maintain that order. That has consequences.
It may well be that the benefits outweigh this cost, but it's still a cost.
On ordering/priority: I'd argue the reverse: abstract concepts like priority are borrowed from physical ones like 'order', which is why some physical representations seem like more natural expressions than others. These are stronger relationships than conventions because they are not arbitrary. The *form* of representations may be as important as the abstract relations they enter into.
Of course you're right on the cost. If however (for an individual or their idiosyncratic purpose) manual order is the most natural expression of what they're trying to do, the cost may be less than that of the alternatives.
I just don't see how that applies to organizing a database of references (or any similar kinds of data application; one for emails, or news feeds, or recipes).
Or to be really specific, I don't see why this is yet another feature that Zotero should add that could probably be better handled in other, dedicated, applications.
In any case, an Interesting discussion.
Some people want to use Z not only as a library, but also as the stack of unread papers on their desk. From a UI/metaphor/workflow standpoint, it is natural to want to order the stack in a granular fashion, and to add new stuff to it in specific positions (leaving aside the depressing question of whether any of the papers actually ever get read). Tags are suboptimal for this, as is "date added." There's simply no data-architecture replacement for having a stack of stuff (bills, papers, donuts, whatev) and putting them in order of personal preference/priority.
The most oft-invoked parallel to explain Z's data structure and UI to newbies is iTunes' library/playlist architecture. For (to me) obvious reasons, in a playlist one can manually put songs in any order one wants. I'd argue (though not very strenuously) that reading is similar to listening to music in that order does matter.
One idea for this would be to have the ability to "touch" the files to update their "date modified" field. Within a "to read" collection, touching an item would move it to the top or bottom of the queue depending on ascending/descending sort; touching a series of files in order of preference would result in an ordered stack. This proposal seems extremely silly reading it back to myself. Just thinking aloud.
Just to clarify, the tags that I need to get rid of are mostly not automatically added tags - I believe they came over with some items I imported from Connotea. Also there are a lot of tags I added when I was experimenting with how to organise my library - these are now all redundant with my subcollections.