Great points about apps and the web in this article.
Apps compete with the web for dominance over where people get their content. Apps as games and tools are perfect, but apps for content are not. Content is best on the web, because the web is built for sharing content. The web is open! The web is consolidated and instant and accessible (meaning that any device/browser/screen size/location/etc can already access the web and you can update it anytime and all users see the update instantaneously). The web is also accessible via the defining url. Meaning that it’s a required standard that all assets and bits of content have an address. You can take this address and share it and return to it easily, apps – not so much. You want to share an experience or idea from an app with a friend (sure, some have a process built in), you first check to see if their device has this app available, they want to go through the steps of finding the app and then installing it (likely having to pay money) and then you send them a link have to explain how to get to where the magic happened.
Newfangled, a web agency I respect for being very smart has a great article about this. It was then moved into the basis for a chapter in their ‘The Strategic Web Designer’ Book. I highly recommend them both!
Here’s a great “HTML5 Love Story” about the team at Sencha, who is passionate about using proper technologies for the one open web, who knew better than to trust that the failure of Facebook to create a reliable HTML5 app for users was because HTML5 wasn’t ready (as Facebook claimed). They built this demo to prove that HTML5 can do all that the now gone native FB app does and faster. The trick is you have to know what you are doing. Something it seems, FB doesn’t. Ready the full story and watch the comparison video: The Making of Fastbook: An HTML5 Love Story | Blog | Sencha. Or go try it yourself. Visit http://fb.html5isready.com on your favorite mobile browser.
When we started what became Sencha, we made a bet on the web: a bet that modern application development didn’t need anything except the browser, a great set of frameworks and a great set of tools. With those three weapons in hand, we knew developers could build applications that would delight users. The advent of HTML5 upped the game and it gave developers even more tools to let them treat the browser as an application development platform and not a page rendering engine. Developers sprang at the opportunity and unleashed a torrent of apps — on both desktop and mobile — that leveraged the new HTML5 capabilities to build amazing applications using web standards.
So, when Mark Zuckerberg said HTML5 wasn’t ready, we took a little offense to the comment.
We thought to ourselves: HTML5 can’t really be the reason that Facebook’s mobile application was slow. We knew what the browser on modern smart phones was capable of and what kind of rich capabilities HTML5 offered. We saw the latest generation of mobile devices — running at least iOS 5 or Android 4.1 — push ever increasing performance and HTML5 implementation scores. But perhaps most importantly, we’d seen what our customers were building and the amazing things they were creating using HTML5.
I totally agree with this sentiment and believe that native apps are the new flash to the web. They are fun and seem to be the way, but give it a few years and these native apps will quickly give way to web based apps that are browser based and offer speed and flexibility and consistence to the web experience. Sure, flash can do things that html still can’t. But I’m pretty sure no one would want to build their whole site in flash today. They would put the parts that need to be or the parts that belong in flash in flash and let the rest be standards compliant open web. Facebook has essentially built a flash based website for phones to access their website content. They will have to maintain and update this separate from their “real” version.
Our smart phones are helping us converge our devices, as in we no longer need a phone a camera a gps a notepad a … But it is not helping us converge our internet or content. We currently need to use a website in one way at our desk and another way on the go. Websites and the internet should have the same capabilities and the same uses no matter where we decide to use it. Sencha is showing us that, built correctly, HTML5 truly is ready to handle many things that belong in the browser rather than in a native app. We should never need to download a native app to access website data that we normally would just login at our desk. That’s inefficient, divergent and complicated. It’s against the openness and standards everyone preached and pined for and indeed “won” when flash-haters succeeded in ousting flash from mobile browsers. I actually respect Adobe for finally pulling the plug there because they too, believe in the web (and at the time, I was a full-time flash developer). I believe in the web too and that’s why I call it the one open web.
I agree with this idea from Ryan that the web has big advantages. I am constantly hearing stats and projections that Mobile is taking over. And sure, I agree that I use my phone to browse more sites, but when it comes down to it I’m just casually browsing – not working. I love the post he’s links in the first line: Vibhu Norby has a detailed post on why his startup is pivoting from mobile first to web first.
Vibhu details that he’s done the mobile startup thing and has learned from the complications. He explains that most of these have been solved in the desktop browser already and a lot of it relates to usability.
Another big point is that mobile apps must be installed (actually they must be found, installed, opened and setup), whereas a web app can be as simple as a link- click, and then the user is already using it. Adoption is much easier on the web.
And even another point is updates and testing and whatnot. YOu can do various tests and even update the whole app relatively fast on the web. There is the one version to support – the live one. While with apps, you can’t do much in the arena of testing and updating is sluggish plus it relies on the user to update (some don’t know how to update and even less care).
I think a web app that is mobile friendly wins. You can give mobile users access, but they aren’t stuck on mobile. They can use it anywhere. While so many are talking about responsive design and produce sites that are device agnostic mobile apps are very device centric.
I’m a fan/advocate of future friendly at least, and strive for future proof (although I understand that’s near impossible). I also hold that there is ONEweb and mobile myths.
This post on creativejs picks apart how this doodlue was made. Nice they they are able to support HTML5 audio even if it is only supported on chrome and the rest fall back to – you guessed it – flash.
Embedded Link
Google Moog synth tear-down
Yesterday we featured Google's web-based analogue synth Moog tribute when we found it on the Japanese site several hours before it hit t
Great article from Jeremy Keith about the nonsense it is to use breakpoints determined by devices. The whole point of responsive web design is to make your designs flexible. Let's not only target certain widths, let's just finish the thought and make it a great experience no matter what width it is. Let the content determine the breakpoints.
The all-new API for the all-new Basecamp – (37signals)
37signals logo. This is Signal vs. Noise, a weblog by 37signals about design, business, experience, simplicity, the web, culture, and more. Established 1999 in Chicago. Follow us on Twitter for more i…
Worrisome points here. The release cycle IE is now projecting is decent, new browsers more often. But what’s far more important than shipping frequency, is the browser half-life; soon there will be way too many configurations of IE for anyone in the web production industry to stay sane. IE10 comes out soon and IE6, IE7 and especially IE8 aren’t going anywhere. So each new IE browser, even if it were clean of bugs, still does nothing to make IE better. No one is using them. Not to mention the rendering mode in each IE browser is different than the last – bringing in bugs almost as random or weird than the ones it reportedly fixes.
I like that: “From now on, if it’s not responsive, it’s not web design.”, thanks Andy. I also agree that the term responsive web design is a bit flawed. But it’s a bit late to be thinking up a new term. I’d like responsive to refer to how elements respond to user interaction, but what we now call responsive web design could better be called… I’m not even sure: dynamic layout, stepped fluid layout, screen friendly, indifferent to screen size… none of those are that good either.
