My Glamorous Life: Crossing the Continent

The Edgewater Hotel, Seattle, Washington.

RAINY MORNING IN NYC. Put my kid, my ass, and my suitcase in an Uber. Dropped Ava at school, then crawled to JFK via every emergency-vehicle-blocked thoroughfare Lower Manhattan, Brooklyn, and Queens had to offer. The roads were all rain and sirens and nobody getting anywhere.

From JFK, flew across the country to surprisingly sunny Seattle. Now ensconced at the Edgewater, the Robert Mitchum of hotels. Built for the 1962 World’s Fair, it sits at the end of a pier over Puget Sound, perpetually threatening to drown itself, but somehow never going through with it.

The rooms are small, but many face the water. Some boast crow’s-foot tubs and windows over the water. Others, smaller and tub-less, make up for it with a sliding glass door to a tiny patio above the water. Mine is the latter type, and my sliding door is flung wide. Gulls caw and ships pass as I rehearse my AEA presentation and catch up on work.

I brought a sketchbook with me (it was a gift from Ava), and gave Ava a sketchbook before I left. We will draw while we’re apart, and compare drawings when I return to NYC.

Looking forward to seeing friends I’ve not seen in months, and to putting on our first AEA show of the year!

Friday Links

TEN great links to launch your weekend:

If you missed Gerry McGovern’s brilliant An Event Apart talk on “Top Task Management,” the video’s here for your pleasure.

If you missed Eric Meyer’s article “Practical CSS Grid: Adding Grid to an Existing Design” in A List Apart, drop what you’re doing and read!

If you missed my chat about design discovery with UX consultant Dan Brown on this week’s Big Web Show, have a listen.

Like it says: “How to Build a Simple and Powerful Lazyload JavaScript Plugin” by Alex Devero in A List Apart: Sidebar.

Modern JavaScript for Ancient Web Developers” by Gina Trapani in Postlight’s “Track Changes.”

What sex is your font? Many people see typefaces as gendered. All this and much more in “The Font Purchasing Habits Survey Results” by Mary Catherine Pflug.

The Gig Economy Celebrates Working Yourself to Death” by Jia Tolentino in The New Yorker.

Well, there goes *that* startup idea. Facebook starts warning U.S. users when they’re sharing fake news in Macworld.

The Three-Hour Brand Sprint” (“GV’s Simple Recipe For Getting Started On Your Brand”) by Jake Knapp.

Why Are Designers Still Expected To Work For Free?” asks Design Observer’s Jessica Helfand in Fast Company’s Co.Design.

Bonus (this one goes to 11): “Jeffrey Zeldman Presents a Math Problem” from Typethos.


Also published in Medium.

Automatic check-ins and the old, personal web

ABOUT A YEAR ago, around the time I launched my new design studio, I moved nearly all business-related communications to Basecamp 3, the latest evolution of the web-based project and communications management tool from my Chicago designer friends who used to be called 37signals.

One of Basecamp 3’s nicest features is the ability to set up automatic check-ins, such as asking all team members “What did you work on today?” at 5:00 pm daily.

On the surface, it’s intended as a way of letting everyone know what their teammates are working on, thereby deleting needless meetings from everyone’s schedules. But the feature can go much deeper, as I’ve discovered to my great pleasure. A day at a time, it can build community and help you design your career and your life. It even brings back some of the joy we once derived from the days of the personal web.

What did you work on today?

Over the years, I’ve started or cofounded several web-related businesses. Rather than limit my new studio.zeldman Basecamp exclusively to the designers, developers, and UX specialists who make up my studio, I decided to include everyone from all the businesses I touch.

Naturally, I’m mindful of people’s bandwidth, so anyone who doesn’t wish to participate can opt out or selectively block threads or projects that don’t interest them. I also refrained from inviting two staffers from one of my businesses who, for whatever reason, have just never hit it off with Basecamp. (Evangelizing any tool, however much one personally loves it, is like trying to convince a carnivore to go vegan. It accomplishes nothing, and leaves everyone feeling hurt.)

Save those two folks, with whom I collaborate through other methods, everyone else I work with on a daily or weekly basis, across all my little businesses, has access to a shared Basecamp. And every day at 5:00 pm Eastern Time, Basecamp asks all of us, “What did you work on today?”

The evolution of open sharing

At first, those who chose to participate took the question literally, sharing the work-related tasks we’d accomplished that day. But, over time, we began something sharing else. We began sharing our lives.

As if in a Unitarian church group, or an AA meeting, we share daily joys and sorrows, hopes and aspirations. One of us has a child leaving the nest; another’s child may have had a tough day at school. One of us is writing a book, another has begun physical therapy. Some of us comment on each other’s shares; others use Basecamp’s “applause” feature to indicate that we read and appreciated what was shared. Some folks write essays; others share via bulleted lists.

Hearkening back to the old, personal web

Sharing and reading other people’s posts has become a highlight of my day. Of course it helps me get my work done, but more importantly, it also lets me focus on my life and professional goals—and those of my friends. I love getting to know people this way, and I deeply appreciate how respectful and safe our sharing space feels—partly because Basecamp designed the space well, and partly because I work with people who are not only talented and bright, but also kind and empathetic.

If we all sat together in the same office space, I doubt we would let down our guard as much as we do when responding to Basecamp’s automatic check-in. Indeed, far less personal sharing goes on with the non-remote colleagues in my NYC studio space—probably because we are all there to work.

It reminds me of what life was once like on the old web, where people shared honestly on their personal sites without fear of being harassed. I’m not the only old-timer who misses that old web; in recent years, several of my internet friends who once blogged blithely have switched to opt-in newsletters, sharing only with subscribers. Although I mourn the personal, open-hearted web we once shared, I understand this impulse all too well. Sharing with my colleague/friends on Basecamp restores some of the joy I used to take from sharing and listening on the old open web. You might try it.

Also published at Medium

State of the Web: Evaluating Technology | Jeremy Keith

Jeremy Keith at An Event Apart.

12 LESSONS from An Event Apart San Francisco – № 6: We work with technology every day. And every day it seems like there’s more and more technology to understand: graphic design tools, build tools, frameworks and libraries, not to mention new HTML, CSS, and JavaScript features landing in browsers. How should we best choose which technologies to invest our time in? When we decide to weigh up the technology choices that confront us, what are the best criteria for doing that?

Jeremy Keith was the seventh speaker at An Event Apart San Francisco this month. His presentation, Evaluating Technology, set out to help us evaluate tools and technologies in a way that best benefits the people who use the websites we design and develop. We looked at some of the hottest new web technologies, like service workers and web components, and dug deep beneath the hype to find out whether they will really change life on the web for the better.

Days of future past

Its easy to be overwhelmed by all the change happening in web design and development. Things make more sense when we apply an appropriate perspective. Although his presentation often dealt with “bleeding-edge” technologies (i.e. technologies that are still being figured out and just beginning to be supported in some browsers and devices), Jeremy’s framing perspective was that of the history of computer science—a field, pioneered by women, that evolved rationally.

Extracting the unchanging design principles that gave rise to the advances in computer science, Jeremy showed how the web evolved from these same principles, and how the seemingly dizzying barrage of changes taking place in web design and development today could be understood through these principles as well—providing a healthy means to decide which technologies benefit human beings, and which may be discarded or at least de-prioritized by busy designer/developers working to stay ahead of the curve.

Resistance to change

“Humans are allergic to change,” computer science pioneer Grace Hopper famously said. Jeremy showed how that very fear of change manifested itself in the changes human beings accept: we have 60 seconds in a minute and 24 hours in a day because of counting systems first developed five thousand years ago. Likewise, we have widespread acceptance of HTML in large part because its creator, Tim Berners-Lee, based it on a subset of elements familiar from an already accepted markup language, SGML.

How well does it fail?

In our evaluating process, Jeremy argued, we should not only concern ourselves with how well a technology works, but also how well it fails. When XHTML 2.0 pages contained an error, the browser was instructed not to skip that error but to shut down completely. Thus, XHTML 2.0 was impractical and did not catch on. In contrast, when an HTML page contains an error or new element, the browser skips what it does not understand and renders the page. This allows us to add new elements to HTML over time, with no fear that browsers will choke on what they don’t understand. This fact alone helps account for the extraordinary success of HTML over the past 25 years.

Likewise, service workers, a powerful new technology that extends our work even when devices are offline, fails well, because it is progressively enhanced by design. If a device or browser does not support service workers, the content still renders.

Jeremy argued that pages built on fragile technologies—technologies which are powerful when they work, but which fail poorly—are a dangerous platform for web content. Frameworks that require JavaScript, for example, offer developers extraordinary power, but at a price: the failure of even a small script can result in no content at all. Service workers technology also offers tremendous power, but it fails well, so is safe to use in the creation of responsive sites and web applications.

On progressive web apps

Likewise, progressive web apps, when designed responsively and with progressive enhancement, are a tremendously exciting web development. But when they are designed the wrong way, they fail poorly, making them a step backward for the web.

Jeremy used the example of The Washington Post’s Progressive Web App, which has been much touted by Google, who are a driving force behind the movement for progressive web apps. A true progressive web app works for everyone. But The Washington Post’s progressive web app demands that you open it in your phone. This kind of retrograde door-slam is like the days when we told people they must use Flash, or must use a certain browser or platform, to view our work. This makes it the antithesis of progressive.

Dancing about architecture

There was much, much more to Jeremy’s talk—one of the shortest hours I’ve ever lived through, as 100 years of wisdom was applied to a dizzying array of technologies. Summarizing it here is like trying to describe the birth of your child in five words or less. Fortunately, you can see Jeremy give this presentation for yourself at several upcoming An Event Apart conference shows in 2017.

The next AEA event, An Event Apart St. Louis, takes place January 30-February 1, 2017. Tomorrow I’ll be back with more takeaways from another AEA San Francisco 2016 speaker.


Also published in Medium.

Val Head: Web Animation in the Design Process

Val Head12 LESSONS from An Event Apart San Francisco – № 5: Val Head was the 9th speaker at An Event Apart San Francisco last week. Her session, Motion In Design Systems: Animation, Style Guides, and the Design Process, led us through everything designers and developers need to make web animation work for our whole team.

Val covered guidelines for designing animation that fits your brand, making animation part of your design process, and documenting your animation decisions in your style guide for future use.

It takes a village

Animation works best when the whole team plans for it. If it’s simply a wish—say on the part of the designer—everyone in the chain will be too busy with higher priority tasks, and the animation won’t get made.

Which is a pity, because well-considered animations (such as Val showed) can make interactions much easier to understand. Additionally, if choreographed by the entire team as part of a bigger picture, animations can reinforce your brand. (Done without consideration, and without the support of the entire team, they’re more likely to contradict important brand attributes.)

Better animation requires good communication, comprised of…

  • Shared vocabulary
  • Established animation values
  • Documentation and repeatability

Deliverables – the things that start conversations

The first deliverables for animation are conversation starters: storyboards and sketches that help the team envision where there is potential for animation in their user flow, see how an animation could make the screen easier for users to understand, and begin to plan how to animate between screens. Best of all, anyone can create a sketch or storyboard: artistic talent is not required (these are not Pixar animations but simple conveyors of ideas).

In every storyboard, we should draw or describe a trigger (what starts the action?), an action (what takes place?), and a quality (how does it happen?).

Motion comps and interactive prototypes

Motion comps answer questions about how the animations should look, move, and behave, and allow for quick iteration. When handing them off to the development team, it’s important to include the duration and delay values; details of the easing used; repeat values, and iteration counts.

Interactive prototypes come next. They allow the team to explore what the interaction will be like to use, decide if it feels right in context, and determine how animations interact with input or real data. Val took us through a number of tools that can be used for prototyping, from apps like Atomic to good old HTML, CSS, and JavaScript.

Define and document – save future you time and effort

Interface animations are most effective when they work in concert as part of the bigger picture. Designing and choreographing your web animation efforts from the top down leads to more effective animations that integrate into your design system. And, defining a motion language for your brand can help your team to develop a shared vision from which to work.

Don’t just create animations—define and document them. Define your brand in motion with the same care you take for your logo, style guide, and pattern libraries. Use design principles to inform motion decisions. Study Brand Pillars, Voice & Tone, and Experience Pillars, and build your animation guidelines from there. Animations are best when they’re brand-appropriate and repeatable.

Get input from everyone

Having brought us through the rationale for animations and a variety of potential workflows, Val took us deeply into the details that make for effective animations, and ended with a game plan enabling everyone on the team to become an undercover animation superhero.

Tomorrow I’ll be back with more top takeaways from another AEA San Francisco 2016 speaker. The next AEA event, An Event Apart St. Louis, takes place January 30-February 1, 2017

 

Also published in Medium

See also: 4 tools for designing better UI animation by Val Head.

Jason Grigsby on Design Beyond Touch

Jason Grigsby at An Event Apart

12 LESSONS from An Event Apart San Francisco – № 4: Jason Grigsby was the 10th speaker at An Event Apart San Francisco last week. Jason’s session, Adapting to Input, presented designers and developers with a conundrum many of us hadn’t yet considered when designing for our new spectrum of web-capable devices.

Responsive web design forced us to accept that we don’t know the size of our canvas, and we’ve learned to embrace the squishiness of the web. Well, input, it turns out, is every bit as challenging as screen size! We have tablets with keyboards, laptops that become tablets, laptops with touch screens, phones with physical keyboards, and even phones that become desktop computers. What’s a design mother to do?

During his session, Jason guided us through the input landscape, showing us new forms of input (such as sensors and voice control) and sharing new lessons about old input standbys. We learned the design principles needed to build websites that respond and adapt to whichever inputs people choose to use.

Four truths about web inputs

Jason began by sharing four truths about input in 2016:

  1. Input is exploding — The last decade has seen everything from accelerometers to GPS to 3D touch.
  2. Input is a continuum — Phones have keyboards and cursors; desktop computers have touchscreens.
  3. Input is undetectable — Browser detection of touch‚ and nearly every other input type, is unreliable.
  4. Input is transient — Knowing what input someone uses one moment tells you little about what will be used next.

A Golden Rule of Inputs

Just as many of us screwed up our early approach to multi-device design by consigning the “mobile web” to a non-existent “mobile context,” we now risk making a similar blunder by believing that certain tasks are “only for the keyboard”—forgetting that by choice or of necessity, the people who engage with our websites use a variety of devices, and our work must be available to them all.

One of my principal takeaways from Jason’s presentation was that every desktop design must go “finger-friendly.” Or, as Josh Clark put it back in 2012, “When any desktop machine could have a touch interface, we have to proceed as if they all do.”

Learn More

For more illuminations on input, read Jason Grigsby’s “Adapting to Input” in A List Apart, and check out these amazing demos and articles:

Tomorrow I’ll be back with another top takeaway from another AEA San Francisco 2016 speaker. The next AEA event, An Event Apart St. Louis, takes place January 30-February 1, 2017 in the shadow of Mr Sarrinenen’s fabulous arch. See you there!

Solve the Right Problem: Derek Featherstone on designing for extremes

Derek Featherstone at An Event Apart

12 LESSONS from An Event Apart San Francisco – № 3: Derek Featherstone was the 10th speaker at An Event Apart San Francisco, which ended Wednesday. His session, Extreme Design, showed how creating great experiences for people with disabilities results in better designs for everyone.

Focusing relentlessly on accessibility helps us think of extreme scenarios and ask questions like “how can we make this work eyes free?” and “how can we make this work with the least amount of typing?” Most importantly, it leads to deeper design thinking that solves problems for everyone who uses our sites and products.

A Map For The Blind

One of my favorite examples from Derek’s presentation had to do with a map. A Canadian city was expanding geographically to encompass some of the surrounding suburbs. The city’s website was charged with letting all citizens know about the change. The web team did what you or I would probably do: they created a map that clearly showed the old and new city limits.

Unfortunately, this visual map was by definition inaccessible to blind citizens, so the city brought in Derek and his colleagues to design an equivalent experience for the unsighted. Derek’s team and the web team pondered typical solutions—such as laborious written descriptions of the city’s shifting geographic borders. But these were not user-friendly, nor did they get to the heart of the problem.

Maybe creating a verbal equivalent of a visual map wasn’t the answer. Derek’s team kept digging. Why was the map created in the first place, they asked. What was the point of it? What were users supposed to take away from it?

It turned out, people wanted to know if their street fell within the new city boundaries because, if it did, then their taxes were going to go up.

Solving for a map wasn’t the point at all. Allowing people to find out if their home address fell inside the new city limits was the point.

A simple data entry form accomplished the task, and was by definition accessible to all users. It was also a much quicker way even for sighted user to get the information they wanted. By solving for an extreme case—people who can’t see this map—the web teams were able to create a design that worked better for everyone.

Tomorrow I’ll be back with another top takeaway from another AEA San Francisco 2016 speaker. The next AEA event, An Event Apart St. Louis, takes place January 30-February 1, 2017.

 

Also published at Medium.

Identify “stress cases” and design with compassion: Eric Meyer

Eric Meyer at An Event Apart12 LESSONS from An Event Apart San Francisco – № 2: Eric Meyer was the 11th speaker at An Event Apart San Francisco, which ended Wednesday. His session, Compassionate Design, discussed the pain that can occur when our carefully crafted websites and applications, designed to create an ideal experience for idealized users, instead collide with messy human reality.

You can’t always predict who will use your products, or what emotional state they’ll be in when they do. A case in point: when Facebook’s “Your Year in Review” feature, designed by well-meaning people to help Facebook users celebrate their most important memories from the preceding twelve months, shoved a portrait of Eric’s recently deceased daughter Rebecca in his face, surrounded by dancing and partying clip-art characters who appeared to be celebrating her death.

With great power…

Certainly, no one at Facebook intended to throw a hundred pound bag of salt into the open wound of a grieving parent. What happened, surely, was that no one sitting around the table when the feature was planned asked the question, what if one of our users just had the worst year of their lives?

If even one of the talented Facebook folks charged with creating the new feature had asked themselves “what’s the worst that can happen?”—if just one of them had realized that not everyone using Facebook felt like celebrating their year—they might have put in safeguards to prevent their algorithm from assuming that a Facebook user’s most visited (most “popular”) post of the year was also their happiest.

They might also have made the “year in review” feature an opt-in, with questions designed to protect those who had experienced recent tragedy. Facebook didn’t build in those protections, not because they don’t care, but because our approach to design is fundamentally flawed, in that we build our assumptions around idealized and average users and use cases, and neglect to ask ourselves and our teammates, “what if we’re wrong? How could our product hurt someone?”

It’s not just Facebook. We all ignore the user in crisis.

Eric shared many examples from leading sites and services of unintended and sometimes horrifying instances of designs that hurt someone—from ads that accidentally commented sadistically on tragic news stories (because keyword exclusion is underrated and underused in online advertising); to magic keywords Flickr and Google added to their customers’ photos without asking, resulting in a man’s portrait being labeled “gorilla” and a concentration camp photo being tagged a jungle gym.

The problem, Eric explained, is that our systems have not been designed with people in mind. They’ve been designed with consumers in mind. Consumers are manageable fictions. But human life is inherently messy. To create sites and applications that work for everyone, including  people who may be having the worst day of their lives at the time they encounter or product or service, we must always think about how our product could be used to hurt someone, and plan for the worst-case scenario whenever we design.

When we label a usage an “edge case,” we marginalize that user and choose not to care. Think “stress case,” instead, and design for that human.

We can do better.

Eric’s presentation included many techniques for bringing these new principles into our design workflows, and his book with Sara Wachter-Boettcher, Design for Real Life, goes into even greater detail on the matter. (It’s one of those rare and important books that defines how we should be looking at our design jobs today, and I would say that even if I weren’t the publisher.)

Tomorrow I’ll be back with another top takeaway from another AEA San Francisco 2016 speaker. The next AEA event, An Event Apart St. Louis, takes place January 30-February 1, 2017.

 
Also published on Medium.

Measure Customer Time, Not Organization Time: Gerry McGovern

Gerry McGovern12 LESSONS from An Event Apart San Francisco – № 1: Gerry McGovern was the 12th speaker at An Event Apart San Francisco, which ended yesterday. His session Top Task Management: Making it Easier to Prioritize tackled the firehose of content and interactions web and interaction designers and developers are called upon to support.

Gerry shared example after example of cases where most of this stuff didn’t matter at all to the person using the site or service, and drew the commonsense—but too rare in the corporate world—conclusion that if we spend our time making stuff that matters to our organization instead of stuff that matters to our customer, we will lose our customer. (“Nobody reads your annual report.”)

One of my favorite takeaways from Gerry’s session was about performance, but not in the way you probably think. Gerry pointed out that, in organizations, we are always measuring our own performance: how quickly did we turn that project around? Did we launch on time? Instead of dressing up our navel gazing with analytics that are about our tasks, we should measure our customers’ speed. How quickly do our sites and products help our customers achieve their goals? How can we identify and remove additional obstacles to completion, so our customers achieve their goals faster and faster?

We need to manage speed on the page, not just the speed of the page load. Manage the customer’s time on task. We won’t become customer-centric until we change our metrics—focusing on customers’ time to complete tasks, not on internal speed, and not just on the mechanical speed of page load—although page load speed (and perceived page load speed) are also terribly important, of course, and are part of improving the customer’s time to complete their task.

“If you solve the customer’s problem, they’ll solve your problem.” When you understand your customer’s top task, and focus relentlessly on helping them achieve it, you build a relationship that works for organization and customer alike.

Tomorrow I’ll be back with another top takeaway from another AEA San Francisco 2016 speaker. The next AEA event, An Event Apart St. Louis, takes place January 30-February 1, 2017.

 

Also shared on Medium

Ten Years Ago on the Web

2006 DOESN’T seem forever ago until I remember that we were tracking IE7 bugsworrying about the RSS feed validator, and viewing Drupal as an accessibility-and-web-standards-positive platform, at the time. Pundits were claiming bad design was good for the web (just as some still do). Joe Clark was critiquing WCAG 2. “An Inconvenient Truth” was playing in theaters, and many folks were surprised to learn that climate change was a thing.

I was writing the second edition of Designing With Web Standards. My daughter, who is about to turn twelve, was about to turn two. My dad suffered a heart attack. (Relax! Ten years later, he is still around and healthy.) A List Apart had just added a job board. “The revolution will be salaried,” we trumpeted.

Preparing for An Event Apart Atlanta, An Event Apart NYC, and An Event Apart Chicago (sponsored by Jewelboxing! RIP) consumed much of my time and energy. Attendees told us these were good shows, and they were, but you would not recognize them as AEA events today—they were much more homespun. “Hey, kids, let’s put on a show!” we used to joke. “My mom will sew the costumes and my dad will build the sets.” (It’s a quotation from a 1940s Andy Hardy movie, not a reflection of our personal views about gender roles.)

Jim Coudal, Jason Fried and I had just launched The Deck, an experiment in unobtrusive, discreet web advertising. Over the next ten years, the ad industry pointedly ignored our experiment, in favor of user tracking, popups, and other anti-patterns. Not entirely coincidentally, my studio had just redesigned the website of Advertising Age, the leading journal of the advertising profession.

Other sites we designed that year included Dictionary.com and Gnu Foods. We also worked on Ma.gnolia, a social bookmarking tool with well-thought-out features like Saved Copies (so you never lost a web page, even if it moved or went offline), Bookmark Ratings, Bookmark Privacy, and Groups. We designed the product for our client and developed many of its features. Rest in peace.

I was reading Adam Greenfield’s Everyware: The Dawning Age of Ubiquitous Computing, a delightfully written text that anticipated and suggested design rules and thinking for our present Internet of Things. It’s a fine book, and one I helped Adam bring to a good publisher. (Clearly, I was itching to break into publishing myself, which I would do with two partners a year or two afterwards.)

In short, it was a year like any other on this wonderful web of ours—full of sound and fury, true, but also rife with innovation and delight.


As part of An Event Apart’s A Decade Apart celebration—commemorating our first ten years as a design and development conference—we asked people we know and love what they were doing professionally ten years ago, in 2006. If you missed parts onetwothree, or four, have a look back.