Unresponsive Web Design — the New AIGA.org
There's a lot of "heated debate" about the new AIGA.org design. Just like the last time. Somehow, some of it is even the same debate about a completely different design. And apparently all the comments that don't mention the lack of hierarchy are being moderated. That's the only reason I can come up with for everyone bringing it up.
But I don't want to get into a critique of the design. I don't envy Method (or Happy Cog before them)—designing for an organization full of opinionated and talented designers (most with more of one than the other) is a difficult challenge, to say the least. In short, I actually kind of dig the new look, aside from the background being a little too distracting for my tastes. It feels current enough and encourages exploration of their vast archives and resources. What I don't get at all is how they could have implemented a responsive design so poorly. It fails in so many important and obvious ways, I waited a while to write this post to see if it was just launch-day glitches. Nothing has changed in the last week and a half.
First and foremost, how is it even possible to build a responsive site that doesn't correctly and consistently scale down to an actual mobile device width? It seems every page behaves differently, so I'm constantly pinching in and out, and sometimes can't even pinch at all even though I can see content off the edge of the screen. Here's a few screenshots on my iPhone:
Unpleasant at best and frustrating to the point of giving up at worst. As far as I can tell, the only mobile-specific media query (max-device-width:480px) is the font-resizing fix. They do, however, go to the trouble of setting up styles for screen resolutions all the way up to min-width:1885px. Amazingly, the site still manages to behave erratically on my desktop computer as well. Sometimes the columns shift around when I resize, sometimes they don't. So. Confusing.
Next, it loads so freaking slow. Not only is the site not optimized visually for mobile, the files themselves aren't optimized at all. A cursory glance behind the scenes with Pingdom's load time test reveals a full megabyte of files on the homepage. That's not completely unheard of in this age of ever-increasing internet speeds, but what is astounding is that about 100KB of that is for the HTML alone. I couldn't even fathom how an HTML file for a relatively small page could be that large, so I took a look at the source. It's 1219 lines of HTML. One thousand two hundred nineteen. And that's not even an article page cluttered with tons of Disqus comments and cruft. MySpace (not known for their clean code) has a homepage that is only 660 lines and 49KB.
Looking more closely, there's an <input> element near the top of the page with an id="__VIEWSTATE" that has more encoded text than Kryptos. It's all one wrapped line of text, so it doesn't even contribute to the ridiculous 1219 lines of HTML, but it takes me 4 clicks of the Page Down key to get past it. I pulled just that encrypted text out and saved it as an HTML file and clocks in at 33KB by itself. Bigger than most complete HTML files.
I have no knowledge of the CMS they're locked into there (appears to be Ektron), and I'm sympathetic to having to work with something that doesn't break older dependent parts of the site (we have to do the same thing at BRIC). But if this is what your CMS is shoving down every iPhone and Android phone's gullet, then it's probably time to find something better. What a waste of bandwidth and time.
Digging deeper into the Pingdom report, the next most glaring issue is that there are 104 images. Now, the Pingdom report doesn't distinguish between images called in the CSS file(s) and images actually on the page, so I took a look. There's a couple CSS files apparently named "EktronModalCss" and "EktronPageHostCss" that load a lot of what look like CMS backend icons (e.g.). Why are these CSS files loading into every page on the site? Is Ektron (which sounds like an evil robot from the 1950s and not a CMS, by the way) really that inflexible that you can't pull that off the frontend pages?
Finally, Pingdom tells us that we need to load 8 javascript files totalling almost 350KB to make the new site sing. Three of those files are each 75KB+. That seemed strange to me, since you'll usually have only one large file for whatever library you're using. The 3 large files are jquery.min.js (makes sense), ektron.js and MicrosoftAjax.js. A quick search led me to find out that ektron.js is just Ektron's "enhanced" version of jQuery (enhanced in the same way frying a Twinkie enhances it) and MicrosoftAjax.js is Microsoft's AJAX javascript library. So, that's 3 separate javascript libraries aiga.org apparently needs, 2 of which are essentially redundant. Ugh.
In 2006, Khoi Vinh's criticized of AIGA as a design organization that either doesn't understand Interaction Design or doesn't take it seriously. That was 5 years and 2 redesigns ago, and if the way they treat their own site is any indication, not much has changed. It's really not that hard to make a website these days that doesn't need to be grappled with to be enjoyed across all devices. I finally broke down and became a member of AIGA recently. I just hope that I don't have to use their site with a 24" monitor and a 100 mbps internet connection to get the most out of it.
