Categories
Design glamorous The Essentials Usability User Experience UX

Pinterest giveth, and Pinterest taketh away

Jeffrey Zeldman's Pinterest (excerpt)
AS MY design career has taken on more and more strategic and managerial freight, I’ve done less and less hands-on design. This year, I decided to change that. As part of my reimmersion, I found myself reading less, and absorbing visual information more. Enter Pinterest.

I’d played with the app when it first came out—who didn’t?—but it didn’t stick with me the way a handful of apps do. It didn’t become an obsession, and so I gradually forgot about it. That’s just how apps work for me. They’re heroin, or they’re nothing.

But the moment my days began filling with sketching, and coding, and Photoshop comping, the genius of Pinterest, and the addictive high it provides when used obsessively and compulsively, was revealed to me.

In borderline religious ecstasy, I became a Pinterest junkie, compelled to collect and catalog every artist I’ve ever loved—every type designer, illustrator, filmmaker, social absurdity, comic book character, and book designer; every half-forgotten cartoonist; every city or nation I’ve visited.

Using Pinterest not only revived long-dead visual design brain cells, it created new ones. Work-related layouts and color schemes came easier as I spent more and more “downtime” collecting and cataloging half-forgotten styles, genres, and artists—and discovering new ones.

Jeffrey Zeldman's Pinterest (excerpt)

I ? Pinterest

As part of this work—for work it is; call it “research” if you prefer—I spent hours rearranging Boards on my profile for maximum aesthetic effect and rhythm. And more hours choosing and replacing the cover illustration for each Board. (If you don’t use Pinterest, here’s a summary: it lets you pin any image you find on the web, or on your own computer desktop or mobile device, to a virtual whiteboard. Pinterest calls each whiteboard you create a “Board,” and each image you affix to it a “Pin.” Part of the fun comes from sequencing Boards on your profile for aesthetic or educational reasons; choosing the featured image for each Board is likewise important and fun.)

Until a few days ago, you could edit and re-edit the featured image for each Board whether you were using Pinterest on the web (that is, via desktop computer), your phone, or your tablet. Doing these things worked differently on the different devices—choosing the featured image was actually faster and less tedious on iPhone and iPad than it was on the web—but the functionality was available in all three places, because Pinterest recognized that brands exist between devices, and that folks interact with your service on different devices at different times, as they choose.

Likewise, until a few days ago, you could change the order of Boards on your profile via drag and drop whether you were using Pinterest on the web or your tablet. (Likely because of screen space constraints, this functionality was not available on iPhone, where the display of Board content necessarily differs from the more desktop-design-focused method used on the web and on iPad.) Users like me changed the order of Boards to create visual interest, set up ironic contrasts, create visual rhythms up and down the screen, and so on. I’m a designer. I have my ways. These details are important to me—and, I imagine, to many other users, since Pinterest is a drug for visual obsessives.

Jeffrey Zeldman's Pinterest (excerpt)

An unexpected change

Then, a few days ago, Pinterest released an update that removed this functionality from the iPhone and iPad (and, I’m assuming, from Android as well). There was no blog post announcing the change. And no rationale offered for taking away features that mattered a lot to users like me. Pinterest knows these features matter, because Pinterest has our data. That’s the difference between making a digital product folks interact with via the internet, and making, say, a toilet plunger. If I manufacture toilet plungers, I can make assumptions about how folks use my product, but I probably don’t have much real data. If I make an application people use via http, I know everything.

Now, it’s not like people were complaining about the ability to edit their Boards: “We have too much freedom! This software provides too many delightful functions. Please remove two of them. But only from my mobile device.”

No. The features are still there on the website. So Pinterest knows people like these features.

And it’s not like the features are too difficult to put into mobile devices, since they already existed in those mobile devices.

Jeffrey Zeldman's Pinterest (excerpt)

A failure to communicate

You may ask why I’m telling you all this instead of telling it to Pinterest. Good question. The answer is, I tried telling Pinterest, but they don’t provide a forum for it. And that is the biggest problem. A company that makes products people love should have a way to communicate with those people. Not grudgingly offer them a few character-limited form fields on a “survey” page that isn’t even referenced in the site’s navigation.

When the features stopped working on my iPhone and iPad, I assumed something had gone wrong with my apps, so I deleted and reinstalled them. (Remember, there was no announcement; but then why would any company announce that it was taking away loved features for no apparent reason?)

When deleting and reinstalling didn’t help, I sought help and contact pages on Pinterest (and was only able to find them via third-party search engine).

In trying to file a bug report, I ended up in a pleasant (but confusing) conversation with a very nice Pinterest employee who explained that I wasn’t experiencing a bug: the software engineers had made a conscious decision to remove the functions I use every day … and had no intention of restoring them. She wasn’t able to tell me why, or point me to a URL that would offer a rationale, but she did tell me I could use Pinterest’s “Recommend a feature” form to “recommend” that the software engineers put those features back.

Since “Recommend a feature” is hidden from site navigation, the kindly person with whom I was in dialog provided a link where I could type in a few characters requesting that Pinterest restore the “drag Board order” functionality. There wasn’t room in the form fields to explain why I thought the feature should be restored, but at least I was able to make the request. The form asked if I was a Business account user, which I am. I don’t remember when or why I bought the Business tier of service. Maybe for the analytics. Maybe just because, as someone who makes stuff myself, I choose to pay for software so I can support the good people who make it, and do what I can to help their product stick around.

(It’s the same reason I remained a Flickr Pro user even after Yahoo gave the whole world 2GB of photo storage space for free. If everything is free, and nobody pays, services you love tend to go away. Half of web history is great services disappearing in the night after investors were dissatisfied with only reasonable profits.)

I don’t know why my paid status mattered to Pinterest, but I couldn’t help feeling there would be a prejudice in favor of my comment if I checked the box letting them know I was a paying customer. Even though it was information they requested, checking the box made me feel dirty. I also wondered why they were asking me. I mean, don’t they know? I gave them the email address they use for my login. I was logged in. They know my status. Are they just checking to see if I know it, too?

Jeffrey Zeldman's Pinterest (excerpt)

There can only be one (feature request)

But I digress. Because here is the main point. The moment I submitted the tiny, inadequate form requesting the restoration of a recently removed feature, the site set a cookie and sent me a message thanking me for completing the “survey.” It wasn’t a survey, but I guess one task completion message is as good as another.

Then I tried to use the inadequate form to report my second concern—the one about the removal of the ability to choose a featured image for my Board. The way this had always worked on the tablet was far superior to the tedious, painstaking way it works on my desktop. On the tablet, you could scroll through all your images with the flick of a finger, select the image you wanted, and complete the task in a few seconds. On the desktop, you had to click your way through every image on your Board in reverse chronological order. It’s the difference between flicking through a calendar, and clicking backwards from today, to yesterday, to the day before yesterday, and so on. The tablet version was fast, easy, intuitive—you interact directly with your content; you can see all relevant content at a glance. The desktop version is cumbersome and 1999-ish. If I had to pick which platform must lose the functionality I relied on, I would not have chosen the tablet. No customer who used the feature in both places would.

But I wasn’t able to share even a few characters of this thought with Pinterest, because once you submit a “survey” requesting a feature, a steel wall in the guise of a cookie slams down, and you cannot make a second feature suggestion.

Not even the next day. (Which is today. Which I just tried.)

Jeffrey Zeldman's Pinterest (excerpt)

This is a love letter

And that is why, as a hardcore fan and user of Pinterest, a service I love and use compulsively, I am using the public web rather than Pinterest’s somewhat unhelpful help center, to share my request with the brilliant software engineers who create this fabulous product.

And with designers, because these are the mistakes we all make when we create products and content sites. We think we are all about the people who use what we create. But we are probably frustrating the pants off them with our arbitrary design decisions and inadequate customer feedback mechanisms.


Also published on Medium.

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
Advocacy Big Web Show Design peachpit State of the Web The Big Web Show Usability User Experience UX W3C Web Design Web Design History Web Standards

Progressive Enhancement FTW with Aaron Gustafson

Book cover art - Adaptive Web Design: Crafting Rich Experiences With Progressive Enhancement, 2nd EditionLONGTIME developer, lecturer, and web standards evangelist Aaron Gustafson and I discuss the newly published update to Aaron’s best-selling industry classic “love letter to the web,” Adaptive Web Design: Crafting Rich Experiences With Progressive Enhancement, 2nd Edition (New Riders, 2015) in Episode ? 140 of The Big Web Show—everything web that matters.

Topics covered include: Aaron’s superhero origin story as a creator of progressively enhanced websites and applications; “we’re not building things we haven’t built on the web before;” “creating opportunities for people outside your comfort zone;” development in the world of Node.js; “every interface is a conversation;” “visual design is an enhancement;” “interaction is an enhancement;” nerding out over early web terminal interfaces; Microsoft, Opera, and more.

Sponsored by DreamHost, Braintree, and Thankful.

Deal

Save 35% off Aaron Gustafson’s Adaptive Web Design: Crafting Rich Experiences With Progressive Enhancement, 2nd Edition when you enter discount code AARON35 at checkout.

URLS

https://www.aaron-gustafson.com/about/ – About Aaron
http://adaptivewebdesign.info/2nd-edition/ – Adaptive Web Design Second Edition (“95% new material”)
[PDF] – Read the first chapter free (PDF)
http://adaptivewebdesign.info – First Edition, May 2011 (read the entire first edition free)
http://webstandardssherpa.com – Web Standards Sherpa
https://github.com/easy-designs/batch-ua-parser.php – UA Parser Script by Aaron – on Github
https://www.aaron-gustafson.com/notebook/ – Notebook: Aaron’s blog
https://www.aaron-gustafson.com/speaking-engagements/ – Engagements: Aaron’s speaking page, using Quantity Queries
http://alistapart.com/article/quantity-queries-for-css – “Quantity Queries for CSS” by Heydon Pickering in A List Apart
http://alistapart.com/author/agustafson – A List Apart: articles by Aaron Gustafson
http://alistapart.com/article/goingtoprint – Eric Meyer’s “CSS Design: Going to Print” in A List Apart
https://www.whatsapp.com – Whatsapp

Categories
A Book Apart Big Web Show Design mobile Mobile Multi-Device Platforms Standards State of the Web The Big Web Show Touchscreen User Experience UX Web Design Web Design History Web Standards

? 139: Every Time We Touch—Josh Clark, author of “Designing For Touch”

Author Josh Clark on The Big Web ShowTOUCH introduces physicality to designs that were once strictly virtual, and puts forth a new test: How does this design feel in the hand? Josh Clark’s new book, Designing For Touch, guides designers through this new touchscreen frontier, and is the launchpad for today’s Big Web Show conversation.

In a fast-paced, freewheeling conversation, Josh and I discuss why game designers are some of our most talented and inspiring interaction designers; the economy of motion; perceptions of value when viewing objects on touchscreen versus desktop computer; teaching digital designers to think like industrial designers (and vice-versa); long press versus force touch; how and when to make gestures discoverable; and much more.

Sponsored by DreamHost and BrainTree. Big Web Show listeners can save 15% when ordering Designing For Touch at abookapart.com with discount code DFTBIGWEB. Discount valid through the end of January 2016.

URLS

Big Web Show Episode ? 139
Big Medium
Designing For Touch

Categories
Apple bugs Design glamorous OSX software The Essentials This never happens to Gruber User Experience UX

Zen & The Art of iTunes Failure 

REBUILDING iTunes library from scratch over two days got app working again. Fine use of lazy weekend.

Had to sacrifice all custom playlists dating back to 2002, including An Event Apart playlists and delivery room mix from Ava’s birth.

Playlists still exist on old iPod but can’t be copied from it back to iTunes. (All software I’ve tried freezes & fails.)

Playlists still exist as code snippets inside .itl file in old iTunes folder, but numerous trials prove iTunes can’t launch from that folder any more. Thus I can’t temporarily launch from old folder, export playlists, switch back to safe new folder, and import them, thereby saving them.

And iTunes can’t import old .itl files. I Googled. I tried anyway.

13 years of custom playlists. From before, during, and after my marriage. Including one my daughter called “princess music” and danced to when she was three. Gone.

But, really, so what? Over time we lose everything. This loss is nothing. Attachment is futile. Always move forward, until you stop moving.

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
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
Design Google Usability User Experience UX

Material Design: Why the Floating Action Button is bad UX design

I HIGHLIGHTED so many passages in this brief, well-focused design argument, it’s almost embarrassing. Read it (it takes about three minutes), and you’ll wear out your virtual highlighter, too:

Material Design is a design language introduced by Google a year ago, and represents the company’s bold attempt at creating a unified user experience across all devices and platforms. It’s marked with bold colours, a liberal but principled use of shadows to indicate UI layers, and smooth animations that provide a pretty pretty user experience on Android (and some Google apps on iOS).

One thing about Material Design, however, has bugged me ever since it was introduced last year: Floating Action Buttons.

Floating Action Button | Image credit: Google

FABs are circular buttons that float above the UI and are “used for a promoted action,” according to Google. They act as call to action buttons, meant to represent the single action users perform the most on that particular screen.

And because of the bold visual style of Material Design, FABs are strikingly hard to ignore and stand out?—?and herein lies the problem.

While FABs seem to provide good UX in ideal conditions, in actual practice, widespread adoption of FABs might be detrimental to the overall UX of the app. Here are some reasons why.

Material Design: Why the Floating Action Button is bad UX design by Teo Yu Siang

Categories
A List Apart business Career client services content strategy Corporatism creativity Design Designers UX

A List Apart ? 421 Gets Personal

A List Apart Issue No. 421

THERE’S GREAT reading for people who make websites in Issue No. 421 of A List Apart:

Resetting Agency Culture

by Justin Dauer

Forget Air Hockey, Zen Gardens, and sleep pods: a true “dream” company invests in its people—fostering a workplace that supports dialogue, collaboration, and professional development. From onboarding new hires to ongoing engagement, Justin Dauer shares starting points for a healthy office dynamic and confident, happy employees. ?


Crafting a Design Persona

by Meg Dickey-Kurdziolek

Every product has a personality—is yours by design? Meg Dickey-Kurdziolek shows you how Weather Underground solved its personality problems by creating a design persona, and teaches you collaborative methods for starting a personality adjustment in your company. ?


Categories
A List Apart Design UX

A List Apart ? 420: Add Friction to Interactions, Customize With Care

IN ISSUE ? 420 of A List Apart:

Meta-Moments: Thoughtfulness by Design

by ANDREW GRIMES

Does the internet ever stop you in your tracks? Does it sometimes make you pause and think about what you’re doing? Andrew Grimes calls such moments meta-moments. He walks us through why meta-moments are occasionally necessary and how we might build them into the experiences we design. ?


Approaching Content Strategy for Personalized Websites

by COLIN EAGAN

Experience management systems are making it easier than ever to customize content for your visitors—but are you using your newfound personalizing powers for good (or for creepy)? Colin Eagan shows that personalization can be done, thoughtfully, using the same tools you would apply to any content strategy conundrum: by asking why, being deliberate, and putting users first. ?

Categories
A List Apart content Design UX writing

A List Apart ? 419: Narratives & Conversations

IN ISSUE ? 419 of A List Apart:

Do Androids Dream in Free Verse

by JOSCELIN COOPER

From ATMs to Siri to the button text in an application user interface, we “talk” to our tech—and our tech talks back. Often this exchange is purely transactional, but newer technologies have renegotiated this relationship. Joscelin Cooper reflects on how we can design successful human-machine conversations that are neither cloying nor overly mechanical. ??


Building Nonlinear Narratives for the Web

by SENONGO AKPEM

The web operates in ways that can conflict with our traditional view of what a “story” is. Content is chunked, mixed, and spread across channels, devices, and formats. How do we understand story lines, characters, interactions, and the role of the audience, given this information sprawl? Cue nonlinear narratives—Senongo Akpem guides us past basic “scrolly-telling” to immersive, sometimes surprising experiences. ?

Categories
Design Usability User Experience UX

Designer Blindness

AFTER USING the web for twenty years, and software for an additional ten, I’ve come to believe that I suffer from an affliction which I will hereby call “designer blindness.”

Put simply, if an interface is poorly designed, I will not see the data I looked for, even if it is right there on the page.

On a poorly designed table, I don’t find the column containing the answer I sought.

On a poorly designed interface, I don’t push the right buttons.

On a poorly designed social sharing site, I delete my data when I mean to save it, because the Delete button is in the place most designers put a Save button.

This doesn’t happen to everyone, which is why I call it an affliction. Indeed, it happens to almost no one.

My non-designer friends and family seem quite capable of using appallingly designed (and even undesigned) sites and applications. Somehow they just muddle through without pushing the button that erases their work.

In fact, the less concerned with aesthetics and usability these friends and family members are, the more easily they navigate sites and applications I can’t make head nor hair of.

Like the ex-girlfriend who mastered Ebay.

Or the colleagues who practically live in Microsoft Excel, an application I still cannot use. There are tabs on the bottom, way below the fold, way past where the data stops? And I’m supposed to scroll a blank page until I find those tabs? It’s easy for most people, but it never occurs to me no matter how often I open an Excel document. I could open a thousand Excel documents and still never think to scroll past a wall of empty rows to see if, hidden beneath them, there is a tab I need to click. Just doesn’t occur to me. Because, design.

It’s not a visual or mathematical disability. If something is well designed, I can generally use it immediately. It’s the logic of design that trips me up.

I recognize that I’m an edge case—although I bet I’m not the only designer who feels this way. Give me something that is well designed, and I will master it, teach others about it, and unconsciously steal my next five original ideas from it. Give me something poorly designed, something that works for most people, and I’ll drive a tank into an orphanage.

Not that I’m a great designer. I wouldn’t even call myself a good designer. I’m just good enough to get messed up by bad design.

Yet you won’t hear me complain about my designer blindness.

See, divorce is a terrible thing, but if you have a kid, it’s all worth it. The heartache, the anger, the loss of income and self-esteem, the feeling that no matter what you say or do, you are going to be someone else’s monster forever—all the unbearable burdens of failed love and a broken family are worth it if, before that love failed, it brought a wonderful child to this world.

For my daughter I would suffer through a thousand divorces, a million uncomfortable phone calls, a trillion emotionally fraught text messages.

And how I feel about my kid is how I also feel about my design affliction. The pain of being unable to use what works for other folks is more than compensated for by the joy of recognizing great design when I see it—and the pleasure of striving to emulate that greatness, no matter how badly I fail every time.

Categories
Usability User Experience UX

Broken All the Way Down: Seeking Basic Information from Southwest Airlines

I was taking my daughter to Laguardia Airport to meet her mom, who would then take the girl on to Chicago for a few days’ holiday-time visit. Laguardia is a large airport, with many terminals, and as I hadn’t bought the ticket and wasn’t flying, I didn’t know which of the many terminals to go to.

So the day before my daughter’s trip, I visited Southwest’s website and punched in the flight number. It is a recurring flight from New York to Chicago that takes place every weekday at the same time. The website told me that the flight had left for the day. It couldn’t tell me the terminal of departure or anything else.

Next I punched in the confirmation code for my daughter’s flight. Her mother had already checked her in, and sent me a digital copy of the boarding pass, which I needed to get through airport Security, and which also didn’t have a terminal or gate number—not surprisingly, since, even for a recurring flight, gates aren’t typically assigned until a few hours before the flight departs. I didn’t expect a gate, but a terminal would be nice. When I punched in my daughter’s confirmation code, there was still no sign of a terminal.

So I scoured the entire Southwest website. No mention of terminals anywhere.

I then used both Google and Duck Duck Go to run every query I could think of that might tell me which terminal or terminals Southwest departs from at Laguardia. Neither search engine was able to return anything of the slightest use.

I began to think that Southwest might have a problem with its markup, and its content strategy, and with any additional findability voodoo that usually gets called “SEO.”

Even maps of Laguardia and maps of airlines at Laguardia and records of flights from New York to Chicago and other Giles-like aracana I eventually thought of were unable to produce a tiddle of information about which terminal at Laguardia plays home to all or even some of Southwest’s flights.

When all else fails, call the company.

As you might expect by now, it took work to find Southwest’s phone number on its website, and when I did find it, it was one of those 20th Century mnemonic numbers that are hard to use and rather meaningless in the age of smartphones: 1-800-I-FLY-SWA.

You will not be surprised to learn that I sat through a long, unskippable audio menu full of slow-talking sales puffery before I was offered the chance to say “agent” and speak to an agent (which I needed to do since none of the menu options led to the information I wanted). After I said “agent,” the robotic voice told me, “Okay, I will connect you to an agent,” and hung up on me.

I went through this three times to make sure I wasn’t going mad and there was in fact no chance of reaching an agent.

To summarize so far: basic information not on company website or, apparently, anywhere on the web. Hard-to-use phone number did not provide info in its menu, and hung up every time it promised to connect me to an actual human agent.

So I used the contact form on the company’s website to ask my question (requesting an answer the same day if possible), and to report the usability problem on the company’s phone system, wherein if a human asks to speak to an agent, the system agrees to provide an agent and then hangs up on the customer.

Today—the day after my daughter’s flight—I received via email a form letter from Southwest apologizing for not getting me the information in time (and still not giving me the information), and advising me to solve my own problems in the future by using Southwest’s super-useful toll-free number for concerns that require immediate assistance.

I guess the person who sent the form letter hadn’t read the second sentence of my two-sentence request for help, where I mentioned that the toll-free number was broken.

Here, in its entirety, is Southwest’s response:

Dear Jeffrey,

Thank you for your email. We certainly wish we had been able to touch base with you prior to your travel. We realize how important it is to respond to our Customers’ concerns in a timely manner, and we regret disappointing you in this regard. For future reference, you may contact our toll-free number, 1-800-I-FLY-SWA, for concerns that require immediate assistance.

We appreciate your patronage and hope to see you onboard a Southwest flight soon.

Sincerely,
Wanda, Southwest Airlines

The file reference number for your e-mail is 255648215756.

You can’t make stuff like this up. The last sentence is my personal favorite. There’s nothing like a file reference number to cheer you up after experiencing failure at every customer experience point you touched.

In the end, because my kid’s mom had shared the flight details, Tripit texted me the terminal information hours before I needed it. Terminal B, which is about two-thirds the size its needs to be for the amount of traffic it handles, was predictably mobbed with holiday travelers. There was not a free seat in the house.

Business is booming.

Categories
Design software State of the Web The Essentials The Profession Usability User Experience UX Web Design Web Design History Web Standards

The Lords of Vendorbation

Vendorbation
ven·dor·ba·tion
/?vend?r-?b?-sh?n/

noun : Unusable web-based intranet software foisted on large populations of users who have no say in the matter. For example, the “dynamic” website for your kid’s school, on which you can never find anything remotely useful—like her classroom or the names and email addresses of her teachers. Merely setting up an account can be a Borgesian ordeal minus the aesthetics.

Tried updating a driver’s license, registering a name change after a marriage, or accomplishing pretty much any task on a local, state, or federal website? Congratulations! You’ve been vendorbated. In ad sales? In publishing? Travel agent? Work in retail? Y’all get vendorbated a hundred times a day. Corporate America runs, not very well, on a diet of dysfunctional intranets sold by the lords of vendorbation.

Terrible food kills a restaurant. Terrible music ends a band’s career. But unspeakably terrible software begets imperial monopolies.

Wholesale contractual vendor lock-in between vendors of artless (but artfully initially priced) web software and the technologically unknowing who are their prey (for instance, your local school board) creates a mafia of mediocrity. Good designers and developers cannot penetrate this de-meritocracy. While they sweat to squeeze through needle’s eye after needle’s eye of baffling paperwork and absurd requirements, the vendorbators, who excel at precisely that paperwork and those requirements, breeze on in and lock ‘er down.

Vendorbation takes no heed of a user’s mental model; indeed, the very concept of a user’s mental model (or user’s needs) never enters the minds of those who create vendorbatory software. I say “create” rather than “design,” because design has less than nothing to do with how this genre of software gets slapped together (“developed”) and bloated over time (“updated”).

Vendorbatory product “design” decisions stem purely from contingencies and conveniences in the code framework, which itself is almost always an undocumented archipelago of spaghetti, spit, and duct tape started by one team and continued by others, with no guiding principle other than to “get it done” by an arbitrary deadline, such as the start of a new school year or the business cycle’s next quarter.

Masturbation, or so I have read, can be fun. Not so, vendorbation. It is a nightmare for everyone—from the beleaguered underpaid lumpen developers who toil in high-pressure silos; to the hapless bureaucrats who deserve partners but get predators instead; from the end users (parents, in our example) who can never do what they came to do or find what they want, and who most often feel stupid and blame themselves; to the constituents those users wish to serve—in our example, the children. Will no one think of the children?

Cha-ching! Like a zombie-driven un-merry-go-round spinning faster and faster as the innocents strapped to its hideous horses shriek silently, the vendorbation cycle rolls on and on, season after bloody season, dollar after undeserved dollar, error after error after error after error in saecula saeculorum.

Think it’s bad now? Wait till the lords of vendorbation start making their monstrosities “mobile.”


Doff of the neologist’s toque to Eric A. Meyer, whose cornpensation helped crystalize what to do with the bad feelings.