[OPEN-ILS-GENERAL] mobile OPAC functionality in 2.0

[Lori Bowen Ayre]

Thanks, Dan.  To be honest, I'm not clear what is involved in the "skin" or
the "skinning" process and it appears my guess was wrong.  At any rate, I'm
happy to pursue publication of the skin that was developed if people think
that would be useful as is.

I'll let you know what I find out.

Lori

On Thu, Jan 20, 2011 at 1:35 AM, Dan Scott <dan at coffeecode.net> wrote:

> On Wed, Jan 19, 2011 at 04:03:23PM -0800, Lori Bowen Ayre wrote:
> > Hi Tara,
> >
>
> <snip>
>
> > So.  After many attempts at fixes and tweaks, the KCLS and Equinox folks
> are
> > looking are completely rewriting the Evergreen OPAC.
>
> Note that it's not just the KCLS and Equinox folks, although they might
> have a contractual relationship. As a project we probably should have
> started this effort some time ago - we kicked the idea around a number
> of times - however, there were many other fish to fry and not many
> friers, and the current OPAC works well enough for most of us (even with
> the performance concerns) that it didn't became a high enough priority
> (outside of experimental efforts like the plain-HTML social interface).
>
> > This is ultimately
> > really good news because all that great new functionality will then be
> part
> > of Evergreen (no "skinning" required).
>
> Well, "skinning" will always be required, unless libraries want to live
> with the default Evergreen logo and text and colours and layout...
> Unless by "skinning" you mean something like "stripping all of the
> site-specific information from the surface of an interface", which is
> the opposite of what the term normally means but actually might be
> appropriate in the KCLS case.
>
> I'd still like to see the KCLS skin get published in a repository
> somewhere, as (unless the skin itself is exacerbating the performance
> problems at KCLS) the design elements that many oohed and aahed over
> so many months ago could still be a nice contribution to the project.
>
> > The bad news is that might take a while.
>
> If we tackle it as a high priority, rapid iteration effort, then we
> should be able to knock out large blocks of functionality relatively
> quickly. If pages and pages of formal specs need to be written first,
> signed off on, etc, before any code gets written, then that will take a lot
> longer.
>
>


-- 

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=
Lori Bowen Ayre // Library Technology Consultant
The Galecia Group // www.galecia.com
(707) 763-6869 // Lori.Ayre at galecia.com

<Lori.Ayre at galecia.com>Specializing in open source ILS solutions, RFID,
filtering,
workflow optimization, and materials handling
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20110120/eb174a5c/attachment.htm