HTML

Every developer knows how to write HTML, but I care deeply about writing semantic markup. It is the language of the web, and therefore the language in which the large majority of the information available to humanity is now written. For this reason, writing clear HTML is fantastically important.

HTML elements should be used to assign semantic meaning to areas in a document, rather than as handles for code. This has been made vastly easier with the addition of new semantic elements, and the removal of some complexities in HTML5.

Writers of HTML should try as far as possible to avoid using any elements that don’t add semantic meaning. Rendering of complex layouts should be done by the CSS wherever possible (and, if necessary, JavaScript). We should also avoid adding inline styles or script tags to keep the HTML clean.

I am so very glad that the W3C are moving away from strict standardisation of HTML, with the HTML5 spec being much more flexible than previous specs. HTML needs to be as quick, easy and forgiving to write as possible.

Writing expressive, semantic and clean HTML will not only significantly ease maintenance, but will encourage overall simpler designs and architectures, and be inherently more accessible and better for SEO.

CSS

I was first trained in CSS at Tamar in 2005, and have eagerly taken ownership over many CSS projects in every job since then.

I have a deep understanding of the layout models of modern browsers, and I’m experienced in recreating simple and complex designs with straightforward CSS. I apply the CSSLint rules and I use the principles behind OOCSS and SMACSS to write maintainable and modular CSS.

I have experience using SASS (and LESS) to help keep CSS code DRY and structured.

I am a big fan of progressive enhancement, and I will always choose it as a solution over having to target styling rules at specific browsers. Simplicity is the key to responsive design.

I believe that in writing CSS it’s important to embrace flexibility, to allow the page to respond natively to different browsers and devices. For example, I prefer to base my font sizes on the device’s default size, rather than specifying an absolute font-size, and I tend to use max-width rather than width to allow the design to respond to the device width.

Responsive design

I am a big fan of responsive design, which to me goes hand in hand with progressive enhancement as an invaluable principle that should be applied to all front-end projects. With the number of different devices of all sizes and capabilities growing far more rapidly than we could possibly keep track of, it is paramount to write front-end code to be as flexible as possible.

Although I’ve never worked on a “responsive project”, by writing simple and flexible CSS, I have made a number of design projects responsive by default, even though responsiveness was not in the plan.

Ideally, new projects would be designed and implemented “mobile first”, firstly to keep the project focused on the really important elements of each page, and secondly so that extraneous content doesn’t even get sent to a small device, which probably has a slower internet connection. I am very much looking forward to working on my first mobile first project, hopefully in the near future.

JavaScript

I learned JavaScript basics during my Computer Science BSc, but I first put it into practice at Tamar in 2005, eventually becoming their principal JavaScript expert and creating a large JavaScript library.

I understand JavaScript’s functional roots, its prototype-based model and I am experienced in event-driven programming. I know how to use closures, and encapsulate code in a function to prevent it polluting the global space, and I am familiar with Douglas Crockford’s JavaScript code conventions.

I have used JavaScript extensively in every job since then, and have created modules in jQuery, YUI and MooTools. I like to write well-structured and expressive JavaScript, and I’m a big fan of backbone and require.js (or, indeed, any AMD implementation).

Having said all that, I also believe that JavaScript should only be used where appropriate. In a traditional website, JavaScript should only be the sugar on top. As much of the functionality as possible should be provided through traditional HTML, CSS and native browser functionality. Where functionality is supported natively by the browser (e.g. HTML5 input fields, form validation, <video>) this should be used in preference to custom JavaScript. This will lead to a more stable, maintainable and accessible website.

Performance

I am very interested in front-end performance, and have applied and developed my knowledge of optimising front-end performance in every job I’ve had.

Although some performance tweaks can be achieved purely by structuring markup differently (e.g. load JavaScript at the end of the document), most tweaks (like concatenating and minifying CSS and JavaScript) require work throughout the project.

Lately I’m particularly interested in performance benefits from aspects of responsive design, e.g. serving responsive images and lazy-loading extraneous content.

I’m also very interested in the potential use of the cache manifest to both dramatically improve performance and make content available while offline.

Usability

My interest in the user experience was my main motivation for doing my MSc in Interactive Systems Design, which taught me to think in terms of systems, and to recognise that people are a central part of every human system. I also learned the key usability principles how to conduct and interpret user studies.

I’m very interested in user design. Even when there’s no time to conduct user studies, we can always benefit from prioritising usability over aesthetics (which doesn’t necessarily mean sacrificing beauty), and following established UX patterns.

I also don’t believe that usability stops with the end user. Code, email, prose, and meetings should all be as usable as possible throughout projects and teams. Striving for ease of use is a mission for the whole of life, and is tied up, in my mind, with a quest for simplicity.