About successful Web sites 

Table of Contents | Previous Page | Next Page

---

The measure of success for a Web site varies by the type of site it is. For example, an e-Commerce site can measure sales to judge how well it is doing. However, there are points that are relevant to all Web sites such as user retention, user enticement and usability design. To give a site the best possible chance of hitting its goals it is best to lay out best practices in the design phase. In this chapter, some elements of best practices including how to best define a project scope and key considerations in the user interface design will be outlined.

Information architecture and site design

The table below outlines common challenges associated with Web content.



The Information Architecture (IA) of a system is all the information located within a system expressed in a defined and structured way. It is critical to the design of a Web site, as it not only organizes the content but also lays the groundwork for the user experience with the system. A strong information architecture ensures that when the site is designed, all critical aspects of the site are addressed and there are no ambiguities in the system. Defining the information architecture ensures that the development team has a good understanding of the content that is to be displayed.

It is important to acknowledge the relationship between the information architecture and the WCM site framework. The WCM site framework structures the information about a published site and is closely integrated with Web site navigation.

To begin, you define an initial WCM site framework with primary and secondary site areas. The WCM site framework is a prerequisite for the design and development of the content management system. In addition, you must develop an initial layout of the home page based on the primary and secondary site areas. Both the framework and the home page layout require review and validation by the project owner, from both an authoring and Web usability viewpoint.

Choosing the right framework for a site dictates how the development teams approach the information architecture. WebSphere Portal provides other things such as security, content aggregation or user personalization. Information needs to be structured at an early point to ensure that there are no problems further down the line. For example, if a user role is not modeled correctly in the system, then there is a chance that an element of the site that is too rigid, such as the design, may need to be reworked.

Information architecture

The following outlines the components and that make up an information architecture.

How to classify the content

The content classification shows all the different types of content that will be shown on the site.

Defined with:

• Content audit
• Site framework (only an outline of what the site framework will be is defined here)

The hierarchical structure of the site

This gives a clear picture of the way the content fits together in the context of the Web site. It shows how the site content fits into the different areas of the site.

Defined with:

• Site framework
• Site map

The functionality that is required on the site

This gives the behavior of the site and what functions the site performs. It also provides a detailed account of the site capabilities.

Defined with:

• Requirements
• Use cases

The look of individual pages

This shows how the content fits in with the functionality of the site, how the user flows through the site and details the look and feel of the site.

Defined with:

• Wireframes
• Storyboards

The flexibility of the architecture to allow the business to evolve

To ensure that site can grow and progress naturally the ability to evolve has to be taken into consideration in each section of the site. However, there will be times that an area of a site will not be suitable to grow. This should be captured and fed back to the project owners.

Defining the information architecture

The following sections describe the key steps to defining and information architecture.

Requirements gathering

The best way to ensure that you have an easy to use and intuitive Web site is to have a clear idea of the scope of the site from an early stage. This gives the developer a clearly defined set of goals to work towards and provides a measurable set of parameters for the site. It also defines an end point for the site development.

It is useful at this stage to identify aspects of the demographic that will be targeted by the Web site and how the requirements relate to the user. There are many methods of defining this relationship but this document shall focus on use case creation and analysis. This provides the ability to map the Web site function and how the user type relates to it.

In most cases, user types will be fairly obvious as a project owner will know their audience fairly well. However, in some cases more analysis will need to be done. It is also difficult to do this without making fairly broad generalizations about certain user groups. For example, if the site is targeted at people over the age of 65, then the designer should assume that the users might have traits common to that age group such as poor eyesight or decreased mobility and should write the requirements to cater to this user group. This is not to say that everyone in this group has these particular challenges, but there is a greater possibility that this is the case. For an external Web site, the user base will tend to be fairly broad as you can never tell who will be accessing the site. It is usually important to ensure that no user feels left out by the system. Certain levels of competence and ability can be assumed if the project owner determines these assumptions can be made.

Functional / Non-Functional requirements

Requirements can be split into various sections and priority levels. The most commonly referred to sections are functional and non-functional requirements and the main priority levels are must, should and may. Functional requirements define behavior that the Web site implements such as adding a product to a shopping cart or logging in. A non-functional requirement is a factor that the system has as operational criteria, such as a list of browsers the system will support.

The priority levels of the requirements of a system refer to the importance of that requirement with regard to delivery. ‘Must’ refers to a requirement that the system has to implement, that is, a core part of the system and therefore has to be included in the first phase of the project. ‘Should’ refers to a requirement that the system ought to meet. It will refer to criteria that the system will be able to do without if there is a valid reason not to have it. ‘May’ refers to requirements that are not important to the running of the site but will add additional features to the system.

At the completion point of a system, all of the ‘must’ requirements should be implemented and all the ‘should’ requirements are either met or omitted, provided the omission is justified. The ‘may’ requirements should not prevent the system from going live. However, any of these requirements have to be either not started or complete, as an unfinished piece of functionality should be seen as a bug by the testing team.

Content audit

A content audit requires a sample of all types of content and what document or media types need to be displayed. Creating the sample cases, should not take a lot of time as it should primarily encompass picking a sample of content that fits into a particular content type and adding that to the audit sample. For example, all press releases tend to look the same as each other so analyzing them all would be a little redundant.

Once the content sample has been defined, content analysis can be performed to identify the patterns and the links between the sections of content. This provides the definition of the sections of the site that can later be drawn into the hierarchical site framework or taxonomy and include:

• Types of content
• Audience
• Dynamic content vs. Static content
• Connections between content
• Hierarchical structure
• Dependencies

By visually mapping the content with a content map the structure of the site can be marked out in a clear way. It will outline the structure of the site with the project owner in a clear and easy to understand manner, and it will ensure that the content is structured in a scalable and understandable way.

In later stages of project development, a content inventory will be required, but in the planning phase of a project a content audit is necessary. The difference is that where a content inventory is a definitive list of everything on the system, a content audit is a sample of that information.

By the end of this process and by organizing the content in this fashion, the site framework should be confirmed and the outline for creating visualizations of the system should be in place. This makes defining the content a critical point in the development of the system.

Visualizations

A key piece of the information architecture include the visualizations of the various pages.

Wireframes

A wireframe can be drawn to add definition to the content on a site and to help define how navigation works on the site. Wireframes are a high level tool that allows the architect to design how the content is laid out on the screen without having to worry about the look and feel. This will create a low fidelity version of the site that focuses on the usability of the site and not its presentation. A high fidelity version of the site can be drawn later in the design process, but by creating the wireframe of the site early on, the outline of the site is defined ensuring that the project owner is brought into the design process and can start to picture how the site fits together.

Storyboards

A storyboard defines how the user navigates through the system. It also allows the project owner to visualize the way that the user will view the use sequence of a site before the design phase is started. Storyboards tend to model the use cases, as they are event driven and from the point of view of the site user.

Use Cases

After defining the different user types that the system will cater to, and the requirements of the site are defined, use cases can be developed. The user types can be defined as actors in the system and the set of steps the actor takes while navigating through the system will become the events in the use case. This provides a testable and measurable plan for the development team. This definition of functionality will also help in the planning stage of the system to identify the dependences between the requirements, and will also highlight the areas of the system that might cause the development team problems.

Web Content Management deliverables

At the end of the Information Architecture stage the development team will then be able to draw up some documentation that will allow the development team to start developing. These deliverables give a clear picture of how a developer should implement the system, and also how all the information hangs together. It therefore provides a strong content centric design of the system. They include:

• Site framework
  Similar to a site map that would be found in the development of a traditional web site but rather than setting out a series of pages in a tree structure, it defines a set of site areas and content items. This effectively maps out how the user navigates round the site.
• Libraries
  A library is a container for any WCM objects that you wish to group together, although it is not necessarily important exactly what the libraries contain it is important that what they contain is logical. For example an Authoring Template can be referenced or copied between 2 different libraries but it may be logical to keep it within a specific container.
• Authoring Templates
  An authoring template specifies the input fields, for example text or images, that will be presented to an author when creating a content item .
• Workflows
  This defines the process by which a content item is verified before it is published.
• Security requirements
  Includes the access rights of the different user types within the system.
• Category hierarchy (taxonomy)
  It is important to note the hierarchical categorization of the content on the site. It differs from the site framework in that the site framework refers to the areas of the site but the taxonomy is independent to the location of the content.

WCM Web site decomposition

After completing the visualizations and assuming that the project owner has signed off or has provided some design elements such as prototypes, screenshots or existing sites to recreate, it is important to define what components are going to make up the site. The functional parts of the design that are provided can be broken up and divided into the constituent parts. Then the pages that these components are shown on are identified. That is, if a component is located on every page then it should be identified that it can be re-used. A WCM specialist, while performing this analysis, will be able to identify components that may cause problems and highlight them as areas to address.

User interface and user experience design

There are certain web standards relevant to the development of an external site that a system should support, such as having a search function or navigational features like breadcrumbs. These are important points to note while defining the scope of a system as they declare what a system will and will not do to support its users. A well designed user interface (UI) that puts the emphasis on user experience ensures that the user will have a positive experience. This is a key point in supporting customer care which is often lacking on-line, particularly on e-Commerce Web sites, but is good practice with all websites. Good customer service dictates that if a customer has a positive experience they will tell a friend but if they have a negative customer experience they will tell ten, and this logic is no different on-line.

Usability

A key item for successful Web sites is usability. The following sections describe some key aspects to usability.

Identifying the different user types

To define the demographic there are 3 points that need addressed

• Who is using the system?
• What functions do they require?
• What challenges does this group face?

This gives the design team a clear picture of what issues have to be addressed by the user interface and what limitations have to be imposed on the site. For example, when designing a technical blog about programming, the site usually will not have to cater to people with little technical ability and this can be defined as an assumption about the users. On the other hand when creating an e-Commerce Web site it would have to assume less technical ability as anyone might be interested in buying a product.

80 20 rule

When laying out a site, a designer should take into consideration what features a user will require. When it comes to UI design in most cases, 20% of the functionality of the Web site is used 80% of the time, this is known as the 80/20 rule. It is therefore important to identify the aspects of the site that users use most often and give prominence to those features, and to also try to keep them together in strong positions on the page. This gives the user key areas of the screen that they know they can interact with.

Function and appearance

Items on the page must look and behave in a way that is obvious and it must be really clear what their function is. Using icons is a common way of defining what function the buttons have, and there is often an obvious choice for what icon to use. A save button for example will almost always have a disk or a file folder as the icon accompanying it.

User centric design

It is important to a user that they can quickly find the function that they are looking for, so they don’t have to think about what they are trying to do. Jakob Nielsen states "If your users have many questions, it's a failure of your primary site design. It becomes not so much customer support, as much as customer complaints". This illustrates that if a UI does not do the work for the customer then the customer will place the blame with the UI. This becomes a major factor in the success of a site, especially considering that it is much more beneficial for a business to keep an existing customer, than find a new one.

Content

The quality of the content on a Web site goes beyond merely making the site interesting. This is of course an important factor, but the site must go further. Targeted content is an important method of pulling users into the site, keeping users on the site and guiding the user to where they want to go. Different sites will require focus on different sections. Unfortunately this is very much dependent on what the function of the web site is.

• The inclusion of keywords will improve search engine ranking
• Readable content and accurate information delivered in a timely and efficient manner will assist user decisions
• Interesting copy will retain users on the site

At times, these factors will conflict with each other. For example a passage of text that is overloaded with keywords will tend to be unreadable. To ensure a positive user experience it is imperative that the content makes sense and is relevant to the user. Appropriate keywords facilitate the external search engines to serve the correct page to the user. In most cases succinct content that is relevant to the subject matter will contain a lot of the keywords and phrases that the end user will search for anyway.

Look and feel

To create a positive user experience, the UI should have a strong design, not only from a functional perspective but a graphical perspective. If a design looks untidy or the layout is confusing it will be hard to navigate through, creating a negative experience for the user. The site must therefore concentrate on providing the function that the end user was originally looking for in an attractive and easy to use way. The main consideration for the look and feel of a site should lie with the function of the site. For example, a corporate Web site should look professional and clean where as in the case of an e-Commerce site the focus should be on show-casing the products that it offers.

Clean design

A UI should be simple and easy to navigate and a clean design helps to facilitate this as it tends to avoid clutter and superfluous images or text.
Some simple guidelines include:

1. Avoid clutter
   By overburdening the site with excess images and over designing elements, the Web site will start to look cluttered. It is tempting to keep adding things to attract users to different areas of the site. However, by adding too much, the flow through the site can be disrupted. This can be addressed at a very early stage in the development process by avoiding the shopping cart effect when requirements gathering, that is when gathering requirements the project owner is likely to want to keep adding things to the Web site until there is a saturation point of what is physically possible to do.
   
2. Pick a simple color scheme
   A color scheme in which each color complements the others should be defined. A strong color scheme provides definition for the site and ensures that the colors used by the site remain consistent. It can also differentiate each level of the site design from background down to the color of the text. Use of color can be very important in guiding the user around the site as it creates a visual definition between different sections. It should be noted that some colors have meanings for users. A common mistake in design is to try to attract user’s attention by using red text. This often clashes with the color scheme of the site, is often lower in contrast to its background, and also tends to have negative connotations for a user. Use of bold text or text with a border has a much greater impact for the user.
   
3. Ensure all text is readable
   Text should always be high contrast from its background ensuring that it can be read. Text that is unreadable will tend to get ignored or passed over by the user and does not have the same impact as text that clearly stands out from its background. Also it is important to ensure that heading text can be clearly associated with any passage of text it is linked to. the following figure shows two poor examples of the use of contrast and one good example.
   
   
   
4. Use subtle and consistent effects
   Many web sites use gradients or other effects such as drop shadows to provide emphasis and depth to different sections of the site. Many of these effects suggest a light source somewhere on the page and often a designer will have two elements in a design that suggest that the light source is in different places. It is important to ensure that these effects do not overpower what they are displaying or compete for the user’s attention.
   
5. Use a tried and tested layout
   When laying out the Web site the designer generally should avoid re-inventing the wheel. Most sites particularly corporate sites should tend to follow existing standards. By using a layout the user is familiar with, they can easier understand where things are. A designer can follow a different layout and it is important to note that this point is a judgment call. A bad design that conforms to a standard provides a worse user experience than a good design that does not conform to standards.
   
   
   
6. Put important information in the strongest part of the design
   The top left of a website is usually the strongest part of a design. This is likely to be the location of the corporate logo or the primary navigation on the page. It is also the location of most of the common navigation functions on a browser such as back or forward, and on the menu bar with the most used functions such as file, edit and so on.
   
   

The KISS principle

The KISS (Keep it simple, stupid) principle is an important methodology for UI design. The idea is to minimize complexity and make things as intuitive as possible by, as the name suggests, keeping it simple. It is important to constantly put yourself in position of the end user. When developing the interface, concentrate on providing clear visual cues to the user such as icons or labels and avoid giving the user too many options.

Fixed versus fluid

Navigation

Navigation through the site should be obvious. It should be located on the top or on the left side of the screen and should be consistent throughout. Dropdowns should be close to the top level item and navigation should behave in a standard and expected way.

Three clicks rule

The three clicks rule recommends that the user should have to use a maximum of three mouse clicks to get to the content they would like. However, as there is no evidence to support this rule, it is widely suggested that the user will be better served by ensuring that the content that they would like to find is in the most obvious place regardless of how many clicks they took to get there. The key is to balance the two schools of thinking and not to get too hung up on ensuring that the user clicks no more than three times. Well designed navigation and a clear easy to follow site map will provide much greater value for the user, than adding additional complexity to the user to shoe-horn the site structure into a site map that only has three clicks.

Web 2 0

When looking at the human-computer interaction (HCI) of a Web site, Web 2.0 techniques can ensure that the site is easy to use and gives information to the user in a clear way, as well as providing a mechanism for refreshing the parts of the screen the user is interested in more quickly. However the use of Web 2.0 techniques can prove to be a double edged sword, as over use or inappropriate use can lead to confusion or annoyance for the user. For example, if an animation on a pop-up is too slow, the user can lose patience with the system, or if the information they want to get to is hidden, then they will become frustrated at not being able to find it.

The best practices here are to:

1. Decide what library to use
2. Identify the sections of the site that will benefit most from using a Web 2.0 function
3. Deliver the key information that the user is interested in without requiring user action
4. Where possible, give the user a summary that can be expanded to more information
5. Don’t over use a function
6. Ensure that time based effects, such as animations, are kept as short as possible so as to not withhold information from the user
7. Always provide a no-script alternative
8. Keep effects consistent throughout the site

For more information on Web 2.0 and WebSphere Portal, see the Web 2.0 page in this wiki.

Accessibility

The Web Accessibility Initiative (WAI) defines accessibility this way. "Web accessibility means that people with disabilities can use the Web. More specifically, Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web. Web accessibility also benefits others, including older people with changing abilities due to aging."

See http://www.w3.org/WAI/intro/accessibility

As with Web site usability, accessibility is dependent on the demographic of users of the site. There is some overlap between usability and accessibility in that a user centered design will adhere to the standards set out in these disciplines. However, accessibility does cover some topics that usability does not cover. The key to what these are lies within the ability of the user groups the site is to be made accessible to.

Most sites will require basic accessibility features such as cross browser compatibility. Whereas other sections will require a more detailed approach implementing such features as variable text size, mobile support or screen reader compatibility. It is important to the success of the site to define what these requirements are at the start of the process.

Accessibility in WebSphere Portal

Accessibility is important for everyone. Web sites are primarily about communicating information with the widest possible audience, whether it is a news site, a commerce site or a technology organization like IBM; it is about information dissemination and communication. Making a site accessible is about removing the barriers that limit the groups of people that can receive the information the site provides.

The Lotus Web Content Management (WCM) system provides the development team with a platform and components to build an accessible Web site. Using the team’s existing skills and tooling the IBM WCM platform provides you with a foundation and management system to facilitate accessible web design and development.

WAI

The Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C) is focused upon addressing the needs for web accessibility. WAI provides a repository of the latest web accessibility guidelines and tools.

See http://www.w3.org/WAI/

Web content accessibility guidelines

The WCAG guidelines that have been set out by W3C are primarily intended for four main groups:

• Content developers (content contributors, presentation designers and developers)
• Web authoring tool developers
• Web accessibility evaluation tool developers
• Others who want or need a technical standard for Web accessibility

The WCAG documentation provides guidelines as to how to make web content, such as text, images, forms or sounds, accessible to people with disabilities. WCAG is part of a series of accessibility guidelines, including the Authoring Tool Accessibility Guidelines (ATAG) and the User Agent Accessibility Guidelines (UAAG).

See http://www.w3.org/TR/WCAG/

Standards W3C WAI and section 508

Making websites accessible is only really possible by adhering to the standards laid out in the WAI (Web Accessibility Initiative) & Section 508 guideline documentation. In addition, it is important to adhere to any regulations that are specific to the country in which the site is being deployed and need to be understood and applied appropriately. In the USA, Section 508 covers the legal requirements for web sites.

http://www.section508.gov/index.cfm?FuseAction=Content&ID=3
http://www.w3.org/Consortium/

Browser compatibility

There are currently more major browsers on the market than ever before, and ensuring that a site looks the same on all browsers has never been so important. If a site fails to render properly or fails to work properly then it can frustrate users, and may lose their interest entirely. Although most browsers should display standards compliant code in the same way, there is always a chance that a site will look different in each browser.

As new CSS attributes and HTML standards are released there are older tags and attributes that are no longer supported by the browsers. HTML standards are becoming more future proof. For example, XHTML is trying the take all formatting out of the HTML document. So future proofing and keeping the markup current is very important to ensuring that the site renders successfully.

The best way to ensure that there is a high degree of cross browser compatibility is to test the site in all these browsers. There are some things that the development team can predict and make efforts to resolve, however visually confirming that the site looks proper on all browsers is the only real way to be sure.

Define your support list

In the early stages of compatibility testing it is important to define the browsers that you wish to support. As new technologies are released and browsers become more advanced inevitably older browsers will become deprecated. There will also be a noticeable drop in the browsers market share as users upgrade to the latest versions of their preferred browser. However this drop off in usage will tend to happen slowly rather than overnight and this can mean that requirements to support older browsers are necessary. It poses the question; to what level should older browsers be supported within the system?

There are three levels of support the development team should consider:

1. Does the system look and function identically in each of the browsers this system is designed to support?
2. Does the system look and function to a high standard but not look identical in each of the browsers this system is designed to support?
3. Is the system navigable in each of the browsers this system is designed to support?

Obviously the more browsers a developer is required to support the longer it will take to develop and test. Also with older browsers there may be aspects of the design that are not possible with the tools supported by the browser. It may be prudent in this case to just ensure that on older browsers the site looks presentable and easily navigable.

At the very lowest level of cross browser compatibility the user should be able to find their way round a site in the same way in each of the browsers on the support list. The look and feel may vary slightly on each browser but this is a secondary to functionality.

When defining the list of supported browsers the development team should first list all the major browsers and versions of those browsers then agree with the project owner how rigorously the browsers should be supported. This information should be fed to the designers of the user interface to ensure that there is nothing in the design that cannot be produced in a supported browser.

---

Table of Contents | Previous Page | Next Page