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
Jeremy Wagner’s “Now THAT’S What I Call Service Worker!” provides innovative techniques to harness the power of Progressive Web Apps with smaller HTML payloads and better performance for repeat visitors.
“IN AN INDUSTRY that extols innovation over customer satisfaction, and prefers algorithm to human judgement (forgetting that every algorithm has human bias in its DNA), perhaps it should not surprise us that toolchains have replaced know-how.”
Our addiction to complicated toolchains and overbuilt frameworks is out of control. Web-making has lately become something of a dick-measuring competition. It needn’t stay that way.
If we wish to get back to the business of quietly improving people’s lives one thoughtful interaction at a time, we must rid ourselves of the cult of the complex. For more about why and how, see my new article, “The Cult of the Complex,” in A List Apart, for people who make websites.
Illustration by Kevin Cornell
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.
WE have creative directors and design directors, but we don’t seem to have any front-end directors. And maybe we should.
For years at big companies, people in different silos have written CSS with no information or understanding about each other’s work. This results in huge, sloppy files that have a negative impact on site performance, as folks write more and more complex rules trying to override pre-existing ones … or “solve” the problem by adding dozens or even hundreds of classes to their CSS and markup.
Professionals with serious front-end chops have tried to solve the problem by coming up with complex rules and systems which, by the time they filter their way down to less experienced developers, get turned into dogma. Every time I see a front-end article’s comments section rapidly fill with absolute statements about whether it’s okay or not to use
id, I recognize that someone’s good idea has turned into somebody else’s religion.
And while I commend my colleagues who craft approaches to CSS that help avoid the inevitable problems large-scale enterprises encounter when many coders in many silos work on many components without talking to each other, I think there may be another way to look at the problem.
We all know having many people in many silos write CSS any old way doesn’t work, unless you consider bloat and poor performance working.
And while restricting how you allow people to write code solves some of these problems, it introduces others: too many class names is just another word for bloat.
So how about following the example of other creative endeavors, and putting a single mind in charge? After all, no matter how many disparate photographers, teamed with how many art directors, work on a given issue of a periodical, there’s always a lead art director who advises, helps plan shoots, and ultimately approves the work. Every orchestra requires a conductor. And no matter how many animators work on a film, there’s always a director. There’s a reason for that.
Imagine shooting a film with no director and no storyboards, in which each scene was written by a different screenwriter, and nobody knew the shape of the overall story. It wouldn’t make a coherent movie, much less a good one. Yet that’s how too many big organizations still approach front-end design and development.
So here’s a thought, big orgs. Instead of throwing a thousand front-end developers at your problem and seeing what sticks, consider creating a front-end director position as empowered as any other director at your organization.
CSS GRID LAYOUT is nearly finalized. Which means it’s time for designers and front-end developers to set the flags enabling their browsers to support the new specification, put CSS Flexbox through its paces by using it to create layouts, and see if anything breaks. This way, if anything does break, we’ll have time to tell the framers of CSS Grid Layout what happened, and get the spec (and browser support) fixed before it is released. Once Grid is finalized, it will be too late to fix oversights.
The links below can help you (and me) get up to speed with the new tech:
CSS Grid Layout and CSS Flexbox Links
- CSS Grid Spec
- How to enable CSS Grid Layout in your browser
- Grid By Example: Learn CSS Grid Layout by doing, with these incredibly useful examples by Rachel Andrew. Newly updated. Fun!
- A Complete Guide to Grid by Chris Coyier
- A Complete Guide to Flexbox by Chris Coyier
- Though CSS Flexbox is better suited to laying out modules (rather than entire pages—that’s what Grid is for), Phillip Walton has used it to solve a classic CSS page layout problem: Holy Grail layout in Flexbox
- Vertical centering? Easy. Equal height columns? By default. Paul Robert Lloyd gets to grips with CSS Flexbox and finds a lot to like: CSS Flexbox Is Entirely Logical (Almost)
- Three Years with CSS Grid Layout by Rachel Andrew
- Grid, Flexbox, Box Alignment: Our New System for Layout by Rachel Andrew
- CSS Grid Layout Examples: Several examples showing different CSS Grid Layout use cases
- CSS Grid and the Box Alignment Module
Additional link curation by Rachel Andrew, author of Get Ready for CSS Grid Layout from A Book Apart, and speaker extraordinaire at An Event Apart Nashville, a three-day conference that wrapped yesterday. For a ton of great web resources, see AEA Resources: Articles, Links, and Tools From An Event Apart Nashville 2016.
RACHEL ANDREW—longtime web developer and web standards champion, co-founder of the Perch CMS, and author of Get Ready For CSS Grid Layout—is my guest on today’s Big Web Show. We discuss working with CSS Grid Layout, how Grid enables designers to “do something different” with web layout, why designers need to start experimenting with Grid Layout now, how front-end design has morphed into an engineering discipline, learning HTML and CSS versus learning frameworks, and the magic of David Bowie, RIP.
Enjoy Episode ? 141 of The Big Web Show.
- 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é
AN EVENT APART, the design conference for people who make websites, seeks a freelance, part-time, front-end developer to work with our web designer, creative director, and project manager on ongoing design and UX improvements to our site at aneventapart.com.
For details, and to apply, see our listing on weworkremotely.com.
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
IN BIG WEB SHOW Episode ? 117, Tom Giannattasio, Founder/CEO of Macaw, “the superhot web design tool of the future,” joins me to discuss a paradigm shift: can we really draw semantic HTML and succinct CSS? How it works. Pixels, percentages, ems, or rems? Designing a design tool. How to quit your job. From Kickstarter to startup. Team building. Responsive design, responsive community.
AN EVENT APART Chicago—a photo set on Flickr. Pictures of the city and the conference for people who make websites.
Notes from An Event Apart Chicago 2013—Luke Wroblewski’s note-taking is legendary. Here are his notes on seven of the ten presentations at this year’s An Event Apart Chicago.
#aeachi—conference comments on Twitter.
Chicago (Foursquare)—some of my favorite places in the city.
An Event Apart Chicago—sessions, schedule, and speaker bios for the conference that just ended.
AEA Chicago 2013 on Lanyrd—three days of design, code, and content on the social sharing platform for conferences.
A handful of seats are available for the final event of the year, An Event Apart San Francisco at the Palace Hotel, December 9–11, 2013. Be there or be square.
Except when I occasionally update Designing With Web Standards, I quit writing hands-on, nuts-and-bolts stuff about CSS and HTML years ago. Publishing abhors a vacuum: other designers and developers took my place. For the most part, this has been a good thing—for them and for our industry. The best writers about code have always been those who spend 25 hours of every day up their necks in it, as I used to. While folks like me migrate into strategic or supervisory roles (providing us with new places to innovate and new things to write about), a new generation of code crafters is making new discoveries and sharing new teachings. Ah, the magical circle of life.
But amid the oodles of resulting goodness, I find occasional stinkers. Take the notion, now concretizing into dogma, that
id should almost never be used because it has “too much specificity,” and that
class names are always preferable. Respectfully, I call bunk.
To my knowledge, this notion comes out of Nicole Sullivan’s brilliant Object Oriented CSS, an approach for writing HTML and CSS that is designed to scale on sites containing thousands of pages, created by dozens of front-end developers over a period of years, generally with no rules or style guide in place (at least no rules or style guide until it is too late). On sites like these—sites like Amazon or Facebook that are hosed from the get-go thanks to too many cooks and no master chef—the use of structural
id and descendant selectors can be problematic, especially when inept coders try to overwrite an
id-based descendant selector rule by creating ever-more-specific descendant selector rules.
In this particular (and rare) circumstance, where dueling developers have added rule after rule to a huge, shapeless style sheet that is more of an archeological artifact than a reasonable example of modern code, Nicole’s admonition to avoid descendant selectors based on
id is probably wise. If you have the misfortune to work on a huge, poorly developed site where you will never have permission to refactor the templates and CSS according to common sense and best practices, you may have to rely on class names and avoid descendant selectors and
But under almost any other circumstance, properly used
ids with descendant selectors are preferable because more semantic and lighter in bandwidth.
The way I have always advocated using
id, it was simply a predecessor to the new elements in HTML5. In 2000, we wrote
div id="footer" because we had no footer element, and we wanted to give structural meaning to content that appeared within that div. Today, depending on the browsers and devices people use to access our site, we may well have the option to use the HTML5
footer element instead. But if we can’t use the HTML5 element, there is nothing wrong with using the
As for descendant selectors, in a site not designed by 100 monkeys, it is safe to assume that elements within an
id’d div or HTML5 element will be visually styled in ways that are compatible, and that those same elements may be styled differently within a differently
id’d div or HTML5 element. For instance, paragraphs or list items within a
footer may be styled differently than paragraphs or list items within an
aside. Paragraphs within a
footer will be styled similarly to one another; the same goes for paragraphs within an
aside. This is what
id (or HTML5 element) and descendant selectors were made for. Giving every paragraph element in the sidebar a classname is not only a needless waste of bandwidth, it’s also bad form.
Say it with me: There is nothing wrong with
id when it is used appropriately (semantically, structurally, sparingly). There is plenty wrong with the notion that
class is always preferable to descendant selectors and semantic, structural
Please understand: I’m not disparaging my friend Nicole Sullivan’s Object Oriented CSS as an approach to otherwise unmanageable websites. No more would I disparage a steam shovel for cleaning up a disaster site. I just wouldn’t use it to clean my room.
I’ll be discussing code and all kinds of other things webbish with Chris Coyier and Dave Rupert on the Shoptalk podcast today. Meanwhile, let me know what you think. And don’t forget November 30th is the sixth international celebration of Blue Beanie Day in support of web standards. Wherever you may stand on the great
id debate, please stand with me and thousands of others this November 30th.
“WE ARE ALL PUBLISHERS,” claims Issue No. 353 of A List Apart for people who make websites. Design books with CSS3; craft a responsive web résumé.
by NELLIE MCKESSON
While historically, it’s been difficult at best to create print-quality PDF books from markup alone, CSS3 now brings us the Paged Media Module, which targets print book formatting. “Paged” media exists as finite pages, like books and magazines, rather than as long scrolling stretches of text, like most websites. With a single CSS stylesheet, publishers can take XHTML source content and turn it into a laid-out, print-ready PDF. You can take your XHTML source, bypass desktop page layout software like Adobe InDesign, and package it as an ePub file. It’s a lightweight and adaptable workflow, which gets you beautiful books faster. Nellie McKesson, eBook Operations Manager at O’Reilly Media, explains how to build books with CSS3.
by ANDREW HOFFMAN
Grizzled job hunting veterans know too well that a sharp résumé and near-flawless interview may still leave you short of your dream job. Competition is fierce and never wanes. Finding new ways to distinguish yourself in today’s unforgiving economy is vital to a designer/developer’s survival. Happily, web standards whiz and mobile web developer Andrew Hoffman has come up with a dandy differentiator that is just perfect for A List Apart readers. Learn how to author a clean résumé in HTML5/CSS3 that scales well to different viewport sizes, is easy to update and maintain, and will never grow obsolete.
Illustration by Kevin Cornell for A List Apart.