JOIN An Event Apart’s Eric Meyer on a journey through the inner workings of CSS Grid as he tests various techniques to build a tic-tac-toe board filled with content. Hearkening back to the early days of CSS and A List Apart, these playful hacks rekindle a spirit of experimentation.
A liquid page will resize to fit whatever size browser window (within reason) that the user has available. … the real goal in building a website is to provide the user with a seamless interface to information. The site should not intrude on the user’s thought processes, but should gently guide them to their desired destination. If a site doesn’t look right because it doesn’t fit the user’s browser window, then the design has become intrusive to the user. — Glenn Davis, quoted in 15 Minutes, sometime in 1997.
TWO DECADES before Responsive Web Design, we dipped our toes in Liquid Layout — a similar but necessarily less refined concept. Glenn Davis of Project Cool fame coined the phrase in 1995 or 1996. (Glenn also came up with“Ice” to describe fixed-width layouts, and “Jello” for layouts that combined some fixed with some flexible elements.)
Liquid Layout was mainly what John Allsopp had in mind when he wrote A Dao of Web Design for A List Apart (quite possibly the most influential article we ever published). The most famous paragraph in that famous article explains…
The control which designers know in the print medium, and often desire in the web medium, is simply a function of the limitation of the printed page. We should embrace the fact that the web doesn’t have the same constraints, and design for this flexibility. But first, we must “accept the ebb and flow of things.”
Everything new is old
Modern designers look back at Allsopp’s article and think John must have been a time traveler who had seen the future of responsive design and mobile devices. In fact, though, John was simply a highly skilled (and extremely articulate) mainstream developer. As such, he was familiar with Liquid Design and frequently used it in his work, along with other ideas mentioned in “Dao,” such as not forcing users to see a particular type size or typeface. To a good developer in those days, what mattered was making something that worked for everyone. (That should still be what good developers care most about, right?)
Liquid design was part of a “works for everyone” approach to web design, but it had limitations. For one thing, breakpoints hadn’t been invented. CSS layout was in its infancy, used by almost no one, except in experimental work. The ability to separate content and behavior from presentation was nonexistent, unless you limited “presentation” to setting type in a single column, letting the user override the type setting, and letting the column reshape itself to fit any viewport.
With so few controls available, Liquid design tended to become unusable in certain settings, and was almost always ugly.
Liquid design was Responsive design’s rough draft
Liquid design was immediately popular with developers when they were given permission to just make stuff — i.e. when they weren’t constrained by overly rigid Photoshop layouts. Designers almost never used Liquid design because the layouts moved so quickly into ugliness and unusability — too wide to read, or too narrow, or with overlapping columns in early CSS layouts. Designers also disdained Liquid layouts because most of us see our job as imposing brilliant order on ugly chaos, and fixed proportions always seemed to be part of that order.
Fig 1. The Web Standards Project: a liquid layout as seen on a wide computer screen. Designed by Andy Clarke in the early 2000s.
Fig 2. The Web Standards Project: a liquid layout as seen on a narrow computer screen. On the narrow screen, type overlaps and the page becomes unusable.
Ugly on one side. Unusable on the other. It took a special breed of designer to forge ahead with Liquid Layout anyway.
Were it were not for the iPhone and the phones and tablets that rose quickly in its wake, the W3C would likely not have invented breakpoints. And without breakpoints, there could be no Responsive Web Design. And without Responsive Web Design, created by a visually gifted designer and with tools to satisfy his peers, the idea that drove Liquid design back in the 1990s would not, at long last, have caught on.
It’s easy to view our current design thinking as more evolved than what we practiced in the past. And in some ways, it is. But if you read between the lines, it’s fair to say that our thinking was always advanced. It’s only now that our tools are beginning to catch up.
Start by asking questions. Sketch, share your sketches, ask more questions. Don’t be precious with your work. Don’t hurry to finish.
Why don’t nonprofit sites convert?
Living in New York and working in media, I talk to nonprofit organizations a lot. Big or small, they all say the same. No matter how much work they put into their apps and websites, they just don’t get enough new members. No matter how many expensive redesigns they undertake, they still don’t convert. Why is this?
Generally, it’s the same reason any site with a great product doesn’t convert: the organization spends too much time and effort on the pages and sections that matter to the organization, and too little on the interactions that matter to the member. (“Member” is NGOese for customer.)
Of course there are sites that don’t convert because they have a crappy product. Or an inappropriately priced product. Or because their content attracts people who are never going to be their customers, and gets missed by people who might want what they’re selling. Or because their content attracts nobody. Failure has a thousand fathers, and most businesses fail, so the fact that a website doesn’t convert could mean almost anything. (To know what it actually means, you need data, and you need to watch users interact with it.)
But with nonprofit sites, the product is almost always great, and the person visiting is almost always interested. So what goes wrong?
Never mind the user, here’s the About page
What goes wrong is that nonprofit stakeholders are so passionate about their mission—a passion that only deepens, the longer they work there—that they design an experience which reflects their passion for the mission, instead of one which maps to a member’s mental model.
NGOs lavish attention on their About page and mission statement and forget to work on their members’ immediate, transactional needs. And this is true even for those members who are as passionate about the cause, in their own way, as the stakeholders are in theirs. In the wake of a hurricane, a passionate member thinks of your site in hopes of donating food or giving blood. But nothing on the site calls out to that member and addresses her needs. All she sees are menus, headlines, and buttons trying to lead her to what matters to the organization — namely, the things it says about itself.
How to satisfy the user and convert at the same time
First, decide what one single action you, as the organization, want the user to perform. Should they sign up for your mailing list? Make a donation? Keep it singular, and make it simple. One form field to fill out is better than two; two is better than four.
Next, put yourself in the member’s shoes. What does that member wish to achieve on your website? Have you created transactions and content that allow her to do what she came to do? Have you designed and written menus, links, and headlines that help her find the content that matters to her? Forget the organization, for now. Pretend the only thing that matters is what the user wants. (Because, ultimately, it is.)
Do these things, and weave your singular, simple conversion opportunity into each screen sequence with which your user interacts. To optimize your chance of success, place the conversion opportunity at the very point where the user successfully finishes transacting the business that mattered to her. Not before (where it is only a distraction). Not in another part of the site (which she has no interest in visiting). She’s a lot likelier to sign up for your mailing list after you’ve helped her donate food to her neighbors than she is to sign up in an unsolicited popup window.
Thank you, Captain Obvious
All the above suggestions are obvious common sense, and have been known since transactional web design was in its infancy in the 1990s. And yet, because of organizational dynamics, internal politics, and our getting so close to our own material that our eyes go out of focus, we forget these simple ideas more often than we use them—and fail when success is so easy, and so close to hand.
Medium to pay writers; program similar to Readability
INTERESTING. Medium will now pay writers. The revenue to pay writers will derive, not from advertising—Medium scorns it—but from member contributions.
How Medium will pay writers
Medium now publishes two kinds of content: public content, viewable by anyone; and private, members-only content. Medium members pay a small monthly fee; in return they get access to members-only content.
As in the past, writers who write public content will not be paid, but they will have access to a potentially large audience. Only writers who write members-only content will have the potential to earn.
Payments will be based on “claps,” a UI experiment Medium introduced seemingly only a few days ago; readers are supposed to indicate how much they like a story by how hard (or how long) they press on the clap widget. None of this is explained to readers in context, but it’s pretty easy to figure out. At least, it is easy to figure out that clapping indicates approval, and that the longer you lean on the clapper, the higher the numeric approval level you can share.
The “clap” widget also appears on public stories, where it has no effect on how much the author will get paid—since writers of public stories will not get paid. On public stories, it’s just there for fun, and/or the make the author feel good. You can’t clap for your own story, which helps prevent the most obvious types of system gaming.
Initially, the payment program will be open only to a select group of writers, but if it succeeds, more and more writers will be included.
Why it matters
As the publisher of A List Apart, which has relied on advertising revenue in the past but is about to stop doing that; as a writer, reader, and passionate devotee of web-delivered content; and as a blogger at zeldman.com since 1995, I will be watching this experiment and hoping for its success. I became a Medium member as soon as the publication offered it, even though I have no interest in reading “exclusive,” members-only content. I did it to support Medium, which I see as one web pioneer’s attempt to keep the web a vital content ecosystem.
It’s the same reason I cheered for the Readability app invented by my friend Rich Ziade and his team, back in the day. I even served on Readability’s advisory board, for which I was paid—and asked—nothing. I did it because I believed in Readability’s mission to find a way to pay for content. That particular experiment died, but in many ways its spirit lives on in Medium, whose readable visual layout Readability helped to inspire.
I will not apply to be a paid Medium writer since I have my own magazine’s content and finances to figure out, and since I choose to publish my content publicly. But I applaud what Ev and his teammates are doing, and I will be watching.
I HADN’T heard from her in years. Suddenly, there she was in my in-box. Tentatively proposing coffee. Maybe lunch. A dam broke inside me, releasing a flood of warm memories. Our first, tentative contact ten years or more ago. Getting to know each other. Endless, happy discussions about where this thing was going. Coming together on goals and brand; on voice and tone. Finally, the joy of designing and launching her website. And then, abruptly, the last invoice and the hurried departure.
My former client. She had a new job now. She wanted to catch up. And, sheepishly, she admitted, she might want something more. Advice about a design problem.
Over an unassuming wooden table laden with summer lunch—mine was Ramen, hers was salad—we shared personal updates. Kids, relationships, projects. And then we got down to the real agenda: an issue at work that was stumping her. Desire for an outside perspective.
Former clients often feel slightly embarrassed about reaching out for a little free advice. They shouldn’t. As a designer, one of my greatest joys is to reconnect with good people whose projects I loved working on. Design is a job, but it’s also a relationship. When design is going well, the exchange of ideas is almost addictively exciting. And then, all too soon, the project ends, and, if you’re a consulting designer, and you’re lucky enough to have a steady stream of business, you move on to the next gig.
We designers have built-in forgetters: super powers that enable us to care passionately about the problem we’re solving and the people we’re solving it for, and then, absurdly, to discard those feelings as we move on to the next client and design problem.
Clients have a built-in forgetter too. They forget that our relationship, although partly monetary, was also very real. Many clients are self-conscious about reconnecting personally and asking for a small favor in the same breath. But I couldn’t welcome that more. If I can help people, it’s a joy to me. Collaborating on the discovery and solution to a problem isn’t just a stimulating mental exercise and a profession: it’s also a codependent rush.
Between the cracks of my studio’s bigger projects, I’m always looking for ways to help people. So, in the spirit of Ask Dr Web, I’m taking this opportunity to issue an invitation to folks located in or visiting New York. If you’re someone in my network—a former client or old friend or both—with a design problem to mull over, you don’t have to do the mulling alone. Ping me. And let’s do lunch.
Big Web Show № 159: If You Can’t Stand the Heatmaps, Stay Out of the Conversion, with @nickd
NICK Disabato (@nickd) and I discuss heat maps, conversion rates, design specialization, writing for the web, Jakob Nielsen, and the early days of blogging in Episode № 159 of The Big Web Show – “everything web that matters.” Listen and enjoy.
We’ve got some exciting news to share. Web and interaction design studio.zeldman is moving, from our digs at 148 Madison Avenue to a new location on Fifth Avenue. As of June 1, we’ll be designing, creating, and consulting out of our beautiful new studio space at The Yard: Flatiron North.
But we’re tired of playing landlord. Instead of debugging the internet router, tending to the recycling, hiring HVAC repair people, and seeking suitable replacement studio mates when a company moves out, we’d rather spend our time solving our clients’ design problems and making cool stuff like A List Apart, A Book Apart, The Big Web Show, and An Event Apart. And The Yard’s the perfect place for us to ply our trade and make our goods. (Plus we still get to rub shoulders with other creative business folk.)
We can’t take it with us: furnish your office with our stuff!
Running a co-working studio space meant buying a lot of furniture and equipment. Beautiful stuff, still in great condition. Elegant stuff, because we’re designers. Stuff we won’t need any more, now that we’re moving to new digs where somebody else does landlord duty. So we’re selling it, for a lot less than we paid. And that’s where (maybe) you come in.
Most everything must go, including our famous Eero Aarnio (style) ball chair (if its red cushions could talk!), custom Bo Concept shelving, Eames Desk Units from Design Within Reach, Herman Miller Aeron chairs (ditto), midcentury tulip table and side chairs, black glass desks, Nespresso espresso maker, file cabinets, icemaker, microwave oven, see-through glass mini-fridge, and more. These are beautiful things that inspire good design, and they deserve good homes.
Big Web Show № 158: Old Men Shake Fists at the Cloud – with Jim Coudal
IN Big Web Show № 158: internet veterans Jim @Coudal & Jeffrey @Zeldman on the death of blogging, the birth of Field Notes, the virtues of a subscription model, and much more. Begins in tears, ends in triumph. One of the most fun (and inspiring) episodes ever. Sponsored by Hotjar & Blue Apron.
AS THE HEAD of a newish design studio, I spend a fair amount of time writing proposals. And here’s how I like to do it.
I do it like a conversation, and that’s how we start: with phone calls and emails to one or two key decision makers, followed by a research period of about two to three weeks. And when I say research, what I’m really talking about—besides the usual competitive analysis, analytics, and testing—is even more conversations, but this time with a wider net of stakeholders and customers.
Some studios do this for free, and other studios only do it if the client has signed off on a huge project and paid the first big deposit. But we do this research for a fee. A small, reasonable, consulting fee. If the client then hires us to do the job, we deduct the research fee from the project cost. If they don’t, they’ve gained a lot of great information at a fair cost. (So far, they’ve never not hired us to go on and do the project.)
From intake to ideas
About two and half weeks into the research project, we have a strong idea of what matters most to the business and its customers, and we begin to have visions of solutions and innovations, large and small. We can’t help it. We’re interaction designers and it’s how our minds work.
After soaking in a potential client’s world for two-plus weeks, we can’t help beginning to invent designs that solve some of their big and small problems, and that enhance what’s already great about the client and their product. This happens in our heads whether we want it to or not.
At first, we are merely neutral listeners, forcing ourselves not to solve, not to imagine, but only to truly hear and understand. But within about fifteen days, we can’t help but begin imagining little modules and big sections, huge themes and tiny, innovative enhancements, which might please and help our client, their customers, or their staff. And so long as those ideas come from the product, come from what the client and their customers have told us, we feel free to begin sharing them.
The first design is written
We do that by writing a report where we share with the client what we’ve begun learning and thinking about their business. Although this report is structured like a business document, we think of it as the first part of design—the first written rough draft of articulating what the client’s business needs to do, and how design might help.
Because it’s a business document, and because we’re workers, not magical pixies, we share facts and data and things stakeholders and customers have said that ring true and that harmonize with other things other stakeholders and customers have said. But all that mustering of facts and data is in the service of a shared creative awakening to the design’s possibilities.
Start ugly to stay honest
Now let me tell you how we present our findings: we present them in a Google Doc that the client can access, share, and comment on. We know that many design studios spend much energy visually tarting up even their most basic client communications. Thus, even a humble invoice comes dressed for the prom.
But we don’t do that. We save aesthetics and beauty for the site design. We keep communications open and plain, like an Amish shirt. And we keep communications editable, because this is collaboration, this is conversation, this is not a dead artifact, a take-it-or-leave-it. And Google Docs is the perfect vehicle for it. Just as the traditionally formatted typewritten screenplay is the perfect, neutral vehicle for a writer to share with a director.
This initial research report, this poem of business, this first, rough, written design, presented to the client via the homey simplicity of Google Docs, elicits more client/designer conversation, more emails, more Basecamp posts, more internal discussions in the studio.
And then, after about a week, we present the client with our proposal. Which is clearly the product of all our conversations, and particularly of all the important agreements we reached during that research period. By the time our clients receive the proposal, they are already nodding, as if they always knew what it contained. Because, in a way, they did. Because, if we did our research right, we’ve merely externalized and articulated what they already felt but had not expressed.
And even now, when we’re asking for serious money to do a serious job, we submit our proposal via Google Docs—because prettified, overly branded proposals are about the studio that produces them, whereas our work is about the client and their product. Because even the most painstakingly researched and written proposal, if it is too pretty and too studio-branded, feels like boilerplate, whereas an ugly Google Doc is clearly just work, to be modified or agreed to or argued about.
This is just what we do at our studio. You can try it or not. Personally, I like this approach and I’ve never had a client complain. I’ve always felt a little dirty when presenting a pitch that was too visually polished, and I’ve never won a single gig with boilerplate. Every job has to be earned by studying and understanding and knowing how to share what you’ve understood. At least, that’s how we do it.