[OPEN-ILS-DEV] OPAC (was: Planning for Evergreen development, post 2.0)

[Bill Erickson]

On Fri, Jan 7, 2011 at 1:01 PM, Dan Scott <dan at coffeecode.net> wrote:
<snip>

>
>  * Provide a full-featured OPAC that requires no JavaScript, but uses
>    JavaScript for enhancements
>
>    Why: The current OPAC takes an agonizing amount of time to load when
>    the JavaScript is not cached: 10 - 15 seconds on a DSL connection is
>    pretty normal http://www.useit.com/alertbox/response-times.html has
>    some interesting observations on Web response times, but we all know
>    that 10 seconds is not fast.


Indeed, to a large segment of the patron population, the OPAC is aggravating
or simply unusable.


> The underlying HTML of the current OPAC
>    is also useless to Google and other search engines; a rewrite that
>    generated semantically meaningful HTML could actually provide
>    another entry point into our catalogues.
>
>
Reduced reliance on JS would improve browser compatibility, usability on
mobile devices, etc.  Reduction in XHR would reduce bandwidth requirements.


>    Development impact: Another OPAC rewrite. Would it be possible to
>    provide the functionality we need to support the staff client in the
>    new OPAC in the time frame we have to develop a new HTML-based OPAC,
>    or would we have to maintain both OPACs for a period of time? (The
>    latter seems likely anyway given the investment in skins that some
>    sites have already made).


It would depend on the time frame, of course.  Practically speaking, though,
staff client integration is still fairly basic when compared to all of the
other OPAC functionality.


> Skinning will require learning TT2 or
>    whatever underlying framework is chosen (which might be easier/more
>    powerful in any case).
>

Given that the current framework has limited capacity for local
customizations, I would expect just about any change (TT2, etc.) to be an
improvement in that regard.  Also, in theory, modifying skins would be much
simpler without all of the DHTML.  (Where'd that <div> come from?)


>    User impact: Changed user interface means some relearning. Speed
>    boost should be significant.
>

I've been beating my head against the OPAC a lot lately and it's probably
created some obvious bias ;)  This would be a big project, of course.  There
is quite a bit of functionality in the OPAC (more than I can remember,
sometimes).  In my opinion, though, such a change, if done right, would be a
major victory for Evergreen and one of the most important requirements for
wider adoption of the software.

-b

-- 
Bill Erickson
| VP, Software Development & Integration
| Equinox Software, Inc. / Your Library's Guide to Open Source
| phone: 877-OPEN-ILS (673-6457)
| email: erickson at esilibrary.com
| web: http://esilibrary.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20110111/4983b82b/attachment.htm