Category Archives: Web Design

UX Cambridge: Stuart Church, From Darwin to Design

Stuart Church is an animal behaviourist turned UX consultant. He tweets as @stuchurch.

  • Darwin’s idea of evolutionary natural selection was one of the most powerful ideas of all time; the idea is something that is useful to us as interaction designers. Animals optimise what they do in a competitive Darwinian world, in the same way we want to optimise websites.
  • Biomimicry: There are amazing examples of adaptations in the animal world that influence/inspire product design — sticky plant seeds became velcro; there are swimming costumes inspired by shark skin; turbines shapes like whale fins; and lizard feet with sticky pads inspired adhesives.
  • Evolution is “the change in the inherited characteristics of biological populations over successive generations” aka “The survival of the fittest”.
  • Biological vs cultural evolution: Genes vs Memes (memes are the cultural analogue of genes, ideas that develop and are passed on. Good ones spread; bad ones don’t.)
  • There are selection pressures on genes: Prey, Mating, Competition, the physical environment, Pathogens/disease, Predators — a massive amount of pressure on an organism to survive.
  • For memes there are also pressures: Motivation, social factors (religion being the biggest example), utility/function, meaning, etc.
  • Designs as memes: Designs are ideas that are culturally inherited. Good designs serve a purpose and persist. Poor designs are forgotten. The unit of selection is the idea rather than the design itself.
  • What can we learn about design and innovation from evolutionary systems?
  • Evolution is just one big massive A/B experiment (“The Creator, if He exists, has an inordinate fondness for beetles” — JBS Haldane).
  • Design and innovation as experimentation: The ‘Lean’ concept, treating designs as experiments, and iterating through the cycle of idea>build>measure>data>learn.
  • Failure is the norm. 99.9% of all species that have ever existed are extinct. 80-95% of new products fail in their first year.
  • Innovations are not that innovative: “new but similar” – not necessarily different and radical.
  • “The adjacent possible.” Most successful ideas and innovations tend not be that different from what already exists. (This is also why we’re not all wearing jetpacks or living under the sea.)
  • Mixing it up: “Optimal Outbreeding” is why some animals don’t mate with others extremely genetically dissimilar to themselves. Sex allows you to experiment and create new gene combinations but you don’t want to lose the good combinations you have. New innovations often come from mixing up ideas too.
  • Ethnographic researchers visited labs, and observed that many ideas were being generated when people came together to share ideas rather than when working alone.
  • Ideas can be ‘too innovative’ — look at the Apple Newton.
  • Evolution is not gradual. It is characterised by periods of relative calm, followed by bursts of speciation when there is opportunity. This is called “Punctuated equilibrium“. For example, look at tablet evolution, pre- and post-iPad.
  • Can innovation be too fast? RNA viruses mutate rapidly, but not so rapidly that they lose self-identity (error catastrophe.) Could our desire to innovate ultimately be harmful? Can users/consumers keep up with the pace of change (gadget fatigue)?
  • Geographical isolation. The act of forming different species (speciation) often occurs when a population is separated. In terms of design, this manifests itself as cultural differences.
  • Evolution and behaviour. Can also apply evolutionary thinking at the level of individual behaviour.
  • Optimality theory. Behaviours are subject to natural selection, so animals will tend to behave in ways that are close to optimal.
  • Relationships and cooperation – technology is making us much more social.
  • The Prisoner’s Dilemma is a classic game theory problem, with well-documented solutions. What does this mean for UX? Can relationships with businesses/brands learn from the prisoner’s dilemma? Initial courtship vs long relationship. Reward points as a long-term strategy (e.g. Tesco).
  • Signalling and status. Some animals signal their quality to potential mates through visual displays (e.g. peacocks). To be effective, these need to be ‘honest’ signals (i.e. costly to produce). They are effectively a handicap as they may reduce ability to carry out other tasks (e.g. flying, foraging, etc.) — “The Handicap Principle.” Are there equivalents in design?
  • Optimal foraging theory. Animals forage optimally (or nearly). Prey and patch choice can be predicted and tested experimentally. Works for human hunter-gatherers too.
  • Information foraging theory. Humans as “informavores”. Foraging theories can be applied to people searching for information (Exaptation). Key thing that has come out of this work is the concept of information ‘scent’ — trigger words and feeling confident you are on the right path. People behave in a very similar ways to animals.
  • Jakob Nielsen said: “The two main strategies are to make your content look like a nutritious meal and signal that it’s an easy catch. These strategies must be used in combination: users will leave if the content is good but hard to find, or if it’s easy to find but offers only empty calories.”
  • Final thoughts: There is a lot of insight about the broader context of what we do that can be got out of this. The idea that when we come up with designs that we are putting them into this psychological landscape, with selection pressures acting upon them, is a powerful one.

UX Cambridge: Jeff Gothelf, Better product definition with Lean UX and Design Thinking

Jeff Gothelf is an interaction designer working for Neo in New York. He blogs at his personal site and tweets as @jboogie. His book Lean UX is out next March from O’Reilly.

  • Going to discuss defining better products using techniques of Lean UX and design thinking; how to use the ideas and philosophies behind these methodologies for better product definition and to build better products.
  • Case Study: Plancast (a social event sharing site) — had a big launch, write-up on TechCrunch, VC interest. They spent five months building the service, but it didn’t live up to hype and they sold after 3 years. The founder wrote a post mortem on TechCrunch: initial feedback made them think there was lots of interest; they measured ‘vanity metrics’ (registrations/visits) which gave them a false sense of success; the business plan was based on intuition, with no proof that the market was there. “Most social networks feed primarily on vanity… Sharing plans doesn’t present the same opportunity to show off and incur the same subsequent happy feelings.”
  • Key questions they should have asked: How long do we wait before we launch? (They took 5 months — was this too long?); How do we define the right requirements for our product? What signals are we looking for from the market? (AKA: How do we define success?)
  • All questions that can be answered with Lean UX and Design Thinking.
  • Requirements are really assumptions — guesses at what will meet the market’s need, unproven and untested).
  • If you define your product by ‘looking into a crystal ball’, you’re doing it wrong.
  • If you can build a culture that accepts that requirements are assumptions, you can build a culture of experimentation, where failure is embraced.
  • If requirements are really assumptions, we change our language: “We know” becomes “We believe”; “Let’s build it” becomes “Let’s test it.”
  • Design Thinking can help! “The ability to combine empathy for the context of a problem, creativity in the generation of insights and solutions, and rationality to analyse and fit solutions to the context.” Applies to the entire team.
  • Lean UX: “The practice of bringing the true nature of a product to light faster, in a collaborative, cross-functional way with less emphasis on deliverables and greater focus on a shared understanding of the actual experience being designed.”
  • Fundamental principle: Prioritise learning over growth. Find the right answer first, then scale it out.
  • Early product definition assumptions include: Who is our customer? What pain points do they have that our products/services solve? How will our product/service solve their pain points? What features are important? What is our differentiation (how are we going to win/make money)?
  • …which we then turn into hypotheses: “We believe that [building this feature] [for these people] will achieve [this outcome].” (Measurable business metric.)
  • “We will know we are successful when we see [this signal from the market].” == Test Driven Product Development.
  • Turn these hypotheses into experiments.
  • Case Study: TheLadders. The CEO had a ‘shower epiphany’ and decided every user would have a ‘personal job search assistant’ at the company. Lot of work — website, call centre, phone systems — months of work, based on his intuition that it would work. Nine months in, customer satisfaction/retention/sales not affected. Had a requirement; should have been a hypothesis, which becomes a starting point from which we begin. Gives us success criteria and suggests tests we can run to figure out if it might work.
  • How to test ideas: “Landing page to nowhere” to capture intent. Could have run a manual process on a small number of people. Could have focused on what outcome we were targeting.
  • Always ask yourself: What problem are we trying to solve? How will we solve it? How do we know it will work?
  • How does this change the way a team approaches a project? Measure of progress changes from output to outcome. You can launch features and they can still suck. Focus on driving team towards outcomes — which scale up towards impact (e.g. revenue).
  • Many companies currently manage to output, need to focus on outcome and not task teams with responsibility for impact.
  • Case Study: TheLadders. We were tasked with improving email response rate. Cross-functional team, small sprints, iterating, testing, qualitative and quantitative data. Pushed response rate from 14% to 68%.
  • For every hypothesis, as you collect data you end up with three options: Kill it; pivot; or double-down.
  • Case Study: Lenddo (micro-lending with the concept of a social-network based credit score). Users weren’t returning to add people to their network. We did usability testing with Balsamiq prototypes. Got feedback from the field before we committed resources, mitigating risk by not building things that people don’t want.
  • Case Study: Sesame Street. Wanted to enter the tablet education market; a new market, heavy investment, high risk, long term initiative. We treated the entire case as an assumption: wanted to make sure they were putting their money into the right project in the right way. Did class observation, watched teachers and students interact all day; wanted to see if teachers had time to look at a tablet; did the kids know what to do with these tools? Is there a viable market? Version 1: PDF content test on a tablet. Interviewed teachers before and after and observed. Learned a lot about content, how device works within context of classroom. V2: Card-sorting with features/content with teachers. V3: Clickable prototype to validate workflow.  Not a single line of code written.
  • Case Study: <redacted>. Subscription service to high-end customers that function in groups. Growth had flatlined, so they wanted to pivot the product to appeal to a broader audience, including more individuals. Risks: Significant investment, cannibalisation of current members, no guarantee new audience was interested. How will we know we’re on the right path? Made a clickable mockup on iPad, went to a convention and observed users. Only 5 days worth of effort.
  • Case Study: Agile UX NYC 2012. There are a lot of up-front costs when running a conference. We didn’t know if we should do this; would anyone attend? We did increasing levels of fidelity of testing; first we put up a launch page to capture email signups; next we put up an EventBrite page to sell tickets (no speakers, no venue). Tickets started to sell; proved the market was there and worth investing in.
  • Lean UX and Design Thinking are not just for designers. Cross-functional teams bring perspective to the product definition process from all disciplines; bring increased empathy for the user; a greater level of ownership in what you’re building; everyone understands the ‘why’ behind every initiative; you learn more, and move faster, by sharing the discovery and creation process.
  • Case Study: PayPal. Very silo’d organisation, difficult to have conversations across disciplines, and a very serial, waterfall process. Now they are literally breaking down the walls between teams, starting to work in cross-functional teams, learning how to work together and deliver products faster. Seeing benefits of working closely with developers, PMs, designers, and other departments. Working faster, focusing on outcomes instead of a set of features.
  • Defining the right product reduces the time spent building the wrong product; builds team-wide momentum and shared understanding in a recursive loop (it is more exciting to work on something for two weeks then launch it than work on it for 18 months); and ensures resources are spent on the right initiatives.
  • In summary: Requirements are assumptions; focus on outcomes; work together in cross-functional teams to come up with ideas; test those ideas ruthlessly.

UX Cambridge: Harry Brignull, From Print to Digital: designing The Week Magazine’s iPad app

Harry Brignull is a UX Consultant for Brighton consultancy Clearleft. He also maintains the DarkPatterns.org site, blogs at 90 Percent of Everything, and tweets as @harrybr.

  • Had a ealisation about our industry: We are all big, fat liars. We have an unwritten agreement about how design happens in our studios — we pretend its neat, never falters, proceeds towards a destination. Agency websites feature ridiculously good-looking wireframes; studio quality photos of our workshops. We pretend it happens in a tidy, linear fashion.
  • In reality it is a massive landscape of possibilities where we have no map, so we have to explore — and that involves red herrings, dead ends, fruitless avenues, and insights that are obvious in retrospect. Early stage design is messy and involves mistakes. We need to start being honest about this so our clients understand what this is all about.
  • The Week Magazine is a summary of the world’s top news that week; subscriber count has always been growing since they launched.
  • Our first big insight, then, was that we are not being brought in to reinvigorate a dying publication; they had a winning formula, we have to not screw it up.
  • Looked at their layouts across the years — it has never changed. Main story always laid out in a grid – event, editorial, commentary, future. We realised it’s not lazy, it’s clever — once you’re familiar with the layout, you can consume the articles faster.
  • How much of this can you fit on an iPad screen? Tiny proportion when compared by pixels on an iPad 2. Strength of the print edition is that it is lightweight and scannable — the content isn’t going to fit onto the iPad screen.
  • Trying to mimic a print version using a multi-column layout gives users a staccato reading experience, with 4-6 words per line.
  • The MailOnline iPad app was so complex it launches into a 19 page tutorial on first run.
  • The client had heated discussions about their goals for their app — only agreed that we had to not screw it up.
  • Did hours of interviews, then a stakeholder workshop — had low opinion of them before, but true valuable output is in shared vision it creates. Did empathy maps/persona sketches, then UI sketches; reviewed sketches with reference back to the empathy maps.
  • Useful, but not for the reason you’d expect. The Romeo & Juliet effect is when a barrier is placed between a person and their desires, the object becomes more alluring — it happens to clients when they have a design idea that never gets implemented, and can lead to radical new change requests partway through. The workshop avoided this, as it meant all those ideas had been explored and rejected already.
  • List of ideas derived from the workshop were all standard things/truisms — but as they came from the stakeholders, they had a sense of ownership.
  • Information Architecture: We need section pages with excerpts of articles; Contents, Section page, Article page.
  • Advertising team wanted ads to appear in relevant sections, we wanted to avoid ads altogether. Pitched idea of full-screen ads appearing between section pages.
  • Made an iOS native app, took it into usability testing. Made the classic architects mistake — designing for fictitious user behaviour that only exists in our heads. Users were casually flicking back and forth between sections (causing the ads to appear much more often), not getting the idea of the three-tier IA, and some that would get down into an article would then get stuck.
  • The feeling of not understanding how your users can be so dumb is actually denial that your design decisions have been so wrong.
  • Problem: Articles pages were too similar to section page, we were not giving enough emphasis to the transition between the two levels.
  • Realised we could use two-pane layout like Apple Mail, with sections on left and the article on right — now we have 2, very distinct, IA layers.
  • Second round of usability testing; all problems solved.
  • We still make some mistakes with gestural UI. The map-based interface used a different UI for moving through articles, which contrasted with the rest of the app and was disconcerting to users. You have to evaluate your interface in context — the whole is greater than the sum of its parts.
  • What made the project successful was how everyone reacted after the first round of user testing. We were lucky to have a client that understood good design process involves mistakes and wrong turns. No mistakes means you’re not exploring or trying anything new.
  • We all stand to benefit by being a lot more honest about how we do design, so next time you’re writing or presenting — don’t be scared, just tell it how it happened.

Harry’s own write-up of his presentation can be read here:

http://www.90percentofeverything.com/2012/04/20/from-print-to-ipad-designing-a-reading-experience/

UX Cambridge: Vasilis van Gemert, New Smarter Defaults in Web Design

Vasilis van Gemert is a Dutch developer living and working in Amsterdam. He is currently the Principal Front-End Developer at Mirabeau and a member of the Fronteers board. His personal site is vasilis.nl, he posts links daily at dailynerd.nl, and tweets at @vasilis.

Edit: You can now access the slides from Vasilis’s talk on his website.

  • More and more you hear people say the web has changed – but how has the web changed?
  • The size of the web has changed; we’ve gone from 640×480, then 800×600, now it’s 1280, but also 320×480 — the web isn’t growing any more
  • Everybody has a mouse — except for everybody that doesn’t
  • Everybody has broadband — except for everybody that doesn’t
  • All monitors are calibrated — only those of visual professionals
  • Computers get faster every year — except for those that don’t (and we want stuff that lasts for years)
  • The Dao of Web Design was saying the same thing years ago
  • futurefriend.ly described how you could develop for the future (but basically said “We don’t know”)
  • Old Kindles are good ways to test contrast of designs
  • Last month, 60-70 different mobile devices entered the market
  • Going to talk about some new defaults positions we should consider for interaction design, visual design, content strategy, functional design
  • New default: Touch First – a standard dropdown menu with a touch device doesn’t work (there is a default link for the top-level, click area is too small for fat fingers. Redesign, make bigger links, suppress the top-level link. Never forget the keyboard, don’t remove the focus outline
  • Think in layers – progressive enhancement (“is a principle, not a technique”)
  • On the web we have to support old browsers, modern browsers, future browsers, robots, humans, small screens, fat fingers, etc.
  • The web design stack: content, typography, layout, paint
  • Content will work for everyone, any browser. Typography works just about everywhere (small screens). After that let’s think about layout.
  • New default: Small Screen First
  • Expanding a website to fill more space is easy, but shrinking to a small screen is hard – forces you to focus, what’s really important, first things first
  • Brad Frost’s Ish (http://bradfrostweb.com/demo/ish/) to test sites at different screen sizes
  • It’s up to the visual designer to decide breakpoints — never let the developer decide these things [laughter]
  • Showing a video of filling in a non-optimised form on iPhone (scrolling, wrong keyboards) and improved version (top-aligned labels, html5 input types)
  • New default: Content First
  • How we used to make websites — a logo, navigation, sub-nav, widgets, footer, then cram content into space left over
  • Now we start with the content… and then ask yourself; do we need widgets, sub navigation, header, a logo? (example – all blogs used to have a sidebar, now the ‘default’ is to not have a sidebar)
  • If we do need these things, do they need to be in the place where they are? Logo is in the most important, expensive place. Header is huge — but people come for the content, not for your header
  • Browsers are our friends, not enemies (mostly), this means clean code, this means we can actually redesign a site — we always talked about redesigning with stylesheets only, but it was never a reality due to browser issues; now it could actually be possible
  • New default: CLI First – the web is not just articles, what devices will we use in 2 years?
  • Use the command line – test your app before you design it (see Luke Wroblewski’s article, discussing how they built and tested the API before they designed the site) — it’s a really interesting approach, so find a good nerd to work with
  • A solid API also lets others do the work, and they can make things you don’t have the time or imagination to make

Sketchnotes of the session by Jenny Willatt:

Sketchnote of Vasilis van Gemert talk at UX Cambridge 2012

UX Cambridge: Richard Caddick, The Power of the Imagination

Richard Caddick is a founder of Bristol’s CX Partners, and author of Communicating the User Experience. He tweets at @richardcaddick.

  • Don’t focus on the idea, but the process of imagination/problem solving
  • Imagination can be thought of as a Venn diagram: What has been, What is, What could be — in UX, this maps to Insight, Empathy, Creativity
  • Creativity. Compare Turner’s paintings from the start and end of his life; what happened in between to change him? He was apprenticed (learned from experts), thought about colour theory, using new technology (new colours became available, tubes of paint were invented), travelled (UK, Italy, France, Switzerland) to learn about differences in light/location, produced over 19,000 works.
  • The baker Christina Tosi: started with lots of experimentation and lack of constraints.
  • Showed a picture by Felix Baumgartner aged 5 of himself falling from the sky; he had a focus, having a vision is powerful.
  • Becoming imaginative isn’t passive, it’s something we can consciously do. We can practice what we do to build up our skills. Teaching helps us learn how to communicate our ideas to other people. Observation shows us what is going on in the world/people around me. The ability to Experiment/prototype; asking questions/debating and reflection – what can i learn from what i’ve done so far. Vision – know the direction in which you are heading.
  • Insight + Empathy = Deep understanding, which comes from better research. It’s very easy to get into the habit of doing a little bit of regular research, which then just sits there. You’re not getting any value or understanding out of research.
  • mobiserve.eu is a project investigating how we can keep the elderly population more active/mobile in their own environment. Involves a robot that interacts with a person. Researchers used disposable cameras, 2 per person, with a sad and happy face drawn on them. Users were asked to use the cameras to take photos of things that made them happy or sad. These photos (and the explanations behind them) increased designers’ empathy towards their users. Interviews are important to reduce assumptions about users’ feelings.
  • How about our own experiences? Richard talks about having testicular cancer. Moved from basic empathy to deep understanding of what it feels like to have that kind of illness. Sometimes we forget users in research have multi-faceted lives. Imagination draws on your own experiences to heighten feelings of empathy and decisions you make.
  • As designers we create and think we can solve problems.
  • Arthur Fry worked for 3M and sang in his church choir, but he often lost his place in his hymn book. He wanted to invent something to keep his place, and the Post-It note was born.
  • As humans we have the incredible ability to feel for people we don’t know. Need our stakeholders to have empathy for their users. Case study: a local council site with problems. It would have been easy to just make the buttons and text clearer; instead used empathy mapping techniques to go through planning application process. Natural empathy makes people build more detailed picture of user than just listing facts.
  • In the 90s, a virtual reality experience was used to give doctors an experience to encourage empathy for patients suffering from fatigue. 60% of doctors said they would change how they would treat their patients.
  • What about our projects? Treat projects as several periods of open imagination closing in on solutions/answers. Consider the dynamics of projects, the context/level of detail, and activities to stimulate creativity.
  • Someone to encourage, someone to challenge – we need people that fulfil these roles for us.
  • Constraints vs freedom. As designers, constraints are more useful – they make us more innovative (e.g. car design has improved within the constraints of legislation around emissions).
  • New and familiar – the temptation is to be really creative, but sometimes customers need familiarity. You need both.
  • Play. The people we are designing for are also imaginative and playful people. They want freedom. If we try to constrain people when they’re in their decision-making process (when all the things affecting their decision are jumbled up as if in a washing machine) it feels unnatural.  There is a massive experience gap between what people are trying to do and what technology is letting them do. Computation doesn’t fit with people’s imagination/individuality. We want people to think and imagine.
  • An example of a dull product put across in imaginative way: an old Union Carbide ad.
  • User research involving mobile devices gets much better/truer responses when users can use their own device instead of being given one.
  • Book recommendation: Computers as Theatre by Brenda Laurel
  • Story of the invention of the Brooks bike saddle. John Brooks was a leather manufacturer. His horse died, he couldn’t afford a new one, so he borrowed a friend’s bicycle, which back then didn’t have saddles (instead they had wooden planks). So Brooks patented the leather bike saddle. Bike saddles are interesting technology, because they get better with time (becoming more comfortable). How can we create stuff like this?
  • “Be yourself, everyone else is already taken.” – Oscar Wilde

Sketchnotes of the session by Jenny Willatt:

Sketchnote of Richard Caddick talk at UX Cambridge 2012

Synaesthesia.js

Ever found yourself struggling to choose a colour scheme for a new project? Maybe you browse sites like Adobe’s Kuler or COLOURlovers; perhaps you find photographs that capture the mood of the site you’re trying to design; or maybe you click aimlessly on Photoshop’s colour-wheel until inspiration strikes.

Well, fear not – here’s another pointless and entirely arbitrary way to select those all-important tints and shades. Synaesthesia.js is my JavaScript solution for the inspiration-impaired.

How it works

The script converts whatever you type (discarding any non-alpha characters) into shiny hex colour codes, and shows you the result. The results update as you type, so you can try out creative new ways to spell.

How it actually works

  • Letters are matched to a hex code: A becomes 0, B becomes 1, C becomes 2, and so on through to Z (9, in case you were wondering).
  • From the resulting string of hex, each substring of six characters is used to create a colour block.
  • The colour blocks are appended to the target element, together with the hex code for easy copy-pasting into Photoshop or your text editor.

And that’s all there is to it! Have fun – the project is also on GitHub if you want to play with the code.

Quick and dirty debugging of the notorious ExpressionEngine blank page bug

I don’t do a lot of ExpressionEngine work any more, but I still get the occasional email about it. More often than not, a serious bug triggers the uniquely ExpressionEngine response of a completely blank page. Not particularly helpful when you’re trying to debug the issue.

Although there are various settings you can trigger in the admin, I found the easiest thing to do is to add the following lines to the index.php file in your site root, just below the error_reporting(0) line (EE 1.6-7) or the $debug declaration (EE 2):

Reload the affected page to see the PHP error that is being thrown and figure out where to start debugging.

And of course, don’t forget to remove the debug code once you’re back up and running!

Future of Web Design 2012

Later today I’l be jetting off yet again, bound for London and the Future of Web Design conference, taking place over the next two days.

Stuart Frisby and I will be there as part of the Booking.com recruitment bandwagon, handing out goodies and trying very hard to tempt the cream of the UK’s web design scene to up sticks and relocate to beautiful Amsterdam.

Hopefully we’ll be able to catch some of the talks while we’re there as well. I’m looking forward to hearing Brendan Dawes for the first time; Vitaly “Smashing Magazine” Friedman, Steve Fisher and Laura Kalbag will be the first non-Marcottes I’ve seen talk about Responsive; and the closing talks by Martin Beeby and Mark Boulton both promise to be inspiring.

If you’re attending, make sure to come and say hi – and if you overhear anyone complaining about their job, be sure to point them in our direction!

Throwing out the kitchen sink

In a recent post on the BBC Responsive News blog, Tom Maslen makes the case for a significantly more aggressive browser grading strategy.

Browser grading, as a formal concept, was popularised by Yahoo! back in the day. At the time, their support matrix was understandably generous: IE6 and Firefox 2.0 were both “A-grade” browsers at the time, which by Yahoo!’s standards meant that they deserved the full, bells-and-whistles experience. Their policy has changed over the years; they no longer explicitly specify an A/C/X grade to indicate support, but instead use the woolier term “test baseline” to determine which browsers belong in their QA suite. IE6 and their low percentage ilk remain C-grade, meaning they receive:

…nothing more than semantic HTML, the content and experience is highly accessible, unenhanced by decoration or advanced functionality, and forward and backward compatible. Layers of style and behavior are omitted.

Progressive Enhancement in a nutshell.

Maslen’s hierarchy of browser needs

The BBC’s approach, while sharing the PE philosophy, is significantly more exclusionary. A single line of JavaScript leverages browser feature detection to decide whether you’re one of the chosen few:

if ('querySelector' in document
&& 'localStorage' in window
&& 'addEventListener' in window) {
// bootstrap the javascript application
}

The upshot of this simple check is that IE9+ and all other modern browsers get the progressive sugar. And, according to Maslen, it also means that (because you now know that your visitor’s browser supports such useful shortcuts as document.querySelector and window.addEventListener) you can avoid the need for large and slow-to-download JavaScript libraries. Instead:

…we can now develop JavaScript solutions that use native implementations of features that we have grown accustomed to using without having to download polyfilling libraries.

I have a problem with this approach.

Baby with the bath water

Reducing page weight is a noble aim. A recent article from Pingdom contains some statistics on the increase in average KB over the last year; it’s certainly true that the golden rule I grew up with – no page should ever be over 100Kb – has long since been mothballed. And, as Maslen’s and Pingdom’s articles indicate, the explosion in the use of JavaScript libraries is definitely a part of the problem, despite also evidently being the solution to many developers’ prayers. By abstracting away all of the cross-browser headaches and leaving novices with a single, easy to learn API, libraries such as jQuery have secured a place in almost every developer’s default template.

Maslen contends that, if the primary reason for using a library is to work around the lack of universal support for querySelector and the like, you don’t need it providing you are only targeting browsers with native support for that feature. Bang – well done, you just reduced your page weight by 32Kb or more!

I have two main issues here:

  1. By excluding users on IE8 and lower, you are potentially cutting off a quarter or more of your audience from experiencing the intended experience. This proportion will also vary depending on what day it is (IE usage rises during the week when people are at work without the freedom to choose their browser) and from what part of the world your site is being accessed (IE6′s share of US traffic might be sub 1%, but could be closer to 50% in China according to Wikipedia).
  2. Replacing library functionality with native doesn’t really gain you anything in modern browsers. Any decent library will be checking for the native functionality first, so the library function simply becomes a reference to the native function.

So, if ‘going native’ has no meaningful benefit for A-grade browsers, and you don’t want to exclude large swathes of your traffic, what are we left with in the “No” column for library usage? File size.

I accidentally a whole JavaScript library

jQuery and other libraries are attractive because they make it possible to do clever things with web pages without the need to actually learn or understand JavaScript. Novices can drop the core library into a page, throw in a few other plugins, maybe the jQuery UI module as well, and get started on making things appear, disappear, or fly around the page. And for the hobbyist or small business that might be okay, but at scale you naturally start to worry about download speed, concatenation, minification, and all the other site speed buzzwords. But I’m going to let you in on a little secret…

Nobody ever said that you had to use the whole library.

Don’t need to use any AJAX requests? Strip that shit out. Same for animation, event handlers you’re never going to use, dimension calculations – in fact, anything that you don’t actually need to use can be removed (or commented out, then minified using a minifier that ignores comments).

Of course, this approach requires you to know what you’re doing when it comes to native JavaScript; but so does Maslen’s proposal, and by choosing to keep the library you’re scoring some significant benefits:

  • There is now no need to exclude older browsers that don’t support the native features simulated by the library;
  • You can spend your time creating new functionality, instead of painstakingly recreating something that was already present in the library you threw away.

Library authors have put in many thousands of hours figuring out the most efficient, compact and bug-free way to do most of the things you’re likely to need on a web site. Ignoring that free labour in favour of doing it yourself to help fewer people just seems like the wrong decision.

Should your logo link to your homepage? Google says no.

Ever since I’ve been building web pages, it has been gospel that your logo (top-left, of course) should be a hyperlink back to your homepage. Jakob Nielsen’s seminal Homepage Usability recommended as such (with the caveat that the link should not be live on the actual homepage), and it is almost a subconscious action to wrap that IMG or text in an A tag and link it to “/”.

Strangely though, Google’s most recent refresh of their apps have dropped this two-decade convention. None of their properties – GMail, Google Docs, Google+, et al – make the Google logo into a link; now if you want to return to the default view of the app, you must locate and click the much smaller “Home” link (or, in the case of Google+, the even smaller Home icon in the navigation bar).

I suspect that the reason is an attempt to train users that the top light-grey bar on all Google’s properties is not tied to the app you are currently using, but is instead a persistent area present across the entire range. The right-hand end of the bar is now home to your G+ notifications, avatar and share link, so perhaps they hope that by dedicating the top 100px of the page to their social network they can encourage adoption and/or use. I think that the loss in terms of usability and user expectation is disappointing.