| The
tragic events of September 11 really messed up the autumn conference season
this past year. The Special Libraries Association cancelled its October
get-together in Monterey, California. Even after that, attendance was not
what it normally would have been for the Information Today Internet Librarian
conference held in Pasadena, California at its Conference Center [http://www.pasadenacal.com/faciliti.htm]
from November 6 through 8.
This was too bad,
because the setting was great. Pasadena, home to the Rose Parade, is located
at the base of the San Gabriel Mountains, about 15 miles northeast of downtown
Los Angeles. The weather in early November is just fine, warm with a bit
of haze.
Much of the conference
took place inside the Pasadena Civic Auditorium, a fantastically decorated
theater built in 1931 at the height of the "golden age of architecture"
in the Los Angeles area. The lush auditorium interior evokes a pastiche
of romantic Mediterranean notions. Pale satyrs and shepherdesses gambol
on peach panels around the room. At their feet, a powdery aqua wainscoting
marches around the house and up to the stage. The upper walls of this palace
are painted to resemble rippling green and crimson curtains reminiscent
of the time of the Medicis. Patterned grates cloister old theater organ
pipes. Forced perspective vistas parallel the proscenium arch. And on the
ceiling, figures from the zodiac seem to wheel and bless the crowds beneath.
The effect is very pre-war Hollywood. In fact, this theater has a strong
show business connection: It has played host to the Emmy Awards 25 times.
In contrast, the
conference center itself, built in 1973 in a low bunker style under the
auditorium plaza, lacks decoration almost completely. A long, windowless
hallway connects the meeting rooms with the exhibit area, its ecru vastness
broken only by a few lonely looking posters of planets and a satellite
view of the Los Angeles basin, courtesy of the nearby Jet Propulsion Laboratory
[http://www.jpl.nasa.gov/].
It is as if the
design of this conference complex, with its juxtaposition of the romantic
early century with the no-nonsense technological visions of the post-World
War II era, was trying to express the history of Southern California itself
through the medium of architecture.
So this was a fitting
setting for a gathering of librarians who strive to reconcile the old romantic
vision of our profession (holy books and silence) with the implications,
opportunities, and pitfalls of rapidly changing technology. The 2001 conference
focused on library Web page usability, patron training, taxonomies for
better searching, and a whole lot about 24/7 remote reference.
Something for everyone
means too much for one person! But let me offer, in some detail, the parts
of the program that I found most compelling.
XML for Libraries
I have never seen
Roy Tennant so excited. He takes the podium with a shine in his eyes and
a bounce in his step. His face is animated. He speaks with great passion.
What is the subject that moves him to such delight? XML for libraries!
By now, most of
us have heard of XML (eXtensible Markup Language). We know that it is cousin
to the HTML (Hypertext Markup Language) that we use to fashion our library
Web pages today. We may have had some idea of its filial relationship to
SGML (Standard Generalized Markup Language). But the details, especially
as related to library operations, remain fuzzy.
Tennant brought
the picture into focus. He explained that like pages written in HTML, XML
documents consist of plain text sprinkled with markup tags. These pairs
of tags indicate what the text between them is. In contrast with
HTML, which we use as a crude tool for Web page layout and hypertext linking,
XML can define the content and structure of a document. For
example, the author of a document can be marked as an "author" element,
e.g., <author>Jane Doe</author>.
You know how we
mark the beginning of a Web page <html> and the end </html>?
It is the same in XML. The difference is that the beginning and end tag
set, called the "root element," describes the nature of the document, no
matter what it is. For example, a book would have a root tag <book>
at its beginning and </book> at its end.
This content tagging
allows software to easily "parse" documents. With XML, all kinds of programs
can recognize the different sections and elements within a document. Tagged
data can be easily pulled out, indexed, and displayed according to the
preferences of an end-user.
Tennant explained
that XML is a simplified and "Webified" (that is, it supports hyperlinks)
form of SGML. Whereas most Web browsers cut us some slack for minor HTML
mistakes, XML is very strict and allows no mis-nesting or single tags.
Even the list tag <li> must have a corresponding close tag: </li>.
(The exceptions are empty tags such as <br>. These can be represented
as combination tags by placing a space and a slash after the tag letters,
e.g., <br />.) All attributes must appear in quotes, e.g., <td
align="left">. Also, XML is case-sensitive: Its markup tags must be
typed in lowercase.
How do we know
what tags to use? We can sort of make up our own tags. That's what makes
XML "eXtensible." However, we must make certain that the tags we use are
defined in a companion file called an XML Schema or a DTD (Document Type
Definition). These serve as style sheets similar to the CSS (Cascading
Style Sheets) sometimes used in HTML. Do we have to make these up ourselves?
Thankfully, no. There are existing downloadable definition files designed
for different applications. Also, there is XML-editing software available
to keep us from making any mistakes.
There are two forms
of XML, both of which sound equally forbidding: "Well-formed" and "Valid."
The two follow the rules of XML to varying degrees of severity, mostly
having to do with what kind of style sheets required.
Now here was the
missing part of the puzzle for me. Suppose you go ahead and mark up a document
with XML tags. How do you get that page off your server and out on the
Web to your patrons? Tennant revealed the secret: There are programs, called
XML Stylesheet Language Transformations (XSLT), that use templates to transform
XML into HTML or something else entirely. XSLT templates allow alternative
displays of the same material and can even be used for on-the-fly responses
to patron queries.
Well that explains
a lot. So it turns out that, in addition to an XML document, you need its
accompanying DTD, which defines the tags you used in the document. Then
you need an XSLT to translate the whole thing into a Web page with an accompanying
CSS for sending to the end-user. Simple. Three steps: Information; Transformation;
and Presentation.
Now, why are we
coding everything into XML again? Because it is a great way to store information
that we want to use over a long period of time through different platforms
and over new services. It makes migration easy, because XML separates structure
from rendering. It defines fields and so enhances searchability of documents.
Because we can invent new fields, as we need them, XML is very extensible.
In short, XML is trying to become the standard for encoding digital documents.
"What MARC was
for libraries in the last half of the 20th century, XML will be in the
21st!" exclaimed Tennant. "It has huge potential!"
Okay, Roy, I buy
it. But what can we do now to begin preparing for a migration to XML? First,
suggests Tennant, we can learn about and begin applying cascading style
sheets to our library Web pages. This gets us used to keeping content separate
from presentation by defining display in a separate file.
We can write our
library pages in XHTML [http://www.w3.org/TR/xhtml1/].
Say what? This is a form of HTML compliant with the rules of XML but readable
by all Web browsers. And, we can begin to code documents that we want to
keep for a long time into XML.
How can we learn
more? Why, just join Roy Tennant's listserv, XML4Lib [http://sunsite.berkeley.edu/XML4Lib/].
Its archives are eminently searchable — probably coded in XML!
It's Usability, Stupid
The '80s were
the years of great advances in computer hardware. The '90s saw the explosion
of software and the birth of the World Wide Web. Early in the new millennium,
we anticipate a "third wave" of improvement in the Information Age. What
is the byword of this "third wave"? Usability!
So says Eric Schaffer,
CEO of Human Factors International [http://www.humanfactors.com/home/default.asp]
and keynote speaker on Wednesday, November 7. The purpose of library Web
pages is to convey information, so if our pages are not usable, they fail.
And designing them to be usable is difficult. Even the argot of computers
(e.g., "download") makes it obvious that computer applications are not
designed to be "human-centered."
To illustrate the
difficulty of giving usable instructions to unseen users, Schaffer asked
a librarian volunteer from the audience to guide him in putting on his
suit jacket — without looking at him. "First, put the jacket behind you,"
the librarian instructed. Schaffer obediently dropped the jacket behind
his back. It fell to the floor.
"Put your arm through
the hole that you may find there," she commanded, "and swing it around."
He picked up the jacket, put his hand in the front pocket then swung the
jacket like a lasso above his head.
At this point,
the demonstration broke down in general laughter. What could this librarian
have done to make her instructions more useful? Schaffer suggested that
she could have used an analogy, e.g., she could have asked him to put on
his jacket the same way he put on his shirt that morning.
As Schaffer emphasized,
"Nobody does it right the first time." That is why usability testing is
so important. Web design is an iterative process. We must observe our users
as they try to use our Web pages. We can see what is easy and hard for
them. We can then redesign according to the results. We can also draw on
usability research literature in our designs.
An important concept
in usability, according to Schaffer, is "affordance," i.e., making it obvious
what to do. For example, a chair possesses great affordance. Its shape
just says, "Sit on me." It doesn't need a sign with instructions for us
to know what to do with it.
So it should be
with Web pages. Clickable things need to look like buttons, with boundaries
and shadows. Pictures should look like pictures, not buttons.
There are many
rules of thumb that have been researched and developed for our Web usability
guidance. These rules are called "heuristics." Schaffer offered some that
he thought would be most relevant to us librarians. He noted that menus,
for instance, is the best bet for site navigation. Research shows that
Web sites can list up to 18 to 24 items on a menu for effective use if
the clusters carry no more than 10 items.
To facilitate usability,
it is important to maintain the same look and structure throughout a Web
site. The science of mental maps applies to Web sites. Here, Schaffer displayed
a real map of New York City. He asked the audience to locate a certain
intersection. Because the city is laid out in a grid, we found the intersection
very quickly. Then he displayed a map of Boston, which is laid out in a
hodgepodge with random street names. Finding an intersection on this map
took considerably longer. Schaffer suggested that our sites should be laid
out as clearly as the street grid of Manhattan. "If you have a good site
structure," he said, "the user does not have to use the back button."
What we want to
avoid in Web site design, according to Schaffer, is "cognitive friction,"
little navigation problems that add up to big site headaches. Some tips?
First of all, put your most important information on the left, for that
is where people tend to look first. If you offer lists, put horizontal
lines across them every five listings or so, so that users' eyes can track
across easily. Use mixed-case type: Using all caps reduces readability.
Don't use too many fonts in one document. The result of that mistake is
"font salad."
Color is important.
Colors focus in different parts of the eye. This effect is known as "chromatic
aberration." Yellow focuses properly on the retina. Red focuses "long,"
i.e., behind the retina, and so can appear fuzzy. Blue focuses "short,"
which also causes fuzziness. The worst color mistake we can make is a page
that puts blue type on a red field, or vice versa.
Another idea from
Schaffer: Don't use institutional jargon on your Web page. Users will feel
confused by three or more nouns in a row, e.g., "Interlibrary Loan Requests,"
"Literature Resource Center," or "WebPAC Interface Use Instructions." Remember:
The short-term memory of the human animal is limited to seven items, plus
or minus two. The patience of the average human is equally short, so Web
pages should not be longer than three to five scroll-downs. Place buttons
above
images, so users don't have to scroll down to find them.
Another sign of
a usable page, according to Schaffer, is that it allows users to easily
correct their errors. It tells them what they entered, why it was wrong,
and what to do about it, all without using alarming phrases such as "illegal
command" or "action aborted due to fatal error."
How can we test
to see if our interface is usable? Try the "cookie test." Make paper copies
of the interface you want to test, then ask different people to circle
what they think they can click on. After they have finished, give them
a cookie for their trouble.
Do you remember
those drawings that ask children to find the pictures hidden within them?
It turns out that once we finally see the hidden picture, it becomes impossible
for us not to see it. That is why it is important to ask different
people every time you test your page.
Finally, Schaffer
concluded, when designing the library Web pages, picture a rat trying to
cross an electrical grid to get to a morsel of cheese. If the grid only
shocks mildly, the rat will endure it to get its prize. But if the shock
is too painful, the rat will quit rather than endure the pain. The grid
in this case is the ease of navigation on a site and the length of download
delays. We want our library Web sites to be on the right side of the grid/cheese
continuum.
"Remember," warned
Schaffer, "If your users can't find your information, it effectively does
not exist."
User Testing Made Easy
Anne Platoff of
the Arizona State University Libraries backed up Schaffer's presentation
with some interesting user test tips.
In designing user
tests, Platoff suggests that we first ask ourselves precisely what it is
we are trying to learn. Are we simply testing one page? One function? It
is wise to test just single pages or pieces at a time. Be sure to test
a variety of users: staff and librarians as well as patrons.
Platoff advises
using three testers at each station: one to read instructions, one to record
the subject's actions, and a third to write down what the subject says.
"First," she says,
"collect some brief demographic data and ask questions such as, 'How often
do you use our site?'" Then watch and record the ways in which users interact
with the site to identify bottlenecks that hinder usability. Don't forget
to ask how subjects feel about the site.
How many people
should one test? Platoff quoted research that shows that the first five
subjects tested will find about 70 percent of the problems on a Web page.
Eight subjects with spot 85 percent of problems. Because we really need
so few test subjects, we can use "Hallway Methodology"; that is, we can
grab random folks and ask them to give us 5 or 10 minutes of their time.
They usually will.
There are four
main types of testing that we need to do on our Web pages. The first and
most painful type of test is the "baseline" test. This is where we find
out exactly what is wrong with our old designs. A second test is called
"preference testing." In preference testing, we ask users which button
or link text or design makes the most sense. The third type is the "prototype
test." This is where we try our new designs to see if they work. The final
test type is "benchmark testing." Use this when you are considering adopting
design elements from other people's pages. Test before you steal.
Testing will make
the design process easier because it guides decisions with solid information.
It also helps other members of the library community "buy in" to a new
design.
When we test, we
should ask our subjects to "think aloud." Remember to reassure subjects
that we are testing the design of the Web site — not them. So if they can't
find what they seek, they are not stupid; it is the site that needs work.
How can we tell
if we have achieved site design success? This point is reached when test
subjects stop knocking their own intelligence and start asking questions.
A site works when users stop focusing on the search task itself and instead
think about what they want to find.
Search Engine Survivor
"What was the
biggest challenge to search engines over the last year?" demanded Danny
Sullivan, editor of Search Engine Watch [http://www.searchenginewatch.com].
"How many think it was synonym support?"
Many in the audience
of librarians raised their hands. That sounded like a hard task for search
engines to master.
"How about parsing
the relationships between words?" Other hands went up. "Non-text issues?"
Another tough one. More hands popped up.
"All those answers
are wrong!" Sullivan exclaimed. "The biggest challenge for search
engines last year? Staying alive!" Sullivan ticked off the names of the
portals that got "kicked off the island" in 2001: Infoseek, NBCi,
and also Excite and Alta Vista, whose days are numbered,
according to Sullivan.
The economics of
search engines are boring but important, Sullivan asserts. Economics used
to be supported by banner ads. But in the last year, that "cash cow" ran
dry. Now, search engines get income through "paid participation," which
is a mixed blessing. Paid placement is bad in the sense that it gives preference
to those who can pay more to have their site listings thrust forward. But
it can be good in that it opens up a dialogue between site owners and search
engines. Since site owners have become paying customers, search engine
staff have more initiative to provide better service to them by maintaining
their links and describing sites accurately.
As long as search
engines label paid participators as "sponsored sites," users haven't seemed
to be too bothered by them. Of course, search engines such as Overture.com
(formerly GoTo.com) list nothing but paid links and also
distribute paid links. Some meta-search engines front-load paid links,
too. For instance, it is difficult to get beyond the ad breaks on Search.com
and Dogpile.
But even on regular
search engines, participants who pay more have a better chance to get to
the top of result lists. Is this fair? No, but it is capitalism.
On the other hand, NorthernLight.com has always charged for inclusion,
but in that case, it is not a bug, it's a feature.
Non-profits and
hobbyists still have outlets, though, through specialized indexes like
Zeal.com
and Yahoo!'s noncommercial categories.
Search Engines as Mind Readers
Danny Sullivan
spoke about the curious way that the search engines responded just after
the September11 attacks. Usually, he said, search query streams are always
the same, e.g., "Britney Spears" and "sex." But 9/11 brought up search
terms that had never been seen before. "Sex" fell out of the list of the
top 10 search terms for the first time since the Web was invented.
Sullivan discussed
how search engines handled the flood of use that resulted as the public
turned to the Web for answers on that awful day. When users visited AltaVista[http://www.altavista.com],
they found what they were looking for, that is, news of the attack. That
is because Alta Vista mixes in news with its results automatically. Although
in many ways, Alta Vista is a dying search engine (it hasn't refreshed
its Web crawl in at least 6 months), it just happened to be able to deliver
what people needed in the moment.
On the other hand,
Google[http://www.Google.com],
the excellent search engine that refreshes itself monthly, does not mix
news into its results. Consequently, it could not deal with the tragedy
on the day it happened. When the public turned to Google to get the latest
news by typing "World Trade Center" into the Google search box, their results
asked them if they would like to make reservations at the "Windows on the
World" restaurant "with its spectacular view from the 107th floor of One
World Center." Later that day, Google simply posted a message telling people
to go away — it couldn't handle their requests.
We want our search
engines to do what we mean. Patrons want search engines to understand
that they want pictures of Spain even though they never, and probably
never would, click the "image" tab. Search engines such as Teoma[http://www.teoma.com]
and WiseNut[http://www.wisenut.com]
get around this problem by clustering results by subject similarity. WiseNut
even offers a feature called "Sneak-a-peak" that will display a section
of the linked-to page. This helped me when I searched for replacement pieces
for my Oneida stainless flatware set. A search on WiseNut helped me to
find eating utensils while bypassing the esteemed Native American nation,
the Baptist community, and the town in New York State.
In conclusion,
Sullivan pointed out that 32 percent of Americans report that they use
search engines (which are less than a decade old) as their top resource
when seeking answers. (Notice that they don't use librarians.) Yet, search
engines don't cover everything. As librarians, we need to remember that
they are just one of many tools. Telephone calls and e-mails are often
better ways to find the answers we seek. We should definitely use these
alternatives when we feel ourselves developing "search rage," which can
happen after only 12 minutes of fruitless Web searching.
"And please," begged
Sullivan, "please don't use Boolean when searching the Web. Search
engines simply are not built for it." Explore your first catch, he advises,
because good sites link to other good sites. These links may well bring
you documents that you couldn't have found with synonyms.
The PowerPoint
slides of Danny Sullivan's presentation appear at Calafia Consulting[http://calafia.com/presentations/].
Other Conference Highlights
What other wonders
did I see and learn in Pasadena? Well, Sheri R. Lanza, president of Global
InfoResources, Inc., described two Web tools she couldn't live without.
[See the "Tools of the Trade: Seize the Screen and Scan the Site: Snagit
and Quickbrowse" by Sheri R. Lanza in the November/December 2001 issue
of Searcher.]
SnagIt
http://www.techsmith.com/products/snagit/default.asp
Lanza raves about
this advanced screen-capture program. Use it to suck up images, text and
video. Better still, the text captured is not an image: It remains searchable
text. This fabulous program is free to try for 30 days. To buy it forever
costs only 40 bucks.
Quickbrowse
Plus
http://www.quickbrowse.com/
At $12.95 for 3
months, Lanza says you won't find a better Web time-saver than this service.
Set it up to monitor sites you visit every day. Quickbrowse visits them
and stitches them into a single document. Try it for free!
Debbie Hunt, senior
Information Specialist at The Exploratorium, has three Web tools that she
recommends — Spyonit, BookmarkSync, and Search Adobe PDF Online.
Spyonit
http://www.spyonit.com/Home
Hunt adores the
free site monitoring service called Spyonit. Set it up to inform you about
Web page changes, newsgroup postings on specific topics or by specific
individuals, closing bell stock quotes, etc. Get your notifications via
e-mail, instant message, cell phone, or PDA.
BookmarkSync
http://www.syncit.com
"Oh, no! I have
that bookmarked on my other computer." No problem after you download
BookmarkSync for only $50. Try it for free: You get 20 free syncs.
Search Adobe
PDF Online
http://searchpdf.adobe.com/
Use this site to
shed light on that mysterious "Invisible Web," in particular, those Adobe
PDF (Portable Document Format) files otherwise invisible to most browsers
(except the newly expanded Google).
I also heard about
the perils of running a real-time chat reference service, at times called
a "Homework Center," at the King County Library System near Seattle, Washington.
Their biggest challenge lay in trying to answer math questions raised by
elementary school students. These students did not want "help," they wanted
answers, and the call center librarians weren't as adept as they used to
be at mathematics. When they cut the word "homework" out of their reference
service title, they began getting questions about library circulation.
Then, they got obscene and abusive messages. So, they put "homework" back
in the title.
Some medical librarians
from the University of California at San Francisco discussed their experiences
with pushing medical information out to their patrons' PDAs. Doctors and
residents love their Palm Pilots and other handhelds. The two biggest challenges?
First, there is no standard operating system for these things yet. Applications
designed for the Palm OS are incompatible with those for Windows CE. Also,
PDAs are still not wireless. This means that in order to receive new information,
patrons have to return to their offices and place their devices into cradles
for downloading.
For More Information
Internet
Librarian 2001 Presentations
https://www.infotoday.com/il2001/presentations/
Sorry that you
missed it yet? Or, if you were there, do you want to recall a particularly
useful presentation? Many conference participants have donated their PowerPoint
presentations to the Internet Librarian Web site. Re-live and review your
conference experience here!
See you next year
— in Palm Springs!
|
