Disclaimer: While I work there this post is on my personal blog and does not necessarily reflect the opinion of Mozilla. Feedback bickering about how Firefox fails to meet your needs will be blocked out by me by means of looking at cute pictures online (this one for example which kills me every single time). Thank you.

“What should a browser do to really make you more effective and allow you to build great products?” is an interesting question to ask. I’ve asked it a few times in different environments and I got a lot of different answers. When you dig deeper and ask for details why browsers need what people wanted it gets interesting – most of the time they can’t say why.

New toys with older and better implementations

In many cases as developers we want new toys, we see a cool experimental feature in one browser and want that, right here, right now, regardless of its usefulness.

Many of these hot new and cool features in browsers have been in Flash and implemented in a more flexible way so to a degree, we still play catch-up. This is annoying as we could have learned from what Flash gave the web and how it moved it ahead (yes, without Flash we would have no video, audio or gaming on the web, let’s face facts) and copied and enhanced instead of going on a parallel innovation stream.

A battlefield with not-so-hidden agendas

In addition to this urge of wanting the new and shiny there is a need for some companies to sell their browser and get mindshare of developers to point them to their other products. This results in a browser battlefield that tries to impress with cool and new rather than building a predictable and stable platform. Granted, this is mostly the impression you get through marketing materials and not talking to the browser engineers, but, for example, I don’t see any of the players making a real effort to get all HTML5 input types supported and style-able – a need we really have as forms will not go away any time soon.

Regardless of the lack of support for a few of the basics in HTML5 when it comes to moving browsers forward I think the main feature we need is feature testing APIs in the browser. What do I mean by that and why do we need them? Well, here goes.

We need native feature testing

Web development always came with a choice:

• Do you want to use a feature and demand that your users have the ability to consume it and risk broken experiences or
• Do you want to test before you use a certain feature and give it only to those who can consume it?

The former are the sites that come with disclaimers like “this web page feature $x and needs a modern browser like $y” and can look extremely silly a few years down the line. The latter is what we call progressive enhancement, giving everybody what they can deal with and not more. There is also an unhappy middle ground called graceful degradation, which means you build something with all the features and a fallback solution and hopefully maintain both.

If you go for the progressive enhancement approach you need to provide several solutions or you need to test. The several solutions approach for example would be to ensure you do not have a button with white text on white background by providing a fallback background colour for browsers that don’t render gradients:

button {
	color: #fff;
	border: none;
	/* defining a background colour for all browsers */
	background: #0c0;
	/* defining a gradient for those who can */
	background: linear-gradient(0deg,#000, #0c0);
}

This is not much work and should be easy to do for everybody (that there are a lot of buttons with only webkitlinear-gradient backgrounds is baffling to me). It gets harder though when you want to use more advanced features.

Testing mechanisms

What we want to do is to test a feature before we apply it. The worst way of doing that is by trying to detect the browser and make the assumption that it really is the one you are targeting and that it can do what it promises. Reading out the user agent string of the browser is the standard way of doing that and let me just tell you now that this is where madness lies. Forget trying to detect the browser, they will lie to you and you lock yourself into an ever-changing game of hide and seek with new browsers coming out all the time.

The more robust way of testing is feature detection, you plain and simply ask the user agent if it can do something before you apply it. This could be as simple as asking if navigator.geolocation is an object before trying to call its methods. This can result in a lot of code though and there are browser quirks to consider, which is why we have to be very thankful for the people who build and maintain Modernizr to do all that work for us. Using modernizr we have handles in the form of class names on the root element and a very handy JavaScript API to test for features and under the hood it checks thoroughly and forks for several browser quirks – pain we don’t need to inflict onto ourselves.

To me the existence and success of Modernizr shows that there is a massive need for being able to test features in browsers before applying them and getting a definite answer back. This is where browsers don’t do too well yet.

Native testing mechanisms

As shown with the background example our native testing in most cases just means applying things the browser might not understand and rely on it skipping the bits it doesn’t know about. This works in CSS, as CSS doesn’t throw errors and stops executing. JavaScript, on the other hand, does.

CSS is doing a lot in that respect at the moment. Media Queries, for example, are feature detection mechanism. I love that I can apply a style only when the browser window is a certain size or in a certain orientation. It is simple and works. More of that.

Well, funnily enough there is more already. The current Opera and Firefox Aurora support the CSS3 Conditional Rules Module Level 3 which means you can test for CSS features with an @supports block:

@supports (-webkit-transform: rotateX(0deg)) or
          (-moz-transform: rotateX(0deg)) or
          (-ms-transform: rotateX(0deg)) or
          (-o-transform: rotateX(0deg)) or
          (transform: rotateX(0deg)) {
 
  // this will only apply to browsers with 3D transforms
 
}

This also comes with a JavaScript API to test for features whose syntax is still currently discussed. You could end with window.supportsCSS('display:flex'); or CSS.supports('display:flex') respectively, but still the power of this idea is staggering and it could mean Modernizr would be not needed in the future (or a lot smaller as we could for @supports and lazy load the rest of Modernizr only on demand).

If you want to learn more about @supports check Chris Mills’ Native CSS feature detection via the @supports rule.

Pointers in the right direction

All of this makes me hopeful that the next generation of browsers will give us developers what we really need: a way to test that what we do can be applied before we do it. Right now we need to spend far too much of our development time on adding polyfills and libraries to test for and – if needed – simulate functionality we should be able to just use. A great case is touch and mouse support in browsers which right now is not fun to apply which is why we do have to use libraries like pointer.js.

Fact is that we will never have one browser and one environment for the web. That would neuter it and violates its main principles. We can dupe ourselves into believing that we can control and demand what our users take to look at our products, but this is a fool’s gambit. Hundreds of web sites and enterprise systems out there demanding you in 2012 to use Internet Explorer 6 to get the best experience should teach us that this is a mistake not to repeat.

The much more likely future is that we will have to have a much more diverse environment to support. The web design community is already harping on about that for quite a while under the Future Friendly label. Seeing the amount of smartphones, tablets and web-enabled TV sets and game consoles out there it is not hard to grasp that testing and being flexible in our approach of web development is the future indeed.

Native testing for all the things!

What’s happening in CSS is encouraging, we need to move that idea further ahead. Some other parts in browsers less so. For example when we got native video we realised early on that it would be great to have a feature test for which video formats are supported. I agree, this is very needed indeed, but getting an API that returns “”, “maybe” or “probably” is a joke and not a helpful addition. On the other hand the Page visibility API and its under-the-hood implementation in requestAnimationFrame is a wonderful addition and exactly how it should be. I can ask the browser if the user sees what I do and if she doesn’t it stalls until it needs to animate again. The WebAPI work of course is also very encouraging – we just need to get them supported cross-browser.

Retina displays and their need for large (by dimension and file size) images are the big new issue. Should you add large images and risk people on a mobile device with a small screen burning through their data allowance plans or should you risk a blurry view and load larger files later on demand? When on demand though? When the display really can show larger images or when the connection is fast enough to load them?

Right now there is no way of detecting the speed of a connection and if it is OK to load lots of data. PPK is doing some research to see what that could look like and it is not easy. But we need that, I am not kidding here. Simply assuming people can load lots of data is not delivering a good service.

Quick example: I got that a lot on my blog when I embedded HTML5 videos. I thought this is a good dogfooding exercise but got feedback that I should switch back to YouTube embeds as their Flash versions delivers lower quality streaming versions of the video to people on bad connections. HTML5 video doesn’t do connection negotation yet (which is a dirty hack of chunking a video into 4k bits and sending as many as possible at a time). So in order to deliver a good service, I needed to go back to “closed” technology as I had no means of testing if my readers can consume what I gave them.

We push browsers to their limits these days and we don’t get much feedback as to what is possible. Say you do a massive CSS animation with complex transitions, drop shadows and transparency. How can you be sure this will be smooth and not an annoying flickering slide show experience? Imagine a browser telling you the FPS it runs the animation on, imagine – even better – that it would have an internal threshold to stop animations and automatically move to their end when the browser is too slow (something YUI had for quite a while now).

There are many things we need to be able to know in the nearer future, and I wish browsers would add a few of those testing features:

• What is the connection speed/reliability?
• How busy is the machine? Does it make sense to start this animation or will it be laggy anyways?
• What is the battery status? Should my app offer a low-level experience to be alive for longer?
• Is the audio/video channel of the machine busy already? Why play a sound when the user is listening to music anyways?
• Are there already fonts available or do I need to load a web font?
• Can I store content locally and what is the quota already used up?
• Is this a touch device with gestures or a kinnect or a mouse-enabled device or what?
• What codecs are installed, what media can be played?
• What is hardware accelerated and what isn’t?
• Is the browser talking to an assistive device layer and what assistive technology is in use?
• What is going on in the browser cache?

A lot can be added to the list and I really hope that browser vendors understand that we can only work effectively if we have the right tools. Right now I feel we need to resort to libraries, polyfills and shims for far too many things. Which might be an alternative future, but I for one would love the browser to do that work for me so I can concentrate on building apps running in it.

Yesterday evening I gave the closing keynote of the HackerNews meetup in Old Street, London, England. I joined about 200 developers, lots of empty Pizza boxes and beer cans to as them to “Keep calm and trust HTML5”. Here are the slides, an audio recording, the notes and a screencast on YouTube. The video of the talk should be on Vimeo in a week or so is now available on vimeo.

Chris Heilmann – Keep Calm and Trust HTML5 from HN London on Vimeo.

You can get the audio at archive.org as MP3 (29.6) or OGG (16.1MB).

Notes

The honeymoon period of HTML5 seems to be over and as developers we seem to feel confused and wary of the hype about it. Instead we compare HTML5 with the other booming tech and wonder if it really is something we should put our efforts in. In this talk Chris Heilmann of Mozilla will cut through the hype, show what’s ready to use and around the corner and help you do your part to make HTML5 work without adding to the confusion.

Today I shall attempt to set your mind at ease about HTML5 an whether you should bet on it or not. Spoiler: you should. Another spoiler: you are not forced to.

About that HTML5 thing…

HTML5 - like any other new technology – follows The hype cycle. We are past the inflated expectations stage and are going down into the trough of disillusionment. This is good, it means that we can concentrate on making the technology work for us rather than coming up with impressive made-up facts around it.

A lot of the players in the HTML5 space have spent an enormous amount on impressing people with shiny demos of new technology and “pushing the envelope of what we can do with the web”. A lot of them were pointless and even more were scarily similar to the things we did with Flash in the past.

A depressingly large amount of those demos only work on a certain browser with a certain setting and tell users that they should download that one. This is a product marketing ploy but very much hurts the web. HTML5 is not about telling people what to use, it is about giving them the best experience in the current circumstances. For developers it means upgrading what we already do on the web and giving it more predictability.

A lot of the demos we see are beautiful, but heavy and expect a lot from the machine they run on. That’s not good. Of course it is great to give a beautiful and rich experience to those who can consume it, but our mistake is that we see them as a given rather than working towards them and giving less rich, but delightful experiences to others.

The other thing we very much do wrong when it comes to HTML5 is to simulate the native environments. We try to make HTML5 apps behave like native apps and wonder when this doesn’t quite work out the way we want.

Catering to a hipster market…

A lot of the work in HTML5 we right now is trying to cater to a very current market. Pascal Finette just explained in his blog post “The False Economy of Apps” how little closed app markets allow developers to earn and what the issue with them are. App markets are hot right now and there is quite some hype about it. The problem with hypes is that they happen very fast, so if you want to play that game, be quick about it or your opportunity is gone.

A new market…

The amazing thing is that the next market is already around the corner and it is interesting. According to a presentation by Anna Debenham at the Full Frontal Conference, teenagers in Britain are connected at home to 95%, but only 10% own a Smartphone. 46% have a mobile phone and 44% an own computer.
Of the teenagers involved 69% have a handheld console and 86% a games console connected to the TV. This is where a lot of them surf and consume the web. Given the constraints of these devices this will become interesting indeed.

The web is ready for it!

This is where the web comes in. Instead of having native apps on these devices and the next to come (cars, toasters, connected furniture?) we can build apps with web technologies that easily adapt to the new needs of the device.
My former colleague Mike Davies put it quite succinctly in the “WebApp mistakes we are condemned to repeat” article lately that the main power of the web is that it is not dependent on any platform. This allowed it to survive quite a few that came and went already:

The Web is platform agnostic, its success isn’t chained to the continued success of a specific platform.

Another great point he made is that we try to simulate widgets and interfaces that are native, and thus build interfaces that promise a lot but fail to deliver the same way native ones do. Instead of using what is there we shoe-horn another environment into the one we play in. Instead, we should embrace that there are differences and deliver different experiences according to the device and browser in use. An Android device should not get something that looks like iOS and feature a back button that does a different thing than the one the OS gives us.

This platform independent characteristic is a feature of the Web, not a shortcoming. It’s not meant to emulate Operating System graphical widgets. That’s the browser’s job (or the operating system’s job), not the web stack’s.

But isn’t that fragmentation? Doesn’t that mean we need to build lots of different versions for different browsers? Won’t our app look different from browser to browser?

No, it is the internet experience! The internet is there to participate, people should not be be blocked out because of their environment or ability. This always meant and will always mean that people have different experiences on it. And that is good. Why should we force everybody to have the same experience when they can have a better one or one catered to their needs?

The cutting edge will hurt you!

Disappointment comes with the territory when you live on the bleeding edge of any technology. The same happens with HTML5. A lot of initial messaging promised us that everything is simple and just works when it clearly does not. Again, this is to be expected. We are experimenting here.

Here’s the thing: the web as a platform revolution is happening – no matter what. Browsers are performing better with each version and there is a new version every few weeks. You can enjoy that and reap the rewards or complain about a currently annoying and broken thing for months. Probably by the time you calmed down it will be fixed and you realise that your energy could be spent more productively.

If HTML5 is not you, that’s OK…

If you don’t want to be part of the ride, that is totally fine. There is space for all of us on the web. Build native apps, stick to one environment, make money, be successful. But don’t waste everybody’s time by comparing apples and oranges. It is possible to sell your services and products by badmouthing the alternatives, but is this really how you want to live your life or sell yourself as an expert? Sounds like a waste of effort to me when your creativity could speak for yourself.

It is not that complex…

All in all it is not complex to start with HTML5 and having success. It might not be as quick as it is in a closed environment, but it is very much likely to be more rewarding in the long term.

So if you want to get started with HTML5 in a relaxed and sensible fashion without the hype and the hate here are a few things to remember and a few to check out.

Five HTML5 mistakes to avoid in 2013

I was asked by .net magazine to come up with five HTML5 mistakes to avoid in 2013. Here they are.

• HTML5 is not “building for iPhone” – The web is littered with web sites and apps that only work with Webkit browsers as they rely on functionality that only the iPhone provided. Granted, it was the groundbreaking product to get HTML5 off the ground, but now others have emerged that play nicer with the standards, perform very well indeed and also need support from you. So stop sniffing user agents and provide non-webkit prefixed, standards-compliant fallbacks to whatever you code and you’ll be smiling when the next killer product not backed by Apple comes out.
• HTML5 doesn’t mean “write whatever” – The HTML5 parser is amazing and allows you to do incredibly random things in your markup and still get a predictable outcome. You can omit closing tags, there is no need for quotes around attributes and many other things that were considered bad in the past. The reason why the parser is so lenient is that there is a lot of bad and broken code on the web and new browsers should not punish users for our mistakes of the past. Let’s not make new mistakes to add to that landfill. What the browser displays should not be your guiding principle, what the person who maintains your code gets should be.
• HTML5 has to work offline – The main opportunity for HTML5 lies on mobile devices and in the app space. Apps have to work offline – period. Build a small shell for first load that gets the rest of the content on install and store it offline for later use. Yes, AppCache is bad and could be very much improved, yes, we have browser differences with IndexedDB and WebSQL. These are temporary issues though and we can only fix them when people use them and report issues. So go offline and don’t expect a great connection every time people load your HTML5 solution.
• HTML5 should be mobile-friendly – A lot of HTML5 and responsive design showcases look like Flash pages a few years ago, except that they are heavier and don’t support streaming content and connectivity negotiation like Flash does. We should move to a leaner, “use what you need” approach rather than simulating the richness of Flash without having the same opportunities. We got tired of Flash loading animations – doing them in Canvas doesn’t make it better.
• HTML5 can adapt – let’s allow it! – Last but very much not least – let’s move past the “demo” and “showcase” stage with HTML5. A lot of of what we call HTML5 expects a certain browser in a certain setting and shows off what could be done. “Could be” is over, we now have to deliver if we want to be a serious alternative to native solutions. HTML5 can deliver a sensible experience to all environments and a beautiful one for the high-end. Let’s deliver that instead of a high-end experience for a few who care enough to alter their browsers and are on the bleeding edge.

More things to know

Here are some more things that help you keep your sanity when plunging into HTML5 development.

• JavaScript is here to stay, learn it! – JavaScript is the language of the web. It is a weird language, but powerful. Go and learn it. Yes, jQuery is simpler, and Coffeescript more structured, but when push comes to shove and you are on a very restricted piece of hardware you need every bit of performance you can get.
• Don’t rely on experimental features – A very dangerous thing we do right now is to rely on experimental features with browser-specific prefixes in our products. The idea of browser prefixed features is to test them out and find a consensus in the end that lives without the prefix. Prefixed functionality will not only go away really soon, it will also change constantly. You can not rely on it. Give anything a fallback that works in legacy browsers and use the non-prefixed version. That way you can test new features and you don’t have broken code when browser un-prefix the feature in the very near future.
• The browser is developer environment – The missing HTML5 developer environment people coming from native environments bemoan is here – we call it a browser. All browsers have developer tools, many even have remote debugging for phones. This is where it will happen. And it makes sense, as we debug where our users are.
• Build in HTML5, render natively – The fun bit about HTML5 is that you can create native apps from it using PhoneGap (and many others). This means you can reap the rewards of having an app that can be found on the web and you can submit it to the closed markets, too.

This is not new either. As mentioned by Mike Davies in his latest post about web apps, we’ve been building installable apps with XML, CSS and JavaScript for quite a while – Firefox being one of them.

While webapp ninjas complain about their tools and environment, entrepreneurs create these applications with the web stack. – Mike Davies

Splendid stuff in the making

But that’s not all – there is a lot of great stuff happening right now.

One big annoyance of HTML5 on mobile devices is that we don’t get access to the hardware from JavaScript. This limits us to a degree, and needed changing.

The Web APIs work tries to fix that problem – open source drivers with JavaScript interfaces to access all the hardware of the phone.

The Web APIs power Firefox OS, the thing Mozilla is right now going full force to bring out to the market. Firefox OS will be the first truly open operating system for mobile devices. It has a market, it supports installable apps that have a URL on the web and it will be shipped next year on mobile devices.

Another big thing are Web Components, which define the missing app widgets we need, X-Tag which makes those available cross-browser and the Mortar and WebGame stub systems. Both of those allow any developer to start an app or game from building blocks and with a deployment script that uses GitHub as the host. They even create the offline and app manifests for you.

Google is also working on a very clever system called Yeoman which is a packaging system for web apps that automates a lot of optimisation and deployment steps for you.

In general I think tools is what we need much, much more. A very interesting move is that Adobe released Brackets, which is an editor that also ties into live rendering in the browser. It is pretty alpha but the very important point here is that the company who makes all their money with tools and rules for example the graphic creation market supreme is playing with open source. They want developers to work with them and make Brackets better and see how it works for them. This is a good chance to work with a company that knows how to build good tools and get them to open up more. Brackets is written in JS/CSS/HTML5 and targeted at writing these languages with it.

The vanilla web diet

Last but not least I am working on a new book explaining how you can use web technologies in a very simple way to build future-proof solutions without relying on a lot of third party libraries and writing a lot of code. Check out the demo page to see what I mean. Very few lines of JavaScript, no images, and a nice fallback for small screen devices and old browsers.

All in all it is now the time to get your hands dirty in HTML5. We have a great time ahead, if we embrace the idea of the web as a diverse environment and not another closed platform.

I am a trainer and I love to give trainings to “crowd-source” my knowledge. I take training seriously, having suffered far too many boring and bad trainings myself and swearing myself back then I will do better if I ever get the chance.

Training is treated as a nice to have

There is, however, a certain laxness in IT when it comes to trainings, and it makes me sad. Trainings are not to have a jolly off work, they are also not a nice to have. They should be the most efficient way to learn new things and get ahead in your career and should be treated as such. Instead of having bright and bushy-tailed training attendees many a time you find yourself in front of a tired group after an event half of whom didn’t show up, others are delayed, not prepared or people interrupt halfway through trying to “just join in”. This is a waste of time and bizarre considering how much training costs.

Training is expensive and precious – treat it as such

Sending engineers or managers to a training is a high cost. Not that I charge a lot (I should, most other trainers do!) but you are going to be out of the normal work flow for quite some time. For myself preparing a training means 8 hours of research, preparation and planing for every hour I am in the room. This is a large chunk of my life – professionally and personally – and it should be worth my while. I judge the success of my trainings by how much people learned and what they did afterwards, how they used the knowledge gained. If I don’t get the chance to learn any of that I wasted my and probably your time. Success of trainings should not be accidentally, it should be measurable and obvious. This is why from now on I will not take on any trainings any longer unless the following points are met.

My training manifesto

• We don’t start as strangers – the overall number and each attendee of the training should be known to me. This involves a quick email by attendees telling me about the training:
  • Who they are
  • What they expect from the training
  • Relevant knowledge they have with examples (“here are talks I gave, I want to be better”)
  • Special treatment that is needed (Proficiency in English, Disabilities, Materials)
• We are on time – or we don’t take part – my trainings are planned minute by minute to make the best out of the short time we have. If you are late, you delay everybody and disrupt an ongoing part of the training which will impact the rest and leave you without prior knowledge needed for the advanced lessons later on
• The door is closed – there will be breaks for human issues and there will be drinks and snacks (healthy ones, nuts and fruit, no point getting you sugared up and sleepy). So no leaving halfway through and no interruptions from the outside. This is our time and we use it as such.
• Laptops are closed, phones are on silent and in the pockets – for the most part you won’t need your computer in my trainings and it is just rude to be distracted by your emails, tweets or kittens. You are in a training, you are not available. Nothing your boss or colleagues need is more important, your attendance is very expensive, and should mean you are incommunicado to those not in it
• The group is responsible for the documentation
  • I will only give out very few materials about the training (mostly links to learn more from)
  • You are much more likely to really learn when you document yourself in the way you understand the most
  • There will be no binder at the end to collect dust on a shelf, keep your own notes
  • There will be times allocated to documenting in the training
• There will be a test and homework – I want to know what you learned and if you need to know more. The only way of doing that is to make you use the things we talk about

If these things can’t be met by the training I am not giving it. I don’t want to be a person collecting money or spending people’s time without making sure they get a lot of out it.

Compliance with this means you need to put more dedication into the training than you probably are used to. It also means though you will get much more out of it. I promise that.

I am currently at MozCamp Asia in Singapore and just gave a quick presentation on blogging comparing a good technical blog post to rock songs. When you think about it, they have a lot in common:

• No intro – just straight to the point
• Memorable hooks and riffs
• One message per post
• Simple language
• An easily repeatable main message (something to scream along to no matter how drunk)
• A memorable solo to end with

Confused? I guess it will all get clearer when you see the slides and listen to the screencast.

If you’ve been at Mozfest in London, you might have seen me stand next to a weird contraption of cables, tinfoil-covered squares and my computer. Here is what it looked like in action:

This was the so-called Interaction cam and here are the photos people took with it. This is how it works:

• You put your hand on the pad on the left – this should stay there the whole time
• You shoot a photo of yourself touching the pad on the right
• If you like it, you touch the second pad from the right
• Or you can discard it by touching the second pad to the left

You can also use the camera with more than one person. If one of you puts his hand on the left pad and the other on the right shaking hands, high-fiving or hugging would trigger the camera:

The camera stores the photos on the hard drive if you are offline or you can upload them to imgur.com immediately.

You can have the Interaction Cam for your event. All you need is a computer with a camera and one of the new browsers (Chrome, Firefox Nightly – Opera coming soon). Out-of-the box you can use the Space bar to take a photo, and the arrow right and left keys to upload or take another photo.

In order to make the pads work (and you can use anything that is an electrical conductor – fruit, water, vegetabless…) you need a MaKey MaKey and connect the appropriate parts of the MaKey MaKey (left, right, space and grounding) to the pads.

Your own cam – step by step

Here’s the step by step to have the camera for your event:

• Have a laptop with a camera and Chrome or Firefox Nightly
• Make sure to enable WebRTC in Firefox by typing “about:config”, saying yes that you want to make changes, finding the “media.navigator.enabled” entry and setting it to true
• Make sure you have a PHP enabled local server if you want to keep the photos offline and not rely on uploading to the web (MAMP for Mac or XAMPP for Window – Linux folk know what to do)
• Download the Interaction Cam code and unpack it to the htdocs folder of your local server
• Replace the mozfest.png file with your own event logo – this should be 600×104 pixels and use some transparency for more awesome (for other sizes you can alter the settings in interactioncam.js around “/* Branding */”
• Go to your browser and open your install of the camera app – in my case http://localhost:8888/interaction-cam/
• Grant the browser access to the camera – you should see it playing.
• Press space to take a photo and store it by hitting the right arrow
• On your hard drive, you should now have a file in the “copies” folder that is your photo

When all that works, add the MaKey MaKey:

• Connect the MaKey MaKey via USB
• Go through the recognition process of MaKey MaKey (like any other USB keyboard)
• Lay out your pads/connectors and connect the cables to the appropriate parts of the MaKey MaKey (make sure they don’t touch)
• Go back to your browser
• Reload the Interaction Cam
• Profit

That should do it – just upload the photos in your copies folder at your leisure later on and when you are connected to the web with a non-flaky connection.

Things that can go bump

Electricity, cables, computers and software are not natural and therefore hate humans. So things can go wrong. Here are a few things I found:

• If the camera doesn’t start running make sure you have the latest Chrome or Firefox Nightly and have WebRTC turned on
• If it still does nothing, you might need to reboot the computer (I had to a lot with the MacBook Pro)
• If your computer has the power cable connected to it (which is a good idea as WebRTC is hungry to the battery) it can happen that just touching the “take photo” pad already triggers that. Just hide the leftmost pad then as it is not needed any longer. If someone doesn’t trigger the shooting, tell them to touch the left one, too.

Happy shooting! I am off to MozCamp Asia where I will put up the cam. And my friend Marc Thiele is planning on setting it up at Beyond Tellerrand, too.