Whenever I go to conferences I see lots of people running around with impressive SLR cameras snapping away furiously at everything that moves. When I get back from the conference and check the normal sources for these photos (Flickr, Facebook, heck even Picasa…) I get almost nothing. This wasn’t the case a few years ago – almost every conference was well documented by amateur photographers and yielded lots of great comments and conversations on Flickr.

I am not alone in my analysis – @yaili complained on Twitter:

@yaili: Flickr needs more @dConstruct 2010 photos. How am I supposed to feed my post-conference blues?

And I agreed:

@yaili over the last year less and less people upload photos from conferences. annoying. Everybody runs around with SLRs and shoots a lot.

I did talk to people with impressive photo gear and a lot of them agreed never to upload much. There might be a few reasons for that:

• People take photos in high resolutions – and wireless at conferences is not able to cope
• People who spent a lot of money on massive cameras aspire to be a real photographer and are reluctant to upload photos that haven’t been perfected in Aperture or Lightroom
• People just forget as by the time one event is over the next is on.

This aim for perfection leads to a lot of people missing out. Why not upload lower resolution photos as “raw” or “live” to Flickr and at least allow people to join the fun. It sounds to me like Worth1000 vs. B3TA – both had the same goal – funny photoshop manipulations. Whilst Worth1000 had strict quality control and only the most impressive stuff got released b3ta is all about the joke, then the technique. B3ta left its mark on mainstream media with magazines republishing content and some TV ads being made by artists who started at b3ta. Worth1000 is still a web community and seems to dwindle down to another “make better photos” resource. Allow yourself to release non-perfect products – and more people will find you.

Interestingly enough the post-conference follow-up fail goes even further. As Stuart Robson pointed out it takes too long to get the slides:

StuRobson @codepo8 I wonder what they’re doing with these photos at home. I’m just forever waiting for the slides to go up. #Iwillgettoaconference1day

Both of this is a real shame, as organisers, speakers and the amateur photographers miss out a massive opportunity to create more buzz about the conference and themselves.

• Conferences create a lot of buzz on Twitter – your photo could give that a visual add-on. If you license your photo with CC large blogs and newspapers could use them and have to mention your name.
• Slideshare is a large community and your slides being featured as part of a conference channel or even on the homepage has quite an impact. This could be as simple as your presentation being the first to be uploaded for a large BarCamp
• Speakers who do publish their presentations and blog about the conference always look for good photos of themselves. As it is hard to shoot those whilst you speak (I normally give my camera to a friend) I for example troll Flickr immediately when I get back from a conference. If you shot a cool photo of me, I will use that and link your name.
• People who missed the conference will get an idea of what was covered and how much fun people had – and will get a ticket next time.

So, please share, folks – the web needs you!

I just got back from Frontend 2010 in Oslo, Norway. Two days of excessive drinkinggreat information about designing and building the web of tomorrow.. I was invited as a speaker alongside a lot of great people and my task was to give the last presentation of the conference to sum up a bit what we had heard about and what to do with it when we get back home. And this is what I did. Here are the slides. More to come later when the video is out and I am not using my almost empty Nexus as a hotspot as the British Airways wireless is FAIL again.

Yesterday Framsia organized a meetup in Oslo, Norway with Molly Holzschlag, Paul Irish and me ramping up to the Frontend2010 conference. Molly talked about the open web and the open stack of technologies and Paul showed people the developer tools in Chrome.

My talk was about building web applications with JavaScript and how using progressive enhancement helps you build great things with very few lines of code. The slides are available on Slideshare:

As per usual, I also created a audio recording of the talk hosted on The Internet Archive:

I loved the evening – the location sponsored by Epinova had all the things we needed (including a copious amount of beer) and the audience (once warmed up) had some very good questions to answer. The talks were filmed and Framsia will release them soon.

One of the things that gets me excited about the new features of browsers is the “HTML5” Web Storage module. I like it mostly because of its simplicity.

The Web Storage idea is to simplify storing of information for the user. I always hated using cookies because of all the domain issues. It was also a mess to check for them and then fall back to other things. Most of all people are paranoid about them and I know a lot of corporate computer users who have all cookies disabled.

Web Storage on the other hand is a simple object in the browser. You can set localStorage.foo to ‘bar’ and when you read out localStorage.foo next time you load the document it will be ‘bar’. That’s how easy it is. You can store 5MB of textual data which could be integers or strings. With JSON.stringify() you can easily store more complex information.

So I was wondering what you could use that for to get the most out of it and I realised that in a lot of cases I render simple HTML in PHP and then do some clever stuff in JavaScript to make it a different interface. If I wanted to retain the state of that interface I’d have to somehow store it in a DB so next time the user comes to the site, I re-render the last state of affairs.

With localStorage you could do that by simply caching the innerHTML of the main app (if you build it progressively):

You can check the source of the trick in this Gist on GitHub:

If you don’t get what I am doing here, check this quick screencast:

I’ll be using that a lot – it is terribly simple and yet powerful.

Lately I find more and more people in comments fighting for the need for “view-source” in our web products and claiming it to be a “vital part of the open web” and a “great way of learning for new developers”. This ails me as it is in my point of view a very outdated idea of learning and building web sites. I am not saying that view-source is not important – I am saying that there are better ways of learning and analysing code.

When view-source was king

Back in the days when I started working on the web you learned by looking at the source code of other peoples live web sites, copying and pasting what they’ve done and reverse engineering the workings to see how you can use or improve it. This is how I learnt JavaScript as there were no free blogs, tutorials or articles out there to tell me. The books available (basically the JavaScript Reference) dealt with the technologies themselves and not their application in a browser world. JavaScript for example was still considered a toy language in comparison to the mighty Perl or ASP or PHP or Java.

A few years before the web I learnt Assembly Language by analysing games on my C64 and trying to get endless lives. I did this by freezing the game, checking the part of the screen that changed when I lost a life (the counter) and then hunting through the memory to find the code that altered the counter on the screen (finding the DEC). I learnt how to cheat the system – not how to write Assembly Language. That came later when I had spent a few years reverse engineering.

That kind of commitment we don’t have time for if you want to learn web development.

View source gives you a view and not the source

Despite the time spent, the problem with looking at a web site with view source is that you don’t see the source, but you see a view:

• If you build web sites with performance in mind and in high end environments you send browser-optimized views to different browsers. This means that learners would see what is optimised for Firefox and then try it out in Safari. Or worse, they see what we need to jump through to make old IEs behave and consider this the best way of developing.
• Live code is normally minified and concatenated and has comments removed. So you learn the how but not the why. Some of the things you see might be terrible hacks but necessary for the environment used to build the web site.
• Checking generated source is even worse. Browsers add browser-specific code that the original writer never added.
• Live web sites are normally built by committee and have a lot of things in them the developer feels dirty about: tracking codes, third party ads with ridiculous code quality, quick hacks to get the thing out the door at the agreed time and date.
• Most web sites these days are not written by hand – if you build for the web and you don’t use the power templating, CMS and databases and web services offer you are missing out on a lot of great opportunities. HTML is the end product of a methodology and a build process – not the start of it.

Open source is the new view-source

If you really want to learn about how web sites are built and how to use certain technologies, look at the source code repositories instead. GitHub, SourceForge, Google Code and all the others are full of great examples. This is where developers communicate with each other and show off the newest technologies.

As the final product is created and not written by hand you will find the important comments as to why something is the way it is there.

Say my entry to the 10K competition World Info. If you look at the source code you will see minified JS and CSS, all of it inline. I would never code that way. This is the result of a build script. I tell the world that:

If you look at the source on GitHub you get step by step comments how I have built the solution.

What would a new learner get more information from? This was not much more work for me – as I document where I write I keep things up-to-date. Even more interesting, I actually fixed a few problems and change my code while I was documenting it – as I was forced to look at it again from a different angle after having written it.

Learn the why not only the how

The main problem with teaching people how to become good web developers is that there is a massive lack of patience. Instead of realising that knowing the syntax of a language doesn’t make you a developer we think this is all that is needed. It is like learning the grammar of a language and then trying to communicate without having the vocabulary. Or analysing the syntax of a poem without looking at the metaphors and their meaning or the historical environment it was written in. Most of what makes development and writing art and craft is lost because of the lack of patience.

W3Schools is a great example. It tells you the quickest solution and gives you something to play with. This is why it is massively successful. It is a terrible resource though as it doesn’t explain what can go wrong, when this would be a bad solution and it gives people the idea that they know everything by knowing the syntax. The PHP documentation is better as you learn in the community comments how to apply the functions and how they fail.

If you really want to learn about web development and standards then there are a few very good resources:

• The Opera Web Standards Curriculum
• WaSP Interact
• HTML5 Doctor
• CSS3.info

And far too many personal blogs that I could list here now. None of these are 2 second lookup tasks – but once you went through some of them you will know the why and the how and you will be able to see what is sensible to take on from a source view and what is probably not that a good idea.