• You are currently browsing the Christian Heilmann blog archives for July, 2011.

  • Archive for July, 2011

    Mess them up while they are young? Better web tutorials now!

    Thursday, July 28th, 2011

    I am currently tech-reviewing a book that is used in educational environments (schools, universities, corporate training) on HTML5, CSS and JavaScript, or – in short – web development. And needless to say I am pretty shocked by what is taught in schools on that subject.

    It annoys me that the first materials new learners get seems to repeat a lot of mistakes of the past. Following I will show some of the issues and what we should be doing instead.

    Disclaimer: these are examples I did come across in current code examples and training materials. Anyone shouting that “nobody uses that anymore” and “what kind of idiot would code like that” should please take the stairs down from their ivory tower and get their hands dirty in real, day-to-day training that happens in our schools and corporate training rooms. I am not making this up – this is the impression people get when starting on the web from a school or corporate angle rather than reading magazines, blogs or follow some known people on Twitter.

    The “hello world” from hell

    The thing I keep seeing as the first code example is something like this:

    <script type="text/javascript" language="javascript">
    <!--
    document.writeln("hello world of JavaScript");
    // -->
    </script>

    This is normally followed by explanations that:

    • this is the way to embed a script,
    • that the type and/or the language is important to tell the browser what kind of script it is and
    • that the comments are needed to stop browsers from displaying the code. The JavaScript line comment “//” in the last line is sometimes added “to make sure that your HTML validates”

    If you really use an HTML5 Doctype none of them are needed. JavaScript is the only language browsers that support HTML5 and are in use will execute so the type attribute only makes sense when you want to embed a script that shouldn’t be rendered by all. Some client side templating languages do this. JScript is dead, let’s not even bother telling people about it.

    As for the comments, I haven’t come across any browsers ever that display the code inside script blocks. If you really worried about backwards compatibility that goes back to LynxNetscape 1(as apparently Lynx is still in production) then you should also not embed your scripts in the page.

    In the end, this is what we will do in any case to reap the benefits of maintaining our scripts in separate files. Embedded code in a page is only needed for high performance environments that need everything in one cached file. The other time I keep seeing embedded JS code is to apply a quick fix to a product or to add a “one off as this is a special page” and thus making maintenance harder.

    Let’s do this instead: the way to write a “hello world” would be to write an index.html that explains the very needed basics of semantic HTML and embed the following:

    <script src="helloworld.js"></script>

    That way people never get tempted to mix behaviour, structure and presentation and get to understand what it means to build a web product rather than a page that has everything in one file.

    Of course, there can be benefits of keeping all in one document. For starters you can explain how the different things work together. In a real development environment, however, this is the odd one out and our primers should not start explaining those. It is much harder to un-learn things than it is to learn them, so why do we start with something you won’t use later on?

    Let’s treat both CSS and JS like we treat images in an HTML document – an external resource. This is the biggest use case and it is the one we should get people to start with.

    The curse of document.write()

    Every time I see a document.write() or document.writeln() in materials these days I die a bit inside. I was around when we had to use that to write framesets into popup windows we just opened. The reason was that browsers didn’t support the DOM to reach content in the page or to create HTML content. I don’t want to remember those times, and neither should people who come into the world of web development for the first time.

    I understand that it is the easiest way to show output in a document – to give new developers their first “wow, what I just programmed shows up on a screen” moment. I also know, however, that I would never hire anyone who uses document.write just to print out something on the screen.

    Using document.write() teaches developers that JS writes out content where you add a script node – not how to interact with HTML.

    Let’s do this instead: instead of writing to the document we have a few options. These are ordered in preference, starting with the least desirable:

    • Use alert() – which is only marginally better, but comes with a few benefits. Alerts are disruptive. They stop the execution of your code and you can for example show how the value of a variable changes through the execution of your script. The issue with them is that if you want to show a lot of values, it can become annoying to hit enter to get rid of all the alerts. In new Firefoxes for example alerts are stacked instead of stopping the execution, which means that this benefit is gone.
    • Start with a simple introduction to the DOM. It is really simple if you think about it:

      Using the Document Object Model (DOM) we can reach elements in the page. Say for example you have a <p id="result"></p> in the document. Using document.getElementById('result') in your JavaScript will give you access to this element. You can read and write to this element by using innerHTML. So if you do a document.getElementById('result').innerHTML = 'My result' you will see that the content of the paragraph is changed to “my result”. If you do an alert(document.getElementById('result').innerHTML) you will get an alert stating ‘my result’ as this is the text content of the paragraph after you changed it.

      That’s not too hard, is it?

    • Introduce debugging tools from the very start – explain consoles in browsers. All modern browsers come with a development console that can show messages written out with console.log(). By starting with that we explain developers how to debug code before they write it and we let them see what is going on in their code. It is like showing a new trainee where the manuals and the first aid kit are before allowing them to use the power tools. Most of our job is testing our code – not writing it. In the real world we spend most of our time debugging and refactoring code – so why not start with this?

    The curse of alert() and prompt()

    Using alerts and prompts to print out results and get content from users is a simple way that works in any browser. However, in a real product you will hardly ever use an alert (other than for debugging) and I can safely say that I never saw the use of prompt outside of tutorials.

    Hands up who ever made the mistake of adding an alert() in a massive loop or try to debug a blur() event handler using an alert and thus ending up in an endless debugging loop. Yes, it happens and it doesn’t make sense to go that way when browsers (and server-side JavaScript) have debugging tools these days that are much better in showing us what happens under the hood. A console shows us the objects and DOM elements rather than a cryptic [object object] as debugging information.

    Let’s do this instead: instead of using the browser object model and alerts, confirms and prompts use the console for debugging and form fields for data entry. It is really not that hard to write a simple explanation how to access data in a form:

    Forms in documents allow you to get information from the user and act on it. Say you have the following form in a page:

    <form action="post.php">
    <label for="entrynumber">Please enter a number</label>
    <input type="number" name="n" id="entrynumber" placeholder="0" required>
    <input type="submit" value="calculate!">
    </form>

    The label element is needed to tell users what the entry field is and what they should do with it. The type attribute tells the browser what kind of entry field we expect – in this case a number. The name is needed for a backend script to get the information when the form is sent to the server and the id is needed to connect the label and the input element, the placeholder shows the user an expected value and the required attribute validates the form in the browser.

    As with all elements in the document you can reach the input field using the document.getElementById() method in JavaScript. and you can set and read the value of the field with getAttribute() and setAttribute(). So if you want to use JavaScript to set the value of the entrynumber to 5, all you need to do is document.getElementById('entrynumber').setAttribute('value',5). If you want to read the value of the field you can do a console.log(document.getElementById('entrynumber').getAttribute('value'))

    You can set and read the value of the field by reading or writing to the value property of the element. To set the value of the entrynumber to 5, all you need to do is document.getElementById('entrynumber').value = 5. If you want to read the value of the field you can do a console.log(document.getElementById('entrynumber').value)

    (after some testing and feedback from Mathias Bynens this still is the better way to teach new developers)

    Back that up with a working example you link to and you already explained how forms work, what some of the attributes do, that browsers these days have client-side validation and how to read and write form values. And it wasn’t that long and hard to do.

    The myth of the short attention span

    Whenever I ask people to explain the why and not just the how in tutorials I get feedback that our readers are busy and want to see the outcome as soon as possible. The general consensus is that readers have an incredibly short attention span and don’t want repetition or get long winded explanations.

    That may be true, but it doesn’t mean that you need to spoon-feed information. It means that the start of your tutorial must grab their attention and you must make it interesting. If going through a tutorial and coding along is fun then people will not realise how long they spend on a certain task.

    Look at gaming: Angry Birds didn’t come with a tutorial – every time you get a new type of bird there is a simple picture showing you what they do and how to activate their special skills with your finger. They could have written a long document but they didn’t need to. If you really think people have a short attention span and lose interest really fast just see how many times people try to solve the same level over and over again as it is fun to see pigs explode. The same applies to “Cut the rope”. You feel bad when the little frog frowns as the candy gets lost and its constant excitement about the impending feeding makes you want to solve the puzzle all the more. Why do we have this attention only when it comes to “wasting our time” playing games?

    Our training materials should learn from that and keep our readers excited and wanting to learn more. You don’t do that with dry examples of die throwing simulators and mathematical loops calculating prime numbers. Bring emotion into your materials or show real life examples and you will have the attention of your readers. In a training, have the group discover the materials bit by bit rather than giving them a massive binder with information and examples that need to be done by then end of the day if you want to get a shiny certificate to collect dust on your wall.

    Lipstick and a wig on a pig

    You can not re-use old materials by spicing them up with new technology. Period. Whenever a new buzzword appears, some old books get dusted off and new features get added. This happened with DHTML, then Ajax, then Mobile Web Development and now HTML5. Replace the Netscape 3 screenshots with Chrome ones, slap on a chapter covering the new techniques and voilá – you got yourself a new seller. I am sure a lot of people get approached by publishers to “write a new version of this old book, you, know, upgrading it”. Just say no!

    Unless the original version of the book has been incredibly well written – and I have yet to find one of that calibre – this is a waste of everybody’s time and borders on a scam. In the past, a big part of web development was either working around bugs in browsers or catering for a special environment. Both are things of the past and you can’t just add a theoretical new chapter to upgrade an old book that is based on dated approaches.

    We still struggle to find a correct way to build things on the web and our development practices change constantly. Performance issues, security concerns and stability are constantly fixed and changed in browsers and what was a great idea in the past can easily now get your site hacked or make it perform incredibly bad.

    Changing the approach of explaining code in web development

    All of this inspired me to write another beginners tutorial to web development. Instead of showing all the things that are possible we should show what makes sense and gets people on their way. A solid foundation with the least necessary information is a great starting point to go out there and learn on your own terms. Our tutorials and courses should start a desire to learn more – not to ensure we got all the information out that we were asked to shove down the throats of our students.

    A different approach to conference Q&A – Interviews

    Thursday, July 21st, 2011

    A few weeks ago was Highland Fling, a conference in Scotland organised and run by a very enthusiastic person, Alan White. I spoke twice at that event in the past and one thing I loved most about it was how it handled the Q&A of the audience.

    The issues with Q&A

    After-talk Q&A is always a pain to get right. There are a few issues that keep cropping up:

    • People are too afraid to ask a “probably stupid” question in front of the rest of the audience (funnily enough a lot of times this is the question a lot of others have but are as afraid to ask)
    • People asking questions use the opportunity to profile themselves or their company/product instead of asking a valid question (thus wasting everybody’s time)
    • Speakers and/or the audience can’t hear or understand the question (and speakers need to repeat it so it gets recorded/is heard by everybody thus using up even more time)
    • Speakers can’t see the audience properly (lights in their eyes) which means some half-hearted requests don’t get recognised
    • The people asking questions are asked to wait for the microphone to be comprehensible to everybody which takes up time (and not everybody knows how to handle a mic)
    • Interesting questions at the beginning of the talk get forgotten halfway through
    • Speakers get stuck answering one question or deviate rather than answering swiftly and getting more questions in

    The Highland Fling way

    The Fling does it differently: instead of having an open Q&A session after the talk the conference has a moderator who not only introduces the speakers but also does a 20 minute interview with them after the talk. Conference participants can tweet questions to the interviewer during the talk. This works around most of the issues mentioned earlier.

    This year I was lucky enough to be the moderator/interviewer.

    interviewing at highland flingOriginal photos by Drew McLellan

    As you may know, I have a background in radio where I spent a lot of time interviewing people on the phone and live. It was a lot of fun going back to that and especially interesting to have a mixed group of speakers all with different specialist topics to chat about.

    Judging from the Twitter feedback at the conference I must have done a good job, and it was great to see speakers be more relaxed when they sit on a sofa and know some questions will come rather than hoping there are some.

    I think more conferences should adopt this idea.

    On browser “statistics”

    Wednesday, July 6th, 2011

    browser wars

    Every time I come across tweets about browser stats I get a bit twitchy. First of all because they always try to paint a picture in one direction or another but mostly as I am not sure about the data they are based on.

    What are the sources?

    Whenever there is talk about browser stats a few companies crop up: Counter.com, Statcounter.com and Netapplications.com, all of which are hitcounter solutions.

    I personally use Statcounter – but only on a few of my pages that I specifically want monitored. So if I compare the stats of Statcounter to the overall stats of the Urchin that comes with my server, there are discrepancies:

    Statcounter statistics

    urchin stats

    ( I have no clue what Pipes is doing there – I guess there are some RSS syndicators at work :) )

    This, of course is to be expected. But if I now said that Safari only makes up 6.1% of my stats and use the overall hit numbers of the server in another sentence people wouldn’t blink an eye about that wrong connection.

    Now, as most of the official sources constantly mentioned are companies that make money with selling statistics software it makes you wonder if those numbers could not be doctored to show some cool trends so people want to know if as many cool kids on iPads come to their site or not. Even without my tinfoil hat on I feel that there should be a better way of collecting information from sources closer to the, err, source. You know, like server logs.

    Our fetish for web site statistics

    It seems that people really need numbers. All the big web shows have keynotes with lots of massive numbers in them. So and so many million Android devices at Google IO and so and so many iOS devices at WWDC. So many people upgrading to IE9 at Mix (hey, no Windows XP users though, sorry about that) and of course a lot of people using Blackberries and Nokia phones and and and…

    I have never had a client that didn’t want a statistics package and when you offer them (the aformentioned companies or Google Diagnostics) it is always amazing to see what people look for: the success stories.

    • How many users did we have more than last month (regardless of them being visitors or spam bots trying to inject code)?
    • Which are the most successful parts of the site?
    • What are the main screen resolutions?
    • How many users have JS disabled so that we can pat our back and proclaim that hashbang URLs are not an issue?

    We take statistics as a means of validating our success, not as an opportunity to analyse what could be improved. It is another example of the “like” culture that has taken over our market in the recent years.

    An aside: Your statistics have much more interesting data in them. Check the form submission data on your stats to see what people tried to inject code and where to see which parts of your sites should need some extra security love. Check which parts of your site perform badly or stop people going further and find out what made that happen. Where are broken links and how hurtful to the site navigation are they? Analyse the search bot behaviour on your site and see where they get stuck. And and and…

    Back to browsers though:

    The “only stat that matters” myth

    You probably have seen those talks: someone shows one or another browser statistic and the incredibly uplifting story for us web developers that this data represents and then ends with “of course the only real statistic that matters is the one of the site you work on”.

    This most of the time translates to “if most of your users are stuck on IE < 9 none of the cool stuff really matters to you”. This is dangerous thinking. First of all – using progressive enhancement you can use all of the cool new stuff:

    Supporting old browsers is to me a given when you put things on the web. Read my lips: you can not dictate what browser your users should have. If you do that, you hurt the web, you lock yourself in to a monoculture and you build yet another piece of the web that will block innovation in the future. I do not care if your browser of need is IE, Safari, Chrome or Firefox. All should get something that works – no matter how cool a new version of a certain browser is. This thinking gave us all the apps that now only work in IE6.

    Using polyfills you can even make those less fortunate browsers do the same things the new, cool ones do. I am not a big fan of polyfills but that’s for another post.

    Whilst it is obvious that you should cater to the largest part of your visitors you should not see that as a reason not to improve the experience for those who can get more. Using local storage and offline storage in browsers that support it can significantly reduce your traffic. Using CSS3 and responsive design wisely means that you cater for the web and new, cool tablet and mobile devices without changing the experience for IE6 users.

    It is no wonder that you won’t see many mobile browsers in your stats when you concentrate on supporting only old browsers and desktop machines. Your stats should be a guideline to remind you that you have a diversified audience, not a blocker meaning that you will never get others.

    Also, what happens when you start a new project from scratch? Then there is no “one stat that matters”...

    I tell you what I want, what I really, really want…

    What I’d really want is an open, free and editable resource where you can find statistics of big web sites out there. You could see the stats by market, by nature of the sites and get real information from the server logs rather than some software that relies on tracking and might be blocked (and needs to be installed in the first place).

    Inside Yahoo we had a great resource that showed our statistics. This was never published to the outside though (although I frequently requested it). I do think that every big company does the same. Wouldn’t it be awesome to get the statistics of Facebook, Yahoo, Google, AOL, The Guardian, CNN… ? If the server log data gets stripped of all the information that is not browser specific none of these companies would give out any competitive advantage data. All we would get is a real world view of what people really use.

    Do you know of any such stats? Do you work for a large corporation? Ask now if you could do a dump of your data and show some stats – I promise you’d get a lot of hits by a very selective group of web developers who need the real information!

    TTMMHTM: Fiddle with JSFiddle, stop looking for ‘Likes’, conference book and Mozilla Events

    Tuesday, July 5th, 2011

    Things that made me happy this morning:

    Creating screengrabs from HTML5 video with Canvas

    Friday, July 1st, 2011

    Lately I’ve been playing a lot with canvas and video and see what can be done with it to do things that are tough to do to videos on your own computers. One thing I found really annoying is that it is tough to do screen grabs of videos. In the past it was impossible (before video cards allowed you to capture flash content with screenshots) and even now it is a pain.

    If you offer an online video that is HTML5, it is pretty simple to use canvas to allow end users to download images of your video. I’ve written a demo that does exactly that – it takes a snapshot of a video and adds its name and time stamp to the snapshot. Users then can download the snapshot as a PNG.

    screengrabs with canvas

    Here’s a quick tutorial on how it is done (also available on YouTube)

    You can see the code in action or fork and grab the source on GitHub.

    The only annoyance is that because of security concerns (cross domain origin) you can not grab images from videos not hosted on the same servergrab frames from videos not on the same server but you are not allowed to save them out as images. In Firefox you can save a canvas as an image, but it doesn’t work cross-browser it seems.