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.
  • recommendations are planned:
    http://www.zotero.org/support/development_roadmap

    Arbitrarily-sorted collections have been previously requested.
  • I think reading list functionality is perfectly well covered with the existing collections functionality.
  • I agree & also point out that a "toread" tag is also awesome. However, apple wanted an "ordered list". To get that, you'd presently have to subvert one of the sortable fields (for example, by prepending a number to some relatively-unused field).
  • Yes, I know apple mentioned "ordered. " But whenever someone says that I feel the unavoidable impulse to ask "why?" I think (manual) ordering is seriously overrated for this stuff.

    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.
  • @bdarcus

    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.
  • edited May 28, 2009
    But there are other, better, ways to do that. For example, you could have tags like "to read" and then priority tags like "priority 1" and so forth. You could then set up automatic collections like "read now" and "read later" and "read before I die."

    So the current system offers a lot of power and flexibility.

    Also, adding manual ordering imposes often unintended costs.
  • edited May 28, 2009
    EDIT: beaten to my first point by bdarcus. The last paragraph may still be relevant.

    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
  • edited May 28, 2009
    Edit conflict with noksagt - what i've said still applies to my situation though (although might be different in literature as noksagt is saying - I am a science student).

    @ 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.
  • Two problems with tags for this:

    1. They're not granular enough when you have specific dependencies between individual items you want to read.
    2. 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.
  • Bionatsci:

    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
    Do you realise you can turn off seeing imported tags in the tag selector?
  • edited May 28, 2009
    cool conversation.

    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 :-)
  • @CB: I wouldn't read into my view a preference for esoteric data modeling over human factors. I think this is a rather classic case of a false dichotomy.

    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.
  • Bruce: the dichotomy may well be false, but it is nevertheless enacted in the practice of an awful lot of software development. And *I'm* not calling data modelling 'esoteric'; it (or rather its lack) is one big part of why I'd never use Onenote, for example, for anything permanent or important. 'Geeks and programmers' wasn't meant disparagingly; just a partition of the population of interested parties.

    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.
  • But a document is a fundamentally ordered sequence of content, so it makes sense to represent that as such (in Word).

    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.
  • Bruce, Word outlines are often used not really as 'documents', but as means of structured note-taking. It's the fluent access to structure that keeps people using them, not the sequential aspect, I think.

    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.
  • Bruce, Word outlines are often used not really as 'documents', but as means of structured note-taking. It's the fluent access to structure that keeps people using them, not the sequential aspect, I think.
    Ahem; I know why people use outliners.

    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.

  • Ahem; I know why people use outliners.
    Oops, yes, sorry.

    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.
    You may be right there. But there are all the usual pains of duplication of data across apps. When I'm working on something at the moment I tend to use Onenote or text files to organise things like what to read next, and end up doing too much copying and pasting between them and zotero. I long for the day when it's relatively easy to connect everything up. But I'm glad I don't have to manage the implementation ;)
  • Very interesting discussion--to chime in on the subject of ordering (with no strong feelings about implementing it or not):

    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.
  • regarding bionatsci's post on tags: I was initially excited about the ability of Z to pull in PubMed keywords as tags before learning the hard way that it's worse than useless--some PubMed tags are too granular, some too general, some too long, and every paper has way too many of them, making the "all tags" view useless. I think this is the main reason for the persistence of "delete all tags" requests. I know I was wishing for it. We now use a set of user-defined tags that actually work beautifully, and the tag selector pane's click-on cilck-off functionality is terrific.
  • @CB - Thanks for the tip.

    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.
Sign In or Register to comment.