David Bushell - Web Design & Front-end Development

Pageshift

David Bushell — Tue, 15 May 2012 22:10:48 +0000

It’s 2012, why are we still seeing websites assemble like Optimus Prime?

In January I wrote Web Design: 2012 and Beyond to highlight points of interest for the coming year. On interactivity I asked, “Is the page reload a thing of the past?”. ‘Web apps’ are all the rage, and while we shouldn’t be trying to copy native (the Web is much more than that), surely it’s about damn time to rid our browsers of the page refresh?

Inspiration can be drawn from slide decks like CSSS, deck.js and impress.js, though they all require very specific markup and single page content. Other solutions built on top of JavaScript MVC frameworks like Backbone.js require a massive effort to maintain URL accessible states.

As a Friday coding† experiment I asked myself if I could remove the refresh and add page transitions to a website that was already built…

Say hello to Pageshift

Pageshift is undoubtedly the worst thing I’ve ever written for the Web!

The screencast frame rate below is a little choppy; best to try it yourself. See Pageshift on GitHub for the code and a neat little bookmarklet you can try on any website. Some work amazingly, others fail spectacularly.

This is a prototype!

It does a pretty tidy job of swapping out elements with CSS transitions and 3D transforms. A lot of meta data is also updated. It even supports the History API. It only works on internal links. All JavaScript gets stripped for the time being until I figure out the best way to handle that.

You could probably use it to turn an existing website into a Powerpoint presentation.

Will I develop this further? Maybe. It was extremely fun to take this far and doing it without jQuery was a big challenge. Ultimately it’s just not a good solution! I may develop it to work with individual elements rather than whole pages, that might be useful…

† Friday coding: a micro-hackathon. Normally an hour or two before beer’o'clock.

We’re Hiring!

David Bushell — Tue, 15 May 2012 07:09:04 +0000

We’re hiring at Browser. If you like making stuff for the Web you’ll fit right in. The roles that need filling are a Junior Digital Designer/Developer (1 year’s experience needed) and an Intern Digital Designer (no experience, but lots of skills and ambition).

Hit the website for more info and contact details.

Recruitment agencies, try: +44 (0) 8705 244622.

Paydirt: You’re Doing It Wrong

David Bushell — Tue, 08 May 2012 21:07:01 +0000

We don’t spend hours debugging obscure IE bugs…

Neither do I, yet my websites work just fine in Internet Explorer.

Just over a month after the last “we’re dropping IE support” publicity stunt, another tech start-up has successfully hit pay dirt with the exact same bullshit (read: actively blocking IE).

I realise that by sharing this link bait I’m feeding the trolls, but I feel it’s important enough to highlight the issues here considering the number of impressionable web developers who actually applaud this line of thinking.

Wholly blocking any browser is insular thinking. It screams of bad practice. Don’t talk to me about “costs” involved in supporting certain browsers; your doing it wrong. The whole concept of “browser support” is a dangerous perspective to take. I’ve blogged about it before: Browser Support? Forget it! Today’s Chrome is tomorrow’s IE6. If you’re thinking in terms of all-or-nothing you’re ignorant of how the Web works.

Take a progressive enhancement approach. Use feature detection to offer a granular level of experience; remain agnostic of device and browser.

“IE support” — or support for any browser — is a side-effect of these methods, not something that drains extra time or money. Such an approach makes it easer to take full advantage of the latest hotness. You’re laying accessible foundations to build great things upon. Don’t shroud your ineptitude as a developer with claims like, “We don’t spend hours debugging obscure IE bugs, and we spend that time making real improvements for sensible browsers like Chrome, Firefox, Safari, and Opera”. IE is not the problem, you are. You’re approach is backwards to begin with.

The Web is not the ‘Webkit Web’ or the ‘Firefox Web’, it’s not the ‘mobile Web’ or the ‘iPad Retina Web’ — it’s the Web. The minute your forget that you’re doing it wrong.

And at the end of the day, if you don’t give a hoot about potential users, why actively block them? Your site probably works anyway.

Smashing Book #3

David Bushell — Mon, 07 May 2012 13:51:46 +0000

As an occasional writer for Smashing Magazine — that’s a disclaimer (and an honour!) — I’ve had the pleasure of reading the latest publication, Smashing Book #3 – Redesign The Web.

Here’s my honest opinion on why this book is worth buying:

On Business

Book #3 opens with wise words from Paul Boag on the reality of web design as a business. Designing websites is not just about expressing one’s inner artist in Photoshop. Things like research, testing, and clients exist and the theme of this chapter, a complete website redesign, is not always the sensible option (for either business). Paul informs us on how to keep project scope in check, design at a sensible level, and mobile strategy realistically planned.

While much is written on web design these days it tends to be ideals and personal opinion, rarely is business ever mentioned. Paul speaks from years of experience and is the sort of guy worth removing your iPod headphones to listen to. And going from my own experience with many practitioners and the latest trendy, ‘new iPad’ web strategies; a much needed voice.

The following articles get more technical and cover a wide range of subjects so there’s something for you no matter your level of expertise. Obviously the of-the-moment themes make an appearance regularly, but if you’re tired of hearing about ‘responsive design’ and ‘mobile-first’ — fear not! This book is a refreshing look beyond the much talked about methodologies and is very much grounded in logical, practical ideas. It’s rock solid this is the Web type stuff. If you live and breath web design & development like I do there is nothing revolutionary in these pages — an unfair expectation — but you’ll be happy with the book’s advanced nature nonetheless.

On Practice

I particularly enjoyed Marc Edwards chapter, “Designing for the Future, Using Photoshop”. He introduces the never more relevant issues of screen size, pixel density, colour, and scale with superb thoroughness. A pleasing change from the recent outburst in overblown and blinkered ‘is your website Retina-ready?’ articles. Marc continues with many great examples of non-destructive Photoshop techniques. I would say the main sentiment to take from this chapter is that Photoshop is still as useful as it ever was. We don’t have to abruptly drop it and ‘design in the browser’, or any nonsense like that (in my humble opinion). You can probably guess what my two pet hates are at the moment!

Rounding up an excellent read, Andy Clarke writes on the difficulties of tackling a responsive, modern web design with traditional ideas while offering new techniques that, amongst other things, separates aesthetic design from layout. Something that in inherently non-design on a responsive canvas. He describes modern web design as less about full-screen comps and more about components, moods, atmosphere, and general aesthetic style (I’ve introduced Style Guides to my design & build practice this year). Rather than talking about design decisions like ‘navigation on the left’ we should focus on hierarchical rules and related strategies, like content, to pull design together; layout starts to form itself.

Importantly Andy notes, “Responsive Web design asks more questions than it offers answers.” To that I add, never dimiss a technique until you know what problems it solves and what else must accompany it. Responsive design offers us a way forward on the many-device Web, but it requires a big change in thinking and practice to work.

* * *

I won’t spoil any more for you!

This book is worth buying and reading for yourself. It really covers many aspects of modern website production in eleven in-depth chapters. There will likely be a few you don’t care for — we all have our own tastes — but I’d be surprised if any genuinely leave you disappointed given the chance. I was quite prepared to write something less positive, the first Smashing Book didn’t excite me, but this one very much did.

Hacking it Right

David Bushell — Thu, 03 May 2012 22:07:58 +0000

Developing with open web standards that are to be interpreted by literally hundreds of variations in device and browser can be tricky, but the biggest problem is often not the browser interpreting the code, but the developer writing it. Many so called “bugs” are the product of bad code and wrong expectations; don’t blame the machine.

A long time ago I learnt that in order to improve my ability to build websites I had to understand exactly what was happening. This idea is summed up in an excellent article by Nicole Sullivan, Cross-Browser Debugging CSS:

If there is a discrepancy between these good browsers, chances are you are working against CSS. Do not try to hack around discrepancies between good browsers. Your goal is to figure out *why* it is being interpreted differently. Usually there is a very good reason.

Every front-end developer starts out by writing bad code. Acknowledging that is key to improvement. If you write HTML & CSS once and then hack to fit, the reasons why browser discrepancies appeared in the first place are never understood. You never learn; you blame the browser. It’s an endless cycle of frustration. If you continue to have difficulties you’re hacking in the wrong direction. Tear it down and build it back up again until you understand what is happening.

Notes From User Testing

David Bushell — Mon, 30 Apr 2012 07:20:34 +0000

Last week Browser hosted a UAT session for our latest website development (launching soon!)

Most website designs — or any design for that matter — do not go through this sort of testing but it’s well worth the effort when done right. It’s exciting and a bit scary to be sat there with your clients while real users are effectively approving your work.

Well suffice it to say, things went well. Very well actually. Not to say we won’t be making changes, but the outcome was positive, insightful and just plain fascinating. As designers we build up snippets of knowledge that result in a lot of [educated] guesses being made around usability and user behaviour. Testing sessions like this should confirm that, somehow, we actually know what we’re doing (and that’s good to know.) They also destroy many stereotypes regarding Web and technology usage in general.

A few confirmations I took away from this session:

Users aren’t stupid. If you’re in the industry you’ll know how much respect users tend to get. They’re pretty savvy by comparison (and age has nothing to do with ability). Users read when they think it’s worth ready (note to “SEO” gurus). Users scroll when they think it’s worth scrolling, i.e. content further down is obviously relevant. Learned conventions like clicking the logo to return home, or pressing return on single field form with no submit button (like search, or the Facebook status update) are common but not to everyones knowledge or taste.

Good on-site search is important. For many it becomes the go to navigation method if they know it returns good results. If you’re making the global search prominent, make sure it works very well. Also look for multiple navigation avenues, don’t restrict navigation to a single area like the header. Take advantage of the Web’s interlinked nature. Having multiple links to the same place is a very good thing — but you have to start with an uncluttered and planned layout. Having a crap design overrides any positive usability gained here.

Number of clicks means nothing. This is the bogus default criteria that really translates to “I have no idea how to judge this interface”. Well structured, understandable navigation and content is the important factor. A ‘click’ has no friction or cost if the user knows what they’re looking for, and where to find it.

Oh, and responsive web design is a good idea.

Modularity and Style Guides

David Bushell — Mon, 23 Apr 2012 09:45:28 +0000

Last week I wrote about scoping typographic styles to introduce the concept of modularity in CSS. In that example, I removed the common globally defined text styles — for paragraphs, headings and lists etc — and scoped them with a .text class to be applied to any block of text-based content. This technique gives us more control and less conflicts.

It’s one of many techniques I use in front-end website development. Below I’ll introduce a few more and how I link them together for the ultimate Power Up ★

Disclaimer: there’s no holy grail to building a website!

Modularity

If you’re familiar with SMACSS, OOCSS or BEM you’ll understand the concept of creating reusable “blocks” or “modules”. These are patterns, both visually and in code, that can be reused and expanded upon when building web pages. Done right, time and complexity are significantly reduced. If you tackle each page one at a time, element by element, you end up repeating the same code over and over again. Methodologies like modularity solve the repetition problem exponentially as a website grows.

Before you get modular you need something to build.

Style Guides

Style guides (or pattern libraries) are the perfect place to start a website build and a modular base. They bridge the gap between design and development. They’re somewhat similar to a traditional brand guidelines but contain less fluff & nonsense and 100% practical code examples.

A good style guide starts with the basics like typography (see above) and moves onto more complex arrangements of content and UI elements, like navigation and form constructs.

The benefits of building a style guide first are enormous:

It shows the design elements you have at your disposal.
Its shows the design elements you lack.
It defines the modular HTML/CSS building blocks for the whole website.
It provides an accessible baseline on which to build upon.
It allows you to test code early in browsers and on devices.
Oh, and it leaves a design & build blueprint for future development.

Building the guide highlights weaknesses in a design (before it’s too late) and sets you on the path to build simplicity. Just throw all the elements onto one very long page; don’t waste too much time formatting it. The benefits are so incredible — I feel embarrassed for not utilising the style guide sooner! I use to consider them as additional work but actually it results in far less. Whether you choose to expose and bill the style guide to the client is a question for another day. If you’re a developer just do it anyway; it’ll make your life a whole lot easier.

What’s next? Continue building the website, you’ve already started.

At this point you’ll have written a whole lotta CSS and HTML. In fact, if your style guide is comprehensive enough you’ll have written the vast majority of it! Save that as your base.css or global.css and you could pretty much mark up the rest of the website with a vertical layout, i.e. the initial “mobile”/small-screen breakpoint, or breakpoint zero (since more capable small-screen devices may get advanced interactive layout beyond this).

Remember: the usability of a responsive design is directly proportional to the quality, planning, and arrangement of content. Don’t dismiss a technique that takes advantage of screen size for a problem it never claims to solve.

The next step is to provide layout (at progressively wider sizes using media queries if you’re going responsive). I use a combination of global and layout css (also seen in the Goldilocks Approach) and “Mobile First” CSS with legacy IE support. The reason I go further with a separate IE stylesheet is so layout.css doesn’t need to be afraid of advanced styling. It also means I can throw in the occasional max-width media query without issues. Yes, they’re legal.

And that’s it for now. I won’t go too far into how to actually structure your HTML & CSS. There’s too many factors to set out a single system. If you want to dabble with CSS pre-processors that’s great; whatever suits you. I have my own theories I may share soon — I’m not one for conforming to the general consensus! — but that’s for another day :)

On a similar topic, have a read of Paul Robert Lloyd’s Build a responsive site in a week: designing responsively (part 1) over at .net magazine. I’m liking the cut of his jib.

Scoping Typography CSS

David Bushell — Wed, 18 Apr 2012 11:29:24 +0000

I’m writing a very long article on front-end dev builds, this is a quick prelude to that!

It’s common practice to define global typography style early in a stylesheet. This makes a lot of sense. After all, a good design has consistent typography with a clear hierarchy throughout. When writing this CSS, type selectors like:

h1 { font-weight: bold; }
p { font-size: 1em; line-height: 1.5em; }

are necessary; adding classes to every text element isn’t feasible when you consider content managed websites and WYSIWYG editors. You’d have to be a nutter to do

everywhere. Global styles are great but there are a few catches:

Unique elements exist that are exceptions to the rule.
Many UI elements maintain semantics but are visually worlds apart from textual content, e.g. navigation with

The first example can easily be solved with small “modifier” classes like

. The second example requires hard overriding of styles.

The more your website resembles an application over a document, the more global typography styles become a pain to build upon. Even heavily content-based websites seem more like an app in the modern world of responsive design. The solution? Just scope typographic styles:

.text h1 { font-weight: bold; }
.text p { font-size: 1em; line-height: 1.5em; }

Simply choose a class that makes sense — I swing between .text and .content — and add it to any element that contains text-based content. This frees the rest of your HTML document from CSS pollution and effectively scopes the typographic style.

That is if you’re using a CSS reset, obviously…

Update: 7th May 2012 – I’m glad to know I’m not the only one doing this, see Opt-in Typography at CSS Tricks and Global typographic styles suck by Anthony Short.

Terms of Service TL;DR

David Bushell — Sun, 15 Apr 2012 11:17:06 +0000

This week saw an echo of praise around the tech community for photography website 500px’s approach to its Terms of Service page.

The basic idea being that the left column contains the verbose legal terms while the right column holds a brief layman’s translation. What I find worry is the vast number of web professionals who think this is a good idea and a great user-friendly design. It’s not!

Start by considering 500px’s introduction to their ToS:

You may only create an account after reading and accepting these terms. The column on the right provides a short explanation of the terms of use and is not legally binding.

If you want to use this service you have to read and accept the full version. This approach makes for an even longer read than normal — brevity here is a trick. Now consider 500px co-founder Evgeny Tchebotarev’s response to this praise:

While it’s not legally binding and doesn’t tell everything that is on the left side of the terms, it sums up things that we believe are important to photographers.

Tchebotarev emphasises that the brief version does not contain everything and he reiterates that it is not legally binding. As a fellow creative and web professional I have respect for my peers, this is an industry in which moral ethics are strong. I have no reason to doubt 500px’s good intentions but this approach is disingenuous. If you sign up to a social network — or any website supported by user-generated content — the Terms of Service and Privacy Policy are designed to do several things to the full extent of the law:

Minimise liability of the service provider.
Maximise responsibility of the user.
Take full rights to the users data.

I don’t pretend this practice isn’t messed up, law is fucked up, but it exists and in fairness to 500px it’s very difficult to operate a website without it. Here’s one of 500px’s killer lines:

By posting Content to the Site you hereby grant to 500px a non-exclusive, transferable, fully paid, worldwide license (with the right to sublicense) to use, distribute, reproduce, modify, adapt, publicly perform and publicly display such Content in connection with the Services.

This and many other points apparently translate to two simple notions:

Your photos will preserve whatever copyright they had before uploading to this site. We will protect the copyright and will not sell your photos without your permission.

Remember, the brief version is not “legally binding” and therefore irrelevant to the ToS. Now correct me if I’m wrong, but in reality a user is in fact giving 500px license to effectively do anything they like. This includes selling their photos (permission is given by accepting the ToS). Naturally a user retains copyright, but they’ve also agreed to the world’s most one-sided license agreement ever conceived. Almost every single website you sign up to has a similar catch-all agreement.

Do you see the problem here? Nobody reads these things. Tchebotarev himself admits, “I rarely read terms of use”. Providing a brief version that completely glosses over reality is only going to exasperate user concerns later on. If a service provider wants us to trust their ethics why are they so adverse to actually reflecting them in their terms?

Best intentions aside, this practice can only confuse the user more. Now instead of reading nothing users are only going to read the nice-but-useless version. And that, ultimately, is even more bullshit than the original. On the plus side it does shine some light on the founders morals if we choose to trust what we read. Because when you really read a website’s Terms of Service, trust is all you have.

Spotify & Socialite.js

David Bushell — Wed, 11 Apr 2012 13:23:35 +0000

Spotify have just released their Spotify Play Button allowing you to embed any song or playlist on your website or blog. It’s awesome, but it also comes at a cost.

The whole include (which uses an iframe) weights in at close to 500kb and uses upwards of 30 http requests alone. Chunky! Chunkier than many web pages.

Using this embedded play button is going to slow down your whole website if implemented poorly. Combine it with other social network goodies from Facebook et al and you’re presenting a very long loading experience to your users. That’s not good. Speed — or the perception thereof — is massively important. Imagine trying to load a website over a 3G network when half a megabyte of Facebook like button is shipped to your device before anything else. Awful! Yet most websites are still developed this way.

Asynchronous Loading

This is where asynchronous loading comes into play. Websites should defer the loading on non-critical elements (like sharing buttons and rich media) until the main content has been downloaded and initially rendered. Not a trivial task! Many social networks offer asynchronous methods but they don’t defer for long. I’ve been developing Socialite.js for that exact reason.

Extending Socialite.js

Today I’ve added the Spotify Play Button to Socialite.js. And if everything works, the link below should by now have magically transformed into a play button!

Listen to Sexy And I Know It by LMFAO on Spotify

The crucial thing being that all the hefty loading was done after the main content. Deferring external resources isn’t the only benefit of Socialite. Instead of ugly iframes and empty placeholder elements, Socialite allows for more accessible and usable defaults, such as the normal link used above:


	Listen to "Sexy And I Know It" on Spotify

Additionally, with Socialite you can load new instances at any time with JavaScript making web app development a whole lot easier.

Don’t bloat your website load — get asynchronous!

Help me develop Socialite.js over at Github.