I am right now offline at an airport and closed Aurora for the first time in a few weeks so I had time to read all the tabs I opened but haven’t covered anywhere yet (except for a small tweet here and there).

I thought it might be a cool idea to publish those when I find they pile up as a reading list. Do you agree? Well, here goes, this was open:

• It is silly but the Tea Rex makes me want to drink more tea. I am also a big fan of the Tea Sub.
• Jeffrey way has a genius command to start a server for the current directory with one line of code on the terminal.
• Skepchick has an incredibly annoying article by Rebecca Watson on atheists on reddit being nothing but misogynist ass-hats. Seriously, banter is all fine and good, but making jokes to abduct and rape a 15 year old girl is not really the behaviour open forums should tolerate. Or, if we keep not caring about that we shouldn’t be surprised if the powers who want to censor the internet will get there.
• URI.js is a script for working with URLs. It offers a “jQuery-style” API to read and write all regular components and a number of convenience methods like .directory() and .authority(). We talked about this at the smashing meetup #3, and now it is out.
• Everything for free, always: how Facebook ads show us the sad state of the Internet is a stark reminder that the “we want everything for free” attitude towards the internet as a media is not helpful in the long run. Paying $2 a year(!) could ensure that Facebook is not selling you as a product to advertisers. There was also a great article “don’t be a free user” on that topic on the pinboard blog. My favourite quote was this:

  Most people aren’t willing to pay for services or content on the Internet. There is an expectation that everything should be free, and that at the same time, companies should respect our privacy and keep The Brands™ away from our personal information. It’s not a realistic expectation – something’s gotta give if no one is willing to pay for anything. But most people don’t think about it long enough to realize that.

• Cedric Dugas published a rant about the Occupy Flash site (I can’t call it a movement) in It’s never been about the open web. Cedric has some great points, especially the washing out of the term HTML5 as anything that was added to the web stack for the last two years. He praises Adobe for turning around faster than the W3C and that Flash’s APIs are much richer. Cedric has some good points but it is a rant. The argumentation is very one-sided and not mentioning Mozilla at all when it comes to the open web is just sloppy. In essence the rant is the same arguments native app developers bring up when they talk about web apps. Things can coexist and – as Cedric rightfully says – using the right technology for the job is part of our task as developers. The main thing he fails to mention is that open web tech is for us to change and be part of. If it doesn’t move as quickly as it should then rants like these and fanboisim like Occupy Flash are to blame.
• I don’t write “JavaScript” is already a bit older. It is an explanation of a Twitter developer about the lack of semicolons in Bootstrap. In it we learn that JavaScript is forgiving when it comes to syntax and that it is fine to omit curly braces and semicolons as the JS parser does all that for us. And if you don’t agree then you are probably one of those guys who love Crockford and are too strict to be taken serious as web developers anyway. Yesitistotallyfinenottosticktoasensiblesyntax. YoUcANProbaBLYreadTHIS. IFitI5EA5Y4UisTheQuestionWeNd2ask. Personally, relying on semicolon insertion in your code is lazy and the same arrogance we had with table layouts in HTML - hey they worked, why bother doing things in a more maintainable way?
• Which brings me to a great post that repeats things I have said for quite a while and lived by throughout my career: “My Career Advice: Make Yourself Redundant“. The idea of being the one person who knows something as a means to stay in charge and in a job is outdated and – if you think about it – in a market where the average retention rate of talent is three years borderline ludicrous
• In “Let’s start recognising the hidden gems within our community” my colleague Robin Hawkes ponders about changes in the awards sites and events of web development and that they should focus on new, unknown people rather than being a popularity contest with the same people year after year. Some good ideas there, but I for one would be happy not to have any awards at all. We are not Hollywood and we don’t need Oscars. Our work should talk for us and not a fake celebrity cult. I remember in the beginning we had “cool internet sightings” web sites and “site of the day” as the topic of #html on IRCNET. More of those accompanied by a making of would be interesting. Unknown people could show how they got successful by taking a different approach.
• In “Constructive feedback, not destruction and damnation” my good friend and even better egg Chris Mills talks about the hoo-hah of the “bad speakers list” on Twitter a few weeks ago. He explains why new speakers are needed, why bad presentations happen and how it is our job to encourage and nurture rather than damn new talent who takes the plunge to go on stage and talk about what they did.

The year is over (well, almost) and I thought it’d be fun to list the conferences I attended and spoke at. You can see the 2011 archive here or below:

All in all: 29 talks, 15 videos, 23 audio recordings, 37 conferences
Date	Conference	Location	Title	Slides	Audio	Video
01/28	Heart and Sole	Portsmouth, England	Time to build a better web	slides		Vid.ly
02/04	FOSSDEM	Brussels, Belgium	Moving to the client – HTML5 is here	slides	MP3 OGG
02/08	London Ajax meetup	London, England	Using HTML5 sensibly and multimedia on the web	slides	MP3 OGG	Skills matter
02/10	MF Boat event	London, England
02/17	London Web	London, England	Finding harmony in web development	slides	MP3 OGG	Vimeo
03/09	ConFoo	Montreal, Canada	Moving from hacks to solutions	slides	MP3 OGG	YouTube, YouTube #2
03/18	Login	Vilnius, Lithuania	Building a better web with open, new technologies	slides		YouTube
04/14	Funkas Tillgänglighetsdagar	Stockholm, Sweden	Accessibility and web innovation (slides, audio and notes)	slides	MP3 OGG
04/16	W3café accessibilité	Paris, France
04/20	JAX	Mainz, Germany	HTML5 Das Web und der Browser als Platform	slides	MP3 OGG	Vimeo
04/20	JAX	Mainz, Germany	Wie JavaScript die Welt eroberte	slides	MP3 OGG
05/10	Google IO	San Francisco, CA, USA
05/30	Webinale	Berlin, Germany	HTML5, CSS3 und JavaScript fuer alle	slides	MP3 OGG	YouTube
06/07	Inspire Conference	London, England	Mentoring
06/17	Web2Day	Nantes, France	HTML5 and the web of tomorrow	slides		video – interview
06/25	Converge SE	Columbia, SC, USA	With the power of HTML5	slides	MP3 OGG
07/08	Highland Fling	Edinburgh, Scotland	Moderator
07/16	Open Web Camp	Palo Alto, CA, USA	HTML5 battles still to be won (slides, audio)	slides	MP3 OGG
08/19	Kings of Code	Amsterdam. Netherlands	HTML5 - time for some slicker apps	slides	MP3 OGG
08/20	Encampment	London, England
09/30	Evento Linux	Lisbon, Portugal	HTML5 and the new challenge of open	slides	MP3 OGG
10/01	JSConf EU	Berlin, Germany	Community JS reloaded – how to rock as a movement	slides	MP3 OGG
10/03	Future of Web Apps	London, England	Get excited and build things and browser panel	slides	MP3 OGG
10/05	Fronteers	Amsterdam, The Netherlands	The prestige of being a web developer	slides	MP3 OGG	Vimeo
10/12	Paypal X Innovate	San Francisco, CA, USA	The web and browsers as the platform – exciting opportunities in new web technology	slides	MP3 OGG	YouTube
10/19	HTML5 live	London, England	Rocking the boat and causing a ripple	slides	MP3 OGG
10/20	Frontrow	Krakow, Poland	Fail, Meh or Win? How do you want the web to be?	slides
10/25	Company brownbag at Sabre	Krakow, Poland	HTML5 101 What it is, what it isn’t and where it might go	slides	MP3 OGG
10/25	Company brownbag at SAP	Munich, Germany (skype)	HTML5 101 What it is, what it isn’t and where it might go	slides	MP3 OGG
10/27	Velocity Europe	Berlin, Germany	Accelerating the overall web experience	slides	MP3 OGG
11/01	HTML5 live NYC	New York, NY, USA	repeat	slides
11/03	Mozilla Ignite	online	A fast web for people	slides
11/04	Mozilla Festival	London, England	BrowserID mentoring
11/11	Full Frontal	Brighton, England	my notes
11/12	MozCamp Europe	Berlin, Germany	How to be a kick-ass speaker	slides	MP3 OGG
11/20	Beyond Tellerand	Cologne, Germany	Moving browsers and the web forward	slides	MP3 OGG	Vimeo
12/12	London Ajax	London, England	Rethinking user registration with BrowserID	slides	MP3 OGG	Skills matter
12/21	Smashing Magazine Meetup #3	Stuttgart, Germany	Style and Distance – Moving ahead in web development as a community	slides	MP3 OGG	Vimeo
12/21	Smashing Magazine Meetup #3	Stuttgart, Germany	Working Draft Revision 53: At the Smashing Magazine meetup!			youtube

It was a fun year, and I hope you can use some of the information here to get inspired to go out and bring good messages to people out there.

TL;TR: Single page apps are coming and necessary for the web to be an apps platform. We have to battle two main issues: old conditioning of users and sloppy development for the sake of doing something “new”.

At the Smashing Mag meetup in Stuttgart Paul Irish got a question about single page apps and what he thinks of systems like backbone.js and client-side templating. He quoted somebody of Sencha who famously said that if he sees a web site with an empty body tag he is very happy (citation needed, help me). Paul explained that his first reaction to this was disbelief but he started thinking much more about it later on. He then proceeded to show the Google mail blog which is a single page app that has no real HTML source but instead is a small JSON object with client-side rendering to HTML using JavaScript.

All of this made me go “why” and “meh” mostly, but then again, I am old, seen a lot of things fail, had to fight for sensible use of Ajax without breaking conventions (without giving it yet another name like hijinks or something like that) and learned all I know about the web from a web of view-source and links that can be opened in multiple windows and tabs.

But I also am a very firm believer in the web as a media evolving and seeing how web usage patterns change with new consumption devices I am very much aware that there is a need for single page apps.

Why single page apps?

The benefits of single page apps are obvious:

• The first load sends you the shell of the app and it stays in the browser – this means it can be a very quick experience
• Subsequent data loading can be done by sending very small JSON objects containing content which is great for traffic-limited or slow connections (i.e. mobile environments)
• Maintaining everything in JS means you don’t need to have several, specialised developers on the project
• You replicate best practices of the backend and “higher languages” – especially MVC - on the client, thus making it easier for developers who are used to that to build web apps
• The experience is sticky – you stay in one interface and load content into it which is what “real” apps do

In essence, all of this is about a snappy interface. You don’t send much data, and you don’t have a reload and interface refresh in the browser.

It is nothing that new

Paul reminisced about the web interface of Outlook which out of a sudden told him that there are new emails to be read without reloading (the birth of XHR which lead to Ajax). I had seen this before XHR in forums and boards by having a frameset and an HTTP meta refresh. Frames in general did a lot of what we are craving with single page apps: we loaded only chunks of data and kept the main interface static on the screen.

The old problems of single page apps

The drawbacks of single page apps are the same we had every time we intercepted the reload of the page starting with frames, then with Flash and later with Ajax. Most of them can be done with native APIs these days (history API is a life saver in this case) but the issue is that we are breaking conventions. People in the past have been conditioned to expect things on the web to work in a certain way:

• We compete with a lot of useful browser features that we need to simulate:
  • History navigation
  • Preventing wrong loading by hitting the stop button or ESC
  • Loading indicators – is something happening?
  • Bookmarkability
  • Ability to open a link in another tab
  • State retention. When I reload the page I should get back to where I was and not the initial state of the app
  • Timeout detection (browsers tell me when something took too long)
  • Printability of pages (I just printed out a wikipedia entry for my mother)
• If we don’t change the URL and keep the state of the page we break the web:
  • Sending a link to a friend should get them where we were (unless it is our data behind a login of course)
  • A search engine spider should be able to index the content
  • Conversion tools should be able to get the content and create more accessible versions
  • Slow connections should at least deliver a partial experience. When being on a bad connection (as I am now) I should be able to reload and get more content once I get stuck. I can use gmail even on the flakiest of connections as I can switch to an HTML view and hit ESC when it gets stuck

None of these are insurmountable issues, but it is very easy and tempting to forget about them. This is why we had headless players and redirection scripts in the case of Flash apps. We should be aware of these already solved problems and implement them as a base of our UX considerations.

A shift in the way we use the web

A lot of these interactions above are used by people who have been on the web for a long time. Endless scrolling seems odd to them, they want to see a scrollbar and know how far the page goes. People who started the web on a touch interface or a mobile device on the other hand are confused when they have to click buttons or see a pagination. The old folk of the web have an email client, a browser, maybe a picture viewer and a very sorted download folder. The new folk do all of that in Facebook in a browser and are very happy to never see the page reload or having any of that content on their hard drives.

So to a degree I think it is important that we understand that some of the practices of old are just that – old and possibly outdated. For new users a page reload is as much a confusion point as scrolling and not getting visual feedback that something is loading until it appears is for the old-schoolers.

The new problems of single page apps

That doesn’t mean though that there are no issues with single page apps and a web without reloads. There are quite a few things we have to consider even if we say we build for the new generation of web users exclusively or within a fixed environment.

The first thing is that we are promising a fast web of awesome that is always available and every button does something to the app you are in. This means we need to come up with UX patterns that work with a variety of users and environments. It is not easy to compete with native apps – if we take on that challenge we should excel in it and not do it half-baked.

The second issue is that the web as we have it now is full of bad code. This is especially the case when you rely on third party code without having access to what it does. Unless you run a paid-for app, you will show ads. This is how we work and it is a broken, outdated model. Ads count page views and clicks so you need to find a provider that is OK with you auto-refreshing an IFRAME or something similar. But I deviate from the main point: if the ad code throws an error your whole app could die with it.

It doesn’t even have to be third party code. I can see sloppy code without error detection and fallback being advertised as “teething pains” these days. This is not true. We went through the process on non-reloading interfaces a few times already. A lot of omission of simple condition checking and error messaging is either arrogance or inexperience. As Zach Leatherman put it yesterday arrogant statements like “All of my JavaScript code and 3rd party code won’t have errors, so I can ignore Progressive Enhancement” will come to haunt you as the screenshot of Klout shows:

Gawker also had that issue and Mike Davies has quite some information as to why relying on JS for your links is an architectural nightmare.

In short – we will now once again face a time of New vs. Old and people building apps seeing their own setup and experiences as those of everyone on the web. We had this with Flash in the past and we had it with Ajax. Now we’ll repeat the long discussions, endless bickering and using technology and interface patterns for the sake of using them instead of where they are needed.

Case in point is the blog mentioned by Paul. I am sure it was used as a testing platform for the single app container of Google. Personally I think there is nothing dynamic in a blog that would really warrant it being an app. Not everything on the web needs to be a new Facebook, Google Reader or Google Mail.

Personally I am happy to load a page and read an article in another tab while it is loading and coming back when the tab tells me it is ready for me. I like my web multitasking. On a mobile device or tablet this is a different issue. But who says that this experience should also be forced upon me when I have lots of space, tabs and a browser that brings me the whole web instead of a single resource?

Today Smashing Magazine will released an article I wrote yesterday about a “beginner tutorial” on the same magazine which showed developers how to build a Christmas wish list whilst opening up the server to a lot of attacks.

It annoyed me that these things still happen, which is why I talked to Vitaly about it (I am on the expert advisor panel of SM) and he asked me to write an article to talk about the tutorial.

The beginner tutorial loop of annoyance

In general my point is that we are flooding the web with a lot of beginner tutorials, and a lot of them are nothing of the kind. Instead, they aim to make beginners feel good about a certain topic but fail to deliver knowledge. Instead, they oversimplify and try to pad with a lot of content in one tutorial. The reactions to these kind of articles are predictable:

• Seasoned developers will find issues with the code and claim that it should not be done that way
• Other people will disagree and tell the old men to stop telling young kids to get off their lawn
• Real beginners will chime in and say that they are very happy about the article and getting the feeling that things are not as complex as they seem to be
• A lot of fanboys will mention technology XYZ that makes this much easier
• The author will add more disclaimers about the nature of the code of the article in some edits and add warning messages about its viability in the wild – saying that this is just demo code

In short – a lot of back and forth and in the end the author will comply that the tutorial might be misleading and own up that the code should not be used in a live environment and explain. That doesn’t mean though that people will not do so, which is why I consider it very dangerous to cut corners when
writing beginner tutorials.

A call for real beginner tutorials

In the article I added a call for real beginner tutorials, as right now we keep falling into the same trap:

• We assume that only quick successes will make people want to learn things
• That’s why instead of explaining one thing we build a full solution with a beautiful interface, admin interfaces and a backend – omiting important features and warnings in each of them as we don’t want to overload people
• We release code that is not safe for release or real production quality – as it is easier to explain – and warn people not to use it in the real world – assuming that people do read and follow these warnings

The big fallacy is that we try too hard to give beginners a quick way in instead of allowing them to find out things on their own terms – which includes trial and error.

jQuery is not that easy to repeat

A lot of this is trying to repeat the success of jQuery when it comes to getting new developers to hit the ground running. The problem is that the success of jQuery is only repeatable when you do the thing jQuery did – replace the original technology with a simpler syntax and richer API. This is why it is much simpler to write a tutorial on how to use an API or package to achieve a task than to teach people how to start from scratch – the final goal is much closer and success immediate.

Quick success = lots of hits

The really annoying part about this is that simple and quick tutorials with a beautiful example are incredibly successful. They get a lot of hits, happy comments from beginners who think they learned something they can repeat and because of that online magazines who need the traffic to show ads will always be happy to publish them and deliberately ask writers to add more and omit the “complex stuff”.

Use the web to link to resources for beginners

We should not teach bad practices that are hard to un-learn for the sake of a quick win and click numbers. The web is already full of great resources we can keep up-to-date (yes, the Mozilla Developer Network being the biggest) and link to instead of repeating the same mistakes and starting from scratch over and over again.

Happy holidays everyone, I just used the 3D tester and played around a bit as I was inspired by a christmas tree ornament:

The effect needs Firefox Aurora or Webkit as it uses CSS Animation and 3D transformation.