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

[Tim Spindler]

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 contributor

I think this is a big improvement and something I think we would support.  I
think moving copy details below the copy availability also helps a lot in
the display.

Tim Spindler
C/W MARS

On Wed, Sep 21, 2011 at 10:05 AM, Dan Scott <dan at coffeecode.net> wrote:

> 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
>



-- 
Tim Spindler
tjspindler at gmail.com

*P**   Go Green - **Save a tree! Please don't print this e-mail unless it's
really necessary.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20110921/b3ef6799/attachment-0001.htm>