 |
|
|
Archive - Edition 3: Portals
Leading Article
What is a Portal?
- Portals – The All-In-One Web Supersites: Features, Functions, Definitions, Taxonomy
- Creating New Work Paradigms for the Enterprise Portal
- The Posture of Portals
- Ingredients of Portals – An Overview
- Generic Portal Pages – What Do Most Portals Need?
What's in a Portal: MiniApps, Generic MiniApps
User-Centered Portal Design
- Portal Usability – Is There Such A Thing?
- Do Traditional Design Processes Apply to Portal Design?
- The Budget Manager Portal Revisited – Putting User-Centered Methods to Action
- Creating an Interaction Design
- Information Architecture for Web Portals
Graphic Design and Branding
"Real" Portal Projects
- City Portal
- The Web Master Portal – Roles and Scenarios
- Employee Self-Service and Life and Work Events – Two Ideas for a New User-Centric Perspective
Links & More
 |
Print version |
Related Links |
|
 |
Visual Direction and Balance in MiniApp Design |
Background Links |
|
|
Portals – The All-In-One Web Supersites: Features, Functions, Definitions, Taxonomy |
 |
|
Portal Design vs. Web Design
By Esther Blankenship, SAP User Experience, 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.
In a Web project, the designers know who their client is, the purpose of the site, and the image that the client wants to project. Usually, the designers also know the type and amount of the initial content of the site. Portal designers, on the other hand, don't know any of these specifics. Designing a portal is a bit like creating an all-weather, unisex, one-size-fits-all garment, as opposed to a dress for Madonna to wear on Oscar night. The design of a portal has to be flexible enough to meet diverse clients' and users' needs, yet structured enough to accommodate a wide range of content and visual elements. A good portal should offer an attractive and usable default design which is not so deeply entrenched in the coding that it is difficult or costly for the customer to modify.
Building Flexibility into the Design
One of the most important tools for providing design flexibility is cascading style sheet (css) rendering. By using css rendering we avoid hard-coding colors and images into the portal so that customers (and to some degree users as well) can easily modify the look of their portal. Customers can change the appearance simply by choosing one of a set of predefined looks, called "themes," or having in-house designers or a design firm create a new interface. Our aim is to simplify the customization of the design to the point that one designer, even one with limited experience in Web development and graphic design, can change the face of the portal in a very short period of time.
In addition to using css rendering, we also ensure flexibility by using as few bitmap graphics as possible in the portal. From a design perspective, rounded tray corners and highly modeled tabs would have made for a friendlier interface than the current square corners, but curves require bitmaps, and bitmaps require a graphic designer each time a change needs to be made. Instead, our portal uses HTML tables to draw the tabs, buttons, and trays. The result is a light-weight page and a design that is easily customized.
Another way in which we have built flexibility into the design is by creating monochromatic images on a transparent background (see figure 1) for the navigation and tray header images. Thus, even a person with minimal graphic editing skills can change them to fit a new color scheme. An experienced graphic designer can change them in a matter of minutes.
Figure 1: Monochromatic tray header images
Some flexibility features of the portal are invisible to end users. Although not part of our standard design look, we have left many design options open to the customer. For example, the tray header row contains an extra cell in the left corner, should a customer wish to insert a bitmap there (as trays are often designed with a rounded upper-left corner). This is only one of many design alternatives which are visible only to a developer or designer.
Optimizing for 80%, Taking the Others into Consideration
A portal designer must be graced with an active imagination. First, he must be able to design good interfaces for the situations that are most likely to occur (i.e. 80% of the cases). Second, he must be able to imagine worst case scenarios and ensure that some kind of order and usability still reign on the interface.
Figure 2: Navigation tabs in a portal (click image for larger view)
Take tabs for instance. Tabs work best as navigational aids when there are no more than seven tabs per level, each tab containing short, meaningful text. We estimate that in about 80% of the cases, this will be so. However, we also realize that this will not always be the case. A user may have several roles (and, thus many tabs, see figure 3), or the text on each tab might be very long (see figure 4).
Figure 3: Tabstrip with lots of tabs (click image for larger view)
Figure 4: Tabstrip with lots of text (click image for larger view)
We cannot optimize the design for the exceptions, as we would be trying to please everyone and end up pleasing no one. But we do try to anticipate anomalies and provide a reasonably usable interface even in these cases. It's not easy imagining all the things that could appear other than the way we planned, but that is one of the challenges of portal design.
The Internet Hybrid
One could say that portal design is a hybrid of Web and application design with a flexibility requirement thrown in to keep things exciting. It's certainly a challenging and interesting twist on "normal" Web design.
