This is a community wiki. Be sure you are logged in to edit, comment, and add pages. Not a member yet? It's free and simple. Click Login in the upper right corner and Register.
View a PDF of the original wiki content produced in March 2008 by Lotus and IBM Redbooks.

Project considerations

If you have experience building Notes Client applications, you might find that Web projects are similar. Of course, once your users are in a Web client, expectations change dramatically. Your application must compare favorably with the navigation, page flow, and visual experience on many professionally designed Web sites.  To do this, you need a good multi-discipled project team. This team usually includes a business client, project manager, and programmers depending on the size of the project.

When building Web applications, a graphics designer with Web experience should also be involved in the project. Graphic designers should not be seen as "button makers", as they so often are in technical projects. Graphics and product designers have been trained in creative exploration techniques to refine and improve user experiences, and you should do your best to take advantage of these skills.

Another key member of the team is the client representative. This could be the client, but most likely a member of the internal team who represents the client in the day-to-day project decisions. This person should not be a technical member of the team but should understand the project goals and constraints. The key responsibility of this role is to ensure that the client/user/business point of view is reinforced throughout the project and provide resource to test ideas, resolve issues and communicate with the client as needed.

If you are working independently and don't have access to these additional resources, be creative in finding others to perform these roles. You or your client may have access to design resource on a short term basis and you can ask a college to represent your clients point of view.  Even the most experienced technician professional can benefit from these perspectives during the course of the project.

Visual design considerations

When you are involved in Web applications design, you may be handed a design layout at the start of the project or have the opportunity to work with a graphic designer to develop the application. Even if you are given a layout, you may need work with the designers to refine it deal with technical limitations. Designers are not always technical, but they have been trained to deal with technical constraints, so be patent and clearly explain any limitations which impacts their design, and work through it.

Because these are all inextricably connected, we cover navigation and page flow with visual design considerations in the following sections. If you are working with a designer or designing it yourself, follow the guidance presented here.

Get organized

• Use a mind-mapping tool to categorize content and help design the primary and alternate navigation.
• Use a flowchart diagramming tool to map out any processes.
• Find and isolate common processes and identify patterns.
• Prioritize elements that support both short-term and long-term user/application goals.
• Use this information to help with the following tasks:
  • Confirm your assumptions.
  • Set design goals and expectations.
  • Educate stakeholders.
  • Coordinate the development team.

Keep it simple and consistent

• Make it easy to get around:
  • Use simple menus that do not have too many levels.
  • Avoid drop-down menus, but if you need to use them keep it to two levels (to avoid mouse "gymnastics").
  • Put the next tier of menus on the page (as a second row or as a sidebar).
  • Keep end user actions together and make them easy to find.
  • Put key actions at the top and bottom of working area to avoid scrolling.
• Make it easy to figure out where you are:
  • Use clear readable page titles with enough white-space to set it apart from the rest of the page text.
  • If page titles are ambiguous or repeated more than once, precede it with the logical parent section e.g. "Customer Service - Feedback"
  • Make sure you have an HTML Title tag in the page header. It should have the site/application name and the page name e.g. "Sample.com - About this application"
  • Use breadcrumbs whenever possible, but use short page names as "crumbs." You can design your application with two titles for each page, one for the page and a shorter one for use in breadcrumbs, HTML Titles, and user friendly URLs.
• Keep relevant information handy:
  • Keep second-tier information on the page to let users move through without having to move back up.
  • Supply supporting information when gliding users through a process.
  • Think of creative ways to provide context-sensitive help (pop-ups, using title="help text" parameters on <DIV> and <SPAN> elements, etc.).
  • If you are guiding a user through a critical process, keep distracting information off the page, such as checkout on a purchasing application, or approval on a workflow application.
• Think about relevant "look and feel" requirements:
  • You may have specific requirements regarding the Web site look and feel. Be aware these needs and wishes.
  • Many organizations or companies have user interface standards that address their requirement for a common look and feel for all their web pages. Familiarize yourself with these standards and requirements to make sure they are addressed in your design.
  • To avoid visual ambiguity:
    • Keep the look and feel clear and consistent.
    • Don't crowd the page.
    • Visual elements, blocks of information, margins, and so on  etc. should not move around from page to page (add this to QA criteria).
    • Use whitespace appropriately (not too much or too little).
    • Make sure margins are consistent and line up between vertical sections.
    • Use color consistently, don't mix shades, don't have clashing colors, and make sure colors have enough contast to be readable.

Remember to consider the content

Content is the key to a successful site. As noted previously, understanding the nature of the content within your site or application determines the structure and design. You must also consider the following items in regard to content:

• Where the content is generated
• The result of input into an application
• Whether it is provided by another application
• Whether it is created centrally by specific department
• Whether it is produced as part of a participative process
  

For more information about content, see Thoughts about content

Architectural considerations

While there is no finite checklist, any architectural planning for application development projects require that we consider seemingly unrelated variables that will ultimately influence the overall application. In the following section, we outline specific considerations and explain their importance.

Who will use this application

While it may seem a basic question to ask who will use the application, the answer we get is often the most critical to the application architecture process. For example, let's say that we are creating a Sales Force Automation application for Riverbend. This application has a target user audience that consists of sales and sales associates, customer service, and management. Understanding both how and where these particular business units work, as well as what technology they have available to them, all-but-define your application architecture.

• Riverbend has an extremely mobile salesforce, who rely on their Blackberry mobile devices and primarily keep their company-issue notebook computers in their home offices.
• Sales associates are primarily based out of one of several office locations, using a combination of notebook and desktop computers.
• Customer service is based out of Riverbend corporate headquarters and want to tie this application in with their existing Notes Client-based CS application.
• Management includes executive level and VIPs who want to review the information in a "sales pipeline" and require reports that are both functional and "visually stimulating".

In order for an application to be successful, we need to architect it to specific functional requirements of the intended user community. For Riverbend's Sales Force Automation application, this includes accounting for the mobile salesforce, the customer service application integration, and various metrics reporting.

What are the organization's current technology investments

Cataloging our organization's current (and future) technology investments allows us to understand our architecture options. Just as when we asked who will use this application, by questioning the organizations current technology investments, we can understand which technology we can use to provide our user community with a solution. Knowing which  technology is (and will be) used by the organization, and possibly more importantly how the technology solutions portfolio will be used provides a developer with other vital information: "What technology do I not need to consider?"

For example, Riverbend is currently using Microsoft Office as their productivity suite. There is no intention for Riverbend to adopt a competing productivity suite, and plans are already in place for future upgrades pending future releases. Knowing this, we can utilize Microsft Office-specific functionality and integration-points in our applications without needing to consider a move to a different technology.

What is the expected life cycle of this application

Some development projects result in the creation or maintenance of applications that address business requirements, while other development projects result in [_sunset_] applications or applications that are used to address a particular and immediate business need while a more "enterprise"-level solution is tested and deployed. By understanding the expected life cycle of our applications, we can understand both the complexity and flexibility of the application. For example, a sunset application may not require the built-in maintenance that a non-sunset application. Non-sunset applications often require an architecture that allow the application to be self-maintained and designed to easily allow revisioning. Alternately, a sunset application often requires an architecture that facilitates easy and immediate exporting of all data to the specific target solution.

In addition, by understanding that our application is a sunset application, we can provide feedback on the research and intended deployment of a target solution and can even  alleviate the need for such a target solution.

Most sunset applications become sunset applications due to a given project champion or decision maker(s) not understanding the flexibility of their current technology investments. We have the opportunity, where and when appropriate, to advise on a better way of utilizing current technology investments that very well may, unknown to those individuals deciding on a particular second-version solution, completely address the business requirement.

When is the application deployment or deliverable expected

Understanding the expected deployment or deliverable date or dates for your development projects can greatly impact the architecture of your applications. For example, high-priority/quick-deliverable solutions often require that we refrain from trying more experimental technologies and methodologies in favor for production-ready and time-tested architectures.

Where will this application be used

Understanding the geographic locations can greatly influence and affect the architecture of our solutions. Projects in which low-bandwidth areas, for example, can create "thin-client" or even offline application architectures.

How will the user community use this application

Understanding how the user community will use your application can greatly influence your solution architecture. This is often achieved by understanding the business process and inter-department workings of your target user audience.

Additional topics

• Architectural patterns
• Thoughts about content