[Koha-devel] UI commentary on new zoomopac

[Corey Burger]

Hello all,

Thought I would introduce myself before I start spouting off. I
currently wear two major sets of "hats". The first is in the Ubuntu
community. I am a longtime member of the Ubuntu Documentation Team,
Marketing Team and have the unfortunately pleasure of leading the
Ubuntu Canada team. My second hat is with Userful. Userful makes
DiscoverStation, which is a Fedora-based (ick, I know) public
computing distro. I am a sales person for them. Now that the
introductions are out of way, I will dive into the meat of my message:
The OPAC interface.

All of the below comments are based off the zoomopac interface on
http://zoomopac.liblime.com/ as of July 7th,2006 (in case somebody is
digging through the archives for my words of wisdom^WWWinsanity)

== Overall Goals ==

Any good UI makes easy things very easy and hard things less hard. It
also emphasizes the common tasks over the uncommon. Blather aside,
what does this mean?

The following lack hard facts, but are gut feelings:
* The most common thing somebody is going to be doing just searching.
Enter term, hit enter
*  The next three most common things people search for are: Authors,
Titles and Subjects, in no particular order.
* Another common query I would say is "What boxes on X are in the
branch I am in/going to, right now?"
* Advanced searching beyond the above is going to be done by maybe
1:20, maybe even closer to 1:100
* Staff love advanced search interfaces. They do deal with it all day.
They also want fast search interfaces

== General UI comments ==

* Align text entry boxes, either right or left. Have the description
tag beside them, not on top or the bottom

== Search UI ==

* Search boxes have a common UI. It is a text entry field with the
button with the word "Search" on it. Sadly, the new OPAC appears to
have departed from this idea.
* Drop down menus suck. They are hard to hit and hide information.
Thus if we move Authors, Titles and Subjects, we need to have a
something different.
* Tabs are also bad, as they hide information.
* AJAX is a must. This part is already done well
* I thus suggest we have little "mini-tabs" above the main search bar.
They are labelled: General (or some better term for all inclusive
search), Authors, Titles, Subject.
* Colours are good for reinforcing connected-ness, so the background
of each of the mini tabs would be a different colour and as the user
switched the minitabs, the box around the search entry field would
change accordingly
* The world is full of slow internet connections, thus we need to fool
our users into waiting if the ILS is slow to respond. After they click
search, the page should switch to a hidden div with the words
"Searching" and an hourglass/busy symbol. Because this will have
already been loaded, the ILS can take its sweet time in responding and
the user will not get annoyed.
* The [ ? ] takes me an IndexData help page, written by technical
people for technical people. My eyes glazed over almost right away.
You don't need help on the simple search page. It might be justified
on the advanced page.

== Non-search UI ==
This is the fluff around the search, login,etc.

* There are two places to login to my account. The one on the right is fine
* Viewing new additions should take to a page with a complete listing,
newest at the top. After I am there I can search for specific
branch/subject/author/etc.

Attached is a png showing a rough mockup. I don't claim the mockup is
even roughly complete, but it does show the general idea.

Cheers,

Corey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: opac mockup.png
Type: image/png
Size: 41066 bytes
Desc: not available
URL: </pipermail/koha-devel/attachments/20060713/cff8bc46/attachment-0002.png>