component complexity pt2
After last week's short introduction on component complexity, it's time to get down to business. First off, I'll give a quick run-down of the example I'll be using throughout the rest of the series, after that I'll be looking at the way html can vary within the scope of a single component. To keep things sane I'll try to keep my examples as clear and concise as possible, though I'll be hinting at some additional real-world variations that will only add to the complexity.
example component: the article
I'm going to make it easy on myself and just refer to the Smashing Magazine article I've written back in 2012. It gives a perfect run-down of the component we'll be using here. In short: the article component is a typical (and common) content type, used for displaying articles, blog posts, news items and whatnot. Typical for content types is that they appear in several different guises. Usually there's a detail page with the full article, but you'll also find smaller teasers throughout the website linking through to the detail page. From an html perspective it's all the same component though.
html variants
There is no straight mapping between a single html component and its html output. All variations of an html component will be built from the same html structure, but actual html output may differ depending on several factors. These variations are important as they will impact design, css and possibly even javascript, so it's important to be aware of all the different possibilities.
Just imagine a pager. Some pagers feature prev/next links, some feature first/last links, others feature no extra navigation links at all. All these instances are variations of the same component, but the html output will different (the first/prev/next/last links will no doubt feature different classes and the html will either be there or will be completely absent). Some other examples include headings (ranging from h1 to h6), navigation lists (either marked up with the nav or div element) or input fields (with or without informative text), but the list is virtually endless.
Not all changes in the html output are html variations though. When the difference is an additional (existing) html structure initiated by content (just think of an extra item in a navigation list) this does nothing to change the structure of the output. It simply represents a loop of a specific html structure within the component.
Html variations are pretty common and you should expect each component to have at least a couple of them.
html variations for article
Two main variations exist. First of all you have the views. On the detail page you'll find the full view of the article, but on higher-level pages you'll find various teaser views. These views can range from heading-only to semi-expanded views with a teaser image and abstract. For this article's sake, we'll stick to two views only (detail and teaser).
/* detail view */ <article class="article detail"> <header> <h1>article heading</h1> <div class="meta">...</div> </header> <div class="main">...</div> <footer> <div class="share">...</div> </footer> </article> /* teaser view */ <article class="article teaser"> <header> <h1>article heading</h1> <div class="meta">...</div> <div class="abstract">...</div> </header> </article> The detail view has a main and footer section for body text and sharing options, the teaser view obviously lacks these elements, but features an abstract text section in the header of the component. But that's not all, the teaser view as it is written now lacks a link (as that's its sole purpose of existence: linking through to the detail view).
There are two options there, either we use a block level link (so the entire teaser is linked), or we just link the heading of the view. Both options yield different html
/* block-linked teaser */ <article class="article teaser"> <a href="#"> <header>...</header> </a> </article> /* heading-linked teaser*/ <article class="article teaser"> <header> <h1><a href="#">article heading</a></h1> ... </header> </article> so why is this important
The problem with these structural html changes is that they impact css and javascript work and they might even carry some design impact too (in case of the different link options). A block-linked view has different hover and focus states compared to the heading-linked view, the block-linked view impacts the use of child selectors and the styling of the different base views might be wildly different, so all these different variations will impact the work needed to style and design them.
Looking back, this gives us three different variations: one detail view, one block-linked teaser view and one heading-linked teaser view.
conclusion
In real life, there are usually four to five different views per content type (one detail and three or four teaser views). Combined with the link options this can lead to up to nine different variations already, and we've just started this series. It's important to limit the views to an acceptable minimum and pick one single link method from the start. Leaving the option open will have a disastrous impact on the amount of use cases you'll have to cater for in a later stadium.
Next up: the visual and functional variations of components.