I am currently in Bucharest, Romania and yesterday talked about current issues with HTML5 and how Mozilla found solutions for them during the creation of Firefox OS.

photo by Ștefania Ioana Chiorean

The slides with notes are on Slideshare

There’s also an audio recording available on Soundcloud

It was good fun and I got some interesting questions from the audience.

Update: The recording of the talk is now also on YouTube:

Disclaimer: I work for Mozilla, these are my views, yadda yadda.

Today Google released the Google Web Designer (beta), a WYSIWYG editor to create HTML5 ads for Google AdSense.

The designer is an installable app for Mac or PC but seems to be an HTML app under the hood. The interface is very familiar to people who use Adobe’s tools to create ads in the past (yeah, the F(lash) word) and seems to be a directly catered to AdSense alternative to Adobe’s Edge suite.

Of course, when there is a new editor out, shenanigans are afoot really quickly and David Matthams scored the Twitter goal with his Google Web Designer creation of outstanding beauty (yes, this was sarcasm, yes, David’s creation is a joke).

Here’s the thing though: I do applaud Google for what they’ve done here. First of all, the tool creates CSS animated ads – not JavaScript driven ones and despite a few hitches (div class=”gwd-div-s33n editable editable editable editable editable editable gwd-gen-8p5fgwdanimation gwd-div-ydjn gwd-gen-8p5fgwdanimation-gen-animation0keyframe” being an interesting one) the code is clean, supports all the browser prefixes and a non-prefixed fallback and is editable by a machine and readable by a human.

The latter is a very important bit: getting on our high horse and trying to quarrel with the semantics of generated code like this is futile. These are ads. They are clickable videos, and their main task is to look pretty and get people to buy stuff whilst working in all environments. And this code achieves that goal quite well.

HTML5 needs tools, there is no question about it. And whoever had to work with ad providers knows that a lot of ads cause havoc with your memory consumption and page performance. This tool, at least, does not do that and uses Google’s fixation on performance.

So before we snigger at “the return of Dreamweaver or Flash’s fallback output”, let’s take a moment and remember that a lot of content out there on the web that pays our wages and bills is built by people who have no clue about HTML. And we are arrogant enough not to ever touch the projects they get paid to create.

So, I for one, am happy about more tools that are having a good start and hope they’ll go far. In this instance especially, I wouldn’t be surprised if that will be a part of the AdSense site sooner or later and I am extremely happy that it is not a Chrome App that does not work with other browsers, but a tool that people can use.

One thing that bugs me a lot is that in the publishing world about the web we have a fetish for the “how” whereas we should strive for the “why” instead.

What do I mean by that? Well, first of all, I count everything that is published as important. This could be a comment, a tweet, a blog post, a presentation, a screencast – doesn’t matter. If it ends up on the web it will be linked to, it will be quoted, it will be taken as “best practice” or “common usage” and people will start arguing over it and adding it to what we call “common knowledge” (spoiler: there is no such thing).

That is why publications that answer the “how” without also explaining the “why” are dangerous. We explain how something is done and we pride ourselves when this is as short and simple as possible. We do live coding on stage showing how complex things can be done with one small command and five different build systems. We show how simple things are when people use this editor or that development tool or this browser and everything is just a click away and we get amazing insight into the things we do.

Assumed stamina and interest

We expect people who learn the “how” to be sharp and interested enough to get to the “why” themselves. Sadly enough this is hardly ever the case. Instead, the quick “how” also known as the “here is how you do it” becomes an excuse not to even question practices and solutions any longer. “Awesome technology expert $person said and showed on stage that this is how it is done. Don’t waste your time on doing it differently” is becoming a mantra for a lot of new developers.

Moldy advice

The issue with this is that “best practices” are getting more and more short-lived and in many cases very dependent on the environment they are applied in. What fixed performance issues in a Web View on iPhone 3 might be a terrible idea on Chrome on a Desktop, what was a real issue in JavaScript 10 years ago might not even make a minimal difference in today’s engines (string concatenation anyone?).

What is “the why”?

The “why” can be a few different things:

• Why does doing something in the way we do it work?
• Why should you use a certain technology?
• Why is it important to do this, but also understand the environment it is most effective in?
• Why is using something simple and effective but also dangerous depending on outside factors?
• Why is a new way of doing something more effective than an older way of doing it?
• Why is it important to understand what you do and how do you explain to other people that there is a reason to do it?

Explaining the “why” is much, much harder than the “how”. Telling someone to do something in a certain way is giving orders, explaining a procedure. Explaining why it should be done this way means you teach the other person, and it also means you need to deeply understand what you do. The “how” can be repeated by someone who doesn’t know really how something works – and in many cases is – the “why” means you have to put much more effort into understanding what you advocate. The “how” is what lead to boring school books and terrible training folders. The “why” leads to interactive and memorable training experiences.

W3Schools – the kingdom of the how

Getting rid of the fetish of the how is an incredibly frustrating uphill battle. The biggest manifestation of the “how” is W3Schools.com. This site shows you how to do something – even interactively – and thus has become a force majeur in the web development world. It gives you a fast, quick answer to copy and paste without the pesky having to “understand what you are doing” part. This leads to people defending it tooth and nail every time some righteous people set out to kill it. All of these efforts are doomed to fail if they mean setting up yet another resource that will “do things better than w3schools”. The reason sites like W3Schools work are:

• They give you a short answer and make you feel clever as you achieved something amazing without effort
• They are easy to link to as an answer to a question without having to explain things
• They are easy to embed into a tutorial or article as a quick citation to “prove a point”
• People used them for years and they grew constantly which is something that Google loves

In other words, they are a useful reminder and lookup resource for people who already know the “why” and simply forgot the “how”. Thus, they look like a power tool the experts use and are very tempting for beginners to use as well. Much like buying the same shoes as Usain Bolt should make you an amazing runner…

The only way to “kill W3Schools” is to support resources that explain the how and the why, like MDN or WebPlatform.org – not to create more resources that have the right heart but are doomed to fail as maintaining a documentation resource is an amazing amount of work. Instead of sending new developers to w3schools or a Stackoverflow post that explains how something is done quickly, send them to a deep link on those. We can not expect people we point to solutions to care about how they happened. We have to show them the way, not the destination. By sending them to the destination via a shortcut, we deprive them of their own, personal learning experience and we cheapen our job to something anyone can look up on demand.

The “how” gets outdated, and – in many cases – dangerous practice very, very quickly. The “why” remains as it lights up the way to a solution, a solution that can change over time.

That’s why I’d love people to stop spouting quick answers and let new developers ponder the solution for themselves before telling them a way to do it quickly. We need to learn in order to understand and be empowered to create on our own. You only learn by asking why – let’s be supportive of that instead of feeling smug about pointing out an already existing solution. Web development got to where it is by continuously questioning how we do things and find ways to make it work. If we stop doing that, we stagnate.