Web Patterns

Patterns are nouns. Typically, they are identifiable things, which emerge, or are created, to resolve a set of pressures or problems. They are typically GENERIC ... they have emerged before, although usually in a unique way, adapted for the particulars of a situation. And for our purposes, patterns are GOOD. (An anti-pattern (-) is BAD.) And patterns should be GOOD for the WHOLE system. The SCALE at which they should be applied as a solution should also be clear. It should be clear at which STAGE of development they should emerge. They should also just be RIGHT: i.e. a pattern should make sense both to your head and your heart.

Here you'll see me generally aiming at finding GRADIENTS of patterns, because, to me, patterns are most useful when collected into SEQUENCES.

Note that a blog certainly doesn't have the right kind of order for this work. What I have here is essentially "scratch paper", or "working papers", for patterns which themselves will eventually be presented as a gradient, in order. Of course, that kind of webapp is a pattern: "GRADIENT SEQUENCE".

HTML gradient

Where, in the gradient of web patterns, does HTML(XHTML) fit?

Of course, this is continuously changing. The markup language used to provide:

(1) identity of the page
(2) classification of content
(3) layout of content
(4) styling of content

... and of course, with CSS, (4) is now deprecated completely, with (3) actively being pushed out of the door, but keeping a foot in, in the "CSS with Minimal Tables" compromise (see Apple's Web Development Best Practices page).

That said, it is impossibly difficult to engage in (2) without an existing storyboard (or wireframe or visual outline or mock-up or comp) in mind, on the screen or on paper. In fact, (2) never happens otherwise ... even the most dynamically generated web pages will reveal, in the designer's naming and categorization of classes and ids of elements, some kind of visual arrangement of data -- in fact, usually it was written with some specific example in mind.

Still, both the "Pure CSS" and the "CSS with Minimal Tables" strategies have the same effect: structuring layout sufficiently to begin work on further differentiation, while leaving enough flexibility to change position and emphasis when needed.

(1) is well-covered elsewhere ... titles, DOCTYPES, meta tags, etc.

So we need to look more closely at the gradient sequence of (2) or (2)-(3). The key is to understand the early unfolding of good decisions regarding what is most important about the web page.

* Determine, and order, your ends
* Determine, and order, your means

The Ends and Means, or the "Purposes and Processes", when spelled-out fully, tend to be intertwined: nouns and adjectives, verbs and adverbs ... Discovering and ordering these can involve quite a bit of deep digging. And, in group situations, some tough-minded facilitating.

Let's say they've been found. We then need to:

* Arrange the key elements.
* Ensure their differentiation from each other.
* Ensure that they complement each other.

If you have more than two things on the page, this usually means:

* Arrange the elements into categories beneficial to the user.
* Clarify and distinguish elements by level and type of "engagement", such as which elements require the users to be active, and which require them to be passive.

We now typically have something that would allow us to create a "div" scaffolding. Possibly the most important aspect of this stage is:

* name the elements

... with "class" and "id" designations. These might be:

* unique elements
* categories of elements
* active elements, for example for use with Javascript

... after this, and before applying CSS, we can lean on HTML's presentation categories for differentiation: not everything is a "div". So, "ul", "ol", "table", "h1", "h2" etc. are perfectly appropriate for categorizing certain types of content. It's just typically LESS important than the NAME of the content, and the POINT of the content. But MORE important than the CSS property:value declarations.

And besides, technically, we need all the HTML elements differentiated and named before we can even begin to write CSS rules, which use "selectors" that identify standard element types, our element classes and our element ids.

Styles

When considering the gradient of patterns that makes a website, the styles are patterns that fit into the gradient as lower-level transform functions or methods, applied to the higher-level instances of HTML patterns.

CSS "rules" or styles are patterns that apply across the whole system, at the appropriate scale. Some are common to groups of pages, some are common to HTML structures, and some are exceptions.

When applied, the results are different from instance to instance, as they should be. And yet the purpose of the abstraction is consistency. Very unique things can have common properties at different scales -- Shakespearean sonnets, for example, make use of iambic pentameter on a small scale, and a large scale rhyming scheme of ABAB CDCD EFEF GG.

On the web, patterns at certain scales, having to do with appearance, are styles in the head element of the document, or in Cascading Style Sheet (CSS) files, typically assigned the extension .css. They also can be assigned inline ... which is fine for quick-and-dirty exercises. So, there seems to be a gradient of CSS use:

* quick page: inline style property
* larger page or small web application: styles defined in "head" section
* serious site of perhaps dynamic pages, or a web application: styles in .css file
* serious web service: in several .css files
* super-serious: dynamically generated .css definitions and files

With the right tools, you can start at the high-end ("super-serious"). More on that in another post.

CSS has another gradient for the HTML patterns / elements / features it applies to, or effects, from large scale to small:

* element morphology (position, size, margin ...)
* HTML large elements (tables, lists, paragraphs, buttons, scroll bars ...)
* visibility
* containers
* colors
* text size
* text font

etc.

(-) Ads that nobody will click

It's brilliant to put click-through advertising in places where people are looking either for something specific (as when they use Google), or at content pages near their target.

It's brilliant to put web ads where people are socializing, venting or just fooling around (like YouTube).

It's not so brilliant to put ads in delicate states, like editing states, for webmail or web services generally -- because no one's going to click on a link, when there's a perfectly reasonable possibility that they will lose their work!

In the spirit of the currently canonical definition of "anti-pattern", what is a better generic solution to the problem this is trying to resolve?

The problem: revenue. "Advertising" is the pattern. One version "Display advertising" can be applied all over an application. Another, "click-through advertising", can't be applied everywhere. So, this is really an "anti-pattern" in the sense of a genetic "suppressor" which prevents (based on experience) the "click-through advertising" pattern from being applied to states where the user is editing something. Use "No Advertising", or "Display Advertising", instead.

Profile & Profile Connections

A personal profile, along with a way of telling others about your personal profile. Also, features that move people towards each other, or towards mutual goals, online or offline, in communities, when their profiles match in some way. Examples abound on friendster, flickr, facebook etc.

Portal

It is important to collect and consolidate access to the web. There are, however, several ways to do this:

1. Search

This will continue to be a critically important tool for finding what you need among an ever growing set of data. I expect many changes in search, and many expansions of the notion in the future. For example, people should be able to weigh their search, to use specific analytical tools, to follow the propagation of information, etc.

2. Ontologies or hierarchies

As search has improved, these are less used as before, with the exception of the wiki. But this is an area for dynamic growth. Unfortunately, DMOZ (aka the Open Directory) seems very limited in its approach to ontology, mirroring Yahoo's rather narrow apporach to the problem.

3. Summaries

Essentially, a Portal is a collection of tools, data and links to further information. Most portals offer customization, so that a summary can reflect the user. They are missing the opportunity to provide this as a way of generating content for others ... summaries that are useful to others. Many speciality portals do exactly that ... they simply summarize the subject at the moment, and the work is often that of a single person. Wikis, again, are making inrads into this arena.

4. Newspapers

Many portals are also newspapers, with weighted headlines, taglines, bylines, photos & leads. While blogs have made inroads into the area of columnists, and even groups of columnists, they have yet to really encroach on the true consolidation of information that a newspaper provides. Many smaller web service providers create such automatic consolidation & layout tools. But the big companies have yet to do this, which is odd, since it is the natural extension of the blog phenomenon.

Wiki

When you study something, you tend to forget it almost immediately. Unless you do something with it. Blogs get things written down, and so address this problem some. But a Wiki lets you begin to organize the information permanently, update it, expand upon it, and invite others to do so with you. It is a repository.

I expect that wiki's will begin to show further levels of protection and versioning for the work done on them. I expect that some companies, such as socialtext, are thinking about making wikis available to the general public, for example through aquisition by Google. The only reason it hasn't is that, as of this writing, wikipedia has created not a plurality of information, the way blogger did, but a consolidation of information. This means that communities are more likely to fold their research into wikipedia. But Wikipedia is a public repository, and small groups & individuals can't use it for initiatives they prefer (rightly or wrongly) to keep private. So their is still room for "wiki web service providers", like socialtext, and there's a string possibility that wikis are just at the beginning of their web history.

Blog

People want to record their impressions.

A weblog is a diary, but it is also journalism, in the original sense of that "published daily". It can be investigative journalism, because the investigation itself can be published on a daily basis, and the ongoing story can attract readers, and fund further investigation.

The immediacy of a journal, or a diary, is what makes the writing & reading of weblogs so attractive. Of course, it's as vulnerable to spin and mendacity as any other form of publishing. But when done honestly, it is the opposite of dry reporting of official pronouncements.

The reasons that "the blog" became successful, and is a web pattern, is that it serves a very critical personal need: to just get your thoughts down, so they aren't lost. Other web patterns will also serve such critical & personal needs. There are untapped patterns, in many other realms. In the sense that the weblog was a generic use of the web years before "blogs" became a web service, is an important consideration in mining patterns from the web, and in anticipating future successes.