Z Word plugin: search behaviour changed, counterintuitive results

edited October 17, 2017
I reported something that bugged me recently but I think I misdiagnosed it then as being only about ordering.

In short, it seems the behaviour of the add/edit citations interface has changed (since Z 5 I think). I keep running into this and find it majorly affects my workflow. Can't make screenshots of the Word plugin so we'll have to make do with a verbal description. Both Z and Z Word plugin are up to date.

Scenario: Editing a paper, frequently adding and editing citations to an extensive bibliography from my much more extensive library. Using the default interface of the Word plugin to search/add new items.

1. Add new citation -> 'Casillas 2014' (a paper already cited elsewhere in the doc). Duly comes up under Cited, but: the list of search results from 'My Library' includes loads of items not filtered by both words I typed: includes many non-2014 papers by same author. Why is Z displaying items that clearly do not match my visible input?
2. Type 'Casillas 2014 ' (with a space at the end) — NOW I get the filtering I want. But why only now?

Another try:
1. Add new citation -> Type 'Gardner'. Takes a few seconds, finds not cited in doc yet, presents list of search results similar to filtering on 'Gardner' in Z library. As expected.
2. Now add '2010' after it, yield 'Gardner 2010'. Z plugin pretends to be thinking ('Loading Cited Items...'), takes a few seconds, then serves me the exact same list as before. So providing extra input did put the plugin to work but did not provide the expected result of filtering the earlier search results.
3. Now add ' ', yielding 'Gardner 2010 '. Only now do I get what I want. Too late, especially given the conflicting UI cues of step #2.

You may say, so just learn to type a space at the end. But (i) that goes deeply against the interface logic of all known search and filter input fields; you really shouldn't ask people to do that. Moreover, (ii) it's particularly counterintuitive when you search for partial names (as I often do).

Which leads me to another demo:
1. Add new citation -> type 'Scheglo' (a partial name) in one go. Plugin takes a few seconds, finds 3 citations of 'Schegloff' in doc. So far so good. But the list of search results from My Library includes partial matches to only the first three characters of my input: "Schel et al. 2005", "Schellenberg 2012", etc. (!). This is not helpful at all.
2. Now add 'ff', yielding 'Schegloff' in the search window. Results list is updated. Adding more characters functions like adding a space. I think I'm getting it, from a programming point of view — but this is definitely not what a user wants or expects.

I'm sure there are other intricacies to this I haven't covered; this is just me trying to capture my growing frustration with what seem to be obvious regressions in the search interface. I now run into this literally every time I try to cite something, and it is not a matter of getting used to a different order or way of interacting with the system: the interface now regularly delivers results that are clearly wrong and highly counterintuitive.

Addendum:
Putting on my nonexistent developer's hat I suspect this is a search optimization strategy gone rogue — it may be a good idea to do a quick filter on the first three chars of a users' input, and this may work well in a small library where three chars will uniquely identify almost all authors, but (i) in a huge library like mine, it breaks down entirely and (ii) surely after a first quick filter you'd then want to check whether the user provided input beyond the first 3 chars and take that into account for another round of filtering.
  • This does seem to be new behavior in Zotero 5 (since the middle betas at least). It’s been reported a few times, and I agree that it is counterintuitive.
  • Did a quick search on github and didn't see any reports there yet. I added a note to a thread that seemed most relevant but don't really know my way around the open issues there — help or guidance would be appreciated. I'm mainly interested in whether it's clear to the devs that this is a regression.
  • edited October 18, 2017
    Please keep bug reports and feature requests to these forums. The GitHub issues are intended for developers and people doing coding. It’s much easier to have discussion here—the developers read every forum post.
  • edited October 18, 2017
    (That said, it's not always clear, including to me, when tickets get created and when they don't and I agree that can be confusing. This may just be an issue of not taking the time -- I don't always log Zotero translator issues as gh tickets, although I've tried to be better about that recently. For translators, I'd actually appreciate help with this -- though the ticket should always be created by someone _confirming_ an issue, not the person reporting it.)
  • I don't think I'm seeing this.

    I go to https://scholar.google.com/scholar?hl=en&as_sdt=0,33&q=pinker&btnG=&oq=pinker and save the first 7 results to my library. In a new Word doc, I bring up the Quick Format bar and type 'pinker'. I see all 7 results. I then type '2009' (without a space) and get the one correct result. Am I trying something different, or are you getting different behavior? If you are, could we see a Debug ID for it?

    @bwiernik: Are you getting this on a Mac or on Windows?
  • Did some further testing and I think I found the conditions under which this happens. The key: messy typing (surprisingly common; at least enough so for me to not be aware that this united the cases in which I experienced this). Debug ID D1701025628 but maybe that's not necessary.

    In a new document, using the same 7 fresh Pinker references from Google Scholar, if I do what Dan did all looks well. But here's what it looks like when I do it as a messy typer, typing Pinkke [2x backspace] er 2009, all in one go: screenshot. Here, you can see that even though the search input says "Pinker 2009", the results from My Library show all years, not just 2009.

    This gets weirder the earlier your typos are, as here. Not sure what my keystrokes were here, but they made the weirdest references appear in the search results. Anything that includes "Pin" perhaps?

    Finally my "Schegloff" results above also make sense. That's a hard name to type so it seems I often 'stutter' and recover. This screenshot shows what happens when I, apparently, stuttered after "Sche", recovered and typed the full "Schegloff": references listed include everything that has a "sche" anywhere, which could be authors but also titles (as here, "baskischen", "grammatischen").

    That final case also shows the source of my confusion about ordering of results (the subject of my earlier thread). Even if the match is only to "Sche", shouldn't authors/creators be privileged over partial matches from titles? And yet there is no discernable order at all — not by author name, nor by title. This may be a separate issue but it is also not how I recall things worked up to a few months ago.

    Diagnosis: Search gets to work as soon as possible, somehow doesn't get an updated string passed when the series of keystrokes provided by the author includes backspaces, i.e. when the author is typing messily and correcting things on the fly. Updated string does seem to used when another character (including space) is added after first delivery of results, which explains that search results make more sense on second delivery.
  • edited October 20, 2017
    Here is Debug Output where the search results aren't working correctly:
    D1293307472

    In the output, I am searching for the term "Wiernik", which correctly filters Cited items and items in Libraries to only include papers authored by me (occasionally, searching for words like this doesn't work, but that doesn't happen here). However, when I add "2015" to the search, the window still shows results published in 2013, 2012, 2018, etc. These don't disappear until I type a space after 2015.

    If you need video, I can try to do a screen recording.
  • A lot of the related code here is being updated as part of the delayed-citations feature, so let's revisit this once that lands in the beta (which should be soon), and we can debug this further if it still exists in that.
  • Great thanks.
  • Just to crossreference a new thread where similar problems are reported: https://forums.zotero.org/discussion/69656/quick-format-bar-returns-irrelevant-items
  • Sorry for taking so long to look into this. (The delayed-citations features hasn't yet landed.) This should be fixed in the latest 5.0 Beta, and the fix will be included in 5.0.34 within a few days. If you try out the beta, let me know if it's working as expected for you.
Sign In or Register to comment.