Magic Torch

Inspiration struck over the weekend for a wee web app to make life a big easier in a small way in the office. Going to thrash out the technical details tomorrow, hopefully, and then have a prototype up and running ASAP.

But this evening I’ve been working on the UI. I’ve got something going that I’m really happy with. And the closest I came to opening any kind of graphics software was resizing a couple of user avatar placeholders in Preview. Everything else was done in HTML and CSS, straight into the browser. I’ve never really got used to doing mockups in Photoshop or whatever. I don’t have the patience for it, and it’s not really my medium anyway. But cracking a tricky little layout problem by thinking laterally about how to style a span? Dynamite.

Now it feels like 2010.

I was in the cinema when all the announcing was going on, but I’ve had a wee look just now.

The thing that struck me immediately is that the UI design has this deadly confidence about it. The Mail app, the Calendar, the whole thing. No hesitation, no glancing sideways at what other people are doing, certainly nothing left half-done.

You notice the same calmness and polish on the iPhone, but here it really gets a chance to stretch its legs.

Lovely.

I didn’t think I’d want one, but I really do.

“Yeah, but your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.”

So said Jeff Goldblum, wisest of all Jeffs (with the possible exception of Zeldman) to safari suit-crazed boffin Richard Attenborough in cinema’s “Jurassic Park”.

Jeff knew what he was talking about, too. We all remember the thing with Samuel L. Jackson’s arm, don’t we?

Jeff’s profundity with regard to meddling in Nature’s Ways has been on my mind for a couple of weeks now. But instead of DNA, I’ve been humming and hawing about jQuery.

jQuery has become our go-to JavaScript framework foundation for the scripting we do here at Equator. And we do a fair amount. Nothing like a Google Docs or anything, but we can bring it when required. And it’s great to have jQuery for the heavy lifting. However…

Back to Jeff.

While Dickie was spluttering into his Chilean Sea Bass, Jeff followed up with some extra ‘blum-zen:

“I’ll tell you the problem with the scientific power that you’re using here: it didn’t require any discipline to attain it.”

Are you beginning to see the connection?

Yeah, okay, we’re talking a JavaScript library here, and not Velociraptors in your kitchen, but I think Jeff would recognise what is going on.

jQuery requires very little discipline to produce startling effects. And while that is great for deadlines, I can’t help thinking that proper design thought is being short-circuited a bit. At least with one particular jQuery-enabled bit of magic: the Show/Hide widget, whereby clicking a button shows or hides a bit of content via a smooth half-secondish transition.

It’s very nice. Much less jarring than instantly disappearing or appearing the content and it looks snazzy (there’s a lot to be said for a bit of snazzy). With traditional JavaScript you’d be looking at a fair bit of work to realise it. With jQuery it literally takes a few minutes. There is a one function call (slideToggle) in jQuery that automatically controls the animation in either direction.

What was once expensive is now essentially free. And so it starts getting used all over the place. It’s seductive as hell. Section of content getting a bit big? Stick a show/hide on it. Too many sections making the page a bit long? Stick show/hides on all of them. FAQ page? Do you really need to ask?

I’m beginning to think this is a real problem. I think we have become a bit too enamoured and let clients become far too enamoured of this little warlock’s trick we can do just-like-that.

Hiding things that are sort of in the way or don’t quite fit isn’t any kind of substitute for showing the correct things in the first place. It’s too easy, if the page is proving tricky to get right, to just hide the rough edges.

There’s also a hint of “we know what’s best for you with regard to this inter-net page” about it. If people consume the content in this particular way they will be fitter, healthier, more productive, etc.

It has reached an absurd degree in some particular cases I’ve seen recently (naming no names). Where there seems to be an actual fear of showing the user too much content. And by too much I’m not talking about one of the chunkier Harry Potters. I’m talking about anything that might force its way beneath the page fold (these still exist, apparently). Four or five hundred pixels’ worth of nicely-set copy.

So you end up with FAQ pages where every section and every question/answer within that section is subject to a show/hide widget. Even if the answer is two sentences. Even if the answer is shorter than the question. Seriously.

Why is scrolling such a nightmarish proposition, but clicking one of half a dozen or more non-standard controls to display content that may only be relevant once revealed is the future of the human-computer interface? Just because you’d like your user to grok your UI the way Lobot might, it isn’t going to make it so.

People had been navigating newspapers, magazines, books, parchments and… errrr… scrolls for thousands of years before the Internet turned up, but somehow putting it on a screen means that more than a couple of paragraphs and people are going to be jumping out of windows?

Really?

Come on. What would Jeff do?

I headed back to A List Apart this afternoon to have another look at the examples from that Fluid Grids article. Except the URL got mucked up somehow and I ended up at the ALA 404 error page. Most of the 404s I’ve seen pull you straight out of the front-end of site and into the back-end code. Error, buzz, beep, string of unintelligible characters if you are really lucky. But not in this case.

Something has gone wrong but what you get are a couple of reasons why you are maybe where you are, a reassurance that this isn’t just some unnoticed hole in the site and a couple of sensible exit strategies. And an illustration. An error page watercolour.

It’s great. Not too serious, but also not dismissive. It’s matter of fact and doesn’t dead-end you. Most of all it sounds authentic. Written by someone to explain the real, human situation you are in (surprised and a bit lost), not the contents of a variable chucked onto the page by a bit of code. No “Error. This page does not exist.” bollocks.

After seeing this and experiencing it in the wild, I can’t see why you would do it any other way. A little thought about where the user is, and the best language to engage them, and… hours later, I’m possibly more impressed with the site for failing so well than anything else (the Fluid Grids article does rock, though).