After a couple of years spent designing Web application front-ends, I’ve identified several interface components that are common to many Web applications across a diverse set of domains: finance, health care, aviation, knowledge management, safety regulation, commerce, and education. An awareness of these components can help guide the design process by identifying requirements early on.
Though several of these Web application interface components are also common in “fat” client applications, their implementation in Web applications often differs. Web applications rarely utilize a document-centric interface (found in many client applications), which consists of a working canvas (document) and tools. Instead the focus in Web applications tends to be on navigating through, manipulating, and creating information (so in Microsoft’s Application Archetype model, we are mostly talking about: database, e-commerce, and information/reference applications).
Additionally, limitations of Web browsers (poor window management, spotty display consistency, etc.) frequently require unique solutions to interface components (inline messaging, explicit log-in and log-out functions, sign-in status, navigation hubs, etc.). I’ve tried to note some of these characteristics in my common Web application components list below.
Hubs & Contextual Macro Views
Application and sectional “hub” or “home” pages (navigation screens) present an opportunity to explain functions and components to users. They can also provide high-level data overviews of relevant application or section-wide content.
Navigation & Orientation
Due to an absence of the standard “File Edit View …” menus that provide consistency across client applications, Web applications require consistently placed navigation systems that provide indication and orientation for users as they move between data information and interactions. Navigation menus, application-wide utilities, screen utilities, footer, breadcrumbs, and page titles are some of the interface elements that constitute navigation components.
Many Web applications feature robust data analysis and monitoring tools. As a result, data display screens frequently require complex sets of filters and display options that allow users to adjust the data being displayed and its presentation (most commonly maps, graphs, and tables) to meet their needs. The most effective data displays provide enough contextual information to clearly identify the choices users have made (filters, state, and presentation options) and allow direct editing of those choices.
A consistent set of error, success, and status messages provides users with critical feedback on the actions they initiate. Due to pop-up window issues in web browsers (PDF), Web application messaging often occurs inline (many users block pop-up browser windows). Many Web applications also incorporate “message centers” that serve as a user’s “inbox” for system or admin, or messages form other users.
Whereas many client applications can leverage existing platform Help structures, Web applications require custom solutions. Education components within Web applications (PDF) can include a central Help repository, contextual Help pop-ups (many are still using pop-up browser windows), FAQs, tutorials, and support systems (chat, email, or contact information).
Admin & Settings
Because Web applications are distributed over a network (and not local to individual user’s machines), they require a set of personal preference and management functions. System administrators and application users need to edit profile information, access levels, system messages, personal settings, and more. As a result, many Web applications include a “My” section that allows users to view and store personal data, set preferences, and edit personal settings.
Due to ever increasing privacy and fraud issues online, Web applications often need to include trust messaging systems and safety tools for users.
Many Web applications leverage online community interface components that allow users to comment, discuss, and collaborate within an interface.
Reporting sections allow users to analyze data display histories, run “what if” scenarios, and gain a sense of how a Web application is being used.