A few days ago I was in Miami, Florida, as my old Ajaxian colleague Rey Bango invited me to record a few videos with him on HTML5 topics for Microsoft’s Channel 9 developer programme.
Video shoot on the beach
Originally we planned to have presentations with live coding examples – each 15 minutes long by Rey and me on our own. Thinking it over, we found it more natural to do them together and so to say show the presentation and code examples to each other in a chat format.
The first session we recorded was about “Building for real standards”. In this we talk about what a standard means, how this applies to HTML5 and discuss problems and pitfalls to avoid. The slides are available on Slideshare and there is also a version with presenter notes.
The second session was about “Modern Web Development”. In this we talked about developing for an unknown environment using Progressive Enhancement, what the differences are to Graceful Degredation and we show how Responsive Design can lead to a future friendly product. The slides are available on Slideshare and there is also a version with presenter notes.
If you want to present these talks yourself, I uploaded the slides in various formats and the code examples with lots of explanations on how to present them to GitHub:
All in all this was a great experience and I can’t wait for the videos to be out. It is good to see that there are people in Microsoft who really care about web standards and cross-browser development. We wanted to record a lot more footage of us discussing more topics but sadly enough one of the harddrives crashes so we had to re-shoot all the sessions on the last day. In retrospect this made the sessions better as we got less formal and kept them shorter. The final products should be around 20 minutes each.
Posted in publicspeaking, training | Comments Off on Video training shoots with Microsoft – get the slides and code to present them yourselves
Keeping the streak alive, I was asked to provide a foreword for another book, this time HTML5 in action by Robert Crowther, Joe Lennon, and Ash Blue. So here is what I had to say:
Foreword
Explaining what HTML5 is can be a very daunting task. I’ve been doing this more or less since its inception and I am still amazed just how many myths and how much confusion is there on the topic.
With HTML5 we re-booted web development. The world of HTML4.01 and the non-starter XHTML left those who wanted to use the web as a platform for applications stranded. HTML4 was meant for linked documents and XHTML was far too strict for its own good and it lacked real support in browsers.
HTML5 started with a clean slate. We analysed what was used on the web and added a lot of features we didn’t have before, like CANVAS for creating visuals on the fly or accessing images and videos on a pixel level, native audio and video without the need for plugins and forms that validate in the browser without us having to write extra JavaScript. We also started mudding the waters by merging HTML and JavaScript functionality – a lot of HTML5 will not do anything without accessing the elements via a JavaScript API. This confuses a lot of people. We moved on from a document based web and in that process we need more technical know-how. And this means we need to rethink a few of our “best practices” now which can annoy people so that they spread nasty rumours about the viability of HTML5 as a choice for professional development.
HTML5 is built on the robustness principle, which means that a browser will make a lot of educated guesses what you might have meant when you make a syntax error instead of simply giving up and showing an error. This gives it backwards compatibility and we will be able to show pages developed for a never-to-arrive XHTML world in browsers these days. A large part of the standard is just that – it tells you how to write a browser that renders HTML5 rather than using it as a web developer. Again, this angers some people and they shout about the verbosity of the standard.
HTML5 is also the new hotness. A lot of advertising talk, shiny demos and promises of fidelity that matches native apps on phones make us cynical battle hardened web developers think back on Java, Flash and Silverlight and their promises and sigh. We have a lot of buzz about HTML5 and a lot of things that are not part of the standard are simply declared part of it as it makes a good punch line.
When it comes to extending the language and bringing new features into it we are running wild right now. Every browser maker and web company comes up with great new concepts on almost a weekly level. That can be frustrating for developers who just want to get a job done. Can you rely on the functionality that is currently developed or will the standard be changed later on? We are pushing browsers further into the operating system and allow them to access hardware directly which comes with security and robustness issues that need to be fixed by trial and error. Can you take that risk with us when it comes to delivering your product?
These are exciting times and when you want to be part of the ride you can help forge the future development environment for all of us. If you don’t have the time to follow the discussions on mailing lists, do a lot of browser testing in previews and propose own ideas you can be left quite confused.
And this is where a book like this comes in. Instead of promising you a cornucopia of functionality that will soon be available you get examples that work right now based on examples that worked in the past. Instead of getting experimental demos you learn how to build production code based on proven ideas but using the features in modern browsers that make it easier for us developers and much more enjoyable for our end users. All the examples come with a legend telling you which browsers support the features and you learn how not to give them to old browsers that will choke on them.
You will learn how to use HTML5 now, using secure and intelligent solutions like Modernizr and HTML5 Boilerplate and you will come out at the end understanding how to write things in HTML5 that work right now. This will make you a part of the movement to get HTML5 “production ready” for all of us.
Those who live on the bleeding edge of defining the next browser and language features need implementations in the wild right now. We are past the show and tell stage and we need to get to deliver and enhance. And you can become an integral part of this process by following the advice and applying the examples you find here. Go forth and deliver.
Posted in writing | Comments Off on Another foreword – HTML5 in Action
At the fluent conference last week Nicole Sullivan gave an interesting keynote called Don’t feed the trolls:
I liked this very much. We need to fight the current culture of animosity, one-upping and “winning” on the web and turn it towards a culture of nurturing each other and that values communication and agreement instead. The main techniques to do that were outlined by Nicole:
Respond to what makes sense and is the human part in troll mails and posts
Don’t feed trolls – don’t fall for baits
Nicole works through a few kinds of trolls, jealous trolls, the grammar nazi, the biased troll (and the trolls who look for bias where there is none) and the scary troll. She alludes to another, which I will cover here:
The accidental troll
In her talk, Nicole defines a troll:
Def. Troll – people who seek conflict
Now, I have been called a troll a few times, and it hurts me every single time. I am not a person to seek conflict – at all. I am very uncompetitive and the best way to bore me is to tell me that $x does things better than me. Good for $x. I am not $x – I can look at what $x is doing and see what I like for myself but I shouldn’t copy it as it is not me. I want to be better myself tomorrow than I am today as I am the person that is with me all the time. If you don’t compare yourself to yourself and get better you play catchup and become the “good” that is somebody else. You have your own, unique way of learning and communicating and you should hone and celebrate that. If you get home and the door closes and you are someone else then there is a problem. This is for actors and rockstars who tend to die in drug overdoses.
So how come people saw me as a troll or gave me the “Don’t be hatin” message that pretty much insults the grammar fan in me? Because I posted in anger. I was pissed off – somebody was wrong on the internet and people even applauded and quoted it. This will not do.
Cultural differences
Part of this is cultural. Europeans, especially Germans, are a direct bunch. We say it like it is. If we want something, we request it. If we don’t like something, we make it obvious without a doubt that this is the case. America, on the other hand is not like that. Everything is about not offending people – not because this is bad, but mostly because you can get sued if you do. How this works in a society that is highly competitive at the same time continuously baffles me. There can’t be any losers in any competition, just third, fourth and forty-eighth winners. This dilutes the idea of competition to the degree that people don’t take them serious any more. In Europe, not so much. A competition is something serious and to win, someone has to lose. The same applies to conversations. Meetings in the US are considered a success if everything was mentioned and nobody was affronted or feels bad coming out of them.
In Europe, the result of a meeting is what has been done and what needs to be done next by who and by which date. If that means someone got blamed for doing things wrong, that is just how it is.
Pointing out an error is not attacking the person who made that error. What it is is pointing out an opportunity to fix something. This is the end goal. A lot of people have problems admitting to failure. To me, a failure is a great opportunity to analyse what happened and making sure you don’t do it again. If that hurts, even better, as it is easier to remember for you not to do it.
With this background it is easy to affront people on mailing lists and other communication devices that lack human communication (body language, voice and so on). The problem is exacerbated when the thing that – in your book – is obviously wrong gets sold as a “best practice” and gets a jazzy marketing-ish abbreviation and people quote it all over the place. Something you consider a mistake becomes something other people strive for rather than being something to learn from by avoiding it.
Countermeasures
So here is what I do now. I channel the Fennec:
You notice that this animal is much more ear than mouth and this is what we should be doing. Instead of firing up a massive post ranting about what is wrong in a certain publication or person we should start asking questions and most of all listening. The same applies to humans: we have two ears but one mouth – let this be our ratio for learning.
So if you disagree with something and it really rails you, give it some time before you answer. Do other things, have fun with people. Then go back and write your post if you still want to. Even better, ask the right questions.
By asking for refinement and pointing out shortcomings of a solution in the form of a question you do not only bring it upon you to do better than the original solution. You also turn your anger into a chance to get the original maker to take on your refinements and make the product that angered you work better. If the original author can not answer your questions you managed to show that they made mistakes and called something a best practice prematurely. And other people listen, too. Which means that they’ll request more details and changes.
Another way of listening is to read all the other posts and comments following the thing that annoyed you. You’ll find that in a lot of cases other people will point out the flaws you see, too and you can join a conversation and maybe even soften the tone of other comments to turn them from flame to request.
All in all a lot of accidental trolling happens because we get the wrong urge to answer as fast as possible and be the first to point out a flaw and thus winning 245 internets. Letting things sink in first and listen for a while helps you write better responses, realise that some sins are not really that much of an issue and make you understand the context of what something was published in, which can be a large part of the content decisions.
