From jspool@uie.com Mon Jul 13 18:36:16 1998 Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0) id SAA18771; Mon, 13 Jul 1998 18:09:33 -0400 (EDT) Received: from jasmine (world.std.com) by world.std.com (TheWorld/Spike-2.0) id AA18433; Mon, 13 Jul 1998 18:09:30 -0400 Message-Id: <199807132209.AA18433@world.std.com> Comments: Authenticated sender is From: "Jared M. Spool" Organization: User Interface Engineering To: Gary PERLMAN Date: Mon, 13 Jul 1998 18:04:45 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: Re: Reply-To: jspool@uie.com Priority: normal X-Mailer: Pegasus Mail for Win32 (v2.54) Status: RO Back Issue #1 (Each Issue Sent Separately!) From: "Jared M. Spool" Organization: User Interface Engineering To: UIETips@uie.com Date: Mon, 17 Feb 1997 10:24:21 -0500 Subject: Web Usability -- UIETips 2/14/97 Posted by "Jared M. Spool" : UIETips 2/14/97 _______________ Table Of Contents * Introduction * From The Editor * Overview: Recent UIE Web Research * On The Road * Evaluate Your Website * Visit Our Website * UIETips Subscription Information _______________ Introduction UIETips describes the latest research and other information that developers need to design today's products. UIETips is produced by User Interface Engineering, a product usability consulting firm based in North Andover, MA. Information on subscribing to UIETips can be found at the end of this message. _______________ >From The Editor UIETips is back from its long hiatus. A lot has happened: UI '96 has come and gone, we've held many classes, worked on dozens of projects, and learned many new, cool things. We're committed to using UIETips to deliver the latest information about product design. As always, we'll focus on actual data, not theories -- allowing you to have information that you can use. We'll start this (re)inaugural issue with our hottest, new research: our Web Information Retrieval study. This study is an in-depth analysis on what actually matters when it comes to designing websites. So far, the research has yielded so much data that we'll spread it across several issues of UIETips. Future issues will also include other research we're doing, trip reports from the WinHelp Conference, the Web Developer's Conference, CHI '97, and Software Development '97. Send us questions you have about product design and usability issues. We'll do our best to share with you how we handle those issues with our consulting clients. As always, feel free to pop me a message with comments or suggestions. I'm always interested in making improvements. Jared M. Spool Editor, UIETips Founding Principal, User Interface Engineering _______________ Overview: UIE Web Research We are in the process of conducting a lengthy study on the usability of websites, focusing on the area of information retrieval. So far, we've studied 9 sites, including C|net, Disney, Fidelity, HP, and the Olympics sites. We chose popular sites which used different techniques for locating and displaying information. This way we could see if certain techniques proved to be more usable than others. We've taken data from dozens of hours of user observations, compared them to a detailed analysis of the composition of each site, and looked for any correlations that would tell us what makes one site more usable than another. Here's an overview of what we've found so far: [Note: We've listed the websites at the end of this article.] C|net, an award winning site, often cited by many as a model web site, came second to last in our study. (Disney was last, HP & Olympics were first & second). There are many reasons as to why this is, but the key ones were that the home pages offered very little direction on content. Edmunds came in third. What's interesting is that Edmunds has virtually no graphics -- it's all text. It beat C|net, Disney, Fidelity, Inc and Travelocity -- all very graphic intensive sites. One of the measures we did of the site was how "readable" it was. We took the text and ran it through readability measures, such as Gunning-Fog & Flesch. We found a surprising result: the less readable the page, the more likely people would succeed at finding the information they needed. The more they would say it was authoritative, clear, not over-detailed and not over-complicated. Another measure was the amount of whitespace. We found a similar result: the more whitespace, the less success people would have with finding the information they needed. The more they would state that the site was hard to navigate, hard to find information, over-detailed and complex. These results are contrary to popular wisdom which says that a well-crafted, pretty site will be easier to work with than a site that just has text and a list of links. But that's not what we found in our research -- we found just the opposite. Edmunds is a shovelware site -- it looks like the authors have just shovelled material from their books into it without any consideration of the design of the layout. The home page had the most information of any we tested, the links were amongst the longest and it least amount of graphics. Yet, it beat out the more graphical sites. Why is this? Our theory is that people don't read. Instead they are skimming. Readability and whitespace doesn't contribute to skimming. Readability tools measure sentence structure and grammar (that damn passive voice thing again). Nicely formed sentences hide the key information that users need to navigate through the sites. Whitespace tends to indicate smaller links, which tend to have less content associated with them. We noticed that users would have more trouble with links that were short than with links that were long. Longer links seem to more clearly set the user's expectations on the result of the jump better. Of course, this study (like all good experiments) has created more questions than it has answered. How does a link set a clear expectation? Is it possible to do this with shorter links? What do users do when their expectations aren't met? The next phases of our study will focus on these details. In future issues of UIETips, we'll talk about some of the other findings we've come up with. Here's a little sampler: Download time is not the issue everyone thinks it is. We didn't seem any correlation between download time and user frustration or their inability to maneuver through the site quickly. However we did see serious download problems with small GIF files. Graphic design had very little effect, positive or negative on overall site usability. Every variable we looked at played a minor role. Maybe graphic design isn't worth all the effort we've been putting into it? Navigation that wasn't tightly linked to the content was less usable that tightly linked navigation. This implies that you can forget about designing your site's navigation separate of the content that going to be inside of it. The best site (HP) scored only 159 out of 343. While it was almost three times better than the worst site (Disney, score 63), it still wasn't even half of the best possible score. Our take: we have a long way to go to get to an optimum design for usability. We'll tackle these issues in future UIETips. Websites discussed: C|Net http://www.cnet.com Disney http://www.disney.com Edmunds http://www.edmunds.com Hewlett Packard http://www.hp.com Inc. Magazine http://www.inc.com Travelocity http://www.travelocity.com [Editor's note: A detailed article on the readability and whitespace issues is scheduled to appear in the January/February issue of Eye For Design.] _______________ On The Road User Interface Engineering's consulting team spends a lot of time traveling. Sometimes, you can catch us while we're in your neighborhood. If we have the time, we'd love to stop by and see what you're doing or possibly even give a short presentation about some of our latest research. Here's a brief summary of some of our upcoming travel: Jared Spool: + February 24-28: In San Francisco, CA for the Web Developer's Conference. (If you're there, you can catch his presentation on Website Usability on 2/25.) + March: Ottawa, Canada & Atlanta, GA (CHI '97) + April: San Francisco, CA (Software Development '97) Carolyn Snyder: + February 27: New York, NY + March: Plano, TX & Atlanta, GA (CHI '97) Tara Scanlon + March: Atlanta, GA (CHI '97) Plus, remember that when we're not traveling, you can find us hovering around our home base of North Andover, MA. _______________ Evaluate Your Website An Innovative Way to Measure Your Site's Effectiveness! Find out how your site compares to Disney, C|net, Fidelity, HP, and Microsoft. BENEFITS TO YOU o Identify your site's strengths and weaknesses o Learn where real users succeed with your site o Provides provocative insights on the problems real users have with your site o Find out how your site compares to others o Learn from the mistakes and successes of others o Prioritize your web design efforts o Independent, objective analysis by a prominent usability consulting firm We are offering this comparison at a introductory price of $2,975.00. This is a savings of over $4,100.00. If you are interested, contact us immediately at uie@uie.com or call us at (508) 975-4343. _______________ Visit Our Website User Interface Engineering is no longer among the home-page-less!! Check us out at http://www.uie.com and let us know what you think. Includes articles from past issues of Eye For Design, information about upcoming courses, and the latest on usable products and websites. _______________ UIETips Subscription Information To remove your self from the list: Send the word UNSUBSCRIBE in the body of a message to UIETips-Request@uie.com. To add yourself to the list: Send the word SUBSCRIBE in the body of the message to UIETips-Request@uie.com. Questions? Send mail to Tips@uie.com. (c) Copyright 1997, User Interface Engineering Brought to you by: User Interface Engineering (508) 975-4343 (uie@uie.com) -- End -- ========================================================== Jared M. Spool User Interface Engineering mailto:jspool@uie.com 800 Turnpike Street, Suite 101 (978) 975-4343 North Andover, MA 01845 fax: (978) 975-5353 USA http://www.uie.com If you send me your postal address, you'll get the next issue of our newsletter, Eye For Design. ========================================================== From jspool@uie.com Mon Jul 13 18:36:17 1998 Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0) id SAA18788; Mon, 13 Jul 1998 18:09:46 -0400 (EDT) Received: from jasmine (world.std.com) by world.std.com (TheWorld/Spike-2.0) id AA18569; Mon, 13 Jul 1998 18:09:43 -0400 Message-Id: <199807132209.AA18569@world.std.com> Comments: Authenticated sender is From: "Jared M. Spool" Organization: User Interface Engineering To: Gary PERLMAN Date: Mon, 13 Jul 1998 18:04:46 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: Re: Reply-To: jspool@uie.com Priority: normal X-Mailer: Pegasus Mail for Win32 (v2.54) Status: O Back Issue #4 (Each Issue Sent Separately!) From: "Jared M. Spool" Organization: User Interface Engineering To: UIETips@uie.com Date: Tue, 20 May 1997 17:45:07 -0500 Subject: Eliminating Greying Out -- UIETips 5/20/97 Posted by "Jared M. Spool" : UIETips 5/20/97 _______________ Table Of Contents * Introduction * From The Editor: Tidbits * Eliminating Greying Out * Questions During Testing * Upcoming Course * Clearance Sale: User Interface '96 Notes * UIETips Subscription Information _______________ Introduction UIETips describes the latest research and other information that developers need to design today's products. UIETips is produced by User Interface Engineering, a product usability consulting firm based in North Andover, MA. Information on subscribing to UIETips can be found at the end of this message. Visit our website at http://www.uie.com. _______________ From The Editor: Tidbits Jared M. Spool For the last three issues, we've done nothing but talk about web usability. I thought we'd take a little break from that to talk about something that has nothing to do with the web: what to do instead of greying things out and what to ask users while testing. Before we do that, there are a couple of tidbits I thought you'd be interested in. The reason we've been knee deep in web stuff is because we're almost done with our report. (I've got a final draft right here and I'm supposed to be reviewing it instead of writing this note.) I'm very happy with how it is turning out. We've learned a lot of neat stuff and tried to document as much of it as we could. In the next couple of weeks, we'll be sending out information on how you can get your copy. While we were working on our study, I had the opportunity to be interviewed twice, by John Markoff of the N. Y. Times and Computerworld: New York Times: A Microsoft Test-Firing in Browser Wars by John Markoff http://www.nytimes.com/library/cyber/week/031097microsoft.html Computerworld: Clear Vision by Gary Anthes http://www.computerworld.com/search/AT-html/9705/970519SL0519ga.html The Computerworld article describes the competition in our Product Usability: Survival Techniques course. Several of our clients have made this course part of their regular training curriculum for their development teams. This course also was the highest ranked tutorial at the annual CHI conference this year -- out of 32 tutorials! Finally, in the next few weeks we'll have the dates for User Interface '97 and a preliminary program lined up. I can't tell you anything about it yet, except that its going to be pretty darn cool. _______________ Eliminating Greying Out Greyed Out Buttons and Menu Items. They were a gift with graphical user interfaces. As designers, we can easily show what is available and what isn't. The only problem is: user's hate them. User's hate them because they never know what to do to "ungrey" them. There are no clues for them. It's never quite clear what needs to be selected. In some recent testing, we found that users often tried to click on buttons before they selected the objects those buttons were supposed to help with. We found that by changing the greyed out button to an error message, our users succeeded more often. But in most cases, we could go a step further. We could eliminate the error message by replacing it with a dialog box. Here's an example: Suppose you have a collection of data elements and a Print Description button. Normally, the button would be greyed out until one or more elements were selected. In our first change, we never greyed out the button. Instead, upon pressing the button with nothing selected, the user would get a message explaining that they need to select something first. However, in our second change, we displayed a list box filled with the relevant data elements and a prompt to choose the ones they wanted to print. This way, whether the select the elements first or not, the function still works. We've found this strategy to work frequently. (It ends the old object-action vs. action-object debate.) Users tell us the software seems more intuitive. _______________ Questions During Testing Lisa Wylie from Knight-Ridder Information recently inquired on the UTEST list about which questions to ask during usability testing. The short answer is anything that will help you design the product better. Of course, the main point of a usability test is to observe users working with the product. And we often put more weight on what they do versus what they say. For instance, we've had users tell us that they didn't like the icons but, as they worked with the product, we saw that they knew exactly how to use each one. Conversely, we've had users tell us the think the icons look great, but, during use, we saw that they didn't know what they did or when to use them. There are things you can only get through asking questions. For instance, we've found that questions are the only real way to understand the user's mental model of an application. We had a test where users (electrical engineers) wouldn't press any button labeled Apply. It wasn't until we asked that we found out that they thought Apply meant Apply Voltage. Usually, we're not worried about potentially "biasing" the user's opinions with our questions. We do try to avoid changing their behavior by prematurely giving them hints. We typically don't ask them to explain their rationale until after they've had some chance to work with the product. One type of question, we call them "design questions", seem to always produce poor results. These are questions like: "How would you order the menu options?" or "What would you like the help to say?" The users try really hard to answer these questions, often taking several minutes to come up with an answer. And the answers are usually simplistic and unimplementable. Since the users don't know the design constraints that the development team is working with, the answers can't take them into account. Instead, we like to explore the rationale behind the problem. For instance, instead of asking how to order the menu options, we might watch which pull-downs the user goes to first. If they always look in the View pull-down for a particular option which is currently under Edit, we might consider moving it. We have some tricks that we use. For instance, when we see a user consistently pass over an icon or menu option that we think would help them, we'll ask them to do a walkthrough: "I'd like to do something a little different. Starting with the first icon, can you just tell me what each one does without clicking on it?" (We don't just start with the one that will solve their current problem, because we don't want them to think we're trying to give them the answer.) Another trick involves spoon-feeding concepts: "Would it help if I told you that files are saved in .TIF format?" With this type of question, we can see if a new concept changes the user's behavior. If the answer is yes, we can then figure out how to give the user this information through the design. At the end of tests we like to ask the users some questions about the product as a whole. For commericial applications, we'll often ask them if this is something they'd buy. Every so often, we hear someone say "No, because it doesn't do anything I need." We learn a lot about the users from the ensuing conversation. At the end of a test, we also typically ask users to describe two things they liked about the product, followed by two things they disliked. The first part is often very encouraging, especially to the development team that has just spent 2 hours painfully watching someone struggle with their product. They second part often gives us insight into the user's priorities and their "latent pain" -- the stuff that sticks with them. (By the way, you can subscribe to UTEST by sending the word Subscribe in the body of a message to listproc@hubcap.clemson.edu.) _______________ Upcoming Course Product Usability For Documentation Professionals June 25-26, 1997 This course is being held at the Tewsbury Holiday Inn. The brochures for this course are going in the mail this week. You can check out the course description on our web site at http://www.uie.com or we can mail you a brochure. We can also offer our courses at your company. This is more cost effective when you are training 8 or more people. If you are interested in a course, please call us right away. _______________ Clearance Sale: User Interface '96 Notes While we were cleaning out our supply closet, we found a box of perfect-condition course notes from our User Interface '96 conference. The notes and their contents are: Interface Agents (Dr. Pattie Maes, MIT Media Lab) 44 pp. Presentation slides (mostly text), 1 article ("Intelligent Software"), reading list for software agents Contextual Design (Karen Holtzblatt & Hugh Beyer, InContext Enterprises) 120 pp. Presentation slides (text and diagrams, including tutorial exercises), articles ("Representing Work for the Purpose of Design", "Where do the Objects Come From"), references Managing the Design of the User Interface (Dr. Deborah J. Mayhew, Mayhew & Associates) 98 pp. Presentation slides (primarily text), references Cognitive Factors in Design (Tom Hewett, Drexel University) 123 pp. Book format (text and diagrams), references, reading list Usage-Centered Design and Essential Modeling (Larry Constantine & Lucy Lockwood, Constantine & Lockwood) 70 pp. Presentation slides (text and illustrations), articles ("Collaborative Usability Inspections for Software," "Measuring the Quality of User Interface Designs," "Persistent Usability: A Multiphasic User Interface Architecture for Supporting the Full Usage Life Cycle"), reading list Goal-Directed Design (Alan Cooper, Cooper Software) 38 pp. Presentation slides (text and illustrations), design exercises Designing Visual Interfaces (Kevin Mullet, Macromedia) 149 pp. Presentation slides (text, illustrations, and screen shots with accompanying notes) (Sorry, we're all out of Jakob Nielsen's notes.) Clearance Sale Price: $8.00 per book. We have a limited number of books available. First come, first serve. Credit card purchases only. You can order by Email, Fax (508-975-5353) or Phone (508-975-4343). Ask for Cheryl or Heather when calling. Order Form: (Send to notes@uie.com) (All amounts in US Currency only.) Interface Agents -- Quantity: _____ Contextual Design -- Quantity: _____ Managing the Design of the User Interface -- Quantity: _____ Cognitive Factors in Design -- Quantity: _____ Usage-Centered Design and Essential Modeling -- Quantity: _____ Goal-Directed Design -- Quantity: _____ Designing Visual Interfaces -- Quantity: _____ Total Quantity: _____ x $8.00 = Total: $__________ Sales Tax (Mass. Only): Add 5% per order: $__________ Total Order: $__________ Shipping & Handling not included. Name: ____________________ Company: ____________________ Address: ____________________ City/State/Zip/Country: ____________________ Email: ____________________ Daytime Phone: ____________________ Payment Information: ___ Mastercard ___ Visa ___ American Express ___ Discover Account #: _____________________ Expiration Date: _____________________ _______________ UIETips Subscription Information To remove yourself from the list: Send the word UNSUBSCRIBE in the body of a message to UIETips-Request@uie.com. To add yourself to the list: Send the word SUBSCRIBE in the body of the message to UIETips-Request@uie.com. Questions? Send mail to Tips@uie.com or check out our website at http://www.uie.com (c) Copyright 1997 User Interface Engineering 800 Turnpike Street, #101 North Andover, MA 01845 Phone: (508) 975-4343 fax: (508) 975-5353 http://www.uie.com mailto:uie@uie.com Brought to you by: User Interface Engineering (508) 975-4343 (uie@uie.com) -- End -- ========================================================== Jared M. Spool User Interface Engineering mailto:jspool@uie.com 800 Turnpike Street, Suite 101 (978) 975-4343 North Andover, MA 01845 fax: (978) 975-5353 USA http://www.uie.com If you send me your postal address, you'll get the next issue of our newsletter, Eye For Design. ========================================================== From jspool@uie.com Mon Jul 13 18:36:18 1998 Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0) id SAA18864; Mon, 13 Jul 1998 18:10:17 -0400 (EDT) Received: from jasmine (world.std.com) by world.std.com (TheWorld/Spike-2.0) id AA18987; Mon, 13 Jul 1998 18:10:14 -0400 Message-Id: <199807132210.AA18987@world.std.com> Comments: Authenticated sender is From: "Jared M. Spool" Organization: User Interface Engineering To: Gary PERLMAN Date: Mon, 13 Jul 1998 18:04:47 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: Re: Reply-To: jspool@uie.com Priority: normal X-Mailer: Pegasus Mail for Win32 (v2.54) Status: O Back Issue #6 (Each Issue Sent Separately!) From: "Jared M. Spool" Organization: User Interface Engineering To: UIETips@uie.com Date: Thu, 23 Oct 1997 22:25:48 -0500 Subject: On-Site Searching -- UIETips 10/23/97 Posted by "Jared M. Spool" : UIETips 10/23/97 _______________ Table Of Contents * Introduction * From The Editor: Learning From Lincoln * On-Site Searching * Resources: Web Site Usability Report, Eye For Design, www.uie.com * Upcoming Course * Conference: User Interface 97 * UIETips Subscription Information _______________ Introduction UIETips describes the latest research and other information that developers need to design today's products. UIETips is produced by User Interface Engineering, a product usability consulting firm based in North Andover, MA. Information on subscribing to UIETips can be found at the end of this message. Visit our web site at http://www.uie.com. _______________ From The Editor: Learning From Lincoln Jared M. Spool We're in the throes of completing our latest research study, code-named Lincoln. The objective of this study is to increase our understanding of how to design quality links. (Get it: links -- Lincoln? Ok, it's a stretch, but so are most of our project names.) In the study we conducted last spring (code-named Koolaid -- as in "what are the different flavors of information delivery"), we discovered that links, in particular text links, are extremely important to web page design. But we lacked an understanding of what makes links good or bad. The Koolaid project left us with the belief that a link is a keyhole through which users perceives the page beyond. They peer through this keyhole to identify what the click will get them. Therefore, effective link design has to communicate the benefit of clicking, which, in our tests, was to bring them closer to their goal of finding the target information. So we embarked on the Lincoln study to tell us what makes a good link and what makes a bad link. The Lincoln study is one of the most painful studies we've ever done -- every time users were about to click on a link, we stopped them and asked them a battery of questions about why they chose that link. Also, every time they went to a new page, we asked them another battery of questions about what they got. As a result, we now have more information about how people progress through web sites. We're still analyzing the data from the Lincoln study. Over the next few issues of UIETips, we'll look at what we found. Some highlights include what happens as users learn sites and how users' previous experience and knowledge affect site navigation. In this issue we'll start with something we didn't set out to study: how people use search engines. Let us know what you find interesting and what questions you have. We'll try to answer as many as we can in future issues. Jared _______________ On-Site Searching In a recent study, we sent users off on scavenger hunts of information on various web sites. While all of the information that they sought could be found just by using the links provided, users would often use the search functionality provided by the site. (We saw users use search on 75% of the sites in our study.) This makes sense. Theoretically, if you know the keywords, you should just be able to type them in and instantly find the page you're looking for. However, in practice, it doesn't work that well. Search engines didn't make finding information easier, they made it harder. When users found information without a search engine, they did 50% better than when they tried to use a search engine. Overall, having a search engine on a site doesn't seem to make the site more usable. Of the different sites we tested, the best search engine helped users find the target information only 50% of the time. Some were as low as 25%. We think there are four major reasons for this: 1) Users don't know how to narrow searches Few users did anything other than simple keyword searches. (Almost no one used booleans or other features of the search engines.) They would often type in very broad terms, such as "Videos" when looking for how a video about the Wild West to get a friend. This is the equivalent of walking up to a librarian and just saying "Travel" and expecting they'll instantly find the book on Hawaii that you are interested in. When users got back a result set that was too large to be practical, they often tried completely different keywords instead of adding to the set they had. They didn't seem to know any strategies that would have allowed them to take the stuff already found and narrow it down further (for instance, "regular tire rotation"). None of the sites that we tested provided any useful information on how to narrow a search. In fact, most seemed to assume that users knew how to search effectively and didn't provide any clues at all. 2) Full-text Search engines are not indexed Users didn't seem to understand what a full-text search is. The dynamics of full-text searches are different than looking something up in an index, but users didn't seem to grasp this. For instance, they were surprised when they typed in the word "Tire" on the Car Talk site (http://www.cartalk.com) to find results that contained the word "entire" or the phrase "I'm tired." Although the site did present the option to search for entire words or partial words, users didn't change the setting (the default was partial). We also saw that users didn't understand that plurals and singular words would produce different results and were surprised. Users didn't know that typing errors would produce poor results and couldn't tell that it was a typo, instead of a lack of content, that got them the "nothing found" message. (For example, one user mistyped "Videos" as "Vidoes" and got zero hits -- and then assumed that there weren't any videos on the site.) Full-text searching produces a lot of irrelevant information for users. For instance, one of the tasks we had for the Smithsonian Magazine site (http://www.smithsonianmag.com) was, "Your six-year-old son has to do a report on dinosaurs for school. You remember an excellent article in an old issue of the Smithsonian Magazine that you think would be a fine reference. Go find it." For this task, users naturally typed in the keyword "dinosaur." The first article returned was on the American steel industry -- one of the great American industrial dinosaurs. (Go try this yourself, it's great!) Indexing is a craft that takes a lot of skill. No professional indexer with any self-respect would ever put an article about the steel industry under the topic of dinosaurs. As sites get bigger, this problem will only become more of an issue. Full-text searches will get more noisy and irrelevant as more words are introduced without any sense of what makes them important to the content. Successful searching is essentially an indexing task. To help user search more effectively, this intelligence must be designed into the site. We think that professional indexers and others who have these skills will become more valuable in the years to come. 3) Multiple search areas are not clear Many of the sites provided the ability to search different types of content or different areas of the site. This capability differed from site to site. For instance, the Smithsonian Magazine site lets users search either Feature stories, Columns, or Back Issues '89-'94. Users didn't know which one to pick. Car Talk has four search areas that do not overlap. The designers have scattered the search screens in several different locations (usually with the content it searches). Users not finding information in one area didn't know that they should search other areas. Disney (http://www.disney.com) lets users narrow the areas to search only after they've done an initial search. There is no explanation to users as to how the results from the other areas will be different from the search they just conducted. 4) Search engines are short cuts As a short cut, the search engine is intended to get users quickly to their content. But like other types of short cuts, users first need to know how to get there "the long way." The short cut requires that users understand how the search engine works, how the content has been segmented and indexed, and how content has been labeled (page titles). This is a lot to ask of users and most are not up to the task. Our data shows that the site uses a search engine, there is a strong correlation to users failing to find the right information (r-squared > .7). It also shows that users will gravitate to a search engine when the links are not clear. On sites where no search option was provided, users complained, but did 50% better than the best site that had a search engine. (This is more proof that users don't necessarily know what's good for them.) And with all the times that users failed using search engines, they never seemed to associate the failure with the search engine -- it never occured to them to try a different tack. Instead, they gave up. At this point, based on this information, our recommendation is for site designers to focus on making the long way -- the links of the site -- work effectively for users. _______________ Resources: Web Site Usability Report, Eye For Design, www.uie.com In the process of doing our work, we collect a tremendous amount of information on what makes products and web sites usable. Here are three resources that we've made available: Report: Web Site Usability: A Designer's Guide It's commonly accepted that graphics, color, and white-space are among important elements of a successful web site. However, it turns out that this may not be the case after all. This report sets those ideas on their head. "Web Site Usability: A Designer's Guide" is a 155-page report based on our observations of the struggles and successes of more than 50 users as they searched for information on nine popular web sites. (To get a sample chapter and ordering information, send mailto:web@uie.com with the words "SEND CHAP-1" in the subject of the message.) Eye For Design If you like what you read on UIETips, you'll love Eye For Design, our bi-monthly newsletter containing tips and techniques for developing excellent products and web sites. You'll read about the latest research we've done on how to build usable applications. (For a complimentary issue, send your postal address to mailto:efd@uie.com.) http://www.uie.com Here, you'll find articles on many things, including how tabbed dialogs can get designers into trouble, using paper prototypes to manage risk, how to spoon-feed conceptual information using tips and hints, and a new comprehensive UI bibliography from Chauncey Wilson of WilDesign Consulting. _______________ Upcoming Courses Product Usability For Documentation Professionals November 12-13, 1997 Andover Marriott, Andover, MA This course is filling up quickly. You can check out the course description on our web site at http://www.uie.com or we can email you a brochure. (Just send the phrase SEND INFO in the subject field of mailto:Courses@uie.com.) We can also present our courses at your company. This is more cost effective if you are training eight or more people. If you are interested in a course, please call us right away at (978) 975-4343. _______________ Conference: User Interface 97 User Interface 97 will be held November 3, 4 & 5 in Cambridge, MA. We'll be accepting registrations until the end of business on October 31st. (After that, you can register at the conference.) To learn more about the program for the User Interface 97 conference, send mailto:UI97INFO@UIE.COM with the words SEND BROCHURE in the subject field. Or see the conference web site at http://www.ui97.com. If you are interested in purchasing a set of conference notes, you can send mailto:UI97NOTES@UIE.COM with the words SEND INFO in the subject field. _______________ UIETips Subscription Information To remove yourself from the list: Send the word UNSUBSCRIBE in the body of a message to UIETips-Request@uie.com. To add yourself to the list: Send the word SUBSCRIBE in the body of the message to UIETips-Request@uie.com. Questions? Send mailto:Tips@uie.com. (c) Copyright 1997 User Interface Engineering 800 Turnpike Street, #101 North Andover, MA 01845 Phone: (978) 975-4343 fax: (978) 975-5353 http://www.uie.com mailto:uie@uie.com Brought to you by: User Interface Engineering (508) 975-4343 (uie@uie.com) -- End -- ========================================================== Jared M. Spool User Interface Engineering mailto:jspool@uie.com 800 Turnpike Street, Suite 101 (978) 975-4343 North Andover, MA 01845 fax: (978) 975-5353 USA http://www.uie.com If you send me your postal address, you'll get the next issue of our newsletter, Eye For Design. ========================================================== From jspool@uie.com Mon Jul 13 18:36:21 1998 Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0) id SAA18777; Mon, 13 Jul 1998 18:09:37 -0400 (EDT) Received: from jasmine (world.std.com) by world.std.com (TheWorld/Spike-2.0) id AA18464; Mon, 13 Jul 1998 18:09:33 -0400 Message-Id: <199807132209.AA18464@world.std.com> Comments: Authenticated sender is From: "Jared M. Spool" Organization: User Interface Engineering To: Gary PERLMAN Date: Mon, 13 Jul 1998 18:04:45 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: Re: Reply-To: jspool@uie.com Priority: normal X-Mailer: Pegasus Mail for Win32 (v2.54) Status: O Back Issue #2 (Each Issue Sent Separately!) From: "Jared M. Spool" Organization: User Interface Engineering To: UIETips@uie.com Date: Tue, 4 Mar 1997 10:47:11 -0500 Subject: More Web Usability -- UIETips 3/4/97 Posted by "Jared M. Spool" : UIETips 3/4/97 _______________ Table Of Contents * Introduction * From The Editor: WinHelp & Web Developer's Conferences * Web Observations: Buttons & Fields * Web Observations: User Registration * Eye For Design * UIETips Subscription Information _______________ Introduction UIETips describes the latest research and other information that developers need to design today's products. UIETips is produced by User Interface Engineering, a product usability consulting firm based in North Andover, MA. Information on subscribing to UIETips can be found at the end of this message. Check out our website at http://www.uie.com. _______________ From The Editor: WinHelp & Web Developer's Conferences Jared M. Spool Having just gotten back from two conferences on the west coast -- WinHelp '97 & Web Developer's '97 -- I find the world to be an interesting place right now. Even though the conferences were very different, my impressions of them were the same. Essentially, both conferences were void of content issues. I don't mean that there was nothing said at the conference -- on the contrary, both were fascinating. What I noticed was that everyone was focused on the technology for delivering content, not on the content itself. This is a fascinating juxtoposition to what we're finding in our usability studies of help and the web: the key issues are all content issues. Most of the problems we have found had to do with missing information or information that is structured such that users can't find what they want. But neither of the conferences dealt with these issues. It's as if we don't really know what to say, so we just avoid the topic altogether. When I mentioned this observation in the opening statement to my closing session at the WinHelp conference, I got a round of applause. My take was that the audience noticed this discrepency also. At the WinHelp conference, Microsoft unveiled their plans for HTML Help, the next generation of help tools for Windows platforms. It has many neat and interesting features, primarily for the help developer. There were some interesting new user features, such as the ability to customize what portions of the help file they were interested in (you can choose only expert topics or introductory topics). However, Ralph Walden, the project lead, told me that Microsoft hasn't really tested these new features with users. While they have done testing on the development tools (good news for help developers), they haven't really determined if the new features are actually things that users want. Since we've found that most users never customize their work environments, it's hard for us to believe they will customize their help environments. At the Web Developer's conference, there was lots of talk about ActiveX and Java, authoring Shockwave and using push technologies. But very little discussion about what users need and how to tell if you've met their needs. Here, unlike the world of on-line help, we have an excuse: it's just too new. One line of thinking is that, because components and applets are still just toys, for the most part, we don't need to really understand them. This thinking goes on to suggest that we just need to get them out there and see what works and what doesn't. Then we'll know how we should have built them. Even this line of thinking implies that we need a way to measure effectiveness. And our recent research into how people use HTML-based applications tells us that what we thought we knew about these mediums might, in fact, not be true. Even more reason to have some high-quality measurement techniques. In this issue of UIETips, I've included some more of the tidbits from our research into how people get information from the web. Since the studies are on-going, we'll be giving more of these tidbits as they become available. We're busy working on the initial report, which will be available in a few weeks. (Watch this space to get your copy!) As always, feel free to pop me a message with comments or suggestions. I'm always interested in making improvements. Jared _______________ Web Observations: Buttons & Fields You would think that after years of designing dialog boxes, we'd know how to lay out buttons and fields. Well, in the world of web pages, this turns out not to be true. In our recent research of people using pages, we've found multiple designs that users find difficult. For example, on the Inc. Magazine site (http://www.inc.com), they have provided a handful of search engines for different databases, from Government Small Business agencies to associations and societies. The designers have placed all the search engines on a single page. For each page, they have a brief description of the database, followed by the fields and a button labeled "Search!" Because of their clever use of tables, it was often possible for a user to have two to four engines visible on the screen at once (each with a button with the same "Search!" label). While testing this site, we noticed that it wasn't uncommon for users to enter their search target string into one field then use a different engine's "Search!" button. We don't know if it was the overuse of the same label or the fact that users didn't understand the relationship of buttons which only pertain to a subset of the fields. However, our experience with other sites causes us to lean towards the latter explanation. In dialog box design, we almost never have buttons which pertain to just a couple of fields. Usually, the OK & Cancel buttons apply to everything in the dialog. But that isn't true with this style of web page design, and users seemed confused by it. Travelocity (http://www.travelocity.com) also had a form that caused users problem. In choosing segments of a flight (for instance, a roundtrip from Boston to Los Vegas would be two segments -- one from BOS to LAS and one from LAS to BOS), they present a button labelled "Submit" under the fields for each segment. The idea is that if you have a one-way trip, you'll press the first "Submit" button. If you have a roundtrip or 2 segment flight, you'll press the second, and so on. Users would enter the segments of their trips (which they often didn't do correctly, indicating that they didn't really understand how to book air travel), then scroll down to the last possible segment (#6) and press it's "Submit" button. This behaviour of scrolling down to the bottom-most button was common. We've named it "Button Gravity." Button Gravity seems to occur when the users are not clear as to what they are doing. They enter the fields the best they can then look for the most likely button, which they often believe will be at the bottom of the web page. Our inference is that, since the most important buttons in dialog boxes are found at the bottom-most or right-most parts of the box, that's where they should go. We're presuming that the reason Travelocity has six buttons, all labelled "Submit," is that their CGI code can't easily tell which fields have been filled in and which ones haven't. And, based on the error messages the user received when pressing the wrong buttons, we'd say that our presumption is fairly solid, since it didn't address anything close to the actual problem. When designing buttons and fields on your pages, these findings would indicated that you should try to keep your buttons limited to operating on all of the fields visible. _______________ Web Observations: User Registration In the sites we've been testing for our study, only Travelocity, so far, has a required registration page. However, we noticed that this was the one page that every user gave up on. The way we structured our testing, it turns out that the registration wasn't required to complete the first task, only the second. (This wasn't intentional on our part. They only require registration for flight information, not general travel information.) Therefore, it was often 20 to 30 minutes before they'd hit the registration screen. Just the surprise factor alone was enough to fluster users. What then happened was that users are given a choice between a) signing in with an existing login Id & password, b) becoming a member, or c) becoming a guest. None of the users could clearly tell us what the difference between becoming a member or a guest was. Several users tried their name and a random password, just on the off chance that they (or someone just like them) had already registered -- they hadn't. After a few moments, users would try a link buried in the Become A Guest option that just said "Create a name and password." This would present a simple form where people would be asked for a login Id and a password -- nothing else. Most people would type in their first or last name for their Id. Every name that people tried initially was already in use. (The error message said "Somebody is already using PAULA" -- interesting choice of words.) Users would then try other names, often they'd be in use also. At this point, users would give up. We would have to give them the login id and password we'd established during the setup of the testing. That was the only way they would continue with the site to complete our testing. What this tell us is that, if you have a registration site, you want to make sure it is required. The users we tested didn't see what the value of registration was and didn't know why the site was putting up these obstacles for them to get what they needed. They understood that if they wanted to buy something, they would have to identify themselves, but since they were just on a fact-finding mission, they didn't know why the site needed them to register. If you do require it, make sure it is easy to create a login name. While we haven't tested it, AOL suggests alternative names if the one the user chooses is already in use. If that had been done in Travelocity's case, it would have helped tremendously. _______________ Eye For Design If you are not an Eye For Design subscriber, you've recently missed these articles from the November/December '96 issue: Core Apps vs. Ring Apps Is your application written to help people with their core competencies? Or is it written to help them with skills outside their core competencies? The amount of functionality you provide, the control over details, and whether you focus on productivity or ease-of-learning will depend on your answer. Incredibly Intelligent Help To test and refine the content of the help system, we use a technique we call incredibly intelligent help. Often this technique also identifies ways to improve the interface itself, thus removing the need for help. And, we can use it before anyone begins writing the help. [Designer's Scrapbook] Built In Clues: Adding Affordances An affordance is a clue that communictes how an object can be used. This scrapbook looks at the affordances used in 11 different applications, including Windows 95, Quicken, Travelocity, and Lotus Approach. Measuring Why People Buy It doesn't matter how usable a product is if no one buys it. Good products can fail unless engineering, sales, and marketing have a common understanding of why people want to buy the product. We talk about a recent project where we interviewed potential customers as they left a trade show to find out their perceptions of the product. Integrating Other Applications Your application or web site needs some functionality that is provided by another product. Should you just integrate it with your application, or spend the effort to "reinvent the wheel?" We'll talk about recent projects where we need to make this decision and what we've learned from observing users. We are extending a limited-time, *special* offer of $39.99 for a one-year subscription (six issues, normally $79.00). Subscribe by March 18, 1997 and you'll receive not only our special introductory price of $39.99 for a one-year subscription, but also... o All 1996 issues (a total of 5 additional issues) o 15% off a 1997 User Interface Engineering public course o 10% off your User Interface '97 conference registration Your Price is $39.99. (A savings of over $300.00) International subscribers, please add $12.00. Amex, Mastercard, Visa, and Discover are accepted. You can subscribe via email to efd@uie.com, our website at http://www.uie.com or by phone at (508) 975-4343. _______________ UIETips Subscription Information To remove your self from the list: Send the word UNSUBSCRIBE in the body of a message to UIETips-Request@uie.com. To add yourself to the list: Send the word SUBSCRIBE in the body of the message to UIETips-Request@uie.com. Questions? Send mail to Tips@uie.com or check out our website at http://www.uie.com (c) Copyright 1997, User Interface Engineering Brought to you by: User Interface Engineering (508) 975-4343 (uie@uie.com) -- End -- ========================================================== Jared M. Spool User Interface Engineering mailto:jspool@uie.com 800 Turnpike Street, Suite 101 (978) 975-4343 North Andover, MA 01845 fax: (978) 975-5353 USA http://www.uie.com If you send me your postal address, you'll get the next issue of our newsletter, Eye For Design. ========================================================== From jspool@uie.com Mon Jul 13 18:36:23 1998 Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0) id SAA18855; Mon, 13 Jul 1998 18:10:13 -0400 (EDT) Received: from jasmine (world.std.com) by world.std.com (TheWorld/Spike-2.0) id AA18856; Mon, 13 Jul 1998 18:10:09 -0400 Message-Id: <199807132210.AA18856@world.std.com> Comments: Authenticated sender is From: "Jared M. Spool" Organization: User Interface Engineering To: Gary PERLMAN Date: Mon, 13 Jul 1998 18:04:47 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: Re: Reply-To: jspool@uie.com Priority: normal X-Mailer: Pegasus Mail for Win32 (v2.54) Status: O Back Issue #8 (Each Issue Sent Separately!) Date: Thu, 19 Feb 1998 12:08:36 -0500 (EST) From: "Jared M. Spool" Organization: User Interface Engineering To: UIEtips@uie.com Subject: Category & Content Links -- UIETips 2/19/98 UIEtips 2/19/98 _______________ Table Of Contents * Introduction * Message From The Editor * Feature: Not All Links Are Created Equal * On The Road * Private Talks * New Course: Web Sites That Work: Designing With Your Eyes Open * Resources: Web Site Usability Report, Eye For Design, www.uie.com * UIEtips Subscription Information _______________ Introduction UIEtips describes our latest research and other information that developers need to design today's products. UIEtips is produced by User Interface Engineering, a product usability consulting firm based in North Andover, MA. Information on subscribing to UIEtips can be found at the end of this message. Visit our web site at http://www.uie.com. _______________ Message From The Editor Jared M. Spool We're busy working on the publication of our newest web-site usability findings. We've done all this research and found out some cool stuff, now we have to let you know what we've found. We're doing this through a few different media: * UIEtips is the first place we publish our results. As a subscriber, you'll find out what we know as soon as we know it. * We've put together a new 90 minute presentation entitled "The Scent Of Information." This talk made its debut to rave reviews at the WinHelp Developer's Conference in Seattle last week. * Our new course, "Web Sites That Work: Designing With Your Eyes Open," will be presented in Cambridge, MA, on March 30-31. We expect this course to sell out -- we haven't even officially announced it yet and we're already getting registrations. (Thanks to everyone who participated in our December rehearsal!) (If you want more information on UIEtips, private talks, or the upcoming web design course, see the information at the end of this issue.) * The two most-recent issues of Eye For Design (Sept/Oct 97 and Nov/Dec 97) have featured several articles from our findings. (We've been a little slow in publishing, but we're just about caught up -- sorry, our recent success has had its price! The Nov/Dec 97 issue just went to the printer and subscribers should get them shortly. We expect the Jan/Feb 98 issue to be ready in the next few weeks.) * We plan to publish a series of special reports this spring. These reports will detail our new findings and provide lots of examples of all the factors we've found that help or hurt the usability of a web site. Watch this space for details. As always, if you have any questions, feel free to contact me or anyone else here at User Interface Engineering. Jared _______________ Feature: Not All Links are Created Equal Some findings from our recent web-site study show that users were more successful in finding information when they followed links that led directly to information instead of links that led to other links. By looking at how these types of links differ, designers can gain insights into effective web-site design. >> Our Link Classification In order to study their differences, we classified links according to where they led. Two types were most significant. "Category" links lead to other links. They were the largest group, accounting for 42% of the links users chose in our study. An example of a category link is a link labeled "Museums" that leads to a page containing links to museum web sites. "Content" links lead directly to information. They accounted for 25% of the links chosen. The remaining links included home/back links and type-in fields for search engines. >> Category Links Hurt Usability We believe that category links may contribute to many of the web-site usability problems we've seen. When we correlated the types of links with user success in finding information, we saw that content links led to success significantly more often than category links, even though users chose content links less frequently. When users chose a content link, they had approximately a 47% chance of finding the information they were looking for. However, when they chose category links, they only had approximately a 31% chance of success. Content links led users to information much more successfuly than other kinds of links. We also found that users were four times more likely to give up on finding information when they chose category links rather than content links. They gave up even though we'd told them in advance that they could find the answer on the site. >> How They're Different One obvious difference between content and category links is that the user is only one click away from information with a content link. With a category link, the user is at least two clicks away. Sites with lots of category links require the user to "drill down" deeper to find information. >> Longer Links May Help Theoretically, content and category links shouldn't look any different, because we defined them based on where they went, not any visual aspects of the links themselves. But we discovered that content links tended to be significantly longer than category links -- 19 words as compared to 5.3 words. (Note that we counted the associated text around the link as well.) Something about the additional words seems to have helped users pick the links that led to the desired information. But not all long content links were effective. The Smithsonian Magazine site (http://www.smithsonianmag.si.edu) used article titles as link names. These produced long, but not very descriptive links, and users didn't get the information they needed to succeed. >> Look Down, Not Left The more successful links appeared lower on the page; most of these are content links. The content links users chose were an average of 7.9 inches from the top. The category links they chose were only an average of 4.3 inches from the top of the page. This finding suggests that designers may not need to worry about making web pages short, and can focus on creating good links instead. A left panel is a collection of links on the left-hand side of the page, separate from the rest of the content. We found that links in left panels were much less likely to lead to success than links elsewhere on the page. This may be because most of them are category links. Left-panel links have only a few words because they appear in a narrow column. They also usually appear near the top of the page, often appearing in the first full screen. By contrast, content links can appear anywhere on the page, so their average page depth is more varied. Left-panel links are intended to provide a short cut for users--to give them a way to jump quickly to other major sections of the site. However, because these links are category links, users who clicked on them were actually less likely to get where they wanted to go. Users were less likely to click on left-panel links the longer they used a site. We think they learn that left-panel links don't help them find what they're looking for, so they look for other resources. >> Differences Count >From these striking difference between content and category links, we've concluded that designers may have more success if they put more content links and fewer category links on their sites. They also may help their users if they make category links look and feel more like content links, by making them longer and placing them deeper in the page. We've been experimenting with longer category links in left panels, but haven't measured their impact yet. (You can see an example of this on our web site at http://www.uie.com.) _______________ On The Road User Interface Engineering's consulting team spends a lot of time traveling. Sometimes, you can catch us while we're in your neighborhood. If we have the time, we'd love to stop by and see what you're doing or possibly even give a short presentation about some of our latest research. Here's a brief summary of some of our upcoming travel: Jared M. Spool: - February 26: Seattle, WA (Puget Sound CHI) - April 6: Denver, CO (Web Design '98) - April 14-16: San Francisco, CA (Web Builder '98) - April 19-20: Los Angeles, CA (CHI '98) Tara Scanlon: - April 19-20: Los Angeles, CA (CHI '98) Carolyn Snyder: - March 23-24: Roanoke, VA (Consulting) - March 26-27: Orem, UT (Consulting) - April 19-20: Los Angeles, CA (CHI '98) When we're not traveling, you can find us hovering around our home base of North Andover, MA. _______________ Private Talks User Interface Engineering offers several short talks on topics related to software and web site development. These talks have been "usability tested" at technical conferences across the country. All talks are 60 to 90 minutes in length and include time for discussion. Different talks are best suited to different audiences. We present the highlights here. Check out our web site (http://www.uie.com) for the full descriptions. >> For The Whole Team: We've found that the following talks work particularly well when the whole product team attends. This includes software and hardware engineers, technical support, information designers, course developers, product managers, marketing specialists, and management. *NEW* Darwinian Design Learn how both your users and your products evolve, and how you can stay one step ahead of this evolution. *NEW* In Search of Product Excellence Learn the traits and tricks of the most effective product development teams. Usability: McGyver Style Learn quick and easy techniques for building usable products. Tracking the Ice Floes: Designing for Process Learn how to identify the bottlenecks in a process and increase throughput. In Search of Mission-Critical Applications Hear how other companies have built and deployed mission critical applications. >> For Interface and Product Designers: The following talks are aimed at software engineers, UI designers, usability professionals, tech writers, and anyone else involved in interface design. *NEW* Communicating the Concepts: Learning Design from Tax Software Tax software has to communicate complex concepts quickly. Hear how tools like multimedia help and cue cards can make it easier to teach complex concepts. GUI Tricks: What Works and What Doesn't Find out how best to use Graphical User Interface controls to maximize usability. Building Better Wizards Learn why some wizards works well and others don't, and what you can do to make your wizards usable. >> For Web Designers: Anyone involved in web site design or creation would benefit from the following talks. *NEW* The Scent of Information: How to Make Your Site Smell Great Web users follow the 'scent of information' to find what they need on your site. Here's how to make the scent stronger. Cool Doesn't Cut It: Building a Usable Web Site Hear our research about what actually makes a web site usable. >>For Technical Communicators: Technical writers, information designers, and their managers would benefit from the following talks. *NEW* How to Win Friends and Influence Developers Hear success stories and learn proven techniques for having an impact in product design. What Do People Do with Docs? Hear about how people actually use documentation and online help, based on our observations of hundreds of usability tests. To find out about pricing and availability, please give us a call at (978) 975-4343! _______________ New Course Web Sites That Work: Designing With Your Eyes Open We've got a new course for 1998, based on our ongoing research into the design of web sites. The course contains new and unpublished material. This two-day course is scheduled for March 30 & 31, 1998 in Cambridge, MA. There are a limited number of spaces available, so please be sure to register right away, as this course is likely to sell out quickly. To receive registration and course information, send mailto:courses@uie.com with the words SEND INFO in the body of the message or visit our web site at http://www.uie.com. _______________ Resources: Web Site Usability Report, Eye For Design, www.uie.com In the process of doing our work, we collect a tremendous amount of information on what makes products and web sites usable. Here are three resources that we've made available: Report: Web Site Usability: A Designer's Guide It's commonly accepted that graphics, color, and white-space are among important elements of a successful web site. However, it turns out that this may not be the case after all. This report sets those ideas on their head. "Web Site Usability: A Designer's Guide" is a 155-page report based on our observations of the struggles and successes of more than 50 users as they searched for information on nine popular web sites. (To get a sample chapter and ordering information, send mailto:web@uie.com with the words SEND CHAP-1 in the subject of the message.) Eye For Design If you like what you read on UIEtips, you'll love Eye For Design, our bi-monthly newsletter containing tips and techniques for developing excellent products and web sites. You'll read about the latest research we've done on how to build usable applications. (For a complimentary issue, send your postal address to mailto:efd@uie.com.) http://www.uie.com Here, you'll find articles on many things, including how tabbed dialogs can get designers into trouble, using paper prototypes to manage risk, how to spoon-feed conceptual information using tips and hints, and a new comprehensive UI bibliography from Chauncey Wilson of WilDesign Consulting. _______________ UIEtips Subscription Information To remove yourself from the list: Send the word UNSUBSCRIBE in the body of a message to UIEtips-Request@uie.com. To add yourself to the list: Send the word SUBSCRIBE in the body of the message to UIEtips-Request@uie.com. Questions? Send mailto:tips@uie.com. (c) Copyright 1998 User Interface Engineering 800 Turnpike Street, #101 North Andover, MA 01845 phone: (978) 975-4343 fax: (978) 975-5353 http://www.uie.com mailto:uie@uie.com -- End -- ========================================================== Jared M. Spool User Interface Engineering mailto:jspool@uie.com 800 Turnpike Street, Suite 101 (978) 975-4343 North Andover, MA 01845 fax: (978) 975-5353 USA http://www.uie.com If you send me your postal address, you'll get the next issue of our newsletter, Eye For Design. ========================================================== From jspool@uie.com Mon Jul 13 18:36:24 1998 Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0) id SAA18783; Mon, 13 Jul 1998 18:09:42 -0400 (EDT) Received: from jasmine (world.std.com) by world.std.com (TheWorld/Spike-2.0) id AA18524; Mon, 13 Jul 1998 18:09:38 -0400 Message-Id: <199807132209.AA18524@world.std.com> Comments: Authenticated sender is From: "Jared M. Spool" Organization: User Interface Engineering To: Gary PERLMAN Date: Mon, 13 Jul 1998 18:04:45 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: Re: Reply-To: jspool@uie.com Priority: normal X-Mailer: Pegasus Mail for Win32 (v2.54) Status: O Back Issue #3 (Each Issue Sent Separately!) From: "Jared M. Spool" Organization: User Interface Engineering To: uietips@uie.com Date: Fri, 18 Apr 1997 15:29:05 -0500 Subject: Animation In Web Sites -- UIETips 4/18/97 Posted by "Jared M. Spool" : UIETips 4/18/97 _______________ Table Of Contents * Introduction * Web Observations: Animation * Web Observations: Internal Search Engines * From The Editor: Goodbye's We'd Rather Not Give * Eye For Design * Upcoming Courses * UIETips Subscription Information _______________ Introduction UIETips describes the latest research and other information that developers need to design today's products. UIETips is produced by User Interface Engineering, a product usability consulting firm based in North Andover, MA. Information on subscribing to UIETips can be found at the end of this message. Check out our website at http://www.uie.com. _______________ Web Observations: Animation When we first started testing products that required a mouse, we would see users physically react to their computers. For example, when they would get frustrated with the mouse, they would try to click on buttons by pressing their fingers up against the screen. This physical reaction came from their complete frustration with the device. In the years since, we haven't really seen users react physically this way, until now. We first noticed in Disney's old web site. (http://www.disney.com -- they've since revised it.) What we noticed was, that when a certain animation appeared on the screen (an advertisement for FAMILY.COM which showed a pre-teen girl in braids jumping towards the reader), users would try to scroll her off the screen. But due to the configuration of our test units (800x600), they were unable to do so. So they would cover her up with their hands. Fidelity (http://www.fidelity.com) also had an advertisement that did this -- spinning gyroscope or space station (we never did quite figure out what it was) that appeared on their Personal Investing page. Again, we saw the same reaction -- people covering the image with their hands. To say that the animation was distracting to these users would be an understatement. It was downright irritating. The users just could not concentrate on their reading with all this constant motion on the screen. Imagine trying to look up stock prices in the Wall Street Journal while someone is doing jumping-jacks right in front of you -- same effect. On the Travelocity site (http://www.travelocity.com), we saw some different effects. In this site, almost always, the animated banners could be scrolled off of the screen. So, users didn't seem as distracted as we saw in the previous examples. However, we did notice something. During at least one of our tests, while trying to answer a question about the lowest fares to England, an animated ad appeared with the text of "Lowest Fares To London." Not only did the user not click on the ad, he swore he never saw it. Somehow, the user had "masked" out the animation. (We saw it -- as observers it was difficult to *not* see it.) Our take on this: while retrieving information, users will mask out animation. Now, keep in mind that we didn't see any examples of animation that actually provided content -- all of it was advertising or decoration. So, we don't know if you provided an animation on some procedure that the user needed, whether they would pay attention to it. But, gratuitous animation (from a finding information perspective) didn't work. The really interesting thing is that, if you go looking, you'll quickly come across studies that will tell you that banner advertisements with animation get over twice the click-through rates of non-animation banner ads. People are more likely to notice, and click on, an ad with animation. This is counter to what we found in our testing. But click-through is an activity that one does when surfing. Our tests were all for finding information. (For those of you who have just signed up on UIETips, we've been conducting "scavenger hunt" tests by pointing people at specific web sites and having them answer specific questions.) This difference between the banner ad click-through and our results would imply that there is a difference in surfing and information retrieval. This implication is serious: We haven't met any web site designers who are designing differently, based on whether they though users would be surfing or searching. But these results imply that you might have to do just that: different designs based on the user's goals. It is too early in our research to know if there are elements other than animation that make this distinction obvious. However, if there are, we might have to sit back and rethink the way we design sites. _______________ Web Observations: Internal Site Searching Several sites that we studied included search engines. While it wasn't our goal to study how users use search engines in this study, (we have another study slotted just for that purpose,) it was unavoidable on these particular sites. One problem that we saw had to do with knowing what you were actually searching. Several of the sites actually had multiple search engines, which covered very specific domain areas. C|net (http://www.cnet.com), for instance, had six engines that we could identify (and a whole bunch more browsable lists, that users could manually search). The problem with this approach is that users often searched the wrong engine. For example, users wanting to search all of the articles that C|net had written on digital cameras would accidentally find themselves searching all of the web site reviews. Because this accidental search still returned results (sites for companies that made or sold digital cameras), the users didn't realize that they didn't search what they wanted. Fidelity tried a different approach by putting the different domains in a pull-down combo control on the search window. So, when you went to search, they would ask you if you wanted to search Fidelity Mutual Funds, Fidelity Daily NAVs, or Personal Investing. None of the users could tell us what the differences were between these three domain spaces. And they seemed surprised when using the same search query in each domain space brought up often different, but sometimes overlapping results. The new Disney site has a search engine that seems to search the entire site (all 7,000 pages). But it is not clear what the relevance algorithm is. We've noticed that if you type in, for instance, "Walt Disney World Monorail" (one of our questions was "What is the cheapest hotel on the Monorail at Walt Disney World?") you get lots of seemingly relevant responses, intermingled with results called "Welcome To Disneyland," "Walt Disney Records: Bio of Goofy," and "Disney's Amazing Book Factory". When all done, you are presented with a panel that says that if you didn't find what you were looking for, you could try your search again, this time with checkboxes for 10 or so specific domains, one of which is "Walt Disney World." It was not clear to us why this wasn't presented before you did the original search. Both the Fidelity and Hewlett Packard (http://www.hp.com) sites returned only page titles as a result. As we watched users struggle with the result lists, it became clear to us of the importance of web page titles. Most users were unable to distinguish one page from another based on only the title content. Up until this point, we'd never thought about page titles because we'd never seen users care what the title of a page is -- with the exception of bookmark lists. But here, they were relying purely on the title to determine relevancy, and it almost never worked. There were a couple of other minor anomolies that we witnessed. For instance, several sites would return every so often, for lack of anything better, a filename in the result set. We've assumed that those pages didn't have specified titles. Also, Fidelity, which uses small frame panes to contain HTML-based advertisements, would return these ad pages as part of their result sets. For example, searching on "International" returned several ads talking about international investments. Since these ads were intented to be in a small box, they didn't have anything but a small image and a single link. The users were not amused. The lesson here seems to be: don't let your search crawler see your advertising. Speaking of frames, there was another peculiarity of searching. When users got a result that was a page intended to be in a frame, the display characteristics were very peculiar. For example, Fidelity uses a table-of-contents (TOC) pane in their FAQ pages. Clicking on an item in that pane brings up the topic in the main pane. In one test, the user had searched and retrieved the TOC page as a result. When they brought it up, it wasn't in its intended pane, but instead occupied the entire window. Thus its behavior broke (and gave a Javascript error) when the user clicked on an item. Essentially, if information is designed to be viewed in a multi-pane frame, it's extremely difficult (with today's technology) to make that information searchable and achieve its design goal. It seems that searching information on a site, while straightforward in theory, seems to run into lots of hitches in practice. None of the sites we tested that had internal search engines escaped our tests without usage problems. _______________ From The Editor: Goodbye's We'd Rather Not Give Jared M. Spool Next week, User Interface Engineering will lose 20% of our workforce. This was always the plan, but it is difficult none the less. Our loss is the result of two of our interns, Terri DeAngelo and Maureen Tobin, coming to the end of their six-month internship. You have probably never met Terri or Maureen, but you are intimately familar with their work. Terri has been absolutely essential in our conducting the Web Site Usability study. She observed *every* test (something no-one else in our group can claim), measured every site, and filled out the spreadsheets and worksheets with the hundreds of data points collected. She's collected screen shots and spent time in endless meetings briefing us on this question and that ("Did we ever see anyone use the descriptions that follow each search result in the new Disney site?" "How many people clicked below the fold on the comparison questions?" "What was the cool quotes from people getting frustrated with C|net?" and the perennial favorite: "What do we know about frames?") Maureen has been vital in our ability to get this information to you. While primarily working on our sales and marketing efforts, she has produced all of our marketing materials for the last few months. Because of her efforts, we've been able to bring reduced pricing for Eye For Design, better materials for our private courses, and new perspectives on how to more effectively market the knowledge and know-how that we collect in our consulting and research work. The internship was through the Massachusetts Software Council Fellowship Program. This program places talented people who have been caught in the down-sizing or right-sizing activities of today's world into positions that allow them to get experience in the software industry. We have been exceedingly fortunate to have gotten the cream of the program's crop, and will continue to use the program in the future. But, we are sad to see Terri & Maureen leave us. It is unfortunate that our limited resources, as a small consulting firm, do not let us do what we want to do. Both are currently looking for opportunities and we wish them the best of luck in their future. _______________ Eye For Design If you are not an Eye For Design subscriber, you've recently missed these articles from the January/February 1997 issue: Comparisons Using software can be a process of trial and error, without quite understanding what you're doing. See how some software applications actually make trial and error easier for their users by making comparisons to see if they're moving in the right direction. A Tale Of Two Doc Sets We watched users in the real world work with documentation. Some of them would have killed us if we'd taken their printed manuals. Others wouldn't have even noticed. It was interesting to see how differently people used their doc sets. Tabbed Dialog Designs Tabs are here to stay, and they're popping up in web sites as well as in GUIs. This Designer's Scrapbook shows some ideas to try and some to avoid. Market Maturity Why would anyone pay $100 for a pocket calculator? Why did WordPerfect lose market share to the competition? Users' expectations of a product depend on the maturity of its market. By identifying what stage your product is in now, you can anticipate some of the pitfalls that lie ahead. We are extending a limited-time, *special* offer of $39.99 for a one-year subscription (six issues, normally $79.00). Subscribe by May 16, 1997 and you'll receive not only our special introductory price of $39.99 for a one-year subscription International subscribers, please add $12.00. Amex, Mastercard, Visa, and Discover are accepted. You can subscribe via email to efd@uie.com, our web site at http://www.uie.com or by phone at (508) 975-4343. _______________ Upcoming Courses We're offering our two flagship courses: Product Usability: Survival Techniques May 6, 1997 Techniques For Complex Applications May 7, 1997 Both courses are being held at the Andover Marriott. Registrations for these courses are coming in quickly. You can check out the course descriptions on our web site at http://www.uie.com or we can mail you a brochure. We can also offer these courses at your company. This is more cost effective when you are training 8 or more people. Due to popular demand, we extended our price increase for on-site courses until May 1st. Any courses booked before May 1st, will get in under the old rates (a significant savings). If you are interested in a course, please call us right away. _______________ UIETips Subscription Information To remove yourself from the list: Send the word UNSUBSCRIBE in the body of a message to UIETips-Request@uie.com. To add yourself to the list: Send the word SUBSCRIBE in the body of the message to UIETips-Request@uie.com. Questions? Send mail to Tips@uie.com or check out our website at http://www.uie.com (c) Copyright 1997 User Interface Engineering 800 Turnpike Street, #101 North Andover, MA 01845 Phone: (508) 975-4343 fax: (508) 975-5353 http://www.uie.com mailto:uie@uie.com Brought to you by: User Interface Engineering (508) 975-4343 (uie@uie.com) -- End -- ========================================================== Jared M. Spool User Interface Engineering mailto:jspool@uie.com 800 Turnpike Street, Suite 101 (978) 975-4343 North Andover, MA 01845 fax: (978) 975-5353 USA http://www.uie.com If you send me your postal address, you'll get the next issue of our newsletter, Eye For Design. ========================================================== From jspool@uie.com Mon Jul 13 18:36:32 1998 Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0) id SAA18874; Mon, 13 Jul 1998 18:10:22 -0400 (EDT) Received: from jasmine (world.std.com) by world.std.com (TheWorld/Spike-2.0) id AA19070; Mon, 13 Jul 1998 18:10:18 -0400 Message-Id: <199807132210.AA19070@world.std.com> Comments: Authenticated sender is From: "Jared M. Spool" Organization: User Interface Engineering To: Gary PERLMAN Date: Mon, 13 Jul 1998 18:04:47 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: Re: Reply-To: jspool@uie.com Priority: normal X-Mailer: Pegasus Mail for Win32 (v2.54) Status: O Back Issue #9 (Each Issue Sent Separately!) From: "Jared M. Spool" Organization: User Interface Engineering To: UIEtips@uie.com Date: Fri, 20 Mar 1998 17:20:43 -0500 Subject: Scrolling on Web Pages -- UIEtips 3/20/98 UIEtips 3/20/98 _______________ Table Of Contents * Introduction * Message From The Editor * Feature: For Whom The Page Scrolls * Letters From Readers * New Consulting Service: Web Site Link Analysis * On The Road * On-Site Courses * Resources: Web Site Usability Report, Eye For Design, www.uie.com * UIEtips Subscription Information _______________ Introduction UIEtips presents our latest research and other information that developers need to design today's products. UIEtips is produced by User Interface Engineering, a product usability consulting firm based in North Andover, MA. Information on subscribing to UIEtips can be found at the end of this message. Visit our web site at http://www.uie.com. ___________ Message From The Editor Jared M. Spool In this issue, we're continuing to report on our findings from our most recent web site study. Once again, we've found that popular wisdom turns out not to be true when you actually watch what people do on a site. We also have some letters from readers of previous issues of UIEtips and a new consulting service that analyzes your web site and search engine logs to determine what links you need to have on your site. By the way, if you recently received a message from me saying that you weren't signed up for UIEtips, but it turned out you were, that means that we have two email addresses for you. If you receive duplicate messages from us, just forward both back to me and I'll research the problem. Jared ___________ Feature: For Whom The Page Scrolls It's a widely held belief among the web developers we hang out with that users hate scrolling. We've consistently seen designers struggling to keep as much of their design as possible "above the fold." However, our recent study findings say something different -- users will scroll and are more successful when they do. Our tasks focused on information retrieval -- could the user find specific information on the web site. Users participated in a "scavenger hunt" where we asked them to locate the answers on specific web sites to questions we created. While observing the users attempting to locate this information, we found that they were very willing to scroll through long pages. And, in analyzing the links that the users clicked on, we found some very interesting facts: > Fact #1: The lower the link on the page, the more likely it leads to success We measured the depth of each link that the user chose. We found that it was not unusual for users to click on a link that is up to 20 inches into the page. (We measure page length in inches -- an average 800x600 Netscape browser window is about 4.5 inches. So, 20 inches is about four and a half screenfuls.) We also found that, as users clicked lower on the page, they substantially increased the likelihood that they would (eventually) find the information. It seems that users who click toward the bottom of the page are pickier about what they finally click on. (If you are going to choose one link out of four screen, wouldn't you want to carefully consider which one?) Now, this isn't to say that you should move *all* your links to the 3rd screen. It turns out that there are other interesting attributes about those links that are found deep in the page. For example, links that deep are almost always text links. And they are almost always content links. (A content link is a link that points directly to content -- see "Category and Content Links" in the 2/19/98 UIEtips.) Category links are almost always at the top of the page. (A category link is a link that points to other links.) Also, links that are deep in the page tend to have more words (either in the link themselves or in the associated text). This suggests that creating long lists of content links is a successful design approach. Which brings us to our second fact: > Fact #2: The more groups of content links, the more likely the users succeed It was not unusual for these long pages to have their links grouped into categories. For example, the Edmund's home page (http://www.edmunds.com) had groups for New Cars, New Trucks, Used Vehicles, and Buyer Information. When we counted the number of groups that appeared on pages users visited during our testing, we found that users succeeded least when there were only two groups, and they were most successful when four to eight groups appeared on the page. Grouping is a way for users to discriminate among bunches of links. It also seemed that users used the links within the group to confirm they were in the right place by seeing other links they recognized near by. If the grouping didn't make sense, users seemed to have more trouble. However, we found that having more groups wasn't always the best thing. Six or more groups of category links did far worse than six or more groups of content links. Our recommendation to designers is that if you are going to create groups, fill them with content links. How many links should be in a group? Well, we've found that groups with up to 10 links show no negative effects. (We didn't run into enough groups with over 10 links to say one way or another.) > To Scroll or not To Scroll Scrolling isn't the issue we once thought it was. Users will scroll and it doesn't hurt their ability to find information -- in fact, it often helps. When building web pages that are intended to help people find information, you don't need to worry about scrolling. _______________ Letters from Readers: Category vs. Content Links In the 2/19/98 issue of UIETips we presented our findings on the difference between category and content links. Here's what we heard from one reader [edited for space purposes]: * * * * * >From TamlerH@aol.com As always, I appreciate your latest information on Web links, especially since it fits nicely into what I already believe about information architecture in general. That is, there's a strong analogy between category vs. content links on the one hand, and deep narrow menus vs shallow broad menus on the other hand. Hence, your finding about the greater usability of content links can be seen as a special case of the general rule that menu hierarchy depth should be minimized in favor of menu breadth. Howard ___________________________________________ Howard Tamler, Ph.D. HT CONSULTING - Software Usability Engineering 833 East Meadow Drive, Palo Alto, CA 94303 (650) 493-3426 htamler@baychi.org - - - - - In the 11/28/97 issue of UIETips we presented our findings on Internet-Savvy users. We found that, while users with Internet experience had different behaviors than those without the experience, we didn't see any difference in their ability to find information. Here's what we heard from one reader [again edited for space purposes]: * * * * * >From Lee Wright Having just completed research that included a very small group of expert Web users and a small group of novice users, your latest feature on saavy users was of great interest. Overall, we observed significant differences in the propensity of these two groups to look online for certain information as well as the way in which these two groups went about finding information online. Once in a site, however, they had similar desires that were often not met by the existing sites they visited: Quickly and easily find information relevant to helping make a decision. Both groups responded similarly to prototypes that were designed with this in mind. Based on your observations and those from our work, I'd conclude that experienced Web users are similar to those who have a good deal of experience in any other area. In this case, they have developed clues that enable them to quickly judge the pay-off from continuing to hunt through a site. Thus, the fact that they are willing to abandon the Web for an alternative information source at a rate faster than novice users is a function of efficiency, not lack of interest. Once those responsible for sites are able to implement designs (with the appropriate content) that meet the modest needs of their customers and potential customers, they should see higher returns from their online efforts. Best regards Lee Wright Lee Wright People | Design | Technology 214/503-0052 A research-based consultancy Dallas | Los Angeles | San Francisco __________ New Consulting Service: Web Site Link Analysis Designing a web site is a lot easier when you know what information your users need to find. We've developed a technique that allows us to determine what links users want to click on. By studying how users interact with your current site -- through a combination of usability testing and analysis of your search engine logs -- we can quickly identify the important links that your web site should have. If you would like more information on how we could help you ensure you have the right links on your site, please give us a call at (978) 975-4343. _______________ On The Road User Interface Engineering's consulting team spends a lot of time traveling. Sometimes, you can catch us while we're in your neighborhood. If we have the time, we'd love to stop by and see what you're doing or possibly even give a short presentation about some of our latest research. Here's a brief summary of some of our upcoming travel and what we'll be discussing: Jared M. Spool: - April 6: Denver - Web Design '98 (Web Sites That Work) - April 14-16: San Francisco - Web Builder '98 (Cool Doesn't Cut It & The Scent Of Information) - April 19-20: Los Angeles - CHI '98 (Product Usability Survival Techniques & Web Sites That Work) - April 23: Los Angeles - CHI '98 SIG (Measuring Web Site Usability) - April 29: Chicago - Andersen Consulting (private talk) - April 30: San Francisco - IT Forum (Cool Doesn't Cut It) Carolyn Snyder: - April 14-15: Rochester, Minn. - IBM (Web Sites That Work -- on-site course) - April 19-20: Los Angeles - CHI '98 (Product Usability Survival Techniques & Web Sites That Work) Plus, remember that when we're not traveling, you can find us hovering around our home base of North Andover, Mass. _______________ On-Site Courses Want to set your entire team on the right track for building usable products? Want to have a course that's customized just for your company, where we focus on *your* products and *your* development challenges? Want to get everyone on your team on the same page without decimating your travel budget? If so, an on-site course might be right for you. Some of the courses we can bring to you are: Web Sites That Work: Designing With Your Eyes Open This two-day course is for designers and developers of Internet and intranet web sites, content developers, graphic designers, web authors, and managers. Knowledge of HTML is useful, but not necessary. This course isn't based on opinions -- it's based on actual data about what works and what doesn't. You'll learn about usability tests, the "scent" of information, on-site searching, links, navigation, site organization, graphics, page layout, whitespace, readability, and users' knowledge. You'll gain first-hand knowledge of what works and what doesn't by conducting usability tests on live web sites. Product Usability for Documentation Professionals This two-day course is aimed at people who need to communicate, in particular technical writers, editors, training developers, graphic designers, web site designers, and documentation managers. Discover techniques that will dramatically change the way you build products, without requiring any more time, money, or people. You'll learn how to identify barriers, prevent the majority of usability problems, use techniques for collecting information about users, do usability tests, design usable web sites, and create a fully-working paper mock-up. The following two courses are ideal for all members of the product or web site development team, including software engineers, user interface designers, project leaders, technical writers, marketers, graphic designers, and product managers. Product Usability: Survival Techniques In this one-day course, we'll discuss how quality and usability are intertwined. You'll learn about Affordances, Mental Models, and Tool Time, and how to involve users at all stages of the product's development. Each participant will have the opportunity to build a low-fidelity prototype and conduct several usability evaluations. Techniques for Complex Applications Throughout this one-day course, we focus on the products that you're building right now. The exercises center around *your* applications. By the end of the day, you'll have a whole new perspective on your product. You'll have new questions, but you'll know how to find the answers. We'll discuss Market Maturity, Core versus Ring Applications, how to increase users' productivity, and which techniques to use for a given project. Check out our web site, http://www.uie.com, for more information and additional courses. It lists reasons to bring a course on-site and compares courses so you can decide which one is right for you. Please call us at (978) 975-4343. We'd be happy to have one of our consultants talk with you about your needs. _______________ Resources: Web Site Usability Report, Eye For Design, www.uie.com In the process of doing our work, we collect a tremendous amount of information on what makes products and web sites usable. Here are three resources that we've made available: Report: Web Site Usability: A Designer's Guide It's commonly accepted that graphics, color, and whitespace are among important elements of a successful web site. However, it turns out that this may not be the case after all. This report sets those ideas on their head. "Web Site Usability: A Designer's Guide" is a 155-page report based on our observations of the struggles and successes of more than 50 users as they searched for information on nine popular web sites. (To get a sample chapter and ordering information, send mailto:web@uie.com with the words "SEND CHAP-1" in the subject of the message.) Eye For Design If you like what you read on UIEtips, you'll love Eye For Design, our bi-monthly newsletter containing tips and techniques for developing excellent products and web sites. You'll read about the latest research we've done on how to build usable applications. (For a complimentary issue, send your postal address to mailto:efd@uie.com.) http://www.uie.com Here, you'll find articles on many things, including how tabbed dialogs can get designers into trouble, using paper prototypes to manage risk, how to spoon-feed conceptual information using tips and hints, and a new comprehensive UI bibliography from Chauncey Wilson of WilDesign Consulting. _______________ UIEtips Subscription Information To get the previous issues of UIEtips: Send the phrase SEND UIETIPS in the subject of a a message to archives@uie.com. To remove yourself from the list: Send the word UNSUBSCRIBE in the body of a message to UIEtips-Request@uie.com. To add yourself to the list: Send the word SUBSCRIBE in the body of the message to UIEtips-Request@uie.com. Questions? Send mailto:tips@uie.com. (c) Copyright 1998 User Interface Engineering 800 Turnpike Street, #101 North Andover, MA 01845 phone: (978) 975-4343 fax: (978) 975-5353 http://www.uie.com mailto:uie@uie.com -- End -- -- End -- ========================================================== Jared M. Spool User Interface Engineering mailto:jspool@uie.com 800 Turnpike Street, Suite 101 (978) 975-4343 North Andover, MA 01845 fax: (978) 975-5353 USA http://www.uie.com If you send me your postal address, you'll get the next issue of our newsletter, Eye For Design. ========================================================== From jspool@uie.com Mon Jul 13 18:36:35 1998 Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0) id SAA18816; Mon, 13 Jul 1998 18:10:03 -0400 (EDT) Received: from jasmine (world.std.com) by world.std.com (TheWorld/Spike-2.0) id AA18629; Mon, 13 Jul 1998 18:09:47 -0400 Message-Id: <199807132209.AA18629@world.std.com> Comments: Authenticated sender is From: "Jared M. Spool" Organization: User Interface Engineering To: Gary PERLMAN Date: Mon, 13 Jul 1998 18:04:46 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: Re: Reply-To: jspool@uie.com Priority: normal X-Mailer: Pegasus Mail for Win32 (v2.54) Status: O Back Issue #5 (Each Issue Sent Separately!) From: "Jared M. Spool" Organization: User Interface Engineering To: uietips@uie.com Date: Tue, 12 Aug 1997 09:45:53 -0500 Subject: Pushing Information For Productivity -- UIETips 8/12/97 Posted by "Jared M. Spool" : UIETips 8/12/97 _______________ Table Of Contents * Introduction * From The Editor: From Chaos to Orders * Pushing Information For Productivity * Making Files Disappear * Upcoming Course * Conference: User Interface '97 * Resources: Web Site Usability Report, Eye For Design, www.uie.com * Fall Calendar: Where to Find Us * UIETips Subscription Information _______________ Introduction UIETips describes the latest research and other information that developers need to design today's products. UIETips is produced by User Interface Engineering, a product usability consulting firm based in North Andover, MA. Information on subscribing to UIETips can be found at the end of this message. Visit our web site at http://www.uie.com. _______________ From The Editor: From Chaos to Orders Jared M. Spool For those of you who enjoy UIETips, I want to apologize for the delay in getting this one to you. (For those of you who don't enjoy it, instructions for unsubscribing are provided at the end of this message.) My excuse (and it is just an excuse) is that everything, all of a sudden, seemed to happen at once. Our new report, "Web Site Usability: A Designer's Guide," came out with a bang. In just a few weeks, we went from complete chaos to hundreds of orders and we still haven't spent a penny on advertising. We've also been working hard on our upcoming conference: User Interface '97, which will be held November 3, 4 & 5 in Cambridge, MA. As you'll see below, we've managed to put together an incredible line-up. Plus we have some new research to study the structure of web site links, trying to understand how users decide what links to click and what designers can do to help them catch the "scent of information." We're just starting the testing and should have results in the next few months. You'll read 'em here first. (It you'd like to be a user in one of our tests, you can sign up on our web site http://www.uie.com.) Jared _______________ Pushing Information for Productivity The primary purpose of an application's user interface is to provide information to users about how to accomplish their goals. Applications do not need a user interface -- Unix proved this. There is no way that you could sit an average human down in front of a Unix and expect them to accomplish anything. Yet millions of Unix users accomplish work every day. How did they know what to type? From man-pages, Nutshell books, user manuals, classroom training, Unix For Dummies, other users, technical support, newsgroups and many other sources. All these different mediums supply the information that the user interface doesn't. In essence, product designers utilize all these different mediums to provide information to the user. But we've learned that you can put each medium on a continuum. The ends of the continuum represent how productive the user is while retrieving the information. This is a crude representation of the continuum: <> | -- -- UI (Affordances) | -- -- Wizards & Cue Cards | -- -- Online Help | -- -- Reference Manuals | -- -- Tutorials | -- -- Classroom Training <> For example, when participants are in classroom training, they are not very productive. Sure they are receiving useful information, but they can't apply it right away. The information takes a long time to receive, because it is usually presented in abstract terms. Or it is presented through case studies and examples, but that still requires the participant to figure out which pieces relate to their problems and how to apply them. So, for the duration of this training, the participants are not getting work done. Contrast that with online help. To get the same information from online help, it is probably broken up into smaller chunks. Between each chunk, the user is doing work. As they need more information, they jump into Help, get what they need and leave -- in and out, nobody gets hurt. Overall, this time is very productive for the user. And when they are getting the information directly from the user interface, they are even more productive. When the UI is done right, the users never have to take their minds off of their direct task. The affordances just guide them to their goals. As designers, our job is to move as much information to the productive side of the continuum as possible. Tools like the user interface, wizards, cue cards, and online help make this significantly easier. They cost a lot to develop, but once developed they can make users significantly more productive. And isn't that why we're building these applications in the first place? We've noticed that the most usable applications we find are ones in which the development team has obviously spent time thinking about how they want to get information to the users and then designed explicitly for that. _______________ Making Files Disappear In a recent UTEST discussion, Joe Grant from Tripos brought up a fascinating question. (UTEST is a discussion list for people interested in usability.) Here's what he said: "The points about automatically saving; intelligent, multiple undos; removing the File menu, and basically shielding users from the computer file hierarchy are very thought-provoking, at least for me. Honestly, I haven't tried it, it sounds great, but is it realistic? Do we end up frustrating or satisfying users by doing this, even if it can be done? Has any other software done this? "Quicken comes to mind in addressing at least the point about implicit saving, and, for the most part, it spares me from routinely having to deal with files. (Except when I back up.) For my money, Intuit made a smart leap of faith in their design approach that is appreciated by at least this user." It wasn't a leap of faith that gave Quicken its ability to make the files disappear. We've found that it has to do with the basic nature of data storage. It turns out that Quicken had all of its ducks lined up right -- something that designers rarely get to do. To learn how Intuit pulled this off when others have failed, we needed to understand more detail about both the history of files and their structure. What we found was that designers with this goal have a hard task in front of them. -- The History -- Files, for the most part, are a historical artifact from early computing. Files were originally created to make data management easier. They were originally modelled after card decks. There have been several attempts over the years to eliminate files, such as MUMPS, a programming language/operating system that stored all your data in one massive multi-indexed database. (Bumper sticker: MUMPS Means Never Having to Say Your Sorting!) But, for mainstream computing, we've used files for over 45 years. It would be desirable to eliminate files. Directories, drives, networks all get in the way of real work. Having a different front end has real potential (Show me everything in the Zodiac project that Mary has worked on recently). Users wouldn't have to know which information is in which files. But accomplishing this isn't as easy as it might seem. -- The Structure -- A few applications have succeeded in eliminating files, such as Quicken. Why did Quicken succeed where others have failed? For one, Quicken data is transactional, unlike a word processor document or a medical record. Each element is small and discrete. And identical in structure. A deposit is essentially the same as a check or an ATM withdrawal. They have the same information (amount, date, transaction #, cleared, memo, category). It's also multi-dimensional. For instance, users may want to look at it by date. Or by category. Or by whether the check has cleared. To store this data, Quicken puts it all on one file. The order that the data is stored in actually rarely relates to the order that the information is viewed. Whereas, in a word processing document, the data is stored in essentially the same order as it is shown to the user. Multi-dimensionality changes the ballgame. Essentially, Quicken saves multiple elements in a single file. To save each element in its own file would require that the user know a lot about the infrastructure of the application without much added value. (What if they delete one file by accident? What if they rename it? What if they don't copy all the related transactions in their entirety?) Conversely, word processor documents are not uniform like Quicken transactions. They can be short or long. Often they don't relate to other documents. Users rarely want to produce a report that produces statistics on the contents of a collection of documents. (What's the average amount of passive voice on all the memos written since 1/1/97? How many times have we used the word "proclivity"?) But these are extremes. E-mail messages are an example of something that falls in the middle. Parts of them are uniform (the subject, to, from, date, and other header information). Parts of them are unique (the content). They have transactional value, such as threads. (Show me all the messages on the topic of Alan Cooper's latest book.) And they are multi-dimensional. (Show me all the messages since 1/1/97 about crash bugs in Internet Explorer. Filter out all the messages from MakeMoney@SpamKing.com.) There have been many attempts to provide a decent mail interface and we've never found one that really does the job well. Popular programs such as Notes, Eudora, and Pegasus have all taken a stab at this, but in watching users work with them, it's obvious that we still have a long way to go. A main reason is that Quicken has advantages in its data that most applications don't have: transactional uniformity. Anyone who has struggled with the design of a sophisticated customer service or patient management system will know that transactional uniformity is one of the first things to go when functionality sets in. How do you create a single type of transaction that will work for a patient who comes in for a single blood test versus someone who is staying in the burn unit for 9 weeks, undergoing 6-8 surgeries? Quicken has definitely done a fantastic job of relieving the burden on the user of understanding how the different stored objects relate. It is certainly worth exploring your application to see if you can do this for some, if not all of your stored objects. But if you can't, don't beat yourself up. Many before you have also tried and failed. You're in good company. (By the way, you can subscribe to UTEST by sending the word Subscribe in the body of a message to listproc@hubcap.clemson.edu.) _______________ Upcoming Courses We're offering our two flagship courses: Product Usability: Survival Techniques September 9, 1997 Techniques For Complex Applications September 10, 1997 Both courses are being held at the Andover Marriott in Andover, MA. Registrations for these courses are coming in quickly. You can check out the course descriptions on our web site at http://www.uie.com or we can mail you a brochure. We can also offer our courses at your company. This is more cost effective when you are training eight or more people. If you are interested in a course, please call us right away at (508) 975-4343. _______________ Conference: User Interface 97 Mark your calendar for User Interface 97: November 3, 4 & 5 in Cambridge, MA. While we're still nailing down the final program, we can tell you that we'll have eight day-long tutorials on topics such as: o Effective Web Site Design o Visual Design for Information Products o Interviewing Customers: Discovering What they Can't Tell You o Design for Emerging Web Sites o Designing for the Human Mind o Designing Virtual Worlds o A Usage-Centered Approach to Model-Driven UI Design We've lined up some world-renowned experts as speakers including Jakob Nielsen, Ellen Isaacs, Bruce Damer, Mary Mooney, Wayne Neale, Marc Rettig, Eric Lunt, Tom Hewett, Larry Constantine, and Lucy Lockwood. We promise to send you more information as soon as we've finalized all the details. But you'll want to make sure to keep those dates open. _______________ Resources: Web Site Usability Report, Eye For Design, www.uie.com In the process of doing our work, we collect a tremendous amount of information on what makes products and web sites usable. Here are three resources that we've made available: Report: Web Site Usability: A Designer's Guide It's commonly accepted that graphics, color, and white-space are among the most important elements of a successful web site. However, it turns out that this may not be the case after all. This report sets those ideas on their head. "Web Site Usability: A Designer's Guide" is a 155-page report based on our observations of the struggles and successes of more than 50 users as they searched for information on nine popular web sites. (To get a sample chapter and ordering information, send mailto:web@uie.com with the words "SEND CHAP-1" in the subject of the message.) Eye For Design If you liked what you read on UIETips, you'll love Eye For Design, our bi-monthly newsletter containing tips and techniques for developing excellent products and web sites. You'll read about the latest research we've done on how to build usable applications. (For a complimentary issue, send your postal address to efd@uie.com.) http://www.uie.com Here, you'll find articles on many things, including how tabbed dialogs can get designers into trouble, using paper prototypes to manage risk, how to spoon-feed conceptual information using tips and hints, and a new comprehensive UI bibliography from Chauncey Wilson. _______________ Fall Calendar: Where to Find Us This fall, we're going to be touring the continental US (still waiting for that Honolulu consulting gig!). When we're traveling, we often visit clients to give short presentations, meet their development teams, and just get a feel for what they are up to. If you'd like us to stop by when we're in your neighborhood, just give us a yell. If you're going to be at the UPA conference this week in Monterey, CA (8/13-8/15), you'll find Tara Scanlon at the Author's Table, autographing copies of Web Site Usability: A Designer's Guide. (http://www.upassoc.org) Jared Spool will be traveling all over the country this fall. He'll be speaking: - at Oracle World in Los Angeles on 9/22 (http://www.ioug.org) - at the Tuscon, AZ, STC Chapter on 9/25 (http://stc.org/region5/pac/www) - at the Progress Western Regional Conference in Pheonix, AZ, on 9/26-9/27 (mailto:chazg@erinet.com) - at the Help Technology Update Conference in Boston, on 9/29 (http://www.winwriters.com) - at the SD '97/Web Development '97 Conferences in Washington, DC on 9/30-10/3 (http://www.sd97.com and http://www.web97.com) For client work he'll be in San Francisco from 8/20-8/23 and Columbia, SC, on 9/15-9/16. Carolyn Snyder will be speaking at the Performance Support Conference '97 in Chicago, IL, on 11/17-11/20. (http://www.epss.com) _______________ UIETips Subscription Information To remove yourself from the list: Send the word UNSUBSCRIBE in the body of a message to UIETips-Request@uie.com. To add yourself to the list: Send the word SUBSCRIBE in the body of the message to UIETips-Request@uie.com. Questions? Send mail to Tips@uie.com or check out our web site at http://www.uie.com (c) Copyright 1997 User Interface Engineering 800 Turnpike Street, #101 North Andover, MA 01845 Phone: (508) 975-4343 fax: (508) 975-5353 http://www.uie.com mailto:uie@uie.com Brought to you by: User Interface Engineering (508) 975-4343 (uie@uie.com) -- End -- ========================================================== Jared M. Spool User Interface Engineering mailto:jspool@uie.com 800 Turnpike Street, Suite 101 (978) 975-4343 North Andover, MA 01845 fax: (978) 975-5353 USA http://www.uie.com If you send me your postal address, you'll get the next issue of our newsletter, Eye For Design. ========================================================== From jspool@uie.com Mon Jul 13 18:36:40 1998 Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0) id SAA18834; Mon, 13 Jul 1998 18:10:08 -0400 (EDT) Received: from jasmine (world.std.com) by world.std.com (TheWorld/Spike-2.0) id AA18732; Mon, 13 Jul 1998 18:10:04 -0400 Message-Id: <199807132210.AA18732@world.std.com> Comments: Authenticated sender is From: "Jared M. Spool" Organization: User Interface Engineering To: Gary PERLMAN Date: Mon, 13 Jul 1998 18:04:46 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: Re: Reply-To: jspool@uie.com Priority: normal X-Mailer: Pegasus Mail for Win32 (v2.54) Status: O Back Issue #7 (Each Issue Sent Separately!) From: "Jared M. Spool" Organization: User Interface Engineering To: UIETips@uie.com Date: Fri, 28 Nov 1997 13:21:03 -0500 Subject: Internet-Savvy Users -- UIETips 11/28/97 UIETips 11/28/97 _______________ Table Of Contents * Introduction * Message From The Editor: Trying New Things and a Goodbye * Feature: Internet-Savvy Users * Resources: Web Site Usability Report, Eye For Design, www.uie.com * Letters from Readers: On-Site Searching - Wayne Douglass - Duncan Sanderson - Fred Holtzman - John Springer - Cheryl Ward * 1998 Course Schedule * Area Code Change * New Course: Web Site Usability: Designing With Your Eyes Open * UIETips Subscription Information _______________ Introduction UIETips describes our latest research and other information that developers need to design today's products. UIETips is produced by User Interface Engineering, a product usability consulting firm based in North Andover, MA. Information on subscribing to UIETips can be found at the end of this message. Visit our web site at http://www.uie.com. _______________ Message From The Editor: Trying New Things and a Goodbye Jared M. Spool Our annual conference, User Interface 97, was a great success. We had close to 400 attendees, 50% more than last year. Overall, the conference was a success, and we also received many valuable suggestions for next year. We've already gotten underway with the planning for User Interface 98. The tentative dates are October 5th through 7th, to be held in Cambridge, MA, again. We've received many requests to bring "the show on the road," as it were, to the Left Coast, Europe, and Australia, but I think we're going to stay close to home for the near future. By announcing the dates earlier for next year's conference, we hope to give attendees time to find good deals on airfare. In this issue of UIETips, we are venturing a little off the beaten path. In addition to our usual report on our latest findings, we're going to try a couple of new things. First, I've decided to share some of the interesting feedback we got from our last issue -- On-Site Searching. The neat thing about an email newsletter is that we can be more flexible with the format and therefore make it more interesting for you. Second, we have a special invitation that we're only making to UIETips readers. We're in the throes of putting together a new course on web site design. A one-day version has already been accepted to the CHI conference in L.A. this spring. We're currently considering adding a two-day version to our existing course schedule. Our special invitation is to participate in the design of this course. The details are below, but if you're in the Greater Boston area and want to get a sneak preview of the course, plus contribute to its design, then we've got a deal for you. On a different note, it is time for us to say goodbye to Sandy Spector. Sandy is our latest intern and has been a tremendous amount of help in our most-recent web studies. Sandy was responsible for designing, administering, and collecting the hundreds of data elements that we've been analyzing for the past couple of months and her output will keep us busy for many months to come. Her hard work and diligence has been exceptional. Without her help, we would not have any of the interesting facts that we've recently identified about searching, savvy, links, or the scent of information. This week she's putting the finishing touches on her work and now its our turn to translate her efforts into the reports you'll be seeing. The internship was through the Massachusetts Software Council Fellowship Program. This program places talented people who have been caught in the down-sizing or right-sizing activities of today's world into positions that allow them to get experience in the software industry. We have been exceedingly fortunate to have gotten the cream of the program's crop, and will continue to use the program in the future. We are sad to see Sandy leave us. It is unfortunate that our limited resources, as a small consulting firm, do not let us do what we want to do. She is currently looking for opportunities and we wish her the best of luck in the future. (Sandy can be reached at sspector@uie.com.) Jared _______________ Feature: Internet-Savvy Users One of the biggest surprises that has come out of our most recent study has to do with Internet Savvy. As we brought users in to watch them work with the web, we asked them all sorts of questions about the Internet. From their answers to these questions, their previous web experience and their comfort level with using the web, we came up with a measure we call "Internet Savvy." Based on our previous work, we had hypothesized that those with the most Internet savvy would do the best at finding answers. One reason was from the users themselves: in previous studies, users with little Internet experience always told us that if they had more experience, they would have done better. The second reason was from the web designers we'd been sharing our result with: They always ask if we were testing novices or experienced web users. Based on these comments, we thought we should measure to see if savvy made a difference. It doesn't. Our findings show that there was no correlation between the user's Internet savvy and the number of tasks they successfully completed in our scavenger hunt studies. If there was a difference, we should have seen a positive correlation. Finding no correlation means that just because you've been active on the web, it won't help you find the information you're looking for. >> Defensive Mechanisms We did observe that people who had more web experience behaved differently from their less-experienced counterparts. They had developed behaviors we've dubbed "Defensive Mechanisms." We saw several users independently show the same behaviors. The users who demonstrated these behaviors were all more Internet savvy than users who didn't. Internet savvy users were more likely to: * Scroll all the way to the bottom of a page when viewing it for the first time * Look for a link back to the home page * Look at the status bar to determine where a link led * Use the GO menu to return to an earlier page * Read search tips * Use Edit|Find to search within a page We believe that experienced users evolve these behaviors as a sort of defensive reaction to their experience with other poorly designed sites. For example, one user told us, "I've learned to scroll down, take it all in, before deciding what to click. Look before I leap." However, the defensive mechanisms didn't help: these users had just as much trouble completing tasks as users who hadn't learned these tricks. >> Two Other Differences While we didn't find any correlation between Internet savvy and success, we did find correlations between Internet savvy and two other sets of variables: 1. Critical of Looks Our study showed that Internet savvy users are considerably more likely to be critical of a site's appearance. They consistently rated sites' appearances worse than non-Internet-savvy users. This is probably because Internet-savvy users have seen more sites and have a better point of reference than non-Internet-savvy users. But they were very even-handed in their criticism. They were more critical of *all* the sites, not just the ones that they succeeded less with. Therefore, it may be a mistake for site designers to base their priorities solely on critiques from experienced users, without knowing if the improvements will actually make the site better. 2. Disenchanted with the Web The more experience people have with the Internet, the less likely they are to perceive it as a good place to find information. After each task, we asked the users, "How would you have answered this question if you didn't have web access?" Users who were more Internet savvy were more likely to suggest other non-web venues for finding the information. Our theory is that experienced web users realize the faults of the web. They've developed a "network" of non-web resources to locate information effectively. This tells us that they are more realistic in their expectations of web sites. And even though they weren't any more likely to give up on the tasks we asked of them, in real usage they might be more likely to stop using the web and use a different resource to find the answer. >> Designing For Users The good news is that designers don't have to consider whether their users are savvy or not, and don't have to come up with two designs if they have some of each. But if Internet savvy doesn't make difference, what does? In future issues of UIETips, we'll discuss the other two variables of user experience: how often they've been to the site before and how much they know about the content's domain areas. _______________ Resources: Web Site Usability Report, Eye For Design, www.uie.com In the process of doing our work, we collect a tremendous amount of information on what makes products and web sites usable. Here are three resources that we've made available: Report: Web Site Usability: A Designer's Guide It's commonly accepted that graphics, color, and white-space are among important elements of a successful web site. However, it turns out that this may not be the case after all. This report sets those ideas on their head. "Web Site Usability: A Designer's Guide" is a 155-page report based on our observations of the struggles and successes of more than 50 users as they searched for information on nine popular web sites. (To get a sample chapter and ordering information, send mailto:web@uie.com with the words "SEND CHAP-1" in the subject of the message.) Eye For Design If you like what you read on UIETips, you'll love Eye For Design, our bi-monthly newsletter containing tips and techniques for developing excellent products and web sites. You'll read about the latest research we've done on how to build usable applications. (For a complimentary issue, send your postal address to mailto:efd@uie.com.) http://www.uie.com Here, you'll find articles on many things, including how tabbed dialogs can get designers into trouble, using paper prototypes to manage risk, how to spoon-feed conceptual information using tips and hints, and a new comprehensive UI bibliography from Chauncey Wilson of WilDesign Consulting. _______________ Letters from Readers: On-Site Searching In the 10/23/97 issue of UIETips we presented our findings that users who didn't use a site's search engine were 50% more likely to succeed than those who did use the search engine. Based on these findings, we suggested that if you want users to find information on your site, you should keep them away from your search engine. Here's what we heard from readers [edited for space purposes]: * * * * * From Wayne Douglass >At this point, based on this information, our recommendation is for >site designers to focus on making the long way -- the links of the >site -- work effectively for users. Interesting data, unsupported conclusion. As the author of a "Search Tips" online guide for the Verity search engine, I agree that average users certainly don't have searching savvy, and I tried to overcome their ignorance with my tips. Rather than simply go through the operators, I discuss operators relevant to tasks (expanding a search, narrowing a search, using fields (like author) or zones (like headers) to search, etc). (I even have a one word search that will certainly bring up the most relevant hits with the least noise using ANY Internet search engine. Looking for sites discussing early motion picture technology? Enter "zoopraxiscope." Try it.) The simple fact is that searching is a Zen discipline. If you already know the answer, you can formulate the perfect query. We are all seekers, Jared. "What is the sound of one hand clapping" is just another query. The journey is the reward and it begins with the first step, but if you meet the Buddha on the road, kill him. --Wayne --------------------------------------------- Wayne Douglass Verity, Inc. mailto:wayned@verity.com http://www.verity.com "Connecting People With Information" --------------------------------------------- * * * * * From Duncan Sanderson Quite interesting issue on web links, search strategies, etc. re "how users' previous experience and knowledge affect site navigation" I think this is a key question, and can be asked also for the searching capabilities (although you have a few observations about this). The related question I would like to see asked is the extent to which socio-economic background affects information finding capabilities, and site navigation. If you have (or had) a cross section of users, and information on their schooling levels (and perhaps jobs or not), you could do some tabular analysis with your data. You may not have "representative users" but I'll bet you could provide some preliminary and interesting findings. This then starts addressing some very interesting issues about whether the web will be "accessable" to certain social groups, and what designers may need to do to make it more so (although possible design options would also have to be tested with users). Regards, Duncan Sanderson * * * * * From Fred Holtzman >Search engines didn't make finding information easier, they made it >harder. When users found information without a search engine, they >did 50% better than when they tried to use a search engine. I would add a 5th [reason users have trouble with searching] - knowing the right words to use to find something. For example I want information on double-spacing. Do I enter: 1) double 2) spacing 3) doublespacing 4) double-spacing * * * * * From John Springer >Users didn't seem to understand what a full-text search is. The >dynamics of full-text searches are different than looking something >up in an index, but users didn't seem to grasp this. Long ago, I realized that most of the documents on my sites are just the same words arranged differently, and therefore a full text search was probably useless. I've stuck with hierarchical indexing and searching for keywords. John Springer---- * * * * * From Cheryl Ward I am a reference librarian and indexer. Yes indeed, the results of the trial searches are interesting. As you may know, some interesting research has been done on what it takes for people to continue or give up as they search for info - mostly paper sources in libraries, I think. I learned boolean searching in programming classes in college but don't remember much about it being taught in library school, when I got my masters. While working the reference desk at a local university, people would look at me like I was crazy when I suggested changing search terms to plurals. I always demonstrated simple techniques like that when giving library tours. It seems like there is a great need for some kind of standardization. For example, when libraries buy non-print resources from different vendors, vocabularies are often just different enough to drive searchers nuts. Of course being a librarian, my suggestion would be to avoid reinventing the wheel by using Library of Congress subject headings. There are some problems with that, though. Oh and don't EVEN get me started on the lack of any kind of logic or standard between all the sites provided by government agencies. YIKES! Cheryl Ward Continental Divide Editorial Services _______________ 1998 Course Schedule We've finalized our course schedule for 1998. All of these courses will be held at the Holiday Inn Andover/Tewksbury in Tewksbury, MA. Product Usability: Survival Techniques January 21 May 18 September 21 Techniques for Complex Applications January 22 May 19 September 22 Product Usability for Documentation Professionals June 15 & 16 November 16 & 17 Descriptions of each of these courses can be found at http://www.uie.com. If you don't wish to wait or come to Massachusetts, we can bring the course to you. Last year, we brought these courses to dozens of companies. It's a perfect way to get everyone in your group on the same page. If you are interested, give us a call at (978) 975-4343. _______________ Area Code Change Along with millions of others all over the country, we've been hit with an Area Code change. Our new phone number is (978) 975-4343. Our new fax number is (978) 975-5353. Our email is the same at uie@uie.com. _______________ New Course: Web Site Usability: Designing With Your Eyes Open We're currently working on a new course for 1998 based on our research into the design of web sites. Whenever we develop a new course, we hold a "rehearsal" of it, where we present it to 15 or so people for free, in return for their feedback. Everybody wins - we learn how to make our courses better, and you get the opportunity to hear our latest stuff, for free. We're still looking for a location for the rehearsal. If you have a facility that can hold 18 folks with 5 or 6 computers already hitched up to the Internet, we'd love to borrow it for a day. All we need is an Internet browser for our exercises. There will be no charge to attend the rehearsal, but it ain't free: we'll expect you to give us lots of feedback on how we're doing and what we could do better. Our tentative dates are 12/16 or 12/17, depending on the availability of the facility. If you think you'd be interested, please send mail to rehearsal@uie.com. We'll contact you as soon as we have more information. (The offer is limited by space, so you'll want to contact us right away.) _______________ UIETips Subscription Information To remove yourself from the list: Send the word UNSUBSCRIBE in the body of a message to UIETips-Request@uie.com. To add yourself to the list: Send the word SUBSCRIBE in the body of the message to UIETips-Request@uie.com. Questions? Send mailto:Tips@uie.com. (c) Copyright 1997 User Interface Engineering 800 Turnpike Street, #101 North Andover, MA 01845 Phone: (978) 975-4343 fax: (978) 975-5353 http://www.uie.com mailto:uie@uie.com -- End -- ========================================================== Jared M. Spool User Interface Engineering mailto:jspool@uie.com 800 Turnpike Street, Suite 101 (978) 975-4343 North Andover, MA 01845 fax: (978) 975-5353 USA http://www.uie.com If you send me your postal address, you'll get the next issue of our newsletter, Eye For Design. ==========================================================