The Web is an evolving platform, and it has been consuming the abilities of mobile, which is letting it get to the next stage.
When you look at various species, you see generalists and specialists. Human’s are the ultimate generalists, the swiss army knives of animals who don’t have the sharpest teeth, yet can adapt incredibly well. Our brains give us the capacity to learn new skills and take us in very diverse directions. On the other end of the spectrum we have something like a koala beer, a creature that has specialized to the point that if a particular food isn’t available it is kaputt. There are trade offs on the spectrum of generalist and specialist, and one isn’t necessarily better than the other. If you specialize to have a strong niche that others aren’t fighting you for you can do very well, but you are beholden to that niche.
Flexible platforms are able to see the changing landscape around them and adapt to it, picking up the best ideas from other platforms and finding a way for the capabilities to fit in.
The Web has evolved many times before, and it has had various ways to test ideas. Let’s take a look at some of them.
The Document Web
The Web was born as a document platform. I was at the University of Minnesota, in the computer science department that brought us gopher (Minnesota Gopher’s and all). Oh how proud we were to deploy documentation through our gopher servers. The library met the Internet! And then came along the Web and blew it all out of the water.
The ability to publish documents with a simple format that could arbitrarily link to each other from anywhere within was of course simple and amazing. This ability unleashed the crowdsourcing of the worlds information at unprecedented levels, and the humble roots grew the abilities of these documents. New elements were added to allow for richer semantics. CSS brought much richer styling. And then Pandora’s box was opened when we added the scriptability to the client via JavaScript. Until then we were only creating dynamic content by sending it down from the server via CGI and friends. You obviously wouldn’t want to go on a server round trip whenever you moused over an element.
Other extension points were created in user agents. Thanks to plugins and ActiveX we got new parasitical evolutions of sorts such as Shockwave and Flash. They are often cast as The Bad Guy, but we learned a lot from them and baked in many of the good ideas into the Web itself. And, it was ActiveX that helped us push over the tipping point to get to the next stage….
Ajax: The Desktop Application Platform
XMLHttpRequest first came to us via ActiveX. Finally we had a way to do round trips that wasn’t as limited as frames or CGI pushing data. XHR was the hero, but it was only one of the cast of characters. We often pushed the boundaries by wrapping Flash (remember sIFR?) and the early period was a fight to deliver applications over the Web.
Why were we fighting so hard to contort this document platform when we had native applications that had full access to the power of your desktop computer? The frictionless distribution of the URL.
There is quite a difference between sending your parents to the store to get a CD with an application on it, vs. emailing them a link. Even once we got to the point where you could download a zip file, it took a long time to get the application and you were trusting your security by installing it.
We were also finding out way on what a web application should feel like. Outlook Web Access very much looked like an uncanny valley of “this is like a desktop application but it sits within the world of a browser so it isn’t quite right”. Gmail on the other hand took a very different approach, one that felt like the Web.
Quickly, Ajax became less about XHR, and more a phrase that meant “making sure you are delivering a quality user experience”. Then it faded away and once again became part of “the Web”.
The Mobile Web
Mobile finally really happened, en force. I had been hearing about it for years. At every JavaOne Sun would get up on stage and pronounce THIS as the year for mobile and J2ME. And then another year would pass. It was only with the iPhone that we saw things really kick into gear. One of the reasons was that the iPhone delivered the “full Web” to your pocket wherever you were. This is quite a feat if you think about it. Browsers were tuned for running applications and a desktop experience, and this underpowered device could run the content? Sure, pinching and zooming wasn’t an ideal experience, but you could access it!
Console Wars is a fantastic book that discusses the battles of Sega and Nintendo. One of the mistakes that Nintendo made that allowed Sega to get in the game was the lack of backwards capability in a new Nintendo device. It is often important to remember to bridge one generation to the next.
You want to be able to play your back catalog, and the iPhone played the Web.
But this is just a bridge. You also want to use all of the capabilities and power of the new platform, which allows developers to create this new content. The Web didn’t offer the right level of capabilities fast enough, and thus we got into the era of the native app ecosystem. This is where we got a lot of experimentation, and each generation added new sensors and best practices.
Innovation is still happening of course, but at this point we have learned many of the core tenants that deliver a great mobile experience. This includes system level integration so the web applications feel part of the native platform. For example, you need to be able to have access to a progressive web app right from your home screen, and it needs to be a better experience than a bookmark that opens a browser to a particular tab.
Reengagement is also key, which is why push notifications support is critical. We are seeing great results when web applications implement this feature in a way that users have control.
For example, Beyond the Rack has shared:
- 26% increase in average spend per visit by members arriving via a push notification
- +50% repeat visits within 3 months
- 72% increase in time spent for users visiting via a push notification
It is also worth noting that getting web push notifications also helps on the desktop!
Service Workers is to Progressive Web Apps as XMLHttpRequest
All of this work depends on Service Workers. The Web was built assuming that you were jacked in, and it was vital to have a capability that would allow you to take control of events outside of a running Web page. The control that you get, mapped to new capabilities such as streams, enables you to deliver fantastic experiences.
I have often have orchestration services that would work to optimize and cache data based on the needs of the application. For example, when you think of a product details view, the caching SLA around the price is very different to reviews. It is fine to not show a review that JUST came in, but you can’t show an old price.
With Service Workers, you get to do this work on the client, and you can design your applications in very custom ways to eek out the best of the best. With a nice model driven design, you can send over cached versions and then postMessage updates as they come in (if appropriate).
There is still more to do, patterns to flush out, and “Google Mail|Suggest|Maps of PWA”s to ship.
The Web continues to evolve. With the rise of the app ecosystem many companies needed to ramp up and deliver there, but for many companies it is time to rebalance and deliver progressive web apps. The mobile universe is expanding in all directions, and we need to think about improving all aspects of our services.
There was a time in which we talked about Color TV before color was the norm and was subsumed into TV. The same will happen with mobile Web becoming Web.
As always, I am excited to see all of the vectors of exploration, and to see the Web continue to adapt and evolve.
Leave a Reply