Helping out people with giving their first public presentations can be frustrating. The reason is the misconception that we have based on years of conditioning in school and corporate environments that a good presentation stands and falls with the slide deck.

Of course a beautiful slide deck is a nice thing to have and allows you to emphasize your points. In some instances it is also extremely important to have a good and consistent slide deck. But when you start out and want to become an engaging speaker sweating about what slide format what font and which system to use is a waste of your time.

You already have the killer presentation tool: yourself. Your talk will stand and fall with your performance, how engaging you are and how much you know about the subject matter that is interesting and relevant to the audience. And this is where you should start. You become engaging by being engaged yourself. The first step to any good presentation is to find out why you are excited about the subject. Then build on that.

Sharing your excitement is the most addictive and convincing thing there is. When you are confident that you can explain why you are excited and how the audience can get to the same stage, you could stand in front of a wall of drying paint and people would still remember your talk as something that helped them and was interesting.

Slides are an aid – something to bring your message home. Wallpaper, so to say. At least in talks that are meant to engage and audience and get them to find out more by themselves.

If your presentation is to a group in a meeting room getting everyone up to speed on the state of a certain project – different story. But even then reading from your slides is not the best way to keep people awake. Nothing says “this will be boring, feel free to skip parts” more than an agenda in your slide deck. Sometimes this might be needed, but that is already an indicator that the meeting is badly organised.

As to what format and system to use: find what makes you most effective. Writing your presentation should be about bringing the messages across, not playing with technology. Just be aware that presenting at an event in 99% of the cases means you will have no connection to the web and that making your slides available to the outside world is a different step to preparing and presenting your talk. There are a lot of “host your slides here” systems out there – these are great for distribution, less so for reliable presenting.

Google just announced that on 1st of July 2013 they will shut down Google Reader as a service. Just like that. The reasons are meager:

There are two simple reasons for this: usage of Google Reader has declined, and as a company we’re pouring all of our energy into fewer products. We think that kind of focus will make for a better user experience.

This is a big disappointment for me. I have a few thousand RSS subscriptions I get my information from (and send it out on Twitter and Google+ which a lot of people appreciate). I can not see how any other resource than feeds give you the speed, quality and control over the content you consume on the web.

Yes, RSS has been declared dead many times and people keep banging on about the social web and that Facebook, Twitter, Reddit and others have replaced the old style of blogging and having an own feed. But I don’t buy it, sorry. Every social network is full of senseless chatter and organised advertising. Social media experts and PR folk make sure that information about certain products and celebrities get read and retweeted. I don’t care about that. I don’t want it. The same way I don’t watch public access channels or randomly surf channels but instead plan what I want to see on TV. Random exploration and finding things by chance is fun, but it is not helping you to keep up to date – it is the ADHD of information consumption. I myself use Twitter, Facebook and Gogole+ much more frivolous than my blog. The reason is that they are terrible as an archive of my thoughts or to put out structured data. Search is terrible in Twitter, which is why I use pinboard to bookmark links I tweet automatically. Google+ has the same problem. Finding quality information is damn hard as all the social networks are there to have lots and lots of interaction and not make people write good articles or posts.

Of course the real issue is that this is not about users or the web or making it easy to find information – this is about numbers, quick updates and showing more ads to people. Google+ is where people should go in the Google world. There was never an offer to pay for Reader. I’d have loved to pay for it – much like I paid for pinboard.in when delicious got the “oh we innovate and make it prettier” treatment. There is also no way to pay or call the shots in Google+ – as the consumer you are just there to bear with changes and use them or not. What’s the difference between a circle and a group? How many competing ways to organise our contacts can we use before we spend more time shifting sources around rather than reading what comes from them? Can you rely that anything you put in will be available for you later on? Can it be indexed and searched outside? Maybe, but will that be the same in the future? RSS was open – it was decentralised and used the web to link to each other and give you a mechanism to get information about news without having to go to a site and surf it. This is not good for advertising – you need to own the interface to own the user’s attention. Twitter is also feeling this heavily which is why it is killing all third party clients one by one.

My favourite answers on Twitter when I said that I am sorry about Reader going to the farm where old services go was that people told me that there surely must be an app doing the same thing. Maybe, but how the hell is an app that I need to download and install on all my devices a replacement for a very simple web service with great searchability and archive-search and very quick keyboard controls? Any app needs a sharing button where I need to go to yet another service and the first app needs to log-in on my behalf. On Reader sharing was copy+paste. Simple, works, and it also means when App B gets hacked my personal social stream on the web is not full of spam.

It seems to me that we’ve been thoroughly brainwashed into seeing a nicely packaged – and hard to upgrade – app as the better option for anything. To me, it isn’t. Reader was a simple App tab in my Firefox, lighting up whenever there was something new. Easy to go to, press J a few times and go back to my other tabs where I create things, write or read. Of course this is not how everybody uses the web, but this is how content producers use it. I don’t write long descriptions of my links on my mobile – I re-send them, I simply distribute instead of filtering, commenting and distributing with context.

No, I don’t want to switch to an app for that. And neither should you. The power of the web is connected content – via links and open text-based formats that are easy to index and search. Content permeates through your environment – whatever it is. You shouldn’t have to have a certain app to consume it or comment on it or change it. More walled environments with a “live stream” and no access to the archive or linkabilty are not the answer to keeping the web a knowledge resource. They are the answer to the need of showing us more ads and making us click pointless “like” buttons. The interactions are what is monitored and counted. Not the content – content is just there for a fleeting moment until the next information fix scrolls into view.

I just finished a talk at another “developer conference” which is a side-attraction at a larger trade show and decided that this was the last one of those that I will do.

The reason is that I’ve done a few of them, and they’ve always been a disappointment to me. Of course there are great ones, I am sure, but I’ve had quite a lot of very disappointing experiences. In detail these were:

• Poor attendance by developers – it is a trade show, people are busy running around and dousing fires on demos not working instead. Trade shows are full of distractions and attractions and having a full day taken out is too much for a lot of people.
• The AV setup was always abysmal. I always had to bring my own connectors and got a minute or so to set up whilst the last speaker still answered questions. The sound was always bad as you are in some hall to the side with lots of blaring music and advertising and – in the worst cases – with two side-by-side stages where you hear other people talk and not yourself
• There is never a recording of the talks or a centralised repository where to get the slides and other materials afterwards. It seems organisers just expect lackluster talks by company speakers to lure people to their respective stands and writing a bespoke talk made me feel like a waste
• There was always an overall feeling of half-hearted organisation being sold as “being different for developers”

All in all these “amazing developer event inside the main event” appear to me as a petting zoo for developers. The market knows developers are important, but there is no point or much of value for them on a trade show. So, let’s have some own playground for them to do two hour hackathons with prizes and some talks that don’t really need planning. It feels condescending and to me out of place. Especially when the rest of the show is staffed by half-naked booth babes who have no stake in the product they are actually promoting (something that simply needs to stop). Developer events have a different goal than that.

If you want to integrate developers into trade shows (as it might be useful as they will be around anyways) have an own event in an own venue or a day before or after instead. The way I found things to be organised now just seems like a bleached carbon copy of a good idea. Instead of asking known speakers or asking for sponsoring from large companies and yet another “look our product $x makes it so easy for developers, you are almost redundant” talk, have unknown speakers get up there, allow local small companies to do a technical talk and show themselves (as they are not likely to be able to afford an amazing booth at the show). Have partner companies of large corporations show how they use the products sold as infallible and give information what the real experience looks like. Be disruptive, be different than the main event, but don’t force it by stating you are different without delivering.

Hackathons take time, workshops need dedicated and non-disrupted and prepared attendees, developer talks need audiences. Don’t cheapen this because it seems simple to organise and you already have a location – of sorts.

If this sounds arrogant then it is only because I have been disappointed about all this. I love events, I know how much work it is and I want every event to count for the audience, the organisers and the speakers. I’d rather have “conference in conference” organisers allow someone unknown to speak and give them coverage and promotion in the main event channels than get known speakers in. That’s helping more people on the whole.

I am happy to give a keynote at a partner booth, show demos and examples and talk to the press. But I will give someone else the chance to have a go at talking at these sorts of events in the future. Not because I feel too good for them, but because I feel that these events need to change drastically – or vanish.

I just got back from CeBIT in Germany which hosted the Mooseconf developer conference. My part of the show was to give a talk about Firefox OS and what it means to HTML5.

I gave that talk twice, once in the morning for a closed audience of developers and a repeat in the afternoon for the open part of the conference. The slides and notes are online and there is a screencast available on YouTube.

In the talk I reminisced about the time I had at Mobile World Congress in Barcelona last week showcasing Firefox OS to 57 different journalists. I especially remembered running into an interviewer who was very much a novice in the ways of the web. To make him understand I came up with a simile in my desperation explaining that “Firefox OS is the Volkswagen Beetle of smartphones”.

This was based on the original idea of the Beetle as a car that is affordable for everyone and to be a massive boost to the car-manufacturing industry.

The Volkswagen Beetle, officially called the Volkswagen Type 1 (or informally the Volkswagen Bug), is an economy car produced by the German auto maker Volkswagen (VW) from 1938 until 2003. With over 21 million manufactured[6] in an air-cooled, rear-engined, rear-wheel drive configuration, the Beetle is the longest-running and most-manufactured car of a single design platform, worldwide. Wikipedia

Firefox OS follows the same principles:

• Its aim is to replace feature phones in emerging markets with HTML5 based phones that match the functionality of non-affordable or even locally available smartphones
• The phones are based on the proven Firefox engine (Gecko), fully open and standard-proposed APIs and a Linux core (Gonk) that also powers Android
• Parts of the beetle were interchangeable between its versions. That ensured that spare parts are easy to come by. Firefox OS is powered by and runs HTML5 applications. You can easily turn a current mobile-optimised web site into an app and get much better hardware access support with a few lines of JavaScript and a manifest file
• The idea is to give HTML5 the hardware platform it deserves, not to be allowed to run on platforms that treat it as a thing that runs in browsers and is blocked from accessing the interesting parts of the device

In the rest of the talk I went through the different parts that make Firefox OS special. The ability to search for apps by content for example – enter the name of a band and you get Music, Video and Lyrics apps, enter “restaurant” and you get review apps. In essence we make app discovery and “try before you buy” as easy as surfing the web. This means we need you out there to spice up your “mobile friendly” pages and at least add local caching mechanisms.

I talked through the different levels of apps in Firefox OS and their rights to access the hardware and how to make even your hosted apps get access to the hardware by asking the user to do it with web activities. These are the same idea as web intents that Chrome had and now discontinued (for the moment).

I end with a listing of the resources to get you started and an explanation that the web as a platform is far from over. If you bet on HTML5, you build for now and all the other platforms (using for example phone gap) and the future. And with Firefox OS you reach a whole new market that now only could afford low-end Androids running the stock browser which is not the best HTML5 platform by a long shot.

This was my closing keynote talk of the first day of jQuery Europe 2013 in Vienna, Austria. The slide deck is here. Sadly, due to technical issues there is no audio or video recording.

As developers, we seem to be hardwired to try to fix things. And once we managed something, we get bored with it and want to automate it so that in the future we don’t have to think about it any longer. We are already pre-occupied with solving the next puzzle. We delude ourselves into thinking that everything can get a process that makes it easier. After all, this is what programming was meant for – doing boring repetitive tasks for us so we can use our brains for things that need more lateral thinking and analysis.

Going back in time

When I started as a web developer, there was no such thing as CSS and JavaScript’s interaction with the browser was a total mess. Yet we were asked to build web sites that look exactly like the Photoshop files our designers sent us. That’s why in order to display a site correctly we used tables for layout:

<table width="1" border="1" cellpadding="1" 
       cellspacing="1">
  <tr>
    <td width="1"><img src="dot_clear.gif" 
                       width="1" height="1" 
                       alt=""></td>
    <td width="100"><img src="dot_clear.gif" 
                         width="100" height="1" 
                         alt=""></td>
  </tr>
  <tr>
    <td align="center" valign="middle" bgcolor="green">
      <font face="arial" size="2" color="black">
        <div class="text">
          1_1
        </div>
      </font>
    </td>
    <td align="center" valign="middle" bgcolor="green">
      <font  face="arial" size="2" color="black" >
        <div class="text">
          1_2
        </div>
      </font>
    </td>
  </tr>
</table>

Everything in there was needed to render properly across different browsers. Including the repeated width definitions in the cells and the filler GIF images. The DIVs with class “text” inside the font elements were needed as Netscape 4 didn’t apply any styling without an own element and class inside a FONT element.

Horrible hacks, but once we tested and discovered the tricks that are needed we made sure we didn’t have to do it every time from scratch. Instead we used snippets in our editors (Homesite in my case back then) and created generators. My “table-o-matic” is still available on the Wayback machine:

Moving into hard-core production we shifted these generators and tricks into the development environment. Instead of having a web site, I created toolbars for Homesite for different repetitive tasks we had to do. I couldn’t find the original table toolbar any longer but I found the WAP-o-matic, which was the same thing to create the outline of a document for the – then – technology of the future called WML:

Etoys, the company I worked for back then was hard-core as they come. Our site was an ecommerce site that had millions of busy users on awful connections. Omitting quotes on our HTML was not a matter of being hipster cool about HTML5, it was a necessity to make things work on a 56KB dial-up when browsers didn’t have any gzip deflating built-in.

Using the table tools it was great to build a massively complex page and see it working the same across all the browsers of the day and the older ones still in use (think AOL users).

But there was an issue. It turned out that browsers didn’t render the whole page until all the document was loaded when the content was a table. Netscape also didn’t render the table at all when there was a syntax error in your HTML. In order to speed up rendering you had to cut up your page into several tables, which would render one after another. With a defined header in our company it was possible to still automate that both in the editor and in templates. But it limited us. We had a race between progressive rendering of the page and the amount of HTML we sent to the browser. Add to this that caching was much more hit and miss back then and you are in a tough spot.

The rise of search engines was the next stumbling block for table layouts. Instead of having lots of HTML that defines the main navigation and header first-up (remember, source order defined visual display) it became more and more important to get the text content of the page higher up in the source. The trick was to use a colspan of 2 on the main content and add an empty cell first.

Helper tools need to evolve with market needs

The fact remains that back then this was both state of the art and it made our lives much, much easier to automate the hacks once we knew them. The problem though is that when you deliver tools like these to developers, you need to keep up with changes in the requirements, too. Company internal tools suffer less from that problem as they are crucial to delivery. But tools we threw out for fun and help other developers are more likely to get stale once we move on to solve other problems.

No browser in use these days needs table layouts and they are far too rigid to deliver to the different environment we want to deliver HTML in. Luckily enough, I don’t know anyone who uses these things any longer and whilst they were amazingly successful at the time, I cut the cord and made them not available any longer. No sense in tempting people to do pointless things that seem the most simple thing to do.

When we look at the generated code now it makes us feel uneasy. At least it should – if it doesn’t, you’ve been working in enterprise too long. There was some backlash when I deleted my tools because once engineers like something and find it useful we love to defend tooth and nail:

Arguing with an engineer is a lot like wrestling in the mud with a pig. After a few hours, you realize that he likes it.

What I found over and over again in my career as a developer is that our tools are there to make our jobs easier, but they also have to continuously evolve with the market. If they don’t, then we stifle the market’s evolution as developers will stick to outdated techniques as change means having to put effort in.

Never knowing the why stops us from learning

Even worse, tools that make things much easier for developers can ensure that new developers coming into the market have no clue what they are doing. They just use what the experts use and what makes their lives easier. In software that works as there is no physical part that could fail. You can’t be as good as a star athlete by buying the same pair of shoes. But you can use a few plugins, scripts and libraries and put together something very impressive.

This is good, and I am sure it helped the web become the mainstream it is now. We made it much easier to build things for the web. But the price we paid is that we have a work-force that is dependent on tools and libraries and forgot about the basics. For every job offer for “JavaScript developer” you’ll get ten applicants who only ever used libraries and fail to write a simple loop using only what browsers give you.

Sure, there is a reason for that: legacy browsers. It can appear as wasted time explaining event handling to someone who just learns JavaScript and having to tell them the standard way and then how old Internet Explorer does it. It seems boring and repetitive. We lived with that pain long enough not to want to pass it on to the next generation of developers.

The solution though is not to abstract this pain away. We are in a world that changes at an incredible pace and the current and future technologies don’t allow us to carry the burden of abstraction with us forever. We need the next generation of developers to face new challenges and we can’t do that when we tell them that everything works if you use technology X, script Y or process Z. Software breaks, environments are never as good as your local machine and the experiences of our end users are always different to what we have.

A constant stream of perfect solutions?

Right now we are obsessed with building helper tools. Libraries, preprocessors, build scripts, automated packaging scripts. All these things exist and there is a new one each week. This is how software works, this is what we learn in university and this is how big systems are built. And everything we do on the web is now there to scale. If your web site doesn’t use the same things Google, Facebook, Twitter and others use to scale, you will fail when the millions of users will come. Will they come for all of us? Not likely, and if they do it will also mean changing your infrastructure.

What we do with this is add more and more complexity. Of course these tools help us and allow us to build things very quickly that easily scale to infinity and beyond. But how easy is it for people to learn these skills? How reliable are these tools not to bite us in a month’s time? How much do they really save us?

And here comes the kicker: how much damage do they do to the evolution of browsers and the competitiveness of the web as a platform?

Want to build to last? Use standards!

The code I wrote 13 years ago is terrible by today’s idea of semantic and valuable HTML. And yet, it works. Even more interesting – although eToys has been bankrupt and closed in the UK for 12 years, archive.org still has a large chunk of it for me to find to show you now as it is standards based web content with HTML and working URLs.

In five years from now, how much of what we do right now will still be archived or working? Right now I get Flashbacks to DHTML days, where we forked code for IE and Netscape and tried to tell users what browser to use as this is the future.

There seems to be a general belief in the developer community that WebKit is the best engine and seeing how many browsers use it that others are not needed any longer. This, to a degree is the doing of abstraction as no browser engine is perfect

jQuery Core has more lines of fixes and patches for WebKit than any other browser. In general these are not recent regressions, but long-standing problems that have yet to be addressed.
It’s starting to feel like oldIE all over again, but with a different set of excuses for why nothing can be fixed. Dave Methvin, jQuery core team; President of the jQuery Foundation.

We repeat the mistakes of DHTML days. Many web sites expect a Webkit browser or JavaScript to be flawlessly executed. I don’t really have a problem with JavaScript dependency for some functionality (as the “JavaScript turned off” use case is very much a niche phenomenon) but we rely far too much on it for incredibly simple tasks.

Google experienced that the other day: because of a JavaScript error the download page of Chrome was down for a whole day. Clicking the button to show a terms and conditions page only resulted in a JavaScript error and that was that. No downloads for Chrome that day.

As Jake Archibald once put it:

“All your users have JavaScript turned off until the first script is loaded and runs”

This applies to all dependencies we have, be they libraries, build scripts, server configuration, syntactical sugar to make a programming task easier and less keystrokes. We tell ourselves that we make it easier for people to build things but we are adding to a landfill of dependencies that are not going to go away any time soon.

b2. Dev: “It works on my machine, just not on the server.” Me: “Ok, backup your mail. We’re putting your laptop into production.” Oisin Grehan on Twitter

There is no perfect plugin, there is no flawless code. In a lot of cases we start having to debug the library or the plugin itself. Which is good if we file pull requests that get implemented, but looking at libraries and open issues with plugins, this is not the case a lot of times. Debugging a plugin is much harder than debugging a script that directly interacts with the browser as developer tools need to navigate around the abstractions.

Web obesity

The other unintended effect is that we add to web obesity. By reducing functionality to a simple line of code and two JavaScript includes we didn’t only make it easier for people to achieve a certain effect – we also fostered a way of working to add more and more stuff to create a final solution without thinking or knowing about the parts we use. It is not uncommon to see web sites that are huge and use various libraries as they liked one widget built on one and another built on another.

This leads to ridiculously large pages like Grolsch.com which clocks in at 388 HTTP requests with 24.29MB traffic:

What we have there is a 1:1 conversion of a Flash site to an HTML5/CSS3 site without any understanding that the benefit of Flash for brochureware sites like these full of video and large imagery was that it can stream all this. Instead of benefiting from offline storage sites like this one just add plugin after plugin to achieve effects. The visual outcome is more important than the structure or maintainability or – even worse – the final experience for the end user. You can predict that any of these sites start with the best of intentions but when deadlines loom and the budget runs out the cutting happens in Q&A and by defining a “baseline of supported browsers and platforms”.

Time for a web diet

In other words: this will break soon, and all the work was for a short period of time. Because our market doesn’t stagnate, it moves on. What is now a baseline will be an anachronism in a year’s time. We are going into a market of thin clients on mobile devices, set-top boxes and TV sets.

In essence, we are in quite a pickle: we promised a whole new generation of developers that everything works for the past and the now and suddenly the future is upon us. The “very small helper library” on desktop is slow on mobiles and loading it over a 3G connection is not fun. To me, this means we need to change our pace and re-focus on what is important.

Our libraries, tools and scripts should help developers to build things faster and not worry about differences in browsers. This means we should be one step ahead of the market with our tools and not patch for the past.

What does that mean? A few things

• Stop building for the past – using a library should not be an excuse for a company to use outdated browsers. This hurts the web and is a security issue above everything else. No, IE6 doesn’t get any smooth animations – you can not promise that unless you spend most of your time testing in it.
• Let browsers do what they do best – animations and transitions are now available in CSS, hardware-accelerated and rendering-optimised. Every time you use animate() you simulate that – badly.
• Componentise libraries – catch-all libraries allowing people to do anything lead to a thinking that you need to use everything. It also means that libraries themselves get bloated and hard to debug
• Build solid bases with optional add-ons – we have more than enough image carousel libraries out there. Most of them don’t get used as they do too many things at once. Instead of covering each and every possible visual outcome, build plugins that do one thing well and can be extended, then collaborate
• Fix and apply fixes – both the pull request and issue queues of libraries and plugins are full of unloved feedback and demands. These need to go away. Of course it is boring to fix issues, but it beats adding another erroneous solution to the already existing pile
• Know the impact, don’t focus on the outcome – far too many of our solutions show how to achieve a certain visual effect and damn the consequences. It is time we stop chasing the shiny and give people tools that don’t hurt overall performance

Here’s the good news: by writing tools over the last few years that allowed people to quickly build things, we got quite a following – especially in the jQuery world. This means that we can fix things at the source and go with two parallel approaches: improving what is currently used and adding new functionality that works fine on mobile devices in our next generation of plugins and solutions. Performance is the main key – what we build should not slow down computers or needlessly use up battery and memory.

There are a few simple things to do to achieve that:

• Use CSS when you can – for transitions and animations. Generate them dynamically if needed. Zepto.js does a good job at that and cssanimations.js shows how it is done without the rest of the library
• requestAnimationFrame beats setInterval/setTimeout – if we use it, animations happen when the browser is ready to show them, not when we force it to apply them without any outcome other than keeping the processor busy
• Transforms and translate beat absolute positioning – they are hardware accelerated and you can easily add other effects like rotation and scaling
• Fingers off the DOM – by far the biggest drain in performance is DOM access. This is unfortunate as jQuery was more or less made to make access to the DOM easier. Make sure to cache your DOM access results and batch DOM changes that cause reflows. Re-use DOM elements instead of creating new ones and adding to a large DOM tree
• Think touch before click – touch events on mobile devices happen much quicker than click events as click needs delaying to allow for double-tap to zoom. Check for touch support and add if needed.
• Web components are coming – with which we can get rid of lots of bespoke widgets we built in jQuery and other libraries. Web components have the benefit of being native browser controls with much better performance. Think of all the things you can see in a video player shown for a video element. Now think that you could control all of those

Right now the mobile web looks to me a lot like Temple Run – there is a lot of gold lying around to be taken but there are lots of stumbling blocks, barriers and holes in the road. Our tools and solutions should patch these holes and make the barriers easy to jump over, not become stumbling blocks in and of themselves.