The Posture of Portals

By Ernest Kinsolving, Cooper Interaction Design & Jörg Beringer, 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.

Abstract

This article reviews the idea of "posture," Alan Cooper's classification of the ways different applications should present themselves to the user. Then it examines different types of portals, the goals of the people who use them, and the posture appropriate for each. Finally, it advocates replacing portals with a customizable, integrated computing environment, and describes an intermediate step in that process.

 

Posture in Desktop Applications

In About Face, Alan Cooper introduces the idea of "posture" -- the basic attitude and stance with which an application presents itself to the user. How much screen real estate should the application use? How bold or subtle should the widgets be? How much information should be displayed in the main screen? Determining the appropriate posture for an application helps answer these and other questions, and the appropriate posture for an application is determined by the nature of its use. The designer must understand what the user's goals are in invoking a particular application, then decide which posture best serves those goals. Cooper refers to these postures as sovereign, transient, daemonic and parasitic (please refer to About Face: the essentials of user inter face design for a complete description).

Sovereign posture applications are large and complex; usually maximized during use, their interfaces are feature-laden and subtle, with multiple command vectors, small controls, and a minimum of onscreen explanation. (Familiar sovereign posture applications include Microsoft products like Word and Excel.) Sovereign posture is most appropriate for applications that the user will need to use immersively, frequently, and for long periods.

Transient posture applications, on the other hand, are small and simple; usually taking up only a small portion of the screen, they include a small number of large, simple controls, with enough onscreen explanation to make their behavior immediately clear to a first-time or infrequent user. (Transient posture applications include installers, small utilities like calculators, and, in a sense, dialog boxes.) Transient posture is most appropriate for applications from which the user needs simple, temporary utility, and which the user will use very briefly.

Daemonic posture applications primarily carry out background processes requiring no interaction at all, so they are, ideally, largely invisible. They should not intrude on the user's attention unless absolutely necessary, and interaction with them should be limited to configuration through a simple control panel.

The fourth posture has historically been referred to as parasitic, but the negative connotations of that term argue for a replacement. In this article, we'll be using the term "auxiliary" instead.

Auxiliary posture applications combine features of sovereign and transient posture: they are present for long periods, but are small and have very limited functionality. They are generally used in conjunction with one or more other applications, providing dynamic information or a small set of tools. (The most familiar example of auxiliary posture is the Windows Start bar.) If a user frequently needs some small piece of data or functionality, which is not provided by a sovereign program, the application that provides it should have an auxiliary posture.

 

Posture of Portals

Cooper's posture classification system is geared toward traditional desktop applications: how does it map to the world of portals? To answer that question, it's necessary to clarify what's meant by "portal," and to examine what they help people accomplish.

Navigational Portals

Early search engines allowed people to find and access content and functions distributed throughout the world on the Web. They served as "portals" in the original sense of the word -- ways to get somewhere else -- and can be classified as "navigational." Nothing really happens in a navigational portal; you get in, you go somewhere, you get out.

Use: Why would someone use a navigational portal? To gain access quickly to unrelated information and functions.

Posture: If the user requires that access relatively infrequently, the appropriate posture is transient: something that pops up and gives clear, simple navigational controls (a familiar example of this is the alt-tab functionality in Windows). If the user needs more frequent access, the appropriate posture is auxiliary: a small and persistent panel of links (like the Windows Start bar).

Environmental Portals

As portal sites began trying to keep surfers from clicking out, they began to offer more and more content and function inside themselves, and they became what we commonly refer to as "portals" now: collections of aggregated data, functionality and links. This construct was modified and adopted by various dot-com companies to give unified access to content and functionality related to a specific topic or interest, and by various enterprises as a way to give access internally to important company information and tools. In both cases, the intent was essentially to create an environment in which users could access a particular kind of information and accomplish a particular kind of work: portals became "environmental." Actual work is done in an environmental portal. Information is gathered from disparate sources and acted upon; various tools are brought together to accomplish a unified purpose.

Use: Why would someone use an environmental portal? To have simultaneous access to a group of related information and functions.

Posture: Two things distinguish an environmental portal from a merely navigational one: the relationship among its elements, and the sense of place. If a portal is going to create a working environment, its elements need to relate to one another in a way that helps that user achieve a specific purpose. And when it creates a working environment, it creates a sense of place; the portal is no longer a way to get somewhere else, but a destination in and of itself. The appropriate Cooper posture for an environmental portal is sovereign.

 

Posture of Portal Elements

Within an environmental portal, the individual elements function essentially as small applications running simultaneously -- as such, the elements themselves have a sort of posture.

Auxiliary elements: Most of the elements in an environmental portal will have an auxiliary posture; they typically present aggregated subsets of information which the user wants constant access to (such as small containers or dynamic status monitors), or simple functionality (small applications, link lists, etc.). What was "parasitic" in the traditional desktop framework is now the key building block of environmental portals.

Transient elements: In addition to such small auxiliaries, an environmental portal will often give access to transient portal services. Their complexity is minimal, they are rich in explanatory elements and they are used for short periods on demand. Designers should give a transient posture to any embedded portal service that goes beyond auxiliary, so that it does not compete with the environmental posture of the portal itself but rather becomes a natural, temporary extension of it.

When migrating traditional applications into portals, one of the key design challenges is breaking the application apart into a proper set of portal services with auxiliary or transient posture. Sovereign, full-browser applications are not appropriate within portals because they break the environmental posture and are not perceived as part of the portal.

 

Portals and Beyond

"Environmental" Posture

The great benefit of a portal is its ability to bring together specialized functions and aggregated information from a number of different sources and put it all into a unified context; if it's done right, the whole becomes much more than the sum of its parts, encouraging comparison and synthesis, making appropriate tools immediately available, and intelligently connecting them all so that they function together in service of a single user goal.

The holy grail of portal design is to construct a portal so complete and well-integrated that as long as the user's goals fall within the range of a defined role, the portal can encompass the full scope of that user's computing needs. When this is achieved, the posture of the portal appropriately transcends the sovereign and becomes truly "environmental."

In contrast with a merely sovereign application, an environmental portal is the only thing available to the user because it's the only thing the user needs: it takes the place of the desktop or shell.

Starting Design from Personas

Traditional tool or application design constrains the scope of interaction design to a single tool or application. Even if this design is driven by personas and their goals, the scope of such design efforts is usually limited to one tool, one application, or one type of electronic artifact.

In contrast, the interaction design for environmental portals requires a system-independent analysis of user goals in which the scope is not limited by component or application type. As no design effort can start without a focus, the starting focus of environmental design must be the creation of a persona who embodies the goals of a specific archetypal user within a specific job or working role in an enterprise. A thorough understanding of the persona allows the designer to see beyond the user's customary tasks to the underlying goals that drive their activities and information needs. Decisions about which components and information elements belong in an environmental place should be driven by the goals of the persona.

Kill the Browser

The great drawback of portals is that they are implemented through web browsers; no portal can be made truly environmental within the constraints of current browser technology. Browsers are slow, weak, and plagued by proprietary inconsistencies. Because a browser is an application in itself, it also adds a cognitive hurdle to the presentation of an environmental experience: a browser is a sovereign application running within a shell or desktop environment; this makes an environmental portal running in a browser begin to resemble a hall of mirrors.

Browsers were effective tools when they were used to display and navigate through linked, marked up text. They are not capable of running applications with the speed and consistency that is necessary for an immersive computing experience.

Interim Solutions

In the glorious future, browsers will be dead, replaced by fully integrated, intelligent, goal-specific, customized source-independent computing solutions. In the interim, though, designers of portals need to work to minimize the impact of browser implementation. A full exploration of methods and approaches is beyond the scope of this article, but here are a few possibilities to start you off:

  • Strive for platform independence. If one aspect of your portal's utility is the user's ability to access it from "any web browser," it doesn't help to write it so that it "only works with IE5 or above."
  • Use best-of-breed technology for functionality within the browser. There are companies out there writing applications that work well in a browser without plug-ins (or Java!). See the Alphablox demo at www.alphablox.com for an example.
  • Minimize the cognitive discord of the browser itself. Run your portal in a vanilla window without browser menus or navigational controls to prevent confusion of portal function and browser function.

 

Summary

In the portal's quest to provide a complete, integrated tool for a given user role, it must eventually transcend sovereign posture and become truly "environmental," replacing the desktop entirely. In order to do that, it will have to also transcend the browser. In the mean time, portal designers must work to minimize the impact of the browser's slow speed, inconsistent implementation and cognitive discord.

 

top top