Archive for the 'layouts' category

Designing in code

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.

What would Jeff 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?

Fluidity

My lunchtime reading today is going to be this ALA article by Ethan Marcote on creating fluid grids. That is layout grids that maintain their proportions whilst scaling to the browser window size. Very slinky they are too.

It got me thinking about the layouts we use here at the Equator. They are almost universally fixed-width and centre-aligned. Is this an artifact of the type of relationship we have with our clients, which is visual design-focused to a large extent?

As does the mock-up, so shall the site sit neatly in the middle of the page/window?

We should maybe embrace the slink. I have my calculator standing by.