What I Learned in 2015

It is that time of year when I reflect on what has happened in the mobile (and web) space the last year. I learned a lot. Some trends and things I want to highlight are:

Connectivity

First of all, the community of web developers, companies and products caring about mobile and web has become really big! This is great news! Going to conferences, reading blog posts and talking to people, it is not uncommon to hear about the low bandwidth mobile devices may have. Even mentioning edge/2G as common use cases. To me this is proof that the web development community finally has embraced the web as a mobile medium with all the good and bad things that comes with it. Finally we’ve changed our mindset.

Mobile Finally First

The most inspiring news last year was that the Norwegian classifieds site finn.no is discontinuing their old site for desktops and replacing it with their mobile site. Turned out users was more happy with mobile site, so why not offer everyone the same great experience…. Tables have turned from a downscaled version for mobiles, to an upscaled version for desktops.
Impossible not to mention responsive web design as a accelerator in the revolution of mobilizing the web. I like to think about it like this: Rwd was the technique we needed to move the mobile experience to desktops, because it turned out not even desktop users wanted the desktop experience they were served. The web is mobile by default. On the flip side, we’re starting to see oversized sites with HUGE text and very low content density on desktops. This is sort of the “dark side of RWD”. By that I mean, just poring RWD at your content doesn’t mean you get a great site in any browsing capable thing out there. Applying some adaptiveness still makes a lot of sense. Of course with RWD as the base.

RWD != Mobile

To elaborate on the above, the term “RWD” has unfortunately been diluted and/or overloaded to the point where people say “ RWD”, but they really mean “Mobile”. Try listen to leading podcasts on the topic, and you’ll understand what I mean. Or read a book with “Responsive” in the title… (you only need one book with responsive int he title: the original). Further, there is this dream of “one code base” related to RWD. In recent projects I’ve seen, it’s like this dream of “one code base” is an implicit requirement just because it’s decided to use RWD. This dos not make any sense. RWD is just a way to organize you markup and CSS. A characteristic. We still need to focus on creating the best possible experience for any kind of device. If that mean a forked code base, so be it!

AMP

Speaking of forked code bases…. AMP. The new m-dot. In the beginning I was pretty reluctant to AMP. I thought it didn’t play well with the principles of the open web. First thing I though of was the walled gardens and hacks we used in the early days of mobile. But then, the more I thought of it, it actually makes sense. The message form the AMP team is “if you do it like this, and stick with that, it will actually give a better result. Trust us”. This we’ve also seen before: Defining a subset of something, creating some tools and rules to make the web work better in certain contexts. WML was the early beginning, XHTMLMP is maybe more familiar. On the scripting side, we even had WML script. This was the start back in 2000, of course, but as the mobile web matured, we ended up with something very similar to AMP. At least in principle. So Googles approach has actually been tried and tested before. Actually with great success! The web made for mobile back in the days, was actually pretty fast! So now, I am actually all in on AMP! AMP came for the same reasons as the m-dot sites. It is a product of its time. Question is, how does RWD fit in here…;)

Content Negotiation

Google is also promoting content negotiation particularly by the Client Hints initiative which was implemented in Chrome 46. Client Hints is basically about adding a few HTTP header containing size of the screen and such. Again, I see some history repeating here. With the mobile web we always did content selection, content negotiation, image optimization and so on.  Back then, the mobile operator (carrier) had gateways appending all sorts of contextual information. Gateways, proxies or even the device actually provided most of the information web developers are asking for today. Through UAProf for example. Client Hints re-introduces the same principle: Use what you know about the “thing” requesting the asset, adapt and optimize, then return to the  “thing”. Combined with RWD, this is known as RESS or even “Adaptive” or “Dynamic Serving” like Google calls it. I think, and hope, we will see more content negotiation this year. It works.

Death of m-dot

But rise of AMP? Hopefully not. We really don’t need different hostnames and redirects for the same content. CNN should be available at cnn.com regardless of device or browser. Still, the user experience can (or should) be different. Content negotiation, device detection, dynamic serving, adaptive, server side logic still make a lot of sense and should not be ignored.

Summary

The pattern of 2015 I think was that Mobile First, works. Design content for mobile and your users will love it. RWD is a killer characteristic, but we need to fix performance issues caused by connectivity and hardware. I think capabilities of the hardware will become more important in the future (features of the software wont tell you anything about the capabilities of the hardware). Content negotiation will hopefully be a trend to address this.

4 Responses to What I Learned in 2015

    • Why does it stick out? What I mean by that is that knowing the device, and it’s capabilities, is an efficient way to implement content negotiation. Feature detection will get you to a certain point, but the problem is that detecting a feature does not tell you anything about the hardware. I.e. the detected feature may be useless due to hardware capabilities. This is a common problem with cheap Android devices.

    • Detecting the device’s capabilities is valuable, of course, but “device detection” sounds more like detecting the device itself, as in “iPhone”, “Samsung”, etc., which should not be performed, I think. As for the device’s hardware capabilities, a web app could continuously run micro-benchmarks to get a picture of how fast the device runs JavaScript, but I’m not aware of any libraries for that.