A larger screen is now a progressive enhancement. Hell, with things like Siri and Google Now and Amazon’s Echo, we’re getting to the point where even a screen is an enhancement.
I really, really want to like this article—it’s chock full of confirmation bias for me. But it’s so badly-written …I mean like, just the worst.
Here’s an actual sentence:
So with a capable, HTML-based platform and a well-designed program that makes good use of CSS, one site could support phones, tablets, PCs, and just about anything else with one site.
So, yeah, I’m still linking to it, but instead of it being for the content, it’s because I want to lament the dreadful state of technology writing.
A useful primer on which combinations of attributes and values work best for which form fields:
Following on from that last link, here’s an in-depth run-down of what you can do in mobile browsers today. I think a lot of people internalised “what you can’t do on the web” a while back—it’s well worth periodically revisiting the feature landscape to revise that ever-shrinking list.
Perhaps the biggest advantage the web has over native apps is how quickly users are able to engage. All that’s between the user and your content is one click.
Jennison Asuncion outlines the problem with relying on a swipe gesture for interactions.
I would say that this could be expanded to just about any interaction: it’s always dangerous to rely on one specific gesture. It’s always better to either provide multiple ways of accomplishing a task, or to simply take a declarative approach, get out of the way, and let the user agent handle it.
Why Atavist is betting on the web. See also:
Tom’s thoughts on what AMP means for developers and publishers. He was initially sceptical but now he’s cautiously optimistic. Like me, he’s hoping that AMP can force the hand of those third-party advertisers to get their act together.
Publisher’s development teams are very capable of creating fast experiences for mobile users, but they don’t have the clout to coordinate all the additional cruft that is added to the page. However, if all the different publishers dev team’s got together and put their weight behind a single implementation, then we can force third parties to change their habits.
I’d like to do this for all Clearleft web projects.
How important is mobile for @nytimes? We’re blocking access to our home page on desktop in our building.
I can relate 100% to what Dave is saying here:
I’m disenchanted with desktop. That conviction runs so deep, I groan when I see a desktop layout JPEG.
All too often we talk the talk about taking a mobile first approach, but we rarely walk the walk. Most designers and developers still think of the small-screen viewport as the exception, not the norm.
For once, Betteridge’s Law of Headlines doesn’t hold true, because the data in this article shows that the answer is a resounding “yes!”
The key change in all of this, I think, is that Google has gone from a world of almost perfect clarity - a text search box, a web-link index, a middle-class family’s home - to one of perfect complexity - every possible kind of user, device, access and data type. It’s gone from a firehose to a rain storm. But on the other hand, no-one knows water like Google. No-one else has the same lead in building understanding of how to deal with this. Hence, I think, one should think of every app, service, drive and platform from Google not so much as channels that might conflict but as varying end-points to a unified underlying strategy, which one might characterize as ‘know a lot about how to know a lot’.
Luke continues to tilt against the windmills of the security theatre inertia that still has us hiding passwords by default. As ever, he’s got the data to back up his findings.
Designing primarily in a laptop web browser and testing with a mouse rather than fingers may come to look very out of date soon.
But as people spend more time on their mobile devices and in their apps, their Internet has taken a step backward, becoming more isolated, more disorganized and ultimately harder to use — more like the web before search engines.
I’m an advocate for progressive enhancement. Tom Dale is not. But even though we may disagree on that, there’s a lot to like in his sensible, balanced answers to some sensationalist linkbaity questions.
It’s not that the pace of innovation on the Web is slower, it’s just solving a problem that is an order of magnitude more challenging than how to build and distribute trusted apps for a single platform. As we saw on the desktop, it may take a few years to catch up to all of the capabilities of a native, proprietary platform, but in terms of the impact it will have on humanity, forgive me for not losing sleep if we have to wait a few years for it to arrive.
This isn’t a scientific data sample, but Jonathan’s anecdotal evidence seems to suggest that most web designers and developers are still thinking with a desktop-first mentality. Which is crazy.
The Android vs. iOS debate is one hinges around whether you think it makes more sense to target a (perceived) larger market, or target one that the technorati favor. But why choose? Building a good responsive web app has a series of benefits, the primary one being that you target users on every platform with one app. Every user. Every platform. All the time. Release whenever you want. A/B test with ease. Go, go go.
A fantastic collection of short videos from Luke on interaction design for devices of all shapes and sizes.
Make yourself a nice cup of tea, hit “Play all”, sit back, relax and learn from the master.
A concise case study from gov.uk:
Designing for the constraints of mobile is useful – if we get the fundamentals of the service working on small screens and slow network speeds, it can work on more capable devices.
John echoes some of my recent thinking about what qualifies as a web browser and, by extension, what qualifies as the web:
We shouldn’t think of “the web” as only what renders in web browsers. We should think of the web as anything transmitted using HTTP and HTTPS. Apps and websites are peers, not competitors. They’re all just clients to the same services.
That said, I think he is perhaps underestimating the power of URLs. Addressability—particularly over an extended time period—remains the powerful feature of the web.
A handy way of automating the creation of old-IE stylesheets using Grunt. This follows on from Jake’s work in using preprocessors and conditional comments to send a different stylesheet to IE8 and below—one that doesn’t contain media queries. It’s a clever way of creating mobile-first responsive sites that still provide large-screen styles to older versions of IE.
A great write-up of the design process behind The Guardian’s responsive site. It’s really gratifying to see UX designers talking about performance.
I think Chrome is doing the right thing by removing the 300 millisecond tap delay on sites that set width=device-width — it’s certainly better than only doing it on sites that set user-scalable=no, which felt like rewarding bad behaviour.
Good luck getting that script updated for the thousands of sites and applications, you say to yourself, where it’s laying dormant just waiting to send devices the wrong content based on a UA substring.
Dan Bricklin—co-creator of the original VisiCalc spreadsheet—turns his attention to responsive design, specifically for input-centric tasks.
The case may be a little overstated, but I agree with the sentiment of this. The web is always playing catch-up to something. For a while, it was Flash; now it’s native.
Flash was a great stopgap measure. But it outlived its usefulness and has been reduced to niche status.
Today, we’re seeing the nearly exact same scenario with native apps on mobile devices.
Native mobile apps are a temporary solution. We’re just over 4 years into the Appstore era and this has already become apparent. Open web technologies are catching up to the point that the vast majority of web apps no longer need a native counterpart.
A great presentation from Brian Boyer on NPR’s mobile strategy. Spoiler: it’s responsive design.
I heartily concur with Lyza’s mini-manifesto:
I think we need to try to do as little as possible when we build the future web …putting commonality first, approaching differentiation carefully.
It’s always surprised me how quickly developers will reach for complex, potentially over-engineered solutions, when—in my experience—that approach invariably creates more problems than it solves.
Simplicity is powerful.
Scott gives us an excellent State Of The Web address, looking at how the web can be central to the coming age of ubiquitous computing. He rightly skips through the imitation of native apps and gets down to the potential of just-in-time interactions.
Preach it, Karen!
“Why would someone ever want to do that?” is the wrong question. It doesn’t matter why they want to do it. The fact is that people do. The right question, the one that we all should be asking, is “how can we make a better experience for them?”
A look at the degree of diversity in Android devices, complete with pretty pictures. The term “fragmentation” is usually used in a negative way, but there are great points here about the positive effects for web developers and customers.
You say fragmentation, I say diversity.
Good news from Google: it’s going to start actively penalising sites for perpetrating the worst practices for mobile e.g. redirecting a specific “desktop” URL to a the homepage of the mobile site, or for shoving a doorslam “download our app” message at users.
I wish that we could convince people not to do that crap on the basis of it being, well, crap. But when all else fails, saying “Google says so” carries a lot of weight (see also: semantics, accessibility, yadda, yadda, yadda).
Details on how the BBC Responsive News team plan to eventually make their m-dot site scale all the way up to be the default site. This “planting a seed” approach works really well, not least for political reasons.
Joking aside, this is a useful resource for keeping track of the current spread of Android versions.
A couple of years ago, the benefits of separate sites were more clear to me. Today, I can’t think of a good reason to maintain a separate mobile site.
I think it’s a bit of a shame that Brett is canning his mobile-first device-detection library, but I totally understand (and agree with) his reasons.
There is a consensual hallucination in the market, that we can silo devices into set categories like mobile, tablet, and desktop, yet the reality is drawing these lines in the sand is not an easy task.
An excellent explanation from Tom Loosemore on why the Government Digital Service is putting its energy into open standards and the web, rather than proprietary native apps.
A very handy technique from Cennydd for answering the “it depends” question of when you might need a separate device-specific site (‘though I think that a separate can be a good option in addition to a responsive site, rather than instead of).
And this is why user-agent sniffing not a future-friendly technique. A new mobile browser comes along, and it has to spoof a fake UA string to all of these sites.
It’s a Red Queen arms race.
A great meaty piece from Cennydd, diving deep into the tricky question of context.
I think this is kind of brilliant.
I share Tom’s frustration with news apps that should be websites:
I wouldn’t download a BBC app or an NPR app for my computer. Why would I want one on my phone?
Spimify your household with these bluetooth location stickers. Now you can google your shoes.
Amen, Brad, Amen.
It’s time for us to treat performance as an essential design feature, not just as a technical best practice.
A great piece by Jason analysing the ever-blurring lines between device classes.
Mind you, there is one question he doesn’t answer which would help clear up his framing of the situation. That question is:
What’s a web app?
All the videos from last year’s Breaking Development conference in Dallas are up on the site. They’re all excellent.
A great breakdown of mobile traffic to The Guardian website over time.
The best “Mobile First” strategy is an “API First” strategy:
“Mobile first” companies really are just a front end selection accessing a solid API driven backend infrastructure.
I think Luke would agree. He built a command line interface for Bagcheck, for example, before there was even a UI—mobile or otherwise.
David takes a look at worldwide trends in web browsing, pointing out where mobile traffic exceeds desktop …and we’re not necessarily talking about smartphones here either.
It would be possible to travel from the Niger Delta on the west coast of Africa, to the horn of Africa on the east coast, without passing through a country where people surf more on desktop than a mobile phone.
This looks like it could be one alternative to Adobe Shadow or Edge Inspect or whatever they’re calling it now that they’re charging $120 a year for using it.
I know how Brad feels. I find it hard to muster any enthusiasm for any specific new device these days. But that’s okay. It’s more important to step back and see the trends and directions instead of getting caught up in the specifics of this particular phone or that particular tablet.
My remedy for device fatigue has been to take a step back and let my eyes go unfocused. Much like a Magic Eye, I can then see the hidden pictures behind the stippled noise that is the device landscape. This remedy helps me cope, gets me to stop caring about things that don’t really matter, and gets me to care about the broader trends the Magic Eye unveils.
Andrea looks at support for HTML5 input types in IE10 Mobile.
I concur completely with Luke’s assessment here. Most password-masking on the web is just security theatre. Displaying password inputs by default (but with an option to hide) should be the norm.
Josh takes an-depth look at the navigation design implications of touch/keyboard hybrid devices, coming to a similar conclusion as Luke and Jason:
Unfortunately, the top-of-screen navigation and menus of traditional desktop layouts are outright hostile to hybrid ergonomics. Tried-and-true desktop conventions have to change to make room for fingers and thumbs.
Want to test for a hybrid device? Tough luck. Instead, argues Josh, the best you can do is assume that any device visiting your site could be touch-enabled.
A behind-the-scenes look at how Gov.uk is handling mobile devices. Spoiler: it’s responsive.
I found this particularly interesting:
When considering the extra requirements users of different devices have we found a lot in common with work already done on accessibility.
Luke and Jason have done some excellent research (and put together some demos) into how the placement of navigation could be optimised for touch screens of all sizes. Turns out that the “standard” convention of having navigation along the top is far from ideal on a touch-enabled device.
Celebrating the work of the tireless men and women who shorten headlines so they’ll fit on your iPhone.
In mobile-centric Africa, Responsive Web Design just makes business sense!Moses Kemibaro | Moses Kemibaro
Therefore, from a business perspective, and my excitement in doing this blog post is that RWD is especially important for mobile-centric markets such as Africa.
Remember when I linked to the Github repository of The Guardian’s front-end team? Well, now—if you’ll pardon the mixing of metaphors—you can start to kick the tyres of the fruits of their labour. This beta site shows where their experiments with responsive design might lead.
Smashing Magazine are publishing a book on mobile and the web. I’m writing the foreword. I should really get on that.
Amen, Lyza, Amen. Instead of treating web development for the multitude of devices out there as an overwhelming nigh-on-impossible task, let’s accept the fact that there are certain things that are beyond our control. And that’s okay.
Let’s build on the commonality core to the web where we can. To do this, I think we need to let go of a few things, to lay down our burdens.
Related: do websites need to look the same in every browser? NO!
Wow. This might be the stupidest behaviour from a browser that I’ve ever come across: mobile Safari behaves differently depending on the top level domain of the site! Madness!
Mind you… it’s kind of poetic justice for having a ridonkulous .mobi domain in the first place.
Oh, dear. Adobe Shadow gets a new name and a hefty price tag. Yesterday it was free. Today it is $119.88 per year. It’s useful but it’s not that useful.
So, lazy web, who’s working on an open-source alternative?
Andy makes a good point here, point out the difference between device testing and design testing:
When I’m designing, it’s incredibly important for me to quickly gain an affinity with how my design feels when I hold it in my hands.
Excellent! Scott has his own URL now. If you haven’t read everything he has written so far, start from the start and read every single post.
A list of open device labs around the world (mostly Europe).
Why mobile Web accessibility matters - best practices to make your mobile site accessible | mobiForge
There’s some great practical advice for building accessible mobile web apps here.
An excellent in-depth article from Anna on the many gaming devices out there that have both an internet connection and a web browser.
Luke collates some useful mobile browsing statistics once again. Most of it is quite US-centric, but this closing point is a whopper:
36 countries more than doubled their Opera Mini user bases in one year.
Tim shows how to make a scalable three-line navicon in CSS.
A nice visualisation of Apple’s transition From desktop to mobile over ten years, one Daring Fireball article at a time.
Oh, and happy birthday, Daring Fireball.
Now Amsterdam has a communal device lab.
Some more thoughts on how our workflow needs to adapt to the current ever-changing device landscape.
A little something to whet your appetite for dConstruct: Scott’s superb talk from this year’s Mobilism conference in Amsterdam.
A really fascinating analysis by Jason into the apparent disparity in web browsing between Android and iOS devices: it turns out that the kind of network connection could be a big factor.
An in-depth look behind the scenes of the responsive relaunch of People Magazine’s mobile site that Josh, Karen, and Ethan were involved in. I love it when people share their process and build stories like this.
I’ve seen Heiko present with this gizmo at Mobilism and it worked a treat. I’m very tempted to get one for future presentations.
Remember when I linked to the story of Twitter’s recent redesign of their mobile site and I said it would be great to see it progressively enhanced up to the desktop version? Well, here’s a case study that does just that.
We’ll tell you what you really want: Mobile context, top tasks, and organization-centric thinking | Sara Wachter-Boettcher, Content Strategist
An excellent follow-up to the recent posts on the myth of mobile context.
You often hear about cutting content to cut clutter. I support this—if you’re cutting the clutter from everywhere, not just a mobile experience.
Maybe the answer isn’t cutting. Maybe it’s learning better skills for designing and structuring complex information to be usable and enjoyable in small spaces.
A great behind-the-scenes look at the redesign (and redevelopment) of Twitter’s mobile subdomain silo. Man, I would love to see this progressively enhanced up to the current widescreen view for “desktop” browsers without the need for separate URLs for any class of device.
But I digress …this is good stuff.
Yes, yes, yes! Karen drives home the difference between mobile and local (and there’s more about the myth of the mobile context).
If you’re making an argument for delivering different content to mobile users, or prioritizing content differently based on their context of use, stop for a minute and ask yourself if you mean local content. And if you do mean local content, then say that. Claiming that your travel example extends to cover the “mobile use case” leaves out millions of tasks and users.
Just to belabor this point: people use mobile devices in every location, in every context. Just because you know what type of device someone is using or where she is doesn’t tell you anything about her intention.
A really great article from Stephen on how we are mistakenly making assumptions about what users want. He means it, man!
Anna reports on her experience testing on a device we don’t often think about: the Nintendo DS …very popular with the young ‘uns.
Kyle’s Matryoshka phones are as cool as they are cute.
A great article on the importance of sketching for mobile-first responsive designs, complete with practical ideas for workshopping.
A really great markup and CSS pattern for “content first, navigation second” from Aaron.
This is kinda funny (because it’s kinda true).
A great article by Karen pointing to the real problem with the mobile strategies of so many companies: they are locked in by their CMS.
If you’re based anywhere near Frome in Somerset, get in touch with Cole—he’s putting together a communal device testing lab.
Another call for design-based (rather than device-based) breakpoints in responsive sites.
A great step-by-step tutorial from Brad on developing a responsive site with a Content First mindset.
This is my short explanation of Remy’s explanation of a BBC news article which is an explanation of an academic paper about battery performance of mobile devices when accessing websites.
Albert-László Barabási and Robin Dunbar are among the authors of this paper — it’s the scale-free network equivalent of the Avengers.
The Jig Is Up: Time to Get Past Facebook and Invent a New Future - Alexis Madrigal - Technology - The Atlantic
An excellent longish-zoom article by Alexis Madrigal with an eerily accurate summation of the current state of the web. Although I think that a lack of any fundamentally new paradigms could be seen as a sign of stabilisation as much as stagnation.
Josh responds to Jakob Nielsen’s audaciously ignorant advice on siloing mobile devices. Josh is right.
Nielsen says his research is based on studies of hundreds of mobile experiences, and I don’t doubt it. But because he’s finding tons of poor mobile websites doesn’t mean we should punt on creating great, full-featured mobile experiences.