Hi David,

It's interesting that you bring this up. When we designed the touchscreen
it was more or less as a one-off prototype, just to see what we could do
with what we had. We wanted an aesthetically and functionally pleasing
experience, but other than including some familiar content areas and layout
within those areas, we didn't strive for consistency with other interaction
experiences we offer in any meaningful way -- though nor did we
deliberately set out to make things outrageously different. I think a lot
of the distinctiveness of the interface arose organically in an effort to
develop an interaction model that would be very clear in the "public
touchscreen kiosk" context.

However, a redesign of the touchscreen is in the pipeline, and one of our
primary goals is to make it more consistent with other experiences that we
offer (especially the mobile website), in terms of aesthetics, iconography,
vocabulary, and functionality; at least to the extent that's practical in
context. Of course there'll be some specialty stuff that's unique to the
touchscreen context, but the end result should be familiar enough to users
of the mobile website that the learning curve should be significantly
reduced.

Whether this functional aesthetic gets extended to the website and to
physical library spaces remains to be seen; traditionally we haven't
coordinated these things too strongly, especially with respect to user
experience, but some strategic initiatives that are now underway will
probably result in stronger and more uniform guidelines across our user
experience space. It's definitely something that's on our mind.

(To be clear, in the portion of the article you quote, I was really trying
to say that the interface for the touchscreen was intended not to betray
the fact that it was really just a web browser running on an off-the-shelf
computer. By "dedicated" I meant to indicate that the feel we were going
for was that of a kind of magic box, one whose only purpose in life was to
serve as a touchscreen informational interface -- totally disguising the
dirty details of web browser, HTML content, and mac mini that were making
it go.)

-Dre


On Tue, Feb 14, 2012 at 11:23 AM, David Talley <[log in to unmask]>wrote:

> From the article Tod helpfully links: "One of our implementation goals was
> to build a touch interface that
> appeared to be completely dedicated and self-contained: we did not want
> it to be apparent to the user that the interface had been created with
> and was being driven by commodity components. "
>
> I'm stuck by the self-contained nature of this project design, and
> similarly with the iPad catalog look-up tools. Are such implementations
> most successful with separate, narrowly defined goals? Or would a library
> want to keep a consistent interaction experience across the website,
> kiosks, and even physical space (signage, displays, functional process
> terminology, etc.)? I tend to think that even if specific interaction
> methods are tailored to provide particular information in specific
> contexts, they all need to be designed as components of the user's overall
> interaction experience.
>
> David
>
> ------------------------------
>
> Date:    Mon, 13 Feb 2012 09:55:09 -0600
> From:    Tod Olson <[log in to unmask]>
> Subject: Re: Touch Screens in the Library
>
> NCSU has done some work you might be interested in.  See this article:
>
> Lessons in Public Touchscreen Development
> by Andreas K. Orphanides
>
> http://journal.code4lib.org/articles/5832
>
> -Tod
>
> Tod Olson <[log in to unmask]>
> Systems Librarian
> University of Chicago Library
>