Return to Top

Web Patterns :
Building Blocks for Web Development

A Conceptual Model for Solid Design

In Draft (not recently updated)

This article talks about another concept to help focus a development team on the task of developing a web site. It is related to the 3DHLX Process Guideline.

The current Web Pattern Chart is available in PDF and PNG format.

The Premise of Patterns

In Computer Science, the concept of patterns is used to help students remember useful data structures and algorithms. The patterns are building blocks from which real program designs take form. The practice of using patterns as mnemonics dates back to the beginning of language. Pictographic symbols were used as patterns for letters and words in early writing systems. These symbols became abstracted over time to make them quicker and easier to write.

In "A Pattern Language for Web Usability" by Ian Graham, a series of heterogeneous patterns are proposed for the purpose of making communication about the usability of web sites simpler. These 79 patterns form a language that encapsulates the cross roads of software usability and commercial web site design. While highly useful in specific scenarios, the pattern language in this book lacks several concepts for the broader web design community.

Arguably too large, the web pattern set that follows consists of 201 patterns. This number includes 5 "category" patterns that categorize the 28 "key" patterns. These lay the foundation for organizing the remaining 168 concrete patterns in to some decipherable groups.

The charts linked above display a "work in progress" road map of web development patterns. Not all possible connections have been drawn because of the complexity of arranging so many patterns. More than likely the patterns will have to be divided among several smaller road maps so that all connections can be drawn.

Below is a full outline of the patterns depicted in the chart. Each pattern is described and the most relevant relationships among other patterns are discussed.

Pattern Outline

Stakeholders - Category Pattern

Aguably the most important pattern, [[Stakeholders]] are people. There are three groups of people that appear in web pattens and they are distigusihed by their relationship to the web developlment process. An individual's membership in one of these groups may overlap, but the implications of both rolls are important.

[[Clients]] are the people that want the web site created, the [[Project Team]] members are the people that are developing the site, and the [[Audience]] are the people that will use the site. Each of these groups have some vested interest in the development of the site. Clients have a particular goal that the web site will help them meet. The Project Team wants to develop the best site possible so the end product must help the Client meet their goal. People in the Audience act on their own [[Motivation]]s which might or might not work well with the way a site is designed. The Project Team must also take the Audience into consideration when building the site.

By understanding the [[Processes]] that drive a web site and carefully applying [[Qualities]] to the site they can make it a better product for each of the steakholders.

Client - Key Pattern

Requirements

In communicating with the [[Client]], the [[Project Team]] will receive a wide array of expectations for the web site that is being produced. These expectations of the Client are Requirements. They may be features of the site or outcomes of the [[Audience]] using the site.

Requirements should be collected in clear consice language. If there is any ambiguity to their meaning, the Project Teem needs to get clarification from the Client. The Requirements should then be futher scrutinized by the Project Team against the Client's [[Business Process]]. Requirements tend to be very specific and may even be short term. Target sales may indicate a Requirement, but that requirement could easily change between the time of the [[Design]] phase and the [[Deployment]] phase. Also, the Project Team may find that some Requirements contradict each other in specific cases. Each Requirement should be prioritized by the Client so that these conflicts may be resolved. By understanding the Business Process the Project Team can find the Client's underlying need behind various Requirements.

All Requirements should be considered during the decisions made during the Design phase. Oversights can lead to lost time and wasted effort if changes or conflicts arrise during or after the [[Development]] phase.

Business Process

Every [[Client]] has a unique and complex web of [[Workflow]]s that allow them to conduct day to day business. Some of these workflows may be formal policy, while others are conventions follow by staff that have never been commited to paper. Individually and combined, these workflows represent Business Processes. [[Requirements]] may give the [[Project Team]] insight on the Client's motivations and goals, but understanding the underlying Business Processes will give them a better understand for how the Client operates.

There are [[Conventions]] for web sites that the [[Audience]] may be familiar with. More so than with direct interaction, the Audience is in control of their interaction with the Client though the web. These factors will drive [[Interaction]] with the Client, so some Workflows will have to be tailored for the web. This translation may present challenges in some cases, but present opportunities in others. Because interaction is abstracted by the web, the workflow for the Audience may be altered in a way that best suits them while the Client continues to receive information in the formats they are accustom to. In this way the web site works better for both [[Steakholders]].

Use Cases

Because web sites are user driven, the [[Audience]] is the key consideration behind any web development. Based on their own [[Motivation]], the Audience will use a site successfully or unsuccessfully to work towards a goal. By anticipating the Audience's needs the [[Client]] and the [[Project Team]] can develop Use Cases to provide the Audience with [[Appropriate]] [[Content]], [[Links]], and [[Interaction]].

The Use Cases represent predictions for how the Audience will find what they need and can help establish the [[Layout]] of the site and how [[Navigation]] should work. They help ensure the site meets the [[Requirements]] and are often modeled on the [[Workflow]] of the [[Business Process]]

Project Team - Key Pattern

Business Objectives

The process of developing a web site is complex. To make a successful site the [[Project Team]] must juggle the [[Audience]]'s [[Motivation]]s and the [[Client]]'s [[Requirements]]. Without a clear plan for development the project will fail.

It is important in the [[Design]] phase to establish the Business Objectives for the project. The Business Objectives are the goals set by the Project Team to benchmark the delivered site, and help ensure quality.

The Client has a set of goals. They want to enguage the Audience through a web site, and they want the interaction to have a controlled outcome. In some cases the Audience's Motivations will complement the Client's Requirements, and in other cases they will contradict each other. For example, companies often want to collect information about their visitor's use of the web site and how they found it. The visitors likely have an expectation that their privacy will be respected.

To better understand a Client's goals It is often important to get a bird's eye view. Often clients will present specific Requirements for a web site that may not reveal the underlying [[Business Process]]. Satisfying the Requirements is important, but understanding the Business Process can put Requirements into context and make their real meaning more clear.

Colaborative Stakeholders

The [[Client]], [[Project Team]], and [[Audience]] are all [[Stakeholders]] in the development of the web site. Even though the Audience may not have any direct control of [[Design]] or [[Development]] their needs and expectations must be considered for the end product to be succesful during [[Deployment]]. For this reason is it important to have an [[Audience Advocate]] in the [[Project Team]] throught the process.

Keeper of the Flame

The Keeper of the Flame is a member of the [[Project Team]] responcible for keeping development within the agreed parameters. They will often be the one to [[Document the Attempt]] during the [[Design]] phase and should be the first to challenge any attempt at [[Change]]. It is vital that they work closely with the [[Audience Advocate]] since they are the only voice for the [[Audience]] until [[Deployment]]. They must also juggle the [[Client]]'s [[Business Process]], [[Requirements]], and [[Use Cases]], so their job is not an easy one.

Audience Advocate

The Audience Advocateis a member of the [[Project Team]] responcible for keeping development in lie with the needs and [[Motivations]] of the [[Audience]]. They should have a clear understanding of the intended Audience, so interviews and [[Testing]] with live individuals in the Audience is recommended. It is vital that they have the ear of the [[Keeper of the Flame]] since they are responcible for keeping the project on track. The Audience Advocate may also be needed during [[Deployment]] to train the [[Client]] or group responceible for maintenance once they have [[Control]] of the site. With the help of the Audience Advocate, they can better understand how best to aproach interaction with the Audience and above all, ensure the web site has the [[Human Touch]].

Encourage Creative Acts of Destruction

There are a wide varieties of barriers that can arise from poor web design. These may come from pages that are not [[Usable]], [[Efficient]], [[Compliant]] or [[Accessible]], but they can also have roots in [[Content]], [[Navigation]], [[Aestetics]], or [[Interaction]] that is not is not [[Appropriate]].

Destroying these barriers should be seen in a positive light, eventhough the process should be applied with dicipline.

Avoid Destructive Acts of Creation

In the proccess of re-creating a site that already exists, the [[Project Team]] will often be tempted to "start from scratch". Unintentionally they my throw the baby out with the bath water. When the [[Client]] and [[Audience]] have already established a relationship through a web site, drastic changes can cause damage.

It is important to ensure that the [[Audience Advocate]] does research into usage of the previous web site and [[Solicit Feedback]] to find out what the Audience likes and dislikes. This should be the driving factor behind new development and the [[Keeper of the Flame]] should [[Document the Attempt]] to keep the good and replace the bad.

Audience - Key Pattern

Solicit Feed Back

Feeback from [[Testing]] by the [[Audience]] during [[Design]] and [[Development]] can be the single best indicator to a site's chance at success during [[Deployment]]. Sometimes the [[Client]] or [[Project Team]] may not understand the [[Shared Model]] as well as they thought they did. Poor results from testing can be the early signal that saves a lot of time and effort developing down the wrong path.

Even during Deployment, Soliciting Feed Back can help ensure that the web site stays on the right track and will give it the [[Human Touch]] that the Audience expects.

The Human Touch

The [[Audience]] will respond better to web sites when they feel that they can get in contact with a live human being if the need arrises.

In an ideal situation the [[Use Cases]] for a web site will cover what most users will want to do infrequently and what a minority of the users will do frequently. It is almost impossible to anticipate they many things that a minority of the users will do infrequently. Giving users [[Context Sensitive Help]] may solve some issues, but to ensure that every one has an opportunity to get real help the web site should also provide [[Context Sensitive Contacts]].

When possible and appropriate these should be labeled with real names and sometimes even faces. They may be in the form of an e-mail address, or a phone number. Some sites may even be able to employ an "Instant Message" form of communication. "Chat" applications that put multiple users in one room may not be appropriate in most circumstances.

Contact through these channels should have quick turnaround time and should not be automated. The web site is already an automated system for communication, and without some option for interaction with a live human being it will lack the Human Touch.

Layers - Category Pattern

Web sites are abstract artifacts of technology. They appear to the end user as interlinked collections of words and images on the computer screen, but they exist as binary data on magnetic disks. Conceptually there are three [[Layers]] of information organization that come together to form a web site. The most obvious layer is the [[Hypertext]] layer that is the "page source" of each individual web page in the site. Hypertext provides [[Content]] information with [[Structural Tags]] to give the content semantic meaning.

The way in which information is divided, stored, and regrouped is the [[Layout]] layer. [[Static]] sites commonly divide the information into pages and each page is a file. These files can be arranged into different folders. [[Dynamic]] sites may have the information stored into units smaller than a page and these units are stored in a variety of formats, such as a database. These units are then reassembled into a page for delivery to the end user. In some cases Layout directly influences [[Navigation]] through the site and in other cases the relationship may be more cryptic. Similarly, a site may benefit from a logical correlation between its [[Architecture]] and layout.

The third and final layer of a web site is the [[Expression]] layer which controls the [[Aestetics]] of each page. It integrates the [[Text]] [[Content]] represented in the Hypertext layer with other Content in the form of [[Images]] and [[Multimedia]] to present the finalized page to the end user. The Expression layer may also provide a [[Sense of Location]] based on [[Context]] and the [[Layout]] of the site to aid [[Navigation]] .

Hypertext - Key Pattern

The Hypertext layer is the combination of [[Text]] and HTML Tags to create units of [[Content]]. These units can arbitrarily be broken down in a number of ways including but not limited to: pages (<html> tags), paragrahs and [[Headers]] (<p>, <h1>, <h2>, etc. tags), and containters (<td>, <span>, or <div> tags). These [[Structural Tags]] allow web pages to be sectioned in a flexible variety of way.

The primary function of the Hypertext layer is to provide structure to Content in the web site. It gives structure in the form of sections and semantics using the Structural Tags. The structure tags provide the mechanisms needed by the [[Expression]] layer to style the web page and the [[Layout]] layer to interconnect the pages.

Plain text has been in use on computers since before their introduction into the home market in the 1970's. In this form text is presented without any formatting except the arbitary use of white space. It is clean and simple, but can be hard to read, organize, and manage in large quantities. The logical evolution of Plain Text is Formatted Text in which portions of the text can appear in a different [[Size]], a different [[Font]] face, in different [[Color]]s, or in an alternate style such as bold or italics to create emphasis. This [[Formatting]] can help break the information into more digestible [[Sections]] and draw attention to or attach [[Semantic]] meaning to select words.

Changes in formatting have arbitrary meaning, so various [[Convention]]s have been developed over the years to apply Semantics to formatted text. If a document is moved from one formatting convention to another, or the convention changes, the text must be reformatted. HTML began as a tag set to format and section documents in addition to the primary function of creating [[Links]] between them. Over the past decade it has evolved into a more Semantic language by moving away from using formatting specific tags.

In modern applications, the HTML portion of a web page is relatively devoid of formatting information. Bold tags (<b>) have been replaced with strong tags (<strong>) to indicate the Semantic intention to draw attention. Formatting is applied to the web page in the Expression layer by a [[Style Sheet]]. This allows for greater flexibity by decoupling the Hypertext layer and the Expression layer. A new and fresher look can be applied site wide in seconds by swapping out Style Sheets. In earlier web pages the Hypertext and Expression layers were tightly interwoven which made pages less [[Consistent]], [[Change]] harder, and [[Content Re-use]] a chore.

Content

Content is the information contained in a web site. The most prolific form of this information is [[Text]], but [[Images]] and other [[Multimedia]] are also considered Content. The text of a web site is interwoven with [[Structural Tags]] to form the [[Hypertext]] layer. The tags provide formatting and structure for the information through the [[Expression]] layer.

Content is often broken down into units, the most contentional of which is the page. In [[Dynamic]] web sites content may be broken down in any number of arbitrary ways, depending on the [[Content Management System]]. Greater flexiblity with breaking up and re-combining content units allows for [[Content Re-use]].

Text

All information in the web site should be available in the most basic form, Text. It is the most [[Accessible]] form of information and is needed to support [[Old (Text, Small Screen) Browser]]s.

Other forms of information such as [[Images]] and [[Multimedia]] can be more effective means of communication in some circumstances, but they require facilities that are not always available. Interactive forms of Multimedia may not be [[Printer Friendly]] or the person browsing the web might not have the [[External Applications]] needed to view media in that format. Providing [[Alternative Text]] for all other types of media helps to make a site Accessible.

Text in the web site should have [[Consisent Writing]], use [[Acceptable Wording]], and be comprised of a series of [[Short Texts]] that can be combined for printing purposes or viewed separately for web browsing .

Text Collections

In sites with large amounts of [[Text]] information, it is necessary to plan for extensive information [[Architecture]]. Doing so ensures that there is a logical and consistent method for finding the desired information.

When content is written specifically for the web it is best to create it in [[Short Texts]] but often times there is existing information that needs to be made available on the web and either it's structure or standard use does not all it to be broken up effectively. Plays for example, consist of lines which are too short, and scenes which may be too long. Another consideration is the cost of converting such texts. It may not be cost effcient to structure and break up many documents made in the pre-web era.

Material that was not designed for the web can be kept in [[Text Collections]] of whatever size is most appropriate. These collections should be in a format that allows for [[Searching]] and the web site should provide a mechanism for [[Browsing]] them.

Short Texts

When possible, web sites should be broken down into small pages of information. This makes the presentation of information uncluttered and easier to comprehend. Reducing the need to scroll through a page reduces the likely hood that information will be accidently skipped. Breaking information in the site into Short Texts will improve [[Usability]] by keeping pages small and easy to read.

[[Content Management Systems]] can make this task easier. Content can be authored in sectioned documents and then be broken down based on [[Structural Tags]] such as [[Headers]]. For delivery to the web the information can then be organized in short pages with [[Consistent]] [[Navigation]] beween them. If the user then wants a [[Printer Friendly]] version of the information they can print one page or the Content Management System can recombine all of the sections to create one document.

Structural Tags

The Structural Tags of HTML are designed to give [[Semantic]] meaning to information and break it into [[Sections]]. They may have default [[Formatting]] rules attached to them that effect the appearance of the [[Content]], but they should be used for the Semantic meaning they confer not the appearance they render. The appearance of all tags can be altered with a [[Style Sheet]].

Structural Tags used for sectioning typically consist of:

• [[Headers]]: h1, h2, h3, h4 ,h5 ,h6
• Paragraphs: p
• Dividers: div - Used to create [[Box Layout]]s.
• Blockquote: blockquote

The other Structural Tags may be used for sectioning in certain circumstances:

• Table: table (th, tr, td) - Intended for [[Data Tables]], but can also be used for [[Table Layout]].
• Lists: ol, ul, dl (li, dd, dt)
• Spans: span

Using the [[Appropriate]] Structural Tags is important. It aids [[Usability]] and [[Accessiblity]], and also makes it easier to [[Re-use Conent]] and helps [[Searching]].

Headers

One of the more contentional ways to create [[Sections]] in a document is with Headers. Each header acts as tltle for the section. In HTML there can be up to 6 levels of headers, the "h1" is used for the largest section unit, the "h2" is used as sub-sections of the "h1" and so forth. Many designers avoid this [[Convention]] because the default size for "h1" is too large or the "h4" later headers are too small. These can be easily adjusted using [[Style Sheet]]s, and headers should be applied properly because they effect [[Accessiblity]] and [[Search Engines]]. Headers should only be used for their [[Semantic]] meaning.

Data Tables

Two dimensional tables of data are used in a wide variety of publications. The "table" tag was introduced into HTML to better facilitate the use of tabular data. The alternative was to insert images with the tabular data as a graphic, but that method created barriers to [[Accessibility]] and [[Usability]].

Proper Data Tables have both "th" (table header) and "td" (table data) tags. Any column that labels values in the cells beside it should be made of headers, and rows should be made of headers when they label values in the cells below or above them. Data tables where there is more than one column with headers, more than one row with headers, or where the "td" cells do not always line up with their column or row headers must use complex referencing to identify these relatioinsips.

A table with no table headers may be considered by some browser to be a [[Table Layout]]. The pratice of using tables for layout it frowned upon to varrying degrees in different circles, but the general consensus is that [[Box Layout]] is prefereable and this sentiment is growing stonger over time.

Layout - Key Pattern

At the macro level, a web site is a collection of information in the form of [[Content]]. The information is grouped into pages and the pages are connected by [[Links]]. The way information is grouped and interlinked creates relationships between the information and the pages. In The Layout layer, information is grouped to form pages and the pages are interconnected by some [[Navigation]] scheme to make finding the information possible.

The Layout layer draws it's name from site layout, rather than page layout.

In [[Static]] sites, each page is a file in a directory. The structure of directories may be one indication of the site's layout. Each page has a [[Path]], or address on the web based on it's location in the web site's directory structure. Web savy users may use their address bar to get a [[Sense of Location]], but most will rely on clues presented on the page through the [[Expression]] layer such as [[Structured Menues]], [[Navigation Bar]], and [[Visible Landmarks]].

Pages in Static sites often link to information in other pages rather than include it the way some [[Dynamic]] sites do. Dyamic sites have more flexibility in the way that information is organized because pages can be created on demand by the [[Server]] containing a combination of information from various sources. In these sites the Path may not provide any useful information to the user, so they must rely on features such as [[Breadcrumbs]] and [[Sections]].

In every site there is an underlying [[Sitemap]]. This is a conceptual and often complex diagram of every page connected to every other page through a web of [[Hypertext]] Links. In the [[Design]] phase it is often helpful to create a preliminary Sitemap covering the main information relationships. The Sitemap should never be employed as the primary Navigation aid since they are large and very hard to maintain on Static sites. Instead, the Sitemap should give rise to the [[Architecture]] of the web site in which the [[Navigation (is) Flavored by Content]].

Path

Paths determine where files in the web site are stored. In [[Static]] web sites the Path is always detemrined by the way files and and directories are arranged on the [[Web Server]] and the Path maps directly to the URL. Arranging files into multiple directories that are nested within each other as little as possible creates a shallow directory structure. When there are a lot of pages in a web site this can mean long lists of files and directories for the web developers to look at, but it creates [[Short URLs]] for the audience. Any URL that would likely be published in print, spoken to a user, or shared via e-mail should be as short as possible. Paths should also be structured for [[Lowercase URLs with No Underscores]] in them. This will reduce the number of[[Mistakes]] made when trying to remember or type the URL.

Because the Path often corresponds to the URL, it can give more advanced users a [[Sense of Location]]. It would be unwise to rely on this as the only means for the [[Audience]] to determine where they are in the site. Paths do always not correspond to [[Architecture]]s such as [[Sections]] and [[Multiple Routes]]. Users can get lost in a maze of [[Links]] when their only point of reference is the URL. In [[Dynamic]] sites the URL may not provide any useful information at all.

In [[Dynamic]] sites, some or all of the URLs may correspond partially to Paths to scripts stored on the Web Server, and partially to directionns to the script telling it what [[Content]] should be loaded. These directions are often cryptic and therefore useless to the Audience. Readable URLs are prefereable, but not always practical for large Dynamic sites. Even when URLs to Dynamic Content can't be readable the same content should always be available by [[Persistent URLs]]. This ensures that if a user [[Bookmarks]] useful content or wants to send the information to another authorized user they can simply cut and paste the URL. Occasionaly in [[Task]] oriented pages, it may not make sense to allow a user to bookmark their place or share Dynamimc pages with other users, but these are pages that are more about accomplishing a [[Workflow]] than serving Content.

Persistent URLs

Whenever possible, URLs to [[Content]] in the site should be persistent. This means that a URL that works for one user in the [[Audience]] should work for another so that they may share information by communicating URLs. Persistent URLs also work over time. If content must move it would be preduent to provide a considerate and informative [[Redirect]] using the [[Rhetoric of Arrival and Departure]]. This will help ensure that frequent visitors are made aware of the change and can update their [[Bookmarks]].

For general Content, such as information about a subject, it often is approriate to allow the content at one URL to change over time to maintain [[Freshness]]. For news articles however, there may be two conflicting needs. Some users will want only the most recent article, but others will want a specific article that was published in the past. When this happens the article needs it's own Persistent URL separate from the page where news changes daily.

Considering both the Audiences' needs and the logistics of [[Workflow]] is important in determining what should have a Persistant URL in a [[Dynamic]] site. Information that could be shared between users should have a Persistent URL. Information that is unique to a particular execution of a task by a user would most likely not be shared. The exchange of credit card information for example. In this case it is more important to worry about Workflow issues such as [[Reversible Actions]] and [[Handling Duplicate Requests]] . In the cases where Persistant URLs do not make sense, there are often [[Security & Privacy]] concerns that should be addressed.

Short URLs

Short URLs help the [[Audience]] in a number of ways. They are easier to commnicate, remember, and type thus reducing the chance of [[Mistakes]]. The URL of a site is the only way to publicize it in print documents and shorter URLs are easier to place. Line wrapping can make URLs hard to read.

Pages with Short URLs are more [[Printer Friendly]] because most print-outs put the URL in the margin so that someone that wants to find the online version can do so. Any page that is intendedd to be a [[Point of Entry]] should have a Short URL.

Both directories and documents in the web site should be given short names to make the URLs as short as possible. In some cases it may be better to fully spell out words than use arbitrary abbreviations. Human judgement is required in these situations.

Lowercase URLs (no "_")

Another tactic to reduce [[Mistakes]] in entering URLs is to only allow [[Lowercase URLs with No Underscores]]. Lower case letters are important on Unix/Linux based [[Web Servers]] because the [[Paths]] they use are case sentitive. "web/" and "Web/" are two different things on these web servers, even though the web [[Browsers]] may be on case insensitive computers.

Because of this, it is easier for users to know what case to use if there is a [[Consistent]] naming [[Convention]]. The simplest convention is to always use one case. Text in all upper case letters creates too much emphasis and gives the imporession of shouting:

HTTP://WWW.ENGR.NCSU.EDU/WEB

Text in all lower case letters makes more sense and is easier to read since people read them more frequently than capital letters. Even propernames and acronyms should be lower case in urls.

Underscores should be avoided in URLs because the default appearance for a [[Link]] on the web is underlined. The combination of the underlining and an underscore character can result in something that looks more like a space, which is not allowed in URLs:

http://www.engr.ncsu.edu/web_information

Dashes, numbers, and lower case letters are all aceptable characters for URLs.

Site Map

During the [[Design]] phase it is a good idea to get the "big picture" on the web site. Large sites should be divided into [[Sections]] and all [[Content]] will go into one or more of these Sections. A visual representation of this arrangement of information is called a Site Map and it can be a useful aide in refining the [[Architecture]] of a site and may give some helpful clues on how to design the [[Navigation]].

Because Site Maps are long lists they are not often useful as Navigational tools themselves. In the late 90's many web sites employeed Site Maps for this purpose, but this indicates a problem with primary navigational structures since they should adequitely represent the site's structure. [[Navigational Bar]]s, [[Structured Menus]], and [[Search Enignes]] are much better navigational tools than a Site Map.

Point of Entry

A web site's [[Audience]] begins their journey at a [[Point of Entry]]. This may be one or more [[Homepage]]s designed for different groups in the Audience., but it could just as easily be any page that they find by [[Search Engines]], links from other web sites, shared URLs, or [[Bookmarks]].

It is important to anticipate the different Points of Entry and ensure that the Audience always has a [[Sense of Location]]. The [[Rhetoric of Arrival and Departure]] is also crutial on the first page. Without it the visitor may go elsewhere.

Expression - Key Pattern

In the Expression Layer, [[Hypertext]] pages are styled in the [[Browser]] to create their appearance for the web user [[Audience]]. While the [[Layout]] layer determines what information will appear on any given page, the Expression layer dictates where and how it will appear on the screen, in print, or whatever media the web page appears.

Every aspect of appearance is controled by the Expression layer including:

• [[Text]] [[Formatting]] such as [[Color]], [[Font]], [[Size]], white space [[Margins]], and [[Spacing and Breaks]] )
• [[Images]] and [[Multimedia]]
• The [[Position]] of information and graphics on the page

The [[Wireframe]] is a protyping tool used for page layout in the [[Design]] phase. It specifies how the information on each page will be presented. In modern web sites, [[Table Presentation]]s are being replaced by [[Box Presentation]]s since the table tag (<table>) was intented as a [[Semantic]] structure to organize [[Data Tables]]. The div tag (<div>) that most often provides structure to the Box Layout is more flexible and better suited to the task of flexible positioning.

Another useful feature of the Expression layer is that it allows the Hypertext to be written in a [[Linear Order]], while being presented in a variety of ways. It can create columns and move information around the page to best suit different media and facilitate [[Content Re-use]].

Formatting

Formatting can apply to all visual elements in a page, but most commonly refers to the formatting of [[Text]]. Clean professional content requires a consistent style with deliberate restraint of [[Font]]s, [[Color]]s, and other [[Aestetic]] attributes. The [[Size]] proportions of different blocks of text, [[Images]], and white space on the page is an important consideration.

Formatting may need to be different on the computer screen and in print. Serif fonts have long been considered easier to read in books, but studies show that on computer screens with limited resolution sans-serif fonts are more readable. Both styles of font come with certain connotations. Serif is classic and traditional, while sans-serif is more modern and simple. Careful choice of one, the other, or both are needed.

On the computer screen it is particuarly important to present information in shorter, more digestable units. [[Short Texts]] make information on a web site easier to process. Columns with different groups of content side by side can make a web page longer, but thin columns are easier to read. One chunk of content should not be split into multiple columns for display in the web browser. Longer texts running across multiple columns make sense for print media, but break important conventions on the web.

In steaf of applying formatting inline with the font tag, use [[Style Sheets]] to apply consistent formatting rules to all content based on the existing semantic tags. Apply inline formatting sparringly. The most important thing to remember is that [[The Web Is Not Print]]. There is never any garuntee that content will be displayed in a certain way. The [[Expression]] layer is important polish to the whole web package, but cannot replace careful [[Layout]], sound [[Navigation]], and useful [[Content]].

Spaces and Breaks

As HTML evolves, one feature that has proven problematic was controlling spaces between words and lines. Older versions of HTML, some official and some not, define various remedies from the <nobr> tag to the &nbsp; entity. The current versions of HTML provide the <br> tag to force line breaks. The next version of HTML, XHTML 2.0 proposes to drop this tag and instead use an <l> tag which could wrap content intended to be read as one line.

Proper spacing in the [[Expression]] layer is important. The best way to acheive this in the current generation of HTML while still being prepared for the next is to set spacing between tags with style sheets and avoid the <br> tag when possible. There is no good way to prevent line breaks other than the &nbsp; entity, which is clunky.

Following [[Standards]] is important. Tags that are not part of the standard may work in certain browsers but not others. These tags can cause unexpected behaviours and create invalid HTML.

Box Presentation

Frames

Table Presentation

Images

Multimedia

Synchronization

External Applications

Wireframe

Phases - Category Pattern

The life cycle of a web site can be divided into three distinct phases: [[Design]], [[Development]], and [[Deployment]]. In the Design phase, planning and analysis must be done to ensure that Development is done efficiently and with forethought to Deployment. If a site is to meet the goals of the [[Client]] the [[Project Team]] must develop the right web site for the [[Audience]]. The web site should also be something that is [[Maintainable]] by the Client, unless the Client wishes to compensate the [[Project Team]] for that task.

During the Development phase, the blueprints layed out in the Design phase are [[Actualized]] though some development process. The site must be verified through some form of [[Testing]] to ensure it meets the requirements of the Client, is [[Usable]] by the Audience, and is [[Efficient]] and [[Reliable]] enough to be put into production.

In the final phase, the [[Deployment]], a hand off of responcibility is often made from one group of people to another. This may be from the Project Team to the Client, but is may also be to a sub-set of the Project Team responcible for maintaining the site. The Audience may now use the site, and if the site is designed to be [[Portable]] or [Extensible]] it may be further developed within the constraints of the [[Environment]] and/or [[Content Management System]] that the project team developed.

Design - Key Pattern

Doccument the Attempt

Forging

Reversible Decisions

Development - Key Pattern

Actualization

Iterative Development

Waterfall Development

Deployment - Key Pattern

Empowerment

Control

Ownership

Delivery

Processes - Category Pattern

Several underlying processes drive the interaction between a user and a web site. Each person in the [[Audience]] has one more more [[Motivation]]s that inflience their actions. They may be [[Browsing]] the content that is provided, [[Searching]] for some specific information, have a particular [[Tasks]] in mind, or trying to follow the [[Workflow]] presented by the web site. [[Navigation]] options take them from one page to another, each [[Change]] may bring them closer to information that they are looking for, or take them farther away if they make [[Mistakes]].

Some or all users in the Audience may need a unique [[Identity]] when using the site to ensure allow the experince to be tailored to them. Some times it is useful to identify [[Return Visitors]]. Whenever personal information is involved, [[Security and Privacy]] may become important even when there is no uniquely identifying information being exchanged.

Identity - Key Pattern

Security & Privacy

Big Brother

Return Visitor

Cache Transactions

Secure Transactions

Change - Key Pattern

Navigation - Key Pattern

Bookmarks

Point of Entry

Homepage

Search Engines

Links

Structured Menus

Clear Consistent Labels

Logical, Ordered, Homogenious

Nouns & Verbs

Avoid Prisoners of War

When linking off site let the user know and consider opening a new window.

Rhetoric of Arrival and Departure

Label Links so users understand where it will take them.

Pages should match what was linked to, and how to get back

Symmetry & Idempotence

Two opposite actions should return the user to the original state.

Some actions should only take effect once, repeating shouldn't have any further effect.

Back Button

Safe Return

Sense of Location

Breadcrumbs

Visible Landmarks

Canonical Location

Navigation Flavored by Content

Link to Many Sites

Context

Context Sensitive Help

Context Sensitive Search

Context Sensitive Contacts

Workflow - Key Pattern

Transactions

Interaction

Submit Information

POST Data

GET Data

Feedback (Positive Acknowledgement)

Informed Actions (No Surprises)

Input

Mistakes

Reversible Actions

Focus

Prerequisites

Side-effects

Pipeline Interaction

Exploit Closure

Download Time

Responce Time

Gravity

Handle Duplicate Requests

Redirecting

Reloading

Above the Fold

Content & Media Management

Avoid Modes

Flexible Inputs

Avoid Preemption

Input Labels

Input Groups

Mandatory Fields

Motivation - Key Pattern

Sense of Progress

Tasks

Searching

Browsing

Qualities - Category Pattern

There are a variety of qualities that are desireable in a web site. A few qualities are almost universal in their importance to developing a solid product, such as [[Appropriate]], [[Usable]], [[Efficient]], [[Functional]], [[Feasible]], [[Reliable]], and [[Consistent]].

Depending on the [[Client]], some may be a higher priority than others or irrelivent to a particular project. These include: [[Maintainable]], [[Extensible]], [[Portable]], [[Aestetics]], [[Architecture]], and [[Complient]]. Some qualities are important because of considerations to the [[Audience]]. Every web site should be [[Accessible]].

Appropriate - Key Pattern

Freshness

Shared Model

User Involvement

User Centered Structure

Natural Metaphors

Pay Attention to the Folklore

Get the Model from the People

Consistent Writing

Acceptable Wording

Usable - Key Pattern

What you See Is What You Can Use

Display Options

Visibility and Availability

Words Before Icons

Scannable Pages

Priming & Interface

Accessible - Key Pattern

Linear Order

Alternative Text

Functional - Key Pattern

Environment

Web Server

Browser

Dynamic

Static

Feasible - Key Pattern

Aestetics - Key Pattern

Color

Position

Font

Size

Margins & Padding

Transparency

Use of Color

Support Color with Spacial Metaphor

Two or Three Fonts

Whitespace Separated Content

Adaptive Marings

Web is Not Print

Compliant - Key Pattern

Standards

Follow Standards

DTD

Market Share

New Fangled

Old (Text, Small Screen) Browser

Printer Friendly

Architecture - Key Pattern

Unique Page Titles and Meta Tags

Sections

Semantics

Controlled Vocabulary

Taxonomies

Multiple Routes

Shallow Navigation

Search Box

Extensible - Key Pattern

Maintainable - Key Pattern

Publishing

Site Management

Authoring

Reliable - Key Pattern

Testing

Integrated Testing

Portable - Key Pattern

Syndication

Efficient - Key Pattern

Cache Output

Content Re-use

Content Before Graphics

Download Time

Consistent - Key Pattern

Templates

Stylesheet

Conventions

Inverted "L"

Nagivation Bar

Site Identifier (top left of Center)

Return to Top