will study other applications and learn how to find the structure in them. Why
study other web applications? Studying other designs improves our design skills.
UIE REPORTS FUNDAMENTALS SERIES
THE DESIGNER’S GUIDE TO
WEB APPLICATIONS PART I:
STRUCTURE AND FLOWS By Hagan Rivers, Two Rivers Consulting
FREE CHAPTER
User Interface Engineering User Interface Engineering
510 Turnpike Street, Suite 102
North Andover, MA 01845
(978) 327-5561 or (800) 588-9855
www.uie.com
The Designer’s Guide to Web Applications
Part I: Structure and Flows
SKELETONS
Table of Contents 1 Skeletons ....................................................1 1.1 The Hub ...................................................2 1.2 A Hub With No Data .................................5 1.3 The Interview ...........................................7 2 A Real Application: SupportSuite ..............9 2.1 A simple hub and spoke—or is it? ...........10 2.2 An interview appears! ............................12 2.3 Hubba hubba .........................................13 2.4 A hub for hubs .......................................16 2.5 Finishing touches....................................17 3 Revealing Structure in the Design ..........19 3.1 Tabs ......................................................21 3.2 Menus ...................................................23 3.3 Tab Menus .............................................26 3.4 Breadcrumbs ..........................................29 3.5 Links......................................................32 3.6 Titles .....................................................36 3.7 Progress Indicators .................................37 3.8 Knowing which element to use ................39 4 Designing the structure ...........................40 4.1 Command Architecture ...........................40 4.2 Seeding the structure ..............................41 4.3 Enter the users .......................................42 4.4 As we learn more, more changes .............44 4.5 There are many possible structures ..........48 5 Creating a Winning Design ......................49
©2006 User Interface Engineering. Reproduction Prohibited
1 SKELETONS The structure of an application is like a human skeleton--it forms the basis of the whole body, yet it’s hidden from view. Just as muscles and skin hang on a skeleton, every bit of text, every button, every list, and every link hang upon the application’s structure. When we, as designers, sit down to decide how many screens to build, we are designing the structure. When we determine the items and the commands appearing on each screen, we are again designing the structure. This report will help you understand how to create your application’s structure and how to “hang” your design on a structure, just as muscle and skin hang on a skeleton. We will study other applications and learn how to find the structure in them. Why study other web applications? Studying other designs improves our design skills. Each application we study will teach us more about design. We’ll learn how to identify the application’s structure. We’ll recognize similarities in how different applications solve the same design problem. We’ll see the design chosen for a given structure. We’ll also begin recognizing patterns in the designs. Whether or not we formally write down these patterns, over time we’ll remember them. Then, when we see a design problem, we’ll draw upon all the applications we’ve seen before to weigh different design solutions. With all that in mind, let’s get started.
www.uie.com
1
Part I: Structure and Flows
The Designer’s Guide to Web Applications SKELETONS
1.1
THE HUB There are two basic forms of application structure designers use repeatedly: the hub and the interview. The most common structure is a hub. Literally speaking, the hub is the center of a wheel. On a wagon wheel, there are spokes that radiate outward. In a web application, a hub is a center of activity—a place from where all activities radiate, like spokes. Let’s take a look at a very simple application—in this case, a list of stuff™ (have you ever noticed how there is always a list of stuff?) and see this in action: Figure 1-1: A list of employees——a simple hub
Figure 1-1 shows a simple application listing a small company’s employees. The list here shows employee Name, employee ID number, and the employee’s Location. We can see from the Location column, the company has offices in four locations in Massachusetts. When studying an application’s structure, we try to see past the details and visual style of the design and focus instead on the more abstract elements. In this case, there is a list of employees and there are some commands. For now, it doesn’t matter whether the commands are links in a browser window or buttons in a desktop application when we’re studying structure. However, it will matter a great deal later, when we turn the structure into a design.
Above the data is a row of commands, arranged as a toolbar: Add, Delete, Import, Export, and Send Mail. There are some additional commands embedded within the table itself. For example, clicking on a name is equivalent to Edit. Clicking on ID in the table header will sort the table by ID and clicking on Location will sort the table by location. Finally, notice the table contains checkboxes for selecting employees. Users must select one or more checkboxes before they can use the commands for Delete, Export, and Send Mail.
2
www.uie.com
©2006 User Interface Engineering. Reproduction Prohibited
The Designer’s Guide to Web Applications
Part I: Structure and Flows
SKELETONS
When the user clicks on the Add button, a new screen opens, the Add Employee window (shown in Figure 1-2). Here users can type information for a new employee and then save it by pressing the Add button at the bottom.
Figure 1-2: Clicking on the Add button opens Add Employee screen
This new screen has just become the first spoke of our application’s wheel. The hub, Employees, lies at the center of the wheel and users access spoke screens, like Add Employee, from the hub. When users finish working on the spoke screen, they return to the hub. You may have noticed we’ve used the word “screen” here to describe both Employee List and Add Employee. In Figure 1-2, we’ve shown them in two boxes side by side. Does this mean we have two side-by-side browser windows open? Or, are we suggesting Add Employee will replace the Employee List within the same browser window? Or, does the design intend to show the Add Employee screen using AJAX, layers, and Dynamic HTML, thereby covering the Employee List like a dialog window? From the standpoint of the application’s structure, these are identical. It doesn’t matter which technology you use to display the “screen” containing the Add Employee information. This screen is a spoke. It can appear in a new window, a new layer, or dynamically within the existing window. However, structurally speaking, it is different from the Employee List and that’s all we need to know for now. We’ll talk more about converting the application’s structure into a design later on.
©2006 User Interface Engineering. Reproduction Prohibited
www.uie.com
3
Part I: Structure and Flows
The Designer’s Guide to Web Applications SKELETONS
You can see a diagram of the screens in Figure 1-3. In a stunning bout of creativity, we’ll call this a structure diagram. At this point the structure diagram doesn’t really look like much of a hub–more like an atom of hydrogen, but once we add in the other screens (Import, Export, Send, and Delete) to the diagram in Figure 1-4, then perhaps you’ll agree it starts to look a bit more like a wagon wheel. Figure 1-3: Employees lie at the center of the hub and Add is a spoke screen
What is a structure diagram and why do we use it? We like to use these diagrams as shorthand for visualizing the structure of our designs. It’s a quick and easy way to communicate structure among our team members and to help everyone focus on the key parts of the design—the hubs.
Figure 1-4: The screens for this application form a hub and spoke-style wheel
You’ve probably noticed we haven’t said anything specific to web applications. Is the application we’ve been looking at a web application? It turns out hubs are a core element of any software application design, be it on the web or the desktop. We could implement this list of employees as either a desktop or a web-based application and, structurally speaking, they would be identical. You shouldn’t limit yourself to studying the structure of only web-based applications.
4
www.uie.com
©2006 User Interface Engineering. Reproduction Prohibited
The Designer’s Guide to Web Applications
Part I: Structure and Flows
SKELETONS
1.2
A HUB WITH NO DATA As you might imagine, it’s very common to form hubs around lists of information. However, hubs do not need to contain lists, nor do they need to contain any data at all. Here’s another application—this time we have a hub where users can manage their account information.
Figure 1-5: A list of commands can also form a hub
On the left in Figure 1-5, we have the center of the Hub—Your Account. Unlike the previous example, this screen has no list. There isn’t a list anywhere on this screen—no employees, no account items, nothing. Instead, it contains a series of commands. In this figure, our user clicked the command, Change password, opening a spoke screen. To the right, you can see a structure diagram of this hub and all of its spokes. Voila! This hub even looks like it might hitch to a wagon. We’ve stripped these examples of their context and visual style to make it easier to understand the hub structure. Most web applications are much more complex than the examples shown here. No matter the complexity, you’ll probably find they consist of a series of hubs. Hubs are incredibly powerful. You can string them together to build large, highly complex applications. Let’s explore what stringing hubs together might look like. We’ll go back to the last hub and add a new section to the top, calling it Manage Lists. Then, we’ll make the first item Employees. You can see what we have done in Figure 1-6.
©2006 User Interface Engineering. Reproduction Prohibited
www.uie.com
5
Part I: Structure and Flows
The Designer’s Guide to Web Applications SKELETONS
Figure 1-6: Add a link for Employees to the Account screen to tie two hubs together
Clicking on Employees in Figure 1-6 brings up the Employee list. Remember this screen? This is the first hub we analyzed in Figure 1-1. So now, we have strung two hubs together to build a more complex application.
Figure 1-7: Hubs allow us to build large, complex applications
Figure 1-7 shows our new diagram, with the Account hub and the Employee List hub connected together. Our application can keep growing (and growing and growing) by connecting more and more hubs together. It’s typical to see a web application tie dozens of hubs together.
6
www.uie.com
©2006 User Interface Engineering. Reproduction Prohibited
The Designer’s Guide to Web Applications
Part I: Structure and Flows
SKELETONS
1.3
THE INTERVIEW We discussed at the start of the report how application designers use two structures when building web applications. The hub allows us to group functionality into a logical structure. The other structure groups the functionality into a less complex, more approachable design, which we call an interview. The interview follows a step-by-step workflow, collecting information a little bit at a time from the user. Let’s go back to our Employee list and take a closer look at the Export command.
Figure 1-8: When users click Export, they start an Interview.
When users click Export, they see a screen labeled Export: Step 1. This is the beginning of an interview. Here the application asks whether to export all employees or just the selected ones. At the bottom are three commands: Cancel, Back, and Next. The Back command is not available because this is the beginning of the Export interview. Cancel cancels the entire Export interview. Next takes users to the next step in the interview.
Figure 1-9: The entire Export interview
Figure 1-9 shows the entire interview. During this particular interview, users may freely move back to questions they had previously answered, or click Next to see the next question. Only at the end of the last step in the interview will the export take place. Notice on the final screen, Step 4, the Next button changes to read Done.
©2006 User Interface Engineering. Reproduction Prohibited
www.uie.com
7
The Designer’s Guide to Web Applications
Part I: Structure and Flows
SKELETONS
You have almost certainly encountered many interviews—for installing software, completing an online purchase, or perhaps even paying taxes. Interviews break down complex processes into more manageable steps. Not all interviews work exactly like this one—in some, for example, there may be many questions per page. In others, the user can’t go back to change a previous answer. An interview might not wait until the very last step to make some changes or save information the user has entered. The details will vary a great deal from one application to another. Let’s update the structure diagram to show our new export interview: Now instead of a single circle, a 4-screen process (shown in Figure 1-10) represents Export. Users start at Step 1, go through the screens in order, and after Step 4, return to the hub. Figure 1-11 shows a shorthand version you may want to use to save space when you are drawing your own structure diagram.
Figure 1-10: Our diagram with the Export interview
Figure 1-11: Shorthand in the structure diagram
This interview was a rather simple one. No matter what answer the user gave to the question on Step 1, he would see the next question on Step 2. Interviews can be large and complex with branching pathways depending on the user’s situation or answers. In addition, we can combine interviews, just as hubs can, to build structures that are ever more complex.
So now we’ve learned about two structures—the hub and the interview. Is that really all there is to it? Well, yes and no. These structures form the basic structure of applications. Think of them as Lego™ building block pieces. Each piece is very simple. However, they can be put together to create astonishingly complex creations. Similarly, it can be difficult to decide how to piece together hubs and interviews to build an application. Translating them into a real-world design is a long process. Nevertheless, we need to identify and use these structures to build applications that will be easy for users to learn and live with. So let’s look at some real world applications and see if we can decode the structures they use.
8
www.uie.com
©2006 User Interface Engineering. Reproduction Prohibited
Part I: Structure and Flows
The Designer’s Guide to Web Applications
WOULD YOU LIKE TO LEARN MORE?
Buy the complete 54-page report today at www.uie.com/reports/ THE DESIGNER’S GUIDE TO WEB APPLICATIONS, PART I:
STRUCTURE AND FLOWS
By Hagan Rivers, Two Rivers Consulting Hagan Rivers, a pioneer designer of web applications, has written a comprehensive, 54-page report that deconstructs some of today’s most complex web applications. In this report, she’ll walk you through the design techniques employed by Amazon.com, Microsoft Money, Yahoo! Mail, Shutterfly, and Blogger, among others. In this report, Hagan gives you step-by-step guidance through the process of creating successful web applications. You’ll learn: •
How to build your application's structure diagram. Hagan will explain how to use structure diagrams as shorthand for visualizing your designs. Structure diagrams help you communicate your application’s structure with your team members and to help everyone focus on the key parts of the design.
•
How to identify the two basic forms of application structure: Hubs and Interviews. The two most common structures found in web apps, Hubs and Interviews are essential components in your toolkit. You’ll get a comprehensive introduction to these two components, with several examples showing you when to use each type of structure.
•
Which design elements to use. Hagan will show you where and when to use tabs, menus, breadcrumbs, links, and titles in your application. She’ll go over the strengths and drawbacks of each element.
•
How to build your application's Command Architecture. When you design the organization of an application, you’re building a Command Architecture, a hierarchy of hubs and interviews reflecting each command in your application. Hagan will show you how to build your architecture, step-by-step.
DID YOU KNOW… •
An application can have multiple designs and underlying structures that accomplish the same goal. Design teams must weigh the advantages and disadvantages of each to see which most closely match the needs of your users.
•
Menus can save you space, yet tabs make your hubs visible. Tab Menus give you the benefit of both tabs and menus, while breadcrumbs help communicate the relationship of different application components. Knowing which elements to choose is a critical design task.
•
Creating structure diagrams is a quick and easy way to get all members of your design team on the same page when developing the structure of your design. You can save time, energy, and frustration by utilizing these handy illustrations.
•
Conducting field studies and usability tests are two of the best ways to get to know your users. Watch them in their natural environments performing various tasks or have them try out your previous designs to get a sense of how they will interact with your new product.
LEARN MORE AT WWW.UIE.COM/REPORTS/
www.uie.com
©2006 User Interface Engineering. Reproduction Prohibited
