Yesterday Edgeconf attracted about 150 (my guess) bleeding edge web technology enthusiasts to come to the Facebook offices in London, England and listen to seven panels of experts.

Over the day we covered Offline storage, Network detection and optimisation, Performance, Responsive Layout, Input formats, Privileged access to hardware and Testing and Tooling. The format was slightly different than other conferences. Each panel consisted of experts from various companies heavily involved in the subject matter and the audience and people not attending the conference could submit questions beforehand that were selected and collated by an expert moderator. The panels had a ten minute presentation easing the audience into the subject matter and then it was free Q&A using the submitted questions and audience participation.

The weapon of choice for all this was Google Moderator, a tool built for that purpose and heavily used inside Google. All in all the message of the conference was to go deep and detailed on a subject matter and to stay as brief as possible – 30 to 60 seconds answers at the most.

The conference was jam-packed with very detailed information and the attendees had a good chance for the low price of 50 GBP to meet experts and get their questions answered. Break-out rooms also allowed for unconference-style impromptu sessions but I am not sure how much they were used.

All the sessions got video recorded, transcribed and the videos will be available with time-stamped transcription for easy access to the sections that interest you.

All the coverage of the event will be published on the conference hub page.

I was very impressed with how the conference was organised and run. Andrew Betts and team are incredibly detailed and there was no question from me how my session would go or how to contact the panelists. All the communication and collaboration happened painlessly over email and collaborative web tools and the day ran like clockwork. This is of course also very much thanks to Facebook offering the location and Google the filming and transcribing.

A nice little touch was that at the end of the conference there was a full disclosure how much money was made and what it was spent on. The 3000 GBP extra were donated to Codeclub.

Edgeconf was very much value for money with the incoming funds going into recording and making the results of the show available to everyone, food and travel for the experts. There was no merchandise, no overly aggressive marketing or obvious sponsorship. Everybody involved was an expert who needed to be there. I very much enjoyed that and it was refreshingly different to bigger shows that run on more traditional concepts of marketing and sponsorship.

It was a very intense day of detailed information and there was no lull in the whole show. For a one day conference this is perfect and I am sure that there will be more sequels to come. I have to congratulate everyone involved for putting on an impressive show and getting everybody organised without much hassle.

I am right now at the Firefox OS App Day Berlin and just delivered and introductory talk on how Firefox OS can empower HTML5 by being the platform to treat it as a first class citizen. I also commented on the declining hype about HTML5 and issues we are facing with it.

A screencast is up on YouTube and the slides are on the web.

Yesterday I tweeted about The Procatinator, a web site that loads a random cat gif and music every time you click a button. Most people very just happy to get some damn good internets but one reply to me was sadly predictable:

@janl: @codepo8 please don’t link to flash BS.

Burn the witch! I dared to link to something that uses Flash. The same Pavlovian response happens every single time I embed a YouTube video into a blog post about HTML5. Flash is the enemy! How dare I fraternise with it?

Well, in the case of YouTube embeds, there is a reason: I was asked by quite a few people not to include my own hosted video files as they live in areas with slow connectivity and using the Flash embed gives them videos that are terrible quality, but viewable and skip/scan-able on their connections instead of downloading a relatively massive file.

Furthermore, the joke is on the people complaining about Flash YouTube videos, as I am using the iframe embed, which gives HTML5 video to those who opted into the HTML5 trial of YouTube. That someone who loves HTML5 that much that they need to complain everywhere it is isn’t used didn’t do that is unlikely. Or, more likely – they are trolls.

There is nothing “ironic” about using a tool that is widely used to talk about another techology, as eloquently explained in Jeffrey Zeldman’s rant on the subject.

But back to Procatinator. Procatinator is “Internet Whimsy” at its best.

It is there to make people laugh, waste a few minutes not answering emails angrily and has kittens and music. It already skirts on the illegal by using YouTube videos without showing them but playing them as music instead and the code shows that it was done as a fun project and nothing more. And you know what? That is fine. Important is the end result here, nobody gives a hoot about the technology used or the code quality. Nobody but us self-appointed defenders of the open.

If you want to reach as many people as possible, you use whatever works. This is why imgur is full of texts in JPGs without alternative text or text equivalents. These are easy to create and style and can be redistributed in every environment, including those that do not allow HTML like Facebook or Google+. Professional whimsy providers of the web of course also put up a text equivalent to get Google to index their site as a resource as Blame it on the voices shows.

Animated GIFs had a massive comeback last year. The reason is not that they are amazing quality or small in file size – the opposite is the case unless you really know what you are doing (pro-tip: perceptual colours, no dither, 10% lossy, drop those tween frames). The reason is that they are simple to produce and work everywhere that can display images.

So, Flash. Why is it not the enemy? It is closed and alien to the web, after all!

Without Flash, the web as a content distribution platform wouldn’t be where it is. There, I said it. And the reason is the Internet Whimsy we like to scoff about as “waste of time” and “amateur work”. Without Flash we wouldn’t have had Homestar runner, we wouldn’t have had Joe Cartoon and the famous Gerbil in a microwave, we wouldn’t have Weebl and Bob, we wouldn’t have played all the games on Newgrounds and many more.

I talked with this the last time I visited Rob, founder of b3ta.com and we chatted about my job. Rob is a producer of content, most of it Internet Whimsy but with a background of doing it professionally for professional content. And his main point was that Flash makes it damn easy to get something out there and it is all about that. The half-life of content on the web for him is much shorter than it is for me, the guy who cares about code and content quality above all. Using Flash and its tooling it is simple to create a quick animation with music and get it out there.

And this is what it boils down to: tooling! We shouldn’t complain about Flash being used, we should make sure we build tools that allows content makers to publish their work in open formats. Mozilla’s Webmaker initiative is all about that and Popcorn can be a great tool to make your first interactive open technology video using the familiar time-line interface of Flash. Even better, Adobe, the people behind Flash are working on tools to allow content creators to render them out as HTML5. If anybody knows what people who choose Flash need, it is them! Why don’t we as a self-appointed spokespeople of open tech promote and support these efforts instead of complaining about the use of Flash?

So what about Procatinator, does it really need Flash to work? Yes and no. Yesterday night I spent half an hour to create an HTML5 version of Procatinator using much simpler, plain JavaScript, CSS (using background-size instead of stretching the GIFs with jQuery) and using the YouTube IFRAME API and the YouTube Data API. I yet have to put in the permalinking option the real one has and the syncing is not as smooth as I don’t wait for the GIF to be loaded.

So hooray, Chris saved the day and opened what was closed! Rejoicing all around. The question we have to ask ourselves though is what we gained by that? The main reason why people complain about the use of Flash are:

• They have no Flash and don’t want it
• Accessibility concerns (in a lot of cases based on old information about Flash and assistive technology)
• It doesn’t work on iOS.

The latter being the real clincher. We are excited about our expensive Apple toys and are affronted if someone publishes their content in a format not digestible on our very closed platform. How dare they not support the thing “everybody has”?

Well, it turns out that the non-support in many cases is by design as iOS doesn’t make it easy to support it using open standards when it comes to audio and video.

In the case of Procatinator I told the makers that they could use the YouTube iframe API to ensure HTML5 support instead of a Flash dependency. Not so. The main issue is that Procatinator needs to start playing the song automatically, and in iOS any HTML5 media content needs to be activated by the user to start loading and playing. As the video in this case is not visible and just a background music provider and there is no “audio only” API for YouTube all my efforts didn’t make a difference. By design of the operating system our hands are tied. And, as developers, we should scream and complain about that – not about people using what works.

All in all, the big hurdles we need to jump when it comes to making the web open is not telling people off for using what they know. Our job is to provide the tools to make it the simple choice to use open technology and to create as many high-profile sites and products that point out that a lack of functionality is based on the platform not allowing it instead of the technology being insufficient.

What we have to avoid at all cost is bringing up a new dependency layer for end users. It is ridiculous to complain that Flash needs installing when we build “open HTML5 technology solutions” that only work in one browser or expect the end user to set a developer flag or download a nightly build. This is not about users being slow on the uptake, this is about us getting too excited about our toys. Let’s move our efforts and apply our knowledge to making it easy for people to use the open web. We are not in a position to demand anything from them, as if we do, we’ll lose them. Not to Flash, but to native technologies.

Discuss? Google+ thread and on Facebook

Today I played again with drag and drop and HTML5 canvas. The result is a tool to pick colours from images and create the corresponding CSS/HTML called Zoom and Pick

Here’s me explaining what it does in a screencast:

• Zoom and Pick to play with
• The above screencast on YouTube
• Zoom and Pick on the Mozilla Demo Studio
• Zoom and Pick on GitHub

I will follow this up with smaller demos of parts of the whole on MDN soon. The biggest fun part was creating the zoom functionality.

By request: if you want to comment on this, here is the Google+ post and the one onFacebook.

Criticism is a good thing. I am a fan of sensible disagreement and people challenging each other to think different about their work and change their attitudes after seeing a different point of view. Margaret Heffernan’s Dare to disagree TED talk is a great resource to watch if you wonder how that can work. This is what editing is about. A good editor can make a book or a movie much more than it is by challenging the author or maker to go further and think bigger.

Badly executed criticism however can scare, stifle and make people feel like a failure although all they might have done is a small mistake that can be easily rectified.

Good criticism takes time and effort. A good critic doesn’t only point out that something is flawed, instead it is important to explain what the flaws are, what their impact on the overall quality is and what could be done to improve. A bad critic flat out tells what should be done, believing in a subjective truth or way of working formed by the critic’s own environmental influences. That way the critic might be as far off the mark as the person criticized.

I just spent a few days at hack events helping people port their existing or build completely new apps. It was very insightful seeing a massive range of developers in different stages. I was most confused to see people who have very good ideas getting stuck at technical problems and when I showed some ideas and solutions being met with overwhelming thankfulness. When I asked these developers about their experiences in asking people I heard a lot of “Well, I am scared to ask as I don’t want to sound stupid online and people are quick to discard what you do as terrible”.

This saddens me. I, like most web developers I know, learned by looking at other people’s stuff and poking and changing it until it did what I wanted. Then I looked into why it works and spend months of my life on mailing lists and forums asking for and giving ideas and advice. Of course we all said terrible things in heated discussions and prematurely dismissed things, but in the end there was agreement – there was a feeling of having to communicate to become known and get to know people closer that you can learn from.

Enter social media and a 140 character throw-away, realtime web feed fast world of who says the most outrageous thing and “is awesome”. The pace of social media and its fragmentation (do you post on Twitter, Facebook, Google+, GitHub, your blog, JSFiddle, JSBin or where?) is a breakneck environment and it leads to people acting – possibly unconsciously – like complete sociopaths.

Case in point. Over on her blog, my colleague Heather Arthur describes how a piece of software she wrote was mercilessly shot down on Twitter by people other people look up to. Heather felt awful because of that – not only because she was criticised, but mainly because there was no explanation why her code was deemed bad.

This unknown element can make it very easy for anyone to find the flaw in themselves:

At this point, all I know is that by creating this project I’ve done something very wrong. It seemed liked I’d done something fundamentally wrong, so stupid that it flabbergasts someone. So wrong that it doesn’t even need to be explained. And my code is so bad it makes people’s eyes bleed. So of course I start sobbing.

Some of the people who shot down her code in far too short messages lacking any context and information now apologised and there were some good quotes in there:

I am sorry. I feel terrible that I made someone else feel terrible. I feel even worse because I didn’t mean to say that they were terrible, but accidentally did.

It is easy to forget that people write code. But it is important that we don’t forget that. Writing code is easy, putting it out in front of the world isn’t.

Heather ends with a very good point:

I evangelize open source whenever I meet new coders or go to meetups. I tell them to make something that they would find useful and put it out there. Can you imagine if one of these new open sourcerers took my advice and got this response, without the support I had. Can you imagine?

By being too fast and not detailed enough in our criticism we might actually right now discourage a lot of new people who could create amazing things in the nearer future. This is sad.

I am lucky that I have followers on Twitter (amongst the trolls) who are not afraid to point out to me when I am overly harsh or glib about something. I try to make amends when that happens and find that I learn more and more every time I do and it taught me quite a few things.

Let’s see a great example of how things could be done. Jan Hančič posted the other day Load scripts and styles with one request and I read the post and went a bit “uhhh, I am not sure” about it. Then I found a comment that perfectly covered what I wanted to say and didn’t hurt Jan at all:
——
Hey Jan,
Glad to see people hacking around; coming up with new ideas is always a good thing, no matter how realistic they are (the important here is to stretch our imagination).
Btw, the approach you describe has not been done by anyone else in the past, and I believe it’s for a good reason: it doesn’t help… Mixing CSS and JS is a bad idea IMHO, for many reasons:

CSS Is loaded in parallel by the browser, while JS is not;

CSS is loaded in the head (before the DOM is rendered), while JS is generally loaded generally in the body for performance reasons;

Minification of CSS and JS works differently, so including one into another is looking for troubles;

In a decent sized application, with a moderately big codebase, putting everything into 1 single file could end up with an unmanageable big file;

loading it in 1 single chunk would prove unpractical; either you end up with FOUC or you get a white page until the file complete loading by your browser; Moreover, loading 1 single minified CSS file and 1 single minified JS file is generally more than enough in terms of optimisation.

I’m not even considering that recent talks/rumors at Google seem to indicate that modern browsers are nowadays extremely optimised and performant also when downloading multiple resources (it was an Angular guy that glanced over this concept in a recent screencast..) Btw, don’t give up trying; Crazy Ideas can sometimes lead to great discoveries ;)

Cheers,
Davide
——
See what happened here? Instead of throwing out a quick “this is stupid” remark Davide Alberto Molin criticised in a picture perfect way: he started encouragingly, pointed out that this indeed is a new idea, listed the technical details that makes this idea flawed citing examples and ends with thanking Jan for throwing the idea out there and encourages him to go on doing that.

This takes time, this takes effort, but it has overall positive results. Jan was happy to get the comment and learn from it, I got a massive respect for Davide (someone I never heard of before) and Jan can update his post or follow up with one that takes the technical issues into consideration.

Long story short. If we want to encourage people to go out and show the world what they did (and we all learn from that) we need to stop dropping dismissive short sentence criticism and instead spend more time to explain, verify and validate our criticism. That way we can still prevent bad code from being used, but we don’t come across as a terrible person at the same time.

As Steve Klabnik puts it succinctly:

Twitter makes it so hard not to accidentally be an asshole.

Let’s use channels that allow us to give context and explain the why of our criticism instead – if it is code on GitHub, the issue tracker is a great place. We can still send a Tweet out pointing to our criticism there – thus showing that we are out to care and improve and not to harm and win the internets.

photo by Hobvias Sudoneighm