[OPEN-ILS-DEV] Streamlined, more semantic TPAC skin - thoughts?

[Dan Scott]

Hi all:

I've spent a bit of time working towards a streamlined, somewhat more
semantic TPAC skin in the user/dbs/tpac_semantic_amazon_record_details
branch of the "working" git repo. Attached, find a couple of examples of
"-old" and "-new" screenshots and the source HTML.

The "-old" screenshots show how the current TPAC record details display.
It's appealing, but in practice a lot of the information gets buried
under twisties at the bottom of the page. Displaying more information by
default helps with visually scanning the page as well as making more
information digestible by search engines and improving the mobile
experience (load as much as possible in one shot rather than forcing
point & click & wait for reload interaction).

Taking a cue from the display used by some prominent book sales sites, I
moved all authors / creator credits up directly under the title, rather
than just the main author. (This could get interesting for music
compilations, films, etc; we can make different things happen in cases
where there are more than, say, 5 contributors...) 

I also made copy info available as a priority (supporting the use case
of "okay, I found what I want, now just get me to the resource"):

  * Electronic copies first, displayed in the box beside the cover art
    (if available); the ACM examples show results with OpenURL
    integration enabled
  * Physical copies second, displayed in a table immediately below the
    cover art section 
  * MFHD & serials is still in a twisty "Issues" at the moment but would
    be moved here as well (not sure whether before or after "regular"
    copies) 

Record details get moved below copies, again taking a cue from prominent
onling book sales sites.  Depending on how much we have in terms of
record details - currently just ISBN/ISSN, Publishing info, and Physical
description - we could try and jam this in beside the cover art. That
offers more immediate "Yes, this is what I was looking for"
gratification at the expense of pushing the copies down a bit. 

The subjects / series twisties get turned into "Search for related items
by (subject | series)" headings to support exploration; if the user has
reached this point in the record, they probably haven't found what they
were looking for so it's time to go exploring.

The search bar gets turned into a single row instead of two rows, saving
some vertical space.

I removed the navigation/ home page / print button / help tab as most of
the functions duplicate native browser functionality. The "Help" button
still needs to land somewhere, though. 

More interesting than the physical layout (at least to me) is the
gradual move away from tables-inside-of-tables to more positionable
blocks of info. I think this should help with skinning at the CSS level.

Also, the semantic level of change thus far has been minimal; the
"Title" gets placed inside an H1 tag and subheadings get H2 tags, rather
than just being CSS-styled table cells. This should help search engines
do a better job of picking out the important parts of the record;
however, I ultimately plan to move towards incorporating schema.org
microdata in the design.

One other thing I quickly experimented with was removing the fixed-width
attributes from the stylesheets; for the most part, the resulting page
worked, which bodes well for a broader set of devices (again thinking
mobile, but also thinking of 24" screens).

So, some questions:
  * Is this direction of general interest?

  * Are there document IDs that other parts of Evergreen care about (in
    particular, does the staff client need specific document IDs)?

  * I could break this out into a separate skin, rather than replacing
    the default skin as the branch currently does, but worry about a
    craftsman / default fork where one skin gets features that the other
    doesn't. To a certain extent, this skin may reflect academic
    institutional biases. If there's support for this skin, how do we
    want to proceed?

Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: acm-old.png
Type: image/png
Size: 115530 bytes
Desc: not available
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20110921/97144992/attachment-0004.png>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20110921/97144992/attachment-0004.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: acm-new.png
Type: image/png
Size: 126295 bytes
Desc: not available
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20110921/97144992/attachment-0005.png>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20110921/97144992/attachment-0005.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: derby-old.png
Type: image/png
Size: 177412 bytes
Desc: not available
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20110921/97144992/attachment-0006.png>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20110921/97144992/attachment-0006.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: derby-new.png
Type: image/png
Size: 184139 bytes
Desc: not available
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20110921/97144992/attachment-0007.png>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20110921/97144992/attachment-0007.html>