By Gerd Waloszek, Usability Engineering Center, SAP AG – May 21, 2001
Disclaimer: Please note that this edition was written in 2001. Therefore, statements in the articles, particularly those regarding SAP's products, product strategy, branding strategy, and organizational structure, may no longer be valid.
With the advent of Websites, Web applications, and portals, many user interface designers questioned, whether there is still such a thing as Web or portal usability. "Are the 'old-fashioned' guidelines for GUIs or Windows applications still valid?" they asked. Maybe, some of them even hoped that they could get rid of the old stuff and start anew without having to bother with all those rules, guidelines and directions. On the other hand, Web guidelines soon sprouted like mushrooms in an autumn forest. I often wondered, why this did happen. Is there an immanent human need for guidelines and style guides (at least for writing them, maybe less for reading them..)? Anyway, most of them, were of little help for developing Web applications or portals.
So, what do we need to know if we want to design usable and enjoyable Websites and portals? In this article, I take a look at some of the usability issues involved with Web applications and portals - maybe this is a starting point for such a thing as portal usability, whatever its final name will be.
In this article, I often use the terms Websites and portals more or less like synonyms. But is this correct - or are there any notable differences between Websites and portals? My answer is that it depends. It depends on what Websites do or want to accomplish. Portals are a special breed of external or internal Websites offering a blend of information, applications and services. This implies that portals always have more than just information to offer, as many Websites do. Moreover, portals are typically based on more advanced Web technologies that go beyond the simple HTML interface of typical Web pages. So, there are more things to consider, fewer technical limitations, but also a more complex environment for the users - and designers - to work with.
One of the questions developers asked in our Web application courses was "Are the old usability guidelines still valid?" The simple answer is "yes". A more detailed answer would be "yes, in principle". Of course, the more specific guidelines are with respect to a certain platform (e.g. GUI, or Web) or type of application, the more probable it is that they are no longer applicable. However, the more general these rules are, the more probable it is that they are still valid. Radiobuttons or checkboxes remain what they are, irrespective of whether they are used in GUI-based ERP applications or on the Web. Most layout rules for forms still apply, although many of them can be relaxed for the Web and applied more flexibly. The possibility to use different fonts, sizes and attributes on the Web offers far more design options than yesterday's terminal fonts.
Portals are neither "traditional" Websites - maybe that after a few years we can already speak of a "tradition" -, which basically present information, nor are they Web applications, such as SAP's Internet Application Components (IACs). IACs have been the technical basis at SAP for implementing Web applications, for example, ESS applications (Employee Self-service) or B2B (Business-to-Business) applications, such as the procurement suite or the SAP Retail Store. SAP's mySAP.com Workplace, SAP's first portal solution, sprouted a new breed of small application and information snippets, the MiniApps - now renamed to iViews. Portals, however, are a mixture of all of these, blending information, applications and services into one offering. Thus, portal usability is more than the usability and design of its parts. It has also to care for the more general issues of packaging these offerings, structuring, integrating and organizing them, as well as tailoring a portal to a specific user group or role. The latter aspect may be the most important one in the future - to design portals as user- or people-centric solutions.
As mentioned above, traditional Web style guides do not address Web applications: they cover only traditional information-based Websites. So there was a gap that SAP had to fill for its own needs with guidelines for Web applications and MiniApps - see the SAP Interaction Design Guide for Internet Application Components and SAP MiniApp Guidelines in the SAP Design Guild. In addition, the Quick Guide to Creating Information-Oriented Web Sites in the SAP Design Guild offers a somewhat different approach to guidelines for information-based Websites, as well. However, up to now there are still guidelines missing that specifically address the issues of Web portals. There is a SAP Portal Cookbook under way, but it is still rudimentary and not publicly available. This article addresses some of the usability issues of portals and Websites, however, on a more basic level than the forthcoming SAP Portal Cookbook, which will, among others, focus on the "tailoring" aspects.
Now let's come to some basic usability issues, such as the distribution of attention, flow of control, and dependencies between parts of a page, for example, between different MiniApps.
Note that many of the recommendations given here are valid for Western cultures only, where reading goes from left to right and top to bottom.
Caring for the user's attention is more important in portals than it has been in ERP applications. Portal or Web pages often look like newspaper pages with many different types of information competing for the user's attention. Often we want something to stand out of the surrounding elements because it is an important key word or an urgent message. On Web pages, bold font may be used for emphasizing text elements; this helps readers to scan the page faster (see, for example, the bold word "attention" in this paragraph). Italic font, for comparison, does not stand out and is hard to read on computer screens.
For simple portals, the basic distribution of attention found in the SAP R/3 Style Guide still applies, that is, the upper left corner gets most of the attention, and the lower right least. See also that two thirds of the attention go to left left half of a page or screen.
Figure 1: Basic distribution of attention
Many portals, especially those designed for larger screens, have a layout, where the work area is accompanied by narrow areas for indices, navigation links, news, or the like; Figure 2 shows some of the possible layout variants:
Figure 2: Portal layout variants: Index (I) to the left of the work area (W) (left), index to the right (middle), and two index areas enclosing the work area (triptych, right)
For these more complex layouts, the work area still gets most of the attention, but the areas to the left and/or right also get some, probably the one to the left more than the one to the right. Therefore, a so-called "triptych" design could place the more important infos to the left and the secondary infos to the right of the work area.
Figure 3: Distribution of attention for portals with "triptych" layout; within the work area we find the basic distribution with the most attention falling into the upper left corner
The border areas might even get less attention on large screens, where users focus the center of the screen, while the areas to the left and right are already in the peripheral vision.
There have been some quarrels with respect to, whether it is better to place the index to the left or to the right on a "diptych", that is, on a page with two main areas. Some people claim that an index to the left would disturb their reading. On the other hand, we are used to columnar reading from, newspapers and magazines. Also, on large screens this problem should be less severe because people cannot pay attention to the whole screen, anyway. To sum up, only a few Websites place the index to the right of the work area.
Finally, let me mention that reading is easier, if the text lines are not to wide. It is better to have two columns 40 character wide each than one wide column with 80 character. Carried over to MiniApps this means that narrow MiniApps are easier to read and understand than wide ones. Especially, MiniApps containing much text should not be too wide. There are, of course, exceptions to this rule, such as MiniApps which have to display wide tables or diagrams.
Scrolling was a matter of hot debates for a couple of years, after Jakob Nielsen claimed that users do not scroll. Finally, even he realized that there are some users that do scroll (take a look at his own site www.useit.com or Figure 4 left, and you will agree). Of course, he was right in drawing our attention to the potential problem of information that can only be made visible through scrolling. Again and again, users do not find information because they do not scroll or do not consider to scroll. Cognitive psychology offers the "availability" heuristic as an explanation: People regard only that information, which is directly available to them - that is, which is on the current screen, or at the focus of their attention. So, we have to acknowledge that much information is not attended to by the users, even though it is on the screen; this is especially true for text information. So, many users seem to have a different interpretation of the WYSIWYG (What you see is what you get) principle: they believe that they get only what they see.
Figure 4: A text-based "portrait-oriented" page (left) vs. a portal page with a "landscape-oriented" layout (right) (click images for larger views)
With respect to scrolling behavior, there may also be differences between page types. A more portrait-oriented page containing text may be no problem; users typically find it obvious that they have to scroll in order to read on. However, for the more landscape-oriented portal pages consisting of lots of smalls snippets (MiniApps, iViews) this may be not so apparent to users. These pages may look complete to the users, and they do not expect them to continue beyond the visible area.
Flow of control is important in two respects: (1) for the efficiency in performing a task, (2) for the transparency and understandability of a screen or page. Flow of control means that the focus of activity moves across a screen or page while the user performs a certain task.
There are natural ways how control should flow - if the flow is reversed, people are puzzled and may even have problems with performing a task at all. What people regard as a natural flow of control, depends on their cultural background. For Western cultures the "natural" flow is from left to right and from top to bottom - just like reading.
See the arrows for recommended flow between two areas
See the red and blue paths for not recommended flows from start to goal
Figure 5: Basic rules for flow of control
Dependencies between screen areas are closely related to the flow of control. Here are essentially the same basic rules in effect: We expect, at least in Western cultures, that dependencies are from left to right and from top to bottom. With dependencies, I refer to cause-effect relations, not to movements of the focus of activity. For example, you select an item in an overview list and expect that its details will be displayed below the list, not above it.
See the arrows for recommended dependencies between two areas
See the arrows for not recommended dependencies between areas
Figure 6: Basic rules for dependencies
Web technology has confronted us with a new phenomenon, the page update. While in modern GUIs (not on terminals) screen updates go often unnoticed and are rarely a problem, Web browsers typically erase a page and draw it anew. This visual effect is very disturbing for users, especially if it takes several seconds or even longer. There is a perceptual discontinuity: users loose their attentional focus and have to remember the state of the screen before the update. This makes it often very hard for them to realize what actually changed. This visual effect is also very unpleasant.
Screen updates are of course even more of a problem if the changes (not the update, that affects the whole page) happen on parts of a page, which are invisible to the user. The user would have to scroll down to find out, whether there are any changes. Automatic scrolling might be a solution, but then the context of the starting situation gets lost. Moreover, the changes might affect several areas on the page. The context goes completely lost in such a case, and the user has to take great effort in reestablishing it.
User interface designers cannot change the current browsers, so their influence on this situation is rather limited. However, they can choose designs where screen updates are less often necessary than with others, and they can care for the context and dependencies.
I do not want to dig into special layout issues for portals here, but let me stress that it is important to take care of the global layout issues, too. These are closely related to the attention and flow of control/dependencies issues already mentioned. In essence, the global layout should take care of:
Navigation and structure are closely related - navigation is the dynamic aspect, structure the static aspect of the general problem that content has to be organized to be accessible to the users. In other words, content has to be given a structure, and users have to move within this structure in order to access specific content. The standard solution to this problem is to categorize the content according to a hierarchical scheme and to provide a respective access mechanism or index into this structure.
A very "technical" and generic solution would be to offer a tree control as index for the structure. As most users have problems with this approach, the hierarchical index is usually not displayed as a whole, but more or less hidden from the user's view. The current "fashion" is to offer a two-level index where the second level is only displayed for the active top-level category. Further hierarchy levels are offered - if needed - if a respective second level node is being accessed. This sounds a little bit complicated, but can easily by understood using Figure 7:
Figure 7: A two level navigation structure complemented by further nervation links, if needed (click image for larger view)
As navigation within hierarchies can often be cumbersome, additional "short cuts" can be introduced that move between branches without backtracking.
Search offers an additional "direct" path to certain pieces of information or functionality. However, search is a feature, which is used by the more proficient users; beginners and casual users typically prefer to browse or navigate a hierarchy. Thus, a portal should never rely on search alone; search can only be an additional offering.
There is a whole bunch of problems related to Web technology:
HTML offers a limited of forms elements such as radiobuttons, checkboxes, dropdown listboxes, input fields and buttons. Tables lack any interactivity as is possible in windows applications. Interactivity has to be brought in via hyperlinks and page updates - which are, as already mentioned a big problem.
Web pages and Web applications including portals run in a browser. Web browsers create an environment of their own and limit the freedom and choices for applications:
In addition, the browser menu, toolbars etc. take up a lot of urgently needed space. I saw cases where one third of the vertical space was used by the browser and branding elements. This may be amended by using the full screen mode of a browser. However few people do so, either they do not know of this mode (I met a lot of these people) or they do not want the desktop to disappear.
If these elements have been important parts for an application that is to be ported to the Web, then there is a problem. Typically, complex applications rely on these techniques - they have to be rewritten and transformed into simpler modules.
Finally, we move into one of the darkest areas of Web technology, the cross-browsers issue. I do not want to go into detail here, but just mention that this may drive Web designers crazy. Often designers limit their pages or Web applications to a certain platform. This is possible for Intranets, where a company can assure that all its computers use the same browser platform, but it is not a good strategy for the Web where visitors may use any browser. In addition, even versions of the same browsers on the very same platform differ in their rendering behavior. Actually, we're still in the stone-age of Web technology.
What about users? There is no point in doing design and usability without users. The Web once again brought a revolution with respect to the users. We have the "dumb users" to take into account - and we have to do it the more, the wider the public is that we want to address with our Websites and portals. Often, we even cannot assume that the users have a certain and well-grounded knowledge of how today's user interfaces work. As we know, on the Web everything is just a few clicks away. Clicking is easy, knowing about selection rules, tab chains, active and inactive windows, or whatever is another matter.
The new users are different. We no longer have the tekkies who can stand cumbersome user interfaces and are proud that they master all that weir technique. Web users are impatient, they want it fast, and are not willing to learn much and to bother with handbooks or cumbersome procedures. On the other hand, many Web designers either do not know this fact or willingly disregard it for commercial reasons. Or can you explain, why it often takes 10 to 20 clicks to download an update for your software?
I am not sure whether the current tendency to enrich Web interfaces with GUI technologies is a step into the right direction. The better way would be to make the interface more and more invisible behind the information and functionality. Look, for example, at Microsoft's Reader software or Adobe's eBook reader pendant and you know what I mean.
As already mentioned, an important aspect of portals is that they are typically tailored to specific roles, such as a budget manager or Web administrator. This orientation implies that the user interface designers themselves have to adopt a new role. They will be less concerned with the proper usage of interface elements but more and more with tailoring the contents and functionality of a portal to a specific user group, so to speak, to a role. In the article The Budget Manager Portal Revisited – Putting User-Centered Methods to Action in this edition you find a description how user interface designers fill this new role in a development team. Important elements of this new approach are site visits, brainstorming sessions, and prototypes that are evaluated by the prospective users. Only in this combination, usable and people-centric portals can come to life. But user interface designers are not the only players in this new field. Information architects care for the structure and content of Websites and do a very similar job. On the other hand, graphic designers also work in close cooperation with interface designers - often visual and interaction design is hard to tell apart. So, ideally every user interface designer should have a firm knowledge of information and graphic design in addition to his or her usability knowledge. In small teams, these three roles may indeed be combined by one person, irrespective of his or her original background. In larger teams, however, these roles will be filled cooperatively by people from different backgrounds.
Generic portal ingredients exist on the page level as well as page elements, that is, on the MiniApp or iView level. As this edition includes articles covering both of these issues (Generic Portal Pages – What Do Most Portals Need?, Generic MiniApps (iViews)), I simply point out that both areas are a potential field for usability people and user interface designers. The design of these elements is not bound to a specific portal project and can be carried out independently. But it should be done in close contact to actual portal projects for gathering realistic requirements and for testing the concepts. On the other hand, user interface designer who design a specific portal should know what is available on both the generic page level and the generic MiniApp level to ensure that they include the optimal ingredients into their portal.
To sum up, we can conclude: Yes, there is such a thing as Web or portal usability. People who know all the stuff can sit back and relax - most of the stuff they know is still valid, although it may have to be applied differently because of the peculiarities of the Web and Web browsers. Newcomers have to learn that they cannot skip all that old usability stuff and just focus on cool web design. There is admittedly much more fun on the Web, but the fun soon ceases for the users, if the designs are not usable or even prevent people from doing their jobs.
There is not only a new technology that has to be taken into account, we also found out that there are new user groups that require new designs. And finally, we found that the role of usability people and user interface designers may change from designing screen elements and singular applications to a more holistic approach of designing work places for people.