Lately there has been quite some debate about “free services” and what they mean to their users. A lot of it started with the excellent article “Don’t be a free user” by Maciej Ceglowski which described a few unpleasant truths:

• When you use a free service, you are the product that gets sold
• This means in the worst case that your identity information, likes and dislikes and connections with your friends are sold to third parties for data mining
• If the service doesn’t require you to enter this information the content you add to the service becomes the product sold to third parties
• Using a free service can also mean that you have no right to the content you add to it
• You shouldn’t be surprised that you lose everything when the service goes belly-up

The article however also points out that the solution to a lot of these issues – paying for the service – is not that common. We’ve been conditioned to expect everything on the web to be free. That is why the article was so important.

Lately another issue came up with free services – this time related to the mobile market: free apps are a big culprit of battery drain on mobile devices because of the constant loading of ads and reporting of data back to the ad providers and the app.

Strange reactions

What bugs me about all this is not that free services have issues. What bugs me is how a lot of people on the web react to the issue. There is a sense of gloating and arrogant repetition of the points in the Pinboard article as “duh, you should know and expect this” and there is a general consensus of “you can’t expect quality when things are free” and that “free users are doing it wrong”. The latter is especially ironic when a comment like that comes from a Yahoo, Gmail or Hotmail email account.

I got a lot of feedback when I complained about the fact that Twitter sold old tweets in bulk to data mining companies. Whilst my “not cool, Twitter” tweet was easily one of the most re-tweeted in the last months, the feedback was very polarised. A lot of people were outraged (in some cases overly so), and an incredible amount called me out as being naive for thinking that would not happen. The amount of people finding the main problem with this move was very few. The issue was not that data is sold, the issue was that third parties get access to my data while I am denied it.

Basic denial of service

My beef with this was not that Twitter sells the data – I don’t care, as Tweets are openly available on the web and I willingly publish them. My beef is that companies who pay for my data get better access to my data than I get. The Twitter API changed drastically lately and it is not easily possible for me to get a whole archive of my tweets. The API defines that I can get “up to 3,200 of a user’s most recent statuses” and that’s it. Even for searching Twitter and getting access to more than your last 20 photos you need other third party services that pull your information and store them on yet another server (which might be free and cause the same issue).

I use Twitter a lot and a lot of people thank me for my contributions. In order to retain information I have Twitter linked up with Pinboard – which I pay for – to have an archive of my links. I find it sad that I need to hack a service with another service to make me access my data in the future.

Now, Twitter makes money with my tweets, but doesn’t give me an option to get all my data that went through it – and that seems to be totally fine for a lot of people out there. Notice that I am not asking for any user’s tweets – just mine. The argument of the “that is fine” people is that tweets are openly available on the web and thus fair game for mining anyways.

Misdirected blame

That data is freely available on the web for mining should not be a carte blanche for companies to not give you access to your archive. Why offer an API at all when it is “so easy” to mine that information? Naming the best quality of the web – simple publication – as a reason to deliver sub-par user access seems to me lazy. Even the ill-fated Oink now offers you to get an archive of all the info you put in before it will go to the app farm in the sky where many a product bought by a larger corporation goes.

The same weird act of blaming the wrong thing happens with free mobile apps draining your battery. A lot of the comments and feedback blame the users for being idiots to use free apps and not deserving any better.

Let’s think about this: the poster child of a successful app and the success every app developer thrives to repeat is Angry Birds. Now, try to not “be an idiot” and pay for Angry Birds in order to preserve your battery life. Not possible.

The flagship app and the Cinderella story of startup success is a free app.

And as much as playing it is fun, the experience with ads is absolutely awful. I prefer very much playing it offline – as there are no banners covering part of the level and the performance seems to be much better. Even the HTML5 version is plastered with ads – funnily enough for Angry Birds itself. And this is where the real issue comes into play.

A need for new advertising models and metrics

The concept of a mobile app that requires me to be online is wrong. Our mobile connections are too flaky for that. The great thing about apps is that they do one thing and have offline and local storage capabilities and don’t expect me to be online. That means I can use them on flights and in tunnels.

So what is broken here is really the ad display model. You normally put ads in your products by hosting a third party script and pull the information from their servers. This worked on the web and to ensure that gaming the system is a tad harder the ad providers want to host the code and the banners and do their own click tracking (to avoid you for example putting the banner in an iframe, move it off-screen and reload it automatically). In a mobile world, however, this needs re-thinking. I’d really like to see the numbers of banner clicks in mobile games – I can safely say the only time I clicked any was when I actually wanted to explode a bird or slice a piece of fruit which means I got frustrated and much less keen on purchasing things.

One simple idea would be to allow app developers to download banners in bulk and rotate them locally rather than pulling them one by one. That way only clicking them would mean data transfers to the web. The display could be handled by local tracking. I found a few web banner services that do local caching like that. This means there has to be more trust between the app developer and the ad providers, but it would mean that you’d also have offline ads.

The second big problem is metrics. Right now all we measure as the success of apps is the number of users and downloads and when it comes to banners of course the number of clicks. This means of course that free apps will always be deemed much more successful than the ones that ask for payment upfront. So seeing the issues with free apps maybe it is time to reconsider how we measure the success of apps and get less excited about playing the number game.

Discussion on Google+

Yesterday we went to New Work City for the MDN hack day and I kicked off the day with a talk about HTML5, the opportunities it brings for developers and what people can play with during the day.

The slides are available and I recorded a screencast of me presenting them. The screencast is available on YouTube or in various HTML5 compatible formats at vid.ly (embedded below):

If you want an audio only version, you can find that one on archive.org or here:

Here are the things I am covering in the talk:

• World connection density map
• Mozilla Hackasaurus
• 18 days in Egypt documentary
• Mozilla popcorn
• HTML5 beanie maker
• Undoing the double sun in Star Wars
• HTML5 context menus
• Image cropping in the browser
• Building a game from HTML5
• BrowserID and a simple implementation example
• Mozilla Web APIs
• Boot to Gecko

Time to board my plane, more details on the MDN work week and the hackday on the Mozilla blog soon.

In another episode of “things Chris watched in the gym and you should, too” here is a great video from the BayJax event series normally held in the Yahoo offices in Sunnyvale, California.

In this presentation Stephen Woods (@ysaw) of Flickr talks about touch interactions and how they used them in the tablet version of Flickr. You can watch it on YouTube or embedded here:

The slides are available on Slideshare and there is even an updated version Stephen presented at SXSW that is a bit less Webkit centric.

Here is what I liked about the video:

• It is 24 minutes long – enough to burn 273 calories
• Stephen knows his stuff without showing off. There is no ego, just a very relaxed presentation and great info. No need for pep rallies or showmanship, get the info, use it as you think fit
• There are no “this works magical and is awesome” moments, you learn the good with the bad – it is a very realistic talk
• It is a great mix of UX concerns, performance explanations and technical info. As in – you see how things were implemented, not how they theoretically should work backed up by random benchmarks
• I found the first utterly sensible and necessary use case for CSS matrix transforms (simulating pinch to zoom)
• It has cats
• It never tries to show off with awesome knowledge or clever large words for simple solutions. Stephen openly admits to have come to the conclusions shown by trial and error

This is a great example that whilst everybody and their aunt will happily tell you that Yahoo is up a small polluted waterway without proper means of propulsion there is great talent and great work being done there. It also shows that when web technology information comes from people who have to deliver to users rather than push a certain product you can get wonderful insights without being hit over the head with them. I liked it. Great job, Stephen.

Two days ago Alex Komoroske, Product Manager of Chrome released a series of videos about the Web Platform accompanied by links to some of the demos and the standards and proposals it uses. I was excited about this as in a world of shiny HTML5 demos and lock-in examples (“you need this browser to see this”), I was looking forward to an agnostic view of what the web platform gives developers. After all, Google did a great job with their Web App Field Guide released a few weeks ago.

Now the videos come with an explanation that is needed to understand their approach:

A few weeks ago one of my developer friends was gushing about the capabilities of his favorite native platform. After every point I felt obliged to point out that the web platform either already had or was actively developing precisely the same capabilities—and then some. He was incredulous. “Prove it,” he said.

I get this request a lot as well, and in most cases I am happy to show what the web can do that native clients can’t. Comparing them on the same level doesn’t make much sense to me. It is like comparing a Formula 1 car to a hovercraft. One is built for a specific purpose and to excel there and the other is meant to adapt to change in the environment. Native client development thrives on abstraction, on the web we build very close to the live code. The web is not a fixed environment where you know what browser and configuration users run your code in. Promising developers of thick clients that they have the same control on the web that they have in their world is a course of action that is hard to go through with.

According to this series, it seems that what we have right now is a solid foundation that is complemented by new standards that need agreement and then will form the platform of the future:

The web platform is composed of a large collection of interoperable standards that represent a solid foundation for building powerful apps. New standards are born on the cutting edge, where various organizations experiment with new capabilities. Those capabilities that capture the imagination of the broader community may eventually become a formal part of the web platform.

This all sounds grand – if a bit weird – as we have been building web apps for quite a while and before that web sites for even longer. So there is a foundation to be aware of and also an infrastructure of outdated browsers and setups that needs to get something if we offer our apps there.

So let’s take a look at the first video for now: Meet the web platform – Building on foundations

Sorry, here’s the web

The video starts with an apology. In order to convince someone who sees the web as a not mature platform, that is not too good a start, but at least it is honest. There is an explanation that some examples only work in Chrome, others will be implemented in Chrome and others are still being defined. It then continues to say that we need a bit of magic to make things work – setting flags, extra code and so on. The goal is explained that this is a preview from the cutting edge and it should get people excited about the web as much as Alex is.

Wait, hang on. This is called “building on foundations” and from the very beginning we are told that we will see what Chrome can do and that it needs hackery to even work in there? What about other browsers? Like the one that comes with Windows or the one in OSX? This is not the web platform I would put my trust in.

Hello world!

It continues with a great message – the low barrier to entry of the web as a developer platform. Open an editor, save it as .html and open it in a browser and you go. There is no compile step. This is an important message to give.

The example is “hello world” without any HTML around it – from the very get-go developers are being conditioned to expect the browser to do magic under the hood to make things work. HTML is not explained, not what a DOCTYPE does or why it is important to mark things up in order to make the browser turn them into what you want to have.

The first code example (1:22) shown is introduced as a “little toy”. A functionality to make a label show up after a checkbox showing in green that the checkbox is checked and in red that it isn’t.

Here is the code for one of the checkboxes:

<style>
  .toggle label {
    background-color: green;
  }
  .toggle.disabled label {
    background-color: green;
  }
</style>
<div class="toggle">
  <span>Flux Drive</span> 
  <input type="checkbox" checked 
onclick="this.parentElement.className=(this.checked)?
'toggle':'toggle disabled';
this.parentElement.querySelector('label').textContent=
(this.checked)?'ON':'OFF';">
  <label>ON</label>
</div>
[...]

Alex explains that this works, is only a bit of styling, and a small script. The main issue here according to the video is that when you repeat this, you add a lot of code and you might to forget a label or something and then it breaks.

Building blocks and modules for the web

The video then goes on to explain that every other platform has building blocks to build on top of them but HTML doesn’t. It explains that there are JavaScript libraries to do that but they are immediately dismissed as “not being robust”.

Without missing a beat, the video then explains that Web Components are the solution for that – a “new standard” (actually a “Extremely early draft” only supported in Chrome 19 when you turn on a flag). So the code that might cause trouble gets replaced by a template and an is attribute.

<link rel="component" href="toggle-control.html">
<div is="toggle">
  Flux Drive
</div>

With the component being:

<component>
  <element name="toggle">
    <template>
      <style scoped>
        label { background: green; }
        .disabled label { background: red; }
      </style>
      <div>
        <content></content>
        <input type="checkbox" checked 
onclick="this.parentElement.className=(this.checked)?
'toggle':'disabled';this.parentElement.querySelector('label').textContent=
(this.checked)?'ON':'OFF';">
        <label>ON</label>
      </div>
    </template>
  </element>
</component>

Regardless of this not rendering the SPAN in the first example, let’s stop here and see what this small piece of code does to the notion of an “open web platform agreed by several players”.

I understand that this is aimed at application developers used to other environments and these people want to see a module system with reusable components. We have these working fine in browsers using JavaScript libraries at the moment – YUI, jQuery and others doing a great job. This is a foundation we could be promoting as the source where we learn from and try to shift into native support. So to say showing what works and where it can go – a foundation, if you will.

Small code, lots of problems

Let’s break this down:

1. We write awful, hard to maintain inline code that is fragile as it expects HTML to be available rather than testing for it – violating the separation of concerns principle of HTML design (seriously, whoever writes that much inline code that does DOM traversal and checks twice for the state of the checkbox either generates their code in a loop or copies and pastes without knowing what they are doing.)
2. In order to avoid breaking this, we don’t replace the code with something more sensible, but instead we move it into a template
3. By using the template, we break backwards compatibility – one of the very basic principles of HTML5.
4. In essence, we solve the issue of developers – using bad code – over the needs of our end users, violating the priority of constituencies principle of HTML5 (users > authors > implementors > specifiers > theoretical purity).

All of this only working in Chrome right now – after setting a flag.

From the very beginning this code example is a very contrived way to get into Web Components. The irony is that the code violates basic principles of what we do on the web to build accessible and stable solutions.

Making the example web code

The whole inline code could be replaced by a single event delegation:

document.addEventListener( 'click', function( ev ) {
   var t  = ev.target;
   if ( t.type === 'checkbox' ) {
     var c = ( t.checked ) ? 'toggle' : 'toggle disabled';
     t.parentElement.className = c;
     var tx = ( t.checked ) ? 'ON' : 'OFF';
     t.parentElement.querySelector('output').textContent = tx; 
   }
},false);

Engineers understand events. Inline code is for the lazy and confused.

What is this output thing here? Well, the HTML of the example does not make any sense as it is now. The job of a label is to link a text with a checkbox, to, well, label it. This is supported by assistive technology and browsers. In a browser the main benefit is that you can click the whole text and not only the checkbox. So, if you want to use JavaScript for this functionality, then an output element would be more appropriate:

<div class="toggle">
    <label for="drive">Flux Drive</label> 
    <input type="checkbox" id="drive" checked>
    <output>ON</output>
</div>

Funnily enough, there is actually no need for JavaScript at all. By using the proper CSS and a span element we can do exactly the same effect:

<style>
  input + span::after {
    content: 'off';
    background: #c00;
  }
  input:checked + span::after{
    content: 'on';
    background: #0c0;
  }
</style>
<label for="html">I actually know HTML</label>
<input type="checkbox" id="html">
<span></span>

And if we align the checkboxes in order to not make this a UX nightmare we won’t even need the SPAN.

<style>
input + label::after {
  content: 'off';
  background: #c00;
  margin-left: 1em;
}
input:checked + label::after {
  content: 'on';
  background: #0c0;
}
</style>
<input type="checkbox" id="html">
<label for="html">I actually know HTML</label>

You see, the on and off labels are just visual fluff. They are not needed. The checked checkbox gives the same information. When we do things that only make sense as a visual aid, CSS is the technology to use. Then we can’t even forget a label as it gets generated only when the browser supports it.

I know, this is “just a quick toy demo”, but if we want to promote the web as a serious platform we should play it to its strengths and not start on the notion of “write whatever, the browser will magically sort out what you do”. 90% of a good web solution is thinking it through before you code and use what already works and build on top of that.

Tab controls – a real web components example

The next demo makes more sense as a web component – it is turning a few articles into a tab strip. There is no HTML for that, true (we dropped the ball when we defined the semantics of HTML5, we defined menus but not tabs. In WAI-ARIA on the other hand, there are tabs amongst many other widget controls, which could be re-used in web components).

The solution is scrolled through fast explaining there is a “a bit of CSS” and a “bit of JavaScript” – hey this could be interesting! How about some info on the how?

We’re done with the web – here’s a debugger

Instead, the video goes on immediately to introduce the Chrome web inspector for debugging explaining that as we use web components we will see the component code in the inspector and not the code that is generated “to make this work”. We learn as an aside that there are spans and divs being generated to make the tab control work. That is new. So what happens when the generated code fails? Where can I debug and fix this? Apparently, this is a feature and not an issue as “component authors will know that their stuff works as nobody can muck around with the internals of the components”. So much for view-source as the power of the open web.

CSS can do amazing things Apple showed you some years ago

Next up we see that all these components are HTML and can be styled with CSS. the demos are blurring them with the webkit-only blur filter and rotate them in 3D space. This is impressive, but which app spec has these as deliveries? How about showing that I can colour tabs alternately or define a “you are here” state in CSS?

HTML editing in the browser

We then learn how to replace the web component tab strip we just created with a video to rotate in 3D space. This is there to show the web inspector HTML editing. Right after we got to know that our components are safe as nobody can mess with them.

There really are applications for this

Next is the SXSW 2011 BeerCamp web site as an example how the things we just saw can be used in a real web site to show amazing effects between pages.

Application layout

Next up Alex brings up a very important point – layout of applications and that absolute positioning and floats are hacks. He shows off flexbox layouts and how they can be used to allow for icons to realign themselves. The code again is scrolled really fast and declared “simple as there are no floats or absolute positioning” – presuming you know how to do flexbox already. We learn that there is no script and all is done declaratively in CSS. That’s a very important and good message. Separate them out.

Debugging on phones

Next up is showing the same demo on Chrome for Android beta on a phone (you can try this – if your phone runs ICS). We also learn that developer tools now connect to the phone and we can debug on the desktop what is happening on the phone. Opera Dragonfly had that for quite a while but it is very good to show to developers who are tired of compiling.

More stuff in the developer tools

Next we learn about timeline in the web inspector showing us when what is rendered and what things are loaded. For debugging this is very important, but to show off the capabilities of the web of the future, I am not sure.

Experimental typography

Next is advanced typography and text rendering showing off the CSS Exclusions defined by Adobe and only supported in a webkit build available on their site.

The video concludes with that “all of this shows how the web is improving upon its core strengths”.

Summary

I for one am confused. If all of the demos shown here were done by someone in Mozilla I’d have asked to re-write the script.

This video doesn’t explain much about the web platform for development – it is an ad for Chrome. It even mentions “the chrome suite” which I hadn’t heard before. It is a very confused script that tries to pack in far too many things in seven minutes.

As a foundation, we now know that there is a standard that nobody has agreed on but people are interested in that might give you modularity and reuse of components. There is no depth to these examples.

Instead we get to know how to use the debugger in Chrome and how to blur things and rotate them in 3D. We also learn that we can edit a HTML document in the browser. That has only marginally to do with the web as the platform unless we could allow end users to do that in a CMS fashion (contenteditable anyone?). We then briefly hear about application layout before we go back to the editor to debug things on the phone – just to show that it can be done. We hear more about the developer tools and then learn that in the future we’d also have typography.

There are a lot of great ideas and passion here, but the passion is for a browser and its tools, not for the open web platform. I would really love to hear some feedback from developers who saw that as an introduction to building things on the web. Right now these are a lot of promises and remind me of videos I have seen showcasing .NET development in Visual Studio or Flex development in Flexbuilder.

I would love this to be better – the idea is great. Have small videos explaining the benefits of the web. As it is I am overloaded and confused. This is not me saying this because it is Chrome. I have been asked several times to show off debugging tools in my talks about HTML5 and I refused as they are different issues. You can show off debuggers explaining what code does and how it works, not to randomly add things in the page.

This video would have been much, much better explaining one thing at a time. How about this:

• Basics of the web – no compilers, add code run it in the browser
• Styling things in CSS - create what is only visual. Show the power of CSS (animation, transition, transformation)
• Boundaries of CSS - flexbox is a solution for app needs, more typo control coming
• Boundaries of HTML - there are no building blocks to reuse
• Web components proposal with a demo that does things HTML can’t do
• As debugging is a large part of development, here is a debugger – look it even works on a phone

I’d be happy to work together on this. I will not do a “use Firefox as the web platform of the Future” as this is the same approach that led to all the IE6 only apps we have out there and the need for Chrome Frame. The web platform has various players and it is up to the end user to decide what browser to use. This will in a lot of cases be the one that comes with the OS.

One of the big questions I repeatedly got at events lately is this:

Is HTML5 ready yet?

The answer is no, because HTML5 is not a bowl of spaghetti that you know when they are ready by flinging them against the wall. HTML was never “ready” and will never be “ready”. It can be “the right choice” and it will be “an exciting opportunity”, it might also be “a dirty hack that works right now” or a “semantically valuable resource that can be converted to whatever you want”.

You see, even HTML4.01 or XHTML for that matter was never “ready”. Sure, the standard was agreed on and you could put in your project deliveries that your web site will be compatible with it, but in most cases this was a lie.

Standard compliance on the web is a means to an end. It made it easier to track mistakes and it made your work understandable by other developers but when it comes to delivering web products, it had not much impact. As web developers we were constantly asked to build interfaces and apply designs and interactions that were never defined in the standard. Which is why we had to find ways to do that which in a lot of cases meant abusing the standard.

We used spacer GIFs and   for padding and margins before CSS got support, we used tables for layout, we used image maps, we used image replacement, we used HTML generated from JavaScript for different browsers and whatever it took to get the best out of what we had in order to achieve the goal we set ourselves.

The goal was always the same: deliver the best possible experience in an unknown, always changing environment.

You don’t know what browser in what setting on which operating system with which security settings the end user has. You also don’t know what ability and connectivity the end user has. An HTML5 app is meant to run on a desktop with 1440 resolution, quadcore processor and lots of RAM on a 10mbit line but also on an old smartphone in the middle of nowhere with a flaky connection. And this is where HTML/CSS and JavaScript excel: you can build apps and sites that adapt to the needs of the environment they run in. This always meant a mix of various web standards and approaches.

The big issue we have now is that with a lot of HTML5 marketing this goal has been washed out and people expect more control from HTML5. The incredibly brain-dead message of “HTML5 is the Flash killer” (yes, I said it) clouds all of our judgement and stands in the way of great web applications. In my book, Flash doesn’t need killing at all.

What needs killing is the close-minded limited way we think about web applications. Flash gave people the impression that they can control the web and define what the end user sees. This is limiting the web and does a disservice to your product. When building web applications you should focus on reaching as many people as possible and not force-feed your design or interaction to all and deliver an agreement that leaves everybody unsatisfied. The recently released Web App Field Guide by Google brings it to the point: HTML5 has enabled developers to break free of the limits they were used to when building web applications.

HTML5 is the evolution we needed in web technology to build apps instead of documents. HTML4 was not the right technology for that and XHTML was a bust from the very beginning as it was too rigid for the web. We now have ways to store information on the computer, we have access to multimedia and we can create visuals in the browser. HTML5 is not just markup or “watered down XML”, it includes JavaScript APIs and defines how a browser should behave if it wants to be called an HTML5 compliant browser.

The main difference between HTML4 and HTML5 is the direction of innovation. In the HTML4 world we had a standard that was inadequate to what we needed to build. That’s why browser vendors build their own extensions on top of it and created a total mess for developers. In order to achieve our goal we had to write code for each of the browsers out there, rather than writing HTML. This was awful and caused a lot of people to chose the simple way out and write exclusively for one browser. In the past this was Internet Explorer 6 and this is why we now have a lot of government and enterprise IT environments that don’t upgrade to newer browsers. This holds us back.

HTML is now a living standard. This boggles the mind of a lot of people – how could a standard be living? Well, to me, this makes a lot of sense. The needs of the web are constantly changing. A few years ago nobody predicted – least of all the standards bodies – that we will consume the internet on mobile devices with touch interfaces. What will happen in the nearer future? Who knows? Face and motion recognition?

HTML5 is defined by browser makers tinkering and innovating and feeding back to the standard. Then other browser makers weigh in and we make it an agreed standard. This avoids the issue of developers having to build things for browsers and it means the standard will not fall behind. The main power of the internet is that you don’t need to write the same app several times for different environments and by agreeing amongst browser makers we make sure that there will not be a new IE6 situation.

So no, HTML5 is not ready and will never be – and that is a good thing. We have a standard for the web with all its change and adaptation and not a software standard that expects 5 year turnaround times in innovation.

Discussion on Google+ – Discussion on Facebook