Christian Heilmann

You are currently browsing the Christian Heilmann blog archives for December, 2011.

Archive for December, 2011

[Open tabs] things of note I read and saw lately

Friday, December 30th, 2011

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 , 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 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.

What I did in 2011 – talk archive with slides, recordings and videos

Thursday, December 29th, 2011

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/28Heart and SolePortsmouth, EnglandTime to build a better webslides Vid.ly
02/04FOSSDEMBrussels, BelgiumMoving to the client – HTML5 is hereslides MP3 OGG
02/08London Ajax meetupLondon, EnglandUsing HTML5 sensibly and multimedia on the webslides MP3 OGG Skills matter
02/10MF Boat eventLondon, England
02/17London WebLondon, EnglandFinding harmony in web developmentslides MP3 OGG Vimeo
03/09ConFooMontreal, CanadaMoving from hacks to solutionsslides MP3 OGG YouTube, YouTube #2
03/18LoginVilnius, LithuaniaBuilding a better web with open, new technologiesslides YouTube
04/14Funkas TillgänglighetsdagarStockholm, SwedenAccessibility and web innovation (slides, audio and notes)slides MP3 OGG
04/16W3café accessibilitéParis, France
04/20JAXMainz, GermanyHTML5 Das Web und der Browser als Platformslides MP3 OGG Vimeo
04/20JAXMainz, GermanyWie JavaScript die Welt eroberteslides MP3 OGG
05/10Google IOSan Francisco, CA, USA
05/30WebinaleBerlin, GermanyHTML5, CSS3 und JavaScript fuer alleslides MP3 OGG YouTube
06/07Inspire ConferenceLondon, EnglandMentoring
06/17Web2DayNantes, FranceHTML5 and the web of tomorrowslides videointerview
06/25Converge SEColumbia, SC, USAWith the power of HTML5slides MP3 OGG
07/08Highland FlingEdinburgh, ScotlandModerator
07/16Open Web CampPalo Alto, CA, USAHTML5 battles still to be won (slides, audio)slides MP3 OGG
08/19Kings of CodeAmsterdam. NetherlandsHTML5 - time for some slicker appsslides MP3 OGG
08/20EncampmentLondon, England
09/30Evento LinuxLisbon, PortugalHTML5 and the new challenge of openslides MP3 OGG
10/01JSConf EUBerlin, GermanyCommunity JS reloaded – how to rock as a movementslides MP3 OGG
10/03Future of Web AppsLondon, EnglandGet excited and build things and browser panelslides MP3 OGG
10/05FronteersAmsterdam, The NetherlandsThe prestige of being a web developer slides MP3 OGG Vimeo
10/12Paypal X InnovateSan Francisco, CA, USAThe web and browsers as the platform – exciting opportunities in new web technologyslides MP3 OGG YouTube
10/19HTML5 liveLondon, EnglandRocking the boat and causing a rippleslides MP3 OGG
10/20FrontrowKrakow, PolandFail, Meh or Win? How do you want the web to be?slides
10/25Company brownbag at SabreKrakow, PolandHTML5 101 What it is, what it isn’t and where it might goslides MP3 OGG
10/25Company brownbag at SAPMunich, Germany (skype)HTML5 101 What it is, what it isn’t and where it might goslides MP3 OGG
10/27Velocity EuropeBerlin, GermanyAccelerating the overall web experienceslides MP3 OGG
11/01HTML5 live NYCNew York, NY, USArepeatslides
11/03Mozilla IgniteonlineA fast web for peopleslides
11/04Mozilla FestivalLondon, EnglandBrowserID mentoring
11/11Full FrontalBrighton, Englandmy notes
11/12MozCamp EuropeBerlin, GermanyHow to be a kick-ass speakerslides MP3 OGG
11/20Beyond TellerandCologne, GermanyMoving browsers and the web forwardslides MP3 OGG Vimeo
12/12London AjaxLondon, EnglandRethinking user registration with BrowserIDslides MP3 OGG Skills matter
12/21Smashing Magazine Meetup #3Stuttgart, GermanyStyle and Distance – Moving ahead in web development as a communityslides 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.

On single page apps

Wednesday, December 28th, 2011

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:

Klout showing an empty page as there was a reference error in a JavaScript file

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?

Beginner tutorials who don’t help beginners?

Tuesday, December 27th, 2011

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.

Faking a mesh ball with lots of rotated colourfull circles

Monday, December 26th, 2011

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.