Papercuts

2
  • 27) Related to 25, alt+drag on OS X should not change the cursor to "copy drag" if the drop target does not have a special handler for alt modifier. There are two ways this could be solved:

    1) Check for alt modifier in the drop event and if it makes sense to copy (e.g. when you are moving an attachment to a new item it can be copied or moved), then copy instead of move

    2) Disable changing the mouse cursor with alt altogether

    I would vote for a wiki page for keeping track of issues.
  • @mronkko

    Please note that I have edited my post about importing from the clipboard directly into a collection.

    I would not only vote for a wiki to keep track of requests but I volunteer to assist with monitoring it and organizing topics.
  • I'm curious what devs think would be a good way of doing this?
    Would it be helpful to add to the github issue tracker using a "Papercut" label? Or would you rather not?
    If the cord devs like the idea, I think an issue tracker is preferable to a wiki. I believe anyone with a github account can open issues - the only thing devs would have to do is to create the label.

    If devs don't want to use the issue tracker for this, I figure the wiki is going to be mostly for people making suggestions to have a list that's easier to oversee than this thread - I'd still consider that useful.

    In either case, this thread should remain the main place for raising new papercut issues, so there's room for discussion (as in "can't be done," "won't be done," "maybe shouldn't be done," "is already done" etc.). For the list to be useful, all issues on it should be uncontroversial.
  • edited November 2, 2011
    Would it be helpful to add to the github issue tracker using a "Papercut" label?
    Label created. Thanks.
    In either case, this thread should remain the main place for raising new papercut issues, so there's room for discussion
    Agreed. And ideally the suggestions on this thread won't require much discussion either. For anything that's not an obvious to-do item or oversight with a clear single fix, a new thread is probably a better place.
  • great - the issue tracker is here:
    https://github.com/zotero/zotero/issues

    It looks like regular users can't add labels to issues - we can just use [papercut] in the issue name and one of the people with admin privileges can add the label from time to time.
  • True, normal users cannot add labels. But I think that adding [papercut] in the title is sufficient.

    I created an issue from number 27

    href="https://github.com/zotero/zotero/issues?sort=created&direction=desc&state=open&page=1


    @DWL-SDCA : I understand your issue, and I agree that importing to a selected collection instead of creating a new collection is a good idea. However, the problem with this approach would be that import behavior would be inconsistent. So I would prefer to have a preference option whether you could choose if all imports are done as new collections or not. Please start a new thread and link to that, if you want to discuss this issue further.
  • oooh - big +1 for 28)
  • added a ticket for 20).
    Someone over on dev is working on 14)
    http://groups.google.com/group/zotero-dev/browse_frm/thread/397c92dc143f9297

    As for 26) - this is clearly generally desirable, but as mronkko's comments suggest the details of how to implement may require more thought - I suggest DWL opens a thread on that.
  • 29) Installing a new version of a style should trigger reselection of the style in any document sessions that are open and using it.

    http://forums.zotero.org/discussion/20545/csl-style-error-reference-with-no-printed-form/

    It's a small glitch that can be overcome by selecting another style, then switching back. Experienced users hardly think of the extra clicks, but users typically encounter it for the first time when they have found something broken, have asked for help, and may have a deadline coming up.

    If just clicking "Refresh" were sufficient, it would relieve stress in that situation.
  • edited January 9, 2012
    30) In the QuickFormat dialog, clicking an item bubble produces a small popup that shows the item details. This popup should also show the name of the library from which the item is below the citation information for the item

    This would help troubleshooting citing the same item from multiple libraries.

    https://github.com/zotero/zotero/issues/26
  • edited January 19, 2012
    31) The add item by identifier UI should clearly distinguish between "receiving user input" and "processing user input". Greying out the input field (keeping the input) and stopping the cursor from blinking would be enough.

    (Right now at least on Windows 7/FF8 the UI "feels" unresponsive. There is no submit button and the cursor keeps blinking after hitting Enter, meaning there is no feedback whatsoever that you have even submitted the identifier let alone that it is now being processed.)

    (Crossposting from here.)

    (Done now.)
  • edited December 9, 2011
    32) Show item counts in the right pane when no item is selected — e.g. X items in this library, X items in this collection, X items with this tag, X items found. The current method of having to do a Select All before you see a count is notoriously unintuitive.

    Already on github and in a separate thread, but not mentioned here yet. The perfect papercut in terms of the number of times this issue has been raised in the forums.
  • 33) Add Tags to the things that can be excluded when copying items across libraries. (General pane in Zotero Preferences currently includes possibility to not copy child notes and attachments. It should be possible to exclude tags in the same way because they are often personal.) (Original thread.)
  • 34) The quick search in the classic add citation dialog in the Word plugin should show only top level items in the Titles+Creators search mode, just like the client. Right now child attachments appear expanded if the search word also happens to occur in the PDF filename.
  • 35) Provide an option for the attachment label to always mirror physical file name. Many users either do not know that their PDF is already autorenamed or are confused by the unexpected distinction between attachment label and attachment file name.

    It is confusing because (1) attachments are visually presented as files (with icons); (2) anything dragged and dropped already behaves in the suggested way, it's just attachments added by the translator that get this special treatment; (3) there is already a field for translator in the right pane so it is redundant information and the file name is arguably more important.

    References: Old thread with proposal (2008); recent example of a user who got confused by the distinction.
  • edited December 15, 2011
    36) (Related to 35) Also auto-rename add an option to auto-rename PDF attachments that are manually added. If renaming is done for translator-added PDFs it should also be possible to enable it manually added PDFs.


    /edit: reworded in response to mronkko.
  • About 36: Manually added attachments should not be autorenamed, because there are valid reasons to keep the original names. For example, I have several books that I have scanned and stored as separate chapters.

    For example one of my items has the following files
    Nunnally1978_Bibliography_and_Indexes_OCR.pdf
    Nunnally1978_Ch1_Intro_OCR.pdf
    (about 15 more files would follow)

    Autorenaming would have no way of knowing which chapter is which and this information would be lost.
  • Fair enough; but I do think by far the most common use case across the whole userbase is adding single attachments, so it would still make sense if there were an option to enable this.
  • edited December 16, 2011
    37) Add UI to allow the tagging of multiple items in the right pane where people expect it.

    It is really striking how often this comes up in the forums (it was the topic of my first posting here back in 2007 and it came up for a brand new user yesterday — and we know that the people coming to the forums are only the tip of the iceberg!).

    The "select multiple items and drag on tag in tag selector" is just plain unintuitive and should be supplemented by something better.
  • @37, maybe the right-click menu in the center pane could be expanded with the entries:

    * "Add Tags...", which would open a popup window "Add Tag(s)" with an entry field with autocomplete of existing tags (the tags could be shown similar to citations in the new citation entry window used for the word processor plugins, which would also allow for comma-delimited entry of multiple tags).
    * "Remove All Tags"
  • edited December 22, 2011
    38) Throw an error when a user attempts to add a customized style that doesn't validate. Right now drag and drop for invalid styles fails silently, leaving users needlessly clueless.
  • wrt 38 - didn't there use to be a "This does not appear to be a valid style" error?
  • edited January 9, 2012
    39) Provide a notification that item attachments were not transfered when dragging an item with attachment to a group library where attachments are not in use instead of silently discarding the dragged attachments.

    https://github.com/zotero/zotero/issues/24

    40) Allow dragging an item to a library even if it exists in the trash of that library

    Example where 40 would be useful
    - Drag any item from group library A to group library B
    - Remove that item from group library B
    - Drag the same item from group library A to group library B. This does not succeed because the item is already in trash. This is not consistent how trash works in any other software that I use.

    https://github.com/zotero/zotero/issues/25
  • 41) When I import an item, I get the small "Saving item..." dialog to the bottom right corner of the browser. This should be modified to be "Saving item to {LIBRARY NAME}...". The advantage of doing this would be that I would immediately notice if I am saving items to a wrong library.

    https://github.com/zotero/zotero/issues/23

    Seems that many papercuts have not been added to GitHub because the issue number there is much smaller than the numbering of paper cuts here.
  • Yup. I have been adding papercuts only here, under the (naive) impression that they were automagically added on github or trac. Am not particularly keen on maintaining yet another account (same reason I avoid commenting on Trac or zotero-dev)...
  • I submitted a patch for 14, and it was merged into 3.0 a couple weeks ago. The patch included the same functionality for tags as well.
  • willshanks: Your patch was merged into master, not 3.0.
  • I believe devs generally follow issues here, too - it's just easier to keep an eye on things over on github where they can be closed etc.

    38 for example has been implemented a little while ago.
    Also, one of mark's pet issues - the progress bar for add-by-identifier was just committed to the 3.0 branch by Simon - I thought this was among the papercuts, but don't see it here.
  • edited January 19, 2012
    Good to hear that some of these things are already fixed. For reference, the add-by-identifier UI suggestion was #31 on the previous page, but also a separate thread here.

    Could I perhaps suggest that someone more Github-savvy occassionally trail this thread and add suggested items to Github? Shouldn't take too much time, and if that gives devs better ways to respond that would be great. I could then edit my posts in this thread and mark things "done" as needed to prevent confusion.

    I just did this with #31. I have the feeling that #34 might also be implemented already, can someone confirm?
Sign In or Register to comment.