 |
 |
forUse Newsletter Archives | |||||
 |
 |
||||||
 |
|||||||
|
|
|
forUse Newsletter Archives | |||||
|
|
|
||||||
|
|
|||||||
 |
forUse: The Electronic Newsletter of Usage-Centered Design #22 | June 2002 |
|
 |
||
| Subscribe! |
   |
|
|
Contents: || 1. Events: Discounts Available, Get ‘em While They Last. || 2. Technique: Conflicting Needs, Convergent Design || 3. Design: Submit Gracefully. E-Commerce Forms. || 4. Training: Master Class for Experienced Designers. = = = = = 1. forUSE 2002 Discounts Still Available. This month is your last chance to take advantage of significant early-bird discounts to attend the forUSE 2002 Conference. Early-bird discounts of $200 on conference registration and $100 on tutorials end 30 June. The conference is a chance to learn first-hand from the leading thinkers and doers of usage-centered design. Real-world experience and the latest techniques and ideas are brought together for a one-time opportunity to take your skills and knowledge to the next level. Eight focused threads will cover a range of topics, including: * Agile Methods and Techniques (5 sessions) For a quick overview of the entire program, check out the various topical threads at www.foruse.com/2002/schedule.htm. SPACE IS LIMITED, which is another reason to book early. Registrations are already coming in and you do not want to be disappointed. Tell your colleagues about the conference and they will thank you! 2. User Needs versus Business Goals We have long argued that task support for the genuine needs of users should drive the design process, but that is not the whole story. The plot thickens when designers and decision-makers must consider other needs and priorities--which they always must--and when conflicting needs or competing goals pull the design in different directions--which they always do. Some of the biggest challenges are when the needs of the users and the needs of the business are directly at odds. We recently got a chance to relearn how tough the tradeoffs can be when we redesigned our Web site. To kick off the process, we re-examined the mission of the site. We are in the usability business--as designers, as consultants, and as trainers. We also provide a service as a major information resource for others in the usability business. We like to think there is a synergy in this dual mission and to believe that you and we are partners in a creative conspiracy to give people better tools through better design. Taking our own best advice on model-driven design, we constructed a complete task model based on the roles played by visitors to our site. The final model included 20 task cases, such as T01 subscribing to newsletter (that would be this one), T04 getting information on conference(s) (forUSE 2002 anyone?), or T07 browsing material on particular topic(s). We printed our complete inventory of task cases onto index cards, and then each of us independently sorted the stack of cards into order: first by expected frequency, then importance to users, and finally importance to our business goals. We were in fairly good agreement on all three rankings; concordances ranged from 0.638 to 0.877. (You’ll find a template to do the math for you at www.foruse.com/resources/tools/.) Our combined rankings for expected frequency and user importance were also strongly correlated, as expected, and checked out against data from accumulated site logs. The conflicts showed up when we studied user importance versus business importance. The most frequent task case--T10 getting specific (known) material--was also ranked most important to users, but it ended up rock bottom last in terms of business priorities. This task is certainly not irrelevant to us, but its low business priority reflects a subtle conflict. The conflict arises because users who want a particular document and know exactly what they are looking for expect to be able simply to grab it and go. As usage-centered designers, we can respect that intention and should do our best to support it. After all, our site is intended to be an information resource serving practicing designers and developers, not to mention our esteemed academic colleagues and the occasional passing student. The problem is that hit-and-run visitors never learn about what else we have to offer, which is part of the business agenda. We had been aware of the phenomenon at a certain level for some time. Site statistics had shown that many of our “unique visitors” (that’s you) have clicked on a link somewhere (and there are thousands of links to the site) and downloaded a .PDF file (as 160,000 of you have done with the paper on use case structure and style). That’s it, the extent of the “visit.” There is no chance for us to say, “But wait, there’s more!” The horns of this dilemma actually hurt both ways, because the new visitor who never takes a look around is missing out on a lot of goodies. Convinced that we could have our cake and serve it too, we persisted in trying to find a solution that would truly support both the needs of our users and our business interests. We considered and sketched out a number of ideas before deciding to introduce what we initially thought of as a “wrapper,” a layer of HTML wrapped around each .PDF file. We coined a new term after we started thinking through the content and function of this layer. What possible purpose does such a layer serve for the user? Is it only a barrier in business disguise or does it have some value? In answering these questions, we found the point of intersection between user needs and business goals. We eventually realized that we were re-inventing for the Web what amounted to the cards in a library card catalog, so we now think of them as cataloging pages. We designed each cataloging page to be usage-centered and to support key extensions to the base task by providing several things of direct relevance to a user who has the intention of “getting specific (known) material.” In compact form, each cataloging page provides content that facilitates users deciding not to get the material or choosing other material instead of or in addition to the original target. File size, a revision history, and a short abstract for quick review help users decide whether they really want to download the complete paper, which can run over 1MB for some of the graphic-heavy files. A user impatiently drumming the table during an unexpectedly long download over a dial-up connection is not a happy potential colleague or client. Most importantly, the new cataloging pages point to related material, including newsletter articles, other papers, and more recent revisions or recantations. Click-through and page-view statistics confirm that referred (link-following) visitors are viewing more pages and typically end up downloading more material, both by following “related material” links in cataloging pages and by backtracking to the catalog page that lists all available materials. What can other designers take away from this somewhat specialized exercise? We think there are three main points. (1) In considering a design approach driven in whole or in part by business objectives, think about what the content and functions mean to users. (2) Look for ways that the content and functions can provide genuine user benefits in the process of supporting business objectives. (3) Pay particular attention to easily overlooked extensions and exceptions to the basic task cases. In our case, this line of reasoning highlighted a missing task case that had previously been only implicit in our model, namely, getting/finding related material. This task case is important from both business and user perspectives and ended up playing a central role in the organization of the new site. What do you think? If you have not already seen our cataloging pages, just click on any article of potential interest at www.foruse.com/publications/. And please give us feedback on the Web site (www.foruse.com/forms/feedback.htm). 3. Submit Gracefully The devil dwells in the details. The late Steven J. Gould, with his witty penchant for the profound and the provocative, preferred to turn the old saw on its head by saying that God dwells in the details. When it comes to usage-centered design, either perspective works--both the peril and the promise lie in those blessed details. However, as Lucy Lockwood often admonishes, good design is more than just details; it’s details, details, details! Getting the details right means carefully thinking through myriad seemingly small matters--always from the point of view of the user. Without dogged attention, small details can come back to bite the hand that designed them. Consider the Web’s humble and ubiquitous “Submit” button. In a sense, the Submit button makes e-business possible. Without it, customer orders would never be received, feedback would never arrive, and credit cards would never be charged. However, the Submit button is a also frequent point of failure in e-commerce that leads to perplexed or irate customers and lost sales. In its standard form, it looks like this in HTML: <input type=”submit” value=”Submit” /> The problems begin with the label on the Submit button, which HTML in its perversity calls its value. On all too many sites the button just reads “Submit” when to the user it really should say “Order Now” or “Bid” or “Buy Tickets.” The button should say what it means to the user. In addition, a pop-up screen tip should give the hesitant user an informative and re-assuring explanation. The problems continue with the interaction design. The default behavior of the standard HTML Submit button has several major problems. First, every time the user clicks it, a new set of data is sent to the CGI script that processes the form. In case the problem is not abundantly clear, consider the following all-too-familiar sort of message. “IMPORTANT: Click on the Submit button ONLY ONCE. Please wait. Processing may take several minutes. Do NOT click the Submit button again or you may receive and/or be charged for duplicate orders.” Why is the user being told what not to do when it’s the program’s responsibility? Another problem is that the standard Submit button intercepts the <Enter> key, so that the user who ends a text entry by hitting <Enter> may find the form has vanished only to be replaced by an error message that it was incomplete. The programmer-oriented solution to this, which has actually been packaged as a standard component for sale, is a JavaScript that intercepts the user action and asks “Did you really want to submit the form?” So, how should a Submit button behave if it is designed for use? What does the user expect? First, if double-clicks are a problem, the Submit button should be disabled the moment it is clicked. Because users won’t know what is happening, they should be informed that their form--whatever it may be--is being processed and they need to wait. This means the form should display a message along the lines of, “Please wait while we process your order.” A pop-up message box that requires confirmation is NOT the way to deliver the information; it simply annoys users and imposes another action that to users is unnecessary. As in many cases, the place to inform the user is in context, near the button that triggered the forms processing. As it turns out, the programming to correct both these problems--double-clicking and accidental <Enter> key--in the same button is so straightforward that one wonders why Web developers continue to deliver faulty forms or lame fixes. A small part of the fault lies with lazy programmers who take the easiest way out and just use the default HTML Submit button without so much as a thought about its appropriateness to their application. However, the greater part of the fault lies with all of us as usability professionals for failing to pay attention to such details and for not telling our programmers that these things matter. If we pay attention and talk with our programmers, they will write something like this: <input type="button" value="Bid!" name="Submit" title="Submit this bid in auction." tabindex="6" onClick="javascript:validateForm();"> The difference between the inept standard and a usage-centered improvement is in those devilish details! 4. Advanced Usage-Centered Design Following the forUSE 2002 conference (http://foruse.com/2002/) Lucy Lockwood and Larry Constantine will be conducting a very special post-conference tutorial, a Master Class for experienced designers. Called “Pushing the Envelope,” this class will be a chance for interaction designers, information architects, user interface designers, and other usability professionals to take a critical look at their own work in order to take it to the next level. Register now for the conference and master class while early-bird discounts are still in effect. You can save $200 on conference registration and $100 on each tutorial through 30 June. =
= = = To unsubscribe, just click here to send email. |
||
| Subscribe! |
|
|
|
|
||