A new approach (part 1 of 2)

In the last four years, my process toolkit of how I approach building web experiences has grown. Massively. Everything from client inclusion exercises, to learning Twig and Sass, I'm really happy to see a lot there.

This is good. I means there are a lot of considerations going in to a site. Is the markup semantic? Can screen readers use the site? Am I writing Sass in a maintainable way? What I've realised however, I'm not treating the design of my process the same way I treat the design of a site. When I find a new process component, I tend to just bolt it on at some random point ("Today, I'll look at HTML5") without really considering if that is the best place to be doing it or if I'll be undoing other work.

Around this time of a mental audit, I started to think about semantic web design plus progressive enhancement. Chatting to colleges and fellow web enthusiasts, these two schools of thought have made me want to ensure that I'm baking these right into the core of the site, rather than cellotaping them to the edge.

So overall I've decided for a review and some critical thinking of my approach, and where best to utilise parts of my toolkit. This is part one where I outline the process I'm planning on taking. I'll then follow up with a part two, which will be a bit of a retrospective.

Its important to note before we dive into the nuts and bolts, this is me thinking about my technical approach. I felt that trying to change too much at once, and trying to adapt the visual/creative side at the same time, would lead to too much of a mind melt, and risk making projects too unstable. I'll come to the creative side, but as I've been doing creativity professionally for around six years, as opposed to the three to four for code writing, I'm more confident in that side of my workflow as a process.

Progressive enhancement

Inspired by Christopher Murphy's www.monographic.org, I realised that sites should be written logically first and foremost. It makes contextual sense to have the main site title before the navigation for example, so it should be written like that. If we're looking at our wireframe sketches and the nav is all nice and sticky and above the site title, one might be forgiven for writing that as the first element, but we so shouldn't.

Enter progressive enhancement (which I've had some lovely juicy conversations about with the fountain of knowledge that is Kyle Shrives) and the fact we should write our markup like this, then as soon as the browser or device can handle a menu fixed above the logo, we throw it up there. But first, we'll style it in our brand colours and fonts, get that right, then it does up there as later instalment.

Essentially scaling up is easier than scaling down. Its easier for browsers to handle (adding bits on if they are capable, but ignoring bits they don't need) and easier for writing the code. It means we write logically, step by step, and testing as we go. If, for example, we coded our navigation above our logo (to keep with the example) and styled it with the brand and made it sticky and a host of other cool interactions all at once, and only at that point we opened it up in older browsers or devices we might come undone. If it was all chewed up we would have no idea where to start in untangling it.

We might even learn that that particular browser or device can't handle fixed position items, so its not fixed, but its just randomly sitting up there at the top like some kind of Picasso painting, so we might have to write some JavaScript for those cases which moves the markup down below the logo. Yeah, its messy. We'd probably just write it from scratch again, putting the markup in the right place and testing a little more thoroughly, but because of all the time we ate up in the first instance, we'd rush and it would be a bit cack.

I realised this when I was working on some product banners for the John Smedley site, that needed to sit at a 45 degree angle. I coded them up to sit top right as a little pill shape, then, using Modernizr, as soon as the browser could handle 3D transformations, I tilted it, extended the padding left and right, and putting an overflow: hidden; on the main container and positioning it to where it needed to be. This made me feel good. Not just good, like Tom Hanks in 'Big' playing that massive floor keyboard. I was nimble, jumping through notes intentionally and with precision. My actions were grown up and considered, but my glee was childlike.

So I started to think about all of this as a process and how I might approach it to keep the Tom Hanks feeling. After a bit of thought I've come up with the following (untested obvs) process:

I'll carry on as normal up until I finish the rapid sketching phase, where ideas are quick and on paper. Then, when the prototypes (written in twig if possible) are to be created, the sketches will be turned into a list of what needs to be on the page and the sketches will be hidden. Only the list will be used as reference to markup the page.

I'll write the pages in full before I'm allowed to touch the css when that is done. The markup will change and classes will be added, but a full structure of semantic markup will need to be there first. Questions like is it an article with an aside? Are these all sections? Do these have their own header?

I'll then prototype and build in stages, testing each as I go in terms of browsers, devices and usability.

  1. Basic layout – logo left and search right in header etc (this will be the prototype stage and be expanded out to ensure client buy in and sign off and the following points will be for when the look and feel needs to be applied)

  2. Layout enrichment – progressively enhancing the page to do what I need it to do (e.g. moving the nav about the site title)

  3. Basic brand colours – just focusing on colours and setting up my variables logically

  4. Typography – ensuring there is a good solid font stack

  5. Visual enrichments – gradients, shadows and rounded edges, using Modernizr and Sass nested '&' selectors

  6. Interaction enrichments – bringing in JavaScript, I'll work up things like menus and forms to be a more rich experience

Working in this way should also ensure that I'm approaching all parts logically and giving them the critical thinking they need. Too many times I've haphazardly started creating variables, and its all got a bit messy.

Building a framework

I like frameworks. I like them a lot. Theres only a certain amount of times someone can style basic form elements responsively (normally just copy pasting the css from the last project) before you realise frameworks are needed. Main drawback I've now found, is there is so much architecture and components set up, the risk is I get lazy, opting for the first iteration where things seem to inherit and not delving any deeper, and sometimes not even opening the Scss file altogether.

Essentially theres a lot of bloat, and a preset structure that might not be right for the project. If there are going to be 30 objects, do we need separate directories? Do components have sub components? The answer to these questions change project to project.

The plan for this part of the new process, is to have no preset directory structure for my Scss files, and to build as I go. This is how I approached this site, and it seemed to work well. First I created my main.scss, then the first thing I went to style, I categorised it as either a layout, helper, object or component, then created that directory and the Scss file. The obviously imported in into main.scss and started styling.

This means that I'll be creating structures logically as I go, considering the knock on effect to each new addition, and hopefully eliminating complications that arise as a result of having a mega full framework and trying to scale things back that you don't need.

That does however bring back the original problem of having to styling things again and again right from scratch. With this (and this is all in my head as theory for now) I am going to have my base framework which contains my main.scss, directories for helpers, layout, components and objects, and some initial helper classes such as left and right floats, clearing and font stacks.

On top of that, I'll be starting a separate git repo containing individual base styling in Scss files. This will be in essence the robust framework, but rather than apply it all from the start, it'll be a reference guide that I'll employ as and when I need. I'll also add to it as I go, if I style up a new version of a form where labels are inline, I'll add that back to my main framework repo. This might make things a bit slow going at first as I'll have a lot to add, but this is going to make for speedy work 6 months down the line.

Off we go!

Overall I'm keen to get cracking on a new project, but I know when the next one comes along where conditions are right I might hesitate as change is always hard (especially for me, I'm a textbook creature of habit), but I'm confident that lots of good will come of this, so I can iterate, retest and analyse. That's good science, that is.

Posted on 5th Feb, 2015