manual citation entry CLUNKY

hi. i'm not sure whether this post "fits" in this category, but here goes:

i just spent an hour manually entering citations into zotero (these were the leftover ones that, for various reasons, i didn't already have in endnote). in every case that i have 'automatically' added citation information from a website into zotero, i've had to do quite a bit of manicuring, so these comments apply to very broadly...

there are three features (bugs?) of the interface that _really_ slow down manual entry in zotero:

1) getting "in" to each field takes at least two clicks of my mouse. the first click seems to highlight the field (or 'release' you from another field that you've been typing into) but doesn't allow you to alter anything, the second (or third!) click actually allows you to enter text. when you combine this with the tendency of the fields to change size based on how much text has just been entered, you end up with _lots_ of clicks (like, 4) to get into most of the fields.

2) the "tab" feature does not work in a consistent way. for example, tabbing into a new field does not allow you to edit that field--it just serves as the "first" click (see above). also, when you try to tab from the author first name to the next field, the 'tab' starts moving you around in a different zotero window (the 'collections' frame) altogether and messes totally unrelated stuff up...

3) the "autofill" feature in the fields that have it stays open sort of indefinitely until you click on another field. this means that if you want to proceed from one field with the 'autofill' feature enabled to the field below it (like "publication" down to "volume"), you have to click on a _third_ field to clear the autofill so that you can get access to the "volume" field ('cause it's covered up by the 'autofill').

  • What platform are you on? Have you tried disabling custom extensions or themes? On OS X and Windows 7, I can't reproduce any of this.
  • On Linux I can kind of confirm 3) but since tabbing works fine, it's not an issue - to get to the next field you just press tab. Also, Autofill goes away if you either select something or type to the point where the entry is unambiguous. Not sure what a good alternative would be - seems fine to me.
    That's on 2.0.9 on FF 3.6.14 and Ubuntu.
  • yeah. it's weird. i have a mac and a windows machine and i get similar wonky results with both. i just tried to reproduce the behavior outlined above and was able to on both machines. the weird thing is that it's not consistent. try these two scenarios to see what i mean:

    create a new item 'book.'
    set the author field to 'last, first'
    enter a value for 'last'
    try to tab into the 'first' field


    add a value for publisher that makes the autofill come up and type exactly one of the autofill options (on my computer, autofill stays open even when you've completed one of its options). now, hit tab. on my machine, if i repeat these steps ten times in a row, about half the time i "lose" my cursor 'cause it leaves the frame. it's weird and maddening and i can't figure out how to make the behavior consistent!
  • mcsugarfree,

    Before going further, let's be sure of the answers to Simon's questions above. As no one else has reported this kind of behavior, the first place to look will be in the configuration of your local systems. Let us know your OS, Firefox version number, specific version of Zotero, and whether you have tried disabling themes and extensions in the browser, followed by a restart.
  • Mac: ff 3.6.14/Zotero 2.1b7
    Win: ff 3.6.13/Zotero 2.1b6

    i don't have any themes or extensions that are not zotero related on either machine...

    as far as i can tell, zotero is operating "properly." the "clunkiness" i'm reporting is not, i don't think, the result of a malfunction.

    let me describe it it slightly more detail, now that i've played around a little more...

    each of the fields in the entry is capable of being in one of several "states" (there is the 'mouseover' state, during which it turns purple; there is the "click" state, during which it turns dark blue; there is the 'active' state, during which there is a blinking cursor and text can be entered; and there is the 'inactive' state...there are probably other states, too...)

    the 'clunkiness' is resulting from the fact that often hitting tab after an entry has been made in field 'F' results in field F going to the 'mouseover' state. the next field below field F (let's call it field F+1) does _not_ become 'active', as it should. rather, field F stays in the 'mouseover' state and if you hit tab a second time, the cursor gets moved to some other _frame_ in zotero. the only way to get field F+1 into the 'active' state is to click on it either once or twice, depending on the 'state' of the previous field. believe me, the time this takes (and the frustration) adds up...

    there is something weird about the way the 'mouseover' state is working. seriously. mess around with entering some data in a field and hitting tab and you will see what i mean. sometimes, everything works just right, but often lots of 'clicks' are needed to keep each subsequent field 'active' so that data can be entered...

    i feel a little bad bringing this up, 'cause there are no doubt bigger fish to fry out there in zoteroland. but there it is...

  • No, this is a big deal. But it's not what everyone is seeing, so we need to figure out why this happens fo you, when it doesn't happen for other people. I don't see why it would matter, but try installing the next most recent release, 2.1rc1.

    Are you sure you don't have any Personas installed?
  • my experience is that a field that gets tabbed into turns active-grey*, i.e. with the whole field selected. If I start typing, it erases all prior content. If I don't want that, I can use the arrow keys to get a cursor. Is that what you mean by a "click" state? That's 100% reliable for me and I've been using Zotero - including manual entry - a _lot_.

    *actual colors will differ depending on several factors
  • @ ajlyon, in ff i got to tools->Add-ons->extensions and i see only three items (python ext, zotero, zotero Macword integration). if i got to 'themes' there is nothing i can select or disable. i'm not sure about 'personas' --i haven't added any that i was aware of-->how do i confirm that i don't have any personas installed?

    i'm reluctant to change the version of zotero i'm using because i recently installed the trunk xpi because of problems i was having (per this thread: can we hold off on that until it really seems necessary?

    @adamsmith, when i tab into a field successfully (which doesn't always happen) the border of the field glows blue (but not the inside) and the existing text gets highlighted just as you say (if i type the text is erased, if i use an arrow the text stays). this--what you're describing--i call the 'active' state. the 'click' state is what happens when you mouseover a field and then hold the mousebutton down without releasing it. all the problems i'm having with tabbing etc have to do with the 'mouseover' state not turning into the 'click' state or 'active' state like i wish it did! the 'mouseover' state in one field somehow sometimes prevents other fields from being made active, if that makes any sense.

    really?! no one can replicate what i describe above?!
  • Can you make a screencast or screenshots of what you're seeing? This is indeed odd. I have seen funny issues at times, but they were linux-only, and related to Firefox bug (or maybe They could be addressed by switching focus away from and back to Firefox, and it appeared again only after the computer restored from sleep.
  • mcsugarfree, 2.1rc1 contains the fix from the trunk XPI. You should install it soon, because the trunk XPI may become unstable in a week or two.
  • edited March 8, 2011
    ok. here's a screencast in two episodes (don't worry--they're short).

    let me know if this doesn't work for some reason (youtube was being glitchy and i'm new to the "free file sharing" racket)
  • Watched the screencasts, tried on a couple of systems here. Under Linux with the 2.1rc1 client, hitting tab on a field that has the autofill pulldown open closes the field (the behavior on first-entry in your first screencast). It does not push forward to the next field.

    This is perfectly accidental, but the UI to the multilingual client behaves as you desire, with tab always pushing the cursor forward to the next field. I hadn't noticed that the behavior was different, but then I've been putting in much more time on building the variant than on research recently. Lots has changed in the mechanics of the UI for multilingual support, so it's not all that surprising that it behaves a little differently.

    I wouldn't recommend that you adopt the multilingual client for a transient reason like this; it is an experimental product, coded almost entirely by one guy (me) without review. Probably not something you want to commit your life's work to at this point. If you do decide to try it as a stop-gap alternative, be sure to back up your data regularly, and to keep the old copies just in case the unexpected .
  • I see what's happening. Sometimes picture is worth a dozen posts.

    Maybe this could be fixed by 2.1 final? Is this a fix that could be brought in from multilingual relatively easily?
  • edited March 8, 2011
    There are too many changes to the UI in multilingual under the hood, it wouldn't be safe. But it looks as though the Javascript may just be failing silently after the save, leaving the field selected but failing to fully execute the tab jump (I'm sure that the intended behavior is for the next field to be selected). The whole process is implemented in Zotero's own code, so it should be fixable or tunable. But that's just talkin' of course.
  • Hitting Tab with an open autocomplete drop-down closes the drop-down advances to the next field for me on OS X.
  • Now, that is very odd. I just checked again, and found again that tab would not advance to the next field, but only saved to the current field. Then I went into the profile hierarchy, unpacked the XPI, deleted the jar file, and added a string to the catch at the end of hideEditor() to try to see if it was failing.

    After repacking the jar file, I find that the interface is now behaving normally. A long delay before creating each new item for testing has also disappeared. All good news, but I wish I knew why it came right. What might have changed from merely restarting with a repacked jar file?
  • In my testing, I can reproduce this, but only in the Zotero tab. It doesn't happen in the pane. In the tab, the notifier is getting triggered twice, and the second time it blurs the field. I'm looking into it.
  • I can confirm Simon's report - the pane is behaving as expected but when zotero is open as a tab it is not "tabbing" through correctly when filling out a new item manually.


    OSX 10.6
    Firefox 4b12
    Zotero 2.1rc1
  • what is meant here by the zotero "pane" versus the zotero "tab", please?
  • having Zotero open in a FF tab (tab) versus the old way, in which Zotero is either open or closed for all tabs in a window (pane).
  • This is fixed for 2.1rc2.
  • you guys are superheroes.
  • Is it all fixed? I'm still experiencing the 1st problem: "getting "in" to each field takes at least two clicks of my mouse. the first click seems to highlight the field (or 'release' you from another field that you've been typing into) but doesn't allow you to alter anything, the second (or third!) click actually allows you to enter text."

    I'm using Zotero 3.0.7 in a pane in Firefox 13.0.1 on Windows 7 64-bit.

    It's costing me a lot of time! thanks for anything you can do. Should I submit this as a feature request? Could I edit hte source and fix this myself? thanks! -Josh
  • I think the ability to click once to leave a field without selecting a new one is by design and I find that very convenient.
    If you don't have a field selected before, one click should allow you to start typing.
  • I am using the current 3.0.8 standalone version of Zotero. I am manually correcting about 2000 records imported from Endnote and also find overall moving between fields, waiting for new field content to be accepted particularly new tags, etc. is just overall sluggish. I have to work very slowly. It is not possible to type in a tag, hit return, and get the next tag field to appear to type in etc. Same applies with the sluggishness of choosing suggested content in fields where I am repeating the same. It seems that the more records added the more sluggish it gets. Like it wants to be reindexed every 50 records. My current practice is to close Zotero every 30 records to get a little more speed. I really like Zotero, but until I get all the 2000 records cleaned up its very frustrating. I'm using Windows 7.0 with a good processor on a newer Intel laptop. I compare the difference in sluggishness with entering data into Endnote which is very fast, but I want to move away from it.
  • edited July 15, 2012
    ketchell: That definitely doesn't sound like normal behavior. Start a new thread (this one is about a different issue) and provide separate Debug IDs for operations that are slow. Also, make sure you empty your Zotero trash first to make sure you don't have more items in your database than necessary (e.g., old imports).
  • also, note, that you can get from a tag entry to a new, empty tag by using shift+return (same for authors)
  • Thanks for you fast comments.

    I did find 616 items in my trash. I'll work with the dataset for a while and see if that resolved the overall sluggish performance when doing manual editing. If not, I'll start a new thread.

    I'll try the shift+return which I hadn't discovered in the tag entry window, and see if that speeds entry vs. mouse click.
  • I'm keeping my trash empty and it seems faster. I'll start a new thread if it bogs down.
  • You shouldn't need to worry about the trash in general—only if you've deleted a lot of items in a short period of time—but there's a pref to control the number of days after which to automatically purge deleted items.
Sign In or Register to comment.