Upgrade StorageZ Word plugin: search behaviour changed, counterintuitive results
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.
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.
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?
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.
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.