Bug 13218

Summary: usability enhancement for z39.50 search
Product: Koha Reporter: Liz Rea <wizzyrea>
Component: CatalogingAssignee: Liz Rea <liz>
Status: CLOSED FIXED QA Contact: Testopia <testopia>
Severity: enhancement    
Priority: P5 - low CC: chris, frederic, jonathan.druart, katrin.fischer, m.de.rooy, tomascohen, wizzyrea
Version: master   
Hardware: All   
OS: All   
Change sponsored?: --- Patch complexity: Trivial patch
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Bug Depends on:    
Bug Blocks: 7741    
Attachments: Bug 13218 - usability enhancements for z39.50 searches
Search dialog box
Search result
Bug 13218 - usability enhancements for z39.50 searches
Bug 13218 - usability enhancements for z39.50 searches
Bug 13218 - fixing acquisitions z39.50 interface to be consistent with the others.
Bug 13218 - fixing acquisitions z39.50 interface to be consistent with the others.
Bug 13218 - fixing acquisitions z39.50 interface to be consistent with the others.
[SIGNED-OFF] Bug 13218 - fixing acquisitions z39.50 interface to be consistent with the others.
Bug 13218 - usability enhancements for z39.50 searches
Bug 13218 - fixing acquisitions z39.50 interface to be consistent with the others.
Bug 13218: (qa-follow-up) replace tab with spaces
Bug 13218: (RM followup) only scroll on actually variable stuff
Current view with lots of targets
Proposed view with lots of targets
Bug 13218: (RM followup) only scroll on actually variable stuff

Description Liz Rea 2014-11-07 08:21:32 UTC
The z39.50/SRU and authority search windows seem to be occasionally confusing for users.

It seems that splitting the search fields into two columns suggests to librarians that they can either have a search from one column or the other - something that is simply untrue but that the interface seems to suggest.

Additionally, when many z-targets are configured, there is considerable scrolling necessary to get to the search button. One of the goals of this page is to make cataloguing easier and faster, and scrolling takes extra time.
Comment 1 Liz Rea 2014-11-07 08:31:18 UTC Comment hidden (obsolete)
Comment 2 Frédéric Demians 2014-11-07 17:08:35 UTC
Created attachment 33382 [details]
Search dialog box
Comment 3 Frédéric Demians 2014-11-07 17:08:55 UTC
Created attachment 33383 [details]
Search result
Comment 4 Frédéric Demians 2014-11-07 17:10:29 UTC
I like the new layout. But do you thing you could do something for the unsightly scroll bars that are displayed on search dialog box and search result page? It would be great to have dialog box sized properly to display all its content without scroll-bars.
Comment 5 Liz Rea 2014-11-08 01:56:47 UTC
Yep, will have a look at that.
Comment 6 Liz Rea 2014-11-08 02:15:47 UTC
Hi Frédéric,

I think it's sensible to have a vertical scroll on the search results, you're right there shouldn't be one on the search page itself though.

Does that seem sensible to you?

Liz
Comment 7 Liz Rea 2014-11-08 02:26:19 UTC Comment hidden (obsolete)
Comment 8 Frédéric Demians 2014-11-09 08:43:47 UTC
(In reply to Liz Rea from comment #6)

> I think it's sensible to have a vertical scroll on the search results,
> you're right there shouldn't be one on the search page itself though.

Yes, of course. My screenshot was pointing to the vertical scrollbar. That was an error. I was meaning that the horizontal scrollbar is superfluous.
Comment 9 Frédéric Demians 2014-11-09 08:44:20 UTC Comment hidden (obsolete)
Comment 10 Liz Rea 2014-11-20 07:25:45 UTC Comment hidden (obsolete)
Comment 11 Liz Rea 2014-11-20 07:26:47 UTC
needs signoff for additional patch to acquisitions module z-search
Comment 12 Frédéric Demians 2014-11-20 16:22:13 UTC Comment hidden (obsolete)
Comment 13 Frédéric Demians 2014-11-20 16:23:53 UTC
Idea for another patch: Template factorization = One include TT used in z39.50 searches, from cataloging, and from acquisition.
Comment 14 Liz Rea 2014-11-20 19:58:22 UTC
Yes, actually that is a fantastic idea - though the search fields are a bit different for each of these screens, I learned while I was looking at it.

There is probably a way around that, I'll have a think. Maybe a phase two for this little project. :)

Liz
Comment 15 Frédéric Demians 2014-11-20 21:05:17 UTC
Comment on attachment 33747 [details] [review]
Bug 13218 - fixing acquisitions z39.50 interface to be consistent with the others.

Review of attachment 33747 [details] [review]:
-----------------------------------------------------------------

::: koha-tmpl/intranet-tmpl/prog/en/modules/acqui/z3950_search.tt
@@ +99,5 @@
> +             <li><label for="controlnumber">Control no.: </label> <input type="text" id="controlnumber" name="controlnumber" value="" /></li>
> +             <li><label for="author">Author: </label> <input type="text" id="author" name="author" value="[% author %]" /></li>
> +             <li><label for="issn">ISSN: </label> <input type="text" id="issn" name="issn" value="[% issn %]" /></li>
> +             <li> <label for="subject">Subject heading: </label> <input type="text" id="subject" name="subject" value="" /></li>
> +	     <li><label for="dewey">Dewey: </label> <input type="text" id="dewey" name="dewey" value="" /></li></ol>

At the end of the line, there is a </ol> which shouldn't be there. I've missed it when signing-off the patch. Could you fix that?
Comment 16 Frédéric Demians 2014-11-20 21:08:05 UTC
(In reply to Liz Rea from comment #14)
> Yes, actually that is a fantastic idea - though the search fields are a bit
> different for each of these screens, I learned while I was looking at it.
> 
> There is probably a way around that, I'll have a think. Maybe a phase two
> for this little project. :)

That doesn't seem so easy to do! Obviously, acquisition z3950 code comes from cataloging code. But it has diverged since.
Comment 17 Liz Rea 2014-11-20 21:10:55 UTC Comment hidden (obsolete)
Comment 18 Owen Leonard 2014-12-09 17:31:03 UTC Comment hidden (obsolete)
Comment 19 Jonathan Druart 2014-12-10 08:56:49 UTC
Created attachment 34270 [details] [review]
Bug 13218 - usability enhancements for z39.50 searches

This patch rearranges the layout of the z39.50 search pages in cataloguing and
authorities.  There should be no functional change to z-target searching, all
functions should remain the same.

Changes:
* 2 columns of search fields condensed into one
* zTargets moved from below the search fields to beside them
* rearranged search fields into perceived frequency of usage, from most used to
  least
* changed label of Raw (any) to Keyword (any)

To test:
* click cataloguing -> new from z39.50/SRU
* observe how the layout has changed
* import a record or two using the search - there has been no change to the
  function, it should all be working.

* Click Authorities -> new from z39.50
* observe how the layout has changed
* import an authority or two using the search - there has been no change to the
  function, it should all be working.

* sign off if you think these changes are nice. Comments and suggestions are
  also welcome regarding this change.

Signed-off-by: Frederic Demians <f.demians@tamil.fr>

Nice evolution of the z3950 search/result pages.

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Comment 20 Jonathan Druart 2014-12-10 08:56:53 UTC
Created attachment 34271 [details] [review]
Bug 13218 - fixing acquisitions z39.50 interface to be consistent with the others.

Changes:
* Two columns of search fields into one
* moves targets from below search fields to the right of them

To test:
* Create a basket in acquisitions
* attempt to add a record to the order from an external source
* note the changes to the layout
* complete a couple of additions to the basket - functionality should be unchanged.

If you like the changes, sign off :)

Signed-off-by: Frederic Demians <f.demians@tamil.fr>

Ok. Consistency welcomed!

Signed-off-by: Owen Leonard <oleonard@myacpl.org>

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Comment 21 Jonathan Druart 2014-12-10 08:56:56 UTC
Created attachment 34272 [details] [review]
Bug 13218: (qa-follow-up) replace tab with spaces

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Comment 22 Jonathan Druart 2014-12-10 08:57:51 UTC
Qaed with bug 7741.
Comment 23 Tomás Cohen Arazi 2014-12-18 00:16:26 UTC Comment hidden (obsolete)
Comment 24 Tomás Cohen Arazi 2014-12-18 00:17:44 UTC
Created attachment 34498 [details]
Current view with lots of targets
Comment 25 Tomás Cohen Arazi 2014-12-18 00:18:09 UTC
Created attachment 34499 [details]
Proposed view with lots of targets
Comment 26 Tomás Cohen Arazi 2014-12-18 00:19:53 UTC
I was about to push this one, along with my followup. But then I realized there's no rush to push this one, so: do you agree with the followup?
Comment 27 Liz Rea 2014-12-18 00:28:21 UTC
I agree with your followup, please go ahead and push it :)

Cheers,
Liz
Comment 28 Tomás Cohen Arazi 2014-12-19 17:06:36 UTC
Created attachment 34585 [details] [review]
Bug 13218: (RM followup) only scroll on actually variable stuff

Most of the page contents have fixed size. The only exception is the
targets list. If the target list grows, then the whole page needs to be scrolled
in order to reach the buttons.

We should make the z3950 targets area scrollable, and remove scrolbars from all
over the place.

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Comment 29 Tomás Cohen Arazi 2014-12-19 18:06:15 UTC
Patches pushed to master.

Thanks Liz!
Comment 30 Chris Cormack 2014-12-19 23:25:51 UTC
String changes, held for 3.18.3
Comment 31 Chris Cormack 2014-12-23 07:22:41 UTC
Pushed to 3.18.x will be in 3.18.3