From time to time you come across a very courageous and well-written post and just tweeting about it isn’t enough.

Vibhu Norby’s “Why We’re Pivoting from Mobile-first to Web-first ” is one of those. It is brimming with interesting information on how the web is a great opportunity for entrepreneurs today and debunks a lot of mobile myths in the process. In essence it is a grim piece showing how messed up a purely ad-driven business model for any app is.

In detail Vibhu repeats a lot what Pinboard.in’s don’t be a free user mentioned in the past:

Ads are the Internet’s tax on users who want free apps and websites. All free apps and services have ads. I consider virtual goods like ads because everything I’m going to say about ads is also true for virtual goods. Ad-supported companies are akin to the government in the sense that they are both really good at finding ways to charge you without it seemingly coming out of your pocket. Many people’s taxes are taken automatically out of their payroll, so they don’t think of that money as being theirs to begin with. Similarly, we feel like everything that we don’t directly pay money for on the Internet is free, but that is simply not true.

The big dirty truth, however comes immediately after:

Unlike taxes, however, ad-based services target lower-income and lower-education audiences because that’s where they make all of their money. To take the largest example, Google makes $30.00 ARPU (Average Revenue Per User) per year and charges about $1/click on average to advertisers. That’s 30 ads clicked per user per year. I’m certainly not clicking that many Google ads per year and neither are you. I usually know where content stops and ads begin, partly because I’ve had access to the Internet longer than others. I think ads target the same audience that Nigerian scammers do, on average; read this Quora answer on that if you haven’t because it’s interesting.

So you need to grow immensely fast in order to succeed, Vibhu goes on to explain that this is how VC funding past the seed phase works, and there is not much that can be done about it. And as the above shows you need to pander to the lowest common denominator to get the most users. He has a very good point there. Who do you know who is a developer who clicks ads or does not have blockers installed?

This should also reflect in your UX - if you are doing a social product your sign-up and getting started process should be as quick as possible. Sure, we do that, especially when you can piggy-back on existing systems like Twitter, right? Not according to the experiences of Vibhu:

Out of 300,000+ downloads and 250,000 unique website visitors, 200,000 people have signed up. So right away, chop off 60% of your audience whom are just window-shopping. As an aside, I have heard privately from an app maker with a 100m+ downloads that 50% of people don’t even open their app after downloading. And that’s not counting people who can’t find your app in the store or decide not to download it after seeing your app rating (4.5 stars, in our case).

...

We also used to have a social network sign-in screen to automatically create groups for our users. Another 25% don’t want to sign-in to a social network, don’t see the skip button, or get bored by this time. We have since removed those two steps, but it took us a while to get there because we had to re-engineer how onboarding worked.

So that takes our original 550,000 eyeballs + people to 100,000 users. Now that the user is in our app and has an account, we want them to create a group and add their friends or family to the group. 25% of users won’t create a group and another 25% won’t add anybody to the group they created. Now we need them to share something to those people. Then the people they share with need to see the value, understand what is going on, and go through most of the steps above.

At best, we retain 5% of users through the entire onboarding process. Attempts to fix it have raised it only nominally. We are not alone on that count even amongst apps with much better onboarding and many more app versions than our own.

Vibhu goes on to explain that you need to ramp up your numbers ridiculously high to succeed. That can be done with advertising but as explained, it will kill you:

If you paid Google’s $1 CPC for people to enter your funnel, you’re really paying $20 per user and you will never recoup that cost.

There is much more proof in there and Vibhu explains that the turnaround time of app changes is a big issue. You can not be agile in fixing and improving your app (or changing the interface and A/B test) as the closed platforms don’t allow you to do that and your users are not happy to update the apps all the time. The non-atomic update of apps are a killer in this case, something the web excels at:

You have an entirely different onboarding story on the web. You can test easily, cheaply, and fast enough to make a difference on the web. You can fix a critical bug that crashes your app on load 15 minutes after discovery (See Circa). You can show 10 different landing pages and decide in real-time which one is working the best for a particular user. You can also close a viral loop: A user can click an email and immediately be using your app with you. You can’t put parameters on a download link and people don’t download apps from their computer to their phone. Without the barrier of a download + opening the app to try your product, you can prove value to the user immediately upon their first impression, as is with Google. I

Vibhu also praises simple sign-up on the web as browsers do autofill and the interfaces are much easier to use. Typing on a phone is not a good experience. Even worse, according to Vibhu there is not much interest in improving that:

The open eco-system of the web and 20 years of innovation has solved many of the most difficult parts of onboarding. With mobile, that kind of innovation is lagging significantly behind because we create apps at the leisure of two companies, neither of which have a great incentive to help free app makers succeed.

All in all this is a very interesting read, have a peek there. I have a lot to ad about ads in general, but this is long enough for now.

One of the most repeated questions I get when talking about HTML5 is the following:

“How can I protect an HTML5 app from being copied?”

Most of the time the question is not that direct to the point but that’s the gist of it. An example is in the Q&A of my “Keep calm and trust HTML5” talk at Hackernews (40:07 onwards) and this is a more structured approach to answering this question.

In short: there are ways to protect HTML5 apps, but all of them are a lot of effort and will not keep people who want to steal your code off for long. Additionally I’d go as far as saying it is a wasted effort and based on an archaic and ill-advised approach to publishing software. You can’t steal a changing product – you can only try to keep up.

Of course there are apps that need to be protected from viewing. There are also algorithms that need to stay a secret to protect some business models and users from having their data leaked without their consent. Using an open format like HTML5 for these kind of algorithms and apps though is like sending out password reminders in cleartext, storing passwords unencrypted in your database or sending sensitive data over HTTP. Just because you can do immensely wrong doesn’t mean the whole technology stack is not to be trusted.

Protect by packaging – and forfeit a lot of benefits

The simplest way to protect your HTML5 code from being viewed and read (and maybe stolen) is to wrap it in a native wrapper and send it out as a native app (Android, iOS, other OS). By doing that you get the benefits of the closed ecosystems (if your app gets the thumbs up from the app market providers) but you forfeit the benefits of the web: ubiquitous findability, simple, atomic updates and a small code footprint.

Apps code is a constantly moving target

For your normal run-of-the-mill game (think Puzzle Games) or app (productivity app anyone?) spending your time and effort on trying to protect them from being source viewed is time spent on the wrong goals. If you think about it, the code of your application is not what makes it a success:

• Good apps change all the time – Twitter for example became the success it is by observing how people use it, and add functionality accordingly (Follow Fridays and Hashtags were not inventions of Twitter, but of their users
• Your code will be forced to change – this happens mostly when companies get bought and the code of the app needs to start talking to other products by those who bought them. So there is no “one version” to steal.
• There is always a new thing to support – the most successful apps branch out to different devices which means you’ll have to change and re-code when a new one comes out that is vastly different to others
• Apps are fueled by data and users – a great app allows us to do things with it, to add content or to get a simple interface to data we need. Instagram wasn’t bought for its filter algorithms – these are available openly on the web. It was bought for its user base and the data they add to the app (and personal information they willingly expose). A travel app isn’t a success because of the HTML that makes up its interface – its success is making it easy for me to get a lot of data from different sources and seeing them in a simple to use interface.
• A good app optimises for its environment – looking at the generated source in Chrome’s developer tools will be different to what Firefox or IE gets – if you play all of them to their strengths (and there are build scripts that help you with that). So “stealing code” in one of those environments gives the thieves only a snapshot of what the whole app is. Much like saving the HTML of a Yahoo page doesn’t get you the original PHP code.

Open and available fuels innovation

A lot of the fears about HTML5 and the perceived simple way to steal code is a failure to understand that code being in the open is one of the main strengths of HTML5 and the web. The web became what it is now because we could look at code. We can look at our own code while we debug it, we can look at other people’s code and learn from it. We can re-use other people’s code and build on it and improve it and release it for others to do the same.

Client side code, HTML, CSS and JavaScript is a commodity. It is there to make things work and boy do we have to do dirty tricks at times to make it work right here and right now. The environment we publish in changes constantly and trying to release a perfect piece of code that will never have to change and is our secret doesn’t work in it – at all. Secrecy is not what makes the success of a web app – adapting and being able to change quickly is.

Owning and locking up stifles growth

I remember making money with a few JavaScript routines and libraries. I was the one who knew about making menus fly in and out more or less smoothly in Netscape 4 and Internet Explorer 5. Looking at this code now makes me shiver and want to roll up in a fetal position. Seeing that some of this code is still in use as the companies I sold these routines to wanted them “protected” (minified and obfuscated) makes me sad. It is incredibly simple to steal this code with today’s development tools, but nobody bothers. Why? Because there is a cornucopia of free, documented and better solutions available now, on Google Code, on GitHub, on Freshmeat, on people’s blogs and in many other places. Many of the sites using my “commercial and protected code” are not working any longer the way they should. And the companies who bought it never bothered to upgrade their sites and use any of the free and excellent code they can get now. It is a matter of principles, not quality of the final product.

Open code is the best job ad

Web developers like to show off. Instead of showing off in a “I can do this and you can’t” we do it by “look what I managed to make a browser do and here is how I did it”. We learned that sharing means getting incredibly worthy feedback. We learned that people playing with our code means they improve it, find solutions to problems they had and we hadn’t thought of and test our products in environments we neither have access to nor understand. The best way to find and hire great developer talent is have them play with your work – instead of having to educate them when you hire them they already come with passion and knowledge about their job.

Problems worth your solving efforts

So, seriously: all the effort you may think of putting into making your app “protected” (which will most likely result in a glass shield) can be used to solve much bigger issues you should be thinking about:

• What makes your app unique – why should users flock to it, how does it give them what others don’t?
• Test your assumptions – is the UX you chose just because another app does it really the best way to achieve this goal? Get some user testing done, don’t pretend you are your user. The best results come from people breaking your work and using it in ways you haven’t thought of
• Think about your legal protection – the theft you should be worrying about it not your code – it is the idea of your app. The hundreds of Angry Birds clones didn’t rip the code, they copy the idea and the characters. Rovio doesn’t check the code of copied apps – they point out the obvious ripping of characters, music and gameplay and get their legal team to react to that

New playground, new rules

The openness of the web, the opportunity to publish on it and additionally in closed environments with an HTML5 app, the future friendliness of web technologies to the markets and environments of tomorrow is what we should be thinking about. A lot of the demands for “protected code” reminds me of a band trying to write a song that nobody else could play. The notes are not the song. The overall mixture of music, lyrics and delivery is what makes it unique and the band’s product. The same applies to our apps. Let’s not limit ourselves to repeat what has been done over and over again and try to protect it because we think nobody else can do the same thing we did. Let’s embrace that everything is a remix, that ideas are derivatives of other ideas and that our users are the ones that will shape our apps and games with their demands, their data and their time and effort to play and use them. By using an open format thieves could always only get a snapshot of what we do right now. If we spend most of our efforts on trying to put a lock on a door that was meant to revolve we spend our time focusing on the thieves instead of our users.

When the discussion is about HTML5 vs. Native code to deliver apps it is very hard to come to a consensus. There is a massive animosity against the web and myths prevail over realities and opportunities.

I find more and more that this is not a matter of technology and development environment but I feel that it goes deeper than that. We are at a tipping point in web development – technology progresses and our user base progresses – but the people who brought web development to where it is now are still believing and advocating a longevity that might not be there any longer.

A few days ago the social channels around web development – aka our echo chamber – was full of people donning blue beanies on their photos and avatars to celebrate the success and remind people of the need of web standards and Jeffrey Zeldman’s breakthrough book on the topic of designing with them.

Using web standards instead of writing browser specific code and forking for each browser to come meant first and foremost a few things:

• You built in a robust, future proof way and not for the current state of play
• You craved agreement, you built on agreed principles and ideas which meant that the next person can use your code without having to pester you for information on how it works
• You craved clean separation of structure, presentation and behaviour, thus making your code easier to maintain by people who specialised in each of those departments

All of this plays to the concept of the longevity of the web. From the get-go the concept of the web was to be built to last. Cool links don’t change and all that. The web grew because of a few reasons:

• It is incredibly simple to start publishing on the web
• Content created is in an open, simple to convert format – HTML written a decade ago is still readable now
• Creating content and allowing people to add, amend and edit was simple. Wikipedia, IMDB and thousands of forums revolving around the most random topics prove that
• Adding knowledge and content on the web – even in the most ridiculous Geocities rainbow divider ridden format – meant that it gets archived and people can find it years later when all the university papers writen on the same subject are on non-readable floppies and their printouts faded

In essence, we saw the web as a big archive and Archive.org and Google’s caches prove that it can be done. The web does, seemingly, not forget.

Fleeting content, first edition

Of course there were web products that had a due date and got bad after a while. Movie web sites, conference and festival sites, product ads in web form – anything locked in time and costly to keep up was created and vanished from the web. These sites were also the ones that didn’t care much for web standards – their job was to be amazing for a short while and get people excited about a certain product. As web standards advocates they annoyed us as they violated our sacred principles and were beautiful and successful at the same time. I remember websitesthatsuck.com saying that if you want to play as a designer and not care about boundaries and longevity, movie web sites are the best to make quick money and move on. I also remember Andy Clarke giving a talk showing how rich and beautiful for example the (now defunct) Watchmen web site was and how we as web designers should see this as a goal to reach – a beautiful, interactive and media rich web.

This is the chip we have on our shoulders as web developers – the cool and amazing is most likely not possible with standards as we want to make everybody equally happy. We want to build for the long term, we don’t want to add to the already large landfill of outdated, unloved and unmaintained products out there that clog up search results.

A product of our environment

Our environments were desktop computers, then laptops and we are very likely to keep local copies of our work on CDs, DVDs and external hard drives should something happen to our servers or should we be offline. Our main drive was to add to the awesome that is the web and to keep things lasting for a long time. A broken link and a resource that vanished annoyed and hurt us. This is not why we spend hours making things maintainable, right?

The web is a given and consumption is king

Fast forward to the now. The web is not this magical cool thing any longer that everybody wants to be part of. A large series of publishing communities coming and going (Geocities, Google Pages, MySpace, Livejournal) and the rise of the “real time web” with timely updates and image and video uploads instead of writing longer content has made the web a much more ubiquitous and “given” thing for people. You are more likely to catch trolls and spammers with an open comment system than people who give you feedback. Feedback to things you write and publish happens on Facebook, in Google+, on Reddit and on Hackernews. And none of that lasts – you have a few hours window to be awesome and then the next thing will be around to keep people’s attention and incite discussions and GIF uploads to the thread. The attention span is shortened and the MEME-ification of everything and getting things viral is more important than the content or if what you said holds true a few weeks later.

Downloads and non-changing links are not that needed any more, faster and more stable connections allow for streaming on demand instead of getting a song or a movie and going through the pains of tagging and naming them so you find them later on.

We have to face that the web is becoming just another consumption medium. That doesn’t mean the old web of longevity and archiving doesn’t exist any more – it just means that it is the playground of a few whereas the big market just wants to have a quick fix and some fun. If something can’t be found any longer – no big deal, let’s read/watch something else instead.

A need better answered by apps

This is where the mobile environment, with native apps and closed app stores and environments excels. It is a very fleeting space, nothing there cares about longevity, it is all about the immediate success and the next new thing around the corner. The market we target with apps doesn’t care about the long term, it is about instant gratification and the cool and new. When was the last time you played the original Angry Birds? How many of the apps you have on your phone do you really use, and how many are orphaned?

For developers who just started this is incredibly interesting. They want to build something quick, make money and move on. For this, learning what you are doing is boring and in the way. They want an environment to download, install and build things in and ship it to the newest coolest device of the very moment. Doesn’t run on older devices? Who cares?

Changing our tactics and answering the now

Of course this feels terrible to us and – in my case – makes us very angry. Just from a sustainability and environmental point of view seeing mobile devices a year old being blocked out from newest software updates disgusts me and makes me think of “Brave New World”:

“Ending is better than mending. The more stitches, the less riches.”

- Aldous Huxley, Brave New World, Ch. 3

It is Flash part two – back when Flash was hot we got smirked at by Flash developers who rolled out hard to maintain, short lived products and made a lot of money and told us that this is the future and our environment will be history soon. Whilst that did not quite work out the way these shortsighted Flash developers thought (and by all means I don’t describe all Flash developers with that – far from it) we have exactly the same situation now – except that the focus of marketing and people’s buying habits is focused on native apps whereas back then nobody cared what tech your game/site was built in. We don’t play on the same court any longer – we lose people to the one with the locked gate.

Here’s the irony of our fight for web standards: if we really want the web to succeed and HTML5 be an interesting opportunity for developers now we need to partner with the people who used and built in Flash. This is so not about semantics and static pages any longer, it is about apps. It is also not about our way of working and adding to the web in very maintainable ways for a group of experts to work together. Developers now want to do it all from beginning to end. We need people who rolled out apps for the web that followed the same rules OS native apps did. And that was Flash/Flex, and it was good at it. We don’t need more repetition of what made the web great – we need to roll out a massive amount of developer tools that can hold their own against the things iOS and Android comes with. Our web standards world is a labour of love – we build complex and beautiful chippendale furniture that can be thrown about without breaking but the market wants a lot of IKEA Billy shelves that can be put up quickly and break when you dismantle them. We don’t have the answer how to build those.

The web needs to be the thing that allows you to roll out code quicker, in a more convenient way and across devices than native environments do. And we don’t get there by wearing blue caps and talking about benefits that applied years ago. We need to be as flexible as the technologies we stand for.