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.