Journal 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.

I don’t often get the chance to listen to many podcasts but when I do, there are a few that I have waiting in my iPod:

• Mark Kermode’s film reviews from BBC Radio 2,
• In Our TIme with Melvyn Bragg from BBC Radio 4, which even has its own wiki-driven fansite,
• The Guardian’s science podcast featuring regular appearances from Bobbie and
• WNYC’s Radiolab—probably my favourite. If you haven’t heard it yet, do yourself a favour and listen back through the archives of mindblowingly good past episodes.

A recent addition to the podcast parade comes courtesy of Messrs. Hicks and Oxton. Broadcasting from their RAF base, they produce The Rissington Podcast—Gardener’s Question Time for the Web. The podcast also sports a brand new website that positively drips with delight. Go ahead and resize the browser window… admire that header, gasp at that footer.

See, this one of the reasons why I’m such a fan of liquid layouts. Not only do they feel inherently more “webby”, more in-tune with the medium, they also offer more capacity to delight. I know they’re harder to build. Fixed width layouts are certainly the easier option. But just as safe design won’t ever offend or excite, safe layouts won’t have quite the same propensity for delivering that warm glow of satisfaction that comes with having a website flow to fit the dimensions of your browser window. See also: Unstoppable Robot Ninja. Gorgeous.

But back to podcasts… I’m almost done with the dConstruct 2007 podcast—just one more talk left to put up. The presentations were ably recorded on the day by Drew. Speaking of whom, it’s that time of the year again: 24 Ways is back. Drew opens up the first window on the advent calendar with a piece on transparent PNGs in IE6. Expect another 23 high-quality articles to follow.

In a comment on Roger’s post about fixed and liquid layouts, Cameron wrote:

This issue seems to generate a heated debate every time it’s mentioned. I imagine one could pen an article with the headline “Fluid or fixed?” and nothing else, and yet dozens of comments would inevitably appear.

But rather than use that title, I couldn’t resist borrowing a pun from Andy, prompted by a post from Scrivs called What Resolution Will You Design for in 2007? (a classic example of the fallacy of many questions).

Now, firstly, we need to draw a distinction between monitor size and browser size. In other words, the difference between screen resolution and the viewport size:

• Browser size does matter - Actual numbers
• Actual Browser Sizes
• The ridiculous discussion about monitor sizes and screen resolutions
• The importance of window-width
• Design for Browser Size — Not Screen Size

There’s a real danger in thinking that “the numbers speak for themselves.” Numbers don’t speak for themselves; numbers need to be interpreted.

The numbers clearly show that monitor sizes and resolutions are getting bigger. The most common interpretation of that is more and more people have bigger displays. But an equally valid interpretation of the numbers is the range of displays is bigger than ever. It’s a subtle but important distinction. One interpretation focuses solely on the size of the highest numbers; the other interpretation focuses on the range of all the numbers.

The way I see it, the range is growing at both ends of the spectrum. Yes, desktop monitors are getting wider (though that doesn’t mean that viewports get any wider above a certain size) but handheld and gaming devices are likely to remain at the lower end of the scale. The Wii, for example, has a resolution of 640 x 480.

Mind you, the iPhone turns the whole question on its head with its scalable browsing. At MacWorld, Steve Jobs demonstrated this by visiting the New York Times, an unashamedly wide fixed-width website. On the Apple site, Wikipedia—a liquid layout— is shown fitting nicely on the display. The iPhone deals with both. Still, rather than letting my liquid layouts scale down to the iPhone’s width, I should probably start putting a min-width value on the body element.

Speaking of which…

A common argument against using liquid layouts is the issue of line lengths. On the face of it, this seems like a valid argument. Readability is supremely important and nobody likes over-long line lengths. But it’s not quite as simple as that when it comes to readability on screen compared to print, as Richard noted:

Surprisingly, I find short line lengths tiresome on screen; I don’t really subscribe to the empirical prescription of 7–10 words per line for comfortable reading. Most novels have 10–15 words per line and I think the upper region of that range is more appropriate for screen.

In any case, the idea that liquid layouts automatically means long line lengths on large screens is, I feel, a misconception. The problem is that a lot of the examples of liquid layouts aren’t very good and line lengths do expand without limit. But it doesn’t have to be that way.

In my opinion, the most important addition to Internet Explorer 7 is the max-width property. It means that we can now really start to look at creating fluid layouts within defined parameters, as demonstrated by Cameron in Andy’s book. In fact, I think we’re just scratching the surface of what’s possible in creating seamless adaptive layouts (and, more importantly, seamless adaptive page elements) using the dual power of max-width and min-width.

That still leaves Internet Explorer 6 and below. Should they get unbounded fluid layouts or should they get a fixed width fallback? The second is certainly an option using conditional comments, which is the Microsoft-approved way of dealing with rendering inconsistencies. I think that the lack of support for max-width certainly falls into that category. Call it transcending CSS if you will; I call it routing around damage on the designer’s network.

I want to hear what you have to say… if you’ve got something new to say. Let’s not just rehash the same old arguments that would inevitably appear had I simply asked “Fluid or fixed?”

Technorati has been redesigned, or realigned if you prefer. It’s gone a bit gradient happy but overall, it’s quite a pleasing visual aesthetic.

For some reason though, they’ve chosen to lock the pages into a fixed width of 1024 pixels.

Now, I understand the reasoning behind fixed-width layouts. I can see the justification for wide fixed-width layouts on content-heavy sites like A List Apart (even if I disagree with it). But forcing users of what is fundamentally a web app to set their browser to a certain width seems counterproductive to me.

The content on Technorati is user-generated. Usually, that user is me. It has my favourites, my watchlist, and my search terms. I should be able to interact with that content in my way.

This is something that, as with so many things, del.icio.us gets just right. Upcoming is on the right track too. These sites allow me to interact with my data without putting me in a straitjacket.

Flickr is still avowedly fixed but the image-based, rather than text-based, nature of the data I store there makes this somewhat understandable.

Now, don’t misconstrue this as a tirade against 1024 pixel wide layouts. The problem would still exist in an 800 pixel wide design. Choosing an arbitrary number of pixels in which to serve up user-generated content is the issue here. On the one hand, Technorati is a very Web 2.0 sort of site, based on user-generated distributed content and collective wisdom. On the other hand, its visual design is grounded in a very Web 1.0 idea of top-down control and inflexibility.

I like Technorati a lot. It’s come on in leaps and bounds in the past couple of years. I’d like to use it every day. I’m even willing to put up with the oversize ads. But I resent the feeling that I should adjust my browsing environment to the needs of the site, rather than the other way around.