The website anti-pattern
September 23, 2007
We’ve all come across one. That one website that embodies everything that can be wrong about websites. That one product of the dark side of web 0.5 and ECMAscript. That one that seems to be actively preventing you from getting what you want from it.
If you haven’t yet witnessed such an anti-pattern website, please, allow me. Introducing Madkit.
When you arrive, the site looks innocent enough. A classic two pane layout, with a menu and a main window, plus a logo pane at the top. It’s when you start to scroll that the horror dawns: it’s all frames. That 20th century abomination of usability, introduced because of a lack of layout mechanisms such as CSS. This is, honestly, the first framy site that I’ve seen in a long time, and that alone is a strong indicator of how broken Madkit’s website is.
Antipattern #1: frames. They provide a non-uniform browsing experience, and most importantly, they make bookmarking of specific pages impossible.
I attempt to ignore that. After all, if they want to live in 1994, it’s their choice (after all, the software is written in Java). All I want is to download it and play with it a little. So I scan the menu sidebar, find the ‘Download’ section, and… Wait, what? There’s only a ‘Login’ link in that section. You’re telling me that I need to have an account and login, to download your software?
Antipattern #2: login required for trivial actions. I cannot fathom the use of requiring a login for downloads. If it is for statistics, they could put the files up on Sourceforge and let Sourceforge take care of the numbers. This is a critical antipattern: if I wasn’t required to obtain Madkit, I would have turned heels and left. Just like caffeine inhibits sleep at a cellular level, the simple decision to lock out downloads is inhibiting a strong community at the cellular level: only cells that really care, or more likely that have no choice will make it into your community.
But wait, there’s more! As I require Madkit, I have no choice but to create an account. So, on the login page, I click the “Create an account” button, and… Wait, what? Page not found?! Unable to believe it, I try to get to the account creation page by another path in the website, and, again, page not found. I begin to think that maybe madkit has imploded from its complete lack of community and died the lonely death, when I notice something while hovering over the registration link: javascript:register().
Because the internet is full of retarded web designers, I surf with NoScript turned on, which acts as a javascript whitelist. Only sites that I deem worthy may wield the power of dynamicity. Why? Because, like the Force, Javascript has a light side and a dark side. And quicker, easier, more seductive the Dark Side is. I do not want the dark side of Javascript to manifest itself on my desktop, since its usual manifestation is popups and a pegged CPU.
So, Madkit requires Javascript to access its registration page. One feels compelled to wonder why?! It’s a form with a submit button, the kind you could put on a static HTML page. I might comprehend the use of a sprinkle of javascript to pre-validate data on the client side (which doesn’t excuse you from checking it server-side of course), but to access the page?
Antipattern #3: Javascript silently required. It’s fine to have a website that absolutely requires Javascript, for some reason. In that case, you have a <noscript> section, which politely informs your reader that he should upgrade to a 21st century browser or, more likely, authorize Javascript. Flickr embodies this good practice: if you surf to a photo with javascript disabled, the site shows a little box, warning you that the best flickr experience is with Javascript and Flash authorized, and then proceeds to show you what you came for, albeit in a degraded way. Having Javascript functionality that degrades gracefully is the litmus test of dynamic website design.
I could go on and on about the stupidity that is pervasive in that website (have I mentionned that the back button sometimes doesn’t work at all, and just reloads the page you are currently on?), but I have better things to do.
One parting remark: of the three antipatterns above, #1 and #3 are, all in all, minor problems. They are implementation details, details which could be fixed by applying manpower to the website. Antipattern #2 is much more problematic, because it is a design choice. By design, the website makes it hard for people to obtain the software. I can only assume that this is some kind of explicit wish of the developers, but I consider this to be the very best way to drive away potential community members. The only people who actually go through the palaver and finally are in a position to join the community are those who had no choice. Do you really want the common vision of your community to be “Because I had to” ?
By the way, if you want to know how to avoid the most common mistakes in getting a community for your open source projet, I strongly recommend reading Producing Open Source Software. It is a milestone book on the topic.