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

[Lori Bowen Ayre]

Thanks for the feedback, Kathy.  I'll work on getting more info on the
issues that KCLS has run into so that people have a better idea of where the
problem spots were for them and when it was an Evergreen issue, skin issue,
or something else.

Lori

On Thu, Jan 20, 2011 at 11:03 AM, Kathy Lussier <klussier at masslnc.org>wrote:

> Hi Lori,
>
> I think it would be useful to see the KCLS skin in a public repository, but
> it would also be helpful to know where the trouble spots have been with the
> skin and with the new functionality. For example, we noticed that faceting
> was turned off soon after KCLS went live. Is it a problem with the way
> faceting works with the KCLS skin or is it a general problem with faceting
> that will continue to appear when sites start using the default skin in
> 2.0?
> It would help us understand which pieces of the KCLS OPAC we may want to
> adapt for our own use and which pieces we may want to avoid.
>
> Kathy
>
> -------------------------------------------------------------
> Kathy Lussier
> Project Coordinator
> Massachusetts Library Network Cooperative
> (508) 756-0172
> (508) 755-3721 (fax)
> klussier at masslnc.org
> IM: kmlussier (AOL & Yahoo)
> Twitter: http://www.twitter.com/kmlussier
>
>
>
>
> > -----Original Message-----
> > From: open-ils-general-bounces at list.georgialibraries.org
> > [mailto:open-ils-general-bounces at list.georgialibraries.org]
> > On Behalf Of Lori Bowen Ayre
> > Sent: Thursday, January 20, 2011 10:42 AM
> > To: Evergreen Discussion Group
> > Subject: Re: [OPEN-ILS-GENERAL] mobile OPAC functionality in 2.0
> >
> > 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 <http://www.galecia.com/>
> > (707) 763-6869 // Lori.Ayre at galecia.com
> >
> > <mailto:Lori.Ayre at galecia.com> Specializing in open source
> > ILS solutions, RFID, filtering, workflow optimization, and
> > materials handling
> >
> > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> >
> >
>
>


-- 

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=
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/fe68902c/attachment.htm