UX need to alter how they perceive responsive web design, they need to address the scenarios of hostile browsers, tiny screens, slow connection speeds and touch inputs by default. Responsive web design isn’t about mobile or desktop, rather its about adopting a more flexible approach to the web. It’s about accepting that we never really had any control over how the user consumed our content. And instead of trying to force users, browsers and their internet connections to work how we would like them to, its about designing an experience that moves in the same direction as the web, using the flow of the web’s current to move faster to our destination of larger audiences.
“In 2012 GitHub started using Sass. What started as an experiment in internal apps has become our preferred way to build and style our web applications. In this talk I’ll cover how we did it, what we’ve learned, performance tips, and what we think constitutes good code. We even use Sass when designing for native apps.”
Today, I tweeted:
Challenging responsive web design is a long and difficult process. But when it finally shows its shortcomings, then it becomes a lot easier.— Kaelig (@kaelig) February 18, 2014
Following this tweet, I was asked by @lhid to provide some context. Here we go:
Recently, responsive web design seems to have become the default strategy for a lot of large redesign projects. And they seem to be quite successful so far! Good for them.
When building a responsive website and it is successful, we could mistake RWD for the reason behind its success. If we measure success by comparing a new shiny responsive site to crappy, old desktop and mobile sites, in a space where mobile and tablet usage is growing at an unprecedented pace… Of course the new responsive site will perform well.
Recent redesigns reveal RWD shows good results when limited to mobile and tablet. Unfortunately it struggles to provide an optimal, clean and light output on desktop at the same time. Responsive sites tend to use cutting edge web technologies that may leave a lot of our desktop users behind (especially those in corporate environments). Can we afford to lose these desktop users so that we can satisfy more mobile and tablet users? And if we wish to support these older browsers, can we accept the hit on mobile performance that might flow from all the extra code? These are so many hard choices we should not have to constantly make…
I have faith RWD will make sense in the future as a global strategy, but not today. Our tools and processes are too young and too poorly capable to help us delivering truly great experiences to all of our users on a fully responsive website. Design tools, web standards, browsers, development techniques and advertisement: they all need to mature a lot before RWD shows what it really is capable of. I also have hopes that the web will catch up with apps in many regards, as native apps are known to be a much higher engagement driver than websites (which is why they are still part of today’s equation).
Responsive Web Design is not the answer, it is just part of it.
There are viable alternatives to fully responsive websites. I’d encourage building multiple experiences on the same core architecture, catering for both users and business needs, respecting content and feature parity across platforms, using tools and processes we already know. It can help us understand technology and master new processes in agility, so that we are ready when the rest of the ecosystem finally is too.
In the mean time, I really like the idea of a partially responsive site with dedicated experiences for the parts where RWD fails to provide an acceptable experience. If I have the chance to test this approach at the Guardian, I will write on this subject in the next few weeks.
In his presentation at Take Off 2014, Patrick Hamann presents the problems front-end engineers are facing with CSS when developing high performance web applications. He goes through the techniques we use at the Guardian to stay off the critical path, improving the perceived performance for our users.
In this internal teach & learn session at Paypal, Hoa Doan Klein goes through the core principles behind OOCSS and SMACSS, and then explains how her team applied those principles to build their project (an online billing form).
She struggles a little bit when asked questions around the concept of “re-paints” and “overriding rules”, but this is still a video you should watch if you want to know what OOCSS and SMACSS are all about.
About twenty months ago, I was writing constantly. I
wantedneeded to share what I had learned during my years of experience in a web agency. I was also writing a book and maintaining this blog fairly frequently.
I was living in a rather small city in the West of France, away from the central area where the night life and cultural life happen. After a commute back home, there was not much to do aside from chilling in front of the TV or going back to my computer (writing or coding).
In May 2012, I moved to London to work at the BBC and I also felt like blogging about what I was discovering in the world of mobile web development. My wage barely paid my rent, debts, and the taxes I still had to pay for in France. When coming back home after a day at work, the only things I could afford to do were coding, writing, reading, and watching TV. Which is a bit of a shame in a city like London.
Then I changed jobs and my salary increased substantially. Since I could afford it, I started going out almost every night, jumping on a red bus or a black cab to any venue that had some jazz, rock or acoustic gig playing, wine tastings, comedy shows, musicals, clubbing… I was discovering what this amazing city has to offer, losing focus on web development and finally finding a more normal work/live balance.
"Sir, when a man is tired of London, he is tired of life; for there is in London all that life can afford."
— Samuel Johnson
Commuting, interviewing for new jobs, joining a new company every 6 months, looking for a new accommodation, moving between flats, living in an amazingly cultural city… This routine is tiring and it does not leave much time for writing and reading about web development outside of work. By the way, I admire people who have much more busy lives, children and/or relatives to take care of and still manage to make room in their crazy schedules for writing and reading.
I also have the chance to work with extremely talented people who put the bar so high that I feel like an impostor when writing about web development. Being in a crowd of unbelievably skilled people has this effect on me that I don’t feel entitled to put myself in a teaching position.
In a sense, people may expect me to write good articles and good code, and I fear that I may not live up to their expectations.
Today, I am very tired and I get distracted very easily. Focusing on writing is extremely hard and I have 4 major publishers who count on me to write 3 blog articles and a book. Two years ago, I wished I would be lucky enough to be able to write for those publishers one day, and yet I am delaying writing because every time I try to, it is painfully hard.
I can’t wait to feel that irrepressible need to write about web development again and get back on the writing wagon very soon. Thankfully, people like my girlfriend are encouraging me to dedicate time slots to thinking and blogging…
In a way, writing about my writer’s block is the first step towards recovery…