Our static tools and linear workflows aren’t the right fit for the flexible, diverse reality of today’s Web. Making prototyping a central element of your workflows will radically change how you approach problem solution and save you a lot of headaches – and money. But most importantly, you will be creating the right products and features in a way that resonates with the true nature of the Web. A discourse on processes, flexibility, the Web as a material, and how we build things.Saving Your Web Workflows with Prototyping – Matthias Ott
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.
Read more about Liquid and Responsive Web Design
- A Dao of Web Design by John Allsopp, A List Apart, April 2000
- Liquid Web Design: Build it right and it will work no matter what the container, by Nick Finck, Digital Web, August 1999
- What is Liquid Design? By Nick Wilson, November 2002
- Flexible Foundations by Trent Walton, 2013
2006 DOESN’T seem forever ago until I remember that we were tracking IE7 bugs, worrying about the RSS feed validator, and viewing Drupal as an accessibility-and-web-standards-positive platform, at the time. Pundits were claiming bad design was good for the web (just as some still do). Joe Clark was critiquing WCAG 2. “An Inconvenient Truth” was playing in theaters, and many folks were surprised to learn that climate change was a thing.
I was writing the second edition of Designing With Web Standards. My daughter, who is about to turn twelve, was about to turn two. My dad suffered a heart attack. (Relax! Ten years later, he is still around and healthy.) A List Apart had just added a job board. “The revolution will be salaried,” we trumpeted.
Preparing for An Event Apart Atlanta, An Event Apart NYC, and An Event Apart Chicago (sponsored by Jewelboxing! RIP) consumed much of my time and energy. Attendees told us these were good shows, and they were, but you would not recognize them as AEA events today—they were much more homespun. “Hey, kids, let’s put on a show!” we used to joke. “My mom will sew the costumes and my dad will build the sets.” (It’s a quotation from a 1940s Andy Hardy movie, not a reflection of our personal views about gender roles.)
Jim Coudal, Jason Fried and I had just launched The Deck, an experiment in unobtrusive, discreet web advertising. Over the next ten years, the ad industry pointedly ignored our experiment, in favor of user tracking, popups, and other anti-patterns. Not entirely coincidentally, my studio had just redesigned the website of Advertising Age, the leading journal of the advertising profession.
Other sites we designed that year included Dictionary.com and Gnu Foods. We also worked on Ma.gnolia, a social bookmarking tool with well-thought-out features like Saved Copies (so you never lost a web page, even if it moved or went offline), Bookmark Ratings, Bookmark Privacy, and Groups. We designed the product for our client and developed many of its features. Rest in peace.
I was reading Adam Greenfield’s Everyware: The Dawning Age of Ubiquitous Computing, a delightfully written text that anticipated and suggested design rules and thinking for our present Internet of Things. It’s a fine book, and one I helped Adam bring to a good publisher. (Clearly, I was itching to break into publishing myself, which I would do with two partners a year or two afterwards.)
In short, it was a year like any other on this wonderful web of ours—full of sound and fury, true, but also rife with innovation and delight.
As part of An Event Apart’s A Decade Apart celebration—commemorating our first ten years as a design and development conference—we asked people we know and love what they were doing professionally ten years ago, in 2006. If you missed parts one, two, three, or four, have a look back.
- Mobile is today’s first screen. So design responsively, focusing on content and structure first.
- Websites and apps alike should remove distractions and let people interact as directly as possible with content.
- 90 percent of design is typography. And the other 90 percent is whitespace.
- Boost usability and pleasure with progressive disclosure: menus and functions that appear only when needed.
- One illustration or original photo beats 100 stock images.
- Design your system to serve your content, not the other way around.
- Remove each detail from your design until it breaks.
- Style is the servant of brand and content. Style without purpose is noise.
- Nobody waits. Speed is to today’s design what ornament was to yesterday’s.
- Don’t design to prove you’re clever. Design to make the user think she is.
Also published in Medium
Translated into French by Jean-Baptiste Sachsé
ACUMIN by Robert Slimbach is a new type family from Adobe that does for book (and ebook) designers what Helvetica has always done for graphic designers. Namely, it provides a robust yet water-neutral sans-serif, in a full suite of weights and widths. And unlike the classic pressing of Helvetica that comes on everyone’s computers—but like Helvetica Neue—Acumin contains real italics for every weight and width.
Reading about the design challenges Slimbach set himself (and met) helps you appreciate this new type system, whose virtues are initially all too easy to overlook, because Acumin so successfully avoids bringing a personality to the table. Enjoying Acumin is like developing a taste for exceptionally good water.
Nick Sherman designed the website for Adobe, and its subtly brilliant features are as easy to miss at first look as Acumin’s. For starters, the style grid on the intro page dynamically chooses words to fit the column based on the viewport size. Resize your browser and you’ll see how the words change to fill the space.
Heaps of behind-the-scenes calculation allow the page to load all 90 (!) fonts without breaking your pipes or the internet. Developer Bram Stein is the wizard behind the page’s performance.
Nick uses progressively enhanced CSS3 Columns to create his responsive multi-column layout, incorporating subtle tricks like switching to a condensed font when the multi-column layout shrinks below a certain size. (This is something A List Apart used to do as well; we stopped because of performance concerns.) In browsers like IE9 and earlier, which do not support CSS3 Multiple Column specification, the layout defaults to a quite readable single column. Nick adds:
It’s the first time I’ve used responsive CSS columns for a real-world project. This was both frustrating and fun because the CSS properties for controlling widows and orphans are very far behind what’s possible in InDesign, etc. It also required more thinking about vertical media queries to prevent a situation where the user would have to scroll up and down to get from the bottom of one column to the top of the next. If the viewport is too short to allow for easy reading across columns, it stays as a single column.
He describes the challenges of creating the site’s preview tool thusly:
We had to do some behind the scenes trickery in order to get the sliders to work for changing widths and weights. It’s a good way to allow people to type their own text and get a feeling for how the family can be used as a system for body text and headlines (unlike Helvetica, which is more limited to the middle range of sizes). Chris Lewis helped out a lot with getting this to work. It even works on a phone!
Book designers have long had access to great serif fonts dripping with character that were ideal for setting long passages of text. Now they have a well-made sans serif that’s as sturdy yet self-effacing as a waiter at a great restaurant. Congratulations to Robert Slimbach, Adobe, and the designers and developers mentioned or interviewed here. I look forward to seeing if Acumin makes it into new website designs (perhaps sharing some of Proxima Nova‘s lunch), especially among mature designers focused on creating readable experiences. And I pray Acumin makes its way into the next generation of ebook readers.
(Just me? In both iBooks and Kindle, I’m continually changing typefaces after reading any book for any period of time. All the current faces just call too much attention to themselves, making me aware that I am scanning text—which is rather like making filmgoers aware that they are watching projected images just when they should be losing themselves in the story.)
The interview was conducted by Nick Sherman at TypeLab on June 13, 2015. The website is part of Typographics TypeLab and is a demonstration of what can be done with web typography within 24 hours.
Remember: the future will come whether you design for it or not. If your company charges $300,000 for a website that won’t work on next week’s most popular device, your company won’t be able to stay competitive in this business. It might not even be able to stay in the business, period. After all, clients who pay for sites that break too soon will look elsewhere next time—leaving your company perpetually hunting for new clients in a downward spiral of narrowing margins and diminishing expectations.
Your company’s survival is tied to the ability of the products it makes to work in situations you haven’t imagined, and on devices that don’t yet exist. This has alwaysbeen the challenge of web design. It’s one A List Apart has taken seriously since we began publishing, and our archives are filled with advice and ideas you can boil down and present to your bosses.
Source: No Good Can Come of Bad Code
TODAY marks the 20th anniversary of Bill Gates’s famous letter about the web, and my first website, batmanforever.com, created with Steve McCarron and Alec Pollak for Donald Buckley of Warner Bros and optimized for Netscape 1.1.
Gates’s memo to employees, published this day twenty years ago and entitled “The Internet Tidal Wave” accurately identified the web as a threat to its kingdom of binary desktop software, and set Microsoft on course to “own” the browser, thereby holding back the threat for about fifteen years. A transcript of Gates’s memo is available at petri.com, along with a mixed bag of then-and-now analysis. (Hat tip to Alan K’necht for the link.)
Today, of course, Microsoft embraces open web standards, while companies that didn’t exist at the time of the memo (like Google) or were insignificant competitors seemingly on their way to the grave (like Apple) enjoy the godlike position Microsoft once held—and used every trick in the book to hold onto.
The Batman Forever site was much shorter-lived and far less influential than the Gates memo, although we did manage to introduce web design ideas like animated entrance tunnels and metaphor-based navigation—things we later abjured. My partner Steve got out of web design and is a VP Creative Director director at Publicis. My partner Alec stuck with web and software design, but from the agency side. I stayed in web design, and I even still call it that…although I also sometimes just call it design. Our first web client Donald Buckley is a huge deal at Showtime.
“Jeffrey Zeldman Presents” turns 20 on May 31.
THANK YOU for the screen shot. I was actually already aware that the type on my site is big. I designed it that way. And while I’m grateful for your kind desire to help me, I actually do know how the site looks in a browser with default settings on a desktop computer. I am fortunate enough to own a desktop computer. Moreover, I work in a design studio where we have several of them.
This is my personal site. There are many like it, but this one is mine. Designers with personal sites should experiment with new layout models when they can. Before I got busy with one thing and another, I used to redesign this site practically every other week. Sometimes the designs experimented with pitifully low contrast. Other times the type was absurdly small. I experimented with the technology that’s used to create web layouts, and with various notions of web “page” design and content presentation. I’m still doing that, I just don’t get to do it as often.
Many people who’ve visited this site since the redesign have commented on the big type. It’s hard to miss. After all, words are practically the only feature I haven’t removed. Some of the people say they love it. Others are undecided. Many are still processing. A few say they hate it and suggest I’ve lost my mind—although nobody until you has suggested I simply didn’t have access to a computer and therefore didn’t know what I was designing. This design may be good, bad, or indifferent but it is not accidental.
A few people who hate this design have asked if I’ve heard of responsive web design. I have indeed. I was there when Ethan Marcotte invented it, I published his ground-breaking article (and, later, his book, which I read in draft half a dozen times and which I still turn to for reference and pleasure), and I’ve had the privilege of seeing Ethan lecture and lead workshops on the topic about 40 times over the past three years. We’ve incorporated responsive design in our studio’s practice, and I’ve talked about it myself on various stages in three countries. I’m even using elements of it in this design, although you’d have to view source and think hard to understand how, and I don’t feel like explaining that part yet.
This redesign is a response to ebooks, to web type, to mobile, and to wonderful applications like Instapaper and Readability that address the problem of most websites’ pointlessly cluttered interfaces and content-hostile text layouts by actually removing the designer from the equation. (That’s not all these apps do, but it’s one benefit of using them, and it indicates how pathetic much of our web design is when our visitors increasingly turn to third party applications simply to read our sites’ content. It also suggests that those who don’t design for readers might soon not be designing for anyone.)
This redesign is deliberately over the top, but new ideas often exaggerate to make a point. It’s over the top but not unusable nor, in my opinion, unbeautiful. How can passages set in Georgia and headlines in Franklin be anything but beautiful? I love seeing my words this big. It encourages me to write better and more often.
If this were a client site, I wouldn’t push the boundaries this far. If this were a client site, I’d worry that maybe a third of the initial responses to the redesign were negative. Hell, let’s get real: if this were a client site, I wouldn’t have removed as much secondary functionality and I certainly wouldn’t have set the type this big. But this is my personal site. There are many like it, but this one is mine. And on this one, I get to try designs that are idea-driven and make statements. On this one, I get to flounder and occasionally flop. If this design turns out to be a hideous mistake, I’ll probably eventually realize that and change it. (It’s going to change eventually, anyway. This is the web. No design is for the ages, not even Douglas Bowman’s great Minima.)
But for right now, I don’t think this design is a mistake. I think it is a harbinger. We can’t keep designing as we used to if we want people to engage with our content. We can’t keep charging for ads that our layouts train readers to ignore. We can’t focus so much on technology that we forget the web is often, and quite gloriously, a transaction between reader and writer.
Most of you reading this already know these things and already think about them each time you’re asked to create a new digital experience. But even our best clients can sometimes push back, and even our most thrilling projects typically contain some element of compromise. A personal site is where you don’t have to compromise. Even if you lose some readers. Even if some people hate what you’ve done. Even if others wonder why you aren’t doing what everyone else who knows what’s what is doing.
I don’t think you will see much type quite this big but I do think you will see more single-column sites with bigger type coming soon to a desktop and device near you. For a certain kind of content, bigger type and a simpler layout just make sense, regardless of screen size. You don’t even have to use Typekit or its brothers to experiment with big type (awesome as those services are). In today’s monitors and operating systems, yesterday’s classic web fonts—the ones that come with most everyone’s computer—can look pretty danged gorgeous at large sizes. Try tired old Times New Roman. You might be surprised.
The present day designer refuses to die.
IN EPISODE NO. 65 of The Big Web Show (“everything web that matters”), I interview Tim Brown of Typekit and Nice Web Type on where we are with web fonts, real web type in real web context, using Dribbble to develop a tone of voice, how saving small snippets of other people’s content can turn you into a blogger, Samantha Warren’s Style Tiles, molten leading orbital content, pages versus chunks, the type-driven design, web font fallbacks, the connection between leading and font family, transitioning from university work to Typekit, and much more.
Listen to The Big Web Show #65: Tim Brown.
Links mentioned in this show are numerous, enlightening, and available for your pleasure.
Subscribe to The Big Web Show
The Big Web Show features special guests and topics like web publishing, art direction, content strategy, typography, web technology, and more. Get episodes delivered to you automatically:
FacitWeb on Typekit:
Modular scales — meaningful numbers for layout:
More Meaningful Typography:
Web Font Specimen:
Real Web Type in Real Web Context:
How I use Twitter:
On leaving Vassar:
Font Events – Typekit Blog:
Ffffallback – a webfont fallback app:
Nice Web Type:
The Articulate Web Designer of Tomorrow – 24 Ways:
Orbital Content – A List Apart:
Fonts in Use:
Facit web font:
Nice Web Type:
Design by Front:
Style Tiles – Samantha Warren:
Molten Leading – Nice Web Type:
Tim Brown on Dribbble:
Principles of Typography on the Web:
IN The ‘trouble’ with Android, Stephanie Rieger points out the ludicrous number of Android screen sizes on a typical UK client’s website and comes to this conclusion:
If … you have built your mobile site using fixed widths (believing that you’ve designed to suit the most ‘popular’ screen size), or are planning to serve specific sites to specific devices based on detection of screen size, Android’s settings should serve to reconfirm how counterproductive a practice this can be. Designing to fixed screen sizes is in fact never a good idea…there is just too much variation, even amongst ‘popular’ devices. Alternatively, attempting to track, calculate, and adjust layout dimensions dynamically to suit user-configured settings or serendipitous conditions is just asking for trouble.
I urge you to read the entire article—it’s brief yet filled with rich chocolatey goodness.
Responding to it, Marc Drummond concludes that responsive web design default breakpoints are dead and urges designers to “use awkwardness as your guideline, not ephemeral default device widths” and return to fluid design. (I believe he may actually be thinking of liquid layout—the kind we practiced back in the early mid-1990s when cross-platform and multi-manufacturer desktop screen sizes and pixel-per-inch ratios—not to mention strong user font, size, and color preference options—made fixed-width layout design challenging if not impossible. As I understand fluid design, it is merely another word for responsive design, in that it relies on CSS3 media queries set to breakpoints.)
We’ve lost our compass
Rieger and Drummond are hardly alone in feeling that “our existing standards, workflows, and infrastructure” cannot support “today’s incredibly exciting yet overwhelming world of connected digital devices” (futurefriend.ly) and that something new must be done to move the web forward. And of course ppk has been warning us about the multiplicity of platforms and viewports on mobile since 2009.
Agreed: that is an exciting and challenging time; that fixed width layouts do not address, and adaptive layouts (multiple fixed-width layouts set to common breakpoints) do not go far enough in addressing, the challenges posed by our current plethora of mobile screen sizes, zoom settings, embedded views (i.e. “browser” windows inside app windows, often with additional chrome) and what Rieger calls “the unintended consequences” that occur as these various settings clash in ways their creators could not have anticipated.
If breakpoints are dead, responsive design is dead
Of course, if breakpoints are dead, responsive design is dead, because responsive design relies on breakpoints both in creative workflow and as a key to establishing user-need-and-context-based master layouts, i.e. a minimal layout for the user with a tiny screen and not much bandwidth, a more fleshed-out one for the netbook user, and so on.
But responsive design is not dead; it has only begun. It is not a panacea but was never intended to be. It is simply the beginnings of an approach.
I respect those colleagues who say breakpoints are dead, understand how they reached this conclusion, and am eager to see where it takes them in the coming months as they experiment with new methods, perhaps developing wonderful and unforeseen best practices. I hope design will be a brilliant part of these new methods, not something that gets abandoned to create a bland but workable lightweight experience for all.
But I also believe it is possible to draw a different conclusion from the same data. It is even possible, I believe, to say the present data doesn’t matter—at least not in the long run.
Tale of the chart
There was a time in the late 1990s when industrious web designers showed how atrocious CSS support was in browsers. Eric Meyer’s Master Compatability Chart for Web Review, formerly at http://www.webreview.com/pub/wr/style/mastergrid.html, was one of the best, but is no longer available for your historical viewing pleasure—not even at the mighty Wayback Machine. That’s too bad, as it would have perfectly illustrated my point. The chart used a variety of colors to show how each detail of the entire CSS specification was or was not supported (and if supported, whether it was supported correctly and completely, partially and correctly, partially and somewhat incorrectly, or completely incorrectly) in every browser which was available at the time, including, if memory serves, close to a dozen versions of Netscape, Explorer, and Opera.
Looking at that chart induced nausea and vertigo. It was easy to draw the conclusion that CSS wasn’t ready for primetime. (That was the correct conclusion at the time.) It was also easy to look at the table and decide that table layouts and font tags were the way to go.
That’s what most designers who even bothered looking at Eric’s chart decided, but a few (Eric and me included) drew a completely other inference. Instead of trying to memorize all the things that could go wrong in each browser, we created general rules for what worked across all browsers (e.g. font-size in px, floats for layout) and advocated design based on the things that work. This, I believe, is exactly what the futurefriend.ly and Move the Web Forward folks are doing now: trying to figure out commonalities instead of bogging down in details. (This is why some in our community have labeled futurefriend.ly and Move the Web Forward “WaSP II.”)
The other inference Eric, I, and others in the 1990s drew from Eric’s chart was that browser makers must be petitioned to support CSS accurately and correctly. We and many of you reading this engaged in said petitioning, and thanks largely to help from with the browser engineering community (from people like Tantek Çelik and Chris Wilson and organizations like Mozilla) it came to pass.
Of mice and markets
We cannot, of course, petition all the makers of, say, Android devices to agree to a set of standard breakpoints, because there are over 500 different Android devices out there, many of which will fail in the coming months—or if not outright fail, simply be replaced in the course of planned obsolescence AKA upgrading that drives the hardware segment. And each new product will in turn introduce new incompatibilities (AKA “features”).
In the short run it’s going to be hell, just as the browser wars and their lack of support for common standards were hell. But it is the short run.
500 standards is no standard. Give a consumer 500 choices and the price-driven consumer picks what comes with her plan, while the selective consumer begins gravitating toward a handful of emerging market leaders. Eventually this nutty market will stabilize around a few winning Android platforms (e.g. Kindle Fire) and common breakpoints will emerge. What The Web Standards Project achieved with browser makers, the market will achieve with phones.
Until that time, designers certain can abandon breakpoints if they can find a way to do good design under purely fluid conditions—design that pleases the user, satisfies the client, and moves the industry forward aesthetically. But designers who persist in responsive or even adaptive design based on iPhone, iPad, and leading Android breakpoints will help accelerate the settling out of the market and its resolution toward a semi-standard set of viewports. This I believe.
When I see fragmentation, I remind myself that it is unsustainable by its very nature, and that standards always emerge, whether through community action, market struggle, or some combination of the two. This is a frustrating time to be a web designer, but it’s also the most exciting time in ten years. We are on the edge of something very new. Some of us will get there via all new thinking, and others through a combination of new and classic approaches. Happy New Year, web designers!
It’s funny. My daughter always asks what’s my favorite color, and I can never answer, ’cause I love them all. With color, it depends on context and it’s all about combination. But a favorite font? You bet I’ve got one. It’s Franklin Gothic, and especially Franklin Gothic Condensed. Has been for years.
For several years now I’ve used a licensed Franklin Gothic web font by someone other than Webtype here. It was good but not perfect.
Webtype’s Franklin Condensed is as close to perfect as web fonts can come in October, 2011. (And as they improve it, the look and feel here will improve as well.) The font is so good that it emboldened me to apply it to other parts of the page that formerly had to make do with Helvetica. See, for instance, my footer. It’s not a work of art, but it’s now much more pleasant to read in every environment I’ve tested.
I’m still conservative about web fonts (primarily because of bandwidth issues); this site’s body text is still set in Georgia, one of the world’s most beautiful screen fonts as we all agree. This morning, simply to break away from the herd, I tried replacing Georgia with Palatino, an engaging, readable, widely available font that comes with Windows 2000/XP (“Palatino Linotype”) and the Macintosh (“Palatino”). On its own, the Palatino was lovely. But it couldn’t stand up to the heavier elements of this site’s somewhat cartoonish look and feel. So back to Georgia I went.
The site is overdue for a redesign: the last redesign (e.g. the current look and feel) was a retro tribute to the site’s 1990s look. A new look is coming, but for the interim, I’m grateful to my friends at Webtype for their craftsmanship.