Current Cites for Sept. 2019 is out! You can find the issue here...
Usability studies on the effectiveness of library research guides are popping up all over the place. The one I recommended appeared in the latest issue of Information Technology and Libraries. Naturally in the meantime another example popped up -- this one in the latest issue of Journal of Web Librarianship. Hot topic!
MPOW: I set up shop at the computer lab in the Student Center and then hustled out to the hallway to ask students if they had time to test out a page. Some had to go to class. Others said yes (8 in total).
Results went on the writing pad and my cellphone served as a stopwatch.
Funniest moment: Someone who does webwork for another dept. said, "I wish we did testing too."
Actually I've had the 'Handbook of Usability Testing' for years -- the first edition, that is.
Well, it took them a while but Bank of America is finally saying 'bye-bye' to a particularly ineffective form of online security called 'SiteKey'. Probably better known as a 'security image', the idea was to assign you an image which you were then expected to remember every time you logged in. Yeah, good luck with that.
There actually was research on this. Not surprisingly, researchers found that "users will enter their passwords even if their site-authentication images are absent." Brad Stone summarizing the results in the New York Times put it this way, "Of 60 participants who got that far into the study and whose results could be verified, 58 entered passwords anyway. Only two chose not to log on, citing security concerns."
Of course that was 2007 or more than eight years ago. The NYT article concludes with a comment from one of the original researchers, "sometimes the appearance of security is more important than security itself.”
I'd only add that all too often, the mere mention of 'security' is expected to triumph over everything including common sense. The truth of course is that everything deserves a healthy measure of skepticism.
UX Quote of the Day*:
"The designers of the Phelps farm tractor in 1901 based their interface on a metaphor with the interface for the familiar horse: farmers used reins to control the tractor. The tractor was steered by pulling on the appropriate rein, both reins were loosened to go forward and pulled back to stop, and pulling back harder on the reins caused the tractor to back up."*
The authors go on to say:
"It’s clear in hindsight that this was a dead end, and automobiles have developed their own user interfaces without metaphors based on earlier technologies."
*Don Gentner and Jakob Nielsen. 1996. The Anti-Mac interface. Commun. ACM 39, 8 (August 1996), 70-82. http://doi.acm.org/10.1145/232014.232032
Draft BBC Mobile Accessibility Standards and Guidelines:
http://www.bbc.co.uk/blogs/internet/posts/Accessibility-Mobile-Apps
Interesting that they worked with a firm from "the States" (USA! USA!). A summary of the guidelines can be found here...
Interesting points include:
h/t .net magazine
We've been here before -- from a usability study looking at how students use (or don't use as the case may be) various library database pages:
"In 2006, Steve Krug said internet users were mostly looking for something clickable to click on; BGSU students, by contrast, often looked for a search box to search in. When a search was unsuccessful, instead of retooling it, the student looked for a different search box and tried the same search again. The students in the study tried to change the subset of information they were searching, not the search they had already decided was the best one."
Okay, so the next logical question might be, is this a student preference or is there something about the design of the website that drives them to it? Maybe yes, maybe no but considering the effort we put into all of this, it's certainly worth testing.
But hark! A bit further down in the same study -- apparently vendor consolidation will save the day:
"Therefore, if we want students to use a wider range of our resources, it is crucial that we teach them to recognize the resources that will be useful for them. As the brand diversity of our resources narrows, vendors and publishers merge, and vendors market more and more to end users, this strategy may become easier to adopt."
MetaFilter was the original community blog. It's where everyone went to discuss everything from web design to politics. Last week it celebrated its 12th Anniversary.
The site was originally put together by Matt Haughey and frequented by techies. There was a lot of discussion in the early days about web design and development. Adherents of Jacob Nielsen and web designers would trade barbs particularly over the use of Flash (hence the 'Flash Wars'). This was a dispute not settled until the arrival of more reasonable adherents of usability like Jared Spool who knew how to speak to designers and thus had a far more positive impact.
Later on as membership grew, topics of more general interest such as news and politics became more prominent. MetaFilter was where we went to discuss the fall-out from the Bush-Gore election results in 2000 as well as the aftermath following 9/11.
Anyway, the local alternative weekly where Matt Haughey lives in Portland has run an interesting article on him called, "The Blogfather". Also, MetaFilter has its own page of user-submitted reminiscenes called, "MetaFilter Memories".
We've come a long way from the days of 'you must learn our system in order to use it'. From the Usability Guidelines at Yale University Library:
Factor:
- Simplicity. Scale back features and dramatically simplify the experience for initial use. This should reduce unnecessary distractions, excess information, from initial screens. An initial search screen should not include advanced features, such as search by publisher or call number.
Examples:
- Avoid wordiness -- only show most necessary text, be concise.
- Initial page should include only the most important and common tasks for this service with unobtrusive links to other advanced functionality.
I've wanted to link to this for quite a while now. It's a PowerPoint presentation by Khoi Vinh called "Grids Are Good". Khoi Vihn is the lead designer at the New York Times and he gave this presentation along with Mark Boulton at SWSW.
The importance of the topic, namely that grids are essential to how we lay out information can hardly be overemphasized.
Look at the image below from Vihn's presentation. Note how easily the page fits into a grid.
Next, look at the home page of Cornell Library. (It's what got me started on this.) Note how the boxes in the center columns don't line up.
On Cornell's page, this isn't a big deal but it's easy enough to find examples that are far worse.
Whatever the degree, it's clear they hadn't seen Vihn's presentation. If they had, they would have known that visual order is an aide to cognition and that it conveys meaning. The less of it we have, the less clear our design.
You can download the presentation here... A podcast from SWSW is available here...
gapingvoid posts an interesting list called the "End-User Manifesto". It's billed as "things that need to be in the mind of anyone building software, particularly for the Web." Here are the first four items:
1. Don't waste my time.
2. Help me do the right thing.
3. Respect my decisions.
4. Design well, and guide me to make the right decisions by that design.
They're all really quite good. To see the rest go here... (h/t User Centered)
When I read posts like this, I really have to ask myself what is the measure of success for incorporating new technology: the fact that it's been incorporated at all (nice) or that it's actually being used (even better).
"[S]ocial software, Weblogs, linklogs, folksonomies, wikis, podcasts, RSS feeds, and Web services" are definitely advances in the Web as we know it. I routinely use many if not all of these myself. But their simple inclusion (whether real or imaginary) into a library's website doesn't by itself constitute a "success".
It's important when trying to incorporate the tools of Web 2.0 that we don't forget the lessons of Web 1.0: you don't shove technology down the throats of your users simply because you've become enamored by it. Rather it's your users who define what your priorities are and whatever they want, you'd better be in a position to deliver on -- big time! That's the measure of success that counts.
Everything else is bupkis.
UPDATE: Apparently this has been on the minds of a couple of people. Have a look at Sarah Clark's "Dark Side of Library 2.0"
Whatever that is -- and in the academic world, I'm assuming it's articles and books -- that's what we have to build our websites around. Indeed, the whole success of the operation depends on how well we deliver on these core functions.
Anything less and we've got a problem on our hands.
That's why I've got to wonder about all the talk of transforming our websites into social networks. Is this what our users, particularly in the academic world, are really coming to us for?
Are the ones coming to us for articles and books going to be satisfied if we throw a wiki at them?
Are they coming to participate in a "conversation" -- or do they just want to grab something quick and get the hell out?
We want to open up our data to the widest possible audience. We want to establish a presence, where appropriate, in every social network and widget that we can.
But simply because we want to use social networks and various other technologies to extend our footprint, doesn't mean that they're the only models to follow. In some cases, they may not even be the most appropriate.
-------------
Cultural Note to Extraterrestrials: Barnum & Bailey were famous for the adage, 'Always give them what they want'.
"It just works", repeats author David Platt almost as a mantra in this Podcast from IT Conversations. That's what software is supposed to do.
Users aren't interested in what goes on behind the scenes. All they want to do is accomplish their goals with the least amount of hassle.
An obstacle to this is software that's afraid to make assumptions -- even when doing so saves time (i.e. is valid) for the vast majority of users.
"Don't let edge cases complicate the mainstream", Platt pleads.
While the Podcast could use some editing (it goes on for over an hour) and while Platt's apparent familiarity with Microsoft products seems to narrow his perspective at times, still the thing is worth listening to.
Hoo Baby! I caught a live one! No less than 10 characters long that you have to input perfectly in order to create an account at Myspace.com!
Fear of the spambot creating too many accounts? Is that the problem? Not that I'm complaining -- this one's worth it. Hello, 'mhhh5h7D7J', nice to meet you! (Though naturally I blew it on the first try.)
Emre Sokullu writes about the "big barrier" of logging in to a site and what companies do to make things easier:
"Almost all the internet giants, like Yahoo, Google and MSN, use single sign-on across their properties to lower the threshold of accessing their services and to create a competitive advantage. The reason they do this is that signing up is actually a big barrier to entry for users of web apps. Users feel more comfortable when they don't have to sign up to use an app - it's much easier to give it a try and it's less time-consuming to start using it."
Great Interfaces Look Alike:
"Big Barrier" is right. Most sites keep records of people signing in. All you have to do is go through these records to get an idea of the difficulties people have remembering their personal information even with relatively "standard" login requirements.
So what's 'standard'? Well, glad you asked. It's whatever everybody else is doing: email address or user name plus password.
The further you veer from 'standard', the more likely your user will have absolutely no idea how to access your site.
In libraryland this is something of a challenge since most of our systems work by a person's "library number". It's hard to emphasize how user-unfriendly this is -- how unlike any other authentication system the user is likely to encounter. The problem is only compounded by the fact that we're generally running multiple systems which in turn require multiple logins. No "single sign-on" here.
That's why the login on the Queens Borough Public Library Site is so fantastic: all you need is your username and password. Just like any site!
When developing systems, we need to work off of our users' strengths, building around things they're familiar with. Anything less should be a red flag.
I find usability reports fascinating. I went through the ALA's "Usability Assessement Report" and my favorite part was "Appendix F – Usability Testing Notes".
But the entire report is worth a read. The people who put it together did a good job. I mean, who can argue with a recommendation like this:
Organize information according to content. Except for the information specifically about ALA or the divisions, do not categorize the information — especially information of interest to the general public — according to ALA’s organizational structure....
What quibbles I have are minor. That said...
The report recommends that URLs should be "meaningful and reasonably short" (p.13). While I'm all for "reasonably short", I think trying to make them "meaningful" as well is hoping for too much.
Sure there are obvious examples of meaningful URLs that have become almost standard: '../about' for 'About Us' and '../contact' for 'Contact Us'. On a site like ALA.org, you might also expect '../divisions', '../publications', etc. But you can only take this so far.
Even the example they use in the report, "Prods_Pubs" for "Products_and_Publications", doesn't seem particularly intuitive or meaningful to me. I think for most of the pages, just being "short" as in 'ala.org?p=123456' is about as much as we can hope for.
The report argues against using division acronyms like 'ACRL' or 'PLA' as part of the navigation. I don't see why not.
As someone who's paid annual fees for a couple of these Divisions down through the years, the acronym is just about the only thing (other than the location of the annual convention) that I know about ALA. If new people are having trouble deciphering these acronyms, maybe it's an indication that the landing page for the Division Section isn't all that findable.
One way or another, I'm not sure a navigation scheme based on their full names would be any better. It certainly would be a whole lot more crowded.
Okay, I said these things were minor. But only in a few places is there even an intimation that the visuals suck.
About the closest you get is in this user comment:
"The website design ... is extremely unprofessional in appearance. It's like it was designed back in the 1990s before librarians were so internet-savvy, and no one has bothered to update it since then." (p.10)
The color scheme is unattractive. Graphics aren't used in a particularly optimal way to enhance text and navigation. And of course the thing looks like it came out of the 1990s: There's absolutely no use of layout or typography beyond the most basic "three column display"; Everything is just one "river" (or "flood") of content; And the content itself is nothing more than '<h1><p><p><p>', rinse and repeat.
They're going to have to get a whole lot more sophisticated than that to break out of the 90's look.
I'm confident they will. There's no reason why a site that represents the ALA can't be a bit more user-friendly -- and appealing to the eye. (h/t Shifted Librarian)
In this podcast by Gerry Gaffney, Cooper talks about personas, interaction design and other aspects of User Centered Design (UCD).
Interesting quotes include:
"Personas are not something we make, they're something we discover."
Appropriate focus:
"Even though you have a broad constituency of users, you should have a narrow selection of goals. By definition, a product serves a narrow spectrum of goals, even if it serves a broad spectrum of demographic."
Difference between 'marketing segmentation' and interaction design:
What Interaction Design does is, we go directly to that motivation -- not why someone would to buy but why someone would be satisfied using. That's a deeper thing.
Listen to the whole thing here... (h/t infoDesign!)
It's a book called 'Getting Real', written by Chicago-based web development firm 37signals. It applies a provocative 'take-no-prisoners' approach to software development: Cut out the fat, narrow your focus, keep it as simple as possible.
The entire book is available online. It's pretty brief and worth a read. One of my favorite lines: "More isn't the answer. Sometimes the biggest favor you can do for customers is to leave something out."
It had to happen.
First there was the period of experimentation on the Web. Websites were meant to be "explored" we were told -- even the more mundane ones. When that didn't seem to work out, the pendulum swung the other way in favor of clean and simple design. The search screen of Google comes to mind.
Now the question is, are we experiencing a backlash to the backlash?
First, there's the article by noted design theorist Don Norman entitled, 'Simplicity Is Highly Overrated', which concludes:
Yes, we want simplicity, but we don’t want to give up any of those cool features. Simplicity is highly overrated.
Next we have Joel on Software arguing that simplicity "will not work as a good long term strategy". I'm reminded of the librarian discussing his new website who said users only understood the search box on every page when there were three search boxes to choose from.
Don Norman asks us rhetorically,
"Haven’t you ever compared two products side by side, comparing the features of each, preferring the one that did more? Why shame on you, you are behaving, well, behaving like a normal person.
I admit it. I'm looking for a phone at the moment that does everything but light up the driveway when I get home. I love features as much as the next guy.
But it's important to realize a simple fact: people want the features but they don't want the complexity. Furthermore, they'll prove extremely reluctant to try out a site, if in order to accomplish their goals they've got to master every feature on the thing. If this weren't the case, 'Advance Search' would be the first stop of even our most neophyte users.
