A few weeks ago Michael Chaize came to the London Mozilla office to shoot interviews with me for the Appliness magazine by Adobe. This edition is now out and can be downloaded from the iTunes store or the Google Play store. There is also a non-interactive PDF version out there.

He did a great job filming the office and my teaser video explaining what the Mozilla London office is about and what is happening in Mozilla.

If you don’t have an iPad (like me) you can see the 3D view of the office at the end of the article also in this video.

Great job, Michael, I am chuffed to bits how that worked out – even when I was attacked by a vicious red dinosaur.

At the fluent conference last week Nicole Sullivan gave an interesting keynote called Don’t feed the trolls:

I liked this very much. We need to fight the current culture of animosity, one-upping and “winning” on the web and turn it towards a culture of nurturing each other and that values communication and agreement instead. The main techniques to do that were outlined by Nicole:

• Understand your own prejudices and communication failures
• Respond to what makes sense and is the human part in troll mails and posts
• Don’t feed trolls – don’t fall for baits

Nicole works through a few kinds of trolls, jealous trolls, the grammar nazi, the biased troll (and the trolls who look for bias where there is none) and the scary troll. She alludes to another, which I will cover here:

The accidental troll

In her talk, Nicole defines a troll:

Def. Troll – people who seek conflict

Now, I have been called a troll a few times, and it hurts me every single time. I am not a person to seek conflict – at all. I am very uncompetitive and the best way to bore me is to tell me that $x does things better than me. Good for $x. I am not $x – I can look at what $x is doing and see what I like for myself but I shouldn’t copy it as it is not me. I want to be better myself tomorrow than I am today as I am the person that is with me all the time. If you don’t compare yourself to yourself and get better you play catchup and become the “good” that is somebody else. You have your own, unique way of learning and communicating and you should hone and celebrate that. If you get home and the door closes and you are someone else then there is a problem. This is for actors and rockstars who tend to die in drug overdoses.

So how come people saw me as a troll or gave me the “Don’t be hatin” message that pretty much insults the grammar fan in me? Because I posted in anger. I was pissed off – somebody was wrong on the internet and people even applauded and quoted it. This will not do.

Cultural differences

Part of this is cultural. Europeans, especially Germans, are a direct bunch. We say it like it is. If we want something, we request it. If we don’t like something, we make it obvious without a doubt that this is the case. America, on the other hand is not like that. Everything is about not offending people – not because this is bad, but mostly because you can get sued if you do. How this works in a society that is highly competitive at the same time continuously baffles me. There can’t be any losers in any competition, just third, fourth and forty-eighth winners. This dilutes the idea of competition to the degree that people don’t take them serious any more. In Europe, not so much. A competition is something serious and to win, someone has to lose. The same applies to conversations. Meetings in the US are considered a success if everything was mentioned and nobody was affronted or feels bad coming out of them.

In Europe, the result of a meeting is what has been done and what needs to be done next by who and by which date. If that means someone got blamed for doing things wrong, that is just how it is.

Pointing out an error is not attacking the person who made that error. What it is is pointing out an opportunity to fix something. This is the end goal. A lot of people have problems admitting to failure. To me, a failure is a great opportunity to analyse what happened and making sure you don’t do it again. If that hurts, even better, as it is easier to remember for you not to do it.

With this background it is easy to affront people on mailing lists and other communication devices that lack human communication (body language, voice and so on). The problem is exacerbated when the thing that – in your book – is obviously wrong gets sold as a “best practice” and gets a jazzy marketing-ish abbreviation and people quote it all over the place. Something you consider a mistake becomes something other people strive for rather than being something to learn from by avoiding it.

Countermeasures

So here is what I do now. I channel the Fennec:

You notice that this animal is much more ear than mouth and this is what we should be doing. Instead of firing up a massive post ranting about what is wrong in a certain publication or person we should start asking questions and most of all listening. The same applies to humans: we have two ears but one mouth – let this be our ratio for learning.

So if you disagree with something and it really rails you, give it some time before you answer. Do other things, have fun with people. Then go back and write your post if you still want to. Even better, ask the right questions.

By asking for refinement and pointing out shortcomings of a solution in the form of a question you do not only bring it upon you to do better than the original solution. You also turn your anger into a chance to get the original maker to take on your refinements and make the product that angered you work better. If the original author can not answer your questions you managed to show that they made mistakes and called something a best practice prematurely. And other people listen, too. Which means that they’ll request more details and changes.

Another way of listening is to read all the other posts and comments following the thing that annoyed you. You’ll find that in a lot of cases other people will point out the flaws you see, too and you can join a conversation and maybe even soften the tone of other comments to turn them from flame to request.

All in all a lot of accidental trolling happens because we get the wrong urge to answer as fast as possible and be the first to point out a flaw and thus winning 245 internets. Letting things sink in first and listen for a while helps you write better responses, realise that some sins are not really that much of an issue and make you understand the context of what something was published in, which can be a large part of the content decisions.

Earlier today at Over the Air 2012, I gave a keynote about Lego and how it relates to the differences in native apps in comparison to web apps.

The slides are on the web and the screencast is on vid.ly and on YouTube:

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.