Tags: liquid

I noticed something interesting recently about how I browse the web.

It used to be that I would notice if a site were responsive. Or, before responsive web design was a thing, I would notice if a site was built with a fluid layout. It was worthy of remark, because it was exceptional—the default was fixed-width layouts.

But now, that has flipped completely around. Now I notice if a site isn’t responsive. It feels …broken. It’s like coming across an embedded map that isn’t a slippy map. My expectations have reversed.

That’s kind of amazing. If you had told me ten years ago that liquid layouts and media queries would become standard practice on the web, I would’ve found it very hard to believe. I spent the first decade of this century ranting in the wilderness about how the web was a flexible medium, but I felt like the laughable guy on the street corner with an apocalyptic sandwich board. Well, who’s laughing now‽

Anyway, I think it’s worth stepping back every now and then and taking stock of how far we’ve come. Mind you, in terms of web performance, the trend has unfortunately been in the wrong direction—big, bloated websites have become the norm. We need to change that.

Now, maybe it’s because I’ve been somewhat obsessed with service workers lately, but I’ve started to notice my expectations around offline behaviour changing recently too. It’s not that I’m surprised when I can’t revisit an article without an internet connection, but I do feel disappointed—like an opportunity has been missed.

I really notice it when I come across little self-contained browser-based games like

• Constellations,
• Cub’n’Pup, and
• Battleship Solitaire.

Those games are great! I particularly love Battleship Solitaire—it has a zen-like addictive quality to it. If I load it up in a browser tab, I can then safely go offline because the whole game is delivered in the initial download. But if I try to navigate to the game while I’m offline, I’m out of luck. That’s a shame. This snack-sized casual games feel like the perfect use-case for working offline (or, even if there is an internet connection, they could still be speedily served up from a cache).

I know that my expectations about offline behaviour aren’t shared by most people. The idea of visiting a site even when there’s no internet connection doesn’t feel normal …yet.

But perhaps that expectation will change. It’s happened before.

(And if you want to be ready when those expectations change, I’ve written a Going Offline for you.)

One of the recurring themes at the Responsive Day Out was how much of a sea change responsive design is. More than once, it was compared to the change we went through going from table layouts to CSS …but on a much bigger scale.

Mark made the point that designing in a liquid way, rather than using media queries, is the real challenge for most people. I think he’s right. I think there’s an over-emphasis on media queries and breakpoints when we talk about responsive design. Frankly, media queries are, for me, the least interesting aspect. And yet, I often hear “media queries” and “responsive design” used interchangeably, as if they were synonyms.

Embracing the fluidity of the medium: that’s the really important bit. I agree with Mark’s assessment that the reason why designers and developers are latching on to media queries and breakpoints is a desire to return to designing for fixed canvases:

What started out as a method to optimise your designs for various screen widths has turned, ever so slowly, into multiple canvas design.

If you’re used to designing fixed-width layouts, it’s going to be really, really hard to get your head around designing and building in a fluid way …at first. In his talk, Elliot made the point that it will get easier once you get the hang of it:

Once you overcome that initial struggle of adapting to a new process, designing and building responsive sites needn’t take any longer, or cost any more money. The real obstacle is designers and developers being set in their ways. I know this because I was one of those people, and to those of you who’ve now fully embraced RWD, you may well be nodding in agreement: we all struggled with it to begin with, just like we did when we moved from table-based layout to CSS.

This is something I’ve been repeating again and again: we’re the ones who imposed the fixed-width constraint onto the medium. If we had listened to John Allsopp and embraced the web for the inherently fluid medium it is, we wouldn’t be having such a hard time getting our heads around responsive design.

But I feel I should clarify something. I’ve been saying “we” have been building fixed-width sites. That isn’t strictly true. I’ve never built a fixed-width website in my life.

Some people find this literally unbelievable. On the most recent Happy Mondays podcast, Sarah said:

I doubt anyone can hold their hands up and say they’ve exclusively worked in fluid layouts since we moved from tables.

Well, my hand is up. And actually, I was working with fluid layouts even when we were still using tables for layout: you can apply percentages to tables too.

Throughout my career, even if the final site was going to be fixed width, I’d still build it in a fluid way, using percentages for widths. At the very end, I’d slap on one CSS declaration on the body to fix the width to whatever size was fashionable at the time: 760px, 960px, whatever …that declaration could always be commented out later if the client saw the light.

Actually, I remember losing work back when I was a freelancer because I was so adamant that a site should be fluid rather than fixed. I was quite opinionated and stubborn on that point.

A search through the archives of my journal attests to that:

• 2003: The long debate
• 2004: Regurgitating the chestnut
• 2004: Fixed vs. Liquid… yet again
• 2005: Fixed Fashion
• 2005: Transparent liquid
• 2005: A List Too Far Apart
• 2006: Fixtorati
• 2007: New Year’s Resolution
• 2009: Zoomfusion

Way back in 2003, I wrote:

It seems to me that, all too often, designers make the decision to go with a fixed width design because it is the easier path to tread. I don’t deny that liquid design can be hard. To make a site that scales equally well to very wide as well as very narrow resolutions is quite a challenge.

In 2004, I wrote:

Cast off your fixed-width layouts; you have nothing to lose but your WYSIWYG mentality!

I just wouldn’t let it go. I said:

So maybe I should be making more noise. I could become the web standards equivalent of those loonies with the sandwich boards, declaiming loudly that the end is nigh.

At my very first South by Southwest in 2005, in a hotel room at 5am, when I should’ve been partying, I was explaining to Keith why liquid layouts were the way to go.

That’s just sad.

So you’ll forgive me if I feel a certain sense of vindication now that everyone is finally doing what I’ve been banging on about for years.

I know that it’s very unbecoming of me to gloat. But if you would indulge me for a moment…

I TOLD YOU! YOU DIDN’T LISTEN BUT I TOLD YOU! LIQUID LAYOUTS, I SAID. BUT, OH NO, YOU INSISTED ON CLINGING TO YOUR FIXED WIDTH WAYS LIKE A BUNCH OF BLOODY SHEEP. WELL, YOU’RE LISTENING NOW, AREN’T YOU? HAH!

Ahem.

I’m sorry. That was very undignified. It’s just that, after TEN BLOODY YEARS, I just had to let it out. It’s not often I get to do that.

Now, does anyone want to revisit the discussion about having comments on blogs?

I’ve tried a few different to-do list apps in my time: Ta-da List, Remember The Milk. They’re all much of a muchness (although Remember The Milk’s inability to remember me on return visits put me off it after a while).

The one that really fits with my mental model is TuexDeux. It’s very, very simple and that’s its strength. It does one thing really well.

Now it has been updated with a few little changes.

I’m very pleased to see that it has become more flexible and fluid. I’ve said it before but I really think that web apps should aim to be adaptable to the user’s preferred viewing window. With more content-driven sites, such as webzines and news articles, I understand why more control is given to the content creator, but for an application, where usage and interaction is everything, flexibility and adaptability should be paramount, in my opinion.

Anyway, the new changes to TeuxDeux make it better than ever. Although…

If I had one complaint—and this is going to sound kind of weird—it’s that you mark items as done by clicking on them (as if they were links). I kind of miss the feeling of satisfaction that comes with ticking a checkbox to mark an item as done.

I told you it was going to sound kind of weird.

I was in Boston last week for An Event Apart, the second of five instances of the travelling web roadshow touching down in the US this year. As with Seattle, all the talks were of a ludicrously high standard. Tickets are still available for the Minneapolis leg; grab ‘em while you can.

What’s fascinating about seeing all the talks together is finding the unspoken connections between them. Without any prior co-ordination, myself and Aarron had moments of crossover with our talks, Emotional Interface Design and Paranormal Interactivity.

Blenderbox have written a round-up of the themes from An Event Apart. This is the one that really stood out for me:

Your designs should embrace the diversity of browsing experiences offered by different devices.

There was plenty of talk about technologies like media queries and devices like the iPhone and iPad. All of it was galvanised together in Ethan’s superb A List Apart article, Responsive Web Design:

Fluid grids, flexible images, and media queries are the three technical ingredients for responsive web design, but it also requires a different way of thinking. Rather than quarantining our content into disparate, device-specific experiences, we can use media queries to progressively enhance our work within different viewing contexts.

Here’s my quick three-step guide to ensuring your websites work in just about any device:

1. Mark up your content with a logical source order.
2. Style your markup into a flexible—i.e. liquid—layout.
3. Use media queries to re-arrange the layout for varying viewport widths.

If you want some examples—and feel free to resize your browser window—peruse Huffduffer and Science Hack Day from myself, dConstruct 2010 from Andy and Talking Animal Blug from Patrick (actually, that last one uses JavaScript to get the same result but the principle is the same).

It seems that step two continues to be the sticking point for most web designers. We’ve had over ten years to get this right, yet everything that David Emery wrote in 2006 is truer than ever today:

There are very few legitimate reasons for using a fixed width site, the main one being concerns over the line length on a fluid width site; obviously as the site gets wider, the line length gets longer which is bad for readability. This is can easily be countered by using max-width, larger font sizes and so on but is really quite faulty thinking – if the solution is a fixed width site that’s sized for 1024×768 then if you’re window is any smaller then that then the line isn’t readable at all, which is obviously much worse.

I also think he was spot-on with his explanation for the prevalence of fixed-width layouts:

When you make a web site design (probably in something like Photoshop) it obviously starts off as static — you have no way of testing how it’ll stretch in a browser. You’ve got to picture how that’s going to work, and design accordingly.

Photoshop and Fireworks are great tools …for tweaking photos and creating icons, gradients and textures. When it comes to laying out web pages however, they are worse than substandard. They are actively harmful. They reinforce the incorrect idea that there is a way of representing the browsing experience in anything other than a browser.

What’s ironic is that designers who continue to shackle themselves to Photoshop and Fireworks do so because they claim that designing with HTML and CSS in the browser limits the design possibilities. And yet they are perfectly content to limit themselves to an environment where designs cannot be resized, cannot respond to varying text sizes and typefaces, and cannot convey even the most basic of interactions.

Meagan Fisher has some good advice on making your mockup in markup. And of course, Malarkey has plenty to say on this subject.

I know I’m not the sharpest knife in the drawer but there’s one recurring topic that makes me feel downright stupid. I’ve heard a lot of my fellow designer/developers talking about how page zoom (rather than text zoom) spells the death of liquid layouts.

Now, forgive me for being dense, but I just don’t get it. I totally understand how page zoom could spell the death of elastic layouts; using ems for layout won’t be necessary if browsers natively resize pixel-based layouts. But both pixel- and em-based layouts have a set width and that width doesn’t change depending on the width of the browser window.

A liquid layout will resize depending on the browser width, right? Page zooming doesn’t do away with that flexibility. If I open a fixed or elastic width page in a browser window that’s narrower than the size dictated by the designer, I’ll get a crawlbar. Now I could use the browser’s page zoom feature to shrink down everything until the content fits within my browser window but the content would become illegible.

Text-resizing and viewport-resizing are related only in as much as they are both ingredients in good bulletproof design:

1. Ensuring that a design works for different text sizes.
2. Ensuring that a design works for different viewport sizes.

Native page-zooming in browsers obviates the first concern. It does absolutely nothing for the second concern.

I’m perplexed. Either a whole swathe of my peers are confusing elastic and liquid layouts or I’m missing something fundamental.

A more plausible explanation for this strange equation of page zoom and liquid layout mortality is that designers who have already decided that they don’t want to deal with liquid layouts—for the very understandable reason that they’re harder to do than fixed layouts—are attempting to retroactively justify that decision without really thinking through the argument.

Rather than clutching at ill-thought-out strawmen like page zooming, their time might be better spent reading a good book.

The current issue of A List Apart is the proud bearer of a superb article by Ethan called Fluid Grids. If the title isn’t enough of a hint, it’s all about grids …wot are fluid.

It’s an excellent tutorial. I’ve made no secret of my love for a good liquid layout and Ethan’s article is a great resource for anyone brave enough to take up the challenge.

Another excellent resource comes to us courtesy of Zoe Mickley Gillenwater. She’s written a book called Flexible Web Designs. Buy it now. You won’t regret it. I thought I knew my stuff when it came to wrangling CSS but this book had techniques that were new to me.

Both Zoe’s book and Ethan’s article are commendable for showing how to do something without wasting much time talking about why. Frankly, there’s been enough debate on issues like this. We don’t need more debate, we need more tutorials. This is something I struggle with myself. I’ve spent far too much time talking up the benefits of web standards, microformats, unobtrusive JavaScript, accessibility and, yes, liquid layouts. I think I’m done with that. If I haven’t convinced someone at this stage, I’m not sure I can muster the enthusiasm to pimp any more kool-aid.

But I do have one last little piece of propaganda I’d like to promulgate…

In any discussion of liquid layouts—for or against—it’s common for the subject of the “horizontal scrollbar” to come up. The term is an oxymoron. If text is moving vertically—movie credits, for example—then it is scrolling. If text is moving horizontally (as seen on CNN, BBC, and every other news channel), it is crawling. Therefore, the term “scrollbar” can only correctly be applied to an interface element that allows content to be moved vertically. The correct term for a UI element that allows the user to move content horizontally is a crawlbar.

Say it with me: crawlbar. Sounds a bit more negative, doesn’t it? A negative-sounding term seems fitting for a very negative user experience.

If you like this bit of Lakoffian political language, start using the word “crawlbar” in your meetings and documentation. You might get some strange looks to start with, but if enough of us do it, we can perform a little piece of linguistic corrective surgery.