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:
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.
The benefits of single page apps are obvious:
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.
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 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:
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 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.
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.
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:
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.
In the article I added a call for real beginner tutorials, as right now we keep falling into the same trap:
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.
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.
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”.
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.
I just got a weird feeling that we are quite misusing the web at the moment to get eyeballs and clicks to our own personal blogs (I am not talking about company sites here).
Take this cool quote by Penn Jilette:
There is no god and that’s the simple truth. If every trace of any single religion died out and nothing were passed on, it would never be created exactly that way again. There might be some other nonsense in its place, but not that exact nonsense. If all of science were wiped out, it would still be true and someone would find a way to figure it all out again.
This seems to originate on imgur. Probably in a post on 4chan or some other board. Instead of just quoting as text someone put it in an image as it is more appealing and probably people link to it more. Well, the really sensible thing would be to provide the text, too, cause then people can quote and search engines can find it. I am not going to have to explain again that people who can not see the image or for whom it doesn’t load should get the info, I hope.
So this happened:
It went on mlkshk posted by Maggie Nelson, then Kottke blogged it, giving it a transcription in HTML and the enticing title “exact nonsense”. Kottke also proved his worth as a good blogger by linking the quote to the book it came from and linking the book title to Google books for you to see (a lesser blogger would have linked it to Amazon with their affiliate ID). Then Gruber blogged exactly the same post with the same title and a “via” pointing to Kottke (ommiting the link to Google Books though). This is how I found it via a retweet of Gruber by Brandon Mitchell.
I like one thing about this: that the original message was converted to a more portable format and Kottke added even meta information.
I don’t like about this that the message then gets put almost verbatim on yet another blog and information (the link to the book) gets omitted again.
I like distribution on the web and if Kottke’s blog went down we’d still have Gruber to get at least the text. In “amazing world” the original image would have had the alternative text and be linked to the book. I wonder if we don’t just get too overboard with the ‘/via’ we put on the web now – if we don’t add value to the original content by putting it on our blog. There is a lot of duplication going on and a lot of unnecessary branding. You see this with images a lot. A funny image crops up and 2 months later you see it in 20 copies (in worse quality most of the time) with watermarks of “fun collections” domains on them.
Frankly I was just annoyed that I spent time chasing the /via links in this case as I thought the title “exact nonsense” was an article by Gruber on overzealous design or code practices. I find a blog something where you should add to the subject matter, not just copy and paste. Right?