Two days ago I did something new: for the first time ever I cycled to the place I was to give a talk. Two reasons: one of them was that the yellow thing that hates gingers was in the sky and the second was that Reasons to be appy took place in the LSO at St.Luke’s, which is 25 minutes by bike away from my place.

Reasons to be appy was a very packed one day conference about web apps and web development. It featured lots of great speakers and spanned quite a range of topics from typography, design and UX decisions up to debugging on mobiles. Each talk was 45 minutes with 10 minute breaks in between and a longer lunch break. All in all the format worked out pretty fine although I wondered if it wouldn’t be too much for the audience. There was no catered lunch, but it was simple for the attendees to go to the nearby market and grab something to eat.

My own talk, Moving your app-mind to the web (slides) revolved around the battle of native apps vs. web apps and some misconceptions we have about that clash. The screencast is available on vid.ly.

Here are my quick notes on the other talks, to see what you missed. Sadly enough there was no filming, but there are some slide decks available on lanyrd.

• Peter Gregson’s “Playing the Cello game” was an inspired keynote talking about his goPlay app that allows musicians to have much less hardware on stage to create the new kind of chamber music for the now. Great stuff and I thought it was a clever idea to start with a classical musician in a location like the LSO
• My talk was next – I hated that guy. So predictable to me
• Microsoft’s Andrew Spooner was next with “We, human” – a roundup of connected devices throughout history and what interaction with day to day objects and the web can look like right now – I missed half of that as I normally need a break after my talks
• Remy Sharp’s “Mobile Debugging” showed a lot of tools and ideas how to build and debug on various devices and was full of great “traps to avoid” information. It ended with Remy previewing the next generation of JSBin which allows remote execution of code on several devices
• Tim Ahrens’ “New Font Technologies for New Media” was an in-depth talk about web fonts, font formats and rendering issues across various devices, platforms and browsers. It was very technical and detailed but interesting. Together with Jake Archibalds’ In your @font-face this can help people a lot doing the right thing when using fonts on the web (hint: include the bold font if you use bold text. Faux bolding is awful)
• James Alliban and Keiichi Matsuda’s “Cell, Revealing the Digital Aura” was a talk about the Cell art installation at the Alphaville art festival which used a few kinnects and projection to show an “aura of tags” around people in the room symbolising their online identities. The project is pretty amazing and both Hames and Keiichi are veterans of visualisation and augmented reality. The talk was well structured and showed both their relationship in building the exhibit and the craft that went into it. The project is still going on and you can have it at your festival, too
• Mark Boulton’s “When there’s Muck, there’s Brass” was a talk about patina in digital products. Mark called out for products to be more honest in what they are instead of trying to be something else. Fake wood, leather and textures in interfaces on a screen don’t make them more natural, they actually promise a tactile experience that is not there. Mark’s presentation style is absolutely lovely, he just rants about things and reminds himself and us of good stories leading to the conclusion he wants to bring across. Always good value.
• Seb Lee Delisle’s “Pixelphones” is an experiment to turn all the phones of members of the audience into pixels and show animations and play games with the audience. Inspired by the Junkyard Jumbotron and of course the classic Blinkenlights it was once again a great example of how fearless Seb is when it comes to creating complex live code and push boundaries of audience interaction. Entertaining and fun. Now we need the source :)
• “Escaping Flatland” by Brendan Dawes had a bit of Mark’s talk in it as Brendan explained the joy that was physical objects with flaws and how we could bring the same imperfection into the digital world instead of making things perfect all the time. He also reminded us that to build future product we have to stop the fake nostalgia about old ones. Things weren’t better in the past – we just want to remember what was good about them

All in all I liked all the talks and got some nice inspiration for some upcoming projects. There was not much about apps per se in any of them (except for mine and even there I didn’t show any code) but the idea was to show what is possible with the new tech we have right now and apps as the new consumer products. I liked just how approachable all of it was – there was no stargazing or blue sky thinking but instead a lot of “this was great, let’s do that again” and a copious amount of swearing on stage.

With Microsoft/Ubelly being one of the sponsors there were all in all 50 phones given out to the audience and there was a lot of hugging on stage. It was also impressive to see how the ubelly team built and dismantled a whole living room setting with kinnects, touch tables and windows8 showcases over the course of a day. It reminded me a bit of the house-elves in Harry Potter.

The next conference of the same organisers will be Reasons to be creative, both in New York and Brighton.

Discussion. Responsive images. Picture too much? Srcset weird syntax? Brevity argument. Typing hard. People lazy. Let’s go shopping?

In other, more human, words: in the wake of the current discussion about responsive images and solutions using a picture element or the srcset attribute I came across an argument that always annoys me. And I fear that the more we use that argument the more we alienate ourselves from what the web is and how it became what it is now.

It is the argument for brevity in code above everything, especially markup. Shorter is better as it means people can type more and faster and there is less opportunity for doing things wrong. I call shenanigans on this.

XHTML’s failure was not the amount of code

The argument is based on the assumption that XHTML failed because it was far too much to type and too much work. HTML5 is considered superior as we only type what we need and we can even omit a lot of “optional” code as browsers are superb and will fix our omissions for us. We write much less and it still works. We call this pragmatism. Except it isn’t. It is laziness and the arrogant assumption that we write code for browsers to execute instead of people to read.

XHTML did not fail because of the amount of things you had to write. It failed because of the redundant things you had to write, its over-complexity and that it wasn’t supported the way it was meant to in the most used browser at the time.

And even that wasn’t the issue as nobody wrote all these overly complex constructs by hand – we have editors, templates and snippets for that. Code autocompletion is quite common. We were happy adding truckloads of Object/Embed code for movies until video came around and we never typed any of that by hand. We had tools for that.

Be productively lazy

Good developers are lazy in the sense that they don’t want to repeat themselves. Instead of doing the same boring and tedious task over and over again by hand we write a script to do it for us. This is what programming is for: allow humans to do better things than the repetitive tasks computers were made for.

If you write a lot of code and it never gets used that is frustrating. Very much so. It is also pointless work. However, the mistakes of XHTML should not push us into the other extreme of writing code for computers instead of writing code that executes and is easy to understand for people who want to learn or people who will have to maintain what we wrote.

Markup is different to other code

I love markup. I love the idea of – get this – marking up a document. Adding those funky bracket things around text and URLs is not about shifting bytes, accessing a chipset or setting an interrupt. They are there to give meaning to the texts and to the URLs they contain.

Think of them as highlighting texts with a marker and writing lots of explanations in the margins explaining the meaning of the highlighted texts. Think of them as the little booklet you get with Shakespeare’s Julius Caesar explaining to you what political, social or historical tidbits the author talks about that you would never get as you don’t live in that time.

Good markup brings meaning to text. Don’t take that away from the web for the sake of brevity and technical use cases that are possibly very short-lived.

The web we all work in right now isn’t the result of writing very clever and beautiful code nor is it the result of squeezing the last byte out of our documents to make them work perfect in a certain environment. Most of the atomic micro-optimisations and performance testing and tweaking we do can be undone by a single, badly coached and still well-meaning maintainer.

The web is easy to get into – let’s start with a clean slate

The web we have right now is the result of it being the most accessible media out there. You wouldn’t know how to put your photo and a big heading with your name in the newspaper or TV. But you can learn in a few minutes flat how to write a:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Chris' page</title>
</head>
<body>
<h1>Chris rules!</h1>
<img src="http://example.com/chris.jpg" alt="Photo of Chris" 
     title="that's me, that is">
</body>
</html>

Why the doctype, the head, the charset definition and the body? Surely the browser will do that for us?

Because the code above should be the result of someone caring about the web telling you that:

• The doctype ensures predictability in displaying your page
• Defining the language means search engines have it easier to index the page and blind users don’t suffer hearing text pronounced in a different language
• The UTF-8 means that if you need international characters they will show up instead of rectangles or question marks and
• The head and body makes a clear distinction where your visible content and the instructions for the browser go.

All of this can be violated with intelligent and amazing tricks and still be valid HTML5 and cool. I am quite sure that a few people twitched at the last point and disagreed as you can style title to be visible and scripts can go in the body and there are use cases for inline styles and so on.

The point though is that none of the above hurts a web developer to write and all of it has a purpose. A structure like that makes it easier for people to learn the basics of what we do. It makes our work predictable, clean, maintainable and – at least to me – professional workmanship instead of crazy and cool geek stuff. We get tied up in the latter and one-up each other showing just what is possible and we forget that people are watching and don’t spend the time to learn the basics. Case in point? The excellent learning resource Codecademy lately added a HTML 101 course, omitting the doctype and alternative text for images in the first steps. We start to see teaching as “showing the quickest way” rather than “showing the cleanest way that explains and yields results”.

We value instant gratification over working for achieving a goal. And the gratification you feel when you achieve something you had to work for lasts longer and feels better than the fast variant. This includes making mistakes and learning from them. Giving people an environment that is incredibly forgiving as the first barrier to entry doesn’t help people grow or reach the goal on their own terms.

Fostering a new generation of webmakers

At Mozilla we have a very interesting thing going: we set a goal for ourselves to foster a community of web makers. We do workshops with journalists on how to use the web as a platform for news and entertainment. We show Popcorn as a way to produce news items that can be maintained without re-shooting. We talk to children and find playful ways to get them into making the web rather than ploughing through apps buying them, playing them for a day or so and discarding them to buy the next one. For this, we use markup and a live editor in the browser. Check out the web arcade to see what I mean.

The next generation of people coming into our market should not be virtual couch potatoes who want everything to work magically and discard it when it breaks or gets slow. Tinkering with the web is what got us where we are. Playing with the open technologies and learning from what others did made us the developers we are now. The next generation should be allowed to feel the same excitement about making that we feel now.

Be brief, but stay comprehensible

Writing not much to achieve something isn’t cool. Writing the least amount possible, getting your message across and making it easy for others to build on what you did is. It means you are free to do other, better, and – for you – much more interesting things.

Let’s focus on tools instead of muddling the basics

If you really want people to write less and achieve more, help improve and build tools for creating in a way that shortens the distance between creation and seeing the result. There is a lot of exciting work being done in this field and we need something for those who don’t want to write code. As people in the know we scoff at the Dreamweavers out there, but it is also our fault when bad code ends up on the web as we were too arrogant to help those who simply want to get their content onto the web.

Summary: Browser War panels have become predictable and non-informative. Instead they are there to entertain the audience but cause much more drama than good.

I go to a lot of conferences. I organised events, a conference and a few unconferences and I spoke at a lot of them. Lately I also stepped back a bit to coach people to speak instead of me going everywhere.

I think conferences should do a few things: educate, entertain, allow people to network and make speakers and experts available to attendees.

You don’t need to go to conferences to learn things – all the information is on the internet and signing up to a few good feeds, groups and lists will get you all the info you want.

What conferences do is bring the human factor into it. A good speaker can make a topic come to life and show you an angle you had not thought about and inspire you to play with it. A good workshop gives you guidance how to use a technology and gives you a way in without being overwhelmed by a big scary topic. A conference gives you time out from the day to day delivery and allows you to do things that are not yet on the radar of your company but might be soon.

And then there are “browser war panels”. The original premise of the browser war panels was that an audience could hear the latest and coolest about different browsers and ask questions. The first ones were held at Yahoo and had lead engineers from the different browsers to show how the different products work as that was dark magic back then.

HTML5 defines how a browser should deal with the content it gets – we have a lot more predictability already in the standard. A lot of great information on this topic is out on the web and the accelerated speed of delivery of browsers makes the appearance of platform engineers not happening much. There is no need to repeat the standards, instead the discussions are much more about what makes which browser stand out and in a lot of cases this means what the company wants to promote – not what developers want to use now and get stuck as it doesn’t work.

Browser panels these days get people from companies who are either product evangelists of the browsers or general tech evangelists, advocates, or – in the worst case – sales people. This could be good, they can point out features that are in the browsers people don’t know about and they can show some of the plans for the future of the browser. It can also be awful. As browsers are interesting to the media out of a sudden you see a lot of patterns being followed. Instead of giving information about the browsers, dealing with concerns of developers and implementers or showing changes panelists begin to fall into predefined roles and repeat the messages of the companies they represent.

It becomes predictable to see which company representative will value speed over everything else, which one will praise a great experience in the browser as part of a bigger OS experience, which one will talk about following standards and complain about sites blocking out browsers and which one will point out that the browser is the choice of the user and should keep them in control by being open about everything whilst following standards.

The bigger focus on browsers we have these days makes a panel much less of an educational part of the conference (many a time you will get “I have to go back to the engineering team for this”) but pushes it into the entertainment part of a conference. It is a veiled sales pitch.

Everybody loves a good drama. You could go as far as saying that we have a whole tech journalism market that lives on drama. It is fun to see people disagree on topics and make good arguments about one side or another.

A quite open, unscripted and unplanned format like a panel makes for great drama. It is easy to take potshots at each other and score browny points with the audience with pointing out flaws of the other browsers in a glib fashion. It also gives browny points with the audience to make sweeping statements or deliver soundbites.

Soundbites, being witty and fast are becoming the most important part. If you look at the Twitter stream of a browser panel you will hardly ever find a “oh feature $x will ship in browser $y – so cool” but you will get more “$x of browser $y just called $z out on the $a issue”.

Soundbites are also loved by the press. And as drama brings headlines many a time you will find a sarcastic remark or glib retort show up as “Company representative $x said $y about the competition”. A quick shot to get a giggle out of the audience can cause the communications team of a company to get a lot of unnecessary work. Is that worth it?

I’ve even been on panels where the organisers deliberately asked panelists to find topics to disagree on or seen panel moderators throw out one loaded question after another to entice people to disagree and get the drama going. We call this trolling or baiting, and not a way for conference participants to learn about what is going on in the browser world.

It is not hard to find what is going on in the browser world when you look at the open source engines. You hear much less about the closed ones and to me a panel that has no participant of Apple on it is not a “browser wars” panel as it lacks a massive player who should answer quite a few questions web developers have.

There are exceptions. I thoroughly enjoyed being on the panel at State of the Browser 2 in London and I think as there were no egos and no artificial drama we managed to answer quite a few questions from the audience. But on the whole, these are few and far between and many a “Browser Wars” panel is entertainment and cheap laughs or “wow, did he just say that” moments.

This, in the long run, is not fair to the audience who paid good money (and should get real comedians or entertainers if entertainment is the goal), it is not fair to the platform engineers (as they are misrepresented instead of allowing people to peek under the hood with them) and it does not get us anywhere in the real “browser wars”.

As developers you should not be tempted to build for one browser only and you should not have to build different versions for different browsers. Keeping it all about drama and who shouts the loudest and comes across as most witty doesn’t make that happen. It is a waste of time.

When writing documentation or doing examples you constantly run into the same issue: how do you display and demo the code at the same time? You don’t want to have a code display and live code as they will get out of sync (on the other hand I always found that when copying code into a document I also cleaned it up and optimised it).

The easiest way for this are all the “new” services like JSFiddle, JSBin, Dabblet, Tinker.io and others (there seems to be a new one every month now) and you can even embed them into other documents, but it means you need an iframe and load content from another service (which might go down or get forgotten in the future).

The other way of course is to use Ajax/JavaScript to load the code into the page. Back in 2008, I wrote the Ajax Code Display script for that (and subsequently I never used it much).

I was wondering how you can simply demo and show inline JavaScript in a document without needing any extra libraries. The simplest way seemed to read out the innerHTML of the SCRIPT element and write it out into a PRE using textContent (innerHTML would render HTML or greater signs in the script, which isn’t the idea).

However, you can do a simple demo and display of the same script much easier these days using CSS. Check out this demo page for an upcoming Smashingmag article:

If you do a view-source you find no other script in use, yet it displays in the page. What is this sourcery^*? Simple, and it was Mathias Bynens who got me onto it: just display script elements as block and add some generated content to show the “Source” text:

script {
  display: block;
  white-space: pre;
  text-shadow:none;
  background: #333;
  color: #fff;
  font-family: monaco, courier, monospace;
  padding: 10px;
}
script::before{
  content: 'Source:';
  color: #0f0;
}

Mathias has much more detailed explanations on why that works but I for one am once again amazed just how much easier things are these days with the awesome browsers that we have.

^* Sourcery = magical code that does (seemingly) unexpected things.

Conference organisers: I also made a shorter cheatsheet with all this info for you.

Hi, I am Chris,

I love public speaking – so much that I spent most of the last five years on the road (with an average of 37 conferences a year in over 30 countries).

I am also a very busy man (yes, my Twitter stream might make you think otherwise, but I am not kidding) and I am getting roughly 200-300 emails a day and about an offer to speak each day. This is not boasting, I am happy that people want me to speak, and I don’t want to disappoint anyone.

If you’d like me to speak at your event send me an email with the subject [Speaking opportunity]. Please include:

• The dates and location of your conference
• The nature of your conference (who do you target, how many people you expect, how many talks will be there)
• The nature of the talk (keynote, workshop, panel…)
• If there are any travel arrangements or not (more on that later)

Speaking Terms

I am a professional presenter with lots of experience. Therefore I want to make sure that there is no misconception about what I expect and deliver.

If I speak at your event I will:

• Deliver a fitting talk for the intended audience. I am happy to discuss content with you but I will not send slides for review and allow changes by conference organisers. I tend to deliver a unique talk every time I can and it will be an up-to-date talk. This can not be achieved if I need to send in the deck weeks in advance. Slides to me are wallpaper of a presentation and I treat them as such.
• Deliver the talk on time and stick to the defined format and duration. I need to know what time frame you expect and what format you want it to be in. I will show up at the times you need me to be there and set up on stage with enough time for AV people to wire up microphones and other equipment. I tend not to need any dry-run or setup, but I am happy to do so if that is your conference policy.
• Use my own computer to deliver my talk. Many times I will go beyond slide decks and show live code and examples. My setup is a Surface Pro or Macbook and I will bring my own dongle and remote control.
• Attend your event to mingle with attendees. I do speak because I want people to learn something. Therefore I will take part in your conference to be able to answer people’s questions before and after my presentation or workshop. I consider parachuting in and out of conferences and only mingling with other speakers a waste and unprofessional demeanor for a conference presenter. We’re not rockstars or actors who deliver a concert or play and leave. That said, I can’t always be there for the whole conference, especially for multi-day events. I’d appreciate a schedule where you really need me to be there.
• Promote my presence at your event. I will tweet and blog before, during and after the event about what I will do at your event and interesting things I encounter.
• Publish my slides and screen recording after my talk. If there is a good enough connection, this normally happens right after the presentation. Everything I create at your event will be licensed Creative Commons unless otherwise agreed.

I expect you to:

• Provide me with a prime speaking slot. I’ve proven to be a good keynote speaker and find interesting topics to open or close conferences. I also work well as a moderator or on-stage interviewer. I don’t feel I am used to the best of my abilities for your event when I speak to a half-empty room in a side track. I am happy to promote and remind people of side-track activities though.
• Deliver a professional stage setup. I bring my own laptop and connectors, but I expect at least a power plug and a microphone. I am very good with audio engineers (having been one myself) but I am not there to fix audio issues or set up projectors. I expect this to work and be available. I normally don’t need an internet connection, but would love to have one.
• Record and publish my talk. As each of my talks are unique there is no danger that people can attend one they already have seen on the web. Recordings are a great advertisement for your conference.
• If possible, I’d like you to cover my travel and hotel. I am on stage and need to be able to concentrate on that. I can not do so if I need to find lodgings and organise travel to your event in addition to presenting. I don’t expect first class or business class flights, but I do expect to arrive a day before the event and leave the day after with lodging organised in between. I do not want to book and pay myself and get reimbursed. International payments are a mess and I don’t have time to deal with paper work in between events seeing that I am presenting almost every two weeks. I am sorry if that sounds harsh, but I want to concentrate on my talks, not try to explain to the tax department what all these invoices are about.
• Keep me out of sponsorship discussions. I am at your event as Chris and to present. I will not “pay to play” and I won’t speak at sponsored speaking slots. I am happy to provide you with contacts of who to invite instead when we negotiated my participation. I am also happy to introduce you to company colleagues dealing with sponsorships, but this is not – at all – what I do. If you are looking for a corporate sponsoring to sell speaking slots, I am not the person you want.

All this is a lot of work, and beyond what is generally considered practice for presenters. Therefore I expect professional treatment by the conference organisers the same way I am professional about this.

Some of these are negotiable and depend on the nature of your event. For example I am fine to cover my own travel expenses for a single track, independent, not-for-profit event, but I don’t see a point in doing the same for a commercial multi-track conference with a high price tag on the ticket. If you make money, it is just fair to share the load. I go above and beyond my call of duty as a presenter and I’d like to see this being appreciated.

Deal breakers

I am an agreeable person when it comes to supporting events, but there are a few things I am not happy about:

• I will not deliver sponsored talks and I am not interested in being asked to speak so you can get my company to fund your event. I want my presence to be disconnected from any sponsorship. Paid keynotes are terrible for all involved, the 90s are over.
• I will not come to speak at an event that supports any kind of harassment or offers a platform to presenters who bully others
• I don’t pay to play. If I can’t justify my time and effort to my employer to come to your event then I can’t come. Unless I take holiday and then I expect to be fully reimbursed for my efforts
• I don’t support events that didn’t make a good enough effort to represent the diversity our market should have. I am happy to introduce conference organisers to people I support and know to be great presenters on my behalf