Analysing the design
There are several ways of analysing a design for a large-scale site. You will have your Nice Set of Documents, and you'll be looking to find trends within the design that will allow you to specify how the HTML and CSS will be structured.
The four methods of analysis I've been able to come up with so far are analysis:
- From a semantic point of view
- From a functional point of view
- From a modular point of view and
- From a stylistic point of view
From a semantic point of view
This analysis will help you structure your HTML documents. Looking at the design as though you were MS Word in 'outline' view personified, you should be able to point out all the h1s, the h2s, the lists, etc, and, in rare occurences, the definition lists.
Hopefully, all h2 elements are styled in a certain way, if not, you'll be able to note that h2 might look another way in this case, or in these circumstances.
With the other methods, you'll be able to then structure the semantic elements within the layout of the page.
From a functional point of view
By this, I'm suggesting that the item you are looking at does this or has this purpose, thus all instances of the item you're examining will be styled in a certain way (again, if you're lucky!).
This analysis should lead to results that are very close to the functional specification and may borrow thinking from the technical specification.
You might ask how this form of analysis differs from analysis from a modular point of view? Well, yes, more often than not a functional component of a website is also a modular component: e.g. A search form at the top of every page, or an RSS fed list of blog entries, however, a functional website item can appear in several modules, so its styling needs to be considered accordingly. Examples would be:
- All form elements
- Error messaging
- Link types (e.g. External links)
It's extremely likely that most form elements will look the same across the site (as this would make for a consistent user experience), but occasionally, they will differ in position, especially when in combination with other form elements: e.g. A label associated with a radio button may well be aligned differently to a textarea label.
From a modular point of view
Your site almost certainly will comprise several modules – an article, a short summary, a product and its description, a navigation, a breadcrumb trail. In all likelihood these will be styled uniformly, and can be easily described.
This form of analysis might form the backbone of the functional specification, and it aims to modularise the system to make for quicker development and easier maintenance, as well as 'sandboxing' components.
Modular analyses of websites will tend to have either a central part to play in CSS analysis, or play no part. You can either take the view that, semantically, a particular module should be styled according to what it is, rather than what it looks like. On the other hand, though, if the styling (of fonts, colours, etc) is consistent, then very little will be needed in terms of CSS description for modules.
Modular analysis comes into play in creating HTML elements that correspond to the modules in the functional, and possibly technical, specifications. If there are styling differences between modules in differing contexts, a higher level class or ID should identify the context. (See Maxdesign's Selectutorial for a thorough overview of the topic )
From a stylistic point of view
This is the part of the analysis that should come directly from the style guide and source design documents (e.g. Photoshop or Fireworks). Hopefully, you'll have little to do converting the style guide into CSS.
Your analysis might cover:
- Fonts
- Colours and themes
- Text after elements
- Margins and padding
- Containing divs, columns, etc
The likely exceptions will probably be when elements are in proximity to other elements and their styling changes, for example the underlining or padding on the first or last element in a list of elements.
Another likely exception would be the styling of headings in different contexts: a heading 3 in a right hand column may well look less important (smaller font size, etc) than one in a main module, but still have the same level in the document hierarchy.
