On Wed, Mar 18, 2009 at 02:41, Janet Hill <Janet.Hill_at_colorado.edu> wrote:
> Well, such an interface might be considered a failure in certain contexts.
I think the crux here is that old adage where there's one interface
for the users and one for the librarian. Personally I doubt making one
work for both (or all) is hard at all, but it *does* require a
different process for making that interface, one that isn't supported
very well in most library environments.
> But if there are
> some kinds of queries or needs that are not satisfied by the simplest
> approaches, or if a query might be answered more quickly (or more completely
> or accurately) by means of an alternate approach, then asking the user to
> learn a little more about how to search (which might be thought of as
> learning shortcuts) is not unreasonable and is often welcomed.
Again we must be careful to separate the issues. There's a difference
between two interfaces vs. two processes in the same interface. Google
is again such an example, where if "topic maps how-to" doesn't bring
up what I want (the introductory Topic Maps article I wrote years
ago), then it's easy to alter through the same interface to "topic
maps how-to site:shelter.nu". By this I'm pointing out that an
interface should expand its functionality cumulatively, not by
introducing another interface. Some programs are fabulous at this
(Google in general is pretty good, or IDE's like Eclipse or NetBeans,
the latest Office ain't too shabby, etc.) and other are pure dreck
(and won't provide examples; I'm sure you can think of some). Of
course, these interfaces are harder to develop (you've got to be a
good developer, for example :) and require support for things like
UCD, UX processes and serious IA (things you didn't learn in library
school).
> (as a kind-of-aside, what seems intuitive to some is not intuitive to
> others.
Well, I'm glad you said this, because most library systems have been
created by librarians who think that their MARC-infused interfaces
makes perfect sense to *them*. :) Hopefully this will change before
it's too late.
> Figuring out how to load photos onto my ITouch is an example of
> that. You have to have an understanding of how programs tend to work to
> know where to look and what to do once you get there. You get that
> understanding through stumbling along through this program and that website
> and that application and this function. In other words, you get it through
> learning. Personally, I would have preferred not to have to wander around
> and deduce/guess/intuit how to manage the operation)
Programs and interfaces (and attitudes towards using and developing
them) are changing and evolving all the time. Even programs are now
starting to use the "iPod" interfaces, who again have it from
somewhere else. Slowly, but sturdly, things are improving, but there's
a loooong way to go, especially in the OPAC world where MARC still is
king and an important part of any new interface's requirements list.
Kind regards,
Alex
--
---------------------------------------------------------------------------
Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps
------------------------------------------ http://shelter.nu/blog/ --------
Received on Tue Mar 17 2009 - 21:08:09 EDT