Category: Responsibility

Categories
Best practices Design eric meyer ethics Publisher's Note reportage Responsibility

Streaming suicide and other design decisions

“A 12-year-old girl live-streamed her suicide. It took two weeks for Facebook to take the video down.”

So reads the headline of a January 15 news story in The Washington Post. Saying that she’d been sexually abused by a family member, 12-year-old Katelyn Nicole Davis, of Polk County, Georgia, hanged herself, broadcasting the suicide via a 40-minute live stream seen worldwide.

While YouTube immediately removed the video, it “lingered on Facebook for nearly two weeks,” according to the Post’s reporting of Buzzfeed and other unspecified “media reports.”

First, it just hurts

I keep rereading the short article and its headline as if it will make sense or stop hurting on the next scan-through. As a human being, I can’t fully process the horror and sadness of this tragedy.

I was initially going to write “as a human being and the father of a 12-year-old girl,” but that last part shouldn’t matter. You don’t need to be the parent of a child Katelyn’s age and sex to feel the feelings.

Nor does there need to be someone in your life who was raped or molested—although, whether they’ve told you about it or not, there almost surely is. Statistically there are likely multiple someones in your life who have suffered unspeakably, too frequently at the hands of people whose main job in life was to protect them. I’m sorry to have to write these words, and I hope reading them doesn’t rip open wounds.

But the point is, even if you and everyone in your circle has lived a magical life untouched by too-common crimes and horrors, it is still unbearable to contemplate too closely what Katelyn must have felt, and what she did about it, and what watching what she did must have done to those who watched the video—both the empathetic majority, and the hopefully small minority of viewers who, because of their own damage, may have gotten off on it, edging just that much closer to some future sociopathic acting-out.

A designer’s job

On a personal level, I’m good citing horror and sadness as a reaction to this ugly story. But as a web and product designer, I can’t help but see it as another instance of what Eric Meyer and Sara Wachter-Boettcher warn about in their book, Design For Real Life. Namely:

For every wonderfully fresh use of the internet’s social power we conceive, we must always ask ourselves, how might this be used to make our world more hurtful, less loving, less kind? What unforeseen dangers might our well intentioned innovation unleash?

I published Design For Real Life, but I don’t cite Katelyn’s story or repeat Sara and Eric’s moral here to sell copies. I do it to remind us all that what we make matters. Our design decisions matter. The little qualms that might float through our minds while working on a project need to be examined, not suppressed in the interest of continued employment. And the diversity of our workforce matters, because it takes many different minds to foresee potential abuses of our products.

Streaming suicide, monitoring content

Live.me isn’t the first live streaming app, and, as a category, live streaming likely does more good than harm. The existence of a live streaming app didn’t drive a girl to kill herself, although, in despair at not being listened to, she might have found solace and an appeal in the idea that her suicide, witnessed globally, could lead to an investigation and eventual justice.

Similarly, when Facebook began allowing its customers to perform live streaming (or, in Nicole’s case) to post video streams from third parties, use cases like pre-teen suicide or the torture of a mentally disabled teenager most likely did not factor into those business decisions. But here we are.

And, as much content as Facebook produces in a day, you can’t really fault them for not always being johnny-on-the-spot when some of that content violates their guidelines. But surely they can do better. 

Invention is a mother

There’s no closing Pandora’s box, nor would we wish to. But we who create websites and applications must remain mindful, honest, and vigilant. We must strive to work in diverse teams that are better than homogenous groups at glimpsing and preparing for the unforeseen. More than ever, we must develop design practices that anticipate the horrible and tragic—not to mention the illegal and authoritarian.

And in life, as well as design, we must do a better job of asking ourselves what we are not seeing—what struggles the people we meet may be hiding from us, and how we can help them before it is too late.

Also published on Medium

Categories
Best practices CSS HTML industry Markup Off My Lawn! Responsibility Standards State of the Web The Essentials The Profession

Kiss My Classname

SORRY. I disagree. Nonsemantic classnames that refer to visual styles will always be a bad idea.

I’m sure you’re a good coder. Probably much better than I am these days. I know most of you weren’t around for the standards wars and don’t know how much damage non-semantic HTML and CSS did to the web.

I’ve worked on big sites and I understand how bloated and non-reusable code can get when a dozen people who don’t talk to each other work on it over a period of years. I don’t believe the problem is the principle of semantic markup or the cascade in CSS. I believe the problem is a dozen people working on something without talking to each other.

Slapping a visually named class on every item in your markup may indeed make your HTML easier to understand for a future developer who takes over without talking to you, especially if you don’t document your work and create a style guide. But making things easier for yourself and other developers is not your job. And if you want to make things easier for yourself and other developers, talk to them, and create a style guide or pattern library.

The codebase on big sites isn’t impenetrable because developers slavishly followed arbitrary best practices. The codebase is broken because developers don’t talk to each other and don’t make style guides or pattern libraries. And they don’t do those things because the people who hire them force them to work faster instead of better. It starts at the top.

Employers who value quality in CSS and markup will insist that their employees communicate, think through long-term implications, and document their work. Employers who see developers and designers as interchangable commodities will hurry their workers along, resulting in bloated codebases that lead intelligent people to blame best practices instead of work processes.

The present is always compromised, always rushed. We muddle through with half the information we need, praised for our speed and faulted when we stop to contemplate or even breathe. Frameworks built on newish worst practices seem like the way out, but they end up teaching and permanently ingraining bad habits in a generation of web makers. Semantics, accessibility, and clarity matter. Reusability is not out of reach. All it takes is clarity and communication.

Categories
Best practices Code Compatibility Content First content strategy Content-First Design Free Advice HTML Illustration Images IXD maturity mobile Mobile Multi-Device Off My Lawn! Performance photography Responsibility Responsive Web Design Standards State of the Web The Essentials The Profession Told you so tweets Usability User Experience UX Web Design Web Design History Web Standards Websites

The Year in Design

  • 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 German (also here) by Mark Sargent

Translated into French by Jean-Baptiste Sachsé

Translated into Turkish by omerbalyali.

Translated into Spanish by Tam Lopez Breit.

Categories
A Space Apart Advertising privacy Products Responsibility software Standards Startups State of the Web The Essentials Usability User Experience UX Web Design Web Design History

Ad Blocking Phase II

screenshot of Choice app from Been, Inc.

THE WORLD has finally caught up with Been, Inc. Three years ago, this tiny start-up company shared my studio space in New York. Their product idea was remarkably original: instead of passively accepting the data collection and loss of privacy that comes with most ad networks on the web, what if people had a choice—to either block ads and third-party trackers entirely, or earn rewards for letting ads through?

The initial web-based product, playfully designed by Monkey Do, took the scariness and complexity out of tracking issues, and returned the decision making power to the consumer. Unfortunately, the mainstream web wasn’t ready for ad blocking, and consumers en masse either weren’t ready to think about privacy, or simply didn’t know the company’s value proposition because of its nonexistent marketing budget. (The only thing that kills products faster than no marketing is poor execution—although a handful of products have survived both.)

To stay afloat in the face of mass indifference, the company temporarily pivoted, using a portion of their technology to facilitate sharing of web content between consumers, much like the late lamented Ma.gnolia or Pocket’s new Recommended section. But where Ma.gnolia and Pocket were/are text-powered, the pivoted Been app was primarily visual, which helped it gain traction in the eduation market. Grade-school teachers and kids loved using the app for research projects—and their support helped the company stay in business long enough for the internet to catch up with their ideas.

Version 2.0 of their Choice app for iOS is the product of years of work on user privacy, data ownership, and control. iOS fans can download it at www.been.mobi/getv2edu.

The company’s site explains the push-button mechanics through which you can choose to block ads and third-party trackers in your apps and Safari, or earn rewards by letting ads through and sharing (strictly non-personal) information with Been. (Earn Mode is limited to US users for now.)

When I foolhardily put down my deposit on a New York studio that was larger and more costly than what I needed, my hope was that it would attract a like-minded community of designers and tech companies from whom I would learn and be inspired. That was certainly the case with my friends at Been! I wish them great success at helping to bring the changes our web needs.

Categories
Performance Real type on the web Responsibility Standards State of the Web The Essentials Typography Usability Web Design Web Design History Web Standards

Web Performance Today

WEB DESIGNERS have cared about web performance since the profession’s earliest days. When I started, we saved user bandwidth by employing GIF images that had the fewest possible colors—with no dithering, when possible, and by using actual web text instead of pictures of web text. (Kids, ask your parents about life before CSS enabled, type designers created formats for, browsers finally supported, and Typekit quickly popularized web fonts.)

Later, we learned to optimize JPEGs and blur their backgrounds: the blurrier large swathes of a JPEG image can be, the lower the bandwidth requirements for the image. We found the optimally performant size for repeating background tiles (32 x 32 and 64 x 64 were pretty good) and abandoned experiments like single-pixel-wide backgrounds, which seemed like a good idea but slowed browsers, servers, and computers to a crawl.

We developed other tricks, too. Like, when we discovered that GIF images optimized better if they possessed repeating patterns of diagonal lines, we worked diagonal background images into a design trend. It was the trend that preceded drop shadows, the wicked worn look, and skeuomorpic facades, which were themselves a retro recurrence of one of the earliest styles of commercial web design; that trend, which was always on the heavy side, performance-wise, eventually gave way to a far more performant grid-driven minimalism, which hearkened back to classic 1940s Swiss graphic design, but which our industry (sometimes with little knowledge of design history) called “flat design” and justified as being “born digital” despite its true origins going back to pixels, protractors, and a love of Greek mathematics.

All of this nostalgia is prelude to making the obvious comment that web design today is far more complex than it was in those golden years of experimentation; and because it is so much more complex, front-end performance is also far more complicated. You didn’t need an engineering degree to run DeBabelizer and remove needless elements from your markup, but, boy, does front-end design today feel more and more like serious coding.

All of which is to say, if you’re a front-end designer/developer, you should probably read and bookmark Nate Berkopec’s “Ludicrously Fast Page Loads – A Guide for Full-Stack Devs.” While you’re at it, save it to Pocket, and as a PDF you can read on your tablet.

I cannot verify every detail Nate provides, but it is all in line with recommendations I’ve heard over and over at top conferences, and read in articles and books by such performance mavens as Jake Archibald, Lara Hogan, Scott Jehl, and Yesenia Perez-Cruz.

You should also pick up these great books on performance:

(It’s not why I wrote this post, but if you order Scott’s book today, you can save 10% when you enter discount code ABAHARVEST at checkout.)

Even the most complex site should work in any device that reads HTML. It should work if stylesheets fail to load or the device doesn’t recognize CSS. It should work if JavaScript fails to load or the device doesn’t recognize JavaScript. The principles of standards-based design will never change, no matter how complex our web becomes. And as it becomes more complex (and, arguably, much richer), it behooves us to squeeze every byte of performance we can.

Websites can never be too rich or too thin.

Categories
A List Apart Advertising Advocacy Authoring Bandwidth Deck, the Design development editorial glamorous HTML Ideas industry Journalism at its Finest maturity Publications Publisher's Note Publishing Responsibility Responsive Web Design Site Optimization Standards State of the Web Surviving The Essentials User Experience UX W3C Web Design Web Design History Web Standards writing

Publishing v. Performance—or, The Soul of the Web

MY SOUL is in twain. Two principles on which clued-in web folk heartily agree are coming more and more often into conflict—a conflict most recently thrust into relief by discussions around the brilliant Vox Media team, publishers of The Verge.

The two principles are:

  1. Building performant websites is not only a key differentiator that separates successful sites from those which don’t get read; it’s also an ethical obligation, whose fulfillment falls mainly on developers, but can only happen with the buy-in of the whole team, from marketing to editorial, from advertising to design.
  2. Publishing and journalism are pillars of civilized society, and the opportunity to distribute news and information via the internet (and to let anyone who is willing to do the work become a publisher) has long been a foundational benefit of the web. As the sad, painful, slow-motion decline of traditional publishing and journalism is being offset by the rise of new, primarily web-based publications and news organizations, the need to sustain these new publications and organizations—to “pay for the content,” in popular parlance—is chiefly being borne by advertising…which, however, pays less and less and demands more and more as customers increasingly find ways to route around it.

The conflict between these two principles is best summarized, as is often the case, by the wonderfully succinct Jeremy Keith (author, HTML5 For Web Designers). In his 27 July post, “On The Verge,” Jeremy takes us through prior articles beginning with Nilay Patel’s Verge piece, “The Mobile Web Sucks,” in which Nilay blames browsers and a nonexistent realm he calls “the mobile web” for the slow performance of websites built with bloated frameworks and laden with fat, invasive ad platforms—like The Verge itself.

“The Verge’s Web Sucks,” by Les Orchard, quickly countered Nilay’s piece, as Jeremy chronicles (“Les Orchard says what we’re all thinking”). Jeremy then points to a half-humorous letter of surrender posted by Vox Media’s developers, who announce their new Vox Media Performance Team in a piece facetiously declaring performance bankruptcy.

A survey of follow-up barbs and exchanges on Twitter concludes Jeremy’s piece (which you must read; do not settle for this sloppy summary). After describing everything that has so far been said, Mr Keith weighs in with his own opinion, and it’s what you might expect from a highly thoughtful, open-source-contributing, standards-flag-flying, creative developer:

I’m hearing an awful lot of false dichotomies here: either you can have a performant website or you have a business model based on advertising. …

Tracking and advertising scripts are today’s equivalent of pop-up windows. …

For such a young, supposedly-innovative industry, I’m often amazed at what people choose to treat as immovable, unchangeable, carved-in-stone issues. Bloated, invasive ad tracking isn’t a law of nature. It’s a choice. We can choose to change.

Me, I’m torn. As a 20-year-exponent of lean web development (yes, I know how pretentious that sounds), I absolutely believe that the web is for everybody, regardless of ability or device. The web’s strength lies precisely in its unique position as the world’s first universal platform. Tim Berners-Lee didn’t invent hypertext, and his (and his creation’s) genius doesn’t lie in the deployment of tags; it subsists in the principle that, developed rightly, content on the web is as accessible to the Nigerian farmer with a feature phone as it is to a wealthy American sporting this year’s device. I absolutely believe this. I’ve fought for it for too many years, alongside too many of you, to think otherwise.

And yet, as a 20-year publisher of independent content (and an advertising professional before that), I am equally certain that content requires funding as much as it demands research, motivation, talent, and nurturing. Somebody has to pay our editors, writers, journalists, designers, developers, and all the other specialtists whose passion and tears go into every chunk of worthwhile web content. Many of you reading this will feel I’m copping out here, so let me explain:

It may indeed be a false dichotomy that “either you can have a performant website or you have a business model based on advertising” but it is also a truth that advertisers demand more and more for their dollar. They want to know what page you read, how long you looked at it, where on the web you went next, and a thousand other invasive things that make thoughtful people everywhere uncomfortable—but are the price we currently pay to access the earth’s largest library.

I don’t like this, and I don’t do it in the magazine I publish, but A List Apart, as a direct consequence, will always lack certain resources to expand its offerings as quickly and richly as we’d like, or to pay staff and contributors at anything approaching the level that Vox Media, by accepting a different tradeoff, has achieved. (Let me also acknowledge ALA’s wonderful sponsors and our longtime partnership with The Deck ad network, lest I seem to speak from an ivory tower. Folks who’ve never had to pay for content cannot lay claim to moral authority on this issue; untested virtue is not, and so on.)

To be clear, Vox Media could not exist if its owners had made the decisions A List Apart made in terms of advertising—and Vox Media’s decisions about advertising are far better, in terms of consumer advocacy and privacy, than those made by most web publishing groups. Also to be clear, I don’t regret A List Apart’s decisions about advertising—they are right for us and our community.

I know and have worked alongside some of the designers, developers, and editors at Vox Media; you’d be proud to work with any of them. I know they are painfully aware of the toll advertising takes on their site’s performance; I know they are also doing some of the best editorial and publishing work currently being performed on the web—which is what happens when great teams from different disciplines get together to push boundaries and create something of value. This super team couldn’t do their super work without salaries, desks, and computers; acquiring those things meant coming to some compromise with the state of web advertising today. (And of course it was the owners, and not the employees, who made the precise compromise to which Vox Media currently adheres.)

Put a gun to my head, and I will take the same position as Jeremy Keith. I’ll even do it without a gun to my head, as my decisions as a publisher probably already make clear. And yet, two equally compelling urgencies in my core being—love of web content, and love of the web’s potential—make me hope that web and editorial teams can work with advertisers going forward, so that one day soon we can have amazing content, brilliantly presented, without the invasive bloat. In the words of another great web developer I know, “Hope is a dangerous currency—but it’s all I’ve got.”

Also published in Medium.

Categories
A List Apart Best practices Code Design development editorial Ethan Marcotte Future-Friendly HTML Responsibility Usability W3C Web Design Web Design History Web Standards Websites Zeldman

No Good Can Come of Bad Code: Ask Dr Web in A List Apart

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

Categories
Best practices Blogs and Blogging Community Design engagement Responsibility State of the Web twitter writing

140 Characters is a Joke

THERE IS ALWAYS more to the story than what we are told. I am not omniscient. It is better to light a single candle than to join a lynch mob. Other people’s behavior is not my business. Truth is hard, epigrams are easy. Anything worth saying takes more than 140 characters. Blogging’s not dead. F____ the 140 character morality police.

Categories
Design Platforms Products Publications Publishing Real type on the web Respect Responsibility Startups State of the Web The Essentials The Profession This never happens to Gruber

Readlists: behind the scenes

FROM THE HOME PAGE of today’s newly announced, totally disruptive, completely free product powered by Readability: “What’s a Readlist? A group of web pages—articles, recipes, course materials, anything—bundled into an e-book you can send to your Kindle, iPad, or iPhone.”

For some time now, people who miss the point have seen Readability as an app that competes in the read-it-later space. That’s like viewing Andy Warhol as a failed advertising art director. Readability is a platform that radically rethinks how we consume, and who pays for, web content. It monetizes content for authors and its technology is available to all via the API. It scares designers, angers some advertisers. Its transformative potential is huge. Readlists are the latest free product to manifest some of that potential.

With Readlist, anyone can create ebooks out of existing web content. It’s easy. Sign in with your Readability account or sign up for one, and start making books of your favorite web articles.

There are still some bugs being worked out, but hey.

I was honored to beta test the product and create one of the first Readlists, along with Erin Kissane, Anil Dash, Aaron Lammer, David Sleight, and Chris Dary.

Disclaimer: I am on the advisory board of Readability and cofounded The Deck advertising network with Jim Coudal and Jason Fried. Readability removes clutter (including ads) from the reading experience; The Deck sells ads. Conflict of interest? Here’s another: I design content websites so as to make Readability unnecessary (because I design for readers); yet I strongly support Readability as a platform and above all as a web idea that is at least 15 years overdue. Either designers will design for their end-users, or third-party apps will remove designers from the transaction. As a designer, I’m not afraid of that. Rather, it inspires me.

Enjoy Readlists.

Categories
A List Apart Design Layout Responsibility Responsive Web Design

A List Apart: Responsive Images: How they Almost Worked and What We Need

RESPONSIVE WEB DESIGNERS, don’t miss Mat Marquis’ essential article in today’s A LIST APART, for people who make websites: Responsive Images: How they Almost Worked and What We Need. Mat shows why responsive images as we currently use them don’t quite cut it – and shares a way forward that involves the creation of a shiny new HTML element.

Illustration by Kevin Cornell for A List Apart Magazine.

Categories
Applications apps Responsibility Responsive Web Design State of the Web The Essentials UX Web Design Web Design History Web Standards Websites

State of the web: of apps, devices, and breakpoints

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.

As consumers, we’ve all had the experience of seeing the wrong layout at the wrong time. (Think of a site with both mobile and desktop versions—whether these versions are triggered by CSS3 media queries or JavaScript and back-end magic is beside the point because technology is beside the point—good user experience is all this is supposed to be about. On a Twitter app on a mobile device, the user follows a link; the link opens in the browser built into the Twitter app. Which version of the site does the user see? The mobile one or the desktop? Often it is the desktop, and that can be a problem if the app’s version of the browser does not permit zoom. Even if it is a mobile version, it may be the wrong mobile version, or it may not fit comfortably inside the app’s browser window.) Considering our own experiences and reviewing Rieger’s chart, it is easy to share Drummond’s conclusion that breakpoints are dead and that all sites should be designed as minimally as possible.

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!

Categories
Design industry Platforms Responsibility Standards State of the Web The Essentials

Say No to SOPA!

A LIST APART strongly opposes USHR 3261 AKA the Stop Online Piracy Act (SOPA), an ill-conceived lobbyist-driven piece of legislation that is technically impossible to enforce, cripplingly burdensome to support, and would, without hyperbole, destroy the internet as we know it.

SOPA approaches the problem of content piracy with a broad brush, lights that brush on fire, and soaks the whole web in gasoline. Learn why SOPA must not pass, and find out what you can do to help stop it.

A List Apart: Articles: Say No to SOPA.

Illustration by Kevin Cornell for A List Apart Magazine.

Categories
Code Compatibility Design Responsibility Responsive Web Design Standards State of the Web Usability User Experience UX Web Design Web Design History Web Standards

“Mobile” versus “Small Screen”

As we try to become more responsive with our designs, a lot of attention has been focused on providing “mobile” styles. We’ve all been adding viewport meta tags to our templates and @media screen and (max-device-width: 480px) to our stylesheets.

It’s very tempting (and scope-friendly) to tell a client that we can adjust their site for mobile users, when much of the time what we’re actually doing is simply adjusting a design for small screens.

…Simply adjusting a design for a smaller screen and calling it “mobile” does a disservice to both mobile users and developers. Making link targets bigger and image sizes smaller does help the mobile user, but it only addresses the surface issues of usability and readability. It doesn’t address their need to do things easily and quickly.

via It’s the Little Things – “Mobile” versus “Small Screen”.

Categories
Design Responsibility Responsive Web Design Web Design Web Design History Web Standards

320 and up—a device agnostic stylesheet for responsible responsive design

“320 and Up prevents mobile devices from downloading desktop assets by using a tiny screen’s stylesheet as its starting point. … Inspired by Using Media Queries in the Real World by Peter Gasston, ‘320 and Up’ is a device agnostic, one web boilerplate.”

—320 and up by Malarkey

Categories
"Digital Curation" Advocacy Appearances art direction Authoring Best practices business Community conferences content content strategy Design development editorial Education engagement Ideas Micropublishing Molehill Platforms Publications Publishing Responsibility Standards State of the Web The Essentials The Profession Usability User Experience UX Web Design Zeldman

You are all in publishing!

ON SUNDAY, while leading a discussion on the future of web design and publishing, I noticed a slightly confused look appearing on some faces in the audience. The discussion had been billed as “Jeffrey Zeldman’s Awesome Internet Design Panel,” and I thought perhaps there was a disconnect for some in the audience between “design” and such topics as where content comes from and who pays for it.

So I asked, “Who here is in publishing?”

A few hands were gently raised.

Uh-huh. “And how many of you work on the web?”

Every right hand in the room shot up.

“You are all in publishing,” I explained.

Now, I like a good rounded corner talk as much as the next designer. I’ve given my share of them. Also of line height and measure, color and contrast, how to design things that don’t work in old versions of Internet Explorer, and so on. In the practice of web and interaction design, there will always be a place for craft discussions—for craft is execution, and ideas without execution are songs without music, meaningless.

But right now (and always) there is a need for design to also be about the big strategic issues. And right now, as much as design is wrestling with open vs. proprietary formats and the old challenges of new devices, design is also very much in the service of applications and publishing. Who gets content, who pays for it, how it is distributed (and how evenly), the balance between broadcast and conversation, editor and user—these are the issues of this moment, and it is designers even more than editors who will answer these riddles.

%d bloggers like this: