Iterative Design and Testing

Much has been made about the importance of design iteration. However, this is not just fine-tuning late in the development cycle. Rather, true iterative design allows for the complete overhaul and rethinking of a design, through early testing of conceptual models and design ideas. If designers are not prepared for such a major step, then the influence of iterative design becomes minimal and cosmetic. In essence, true iterative design allows one to "shape the product" through a process of design, test, redesign, and retest activities.

Evaluation and Measurement of Product Usage

Here, emphasis is placed on behavioral measurements of ease of learning and ease of use very early in the design process, through the development and testing of prototypes with actual users.

An Early Focus on Users and Tasks

More than just simply identifying and categorizing users, we recommend direct contact between users and the design team throughout the development lifecycle. Of course, your team needs training and coaching in how to manage these interactions. This is a responsibility that you can take on as you become more educated and practiced, yourself.

Though a goal should be to institutionalize customer contact, be wary of doing it merely to complete a check-off box on one's performance appraisal form. What is required is a systematic, structured approach to the collection of information from and about users. Designers require training from expert interviewers before conducting a data collection session. Otherwise, the results can be very misleading.

What A/lakes Products More Usable? - II

Going beyond user-centered design of a product, we should be paying Tn?n7n Vh n ^ USer experience in the entire cyde of user -nershfp of a product. Idea ly, the entire process of interacting with potential customers, from the initial sales and marketing contact through the entire duration of ownership through the point at which another product is purchased or the current one upgraded, should also be included in a user-centered approach In such a scenario, companies would extend their concern to include all prepurchase and postpurchase contacts and interactions. However, let's take one step at a time, and stick to the design process.

Numerous articles and books have been written on the subject of usercentered design (UCD) (for a list of our favorites, see the web site that accompanies this book, www.wiley.com/go/usabilitytesting). However, it is important for the reader to understand the basic principles of UCD in order to understand the context for performing usability testing. Usability testing is not UCD itself; it is merely one of several techniques for helping ensure a good, user-centered design.

We want to emphasize these basic principles of user-centered design:

« Early focus on users and their tasks
■ Evaluation and measurement of product usage
■ Iterated design

What A/lakes Products More Usable? - I

User-centered design (UCD) describes an approach that has been around for decades under different names, such as human factors engineering, ergonomics, and usability engineering. (The terms human factors engineering and ergonomics are almost interchangeable, the major difference between the two having more to do with geography than with real differences in approach and implementation. In the United States, human factors engineering is the more widely used term, and in other countries, most notably in Europe,

ergonomics is more widely used.) UCD represents the techniques, processes, methods, and procedures for designing usable products and systems, but just as important, it is the philosophy that places the user at the center of the process.

Although the design team must think about the technology of the product first (can we build what we have in mind?), and then what the features will be (will it do what we want it to do?), they must also think about what the user's experience will be like when he or she uses the product. In user-centered design, development starts with the user as the focus, taking into account the abilities and limitations of the underlying technology and the features the company has in mind to offer.

As a design process, UCD seeks to support how target users actually work, rather than forcing users to change what they do to use something.
The International Organization for Standardization (ISO) in standard 13407 says that UCD is "characterized by: the active involvement of users and a clear understanding of user and task requirements; an appropriate allocation of function between users and technology; the iteration of design solutions; multidisciplinary design."

Reason 5: Design and Implementation Don't Always Match

The design of the user interface and the technical implementation of the user interface are different activities, requiring very different skills. Today, the emphasis and need are on design skills, while many engineers possess the mind-set and skill set for technical implementation.

Design, in this case, relates to how the product communicates, whereas implementation refers to how it works. Previously, this dichotomy between design and implementation was rarely even acknowledged. Engineers and designers were hired for their technical expertise (e.g., programming and machine-oriented analysis) rather than for their design expertise (e.g., communication and human-oriented analysis). This is understandable, because with early generation computer languages the great challenge lay in simply getting

the product to work. If it communicated elegantly as well, so much the better, but that was not the prime directive. 

With the advent of new-generation programming languages and tools to automatically develop program code, the challenge of technical implementation has diminished. The challenge of design, however, has increased dramatically due to the need to reach a broader, less sophisticated user population and the rising expectations for ease of use. To use a computer analogy, the focus has moved from the inside of the machine (how it works) to the outside where the end user resides (how it communicates).

What is needed are methods and techniques to help designers change the way they view and design products — methods that work from the outside in, from the end user's needs and abilities to the eventual implementation of the product is user-centered design (UCD). Because it is only within the context of UCD that usability testing makes sense and thrives, let's explore this notion of user-centered design in more detail

Reason 4: Team Specialists Don't Always Work in Integrated Ways - II

Each development group functions independently, almost as a silo, and the final product often reflects this approach. The help center will not adequately support the user interface or it will be organized very differently from the interface. Or user documentation and help will be redundant with little

cross-referencing. Or the documentation will not reflect the latest version of the user interface. You get the picture.

The problem occurs when the product is released. The end user, upon receiving this new product, views it and expects it to work as a single, integrated product, as shown in Figure 1-3. He or she makes no particular

distinction among the three components, and each one is expected to support and work seamlessly with the others. When the product does not work in this way, it clashes with the user's expectations, and whatever advantages accrue through specialization are lost.

Even more interesting is how often organizations unknowingly exacerbate this lack of integration by usability testing each of the components separately. Documentation is tested separately from the interface, and the interface separately from the help. Ultimately, this approach is futile, because it matters little if each component is usable within itself. Only if the components work well together will the product be viewed as usable and meeting the user's needs.

Reason 4: Team Specialists Don't Always Work in Integrated Ways - I

Organizations employ very specialized teams and approaches to product and system development yet fail to integrate them with each other. 

To improve efficiency, many organizations have broken down the product development process into separate system components developed independently, For example, components of a software product include the user interface, the help system, and the written materials. Typically, these components are developed by separate individuals or teams. Now, there is nothing inherently wrong with specialization. The difficulty arises when there is little integration of these separate components and poor communication among the different development teams.

Often the product development proceeds in separate, compartmentalized sections. To an outsider looking on, the development would be seen as depicted in Figure 1-2.

Reason 3: Designing Usable Products Is Difficult

The desing of usable systems is a difficult, unpredictable endeavor, yet many organizations treat it as if it were just “common sense.”

While ,uch has been written about what makes somethings usable, the concept remains maddeningly elusive, especially for those without a background in either the behavioral or social scients.

When this book was first published in 1994, few systems designers and developers had knowledge of the basic principles of user-centered design Today, most designers have some knowledge of-or at least exposure to — user-centered design practices, whether they are aware of them or not.

However, there are still gaps between awareness and execution. Usability principles are still not obvious, and there is still a great need for education, assistance, and a systematic approach in applying so-called "common sense" to the design process.

Reason 2: Target Audiences Expand and Adapt

As technology has penetrated the mainstream consumer market, the target audience has expanded and continues to change dramatically. Development organizations have been slow to react to this evolution.

The original users of computer-based products were enthusiasts (also known as early adopters) possessing expert knowledge of computers and mechanical devices, a love of technology, the desire to tinker, and pride in their ability to troubleshoot and repair any problem. Developers of these products shared similar characteristics. In essence, users and developers of these systems were one and the same. Because of this similarity, the developers practiced "next-bench" design, a method of designing for the user who is literally sitting one bench away in the development lab. Not surprisingly, this approach met with relative success, and users rarely if ever complained about difficulties. 

Why would they complain? Much of their joy in using the product was the amount of tinkering and fiddling required to make it work, and enthusiast users took immense pride in their abilities to make these complicated products function. Consequently, a "machine-oriented" or "system-oriented" approach

met with little resistance and became the development norm.

Today, however, all that has changed dramatically. Users are apt to have little technical knowledge of computers and mechanical devices, little patience for tinkering with the product just purchased, and completely different expectations from those of the designer. More important, today's user is not even remotely comparable to the designer in skill set, aptitude, expectation, or almost any attribute that is relevant to the design process. Where in the past, companies might have found Ph.D. chemists using their products, today they will find high-school graduates performing similar functions. Obviously, "next-bench" design simply falls apart as a workable design strategy when there is a great discrepancy between user and designer, and companies employing such a strategy, even inadvertently, will continue to produce hard-to-use products.

Designers aren't hobbyist enthusiasts (necessarily) anymore; most are trained professionals educated in human computer interaction, industrial design, human factors engineering, or computer science, or a combination of these. Whereas before it was unusual for a nontechnical person to use electronic or computer-based equipment, today it is almost impossible for the average person not to use such a product in either the workplace or in private life. The overwhelming majority of products, whether in the workplace or the home, be they cell phones, DVRs, web sites, or sophisticated testing equipment, are intended for this less technical ^USer" ^Today ⁵ wants a tool, not another hobby.             

Reason 1: Development Focuses on the Machine or System

During design and development of the product, the emphasis and focus may have been on the machine or system, not on the person who is the ultimate end user. The general model of human performance shown in Figure 1-1 helps to clarify this point.

There are three major components to consider in any type of human performance situation as shown in Bailey's Human performance model.

■ The human

■ The context

■ The activity

Because the development of a system or product is an attempt to improve human performance in some area, designers should consider these three components during the design process. All three affect the final outcome of how well humans ultimately perform. Unfortunately, of these three components, designers, engineers, and programmers have traditionally placed the greatest emphasis on the activity component, and much less emphasis on the human and the context components. The relationship of the three components to

each other has also been neglected. There are several explanations for this unbalanced approach:
There has been an underlying assumption that because humans are so inherently flexible and adaptable, it is easier to let them adapt themselves to the machine, rather than vice versa.
Developers traditionally have been more comfortable working with the seemingly "black and white," scientific, concrete issues associated with systems, than with the more gray, muddled, ambiguous issues associated with human beings.
Developers have historically been hired and rewarded not for theater, personal, "people" skills but for their ability to solve techmcal proble
The most important factor leading to the neglect of human needs has been that in the past, designers were developing products for end users who were much like themselves. There was simply no reason to study
such a familiar colleague. That leads us to the next point.

Five Reasons Why Products Are Hard to Use

For those of you who currently work in the product development arena, as engineers, user-interface designers, technical communicators, training specialists, or managers in these disciplines, it seems likely that several of the reasons for the development of hard-to-use products and systems will sound painfully

familiar.

■ Development focuses on the machine or system.

■ Target audiences change and adapt.

■ Designing usable products is difficult.

■ Team specialists don't always work in integrated ways.

■ Design and implementation don't always match.

What Makes Something Less Usable?

Why are so many high-tech products so hard to use?

In this section, we explore this question, discuss why the situation exists, and examine the overall antidote to this problem. Many of the examples in this book involve not only consumer hardware, software, and web sites but also documentation such as user's guides and embedded assistance such as on-screen instructions and error messages. The methods in this book also work for appliances such as music players, cell phones, .and game consoles. Even products, such as the control panel for an ultrasound machine or the user

manual for a digital camera, fall within the scope of this book.

What Makes Something Less Usable?

Why are so many high-tech products so hard to use?

In this section, we explore this question, discuss why the situation exists, and examine the overall antidote to this problem. Many of the examples in this book involve not only consumer hardware, software, and web sites but also documentation such as user's guides and embedded assistance such as on-screen instructions and error messages. The methods in this book also work for appliances such as music players, cell phones, .and game consoles. Even products, such as the control panel for an ultrasound machine or the user

manual for a digital camera, fall within the scope of this book.

What Do We Mean by "Usable"? - IV

True usability is invisible. If something is going well, you don't notice it. 

If the temperature in a room is comfortable, no one complains. But usability in products happens along a continuum. How usable is your product? Could it be more usable even though users can accomplish their goals? Is it worth improving?

Most usability professionals spend most of their time working on eliminating design problems, trying to minimize frustration for users. This is a laudable goal! But know that it is a difficult one to attain for every user of your product. 

And it affects only a small part of the user's experience of accomplishing a goal. And, though there are quantitative approaches to testing the usability of products, it is impossible to measure the usability of something. You can only measure how unusable it is: how many problems people have using something, what the problems are and why. 

By incorporating evaluation methods such as usability testing throughout an iterative design process, it is possible to make products and services that are useful and usable, and possibly even delightful.

What Do We Mean by "Usable"? - III

Accessibility and usability are siblings. In the broadest sense, accessibility is about having access to the products needed to accomplish a goal. But in this book when we talk about accessibility, we are looking at what makes products usable by people who have disabilities. Making a product usable for people with disabilities —or who are in special contexts, or both —almost always benefits people who do not have disabilities. Considering accessibility for people with disabilities can clarify and simplify design for people who face temporary limitations (for example, injury) or situational ones (such as divided attention or bad environmental conditions, such as bright light or not enough light). There are many tools and sets of guidelines available to assist you in making accessible designs. (We include pointers to accessibility resources on the web site that accompanies this book (see www.wiley.com/ go/usabilitytesting for more information.) You should acquaint yourself with accessibility best practices so that you can implement them in your

organization's user-centered design process along with usability testing and other methods.

Making things more usable and accessible is part of the larger discipline of •. user-centered design (UCD), which encompasses a number of methods and techniques that we will talk about later in this chapter. In turn, user-centered design rolls up into an even larger, more holistic concept called experience design. Customers may be able to complete the purchase process on your web site, but how does that mesh with what happens when the product is delivered, maintained, serviced, and possibly returned? What does your organization

do to support the research and decision-making process leading up to the purchase? All of these figure in to experience design. 

Which brings us back to usability.

What Do We Mean by "Usable"? - II

Efficiency is the quickness with which the user s goal can be accomplished accurately and completely and is usually a measure of time. For example, you might set a usability testing benchmark that says "95 percent of all users will be able to load the software within 10 minutes."

Effectiveness refers to the extent to which the product behaves in the way that users expect it to and the ease with which users can use it to do what they intend. This is usually measured quantitatively with error rate. Your usability testing measure for effectiveness, like that for efficiency, should be tied to some percentage of total users. Extending the example from efficiency, the benchmark might be expressed as "95 percent of all users will be able to load the software correctly on the first attempt."

Learnability is a part of effectiveness and has to do with the user's ability to operate the system to some defined level of competence after some predetermined amount and period of training (which may be no time at all). It can also refer to the ability of infrequent users to relearn the system after periods of inactivity.

Satisfaction refers to the user's perceptions, feelings, and opinions of the product, usually captured through both written and oral questioning. Users are more likely to perform well on a product that meets their needs and provides satisfaction than one that does not Tvoicallv „c and rank products that they trv and ZT/ users are as» for problems that occur 'eveai causes and reasons product usable is never simply the abilitv  the numbere can tell us no there ,s a distinctive qualitative element to how usable somethine is a well, which is hard to capture with numbers and is difficult to pin down to do with how one interprets the data in order to know how to fix a problem because the behavioral data tells you why there is a problem. Any do tor

can measure a patient's vital signs, such as blood pressure and pulse rate 

But interpreting those numbers and recommending the appropriate course of action for a specific patient is the true value of the physician JudeinR the several possible alternative causes of a design problem, and knowing which are especially likely in a particular case, often means looking beyond individual data points in order to design effective treatment. There exist these little subtleties that evade the untrained eye.

What Do We Mean by "Usable"? - I

In large part, what makes something usable is the absence of frustration in using it. As we lay out the process and method for conducting usability testing in this book, we will rely on this definition of "usability;" when a product or service is truly usable, the user can do what he or she wants to do the way he or she expects to be able to do it, without hindrance, hesitation, or questions. 

But before we get into defining and exploring usability testing, let's talk a bit more about the concept of usability and its attributes. To be usable, a product or service should be useful, efficient, effective, satisfying, learnable, and accessible.

Usefulness concerns the degree to which a product enables a user to achieve his or her goals, and is an assessment of the user's willingness to use the product at all. Without that motivation, other measures make no sense, because the product will just sit on the shelf. If a system is easy to use, easy to learn, and even satisfying to use, but does not achieve the specific goals of a specific user, it will not be used even if it is given away for free. Interestingly enough, usefulness is probably the element that is most often overlooked during experiments and studies in the lab.

In the early stages of product development, it is up to the marketing team to ascertain what product or system features are desirable and necessary before other elements of usability are even considered. Lacking that, the development team is hard-pressed to take the user's point of view and will simply guess or, even worse, use themselves as the user model. This is very often where a system-oriented design takes hold.

What Makes Something Usable?

What makes a product or service usable?

Usability is a quality that many products possess, but many, many more lack. There are historical, cultural, organizational, monetary, and other reasons for this, which are beyond the scope of this book. Fortunately, however, there are customary and reliable methods for assessing where design contributes to usability and where it does not, and for judging what changes to make to designs so a product can be usable enough to survive or even thrive in the marketplace.

It can seem hard to know what makes something usable because unless you have a breakthrough usability paradigm that actually drives sales (Apple's iPod comes to mind), usability is only an issue when it is lacking or absent. Imagine a customer trying to buy something from your company's e-commerce web site. The inner dialogue they may be having with the site might sound like this: / can't find what I'm looking for. Okay, I have found what I'm looking for, but I can't tell how much it costs. Is it in stock? Can it be shipped to where I need it to go? Is shipping free if 1 spend this much? Nearly everyone who has ever tried to purchase something on a web site has encountered issues like these. 

It is easy to pick on web sites (after all there are so very many of them), but there are myriad other situations where people encounter products and services that are difficult to use every day. Do you know how to use all of the features on your alarm clock, phone, or DVR? When you contact a vendor, how easy is it to know what to choose in their voice-based menu o options?

Conclusion

Users’ expectations are on the rise. The web is aging and it needs to be revamped.

Now that there are several platforms that users resort to for different needs, with each platform having its own best-offerings, there is a need to converge such best-offerings of each platform in all other platforms whenever applicable to create an ideal and best-of-all-words. For example, there is no reason today why Rich Interactive Components (RIC) such as accordion, carousel, wheel, wall, dock, parent-child panels, configurators, mixers, selectors, and the like, which have been historically available on the desktop, should not also be available on the web.

Websites are morphing into full-fledged web applications of all types from enterprise applications to games. Such transformation requires a more thorough and disciplined approach to architecting websites beyond being online stores, or worse, online brochures. So far, web design has been page-centric suffering from the limitations of the browser and HTML. The websites of the future will be based on RIA platforms. They will have a broad architecture that covers content, functions, navigation, user interface, and system requirements to provide a minimum industrial robustness along with high usability and very rich user experience.

System Architecture

stage. Websites can no longer be considered as a set of interconnected webpages that can be managed by a document management system.

Like any application that requires a minimum level of industrial robustness, websites require a three-tier architecture that includes:

􀂃 A presentation tier that covers the graphical user interface with all its aesthetics and interactions. It allows users to retrieve and enter data.

􀂃 An object tier that covers all the algorithms related to business rules, data validation, work flow, etc. The modules of this second tier reside on a server machine, to assist in resource sharing.

􀂃 A data tier that includes all the static and dynamic content.

This three-tier architecture offers scalability, reusability, flexibility, manageability, maintainability, multi-threading, load balancing, fault-tolerance, recovery, security, internationalization, etc. Code, components, modules, and web services can be created, distributed, and used across the network as required.

Interface Architecture

the following parameters:

􀂃 Layout, which defines the location on a webpage where objects such as toolbars, forms, widgets, text, media players, buttons, sliders, and the like are placed.

􀂃 Aesthetics, which define the shape, style, colors, gradients, and textures of objects. Typically, it is highly desirable that the aesthetics match the properties of the company’s brand.

􀂃 Interactions, which define the colors, textures, gradients, sounds, animations, and special effects for:

o States including enabled, disabled, hovered, clicked, selected, or visited state. For example, an enabled button should be embossed to invite a user to click on it, while a disabled button should be engraved with fading colors to indicate its disabled status.

o Shapes including icons representing the different states of the cursor. For example, a cursor could be normally represented by an arrow which is transformed into a hand upon hovering over a hypertext or a hyperlink to indicate to a user that the text or the object is a link. Different shapes should be used for sizing, dragging, panning, etc.

o Actions including cut, copy, paste, drag, drop, size, collapse, expand, rotate, flip, slide, pan, scroll, etc.

More than just looks, aesthetics, and beauty, the architecture of the different elements of a GUI must have an underlying function beyond their façade. In other words, the elements of a GUI must have a meaningful behavior that makes their usage more intuitive. For instance, when dragging an object, it is necessary to display the shadow of the object to indicate to the user that the object is actually being dragged and to enable the user to drop the object at the desired location. Playing a sound when expanding a window and another sound when collapsing it could enhance the user experience. When users become so accustomed to all such sounds, animation, and special effects, they unconsciously rely on those special effects to conclude whether or not their action was successfully executed. Thus, those special effects become an integral part of the GUI.

Navigation Architecture - VI

Another scenario is navigating a list of items which could be documents, webpages, pictures, products, etc. Conventionally, web designers have used a page-centric approach to managing and accessing lists in which the list of items is presented in one page, and the details of each item are presented in another page that replaces the page that includes the list. So once a user clicks on an item on the list, that page is refreshed and is replaced by a page showing the details of the selected item. If the user needs to see the list again, he/she must click on the back button. In the event that a user is in discovery mode, this paradigm could become quickly quite annoying because the user will have to go back-and-forth between the page that shows the list and the page that shows the details of an item until the desired item is found. By using parent-child windows in an asynchronous manner that does not require refreshing the entire webpage every time an item is selected, navigating through a list of items becomes not just effective but very pleasant.

Parent window that includes a list which could be displayed in different views such as carousel, thumbnails, wheel, wall, and directory or table whose columns could be sized, ordered, and sorted like in a spreadsheet providing desktop features on the web. The parent window itself can be sized, collapsed, expanded within the current webpage, or expanded in a new tab in the browser.

Child window, which is showing the details of the selected item in the list, can include another webpage, a PDF file, a media player, tabs, etc. When a new item is selected from the list, only the child window is refreshed and not the entire webpage. The child window itself can be sized, collapsed, expanded within the current webpage, or expanded in a new tab in the browser.

Navigation Architecture - V

In case of flat hierarchies, or in case of functions to be executed, the usage of a bar or a dock with a wave or Genie effect similar to the Mac Dock would be very appropriate. In such event, websites will start behaving like desktop applications, and vice versa, combining the best practices of both worlds.
A thumbnail appears upon hovering over an icon in the dock similar to what currently Windows 7 offers in its “Status Bar”.
Such feature offer users the capability of visually browsing a website, which is a very effective way of navigating without ever resorting to any click or any refreshing of a webpage.

A bar or a dock with a wave or a Genie effect when hovering over icons offers a very pleasant user experience that users are familiar with on their desktops such as the Mac Dock. No reason why such rich user experience should not be made available on the web.

Navigation Architecture - IV

Navigation Architecture - III

Navigation Architecture - II

Even though cascading drop-down-menus are an adequate representation of a hierarchical structure, they are awkward to navigate, especially if navigation occurs often, because by their very nature, drop down menus are not designed to stay visible. Thus, users found themselves hovering over the same path over and over again to get where they need to go, unlike a tree where the structure is displayed at all times allowing a user to go directly to the desired node in the tree without having to expand and collapse each and every level in the desired path. For example, if a user selects “Vacation” from the third level in the path “Company-Careers-Benefits-Vacation”, and then wishes to view “Insurance”, then the user will have to travel all over again through the same path “Company-Careers-Benefits” to get to “Insurance” because those drop-down-menus disappear when the user selected “Vacation” the first time around. Furthermore, drop-down-menus in a browser are notorious for annoying users because they are often hard to catch - all it takes is a tiny bit of jerking the focus of the mouse away from the drop down menu for all the drop-down-menus to disappear, and the user would have to start all over again.

As sown below, the ideal navigation system that websites ought to have should combine number of different paradigms and views including tree, accordion, thumbnails, drop-down-menus, wall, and wheels. In addition, an ideal navigation system should take advantage of the web, its connectivity, and its capability of collecting the wisdom of crowds for the purpose of providing suggestions and shortcuts such as:

􀂃 Most popular webpages in a website based on number of unique visitors and number of visits.

􀂃 Highest rated webpages in a website.

􀂃 Webpages similar to or complementary to the current webpage recommended by the publisher or owner of the website. For example, if a user is viewing a description of a product, the publisher could recommend to also visiting the demonstration, presentation, articles, brochures, and white papers related to the product. Thus, the user will instantly have access to everything available about the product in one concise place.

􀂃 List of webpages bookmarked by a user. If a user has the habit of accessing some specific pages, gathering those specific pages in one place can save the user a lot of navigation.
􀂃 List of links created by a user within a specific page. For example, if a page is quite long, a user can simply highlight the paragraph titles and create links for a quick and easy access to certain parts of the webpage.
􀂃 History of webpages visited listed in reverse chronological order starting with the most recently visited.

Navigation Architecture - I

If there is any one particular aspect that impacts usability the most, it would be navigation, especially in websites. Because of their poor navigation, websites tend to be mazes in which we have all been lost in, and found ourselves asking: where am I? How did I get here? Where do I go from here? Where is the page that I just looked at?

A website consists of a collection of webpages organized in a hierarchical structure where the main sections are at the highest level. Within every section, there could be number of sub-sections, and within every sub-section, there could be number of sub-sub-sections, until a node or a leaf is reached which would be the final destination webpage.

In essence, the structure of a website is exactly the same as the structure of the folders in our computer which is typically accessed using a tree component like Windows Explorer. The view of the list of folders could be a tree, thumbnails, carousel, wheel, wall, or a directory. Some views are better suited than others for a particular content. For example, a carousel would be ideal for a small list of pictures but terrible for a large list of job descriptions for which a directory would be far more suitable. Furthermore, different users prefer different views. For example, novice consumers prefer a thumbnail view while advanced technical users tend to prefer a tree view.

The great majority of websites use horizontal tabs as their main navigation paradigm, yet, while tabs are suitable for flat structures, they are quite inappropriate for hierarchical structures. In order to compensate, web designers combine tabs with horizontal or vertical menu bars as shown below. This combination falls flat on its face when the hierarchical structure has more than two levels.