I recently had the good fortune of being put on an exciting project involving a large not-for-profit agency with operations spanning right around the globe. My role was frontend development and the client was well versed with !YSlow analytics so the name of the game here was speed with a capital ‘S’.
Trouble in Paradise
Midway thru the project, I began to realize that an increasing amount of my time was being spent on simply trying to tame an ever-growing CSS file — little wonder considering the client’s existing site contained roughly 8,000 pages of content and a mind-boggling number of layout variations.
Another thing I was noticing was that a fair bit of time was being spent by backend devs on the process of implementing my static HTML in the area’s of the site where front meets back — Kentico CMS Transformations in this case, which are basically Kentico’s version of the WordPress ‘Loop’.
Surely, I thought, there must be a better way of tackling complex, content-heavy sites while keeping things straight between backend and frontend developers.
A Solution?
Existing frameworks like Foundation and Bootstrap certainly solve a lot of problems, like, helping to implement a tabbed interface in under 5 minutes. Or, making your tables all nice and pretty. What’s missing; however, is a predefined structure for individual content types. Bootstrap ain’t gonna be of much use to you when you realize that an outside design firm has found a total of 13 different ways to display articles and stories across a site — which happened to be the case on this project.
So, this got me thinking: why not try and create a more granular HTML/CSS framework that focuses on the type of content as opposed to simply shoe-horning stuff into something like Bootstrap every time, or, constantly building things from scratch. A framework that takes advantage of the fact that an article is an article, whether it is being displayed as a thumbnail with a teaser below. Or, on a ‘single-post’ page.
Before I went all Rambo on my CSS, I thought I would see what was out there already — you know, that whole ‘don’t reinvent the wheel’ thing.
I looked at a couple of different current schools of thought on writing better CSS: BEM (Block Element Modifier), SMACCS (Scalable and Modular Architecture for CSS). And finally, OOCSS (Object Orientated CSS).
BEM was more of a framework than the others, which were closer to a set of ‘best-practices’ than anything. All of them had a similar, and completely sensible outlook that consisted of:
- Staying away from evil ‘descendant’ style rules (yes, I am looking at you Dreamweaver) by utilizing ‘custom classes’ (instead of .object h2 {…} we use h2 class=’category’). And,
- Avoiding the bad habit of styling specific HTML elements, such as an <img> tag and making the styles more ‘portable’ by — surprise-surprise — using a class instead ( .video img.poster would make complete sense when targeting the static poster image within a HTML video element for instance).
A good start for sure, but none seemed to address the issue of writing CSS optimized for ‘Articles’, or ‘Products’ and the common arrangements that can be found within each of these (and many other) ‘design patterns’.
You’ll also notice that the main theme here is: ‘when in doubt, use a class’ which can easily lead to ‘classitus’, the evil twin of ‘divitus’. With these factors in mind, I took away a few of the best-practices from these loose frameworks and came up with 7 goals for what I was hoping to create:
The ‘Plan’
- Define blocks of content according to type which will integrate nicely with RDFa Lite ‘rich-snippets’ and the HTML5 contenteditible attribute — both of which we’ll be seeing a lot more of in 2013 and beyond.
- Content Types: Articles, Products, Events, Image Galleries, and so on.
- Define distinct ‘views’ that will help optimize the CSS – an article is really an article whether we are looking at a thumbnail, summary, or detail view – this is where some really lousy CSS typically gets written (me included). These views should also be largely transferable between content types.
- Views: Summary (article archive/list pages using excerpts), Thumbs (displayed as vertical or horizontal grids) and Detail (full Articles with comments; Detailed Product pages showing specs and reviews, etc.)
- Content should seamlessly morph into Main Content area’s or Sidebars by simply applying a single class to the appropriate container, thereby making loop code more modular/portable.
- Area’s: Main Content (ie, 400 – 800 pixels in width) or Sidebar (200 – 400 pixels as a rough estimate).
- Provide minimal default styles that can easily be changed or expanded without too much pain or effort.
- Content should be responsive and framework independent, meaning, whether these containers get dropped into Foundation columns, Bootstrap spans, or, a 960 grid layout, they will not break in any way and adjust to viewport size if required, out-of-the-box.
- Backend developers should be able to create, copy and paste HTML code blocks, safe in the knowledge that only the CSS will need to change down the road (say hello to Reuze.me — more on that later!)
- Avoid polluting individual content containers (<article> as an example) with a multitude of classes, placing them on the parent container instead. This goes hand-in-hand with the previous goal and should also help to avoid classitus.
A tall order? Perhaps, but, when you consider the amount of time and effort wasted writing inefficient CSS for content that falls outside the scope of traditional front end frameworks, I was firm in my belief that the time spent up-front would quickly be recouped with each subsequent project.
The Execution Of Said Plan
Armed with my ‘manifesto’, I decided to target the Article content type first. Based on some of the points outlined above, the structure for a page showing 3 different articles in thumbnail format, as an example, would look like the following:
<div class="ac image-left thumb" typeof="Article"> <article>{...}</article> <article>{...}</article> <article>{...}</article> </div> Here I’ve applied my ‘ac’ class denoting that the we are dealing only with Article Content (in thumbnail format) while another class specifies the featured image for each article ‘block’ will be left-aligned, as opposed to banner-style (more on style and layout options in a moment).
The other piece of the puzzle here is the ‘typeof’ reference which is part of RDFa Lite — a simple subset of RDFa that is quickly catching on as the preferred way to add ‘rich-snippets’ to web pages, making them even more semantic for search engine crawlers, screen-readers, and the like. For more info on RDFa Lite visit this W3C Recommendation Page.
With this base structure in place I then went on to catalog the typical design patterns and components that are possible within my defined views (Summary, Thumb and Detail). Some of the most common of these with regards to articles were:
- Main Title
- Secondary Title
- Category Title (i.e., economics, politics, etc.)
- Featured Image (left-aligned, banner style or none)
- Image Border (light and dark)
- Image Caption
- Meta Data, such as: Author, # of Comments, Publish Date, Keywords or Tags
- Read More Link or Button
- Quick share buttons for Social media
- 1, 2, 3 or even 5 column layouts within the different Views
Some of these elements ended up being controlled with additional classes on the ‘name-spaced’ container while others ended up being modified through the HTML article code block itself.
Talk Is Cheap. Show Me The Code.
Point number 6 of my plan references the need for backend developers to be able to easily construct the HTML required to produce dynamic ‘loops’, just in case the front-ender is tied up watching the latest iPhone launch or something. This is where the Reuze.me site comes in.
Rather than extending this post any longer than it needs to be, I think it’s more prudent to point you to the Reuze website, where the HTML can be assembled. And, to the tiny CSS file that brings it to life. Strip out the base styling and I can basically achieve an almost infinite combination of article layouts with only 6kb of CSS!
In the weeks to come, more and more content types and their associated design patterns will be added to the Reuze library. CSS files will be broken into separate types (i.e., articles.css, products.css) enabling devs to only include the necessary CSS for each project.
Source : internetwebsitedesign[dot]biz
0 comments:
Post a Comment