You might have seen the big splash Sencha landed today with their Fastbook HTML5 demo showing that using HTML5, CSS and JavaScript you can make a damn responsive version of Facebook. You can see the demo on Vimeo:

All the details are in their post “The Making of Fastbook – an HTML5 love story“. I saw this and went “holy crap, that is awesome”. As an Android user I’ve seen the native app crash several times when trying to scroll through a lot of data (also on Twitter, so this might be a Samsung implementation problem) and the HTML5 demo is incredibly smooth and compelling.

And then of course, the developer in me thought that something must be amiss about this – it is too smooth, it is too “sales demo”. And of course I got backup – the comments on the blog bring up that this is not running in a web view where a lot of the performance issues would come up and Mozilla internal mails already complained about the fact that the demo does not support any other browsers than webkit – no Firefox, no Opera and no Windows at all. To the internets! Someone is wrong about calling something HTML5 without supporting everything.

And then I stopped. And reflected. And thought for a second what we are doing here. There seems to be this massive Pavlovian response in engineers to want to find the flaws in something rather than looking at the benefits.

Cartoon of awesome by The Rut

Yes, this only works on Webkit, which is bad as HTML5 is more than Webkit. It was also wrong of Sencha to claim that this is showing love to HTML5 without embracing the nature of HTML5 as browser-agnostic platform. But this is marketing war. This is making a demo and showing that things can work when you put effort into it. This is a direct response to the in 99% of the cases misquoted Zuckerberg statement that HTML5 wasn’t the right choice for Facebook at the time. But still I vented my disappointment:

Disappointed that @Sencha’s HTML5 love story means webkit love story. No, Firefox Mobile, no Firefox OS, no Opera and no Windows. :(((

Of course the Twitter stream from that consisted of people telling Sencha off and many people who want to see HTML5 fail (although it wouldn’t make any difference to their lives) harping on about the awful state of HTML5 and the bane of browser inconsistencies – another Pavlovian response every time you say HTML5.

Here comes the kicker, though. Quite a few of Sencha’s folks agreed and explained that this was a quick tech demo and thus only worked in Webkit. Jared Nicholls, their Senior Software architect kept it succinct:

@codepo8 agreed and fixable. Only 24 hours in a day.

So instead of waving my finger and complaining about the thing that could have been but wasn’t thought of I am trying to get conversations going to fix and enhance. Let’s see where this goes.

Sometimes the right thing to do is not to listen to the angry man inside your head and see how something can be done better. Sencha’s demo is a damn good marketing move and well done indeed. So instead of shooting it down it makes sense to work together.

Summary: Performance articles are very good to make a point, but they are very much fixed in time and the shelf-life of their findings can be very short. This can lead to great ideas and technologies being prematurely discarded instead of their implementations being improved or fixed. Proceed with caution.

Every few months I see articles about how someone likes some of the great new features we have in HTML5 and how simple they are to use. Without fail, there will be a follow-up post by performance specialists warning everybody about using these technologies as they are slow.

Performance is sexy, and performance is damn important. Our end users should not suffer from our mistakes. There is no doubt about that. There is also no doubt though, that a simple API and one that builds on top of existing development practices will be used more than one that is more obscure but better performing.

This is the dilemma we find ourselves in. LocalStorage is damn easy, but can perform terribly, using WebSQL or IndexDB is much harder but performs better but is not supported consistently across browsers. Data attributes on HTML elements are an incredibly clever way to add extra information to HTML and keep them easy to maintain, but suffers from reading and writing to the DOM which is always slow.

Instead of finding a middle ground, however, we write articles, give talks or post about our favourite point of view of the subject at hand. Performance articles boast with a lot of numbers, graphs and interactive tests that allow people to run a bit of script across several browsers and paint a picture of doom and gloom.

Designers who just want to use technologies on the other hand then write articles that show that not everything is terrible as they never reach the brute force amount of tests these test cases use to come up with a sensible sample to make a statement one way or another.

I am bored of this, and I think we are wasting our time. What needs to happen is that performance testing and implementation should lead to what we really need: improved browsers with fixes for issues that cause delay. A lot of performance articles would be better off as comments in a bugtracking system, because there they get read by the people who can fix the issues. We need much more feedback from implementers why they don’t like to use a more performance efficient technology and what could be done to make them like it.

Right now our polarised writing causes the worst outcome: people are afraid to use technologies and browser vendors don’t see a point in fixing them because of that.

Libraries love implementers

Libraries, on the other hand, recognise the issues and fix them internally. Almost every jQuery script you see is incredibly tightly knit with the DOM and reads and writes on iterations, fails to do caching or concatenation before causing reflows and would be an absolute nightmare if implemented in plain JavaScript. Library makers learned this and swallowed that pill – implementers like using the DOM, they just don’t like the DOM API. Storing something in an attribute makes it easy to change and means that people will not mess with your code. That’s why libraries use caching mechanisms and delayed writing and all in all a DOM facade to allow developers to use and abuse the DOM without the performance punishment (in many cases, not all of course).

The same needs to happen in browsers and standards. That something is slow is not the news. We live in a world of ever changing browsers and technologies. As Jake Archibald put it:

@codepo8 agreed. Also, most “x is faster than y” advice has a very short shelf life

A lot of the performance issues of technologies is based in how they were defined or the lack of definition and browsers implementing them differently. These are the hardest to fix. But we can only fix them when and if people use them. Without usage no browser vendor will be enticed to spend time and effort fixing the issues – after all as nobody complains, it probably is OK.

Read with caution

So when reading about the performance of anything web related, I think it is important to consider a few things. I also think that well-written posts, books and articles should mention those instead of showing a graph and declaring “xyz considered harmful”:

• What usage of the technology causes issues – if storing lots of large videos slows down localStorage that doesn’t mean using it for a few small strings makes it a “do not use technology”
• What are the effects of the performance issue – if what you do delays a page load for 10 seconds, that is an issue, if the problem only persists in certain browsers and with a certain kind of data, less so
• Are there workarounds – what can implementers do to still use the technology, reap its rewards but not cause the issues?
• What are the catalysts – a lot of times a performance issue does not really show until you use it excessively. DOM access for example when cached is not a problem, when you keep reading and writing the same values, it is though

Of course, performance experts will tell you that this is a given. People should take the numbers with a grain of salt and test them against their own implementations. Well, that is not how publishing works and this is certainly not how quoting in a 140 character medium works.

A current example

Let’s take a quick example about this:

Stoyan Stefanov’s “Efficient HTML5 data- attributes” talks about the performance of HTML5 data attributes and that they are slow. We have the graphs as proof, we have an interactive test to run in our browsers. And of course Twitter was full of “data attributes are slow and suck”. The interesting part of the article to me, however, was in the last two paragraphs:

Using data attributes is convenient, but if you’re doing a lot of reading and writing, your application’s performance will suffer. In such cases it’s better to create a small utility in JavaScript which will store and associate data about particular DOM nodes.

In this article, you saw a very simple Data utility. You can always make it better. For example, for convenience you can still produce markup with data attributes and the first time you use Data.get() or Data.set(), you can carry over the values from the DOM to the Data object and then use the Data object from then on.

This, to me, is the missed opportunity here. Right now data attributes perform terribly as they are connected to the DOM node, meaning you do an attribute read and write to the DOM every time you read a dataset property. This doesn’t make much sense – why would you need an extra API then?

The mythical Data utility Stoyan writes about is what this article should have started with. Of course, I can see his plan to make people start playing with the idea and thus getting deeper into the subject matter. This would be lovely, but it means that readers need to either do that or check the comments or follow-ups for that solution. Articles have a much shorter shelf-life these days as they had in the past – it makes more sense to show a solution that fixes the issues rather than a blueprint for one. This is not a workshop.

The magic moment here is not saying that the following will be slow to read and write if you use dataset or get attribute:

<div id="foo" data-x="200" data-y="300"></div>

It is also not that you can replace it with a much better performing script like this:

Data.set(div, {x: 200, y: 300});

They are not the same – by a long shot. The former is much easier to maintain and keeps all the data in the same spot. The latter is spreading the info into two documents and two languages – very much against the whole idea of what data attributes are there for.

An article with this title should have shown a solution that turns the HTML solution into a performing solution – by, for example, looping the document once and storing the information in a data object for lookup.

I am not saying that the article is bad – I think the last two paragraphs made it much more objective. What I am saying though is that it is primed to be quoted wrongly and lead to truisms that stand in the way of the underlying issue being fixed.

Performance improvements happen in several areas. The ones with the biggest impact is making browsers faster by fixing issues under the hood and by making it easy for people to develop. We promised developers a lot with the HTML5 standards – this stuff should perform without implementers having to build their own workarounds. This is the main lesson we learned from the success of jQuery.

So, if you read “xyz considered harmful”, read carefully, consider the implementation parameters and don’t discard a very useful tool just because you see some numbers that right now look grim. Technology changes faster than we think and we need to measure with use cases, not lab tests.

We might be late to the party but yesterday we splashed out a wild $10 to download and watch Indie Game – The Movie directly from the makers.

The very nicely priced movie came in numerous high-quality DRM free download formats including subtitles, captions and creator’s audio track and is a great example how film distribution should be done in almost 2013 rather than telling me I am not in the correct country.

You can watch the trailer here:

Like almost anything awesome, the movie by James Swirsky and Lisanne Pajot originated in Canada and follows a few indie game developers in interviews: Edmund McMillen and Tommy Refenes building and shipping Super Meat Boy, Phil Fish trying to finish and get the rights to release Fez and Jonathan Blow creating Braid.

The imagery and movie making technique is amazing and beautifully done and the movie is a very interesting documentary about the issues indie game developers have to deal with: publishing issues, legal obligations, public feedback and above all personal problems and social anxieties. Whilst a portrait of highly gifted and intelligent people you will be hard pushed to find anybody “normal” in the conventional social sense here.

I was especially taken by the interviews showing the makers dealing with online feedback, demands for the game to come out, hate mail, odd reviews but also all of them reacting badly to positive feedback. As someone who publishes a lot online and spreads out whatever I do for free I could very much relate to these parts.

All in all this is a must watch for anyone who wants to publish in our market – not only games, but anything really. You won’t get car chases and shoot-outs but it is still a very much worth your while movie.

I just spend some time to read myself into the “Mobile Book” by Smashing Magazine and here are my first impressions.

The book, overall, managed to collect an impressive amount of writers known to be “in the know” about all things mobile and each delivered a chapter based on their subject matter. In detail, we have the following:

• What’s Going On In Mobile? by Peter-Paul Koch
• The Future Of Mobile by Stephanie Rieger
• Responsive Design Strategy by Trent Walton
• Responsive Design Patterns by Brad Frost
• Optimizing For Mobile by Dave Olson
• Hands-On Design For Mobile by Dennis Kardys
• Designing For Touch by Josh Clark

The e-book edition also comes with extra chapters:

• Mobile UX Design Patterns by Greg Nudelman and Rian van der Merwe
• Developing And Designing For iOS by Nathan Barry
• Developing And Debugging HTML5 Apps by Remy Sharp
• Understanding The Android Platform by Sebastiaan de With
• Designing For The Windows Phone by Arturo Toledo

The book feels overall very rounded and does a great job in covering all the aspects of mobile development. All of the look and feel things, intended audience and other info is covered in a lovely Mobile book factsheet for the press in case you are interested in that. I read the chapters I wanted on my Macbook Air and on my Android device and in both cases they were beautifully done and easy to take in.

I especially like the fact that the book covers mobile in a holistic sense, giving us a great overview of the market with PPK’s chapter and diving into the different skills needed in detail chapters. I also like that it is platform agnostic, meaning that what you learn in it is applicable across the board. Far too many publications are more or less veiled “here is how to do mobile for iOS” instructions which will be outdated in half a year tops. The information here is written cleverly and whilst it is a snapshot of the current situation it is written in a way that explains what can be used later and what might just be an issue for now and not worth us wrecking our brains over.

I haven’t read the extra chapter, which is a shame as – biased as I am towards HTML5 - I’d have loved to see Remy’s chapter as part of the main book. I am totally fine getting Android, iOS and Windows specific data as a nice to have, but a real HTML5 chapter would have been good.

That said, Dave Olson’s chapter was quite a revelation to me – its title doesn’t give it enough credit. There is information in there that can make you hit the ground running optimising your web product and it leaves you with links and articles to dive into that can keep you busy for months. It crammed a bit much in and could be a book in itself, but it is well worth your time.

In general I think this book is a great addition for a company or agency library. As a specialist, it can leave you with a few chapters that are very much beyond your reach and can leave you with dangerous “knowledge” but a team reading the applicable chapters and then pooling their knowledge and learnings can use this book to go into the mobile future kicking and screaming. And kicking arse.

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.