Showing posts with label Navigation/IA. Show all posts
Showing posts with label Navigation/IA. Show all posts

Tuesday, May 13, 2008

Do Searchers Search More Over Time?

A paper from 2004 recently fell into my hands. It's from the journal Management Science, so you'll have to go there to get the paper (you'll need an account). As is usual in journal papers nowadays, it has five authors, Johnson, Moe, Fader, Bellman, and Lohse.

They did several studies, partly focused on asking whether people use search more often as they get more experienced on the Web. They also looked at how much people searched for sites when they wanted to buy something.

The results might be surprising to some - even in the age of search, users don't like to check out a lot of e-commerce stores. The majority prefer to settle on a few stores and go there rather than constantly checking out new ones. And even when they get more experienced with search, they don't use it much more. And they found that users don't search as much as you'd think.

None of it surprises me, although they didn't account for some factors, like age. Marketers have long known that past a certain age, the willingness to try new brands drops like a stone. The authors didn't break out sessions by individuals, but by households, so there's likely to be a lot of slop to the data.

The question that occurs to me is whether, if such brand loyalty online is real, it's due to actual loyalty, or reluctance to tangle with a new interface. E-commerce isn't so much like brick-and-mortar shopping as it like operating software, and few users enjoy mastering new software. Is it the label, or the comfort level?

There's also the fact that many users dislike searching unless they know a strong keyword. Look for "toilet seat" and you're likely to find an online hardware store. Search for "pens" and you'll end up with specialty stores, stationers, and collector sites, all of which have to sifted. Google is good, but it's not clairvoyant.

Friday, March 28, 2008

Old Houses and Portals

I live in an older home (1920s) in a historic neighborhood. It's not a particularly wealthy neighborhood. Most historic ones aren't. Money flees its breeding ground. But the neighborhood is comfortable and reasonably vibrant. I always wondered why I loved older homes, and finally one of my gurus, Stewart Brand, might have explained it in his book How Buildings Learn: What Happens After They're Built. He says that older buildings exude what we call "charm" or "character" because they've been altered over time to suit both changing infrastructure needs (the arrival of central heating, air conditioning, indoor plumbing, electricity) and the changing life needs of its occupants (bigger kitchens, more light, more entertainment at home). They grow, morph, and gradually conform more closely to actual human life, like an old pair of jeans. New homes are raw despite their efforts to "design for life". Brand points out that buildings can't be designed up-front for our lifestyles, because no designer can get it right the first time. That's why a home needs so much time to find its proper shape.

What's the lesson for Web designers? Alas, probably not much, despite my most earnest desires to bring the analogy across. The missing element is time. Websites don't give you time. Portals were supposed to let users modify their views quickly, compressing the decades of home conformity into minutes online. Never worked. The vast majority of visitors never knew about customization or took the time to mess with it. Personalization works to an extent, but not completely. Web users are now used to their comfortable sites changing regularly, and although they may not approve, they rarely boycott on that basis.

That said, for years I've been fascinated with the idea of a personalization engine that would track Web user behavior and subtly shift the interface to suit. I've never bothered to fully flesh out the concept, but in general it would work much like Microsoft's failed personalization functionality in Office, the one that gave you chevrons instead of full menus. It was a good idea, but possibly the wrong place to use it. Office users are almost all repeat visitors. Website visitors aren't. Amazon does a good job with personalization, but I'd extend it from "you might also like this stuff" to actually shifting controls and navigational paths. A pipe dream, certainly, but given a huge pile of cash something I'd be interested in researching.

Saturday, March 15, 2008

Reading TeaLeaf

Sorry to have been away so long. Complications of various kinds. But now I'm back, and with tea.

Have you seen TeaLeaf? It's a snazzy app that sits athwart your Web traffic, sniffing and recording every user's session. A bit disconcerting, that. But its benefits are undeniable. It stores thirty days (or more, at your discretion) of user transactions, at the user level. It aggregates them too. I've long been a proponent of continual usability checking. Our profession seems to put all its emphasis on initial design and testing, while utterly neglecting Web analytics and other red-flag functionality that can signal usability leaks. Traditional Web analytics is good, but it isn't always granular, meaning that its results are en masse, not at the level of the individual user. It's great for marketing departments, but not as good for usability concerns. TeaLeaf shows the actual user transactions - where people go, what they click, what choices they make, and whether their conversions are successful.

For example, you can lose users at any turn in the road, but especially during checkout. Many visitors drop off when money becomes an issue, and understandably so, since they had no intention of paying anyway; they're just here for the experience, or the knowledge. But others experience technical problems or usability pitfalls. TeaLeaf generates a report on who converted and who didn't, and then you can track out why the failures happened, following every user's trail.

Tuesday, November 27, 2007

Scott Adams and the Demise of Common Sense

Scott Adams, the creator of Dilbert, has announced on his blog that he'll be blogging less often. It seems that his original common sensical expectations about how the blog would turn out aren't coming out well at all.

They original expectations included:

1. Advertising dollars
2. Compiling the best posts into a book.
3. Growing the audience for Dilbert
4. Artistic satisfaction.

Of these, only number 4 has worked out. RSS has made visitors go around the ads, the book hasn’t done all that well, and the audience for Dilbert hasn’t been correlated at all with the growth of the blog. As the blog has exploded, the benefits to him haven’t. So he’s talking about blogging less often. It’s a great illustration of how common sense is a lousy predictor of future events. Viva testing and statistics.

Sunday, November 11, 2007

Why a Messy Room is a Good Thing

I saw a comic the other morning that featured a young man and a thoroughly trashed room, with items strewn all over the place. In doubtless a whiny voice, the youngster pleaded "but when I put things away, I can't find anything". Parents will smile smugly in silent rebuttal, but an HCI'er and part-time economics junkie like me can't help but wonder if those legions of room-messers don't have a point. When we humans do things frequently and in large numbers, there's usually something to it.

Advocates for clean rooms (like rabid inspecting drill sergeants) like to say that everything has its place, and that's where it should be. But is that really true? After you reach a certain threshold of object ownership, is there a single place for everything? Children mostly keep toys in a box, where toys on top obscure the ones underneath. Folded clothing suffers the same fate in a drawer, where you have to pull out the stuff on top to get to the items below.

In effect, it seems to me that a messy room is actually a form of shallow navigation where little is hidden badly enough to be overlooked. The same pertains to a cluttered desk. I often keep a wide, low pile of file folders, papers, notes, books, and pads on half my desk. A neat freak might object that I could just as easily keep all that in their respective drawers and bookcases, but I'm convinced (without much evidence, I have to add) that doing so is less efficient. I can riffle through the pile faster than I can flip through file folders in a file drawer, even in alphabetical order. The pile is for things I'm using frequently at the moment, and overcomes the problem of filing materials under the wrong headings. Our users tend to like shallow navigation, and I'm convinced that I do, too.

Wednesday, September 19, 2007

Bookmarks as IA

I once did a project for a client that involved talking with users about their browser bookmarks. The project was a redesign of an intranet that was built like a Wild West town, with a wacky combination of independent little plots stitched together only by virtue of being under the same corporate umbrella and having links on the central page of the intranet. Every department had its own navigation and design. It turned out that employees coped by using bookmarks to provide dependable paths back to the information they had so painstakingly located. Nothing new in that, of course; Web users still use that strategy. But interestingly, the names they gave to the bookmarked pages in the bookmarks were indicative of their own quirky needs. In effect, the bookmarks were individualized navigation schemes, or IAs. By studying the bookmarks, we got a pretty fair idea of users' mental models for information.

Whenever users create informational structures, it's worth studying them to discover what's core, and what's transitory. That's the problem with today's tag or link clouds: they can't distinguish between fad and eternity. Any given cloud today may have "Britney" as its biggest member, but that probably won't be the case next year. Clouds are intrinsically time-bounded. But it would be interesting to do some multivariate work like cluster analysis on several clouds over time to see what drops out and what stays.

Wednesday, August 22, 2007

Control is Everything

Scott Adams got me thinking. In his blog entry for August 17, he mentions that one of our strongest needs it to feel like we're in control. He used an old example: A genie offers you two choices. In the first choice, "You can eat at the finest restaurants in the world for free, twice a week. The only catch is that the genie picks the day, when you are not already booked, and he picks the specific restaurant." In the second choice, "You can eat at “good” restaurants, again for free, twice a week. But this time you can schedule it whenever you want, up to two places per week, and pick whatever “good” restaurant you want."

He goes on to develop the theme that the first choice probably wouldn't make many people happy, because they would eventually feel the keen sense of loss of control. The second choice, while gastronomically less appealing, is probably a better one for most of us.

It reminded me that one thing users dearly love is control, or at least the illusion of it. This is something that subconsciously irks me about lots of software and websites, I think. It's why I'm irritated with Flash so often. It just takes off and does things without asking me. The same thing annoys me about flashing ads, shifting menus, and other things that don't help me do things, but invade my locus of control. We humans don't seem to resent losing control if we don't expect it. We accept that the good guy may die at the end of the movie, but we'll shriek in fury if we can't change the channel to another movie. And we accept a loss of control when it benefits us. My car's engine does hundreds of things that I don't need to approve as they're happening. But there are some places where humans just won't accept interference. I wouldn't pay less for a car if it decided by itself when it would start. The same thing is true for software and websites, I think.

Friday, May 11, 2007

What's REALLY Screwing Up Usability

After a considerable period of experience, I have come to the conclusion that most websites suck more because of lousy navigation than from bad controls placement, poor color choices, small text sizes, or anything else related to layout. I've found that users will forgive and use almost any interface mistakes, if only they can find what they're looking for. Poor navigation has left more users looking as confused as goats on Astroturf than any other single cause.

Now, it should be noted that this general rule applies more obviously to information-storage sites, not so much to interactive sites. But even if the emphasis is on interactivity, knowing where to go next in a sequence of steps is only a variant on where to go next to find materials.

It's for this reason that I wish HCI programs put more emphasis on information architecture. Many HCI'ers, even those with grad degrees, can't do card sorts or affinity exercises, nor perform cluster analysis. They have no clue about taxonomies, ontologies, or thesauri. I'm finding that the ability to organize whole site logically is both science and fine art, and deserves more class time than it's getting.

Sunday, April 1, 2007

Portals Will Forever Suck for Usability

In the past few years I've spent a lot of time working with portal software. I was involved for half a year with the design of Sakai, which you may know as Oncourse CL. For those of you who want to flail me about its usability flaws, be assured that we refugees from the Tools Team, who were the usability voices, are not too happy about them either. I've since become even more deeply involved in Websphere Portal and its evil little sidekick LWCM, the web content management part of the team. In between, I've been a user of one or two other portal packages. Believe me, they all stink from a usability perspective.

First let's get together on terminology. A "portal" in the old sense is just a website with a bunch of collected links that send you elsewhere. Yahoo pioneered this interface. The newer sense of "portal" is actually a software package that specializes in showing various systems to a user all at once, and supposedly giving the user the ability to customize his own interface (although no one ever does). Portal pages can have different "windows" on a page. For example, one place on the page permits Google searching, another one gives the weather, another one shows your stock market portfolio, and yet another has corporate news from your employer's PR machine. These various "windows" are actually known as "portlets", "applets", "gadgets", or "tools". Oncourse CL is an example. There, it's "tools". You can write a tool. Anybody can. It's completely open, and that's what Sakai's creators are most happy about.

But that's Sakai's Achilles heel, too. Tools don't talk well with one another, because they're designed to be secure and happy living alone. Navigation and other usability factors vary from tool to tool, so you can never just settle down to one consistent interface.

Major portal makers, like IBM and its Websphere Portal, suffer similar problems, except in greater profusion. A typical Websphere portal page may have a dozen "portlets" on a single page, all doing something different, and all potentially with a different "skin". If nothing else, they don't always fit thematically together. They're like jet cockpits. Over there is the flaps indicator, while over here is the oil pressure indicator. Just a flock of barely connected different things. There's no flow to the page, few cues, and little uniformity. And it's designed to be just that way, as if the business and computer science communities conspired in smoke-filled rooms to stick it to both users and usability professionals. Portal proponents claim that users can overcome this madness by customizing their pages, but that's just crazy talk. Users won't do it. They suffer in silence instead. In a portal, there's almost no room for conventional user testing or interface design. There is no "interface" as such, merely pages with things that do stuff. This is great for developers and business types, because portal architecture makes it much, much easier to incorporate in one place functions as diverse as weather announcements, time reporting, and CRM applications.

If you want to see examples, check out the NCAA (www.ncaa.org/wps/portal) or IBM (www.ibm.com).