Category: Standards

Web standards for design and communication.

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
Advertising Amazon Apple Best practices Content-First Standards State of the Web

Ad Blocking and the Future of the Web

YOUR site may soon be collateral damage in a war between Silicon Valley superpowers. By including ad blocking in iOS9, Apple isn’t trying to take down your site or mine—just like the drone program doesn’t deliberately target civilians and children. Apple is trying to hurt arch-rival Google while providing a more elegant (i.e. more Apple-like) web experience than user-hostile ad networks have previously allowed. This is a great example of acting in your own self-interest, yet smelling like a rose. Will independent sites that depend on advertising be hurt along with Google?

We have always been at war with Eastasia

We should be used to this war between digital super companies by now. iPhone and iPad users, consider your Amazon experience on the platform. Notice how you can’t buy books in your Kindle app in iOS? Apple supports Amazon to the extent of letting Amazon distribute Kindle software on the iOS platform. But if you want to buy a Kindle book for your phone, you have to go to a desktop browser (or open Safari on your phone and navigate to Amazon.com). Kind of encourages you to get your digital books in iBooks instead.

Same with Amazon’s video app on iOS. You can stream all the movies you want on your phone or iPad, but you can’t buy them in the Amazon Video app. You must use a desktop browser or navigate to amazon.com in the version of Safari that comes with iOS. Kind of encourages you to buy videos from iTunes instead.

You also can’t buy Kindle books or streaming Amazon videos in the Amazon shopping app for iOS, although you can use that app to shop for anything else.

See, Amazon doesn’t want to give Apple a cut of its media sales, so Apple won’t let Amazon sell products in its apps. In Apple’s reasoning, all other vendors pay Apple a cut; Amazon shouldn’t get a pass. And Amazon is serious about not sharing revenue, because Amazon is a ruthless competitor that has taken over nearly all online retail sales in the U.S. by innovating service and delivery, and giving consumers the lowest possible price—a price that leaves them no margin to share with Apple. It’s also a price that strangles the companies that provide the goods Amazon sells. Oh, well.

Because Amazon is serious about not sharing sales revenue with Apple, and Apple is serious about blocking sales by any vendor that refuses to share revenue, Apple denies Amazon the right to sell products via its iOS apps. Who suffers? You, the consumer, as you put down your phone and toddle over to a desktop—or just shrug and do without. (Not that it’s the worst suffering in this world. But it is anti-consumer, and makes both Amazon and Apple look bad.)

And, of course, you can’t stream Amazon video on your Apple TV, and likewise can’t watch video content you’ve purchased through Apple iTunes on Amazon Fire TV without jumping through (possibly illegal) hoops. Not since Microsoft dominated the desktop software world in the 1990s have tech and media companies viewed success as a last-man-standing affair, with the consumer as collateral damage.

Still, we’re used to all this and don’t think about it.

Ad blocking is a different beast.

Certainly, at first, ad blocking seems like a different beast. After all, consumers may want to buy books in their Kindle app, but no consumer is clamoring for more ads. And media and advertising have only themselves to blame for the horrendous experience online advertising has become. We hate advertising so much, we’ve trained ourselves not to look at the top or right sidebar on most sites. In fact, it’s become a designer’s trick that if the client forces you to put the CEO’s pet link on the home page, you hide it in plain sight at the top of the sidebar, where no one but the CEO will see it. Popups and screen takeovers and every other kind of anti-user nightmare have made advertising a hated and largely ignored thing on the web.

There are tasteful ad networks, to be sure. The Deck, which Jim Coudal created with Jason Fried and me, serves one single, small, tasteful, well targeted ad per page. When we launched The Deck, I hoped other networks would take inspiration from it, and figure out how to increase engagement while minimizing clutter. I even tried to sell my studio’s media clients on the notion of fewer, better priced, better targeted ads. But of course the ad networks have done the opposite—constantly interrupting content to force misleading, low-interest ads on you.

Hip web consumers have long used third-party ad blockers to unfug the web experience, and great applications like Readability explored alternate content revenue models while boosting type size and removing ad clutter from web content. I served on the Readability advisory board. And I used to go around the world warning designers that if we didn’t figure out a way to create readable, clutter-free layouts for our clients’ sites, apps like Readability would do it for us—putting us out of work, and removing advertising as a revenue stream for media companies. As it happens, in the intervening years, many smart sites have found a way to put content first and emphasize not just legibility but readability in their layouts. The best of those sites—I’m thinking of The New York Times here—have found a way to integrate advertising tastefully in those large-type, content-focused, readability-oriented modern layouts. (Medium.com, of course, does an amazing job with big type and readability, but it doesn’t need to integrate advertising—at least not yet—as it floats on a sea of VC bucks.)

But advertisers don’t want to be ignored, and they are drunk on our data, which is what Google and other large networks are really selling. The ads are almost a by-product; what companies really want to know is what antiperspirant a woman of 25-34 is most likely to purchase after watching House of Cards. Which gets us into issues of privacy and spying and government intrusion and don’t ask.

And in this environment of sites so cluttered with misleading ads they are almost unnavigable, Apple looks heroic, riding to the consumer’s rescue by providing all the content from newspapers without the ads, and by blocking ugly advertising on websites. But if they succeed, will media companies and independent sites survive?

Consumer good vs. consumer good

What Apple’s doing wouldn’t matter as much if consumers were still sitting down at a desktop to get their news and cat gifs. But they’re not. Everyone does everything on mobile. Including browse the web.

Thus in The Verge today, Nilay Patel argues there’s a real risk that, in attacking Google’s revenue stream, Apple may hurt the web itself:

The collateral damage of that war — of Apple going after Google’s revenue platform — is going to include the web, and in particular any small publisher on the web that can’t invest in proprietary platform distribution, native advertising, and the type of media wining-and-dining it takes to secure favorable distribution deals on proprietary platforms. It is going to be a bloodbath of independent media. … Taking money and attention away from the web means that the pace of web innovation will slow to a crawl. —Welcome to hell: Apple vs. Google vs. Facebook and the slow death of the web

John Gruber thinks otherwise, at least for small indie sites like his:

Perhaps I am being smug. But I see the fact that Daring Fireball’s revenue streams should remain unaffected by Safari content-blocking as affirmation that my choices over the last decade have been correct: that I should put my readers’ interests first, and only publish the sort of ads and sponsorships that I myself would want to be served, even if that means leaving (significant) amounts of money on the table along the way. But I take no joy in the fact that a terrific publication like The Awl might be facing hard times. They’re smart; they will adapt.—Because of Apple

In Publishing Versus Performance, I looked at the conflict between advertising and content through the filter of performance. For those who didn’t read it (or don’t remember), I pointed out that most consumer interaction with the web happens on mobile, which means it happens on mobile networks, which, at times at least, may be severely bandwidth-constrained; so performance counts as it hasn’t in years. And while good designers and developers are working like never before to create performant websites, the junk ad networks spew interferes with their good work and slows websites to a crawl. This threatens the future of the web, as consumers will blame the web for poor performance, and stick to apps. But removing those ad networks isn’t an option, I pointed out, since, abhorrent or not, advertising dollars are the engine that drives digital media: no bucks, no content.

Well, now, Apple has decided for us. Removing those ad networks may not be an option, but it’s happening anyway. How will it affect your site?

Also published in Medium.com.

Categories
Bandwidth Best practices Design Designers development DOM Ethan Marcotte HTML industry Markup Medium Off My Lawn! people Performance Responsive Web Design Standards State of the Web Tech The Essentials The Profession Usability UX Web Design Web Design History Web Standards XHTML

You’re welcome: cutting the mustard then and now.

EVERY TIME I hear a young web developer cite the BBC’s forward-thinking practice of “cutting the mustard,” by which they mean testing a receiving web device for certain capabilities before serving content, I remember when my team and I at The Web Standards Project invented that very idea. It’s a million web years ago, by which I mean fourteenish human years ago, so nobody remembers but me and some other long toothed grayhairs, plus a few readers of the first edition of Designing With Web Standards. But I like you, so I will tell you the story.

Back then in those dark times, it was common practice for web developers to create four or more versions of the same website—one for each browser then in wide use. It was also a typical (and complementary) practice to send server-side queries to figure out which browser was about to access a site’s content, and then send the person using that browser to the site version that was configured for her browser’s particular quirks, proprietary tags, and standards compliance failings.

The practice was called “browser detection.” Nobody but some accessibility advocates had ever questioned it—and the go-go dot-com era had no time or care for those folks.

But we at The Web Standards Project turned everything on its head. We said browsers should support the same standards instead of competing to invent new tags and scripting languages. We said designers, developers, and content folks should create one site that was accessible to everyone. In a world like that, you wouldn’t need browser detection, because every browser and device that could read HTML would be able to feast on the meat of your site. (And you’d have more meat to share, because you’d spend your time creating content instead of crafting multiple versions of the same site.)

To hasten that world’s arrival, in 2001 we launched a browser upgrade campaign. Those who participated (example participant here) employed our code and content to send their users the message that relatively standards-compliant browsers were available for every platform, and inviting them to try one. Because if more people used relatively standards-compliant browsers, then we could urge more designers and developers to create their sites with standards (instead of quirks). And as more designers and developers did that, they’d bump against still-unsolved standards compliance conundrums, enabling us to persuade browser makers to improve their standards compliance in those specific areas. Bit by bit, stone by stone, this edifice we could, and would, erect.

The code core of the 2001 browser upgrade campaign was the first instance of capability detection in place of browser detection. Here’s how it worked. After creating a valid web page, you’d insert this script in the head of your document or somewhere in your global JavaScript file:

if (!document.getElementById) {
window.location =
"http://www.webstandards.org/upgrade/"
}

We even provided details for various flavors of markup. In HTML 4 or XHTML 1 Transitional documents, it looked like this:

<script type="text/javascript" language="javascript">
<!-- //
if (!document.getElementById) {
window.location =
"http://www.webstandards.org/upgrade/"
}
// -->
</script>

In STRICT documents, you’d either use a global .js file, or insert this:

<script type="text/javascript">
<!-- //
if (!document.getElementById) {
window.location =
"http://www.webstandards.org/upgrade/"
}
// -->

You could also just as easily send visitors to an upgrade page on your own site:

if (!document.getElementById) {
window.location =
"http://www.yourdomain.com/yourpage.html"
}

Non-WaSP members (at the time) J. David Eisenberg, Tantek Çelik, and Jim Heid contributed technical advice and moral support to the effort. WaSP sysadmin Steven Champeon, the inventor of progressive enhancement, made it all work—under protest, bless him. (Steve correctly believed that all web content should always be available to all people and devices; therefore, in principle, he disliked the upgrade campaign, even though its double purpose was to hasten the arrival of truly standards-compliant browsers and to change front-end design and development from a disrespected world of hacks to a sustainable and professional craft. ((See what I did there? I’m still respectfully arguing with Steve in my head.)))

Discovering rudimentary DOM awareness or its absence in this fashion was the first time web developers had tested for capabilities instead of chasing the dragon in a perpetual and futile attempt to test for every possible browser flavor and version number. It was the grandparent, if you will, of today’s “cutting the mustard.” And it is analogous as well to the sensible responsive design practice of setting breakpoints for the content, instead of trying to set appropriate breakpoints for every possible device out there (including all the ones that haven’t been invented yet).

Which reminds us that the whole point of web standards was and is forward compatibility—to create content that will work not only in yesterday’s and today’s browsers and devices, but in all the wonderful devices that have yet to be invented, and for all the people of the world. You’re welcome.

—CHICAGO, Westin Chicago River Hotel, 1 September 2015

Hat tip: John Morrison

Categories
Design Networks Standards Tech

“You’re Now Free to Complain About the Wi-Fi”

You’re Now Free to Complain About the Wi-Fi on airlines.

LOUIS C.K.’s 2008 viral rant on Conan O’Brien be damned. Seven years later, in-flight Wi-Fi is still maddeningly slow, expensive, and unreliable.

Bloomberg: Why Gogo’s Infuriatingly Expensive, Slow Internet Still Owns the Skies

Categories
An Event Apart Standards State of the Web The Profession Web Design Web Standards Websites

Web Design Essentials: Resilience

Jeremy Keith at An Event Apart

RESILIENCE: BUILDING a Robust Web That Lasts by Jeremy Keith. One of twelve hours of essential content at An Event Apart Austin 2015. But if you plan to attend, grab your ticket now. Early bird discount pricing ends Monday, August 10.

An Event Apart Austin 2015

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
Big Web Show CSS CSS3 Layout Standards State of the Web The Big Web Show Web Design Web Design History Web Standards

Big Web Show ? 132: Modern Layouts with Jen Simmons

Jen Simmons

THE BIG WEB SHOW is back from its break. My guest this week is Jen Simmons (@jensimmons) of The Web Ahead. We discuss moving beyond cookie-cutter layouts on the web; the ins and outs of podcasting; tradeoffs when designing a website; learning from your users; Jen’s journey from theater to technology; and more. Sponsored by Dreamhost. Enjoy The Big Web Show ? 132. ?

URLS

http://thewebahead.net/81 (great links in the show notes!)
https://twitter.com/jensimmons
http://labs.thewebahead.net/thelayoutsahead/
https://github.com/jensimmons/thelayoutsahead
http://alistapart.com/article/css-shapes-101
https://css-tricks.com/examples/ShapesOfCSS/
http://sarasoueidan.com/blog/css-shapes/index.html
http://thewebahead.net/80
http://www.w3.org/TR/css3-grid-layout/
http://thewebahead.net/49
http://next.zengrids.com
http://www.jensimmons.com/about/
http://www.pagetutor.com/common/bgcolors216.html

Categories
Design glamorous Medium Molehill nytimes Platforms Publications Publishing Standards State of the Web The Essentials The Profession writing zeldman.com

Who’s Afraid of the Big Bad Medium?

IN 2003, long before he was a creative director at Twitter, Douglas Bowman wrote articles about design, posted case studies about his design projects, and shared his photography on his personal/business site, stopdesign.com.

A year previously, Doug had attained instant fame in standardista circles by recoding Wired.com using CSS for layout. That sounds nonsensical nowadays, but in 2002, folks like me were still struggling to persuade our fellow web designers to use CSS, and not HTML tables, for layout. Leading web designers had begun seeing the light, and there had been a sudden profusion of blogs and personal sites that used CSS for layout, and whose markup strove to be semantic and to validate. But nobody had as yet applied web standards to a large commercial site—giving rise to the charge, among Luddite web designers, that standards-based design was “okay for blogs” but had no business on the “real” web.

Then Doug recoded Wired.com with CSS, Mike Davidson did the same for ESPN.com, and all the old reactionary talking points were suddenly as dead as Generalissimo Franco—and the race was on to build a standards-compliant, open web across all content and application sectors.

IN THE PROCESS of helping to lead this sea change, Douglas Bowman became famous, and anybody who was anybody in web design began passionately reading his blog. And yet.

And yet, when Doug had a really big idea to share with our community, he published it on A List Apart, the magazine “for people who make websites.”

Did he do so because blogging was dead? Because the open web was in trouble? Of course not. He did it because publishing on A List Apart in 2003 allowed Doug to share his innovative design technique with the widest possible audience of his peers.

PUBLISHING in multiple venues is not new. Charles Dickens, the literary colossus of Victorian England, did it. (He also pioneered serial cross-cutting, the serial narrative, and the incorporation of audience feedback into his narrative—techniques that anticipated the suspense film, serial television narratives like Mad Men, and the modification of TV content in response to viewer feedback over the internet. But those are other, possibly more interesting, stories.)

Nobody said the open web was dead when Doug Bowman published “Sliding Doors of CSS” on A List Apart.

Nobody said the blog was dead when RSS readers made it easier to check the latest content from your favorite self-publishing authors without bothering to type their personal sites’ URLs into your browser’s address bar.

Forward thinkers at The New York Times did not complain when Mike Davidson’s Newsvine began republishing New York Times content; the paper brokered the deal. They were afraid to add comments to their articles on their own turf, and saw Newsvine as a perfect place to test how live reader feedback could fit into a New York Times world.

When Cameron Koczon noticed and named the new way we interact with online content (“a future in which content is no longer entrenched in websites, but floats in orbit around users”), smart writers, publishers, and content producers rejoiced at the idea of their words reaching more people more ways. Sure, it meant rethinking monetization; but content monetization on the web was mostly a broken race to the bottom, anyway, so who mourned the hastening demise of the “web user manually visits your site’s front page daily in hopes of finding new content” model? Not many of us.

By the time Cameron wrote “Orbital Content” in April of 2011, almost all visits to A List Apart and zeldman.com were triggered by tweets and other third-party posts. Folks were bookmarking Google and Twitter, not yourhomepage.com. And that was just fine. If you wrote good content and structured it correctly, people would find it. Instead of navigating a front-page menu hierarchy that was obsolete before you finished installing the templates, folks in search of exactly your content would go directly to that content. And it was good.

So just why are we afraid of Medium? Aside from not soliciting or editing most of its content, and not paying most of its authors, how does it differ from all previous web publications, from Slate to The Verge? Why does publishing content on Medium (in addition to your personal site and other publications) herald, not just the final-final-final death of blogging (“Death of Blogging III: This Time It’s Personal”), but, even more alarmingly, the death of the open web?

You may think I exaggerate, but I’ve heard more than one respected colleague opine that publishing in Medium invalidates everything we independent content producers care about and represent; that it destroys all our good works with but one stroke of the Enter button.

I’ve even had that thought myself.

But isn’t the arrival of a new-model web publication like Medium proof that the web is alive and healthy, and spawning new forms of creativity and success?

And when the publisher of a personal site writes for Medium, is she really giving up on her own site? Couldn’t she be simply hoping to reach new readers?

(If she succeeds, some of those new readers might even visit her site, occasionally.)

Thanks to Bastian Allgeier for inspiring this post.

This piece was also published on Medium.

This article has been translated into Chinese.

Categories
Big Web Show Design Education Standards State of the Web The Big Web Show Web Design Web Design History Web Standards

Progressive Enhancement FTW with Aaron Gustafson

IN EPISODE ? 130 of The Big Web Show (“Everything Web That Matters”), I interview long-time web standards evangelist Aaron Gustafson, author of Adaptive Web Design, on web design then and now; why Flipboard’s 60fps web launch is anti-web and anti-user; design versus art; and the 2nd Edition of Aaron’s book, coming from New Riders this year.

Enjoy Episode ? 130 of The Big Web Show.

Show Links

A Bit About Aaron Gustafson
Adaptive Web Design: Crafting Rich Experiences with Progressive Enhancement
Responsive Issues Community Group
Easy Designs – Web Design, Development & Consulting
Web Standards Sherpa
Code & Creativity
WebStandardsProject (@wasp) | Twitter
A List Apart: For People Who Make Websites
Genesis – Land Of Confusion [Official Music Video] – YouTube

Categories
Big Web Show ethics Standards State of the Web The Big Web Show W3C Web Standards

Big Web Show ? 109: Bring Me The Head of Tim Berners-Lee

2aa4b628a29d2b8c1f2b7742a6d8dcb0

IN BIG WEB SHOW ? 109, Robin Berjon and I enjoy a calm, rational conversation about EME, DRM, the MPAA, and the W3C. Enjoy.

The episode was sponsored by Squarespace. Links mentioned:

Categories
Standards State of the Web Web Design Web Design History Web Standards

It’s 2014. Is Web Design Dead?

IN A RECENT article on his website, Web Standards Killed the HTML Star, designer Jeff Croft laments the passing of the “HTML and CSS ‘guru’” as a viable long-term professional position and urges his fellow web design generalists to “diversify or die.”

The reason the Web Standards Movement mattered was that the browsers sucked. The stated goal of the Movement was to get browser makers on board with web standards such that all of our jobs as developers would be easier.

What we may not have realized is that once the browsers don’t suck, being an HTML and CSS “guru” isn’t really a very marketable skillset. 80% of what made us useful was the way we knew all the quirks and intracries of the browsers. Guess what? Those are all gone. And if they’re not, they will be in the very near future. Then what?

From my perspective, the web standards struggle consisted of two phases of persuasion: first we convinced browser makers that it was in their interest to support current HTML, CSS, and JavaScript specifications completely and accurately; then we evangelized the accessibility, findability, and portability benefits of lean semantic markup and progressive enhancement to our colleagues who made websites and their clients.

Evangelizing true compliance, not mastering workarounds for compliance failures, was always the point. Evangelizing was key. Browsers weren’t going to stay standards compliant if nobody made use of that compliance; likewise, W3C specifications weren’t going to advance unless designers seized hold of technologies like CSS to push type and layout on the web as far as they could go—and then complain that they didn’t go far enough.

It took a village of passionate browser engineers, designers, front-end developers, and generalists to bring us to the web we have today. Does the movement’s success mean that many of those who led it will become jobless, like Bolsheviks after the Russian Revolution?

Jeff Croft is correct when he says “the goal of the Web Standards Movement was for it to not have to exist.” But we should take this a step further. The goal of the web standards movement was to remove needless complexity and absurdity from the process of creating websites so we could focus our attention where it should be: on design, content, and experience. Evangelizing standards to browser makers and our fellow designers was not a career path, and was never intended to be—any more than aiding a wounded buddy turns a soldier into a physician.

Interestingly, once web standards made the web safe for design, content, and experience, the web’s capabilities—and, thus, the work required to create certain kinds of websites—started becoming more and more complex. To help cut down on that complexity, some front-end developers began sharing chunks of code (from Eric Meyer’s CSS Reset to Mark Otto’s Bootstrap) which paradoxically set in motion another level of complexity: as Jeff Croft points out, familiarity with these and dozens of other tools is now expected of job applicants who could once get hired on nothing more than a solid understanding of HTML and CSS plus a little JavaScript.

HTML “gurudom” was never a career path for anyone, aside, maybe, from a couple of talented authors. Same thing with CSS trickery. Doing black magic with CSS3 can get you a slot on a web design conference stage, but it’s not a career path or proper goal for most web designers.

Fascinatingly, to me, anyway, while many of us prefer to concentrate on design, content, and experience, it continues to be necessary to remind our work comrades (or inform younguns) about web standards, accessibility, and progressive enhancement. When a site like Facebook stops functioning when a script forgets to load, that is a failure of education and understanding on the part of those who created the site; all of us have a stake in reaching out to our fellow developers to make sure that, in addition to the new fancy tricks they’ve mastered, they also learn the basics of web standards, without which our whole shared system implodes.

This doesn’t mean “go be an HTML guru.” It does mean cherish the lessons of the recent past, and share them with those who missed them (or missed the point). Wisdom is not a job, but it is always an asset.

Never fear, web design generalists: many companies and organizations require your services and always will—from universities still seeking “webmasters,” to startups seeking seasoned folks with multiple areas of understanding to direct and coordinate the activities of younger specialists. But if jack-of-all web work is feeling stale, now may be the time to up your game as a graphic designer, or experience designer, or front end developer. “Diversify or die” may be overstating things a bit. But “follow the path you love” will always be good advice.

Categories
An Event Apart architecture Best practices Chicago cities Code creativity Design Designers glamorous IXD mobile Mobile Multi-Device Standards State of the Web Usability User Experience UX Web Design Web Standards Working Zeldman

Chicago, Chicago

An Event Apart Chicago—a photo set on Flickr. Photos of the city and the conference for people who make websites.

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.

THE NEXT AEA event takes place in Austin and is already sold out (although a few spaces are still available for the full-day workshop on multi-device design).

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.

Categories
Big Web Show CSS CSS3 Designers development Education eric meyer HTML podcasts Standards State of the Web

Big Web Show 79: Eric Meyer

Eric Meyer

IN EPISODE No. 79 of The Big Web Show (“everything web that matters”), I interview CSS guru, Microformats co-founder, O’Reilly and New Riders author, and An Event Apart co-founder Eric A. Meyer (@meyerweb) about upcoming CSS modules including grid layout, flexbox, and regions; his career trajectory from college graduate webmaster to world-renowned author, consultant, and lecturer; founding and running a virtual community (CSS-Discuss); becoming an O’Reilly writer; the early days of the Mosaic Browser and The Web Standards Project’s CSS Samurai; “The Web Behind” variation of The Web Ahead podcast, and more.

Listen to the episode.

About Eric

Eric A. Meyer has been working with the web since late 1993 and is an internationally recognized expert on the subjects of HTML and CSS. He is the principal consultant for Complex Spiral Consulting and lives in Cleveland, Ohio, which is a much nicer city than you’ve been led to believe. Author of “Eric Meyer on CSS” (New Riders), “Cascading Style Sheets: The Definitive Guide” (O’Reilly & Associates), “CSS2.0 Programmer’s Reference” (Osborne/McGraw-Hill), and the CSS Browser Compatibility Charts, Eric co-founded and co-directs An Event Apart, the design conference “for people who make websites,” and speaks at a variety of conferences on the subject of standards, CSS use, and web design.

URLs

Photo: Chris Jennings

Categories
A List Apart Accessibility Apple Layout mobile Standards State of the Web Web Design Web Design History Web Standards

A List Apart Issue No. 367: Apple’s Vexing Viewport

In A List Apart Issue No. 367, Peter-Paul Koch, Lyza Danger Gardner, Luke Wroblewski, and Stephanie Rieger explain why Apple’s new iPad Mini creates a vexing situation for designers and developers who create flexible, multi-device experiences.

Each week, new devices appear with varying screen sizes, pixel densities, input types, and more. As developers and designers, we agree to use standards to mark up, style, and program what we create. Browser makers in turn agree to support those standards and set defaults appropriately, so we can hold up our end of the deal. This agreement has never been more important.

That’s why it hurts when a device or browser maker does something that goes against our agreement—especially when they’re a visible and trusted friend of the web like Apple. Read Vexing Viewports and contribute to the discussion.

This issue of the magazine also marks the departure of Jason Santa Maria as creative director after seven years of brilliant design and support.

Jason’s elegant redesign of A List Apart and its brand in 2005, together with the master stroke of bringing in Kevin Cornell as illustrator, brought the magazine new fame, new readers, and new respect. Over seven great years, his attention to detail, lack of pretension, and cheerful, can-do attitude has made working on ALA a pleasure. Jason was also a key member of the strategic team that envisioned ALA’s upcoming content expansion—about which, more will be revealed when the site relaunches in January.

Jason will continue at ALA as a contributing writer and as designer of A Book Apart (“brief books for people who make websites”), of which he is also a co-founder.

Categories
business businessweek client management client services clients content Content First CSS3 Curation Dan Benjamin Design E-Books Ethan Marcotte findability Google Happy Cog™ HTML HTML5 Jeremy Keith Microsoft podcasts Publishing Real type on the web Redesigns Responsive Web Design Standards State of the Web The Big Web Show Usability User Experience UX Web Design Web Design History Web Standards Zeldman

Leo Laporte interviews JZ

IN EPISODE 63 of Triangulation, Leo Laporte, a gracious and knowledgeable podcaster/broadcaster straight outta Petaluma, CA, interviews Your Humble Narrator about web standards history, responsive web design, content first, the state of standards in a multi-device world, and why communists sometimes make lousy band managers.

%d bloggers like this: