I spend a lot of my time right now coaching people on public speaking and attending conferences seeing other presenters. The latter is a great step to get into presenting yourself. Analyse what you see, find what you like and what you could use without parroting what the other speaker does. Also take down what you thought was bad and store it in the back of your head to avoid when it is your turn to dazzle an audience.

Presenting is not about winning against other presenters

I see a lot of talent and I see a lot of great stuff happening. I also see a worrying trend though trying to impress and audience and “win the conference” or “kill it” with a great talk. In other words, we plan technology performances rather than conference talks.

Attendee feedback seems to say that this is what we need to do; a talk showing how to control a model helicopter with JavaScript gets more votes than one explaining how to fix a layout issue across browsers. The latter does make us more effective in our jobs, the former is inspiring and has a cool factor we’d love our jobs to have every day. It is technological escapism. Maybe there is a place for that in tech conferences – a presentation is a performance as much as a teaching exercise – but I see too much of it. There are excellent people out there doing this kind of work – Seb Lee-Delisle comes to mind – but we also need people who show how doing something in a certain way yielded great, albeit more boring, results.

Nicholas Zakas just wrote about the issue that conference talks seem to trend towards showing us the “soon possible” and “amazing without proof” instead of case studies proving that doing something in a certain way yields great results.

I agree to a certain point, but also realise that filling a conference with great talks is a hard job. A conference consisting 90% of case studies would not be much better – as you can not assume that attendees have the same problems to solve. A lot of what we hear at conferences as “best practices” might apply to GMail’s mobile interface, Spotify’s “find new music” feature or Facebook’s chat panel, but doesn’t apply to a large part of the market out there. And I don’t buy the logic of “if it works in a high-traffic, technically taxing environment it will make everything better” – an argument we keep hearing a lot when it comes to the web on mobiles. What makes sense for a game might not make sense for a CMS driven content site. Delivering a great experience is more than technical excellence and people do use slow interfaces if the content is good enough – heck, I wait 30 seconds for Minion Run on my Android to start as I like playing it.

Why not talk about what you know and how you do things?

What does this mean? It means that there is a massive demand for talks that are coming from the unknown territory of implementation that is not needed for the big players. How did you clean up a Drupal driven site? How did you manage to sell new technology in a local government project? What does making an interface accessible really mean? How can we deal with old Android phones?

Instead I see an annoying effect of the “let’s impress people with technology” talks: a lot of upcoming speakers bend over backwards to write the awesome cool new talk showing an alpha tech product that makes “everything easy” instead of, well, crafting a presentation and talking about what they do and know.

Live coding, interactive examples and “hey this is not a problem at all” talks are highly successful. They can also backfire. Yes, you get the audience clapping, the oohs and aahs and the overly excited tweets. But you also get forgotten as fast when people realise that they can not use what you showed and that five other speakers at three of the conferences running in parallel pulled the same trick. And if you do it over and over again you “kill it” at the conference, but you also – in the long run – under-deliver as people can’t take home what you taught them and impress their boss with it. To me, this is always the main result I want to achieve.

The awesome that actually is a mistake in disguise

I see the search for the “Tech awesome extravaganza” talks be frustrating for a lot of people who are interested in presenting but feel inadequate to do so from the get-go. Which, of course, is nonsense. That’s like saying that there is no point in starting to run as an exercise as Usain Bolt will always be faster than you. What I see a lot is people making the following mistakes when presenting which do work when you are a seasoned speaker but are pretty disrupting when you are not. All of these are born out of the desire to be as cool as that talk that caused the loudest feedback, and we assume therefore to be the most successful.

• Showing too many examples – a lot of decks or outlines I get to review show five or more code examples to talk through. You won’t have time for that unless you rush. Either create one example and build onto that one – then five to seven steps can be easily done – or show two or three, tops.
• Introduce lookatme.js or iassureyouitworks.io – the solution to all of our worries. A lot of times these are abstractions of very complex, still evolving technologies in three lines of code with only five dependencies on other frameworks and libraries. Without your awesome solution having proven itself in a real production environment you are selling pixie dust. Even worse, you discourage the audience to give feedback to the experimental technologies you try to get people to use.
• Build the most complex thing ever and rely on stage tech – you will be offline, trust me, do not rely on wireless or 3G to be available. Also, bringing a lot of hardware and funky gadgets means you make the life of the stage technicians and organisers hell. You probably also will take too much time and make the presenter after you suffer for it as most conferences plan very tight hand-over periods in between speakers
• Meme overload – this is hot right now, and will make you look like a dork in a year’s time. Stay ahead of the fads, you are a professional.
• Minimalism – if your slide says a cryptic word and you are just showing live code at that time – call it demo and link to a code sample that will be available after the conference

You are totally invited to do whatever you want – I am not saying that any of the above can not work and be very natural for you. I am just saying that a lot of it can seem forced to comply with a current trend. And it can make you look like a fraud, or actually be caused by you trying too hard not to look like one.

We need all kind of talks, and the best I have seen and remember and keep telling people about and go back to several times are not the flashy ones. They are the ones based on lots of research, show solutions and explain why the solution came about. Tell your story, do not throw out confetti and hope it sticks and someone turns it into great novels and understandable books. Many great ideas die these days as a “perfect, small solution” is at their start that never gets taken further as it fails to deliver in production.

I am on my way back to England from Budapest where I spent the last two days in an epic hotel and the day speaking at the 10th annual Webconf. I was invited by the Mozilla community in Hungary, who did a great job showing off Firefox OS to the attendees. My presentation (one of the very few in English) was about HTML5 and how Firefox OS helps making some of its promises a reality.

The slides are available on Slideshare:

And as always there is a screencast on YouTube.

The talk was filmed, and the video should be released soon. All in all Webconf was a cozy one day conference with a lot of very interested attendees. As most content was in Hungarian – a language that seems base64 encoded to me – I didn’t get much, but it seemed the overall quality was very high.

It is not very often that I mess up completely, but when I do, I don’t give up easily. On the second day of Øredev I was scheduled at 1 in the afternoon to talk about Firefox OS and I thought I totally got over my jetlag (I arrived 2 days before from San Francisco). I got back to the hotel around midnight to be up early, have breakfast, go to the gym and be ready bright and bushy-tailed for my presentation after lunch. Guess my horror when my hotel room phone rang and I was asked where I was as my talk started 5 minutes ago. My mobile phone alarm did not go off for some reason and I had overslept about 6 hours! This morning I learned that I can brush my hair and teeth at the same time and that I can be on stage and ready to present in 10 minutes after getting up. I am terribly sorry and grateful for the audience waiting for 10 minutes and I still managed to power through the talk in 25 minutes. I am really looking forward to the video of this one as I almost lost my voice at the beginning. The audience reaction was great though, dedication does pay off :)

The slides are available on Slideshare

The Screencast is available on YouTube.

I am currently at Øredev in Malmø, Sweden, and this morning I spoke about “The very near future of a richer, standards based web”.

photo by Fredrik Frodlund

My talk covered new technologies people should be using to make them a reality rather than waiting for a perfect reality and full support across all browsers to happen magically. A screencast of the talk is available on YouTube.

One thing I mentioned in my talk is the great survey results by Visionmobile on Web competing with mobile. If you want to ensure more real data being covered in talks, please help them by taking part in their Q4 survey – it is 5 minutes of your time and you can even win some neat stuff.

Links covered:

• HTML5 for enterprise: Confusion the biggest barrier #AppsWorld
• How can HTML5 compete with native (survey results)
• Bell Centennial
• Solved by flexbox
• JSGIF Bookmarklet
• Irregular shape rollovers
• Image masking with Canvas
• The making of Face to GIF
• Google hangouts
• Together.js
• http://www.w3.org/TR/2012/WD-ambient-light-20120802/
• http://customelements.io
• Brick – Introducing Brick
• What makes a great app?

I am speaking tomorrow about Firefox OS at the same conference.

I just went to the Samsung Developer Conference in San Francisco and one thing in the goodie-bag was a book (paper, no less) on building apps for the amazing new Smart TVs they are bringing out. Exciting stuff, especially as the platform is HTML5 and JavaScript driven. When opening the book randomly though I found the following code:

Click for bigger

<div id="left">
  <a href="javascript:void(0);" id="left_anchor" 
     onkeydown="left.keyDown();">left</a>
</div>
<div id="right">
  <a href="javascript:void(0);" id="right_anchor" 
     onkeydown="right.keyDown();">right</a>
</div>

// left anchor event handling function
left.keyDown = function () 
{ 
  var keyCode = event.keyCode;
  switch (keyCode) 
  {
    case tvKey.KEY_RIGHT:
      jQuery('#right_anchor').focus();
      jQuery('#right').addClass('focus');
      jQuery('#left').removeClass('focus');
      break;
    default:
      break;
  }
};

I do understand that a SmartTV is a defined environment and there might be things that work better when you do things in a certain way, but I am really hard pressed to see any reason why anyone in 2013 would write JavaScript and HTML like that unless what happened is that we keep copying old code without thinking of the impact it has.

There is a huge movement of teaching people to code. Great startups like Codecademy, Codecombat, Codewars and many, many more use the web to teach people how to build things for the web, how to grasp the concepts and logic of code and how to write it. On the other side of the coin we have implementation guides that ride roughshod over everything we learned in all the recent years we used web technologies for the sake of writing a very “easy to understand” hello world example or “keep the code short”. This is not helping, all it does is perpetuate the prejudice that the web is not a professional environment to work in and instead it is OK just to copy and paste something and change some function names as long as the browser understands it.

We got into a world of copying and pasting solutions that work without caring at all about the effects they might have. This is unfortunate, seeing how JavaScript has become a first class language, or as Shinetech put it in their excellent “Respect the JavaScript” post:

It is the only runtime language I can think of that will run on any modern processing device. It’s ubiquitous and the ecosystem has evolved beyond what anyone could have imagined, with many implementations (Rhino, V8, now Nashorn) and it’s very own matching server-side equal, node.js

So, what is so terrible about this code? Chris, why are you such an arrogant bastard in your web standards ivory tower punishing people who just want to write code and release products quickly?

Call me old fashioned, but I don’t like waste. I also don’t like when people use things without understanding the consequences. Our goal should not be “it renders, therefore it must be right”, instead it should be “this is clean, extensible and it uses various technologies benefiting of their different strengths”.

Use the wrong element, then make it work?

So what’s wrong here? The first glaring, utterly useless and bloated mistake that does not seem to want to die is links with a href attribute of javascript:void(0) (I lamented about this in 2005 in Six JavaScript features we do not need any longer).

A link is there to point to a resource. That’s what we defined them for. If you don’t point to a resource – don’t use a link. Much like you don’t use an H1 when you want to define an INPUT, although modern JavaScript and CSS are perfectly capable of making one act like the other. It does not make sense though, which is why you don’t do it. So why use links with href attributes that are long and – by definition – don’t do anything?

If you want something that is focusable, can start a script when the user interacts with it and is both keyboard and mouse accessible, use a BUTTON element. This is what they are for.

Add an ID, then you can access it easily?

The next problem is the use of IDs on the parent element and on each button. It is simple to define a button with an ID and make it styleable and accessible either with getElementById() or querySelector() but it also means that this is a unique thing in the whole document. What if you want more than one button that enables navigation to the right? You need to add a different ID and check for that one in the code. This is wasteful and limits the extensibility of your interface.

Using IDs is simple, but it means that you create a unique element with unique functionality – are you sure you won’t need to repeat the same element at a later stage?

Everybody in line

The next massive issue is the inline event handler on every single element. This seems to be special to the SmartTV platform – the API emits a key event that tells you what key was pressed on the remote control. In essence, all you would need to do is to assign one key event handler to the whole document instead of lots of inline handlers to every single control. This is not only wasteful and mixes HTML and JavaScript (remember, we do work in a pure JavaScript environment here), it also means that you are very likely to repeat the same code over and over again for each control rather than writing a single handleKeys() function that can be activated by various controls depending on what view of your application you are.

If you use an inline event handler on an HTML element you make debugging harder, you make it much harder to refactor code (as function names need to change in your JS and in each HTML documents) and you are very likely to write code that repeats the same functionality in different listeners.

This actually happens in this example as on the next page the right.keyDown method is a copy of left.keyDown with the only difference being the shifting of focus and class names.

Goldfish code

The next bit that is worrying here are all the jQuery calls to get references to elements to set the focus and to remove and add classes to. First of all, hey, we have a jQuery dependency here, why didn’t the rest of the code use jQuery for the event handling? Secondly, why all the repetition? Every time you access the DOM you slow down your app. We know these elements, we gave them IDs to ensure that we know them. That’s why asking jQuery to find them again for us every single time an event is dispatched means your code has the memory capacity of a goldfish (and uses a lot more memory). If you can, always cache elements in variables to avoid yet another DOM lookup. Simple caching like this goes a long way:

/* Navigation buttons */
 
var navright = document.querySelector('#right');
var navleft = document.querySelector('#left');
var navup = document.querySelector('#up');
var navdown = document.querySelector('#down');
 
// from now on use navright, navleft, navup, navdown
// this also means you can rename the IDs later without
// having to hunt all your code for them!

Unnecessary shifting of classes

The last obvious issue here is the shifting of classes from the left to the right. The problem with this is that if you were to add more buttons you’d have to add them to the method as you right now do not know which one was activated. This means you need to either add a “remove class from x” line for each button or write a loop over all buttons removing the class before setting it to the current one. This is a very common and simple to rectify mistake.

First of all, there is no need to set a class to an element if you want to highlight it when it is focused. Setting an active and focus style in CSS is enough (as shown here).

button {
    display: block;
}
button:active {
    background: green;
}
button:focus {
    background: green;
}

But even if you need to set a class to the currently focused element, there is no need to loop through all the others at all. Again, the trick is storing the current element in a variable and remove the class from that cached element:

var current = null;
document.body.addEventListener('click', function(ev) {
    if (ev.target.tagName === 'BUTTON') {
        if (current) {
            current.classList.remove('focus');
        }
        current = ev.target;
        current.classList.add('focus');
    }
}, false);

The code as it stands here does a different thing, agreed, but the solution is still clunky. Instead of repeating the same functionality in each handler, the better way to write this would be a setfocus() function that takes the new element to focus on as a parameter and removes the class and the focus from the current one.

To conclude

All in all, I am really disappointed to see code like this in a brand new book about bleeding edge technology using JavaScript. This is not by design, this is plain and simple laziness and bad editing. JavaScript has become incredibly powerful and is used in a lot of cases for business critical functionality. In a closed environment like a SmartTV there is nothing at all wrong about that. What is wrong though is educating new developers to write code that was maybe needed to support IE4 or Netscape2 and even back then was the lazy and hard to maintain way of doing it. If you write some instructions or tutorials, please, for the sake of the quality of the next generation of developers:

• Don’t use any inline handlers or javascript: pseudo protocol URLs. You know they are a terrible hack – if you don’t then generate your HTML in JavaScript and keep it cleaner that way.
• Limit DOM interaction to the barest minimum – it slows down your App
• Don’t loop when you can store – if you need to shift a focus around this means you need to know the last “active” element and the next one to focus. There is no need to loop over all elements in a group.
• Extensibility is key – if your script is limited to a defined number of elements and repeats them in event handlers, you cause terrible maintenance code.