When bad things happen, people look for a scapegoat. When a government is threatened it tries to analyse what happened and find a quick solution that gives people hope and shows them that those “up there” are in control and can protect us from evil. In the last few days the United Kingdom burnt, got looted and the next generation of citizens to build the future of this country were the people doing it. Others stood by, too shell shocked to realise that mere presence and a “what are you doing, stop this” could have prevented a lot of the damage.

A lot of further damage was prevented as people organised themselves, communities kept close together and stood their ground. People learnt first-hand from Twitter, Facebook, Text Messaging, emails and phonecalls what is happening, when to board up their shops, where rioters are and what is happening. Of course there was a lot of speculation, but so was in the news. The official BBC news channel during the riots had a few false positives and wrong locations and names of burning buildings. Communication errors happen – if the media is swift enough they can also be verified very fast and sorted out.

The police, the courts and the government have done incredible work to stop the mindless destruction and violence – and that is what it was – this was not an organised terrorist attack, it was pure pent up anger and frustration of not having a prospect of a future in a world where you get bombarded with messages to consume more and think less.

Now the government is starting to misunderstand the opportunity communication systems pose for doing good and keeping information flowing. If you keep people in the dark, they assume the worst. We are conditioned not to assume “all is fine”. Deep down in our subconscious we fear to get eaten by some vicious animal as soon as we go out in the dark and that makes us scared, defensive and ineffective to do good.

When David Cameron talks about a clampdown and “banning rioters from social media” I get scared. I am scared to pay tax and support a government that has not a single clue how the new media that its citizens use every day works while spending millions on funding “IT innovation programs” and “enticing UK entrepreneurs to show technical excellence”. Social media is branded a scapegoat and a big part of why the riots happened and why the police was less effective than they could be. The government and old school media conjure a scary image of social media being a free flow of information that is not governed by anyone and is not controllable and therefore a threat and a playground for evil doers to organise themselves much more efficient than the law enforcement agencies can.

There are so many wrong arguments in this, it hurts me even to think about it. Regardless of the technical impossibility to “block people from social media” – which assumes that people only can have one, fixed identity there (guess what, I can buy a £10 pre-pay simcard and I have a new identity) the quick solution proposal to shut down social media access completely misunderstands the concept of social media – it is a massive group of people!

Social media is an incredible evolution of media. Instead of waiting for news to be written, organised and honed to instill one reaction or another (and this is what a lot of our media has come to) it means a free flow of information. This is scary to some but to me it means that it empowers everyone to chime in, make up their own mind and speak up when things are wrong. This has always been the case on the web. I spent a long time of my life on IRC, as an admin and I kicked, banned and told people off for spreading hate or soliciting illegal behaviour. Wikipedia editors spend a lot of time deleting articles that are wrong or politically incorrect. People contact admins to delete content or solve issues or investigate the behaviour of users. We do police social media by being part of it. That the government has not understood embracing a new media and do the same hurts me. Your citizens message each other and talk to each other – when I see official use of social media all I see is a news feed being sent out to a different channel. Using social media efficiently would safe the government money, time and make it appear approachable and human rather than an entity that is far removed and won’t understand us anyways.

My city burned, my country (yes, I have been here for 10 years and I do consider it my country) is shell-shocked that a few kids can take over and destroy people livelyhoods and make us scared to go out in the dark. This is not because they organised themselves with Blackberries and Twitter – this is because the government has failed to listen and people have lost faith and respect for those in charge.

During the riots I didn’t sleep much. I was on every social media channel, taking in information, comparing with the mainstream media reporting and seeing what is going on. I was on my balcony and out talking to shop owners. I tip my hat to the people on the london-journos Twitter list (especially Paul Lewis who followed the riots up-close and gave information from the streets), The West Londoner, Birminghamriots and ##londonriots on freendode (with David Singleton doing a great job keeping rumours in check and keeping people stating information rather than their political view).

Social media is now used for good – much more swiftly than any other channel. I was amazed by the swift organisation of #riotcleanup and the picture of brooms in the air still makes me choke. As does the courage of the lady telling rioters off for destroying their own neighbourhoods. I love how it was people on social media to propose sending money and help to Ashraf Haziq and others before newspapers thought of it.

Even the police uses social media right now to find the rioters – Flickr groups ask you to identify them and they name the rioters on Twitter.

There are so many issues to fix right now. Calling the riots a wake-up call would be the understatement of the year. Maybe the rioters were organising themselves, maybe there is a big, evil orchestration behind the madness. It does not matter, because if we now concentrate on silencing people instead of listening and understanding their needs, then we fail even more as a society and as a sophisticated, first world country. Countries who have to rule with fear and silencing their citizens are those we accused of doing wrong in the world courts and in some cases invaded to “liberate”. We should now liberate ourselves.

For years our media has painted a picture of young people to be no good hoodies who are more likely to stab you than to talk to you. Cheap, emotional headlines outcasted them as leeches to the system and unwilling to work and be a good citizen. This made people scared of confronting them and even communicating with them. This has to stop. We faced a total breakdown of communication. These kids felt outside the law, outside of society and invincible as they have nothing to fear and in some cases nothing to lose. We need to understand them and fight the causes that drove them into this thinking.

For us, as the privileged people on the web who have the luxury of debating for hours which technology is best to rotate a logo I think it is time to show this government why a freeflow of information is a damn good thing.

• Our job right now in the UK is to show with hard evidence that communication systems like social media helped to prevent damage
• Our job is to show that social media is more than celebrities, advertising and organising illegal activity. It is extremely effective as a means to give out information and get feedback – if you use it right
• Our job is to convince the government that informed citizens are citizens who can act and prevent bad things from happening

Let’s use the power we have at our hands to help the police and government do their job. Let’s stop soiling an amazing opportunity like Facebook, Twitter and Google+ with mindless trolling and hatred and ignorance. Let’s be social on the social media, rather than opinionated. Let’s collect positive things about social media and show them to traditional media and the official channels of the government. Let’s stop telling people how much money Zuckerberg made without going to uni and how many millions are spent on buying products that make it easier on the web to buy other products and instead share knowledge and show that the web can be an amazing opportunity for learning and sharing.

I love the internet, I love being able to get information and have the freedom to make up my own mind about it . I love getting raw data which can be turned into facts after verification. I don’t want to wait for information till the news is out or the paper is printed. This is 2011. Media has to move on – if governments and media professionals do not take part it will without them anyways. Ever since the first pamphlet has been printed people realised the power of distribution. And we have an immediate, world-wide distribution right at our fingertips. This can be used for good or it can be used for propaganda and organising crime. I believe in people and think if we stop concentrating on consumption and instead on sharing information, educating people and understanding the background before passing judgement we are on the way to a better society.

This morning I was invited to the ITV offices in London, England to give a bit of information about hackdays, running them and participating in them. ITV are planning a big internal hack day and wanted to know what mistakes to avoid.

The slides are available on Slideshare:

Notes:

What makes developers happy?

• Delivering something
• Getting recognition for your work
• Solving problems
• Learning something new
• Finding ways to improve things

Our dis-comfort zone and how it holds us back

All of this is pretty hard to do in our day-to-day work as we are caught in a cycle of delivery that takes up all of our time. Hardly any company leaves free time for their developers to use as they please and it is hard to make that measurable. It is also very hard to innovate when you are very close to the subject matter as you tend to see more problems to fix than opportunities to extend existing products. We sometimes can’t see the wood for the trees.

Hackdays are an opportunity to leave our comfort (or dis-comfort) zone – for 24 hours we can leave the day-to-day grind behind and go nuts playing with processes, systems and technologies.

Hackdays mean you need to focus and you can reach out

• Take 24 hours to build something new – limiting yourself means you need to focus on the bare necessities and do the most important things first
• Disregard all the protocols you have in delivery – this is your chance to deliver something without worrying about the paperwork
• Collaborate with people you haven’t worked with – as everybody is out to play for the day this is a great chance to get to know each other and learn about the pains of other departments
• Deliver a working prototype and explain what you want to achieve with it – let the code and the design and the work talk for you
• Prepare a damn good 60 second pitch – a skill that you will find makes meetings easier for you later on

Why take part in a hack day?

A big mistake people make is to think that hack days are there for the company and for your boss to test you and/or shine with what you are producing. If that is the case, then your company is doing them wrong. First and foremost hackdays are for you:

• Show off what you are interested in – no matter how geeky
• Learn something new – is there a technology you always wanted to play with?
• Get out of your shell – partner with people with complimentary skills and give a great pitch.
• Release something on your terms and without waiting!
• Show that if your manager is not breathing down your neck you can release awesome in no timw

Scratch your own itch

First and foremost you should always find something to hack on that you are passionate about. Scratch your own itch – don’t try to impress others by hacking on something cool or currently hot for the company. If you don’t believe in it, your pitch will be bad and you will feel like a phoney.

The awesome that is hackday can leak into day-to-day operations

Sometimes the outcome of a hackday can affect day to day operations in a very beneficial way:

• Write a tool to make a day-to-day process more efficient
• Show that by using a certain tool or technology you can deliver something very quickly
• Make the first step to learn that skill you always wanted to have but always pushed further out
• Show that your department can innovate and deliver
• Join a community outside the company

Deliver, don’t plan and talk

Hackdays are all about the delivery – we can (and should) talk about the hacks once we are done.

• Don’t bother building the best thing ever
• Concentrate on one thing and deliver a working prototype
• Steal, borrow, cheat… whatever it takes, get the message across
• Start something – make the code available
• If the hack works only on your machine, also create a screencast (http://screenr.com rocks for that!)

Use whatever tool you need

Whatever makes you a good deliverer, use that. You have 24 hours and we want to see things working (at least as a prototype).

• Open technologies make it easy to build prototypes (HTML, CSS, JavaScript)


• Use libraries (jQuery, Google Visualisation libraries, d3.js, raphael.js…)


• Use APIs for data and conversion (programmableweb.com)


• Find APIs to do time consuming jobs for you (vid.ly for video conversion, YQL for data mashing)

The more you can re-use and connect with each other, the less you have to write (and later on document) yourself. Simple, really.

Prepare your pitch/delivery

When it comes to delivering the pitch of your hack there is no time for foreplay. Go straight for the jugular:

• Show what your hack does
• Explain the effect this has – why is it a cool hack?
• Give ideas where this can go and how the company could benefit from it

What about after the hack day?

Once all hacks are shown, the voting has been done and the winners announced, all the pizza eaten and all coffee and drinks consumed it is time to reap the rewards of the hackday and use what has been shown for good. For this we need you to prepare a bit.

• Have your hack as a package for people to show around the company (screencast, screenshots, working code, 3 sentence pitch). This allows managers to show your hack to product managers and get it into production. If your hack is a non-working link, that can’t be done. So move from localhost to somewhere the world can see what you did.


• Keep hacking on it (freetime or ask your boss to get some extra time)


• Demand follow-up from your company! Keep pestering people for feedback and statuses on what happened to the cool hacks you saw. This is not for a day – innovation needs support

What I want from a hackday in a TV company

As you are all about the moving pictures I’d love to see some hacking with open video and standards. All the stuff I will cover here is documented and can be amended at http://developer.mozilla.org.

We lately had a competition about open video and there were some really cool entries you can look at and you can download the source codes as inspiration:

• The video effects demo shows a scene from Jurassic Park and changes the look and feel of the video container itself according to what is happening on the screen
• The scene detection demo recognises when the movie changes drastically and creates screenshots when it happens
• The Add Track demo shows how a subtitling interface can look like in HTML5
• The Facial recognition and analytics demo allows annotation of videos by detecting people in them

Furthermore there is a lot of documentation on the subject available:

• I gave a guest lecture at MIT on multimedia and the web with lots of examples and links
• This interview with John Foliot of Stanford university has a lot of great ideas on video and accessibility and what still needs to be done
• Popcorn.js is a JavaScript framework that makes it easy to connect multimedia and in-page content. A great use case example is the Minnesota public radio site connecting audio and a transcript for navigation. If you don’t want to code, popcorn also has an app interface called Butter
• universalsubtitles.org is a subtitling and translation solution for videos – simply add the JavaScript to the page with the video and the rest happens automatically
• Audio sync is another demo of connecting transcripts and audio
• Both Mozilla and Chrome now also feature Audio APIs to deep-dive into the sound files on a byte level. If you have that much control you can build awesome things as the fully functional DJ deck using web technologies shows.
• If you want to access the camera or the microphone of a computer in your hack, check out Mozilla Rainbow which features a simple API to do so

Things that made me happy this morning (much like this wombat)

• The current landscape of social media
• Why not offer some grammar tests as a CAPTCHA (yes it will weed out all the YouTube commenters)
• These Tetris cushions might be a scam – if you arrange them the right way they vanish and you got to buy new ones
• The evolution of the Hipster explained
• Google and Mozilla are working on Web Intents, a simpler way for apps to communicate with services and each other (detailed blog post)
• Linux Outlaws recorded a podcast on open web and Mozilla with me
• Yahoo finally updated their web media player
• Be the first of your friends to like this post is clever
• CSS transitions without using :hover explains a few other pseudos
• Prickly Fluff alert – check out this gallery of baby hedgehogs on Facebook
• P2PU is hiring – if you want to help people learn about the web, check these job offers
• jQuery Fracs makes it easy to find out what is currently visible in a page

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:

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:

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

  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:

Please enter a number

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 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.

Original 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.