Visual Vs. Structural

Posted August 1st, 2006 by Tommy Olsson

According to a recent poll on a big web design forum, the knee-jerk reflex of most web designers, when asked to design a new website, is to fire up Photoshop. To another group of designers, this will seem like a rather backwards approach; they will mark up the content, semantically, before applying the layout and design. Does the choice of approach — visual vs structural — have any impact on the accessibility or usability of the site? Will there be any aesthetic differences between the two? Visual designers see a web page as an image: the colours, shapes and images define the page; the content is something that populates the various areas of the image. This is a design-centric view.

Structural designers see a web page as a document. The information conveyed is the main thing, while the visual design is applied on top of that to make it more palatable. This is a content-centric view. Assuming equal skills in HTML, CSS, accessibility, usability, and graphics design, the difference between a page created by a visual designer and one created by a structural designer may be quite small. Visually, they may even be identical.

Visual designers start with the graphics design, making sure that the page will look good in any mainstream graphic browser. They will then create a skeleton HTML file consisting of div elements, each one corresponding to a major part of the design image. Often, the divs will be filled with “Lorem ipsum” place holder text at this stage. The next step is to create the CSS style sheet and position those divs in relation to each other, applying background images sliced from the Photoshop composition or comp. Finally, the place holder text is replaced by the actual content, marked up semantically.

Structural designers start with the content, making sure that everything is marked up semantically and that there is a logical order to it. Once that is finished, they’ll start applying styling, often working from a similar Photoshop comp as the visual designers. Some designers in this group don’t even use comps; they will let the content itself dictate the styling.

So what about accessibility, usability and aesthetics? Visual designs that rely heavily on background images tend to have a fixed width where the dimensions of the various areas on the page are specified in pixels. This may be detrimental to users with small screens (e.g., mobile devices) and to users with visual impairments who need large text sizes. With a structural approach, the designer knows how much content there will be in each area before starting with the CSS, and can thus more easily specify dimensions in font-relative units like em and percent.

A visual designer’s page, compared to one from a structural designer, is likely to have more markup in it. Starting with a skeleton of DIV elements, the visual approach doesn’t take advantage of naturally occurring elements for styling purposes. Experienced visual designers with good skills may optimise their markup, however, and remove redundant divs once the content is in place. In extreme cases there may be an impact for dial-up and mobile users (especially since design-centric pages tend to use more images), but in most cases the differences are probably negligible.

While studies seem to indicate that source order is not of paramount importance for most visitors, it does have an impact on usability for certain groups of visitors; primarily users who navigate by keyboard (due to a disability or because of a personal preference). A page created by a structural designer will automatically have a logical source order, since the content is marked up before any styling is applied.

A page created by a visual designer may also have a logical source order, but with a complex graphic design it is not uncommon for the content to be split into less than logical parts when it is coerced into a structure emanating from the visual design. Aesthetically, there is nothing in either approach that, for technical reasons, limits the design possibilities. In reality, skilled graphics designers tend, for natural reasons, to be design-centric. Those who use the content-centric approach are often — but not always — less skilled in graphics design.

Why, then, is the visual approach so much more prevalent than the structural? One reason is that most people think visually, especially when it comes to web design. Many also find abstract thinking very difficult, and abstract thinking is required for the structural design approach. Furthermore, visual designers believe that starting with the content will impose limitations on the design possibilities. The main reason, of course, is most likely that many designers use WYSIWYG tools like Dreamweaver or FrontPage, which are design-centric to the extreme.

Originally, HTML was devised as a way to mark up scientific documents, semantically, so that they could be exchanged electronically. Later, various presentational element types were added — first as browser vendor extensions — then those were later incorporated into the standard. With time, and because most designers are visually oriented, HTML was seen almost like a page layout language (albeit a mediocre one). Browsers and other user agents deal mainly with the semantic aspect of a web page, although graphical browsers are also capable of applying CSS style sheets to style the document. Assistive technologies, e.g., user agents for people with disabilities, rely on markup being semantically correct, too. Thus, although few designers regard a web page mainly as a document, user agents and assistive technologies do.

How, then, does one go about creating a page from a content-centric point of view? Let’s compress it into a simple step-by-step list of instructions:

  1. Using a text editor, write the content of the document; i.e., every piece of information that will appear on the page.
  2. Add semantic markup to the content, marking up paragraphs, lists, tables, emphasis, etc. Also add the “formal” parts of the HTML document: the DOCTYPE declaration, the head element, body tags, etc. (This step is often combined with the previous one.)
  3. If appropriate, replace parts of the content with images that illustrate or complement the text. Use the replaced text as the ALT attribute for each image. Add any decorative images (those that illustrate the article, but do not convey any relevant information). Use an empty alt attribute (alt="") for those images.
  4. Create the CSS style sheet. Start with generic rules, i.e., rules that use simple element type selectors. Specify rules for basic things like font family and line height, preferably on the HTML element. Specify explicit margins and padding for all element types, since the defaults differ between browsers.
  5. Add rules for the page layout, using floats and/or absolute positioning. Make sure to use relative units (em or %). At this stage, it will usually be necessary to add id and class attributes to the markup. Most layouts will also require a few wrapping div elements to group page components.
  6. Add the remaining CSS rules that will handle things like background images (which may be created from a comp), colours, borders, etc. If you’re styling links, don’t forget the a:focus pseudo-class, which is vitally important to users who navigate by keyboard. (Internet Explorer or “IE” doesn’t support it, but incorrectly implements a:active for keyboard focus instead.)

Throughout this work, test and verify the appearance using the best browser available (the latest versions of Opera, Firefox or Safari). When you’re done, verify that it works in all of them. Then apply hacks and bug fixes for the versions of IE that you aim to support. This may seem backward and difficult to a visual designer, but it’s really not. It’s a radically different way of thinking, but it’s neither harder nor easier than the traditional method. The only real difference is that the result is more likely to be accessible and usable.

Sorry. Comments are closed.

Note: This is the end of the usable page. The image(s) below are preloaded for performance only.