A Lot of Suggestions for Zotero

I have had the opportunity to use Zotero consistently for a week or so now and the program has grown on me. I am happy such a program exists and it will no doubt help my research in the future.

I have compiled a long list of suggestions to improve Zotero. (I hope that none of them are considered outlandish!)

1) I would like the ability to export files from within Zotero (like a collection of PDFs) with *only* the file structure in some sort of readable format, for example My Library -> sub folders - > sub documents.pdf. Currently, it appears the database export (with files) is only useful for another Zotero installation and the folders are named a combination of numbers whose pattern I cannot discern.

I need this feature so that I can browse the library without Zotero using other programs meant for note-taking. (Note taking is, in my opinion, Zotero's biggest weakness by far.) I realize that there will be duplicate files since documents are often in more than one location, and perhaps something can be done about it, but leaving them in would be fine too. This feature is basically essential so that one can use the Zotero database in other document management programs, since they sometimes have more features, and Zotero doesn't seem like its heading in a full document management direction.

2) The ability to start Fire Fox with Zotero running. I only use FFfor Zotero. I'm probably not the only one. An option to do this would be great.

3) The ability to have Zotero start maximized. Like I said, Zotero is my app in FF. It would be great to have it boot up with FF.

On the very related note, others have suggested having Zotero open up in its own tab or in its own separate window. I totally agree with these suggestions. If this is implemented (which it was noted that it would be in 1.5) then it would be great to have the tab open automatically containing Zotero, or have Zotero load in a separate window automatically upon the boot of FF.

4) The ability to mass tag. I would like to be able to select multiple items at once and tag them with the same tags. This seems like a very basic feature, so maybe it is already there and I am missing it...

5) Some way to import emails through Outlook, etc. Email is a big part of my academic life. (My colleagues and I frequently discuss our work.) This would be a great benefit to making sure that their contributions are more easily recorded.

6) A greater ability to organize documents in a folder or My Library. That is, move an individual document up, an individual document down, alphabetize by article name, alphabetize by journal the article is found in, etc. The former two suggestions may be hard to accomplish since it seems Zotero automatically updates a pane using alphabetize by first author's last name. If this is the case, the ability to mark a folder so that Zotero does not automatically sort it, and it can be individually sorted, would be fine as well.

7) Ability to keep nodes in their previous state (open/closed) when switching panes. In case that is not clear, what I am referring to is switching from one folder to another. In doing so, the opened nodes will close.

8) It has been suggested in another form already, but the ability to mark an item somehow, for example "read," or "examined" (perhaps through a color code system) would be *very* helpful in sorting through items, especially after going through a journal splurge and finding new material to analyze.

9) Perhaps it's just me (probably!) and I am missing something, but my manually imported PDFs aren't indexed, but those I grab through Zotero are.

And finally, my most wanted suggestion:

10) Better note taking ability in Zotero. As I noted before, I consider this Zotero's biggest weakness. Most of my research is taking notes. (Goodbye 3x5 cards, right?) When I first downloaded Zotero, I saw note taking capability and thought it would be the perfect program to streamline my academic research. But since then I have had to resort to other means to take adequate notes, and I have been a bit disappointed that more of the program's emphasis isn't on note-taking, which is so crucial to academia. Note taking in Zotero is limited now to extremely bare bones basic text - RTF isn't even possible. There has been talk of a mark up system but this is not really acceptable because it will be too technical to some, and mark up systems aren't that great when it comes to keyboard shortcuts, in my view. Please, please, *please* add better note taking functions. (What's wrong with wanting to bold or italicize?) Here are some ways you might do this:

1) Add a WYSIWYG interface to the notes page, like on some forums. Users who don't like this, or think it takes up too much space, can turn it off. But if Zotero opens in another tab, or in a separate window, then this shouldn't be a problem for anyone.

2) Have a user-defined application open for notes, and have the document created through that program automatically attached to the Zotero file in question. Right now this can be done manually (with no Zotero integration) but it is very time consuming, and defeats much of the purpose of using Zotero if everything is managed in an external application.

Optimally, both would be implemented. But failing that, 1) is my primary suggestion.

Thank you for reading this hefty post and I hope that you take my suggestions into consideration. (And thanks even more for making Zotero!)
  • The ability to mass tag. I would like to be able to select multiple items at once and tag them with the same tags. This seems like a very basic feature, so maybe it is already there and I am missing it...
    http://forums.zotero.org/discussion/692/
  • edited February 11, 2008
    Note taking in Zotero is limited now to extremely bare bones basic text - RTF isn't even possible. There has been talk of a mark up system but this is not really acceptable because it will be too technical to some, and mark up systems aren't that great when it comes to keyboard shortcuts, in my view. Please, please, *please* add better note taking functions. (What's wrong with wanting to bold or italicize?)
    Because "bold" and "italic" is meaningless. This is a tool for scholars, so it seems to me the note-taking system ought to allow us to mark up content according to its meaning: this span refers to a species name, this one to a quote, this to a title.

    To get a hint of the kind of possibilities more semantic encoding of notes and document content open up, see this blog post of mine from awhile back. The short summary is that by attaching semantic classes to (in this case) content, I was able to treat a whole collection of documents as a database of sorts, and run queries on them to generate different kinds of output. It helped a lot in the research process.

    Your arguments against a markup system aren't really convincing. There's no reason why you couldn't assign keyboard shortcuts to span classes, or lists, or whatever.

    In my experience, most WYSIWYG interfaces suck; they cause more problems than they solve.
    1) Add a WYSIWYG interface to the notes page, like on some forums. Users who don't like this, or think it takes up too much space, can turn it off.
    I don't want a WYSIWYG interface at all, unless:

    a) it is really fast and intuitive
    b) it comes with out-of-box support for semantic classes

    In some ways the GUI issue (markup vs. visual) is orthoginal to the more fundamental one: semantic vs. presentational styling (see google for more). In the 21st century, it is insane that a tool for scholars would be adopting an approach from the 1980s.
  • bdarcus, if you don't want an WYSIWYG tool, I would invite you to turn it off. That's why I included the option. (And what WYSIWYG editor is not intuitive? I was under the impression that was their point, with the *alternatives* representing the unintuitive lot.) No one should have to learn a markup language - especially a web 3.0ish semantic one - in order to bold a word. I think that's a technical bent of yours that not everyone would share. If anything, that should be an option, not an imposition. I see the value but fail to see how advanced and intuitive note taking in Zotero would not benefit nearly everyone. I am heavily in favor of *at least* RTF capabilities in Zotero and I am not the only one:

    http://forums.zotero.org/discussion/445/
    http://forums.zotero.org/discussion/336/?Focus=1198#Comment_1198
    Note that they aren't clamoring for a new technical language to learn, only the ability to bold their text. So clearly, many people believe that bolding and italicizing aren't "meaningless."

    Thanks Dan for that link. I hope that you'll consider my other suggestions.
  • edited February 11, 2008
    Note that they aren't clamoring for a new technical language to learn, only the ability to bold their text. So clearly, many people believe that bolding and italicizing aren't "meaningless."
    Just because 50 or 100 people ask for it doesn't mean that it's not a bad idea. You're obfuscating the issue, suggesting that what many of us are asking for necessarily is a more technical, less user-friendly, approach. it's not. Moreover, dismissing our concerns by saying "don't use it" is not an answer.

    To repeat, let's separate out questions of interface (whether you use a simple markup language or a GUI) vs. content (semantics vs. presentation). Just because you have a position on the first one, doesn't necessary mean a particular position on the second.

    So, for example, let's assume we all agree a nice GUI to modify note-content would be valuable. I don't, really, but would be willing to compromise on that. Then the question becomes, how to attach semantics to content?

    One way is to just have some base semantic classes, like "emphasis" and "strong" and "cite". These could map to your "b" and "i" if you like, but they also correspond to basic elements in HTML.

    Then we allow a handful of additional classes: maybe "foreign term" and "species name" or some such, and allow users to define their own classes and how they map to display (italic, bold, etc.). These might be accessible via a simple drop-down menu and optional keybinding. So, highlight term, hit some key, and the content gets tagged with the term.

    This approach is simple and extensible, and I would think would make both of us happy; don't you think?
  • I was not obfuscating the problem but putting its need into perspective. Numbers don't determine a proposal's merits, but they are good way to gauge the want of, or need for, the proposal, and an intuitive editor for notes is clearly needed. In addition, I think that it's perfectly fine to say "don't use it" if there is an option to turn it off, since you could still write in markup regardless, and export it to be interpreted however your wish.

    But I don't see any problem with your latest proposal - in fact I would welcome it - as I my impression was that was nearly exactly what would happen so as to facilitate exporting and conversion to different formats. (Much like in many web WYSIWYG environments, you have your GUI, and then in the background the HTML is being made, accessible at anytime.) The option for user-created classes working in the background is a good idea. However, requiring the user to do more than press the "b" icon or press "ctrl+b" is asking too much when everyone has been trained in this fashion since day one. My impression from your comments was that you wanted to have everything coded by hand, in a technical langauge the average person would have to learn, and then probably have to *export* it to even see it in half-way normal view. That I am against -- I don't think anyone should have to take a class to use the note taking functionality of Zotero.
  • However, requiring the user to do more than press the "b" icon or press "ctrl+b" is asking too much when everyone has been trained in this fashion since day one.
    Kind of ironic, eh? Many people here have PhDs, but they can't learn? ;-)
    My impression from your comments was that you wanted to have everything coded by hand, in a technical langauge the average person would have to learn ...
    Well, let's put this in some perspective; we're talking about the most basic of markup:


    Heading
    =======

    Some text with _emphasis_ and a *bold* list:

    * one
    * two
    * three

    ...


    People CAN learn that easily. I have some colleagues who did just that, and many of them are quite techno-phobic. And people on these forums learn it as well.

    But I recognize that a GUI is the ideal approach; some of us were just saying it might be nice to allow the option of the above, or that it might be a good first step, since all features take time.

    So to be clear, I'm not disagreeing with you on this point really.
  • Even a basic markup like that offers little - if any - advantage over a basic GUI. At that point, it's just technical for the sake of being technical, when a good GUI would have done the same, almost always, with less work involved. A basic wordpad-like GUI seems a better first step to me, although the end result, in my ideal view, should be like the forum example mentioned previously, with a WYSIWYG front end and a markup (most likely HTML, I assume) back end.

    Ph.D's aren't the only ones using Zotero either, and if a Ph.D doesn't want to learn it (and why should one? research is what we are supposed to be doing) think of the students -- FF now has Zotero as one of its featured downloads and a special edition front-page version of FF comes loaded with it, so many students (freshmen and up) are presumably using it. Few students would use the program if they knew they had to learn a second LaTeX just to bold some text or block quote. Making something technical and difficult to a beginner when it can be easy (and just as effective) makes no sense. Just think of the complexity of trying to teach someone tables or something equally complex in a foreign markup.

    Anyway, now that we are somewhat on the same page, I am going to move away from this conversation and attempt to focus on my other concerns, since they have taken a backseat.

    Only 9 to go.
  • edited February 11, 2008
    Even a basic markup like that offers little - if any - advantage over a basic GUI.
    I find it surprising that you don't see any advantages.

    It is lighter in weight (leading to faster development time & also a smaller download & less resource requirements than a GUI), would work well in a web-based version of Zotero (compare to Wikipedia, for example), and enables fast keyboard entry.
    Only 9 to go.
    I think you over-count here. Perhaps you missed Dan's reply re. (4).

    What is the difference between (2) and (3)? Re. (3): If you maximize the Zotero pane & then hide it, it should still be maximized when you show it again. And, as you note, there is already talk on zotero-in-a-tab.

    (5), (6), and (8) have been requested previously. You (like some others) do not mention why tagging doesn't fill your need presently (though it would certainly be nice to assign a color or some other visualization to tags).
  • edited February 11, 2008
    Semantic markup is certainly better, as long as there is a way to read a formatted note on the screen with words in italics and bold and no tags. When I'm working with a complex theoretical argument, I need to see emphasis clearly and I don't want any span tags breaking my concentration. But presumably reports will allow this in any case.
  • QwertyFive:

    The benefits of structural encoding (what it means) over presentational (what it looks like) are widely known, and hardly theoretical or technical. The web as you experience it in 2008 is largely a product of this revolution, which has yielded web sites that are more accessible, more useful, and more beautiful. Even the fact that Zotero can extract metadata from web pages is a product of this transition. The cleaner the structural encoding, the easier is to extract the data.

    But let me make this really concrete with respect to Zotero. Right now notes content is effectively dumb text. You can search through the content, but you can't search for particular kinds of notes content.

    What if, by contrast, you wanted to be able to create queries that would find:
    - quotes from a particular person
    - fragments tagged with your own custom term of "important"
    - references to a particular year

    All of this could be fairly easy to do with support for semantic notes.

    And, of course, what noksagt said.
  • NB: My points were for a GUI vs. lightweight markup.

    You can, of course, have semantic or presentational representations in either mode & it seems we all agree that the only advantage that a purely presentational model has is simplicity & that this isn't sufficient to make up for the deficiencies (and it isn't even that much simpler).
  • edited February 11, 2008
    noksagt:

    I see the advantages to markup in some cases. THIS is not one of them, for the reasons stated previously. While I agree with your Wikipedia example, I don't see how it is relevant, as these are basic notes (nothing fancier than bolding and a list) and the markup under consideration was fabricated. Even so, the idea of having a GUI with an html backend (or whatever markup) covers it.

    Really, you markup enthusiasts are putting the cart before the horse. Usability of technology is almost always more important than having the latest "enhancements." In no case should one sacrifice a program's basic usability for some new technology, no matter how promising, unless your audience is in need of that new technology. You simply cannot make the case that the average member of the intended audience of Zotero craves semantic markup more than it does a basic GUI for taking notes. And I will make the not-so-bold statement and say that is the way it will *always* be, unless Zotero becomes an extremely niche product. Are any of you REALLY going to compose an actual, *publishable* document in Zotero? I think not. You will open up your editor of choice and do it there. I want to take notes. Easily take notes. A GUI allows that, and everyone knows it. If there's anything else behind it, great, but the UI is most important.

    I counted Dan's reply. Thus 9. I don't see how that was not clear to you...

    2 & 3 are different because Zotero is not "open" when FF runs. You have to open it manually. Sure, it is running, but not open. Thus two (2). When Zotero starts, it starts in its non-full screen mode. Thus three (3).

    I don't see how tagging is relevant to (5) and (6). As for (8), why use tags for this? Just because you can? I don't like inefficient workarounds like having to scroll through a hundred tags to find the one I want. Here's a suggestion: just add a column heading alongside "Title" and "Creator" in the main pane (say, "Mark" or "Color" or somethig smaller, since the mark itself will likely be smaller) and do the same thing Outlook 2007 does - a little block of color that can be changed by clicking on it. If this isn't manageable (and I don't see how it could not be!) then the authors can find their own solution.

    bdarcus, please do not lecture me on basic web technology, especially since some of what you said is at best opinion, and at worst incorrect.
  • By the way, I have left most ways to implement something open, because I find that openness facilitates the authors ability to see where and how something might fit, and how to best implement it. The specifics are not as important so much as some of these problems are (hopefully) addressed.
  • edited February 11, 2008
    Well the traditional way (from ye olde mainframe terminal) to do *bold* /italic/ -strikethrough- _underline_ (and maybe ^superscript and _subscript), and it works fairly well - it's quick, visually clear and easily translated to semantic markup. I dare say that some javascript magic could be applied so that *bold* /italic/ -strikethrough- and _underline_ could be displayed on the fly, but that's someone elses' itch to scratch, not mine :-)
  • Let's try moving away from the markup scandal and focusing on the other concerns, please...
  • edited February 11, 2008
    While I agree with your Wikipedia example, I don't see how it is relevant, as these are basic notes (nothing fancier than bolding and a list) and the markup under consideration was fabricated.
    I don't know why you discard the analogy--the WP interface is used by quite a few people & I could imagine lots of reasons that Zotero might want to adopt a similar interface if they have note creation in their server tool. (Note that WP does have a very basic GUI, but is not WYSIWIG.)
    Really, you markup enthusiasts are putting the cart before the horse.
    I don't necessarily think so. If you build a bird house, you don't put on the final gloss coat first. You figure out how many and how big the birds you'll eventually want to feed are (the planning that includes this discussion). Then you start building (getting some rich, semantic text functioning). Next, you paint it (add buttons and other GUI elements). Finally, you put the gloss on (WYSIWYG).

    Each step builds on the previous & more work may need to be done if elements of the foundation have to be re-tooled.

    What people want right now is NOT WYSIWIG (because they already have it). What they want is richer text (and I think they'd want it to be semantic, all other things being equal).
    I counted Dan's reply. Thus 9. I don't see how that was not clear to you...
    I thought you were talking about checking off markup and that you might have missed Dan's note because you mentioned markup, but not mass tagging when you said:
    Anyway, now that we are somewhat on the same page, I am going to move away from this conversation and attempt to focus on my other concerns, since they have taken a backseat.

    Only 9 to go.
    Anyway....
    When Zotero starts, it starts in its non-full screen mode. Thus three (3).
    Within a single session, the maximization setting is remembered, but it looks like it isn't remembered between sessions.
    As for (8), why use tags for this? Just because you can?
    No--because tags are expandable. What binary fields would you have?
    Marked/selected (with no other semantic meaning); I've read this; I own this; I should buy this; I like this; I agree with this; I think this is important.....There are just tons of these traits that people might find useful & tagging lets people have ALL of them. It seems better to make tagging more efficient if you're not happy with scrolling through tags. See how ThunderBird does it for example--it ships with a half dozen popular tags & has color coding for them, but lets you add more tags arbitrarily & have shortcut keys for the top ten tags.
  • edited February 11, 2008
    I think you built your bird house wrong there, or at least mixed up the wood and the gloss. Needless to say, I disagree with you. You can plan the future backend while still employing the far more important basic features of the front end GUI interface. (I don't mean front end literally here, as at this point it would be the only interface.) Note that I am not disagreeing that markup can be very useful, but that what's important - ease and usability - is being seriously misplaced here. I won't say anymore than that, because I want to get away from this and focus on the other concerns. I hope that Dan or another administrator sees them (and the note-taking issue) and can reply. My hope is that a ticket could be created, so that one day...

    I can see how you misinterpreted my counting there.

    I am not sure if the next comment about maximization was supposed to be a solution or an observation. I still feel strongly about (2) & (3) though, and think that coupled with Zotero in a new tab/new window they will be great enhancements.

    Tags are expandable, but they are typically used to indicate content of a piece. That said, why not just use tags instead of semantic markup? All of bdarcus' benefits of semantic markup could be accomplished with tags. Tags for all, I say!

    ...Or perhaps not. (I jest.) The point is that they can do the job, but they don't do it well. A way of marking documents is needed other than tagging that is more directly pertinent to the concerns of myself and other individuals wanting to mark a document in someway ("read" being the most requested reason to mark a document, I have found). I do wish tagging was more efficient, however. The default space is too small and cramped, and it consequently makes searching large amount of tags (visually) difficult. I didn't include it in my list of suggestions because I had no immediate solution and really don't care all that much about tagging, but in retrospect, I wish I had mentioned it. However, I think (2) and (3) would mitigate that quite a bit by allowing more space for Zotero.
  • My hope is that a ticket could be created, so that one day...
    Like this one?
    I am not sure if the next comment about maximization was supposed to be a solution or an observation.
    Just an observation. It does remember the size between sessions, so there's no reason your zotero can't be big (it just won't be "full screen").
    The point is that they can do the job, but they don't do it well.
    And my question is: can they be made to do it better, rather than adding limited, cluttering features?

    Again, all you seem to see is the interface. Those who argue for the use of tags see the back-end. Again, I encourage you to look at the thunderbird interface. It moved from a "selection-based" mode to a tag-based mode. The GUI is practically the same & it has all the advantages of being merely selection-based (easy visualization of what has been marked and fast marking) while still being expandable.
    The default space is too small and cramped, and it consequently makes searching large amount of tags (visually) difficult.
    Lots of possibilities: hierarchy, coloring, sorting by most used, some set of defaults (to establish some minimal ontology & to give a "marking" feature), tag clouds, etc.
  • edited February 12, 2008
    I am glad that there is a similar ticket. I would hope for more than what is presented there (because it seems like so little for a 1.5 release), but at least can hold out hope that more improvements in this area are offered in the future.

    I don't know about Thunderbird, but from the screenshot - if I am interpreting it correctly - the tags themselves can color the object. That's something not available now, and it seems like feature that could be helpful in this context. On the other hand, also gleaned from the screenshot on tags is that the dialog box for tags could easily become cluttered, far more so with Zotero, where imported tags for a large collection will literally run into the thousands (or more). In order for tags to function as easy markers of meta-document data (like being "read") they have to be discernable from other tags easily. However, I think that appealing to both crowds - the marking crowd and the tags crowd - is likely to please no one very much, resulting in workarounds for both, or worse, ignoring the other (marking crowd) altogether. One solution might be to have separate ways of accessing tags - one normal tags and the other "meta-marking" tags. The reason I suggest this is that one will have commonly used tags, and one will also have commonly used tags for meta-marking documents. Mixing them, depending upon their quantity, could make both tasks very hard, but it's likely to be more hard for the meta-marking crowd because these tags are likely to be less to begin with and therefore harder to find in a collection. However, I think that this solution is cumbersome because it would require too much space in an already very cramped program. (Though (2) and (3) would help this a bit.)

    The reason why having them bunched together is a problem is because there will be so *many* tags, especially as Zotero becomes more popular and tags are shared. (Leading to the possibility that you download a document that already has a "read" or some other meta-marking tag applied.) Tag management will be an issue in itself as the current management system is not the best.

    I understand your offering and still think that it is not optimal but could be "gotten used to," but *only* if tag management is significantly overhauled (and again, only to the inefficient "I'll get used to it" level.) I think color coding or some other marking mechanism that achieves the same is better, especially when it comes to browsing one's library. (Even more if the mechanism is placed in the central pane).

    And my stress has not been on the interface, but usability and ease. Many things can be done both ways, having both ease and usability with forward-looking technical ability. I think that is at least partially the case here. But ease and usability is simply paramount. If this tagging solution were an easy to see solution and met basic UI standards I don't think there would be so many posts asking for some ability to mark documents. It just doesn't click for a user that tags might be used for that, and for good reason in my view: tags are seen as depicting content, not document meta-data/marking. The designers probably thought the same thing when implementing tags. Thus a solution based around tags is bound to haphazard and cumbersome.

    I still think (6) would be a great enhancement for organizing one's documents because a primary way of looking at one's collection is to simply browse it, and tags simply could not hope to replace the functionality in these suggestions. The suggestions are aimed at making browsing easier. For example, you might want to put two or three main documents at the top of a folder, indicating their importance and the fact they must be returned to regularly. Or one might want to see which articles in a collection are likely to have had the most impact, by sorting articles by the journal they appeared in (because not all journals are created equal). The data is already there, afterall - why not just use it? These are simple reasons but no doubt dozens more could be offered. (6) is an expansive feature set that lets the user come up with organizing solutions.

    As for (5), it would just be nice to be able to import email, right? Perhaps an Office plugin or Thunderbird plugin would be help here.

    I really hope the group here isn't just piling on my suggestions as immediately bad because I have somehow offended their faith in the semantic web. That would be not only unfair but do all of us a disservice. I am of the opinion all of the suggestions have great merit and have labored to explain why. It would be nice to have support on those suggestions others think are good ideas as well.
  • edited February 12, 2008
    QwertyFive:
    I really hope the group here isn't just piling on my suggestions as immediately bad because I have somehow offended their faith in the semantic web.
    What is bothersome about your arguments here is that you consistently claim to be championing "ease-of-use," the "average user" and so forth, and dismissing those of us who happen to have a different view on how to get there as merely "technical." Here' again you invoke this line of argument with the "faith in the semantic web" sleight of hand; as if we're some kind of cult of zealots.

    The concerns that drive us here are not theoretical. All of us are practicing academics who do real work with Zotero. I am at this moment taking a break from a manuscript in fact. We just may have different ideas of what constitutes ease-of-use.

    So if you want to tell me to stop lecturing you about the state of the web and what we might all learn from it, and accuse me (without any basis) of citing "incorrect" facts, I'd like to suggest you stop with this kind of argument. Make your case, and if it's convincing (ultimately not to me, but to the Zotero developers), then so be it.

    As for some of your specific issues beyond the one we've focused on:

    (5) I don't really want to have email import in by default, but it would seem a great opportunity for a third-party plugin (a "send to Zotero" command within your mail client).

    (6) This is another design choice, but I prefer that folders remain unordered, in part because when Zotero moves to server functionality, it becomes awkward to deal with order when you have shared collections (which will be a killer features, BTW).

    (2) and (3) I'm agnostic about. If it's easy to add for the devs, then why not?

    On tagging, this extension is actually a really good model. You might take a look and see if it has anything to recommend to Zotero.

    GMail is actually also a good model for how to use tagging in conjunction with other UI metaphors (color coding, folders, etc.).

    As an aside: it may have been good to split the issues up into separate posts so that individual items don't get drowned out?
  • I think you are not paying attention to what I have said bdarcus, and I hope not purposefully, because then the zealotry shoe would fit. You are overlooking that I don't have anything against markup itself, just markup at the expense of ease and usability. You even admitted yourself that a GUI would be ideal. And I have not dismissed anyone, but argued for my position continuously ; the dismissal here has generally fallen with my opponents. So please don't cry foul until you re-examine your own posts. In any case, I thought we came to an agreement that a GUI front end and coded back end was the best solution to our mutual concerns? I have not changed my position on that. In fact, I specifically stated I wanted something like that, and welcomed your suggestion for user-defined classes in the backend, accessible in someway through the GUI.

    As for my comment about your incorrect facts, I had written a longer post but decided in good taste to cut it before posting, as posting wouldn't serve my purposes here. To start, what you said wasn't technical is the very *definition* of technical. If there were a private message function I would address them all personally to you and perhaps we could come to an understanding, but it doesn't belong here. I could address the mistakes another way if you wished, but it would have to be done elsewhere. I'll leave that up to you.

    I agree that I should have split the issues up. Would the mods here not mind if I reposted each suggestion (and related suggestions) individually?
  • edited February 12, 2008
    (6) The method of ordering or sorting can be done in a user's collection only. I don't see any immediate technical difficulties. There can be sorting online, and there can be sorting offline. Sorting is just a user-defined view of the data. Each user could define their own view. (I imagine this can be taken even further by the developers if they wished, with each user being able to define their own folders for a shared "my library" store as well.)
  • edited February 12, 2008
    On the other hand, also gleaned from the screenshot on tags is that the dialog box for tags could easily become cluttered, far more so with Zotero, where imported tags for a large collection will literally run into the thousands (or more).
    I'm not suggesting that the current interface should be replaced with something identical to what thunderbird has. I'm suggesting that we can learn from parts of powerful/flexible interfaces. Bruce's mention of gmail may bring up an even better model.
    One solution might be to have separate ways of accessing tags - one normal tags and the other "meta-marking" tags.
    I'm not sure if I understand this.
    f this tagging solution were an easy to see solution and met basic UI standards I don't think there would be so many posts asking for some ability to mark documents.
    But there must be some balance--people have asked for marking to represent different ideas. And adding several checkboxes might clutter the interface. Also: some of the feature requests have been merely to make a visual difference between marked and unmarked records & something like tags with color would deliver exactly that.

    The argument of sharing tags doesn't hold much water either--everyone will have different categorization than you. 'toread' is a common tag on del.icio.us and citeulike, but people are able to copy references from others & retag them as they see fit.
    As for (5), it would just be nice to be able to import email, right?
    There's already a feature request for this & I don't think you have to sell it. (It may be that it is somewhat hard to add support for programs outdside of Zotero & that the payoff isn't that great, so the feature isn't "high priority.") Feel free to contribute some code or to add any novel ideas into past threads on the topic.
    I really hope the group here isn't just piling on my suggestions
    I try not to have resistance to your ideas. Any resistance I do have is because you seem to undervalue the opinions of others. You post your laundry list of feature requests, when there are already threads here about some of them. You could have added to those & this thread wouldn't have been so complicated. Further, you seem fairly closed to any suggestions of how it might work other than your pre-conceived notion of how it should work. You even see people suggesting refinements to some of your ideas as an attack.
    I agree that I should have split the issues up. Would the mods here not mind if I reposted each suggestion (and related suggestions) individually?
    Please use pre-existing threads where possible (and I've observed that you actually did start separate threads for some of these already).
  • edited February 13, 2008
    Both the Thunderbird (presumably) and Zotero style tag system possess the flaws I mentioned and are currently inadequate. There doesn't exist a good way to manage large amounts of tags in both. Zotero's tagging system was not my focus here, but I agree that it can be improved in some of the ways you mentioned, like adding color. Again, I disagree that tagging will address the concerns of those looking to mark the document "read" (or more.) Note that both Thunderbird and Gmail have a mark "read" option - it's simply needed that much, given the context of the program. Zotero is no different.

    The point about normal tags and meta-marking tags was this. Tags, in the users mind, typically depict the content of an article. The idea I had with meta-marking tags was that they depict something the user has assigned to the document that is not actually a part of it, like "read," hence the name "meta-marking" tags. If meta-marking tags and normal tags were treated differently but still considered tags, with meta-marking tags having more options and a separate pane to deal with them, it would help in organizational affairs. I won't go further into this proposal. If these meta-marking tags act like normal tags in the database, then so be it. But they cannot be treated like normal tags in the interface (and in certain functional respects) as their purpose is different, so they should be dealt with differently as a result.

    I feel that the above might be beneficial compromise (with strong reservations), but I don't think that tags get at the root of what people are asking for. They want a simple way to mark documents. They want to be able to *see* that their documents are marked.

    Two better ideas (because they directly address the problem), in my view, are the following:
    1) Add another, optional, column to the main pane [where it (by default) reads "Title," "Creator," "Type," "+," "[]" ] called something like "Mark" (or perhaps another symbol to keep it smaller) that adds something like the color coded functionality of Outlook 2007. Hopefully you’re familiar with this program, but if not, it's a blotch of color that sits beside an email. Colors don't stand for anything in particular, and therefore the user can assign their own meaning to them.

    2) Another color coding option would be to offer simple right click functionality to mark the *row* of document in the main pane a different color. Hopefully this could be extended to easily allow mass-marking of documents via shift-selecting documents and then assigning a certain color (similarly with the above proposal). (This is something I, and at least one other, had difficulty doing similarly with tags due to a lack of intuitiveness. Since this is a forum, with mostly the generally tech-savvy visiting, this number can be inferred to be greater.)

    I disagree with your dismissal of the importance of importing email. I communicate with colleagues literally all day around the world. Importing the basic details of these conversations (author, Date, Time, and perhaps importing the content of the email into the notes section (impossible though, considering how extremely weak note-taking is now) or as a file, akin to .PDF importing) would be a great help to many, many people. The importance of this cannot be underestimated. Email is one of the great tools of scholarly exchange, and almost infinitely faster than alternatives (publishing and conferences) to spread ideas and comment on manuscripts, etc.

    You say I don't need to sell this idea, but here I am being assaulted for not agreeing with the party lines of these forums, ostensibly for not offering "convincing" arguments. I realize that you may be different from this, but you can't have it both ways. Each of my suggestions offered a comment addressing why it was important, at least to me, and my hope was that the authors would recognize a deficit as well. I left implementation generally up in the air *purposefully*. If tags can achieve something, or if markup can achieve something, great, but there are serious flaws to both plans if they are deployed exclusively, which I have now discussed at length.

    And it's absolute nonsense that I have undervalued the opinions of others or have been closed to suggestions. I have made exchanges here, offered ideas on solutions I do not agree with, in addition to commenting that some ideas offered - not my own - were quite good. If it seems that I have undervalued, then that is the taint on *your* lens, not mine. For example, you haven't commented on some of my other proposals, and your contribution here has basically offered the broken status quo as a solution, with hope for improvement. Fine. But realize that, it is, in fact, you who are potentially undervaluing (and self-admittedly so!) Are ANY of my suggestions appealing to you? Assuming so (perhaps a wrong assumption, given what I have experienced so far from these forums), why not post in support of them instead of issuing these baseless accusations?
  • I disagree with your dismissal of the importance of importing email.
    I don't think that I ever dismissed it. I agree that it would be nice to have this feature. But I wanted to mention there are reasons that might make implementing it slow going and/or a good project for a third party--people use a lot of different desktop email clients & some are easier to extend than others, but any would require building something that wasn't part of the core firefox addon.

    It makes more sense to write translators for webmail. Those services are gaining in popularity & external tools wouldn't need to be built (although some online email is on AJAX or other dynamic pages that may be harder to scrape). Note that I say this as a user of desktop mail & that it isn't necessarily "what I want," but is what seems pragmatic.
    If it seems that I have undervalued, then that is the taint on *your* lens, not mine.....Fine. But realize that, it is, in fact, you who are potentially undervaluing (and self-admittedly so!)
    I don't think that either one of us is actively trying to devalue the others' opinions.
    For example, you haven't commented on some of my other proposals
    I think I commented on more than anyone else has. I didn't see the value in commenting on anything I didn't have a strong opinion about, but I'll take the time to do this since you ask:

    (1) is in a separate thread & I think it'd be better to see comments by others in that thread.

    I asked for clarification for (2) and (3) & mentioned a semi-work-around for (3), but did not discount either. The features aren't something that I'd probably use, but I'm not opposed to them (and they seem like fine ideas. I also feel (7) would be "fine, but not essential."

    (4) and (5) received comments.

    I didn't comment on (6) because I don't have a strong opinion on it. Better sorting is needed, but I don't know how useful a customized sort would be. If I had an objection, it wouldn't be about the needs of the server. It would be that it might make a more complex & uglier interface. But it might work--I don't know.

    I commented extensively on (8). I think tagging should be improved & that this might be "good enough" (it certainly is for many of the social bookmarking and social citation sites). If marking were added, it should probably not be highlights, but something like the "star" in gmail/thunderbird.

    (9) is in another thread & I don't have anything to add.

    I agree that rich text is needed for (10), but am more in agreement with bdarcus about what to prioritize in the implementation.
    and your contribution here has basically offered the broken status quo as a solution
    The status quo is imperfect, but hardly broken. And I've not claimed we should keep the status quo. It is just that my ideas for change differ from yours sometimes.
  • Thanks for the comments.
    Can you point me to the threads that are related to (1)? I cannot seem to find it. I found this thread, which is somewhat similar to (1), but has been addressed by Dan already (it is a much simpler request that could be done through explorer the, or doing a search from within windows (or another OS) on the folder for files of the type *.PDF). My suggestion is a bit more complex.
  • That was the thread that I was thinking of, but your request also touches on what they are named in the first place:
    http://forums.zotero.org/discussion/508/
Sign In or Register to comment.