I am currently doing a survey amongst people who speak for Mozilla or want to become speakers. As a result of this, I am recording short videos and write guidelines on how to deal with various parts of presenting.

Photo Credit: Carbon Arc via Compfight cc

A lot of the questions in the “Presenting tips for Mozilla Reps” survey this time revolved around videos in presentations. Let’s take a look at that topic.

Videos are a great format to bring a message across:

• They are engaging as they speak to all senses (seeing, hearing, reading)
• They allow for a lot of information in a very short time
• They are relatively simple to make and with the help of YouTube and others very easy to distribute

As part of a presentation, videos can be supportive or very destructive. The problem with videos is that they are very engaging. As a presenter, it is up to you to carry the talk: you are the main attraction. That’s why playing a video with sound in the middle of your talk is awkward; you lose the audience and become one of them. You are just another spectator and you need to be very good to get people’s attention back to you after the video played.

Videos with sound

The rule of thumb of videos with sound is either to start with it and thus ease people into your talk or to end with it. In Mozilla we got a lot of very cool and inspirational short videos you can start with and then introduce yourself as a Mozillian followed by what you do and what you want to talk about today. You can also end with it: “And that’s what I got. I am part of Mozilla, and here are some other things we do and why it would be fun for you to join us”.

Screencasts

Screencasts are a superb format to use in your presentation to narrate over. Using a screencast instead of a live demo has a lot of benefits:

• They work – you know things work and you are not relying on a working internet connection or being able to use a certain computer setup.
• You can concentrate on presenting – you will not get into trouble trying to talk and do things at the same time. This is harder than it looks and it is astonishing how many speakers forget their password when talking and logging into a system on stage
• They have a fixed time – you know the time you will use for the demo and not get stuck at your computer slowing down for random reasons or showing the audience a loading animation for minutes because of the slow WiFi. Silence on stage is awkward and whilst you can crack a joke it seems bad planning
• You can focus on the important bits – you can zoom in and out in a screencast and only show the relevant bit. This is also possible with a live demo, but needs more skills

Of course screencasts have a few pitfalls:

• They could appear as cheating – make sure you explain the setup used in the demo and point people to live examples where they can try out the same demo for themselves. Do not show things working you know not to. This is what sales weasels do.
• Make sure you have the video on your computer – no, you will not have a connection fast enough to show a YouTube video at every event. Actually that is almost never a good idea.
• Test the video with the projection system – sometimes presentation software doesn’t show the video and you might need to use a media player to show it instead
• Keep them short – you want to make a point, not narrate a movie to an audience.

What about length?

Videos in presentations should make a point and have a purpose. In the end, a talk is a show and you are the star. You are the centre of attention. That’s why videos are good to make things more engaging but don’t lose the audience to them – after all they will have to look at them instead of you. One minute is to me a good time, less is better. Anything above 5 minutes should be a screenshot of the video, the URL to see it and you telling people why they should watch it. This works, I keep seeing people tweet the URL of a video I covered in my talks and thanking me that I flagged it up as something worth watching.

One of the things I always liked about Firefox is that you can right-click any canvas and select “save image as”. Chrome and others don’t do that (well, Chrome doesn’t). Instead you need to get the image data, create a url and open a new tab or something in that order.

One very simple way to allow people to save a canvas as an image (and name it differently – which would have to be done by hand in the case of right-clicking on Firefox) is to use the download attribute of a link.

You can see this in action in this JSFiddle. Simply paint something and click the “download image” link.

The relevant code is short and sweet (canvas is the reference of the canvas element):

var link = document.createElement('a');
link.innerHTML = 'download image';
link.addEventListener('click', function(ev) {
    link.href = canvas.toDataURL();
    link.download = "mypainting.png";
}, false);
document.body.appendChild(link);

Legos by C Slack

Web Components are a hot topic now. Creating widgets on the web that are part of the browser’s rendering flow is amazing. So is inheriting from and enhancing existing ones. Don’t like how a SELECT looks or works? Get it and override what you don’t like. With the web consumed on mobile devices performance is the main goal. Anything we can do to save on battery consumption and to keep interfaces responsive without being sluggish is a good thing to do.

Web Components are a natural evolution of HTML. HTML is too basic to allow us to create App interfaces. When we defined HTML5 we missed the opportunity to create semantic widgets existing in other UI libraries. Instead of looking at the class names people used in HTML, it might have been more prudent to look at what other RIA environments did. We limited the scope of new elements to what people already hacked together using JS and the DOM. Instead we should have aimed for parity with richer environments or desktop apps. But hey, hindsight is easy.

What I am more worried about right now is that there is a high chance that we could mess up Web Components. It is important for every web developer to speak up now and talk to the people who build browsers. We need to make this happen in a way our end users benefit from Web Components the best. We need to ensure that we focus our excitement on the long-term goal of Web Components. Not on how to use them right now when the platforms they run on aren’t quite ready yet.

What are the chances to mess up? There are a few. From what I gathered at several events and from various talks I see the following dangers:

• One browser solutions
• Dependency on filler libraries
• Creating inaccessible solutions
• Hiding complex and inadequate solutions behind an element
• Repeating the “just another plugin doing $x” mistakes

One browser solutions

This should be pretty obvious: things that only work in one browser are only good for that browser. They can only be used when this browser is the only one available in that environment. There is nothing wrong with pursuing this as a tech company. Apple shows that when you control the software and the environment you can create superb products people love. It is, however, a loss for the web as a whole as we just can not force people to have a certain browser or environment. This is against the whole concept of the web. Luckily enough, different browsers support Web Components (granted at various levels of support). We should be diligent about asking for this to go on and go further. We need this, and a great concept like Web Components shouldn’t be reliant on one company supporting them. A lot of other web innovation that heralded as a great solution for everything went away quickly when only one browser supported it. Shared technology is safer technology. Whilst it is true that more people having a stake in something makes it harder to deliver, it also means more eyeballs to predict issues. Overall, sharing efforts prevents an open technology to be a vehicle for a certain product.

Dependency on filler libraries

A few years ago we had a great and – at the same time – terrible idea: let’s fix the problems in browsers with JavaScript. Let’s fix the weirdness of the DOM by creating libraries like jQuery, prototype, mootools and others. Let’s fix layout quirks with CSS libraries. Let’s extend the functionality of CSS with preprocessors. Let’s simulate functionality of modern browsers in older browsers with polyfills.

All these aim at a simple goal: gloss over the differences in browsers and allow people to use future technologies right now. This is on the one hand a great concept: it empowers new developers to do things without having to worry about browser issues. It also allows any developer to play with up and coming technology before its release date. This means we can learn from developers what they want and need by monitoring how they implement interfaces.

But we seem to forget that these solutions were build to be stop-gaps and we become reliant on them. Developers don’t want to go back to a standard interface of DOM interaction once they got used to $(). What people don’t use, browser makers can cross off their already full schedules. That’s why a lot of standard proposals and even basic HTML5 features are missing in them. Why put effort into something developers don’t use? We fall into the trap of “this works now, we have this”, which fails to help us once performance becomes an issue. Many jQuery solutions on the desktop fail to perform well on mobile devices. Not because of jQuery itself, but because of how we used it.

Which leads me to Web Components solutions like X-Tags, Polymer and Brick. These are great as they make Web Components available right now and across various browsers. Using them gives us a glimpse of how amazing the future for us is. We need to ensure that we don’t become dependent on them. Instead we need to keep our eye on moving on with implementing the core functionality in browsers. Libraries are tools to get things done now. We should allow them to become redundant.

For now, these frameworks are small, nimble and perform well. That can change as all software tends to grow over time. In an environment strapped for resources like a $25 smartphone or embedded systems in a TV set every byte is a prisoner. Any code that is there to support IE8 is nothing but dead weight.

Creating inaccessible solutions

Let’s face facts: the average web developer is more confused about accessibility than excited by it. There are many reasons for this, none of which worth bringing up here. The fact remains that an inaccessible interface doesn’t help anyone. We tout Flash as being evil as it blocks out people. Yet we build widgets that are not keyboard accessible. We fail to provide proper labeling. We make things too hard to use and expect the steady hand of a brain surgeon as we create tight interaction boundaries. Luckily enough, there is a new excitement about accessibility and Web Components. We have the chance to do something new and do it right this time. This means we should communicate with people of different ability and experts in the field. Let’s not just convert our jQuery plugins to Web Components in verbatim. Let’s start fresh.

Hiding complex and inadequate solutions behind an element

In essence, Web Components allow you to write custom elements that do a lot more than HTML allows you to do now. This is great, as it makes HTML extensible (and not in the weird XHTML2 way). It can also be dangerous, as it is simple to hide a lot of inefficient code in a component, much like any abstraction does. Just because we can make everything into an element now, doesn’t mean we should. What goes into a component should be exceptional code. It should perform exceptionally well and have the least dependencies. Let’s not create lots of great looking components full of great features that under the hood are slow and hard to maintain. Just because you can’t see it doesn’t mean the rules don’t apply.

Repeating the “just another plugin doing $x” mistake

You can create your own carousel using Web Components. That doesn’t mean though that you have to. Chances are that someone already built one and the inheritance model of Web Components allows you to re-use this work. Just take it and tweak it to your personal needs. If you look for jQuery plugins that are image carousels right now you better bring some time. There are a lot out there – in various states of support and maintenance. It is simple to write one, but hard to maintain.

Writing a good widget is much harder than it looks. Let’s not create a lot of components because we can. Instead let’s pool our research and findings and build a few that do the job and override features as needed. Core components will have to change over time to cater for different environmental needs. That can only happen when we have a set of them, tested, proven and well architected.

Summary

I am super excited about this and I can see a bright future for the web ahead. This involves all of us and I would love Flex developers to take a look at what we do here and bring their experience in. We need a rich web, and I don’t see creating DOM based widgets to be the solution for that for much longer with the diversity of devices ahead.

I just got asked why Firefox doesn’t do the same thing as Chrome does when you copy a GIF into a canvas element using drawImage(). The short answer is: Chrome’s behaviour is not according to the spec. Chrome copies the currently visible frame of the GIF whereas Firefox copies the first frame. The latter is consistent with the spec.

You can see the behaviour at this demo page:

Here’s the bug on Firefox and the bug request in Webkit to make it consistent thanks to Peter Kasting there is also a bug filed for Blink.

The only way to make this work across browsers seems to be to convert the GIF into its frames and play them in a canvas, much like jsGIF does.

On Tuesday, Microsoft announced the end of support for Windows XP. For web developers, this meant much rejoicing as we are finally rid of the yoke that is Internet Explorer 6 and can now use all the cool things HTML5, CSS3 and other tech has to offer. Right? Maybe.

When I started web development my first real day-to-day browser was IE4 and then Netscape Navigator Gold moving on to Netscape Communicator 4. I saw the changes of IE5, 5.5 and finally IE6. I was pretty blown away by the abilities IE6 had. You had filters, page transitions, rotation, blurring, animation using marquee and even full-screen applications using the .hta extension. In these applications you had full JScript access to the system, you can read and write files, traverse folders and much more. Small detail: so had attackers as the security model wasn’t the best, but hey, details…

None of this was a standard, and none of it got taken on by other browsers. That probably wasn’t possible as features of browsers were the main differentiator and companies protected their USPs.

IE was never and will never be just a browser: it is an integral part of the operating system itself. For better or worse, Microsoft chose to make the web consumption tool also the file browsing and document display tool. Many of the very – at that time – futuristic features of IE6 were in there as they were needed for Powerpoint-style presentations.

That’s why the end of XP is a light at the end of the tunnel for all those suffering the curse that is IE6. Many users just didn’t bother upgrading their browser as what the OS came with was good enough.

A cracker’s paradise

Of course we now have a security problem: not all XP installs will be replaced and the lack of security patches will result in many a hacked server. Which is scary seeing that many ATMs run on XP and lots of government computers (the UK government alone spent 5.5m GBP on getting extended support for XP as moving on seems to be hard to do with that many machines and that much red tape). XP and IE6 weren’t a nuisance for web developers – they are a real threat to internet security and people’s online identity for a long time now.

The fast innovator in a closed environment dilemma

You can say what you want about IE6 - and it has been a running joke for a long time – having it and having it as the nemesis of web standards based browsers (Opera, Netscape6 and subsequently Firefox) taught us a lot. Having a browser that dared to dabble with applications in HTML years before the W3C widget spec or Adobe Air was interesting. Having a browser in the operating system that naturally was the first thing people clicked to go online helped the internet’s popularity. It didn’t help the internet as a whole though.

The big issue of course was that people didn’t upgrade and the OS didn’t force-upgrade the browser. This meant that companies had a fixed goal to train people on: if it works in IE6, it is good enough for us. That’s why we have hundreds of large systems that only work in IE. Many of those are enterprise systems: CRM, Asset management, Ticketing, CMS, Document management – all these fun things with lots of menus and trees and forms with lots of rules.

Nobody likes using these things. People don’t care for them, they just see them as a necessary thing to do their job and something created by magical hairy pixies called the IT department. When you don’t like something but need to use it any change in it is scary, which is why a lot of attempts to replace these systems with more user-friendly and cross-platform systems is met with murmurings or open revolt. I call this the Stockholm syndrome of interfaces: I suffered it for years, so I must like it, right? All the other stuff means more work.

Back to the browser thing though: The issue wasn’t IE6, the issues were its ubiquity, an audience that wasn’t quite web savvy yet and didn’t crave choice but instead used what was there, and Microsoft’s tooling centering around creating amazing things for IE first and foremost and maybe a fallback for other browsers. The tools locked into IE6 were most of the time not created by web developers, but by developers of .NET, classic ASP, Sharepoint and many other – great – tools for the job at hand. Everything seemed easy, the tools seemed far superior to those that cover several targets and when you stayed inside the ecosystem, things were a breeze. You didn’t even have to innovate yourself – you just waited until the platform added the next amazing feature as part of the build process (this even happened at awesome events that only cost your employer and means you can get an awesome T-Shirt to boot). Sound eerily familiar to what’s happening now in closed platforms and abstracted developer tools, doesn’t it? Look – it’s the future, now – if you use platform x or browser y.

What should we take away from this?

Which brings me to the learning we should take away from these years of building things for a doomed environment: browsers change, operating systems change, form factors change. What we think is state-of-the-art and the most amazing thing right now will be laughable at best or destructive to innovation at worst just a year ahead.

And it is not Microsoft’s fault alone. Microsoft have seen the folly of their ways (OK, with some lawsuits as extra encouragement) and did a great job telling people to upgrade their systems and stop targeting OldIE. They understand that not every developer uses Windows and made testing with virtualisation much easier. They are also much more open in their messaging about what standards new IE supports. If they understand this, we should, too.

Here are the points we should keep in our heads:

• Bolting a browser into an operating system makes it harder to upgrade it – you see this now in Android stock browsers or iOS. Many of the amazing features of HTML5 need to be poly-filled, not for old IE, but for relatively new browsers that will not get upgraded because the OS can’t get updated (at times on hardware that was $500 just a few months ago)
• Building software for the current state of the browser is dangerous – especially when you can’t trust the current state to even be stable. Many solutions relying on the webkit prefix functionality already look as silly as a “if (document.layers || document.all) {}” does.
• Stop pretending you can tell end users what browser to use – this is sheer arrogance. Writing software means dealing with the unknown and preparing for it. Error handling is more important than the success case. Great UX is invisible – the thing just works. Bad error handling creates unhappy users and there is nothing more annoying than being on a pay-by-the-minute connection in a hotel to be told I need to use another browser or update mine. Stop pretending your work is so important people have to change for you if all you need to do is being more creative in your approach.

There are only a few of us unlucky enough to have to support IE6 in a pixel-perfect manner right now. The death of XP wasn’t the big liberation we really needed. And by all means it should not mean that you write web apps and web sites now that rely on bleeding edge technology in newer browsers without testing for it. This will never go away, and it shouldn’t. It makes us craftsmen, it keeps us on the ball. We need to think before we code, and – to me – that is never a bad idea.

The rules did not change:

• HTML is king – it will display when everything else fails, it will perform amazingly well.
• Progressive Enhancement means you write for now and for tomorrow – expect things to break, and plan for it, and you can never be surprised.
• Browser stats are fool’s gold – who cares how many people in Northern America who have a certain statistics package installed use browser x or browser y. What do your end-users use? Optimise for form factors and interaction, not for browsers. These will always change.
• Writing for one browser helps that one in the competition with others, but it hurts the web as a whole – we’re right now in a breakneck speed rat-race about browser innovation. This yields a lot of great data but doesn’t help developers if the innovations vanish a few versions later. We have jobs to do and projects to deliver. There is not much time to be guinea pigs
• Real innovation happens when we enhance the platform – we need WebComponents in the browsers, we need WebRTC in browsers, we need a more stable Offline and Local Storage solution. What we don’t need is more polyfills as these tend to become liabilities.

So, RIP XP, thanks for all the hardship and confusion that made us analyse what we do and learn from mistakes. Let’s crack on with it and not build the next XP/IE6 scenario because we like our new shiny toys.