Infocon: green

 ∗ SANS Internet Storm Center, InfoCON: green

ISC StormCast for Wednesday, September 2nd 2015

ISC StormCast for Wednesday, September 2nd 2015, (Wed, Sep 2nd)

 ∗ SANS Internet Storm Center, InfoCON: green


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

 ∗ Zeldman on Web & Interaction Design

EVERY TIME I hear a brilliant 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 =

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 =
// -->

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

<script type="text/javascript">
<!-- //
if (!document.getElementById) {
window.location =
// -->





What's the situation this week for Neutrino and Angler EK?, (Wed, Sep 2nd)

 ∗ SANS Internet Storm Center, InfoCON: green


Last month in mid-August 2015, an actor using An ...(more)...

How to hack, (Tue, Sep 1st)

 ∗ SANS Internet Storm Center, InfoCON: green

" />
Agreed, this information is not overly useful. These hacks are basically on the oppos ...(more)...

ISC StormCast for Tuesday, September 1st 2015, (Tue, Sep 1st)

 ∗ SANS Internet Storm Center, InfoCON: green


Go GC: Prioritizing low latency and simplicity

 ∗ The Go Programming Language Blog

The Setup

Go is building a garbage collector (GC) not only for 2015 but for 2025 and beyond: A GC that supports today’s software development and scales along with new software and hardware throughout the next decade. Such a future has no place for stop-the-world GC pauses, which have been an impediment to broader uses of safe and secure languages such as Go.

Go 1.5, the first glimpse of this future, achieves GC latencies well below the 10 millisecond goal we set a year ago. We presented some impressive numbers in a talk at Gophercon. The latency improvements have generated a lot of attention; Robin Verlangen’s blog post Billions of requests per day meet Go 1.5 validates our direction with end to end results. We also particularly enjoyed Alan Shreve’s production server graphs and his "Holy 85% reduction" comment.

Today 16 gigabytes of RAM costs $100 and CPUs come with many cores, each with multiple hardware threads. In a decade this hardware will seem quaint but the software being built in Go today will need to scale to meet expanding needs and the next big thing. Given that hardware will provide the power to increase throughput, Go’s garbage collector is being designed to favor low latency and tuning via only a single knob. Go 1.5 is the first big step down this path and these first steps will forever influence Go and the applications it best supports. This blog post gives a high-level overview of what we have done for the Go 1.5 collector.

The Embellishment

To create a garbage collector for the next decade, we turned to an algorithm from decades ago. Go's new garbage collector is a concurrent, tri-color, mark-sweep collector, an idea first proposed by Dijkstra in 1978. This is a deliberate divergence from most "enterprise" grade garbage collectors of today, and one that we believe is well suited to the properties of modern hardware and the latency requirements of modern software.

In a tri-color collector, every object is either white, grey, or black and we view the heap as a graph of connected objects. At the start of a GC cycle all objects are white. The GC visits all roots, which are objects directly accessible by the application such as globals and things on the stack, and colors these grey. The GC then chooses a grey object, blackens it, and then scans it for pointers to other objects. When this scan finds a pointer to a white object, it turns that object grey. This process repeats until there are no more grey objects. At this point, white objects are known to be unreachable and can be reused.

This all happens concurrently with the application, known as the mutator, changing pointers while the collector is running. Hence, the mutator must maintain the invariant that no black object points to a white object, lest the garbage collector lose track of an object installed in a part of the heap it has already visited. Maintaining this invariant is the job of the write barrier, which is a small function run by the mutator whenever a pointer in the heap is modified. Go’s write barrier colors the now-reachable object grey if it is currently white, ensuring that the garbage collector will eventually scan it for pointers.

Deciding when the job of finding all grey objects is done is subtle and can be expensive and complicated if we want to avoid blocking the mutators. To keep things simple Go 1.5 does as much work as it can concurrently and then briefly stops the world to inspect all potential sources of grey objects. Finding the sweet spot between the time needed for this final stop-the-world and the total amount of work that this GC does is a major deliverable for Go 1.6.

Of course the devil is in the details. When do we start a GC cycle? What metrics do we use to make that decision? How should the GC interact with the Go scheduler? How do we pause a mutator thread long enough to scan its stack?  How do we represent white, grey, and black so we can efficiently find and scan grey objects? How do we know where the roots are? How do we know where in an object pointers are located? How do we minimize memory fragmentation? How do we deal with cache performance issues? How big should the heap be? And on and on, some related to allocation, some to finding reachable objects, some related to scheduling, but many related to performance. Low-level discussions of each of these areas are beyond the scope of this blog post.

At a higher level, one approach to solving performance problems is to add GC knobs, one for each performance issue. The programmer can then turn the knobs in search of appropriate settings for their application. The downside is that after a decade with one or two new knobs each year you end up with the GC Knobs Turner Employment Act. Go is not going down that path. Instead we provide a single knob, called GOGC. This value controls the total size of the heap relative to the size of reachable objects. The default value of 100 means that total heap size is now 100% bigger than (i.e., twice) the size of the reachable objects after the last collection. 200 means total heap size is 200% bigger than (i.e., three times) the size of the reachable objects. If you want to lower the total time spent in GC, increase GOGC. If you want to trade more GC time for less memory, lower GOGC.

More importantly as RAM doubles with the next generation of hardware, simply doubling GOGC will halve the number of GC cycles. On the other hand since GOGC is based on reachable object size, doubling the load by doubling the reachable objects requires no retuning. The application just scales. Furthermore, unencumbered by ongoing support for dozens of knobs, the runtime team can focus on improving the runtime based on feedback from real customer applications.

The Punchline

Go 1.5’s GC ushers in a future where stop-the-world pauses are no longer a barrier to moving to a safe and secure language. It is a future where applications scale effortlessly along with hardware and as hardware becomes more powerful the GC will not be an impediment to better, more scalable software. It’s a good place to be for the next decade and beyond. For more details about the 1.5 GC and how we eliminated latency issues see the Go GC: Latency Problem Solved presentation or the slides.

GopherCon 2015 Roundup

 ∗ The Go Programming Language Blog

A few weeks ago, Go programmers from around the world descended on Denver, Colorado for GopherCon 2015. The two-day, single-track conference attracted more than 1,250 attendees—nearly double last year's number—and featured 22 talks presented by Go community members.

The Cowboy Gopher (a toy given to each attendee) watches over the ranch.
Photograph by Nathan Youngman. Gopher by Renee French.

Today the organizers have posted the videos online so you can now enjoy the conference from afar:

Day 1:

Day 2:

The hack day was also a ton of fun, with hours of lightning talks and a range of activities from programming robots to a Magic: the Gathering tournament.

Huge thanks to the event organizers Brian Ketelsen and Eric St. Martin and their production team, the sponsors, the speakers, and the attendees for making this such a fun and action-packed conference. Hope to see you there next year!

Encryption of "data at rest" in servers, (Tue, Sep 1st)

 ∗ SANS Internet Storm Center, InfoCON: green

Over in the SANS ISC discussion forum, a couple of readers have started a good discussion

Automating Metrics using RTIR REST API, (Sat, Aug 29th)

 ∗ SANS Internet Storm Center, InfoCON: green

Nishant Kothary on the Human Web: “Buy Him A Coffee”

 ∗ A List Apart: The Full Feed

My first job out of college was as a program manager. Program Manager is one of those job titles that sounds important because it implies that there exists a Program, and you have been anointed to Manage it. Who doesn’t want to be boss!

As with all impressive-sounding things, program management job descriptions are littered with laughable bullets like:

Must be proficient at influencing others without authority.

Which may as well be written as:

Life is.


Thing is Thing.

Pretty much every freshman PM ignores that qualification, and interviewers rarely test for it. We take for granted that the ability to influence people is important (true), and that we are all acceptably good at it (false).

For most of us, the first time our ability to influence people is truly tested is at our first job. And most of us fail that first test.

When I first realized I was terrible at influencing people, I projected the problem outward and saw it as a product of the environment I worked in. “It’s not me, it’s them,” I’d tell my friends at work and my management chain. As I wrote in my first column, my boss would say to me, “It is what it is.” This would instantly make me want to either have at the world with an axe or drive my Outback straight up into the North Cascades, hike until I ran into a grizzly, give her cub a wet willy, and submit to the fateful paw of death.

I also blamed my nature. If you are to believe the results of the informal quiz I took in Susan Cain’s Quiet: The Power of Introverts in a World That Can’t Stop Talking, my score of 18/20 suggests I am as introverted as they come. And while I come across as an extrovert now—behavior I’ve practiced over years—nothing about interacting with people feels natural to me. This is not to say that introverts (or I) dislike people. It’s more like like what Dr. Seuss said about children, “In mass, [they] terrify me.”

My first breakthrough came when a colleague at work saw me having a particularly difficult struggle to convince an individual from another team to expedite some work for mine, and suggested, “Buy him a coffee.” The kind of advice that feels like it fell out of a Dale Carnegie book into an inspirational poster of two penguins holding hands. PENGUINS DON’T EVEN HAVE HANDS. But I did it anyway because I was at my wit’s end.

I met him at Starbucks, and picked up the tab for his latte. We grabbed some chairs and awkwardly, wordlessly stared at our coffees.

Panicked at the mounting silence, I tried the first thing that came to mind. What I didn’t know then was that it’s a cornerstone technique of people who are good at influencing others: I asked him something about himself.

“So, are you from Seattle?”

“Indiana, actually.”

“No way. I attended college in Indiana!”

Soon enough, we realized we had far more in common than we’d expected; including cats that, judging by their attitudes, probably came from the same satanic litter. While I still wasn’t able to get him to commit to our team’s deadline, I did walk away with a commitment that he’d do his best to come close to it.

More importantly, I’d inadvertently happened upon a whole new set of tools to help me achieve my goals. I didn’t realize it then, but I had just learned the first important thing about influencing people: it’s a skill—it can be learned, it can be practiced, and it can be perfected.

I became aware of a deficit in my skillset, and eventually I started working on it proactively. It’s been a decade since that first coffee. While I’m still (and suspect, always will be) a work in progress, I have come a long way.

You can’t learn how to influence people overnight, because (as is true for all sophisticated skills) there’s a knowledge component that’s required. It often differs from person to person, but it does take time and investment. Generally speaking, it involves filling gaps about your knowledge of humans: how we think, what motivates us, and as a result, how we behave. I keep a list of the books that helped me along the way, including Carnegie’s almost-century-old classic, How to Win Friends and Influence People. But as Carnegie himself wrote, “Knowledge isn’t power until it is applied.”

What will ultimately decide whether you become someone who can influence others is your commitment to practice. Depending on your nature, it will either come easier to you, or be excruciatingly hard. But even if you’re an extrovert, it will take practice. There is no substitute for the field work.

What I can promise you is that learning how to earn trust, be liked, and subsequently influence people will be a worthwhile investment not only for your career, but also for your life. And even if you don’t get all the way there—I am far from it—you’ll be ahead of most people for just having tried.

So my advice to you is: instead of avoiding that curmudgeon at work, go buy them a coffee.

Test File: PDF With Embedded DOC Dropping EICAR , (Fri, Aug 28th)

 ∗ SANS Internet Storm Center, InfoCON: green


PDF + maldoc1 = maldoc2, (Wed, Aug 26th)

 ∗ SANS Internet Storm Center, InfoCON: green

I received another example of a

Reframing Design

 ∗ Zeldman on Web & Interaction Design

Reframing design in A List Apart.

ISSUE № 426 of A List Apart reframes the design process:

The Language of Modular Design

by Alla Kholmatova

Goodbye, pages; hello, systems! When we break things down into atomic units, design elements become more scalable and replaceable, easier to test, and quicker to assemble. Alla Kholmatova emphasizes that a shared vocabulary should be the jumping-off point for teams who want to adopt a modular design approach. Let’s start with language, not interfaces.

Sharing Our Work: Testing and Feedback in Design

by Jessica Harllee

Showing your in-progress designs can be scary, but there’s no better way to keep your product in line with your users’ needs. Research and testing aren’t just boxes to be checked off; they’re methodologies to be integrated into the entire design process—and the more, and the more diverse, the merrier. Jessica Harllee explains how Etsy shares their work with users every step of the way—and the benefits (and surprises) that follow.

The post Reframing Design appeared first on Zeldman on Web & Interaction Design.

Job Hunting For Web Designers

 ∗ Zeldman on Web & Interaction Design

Stagnation is fine for some jobs—when I was a dishwasher at The Earth Kitchen vegetarian restaurant, I enjoyed shutting off my brain and focusing on the rhythmic scrubbing of burnt pans, the slosh and swirl of peas and carrots in a soapy drain—but professionals, particularly web professionals, are either learning and growing or, like the love between Annie Hall and Alvy Singer, becoming a dead shark. If you’ve stopped learning on the job, it’s past time to look around.

Source: If Ever I Should Leave You: Job Hunting For Web Designers and Developers · An A List Apart Column

The post Job Hunting For Web Designers appeared first on Zeldman on Web & Interaction Design.

Designing With Words

 ∗ Zeldman on Web & Interaction Design

I’M ALWAYS telling my colleagues and students that a designer who wants to make a difference and enjoy a long career must master writing and public speaking. I’ve seen way too many designers with far greater natural gifts than I possess struggle in early, mid-, and late career, because, despite their great talent and the thoughtful rigor of their work, they lack the practiced, confident communications ability that every designer needs to sell their best work.

Few designers currently working better exemplify the designer-as-communicator than Mike Monteiro, co-founder of Mule Design and author of two great design books (so far). If you’ve heard Monteiro speak, or if you’ve read his books, you already know this. If you haven’t, you’re in for a treat: last month, because he loves designers and clients, and with the blessing of his publisher, Mike posted an entire chapter of his latest book, You’re My Favorite Client, for your free reading pleasure; now he has done the same thing with his best-selling first book, Design Is A Job.

Chapter 1 of Design Is A Job, posted for free last night on Medium, poses the question, just what exactly is a designer, anyway? After dispensing with the myth of the magical pixie creative and explaining why it is destructive, Mike settles in to explain what a good designer actually does—and why design, in its role as societal gatekeeper, is a high calling with a tough ethical mandate.

Reading good writing about design, by someone who actually works as a designer, is a rare pleasure. What are you waiting for? Enjoy Chapter 1 of Design Is A Job.

(And, heck, if you want more, you can always buy the book.)

Top animation by Mike Essl for Mike Monteiro.

The post Designing With Words appeared first on Zeldman on Web & Interaction Design.

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

 ∗ Zeldman on Web & Interaction Design

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.

The post Publishing v. Performance—or, The Soul of the Web appeared first on Zeldman on Web & Interaction Design.

A List Apart Summer Reading

 ∗ Zeldman on Web & Interaction Design

SUMMER is halfway over. Have you hid out for a day of reading yet? Grab a shady spot and a picnic blanket (or just park it in front of the nearest AC unit), turn off your notifications, and unwrap this tasty treat: our 2015 summer reader.

Refresh your mind, heart, and spirit with this curated list of articles, videos, and other goodies from the recent past—from A List Apart and across the web.

Our 2015 compilation of articles, blogs, and other gems from across the web: perfect summer reading, poolside and beyond.

Source: 2015 Summer Reading Issue · An A List Apart Article

The post A List Apart Summer Reading appeared first on Zeldman on Web & Interaction Design.

Co-Design, Not Redesign, by Kevin M. Hoffman – An Event Apart Video

 ∗ Zeldman on Web & Interaction Design

Kevin M. Hoffman

MOVE from the nightmare of design by committee to the joys of design collaboration.

In this 60-minute video captured live at An Event Apart Orlando: Special Edition, Kevin M. Hoffman explains how service design thinking, lean approaches to user experience, and co-design processes offer an alternative to the usual (expensive) design project frustrations, and deliver experiences to delight your users.

Source: An Event Apart News: Co-Design, Not Redesign, by Kevin M. Hoffman – An Event Apart Video

The post Co-Design, Not Redesign, by Kevin M. Hoffman – An Event Apart Video appeared first on Zeldman on Web & Interaction Design.

A Beautiful Life

 ∗ Zeldman on Web & Interaction Design

LIZZIE VELASQUEZ, age 25, weighs 64 pounds. Born with a rare syndrome that prevents her from gaining weight, she was not expected to survive. Her parents took her home, raised her normally, and, when she turned five, sent her to kindergarten, where she discovered, through bullying, that she was different.

The bullying peaked when an adult male posted a photo of thirteen-year-old Lizzie labeled “World’s Ugliest Woman” on YouTube. The video got four million views. The uniformly unkind comments included sentiments like, “Do the world a favor. Put a gun to your head, and kill yourself.”

Rather than take the advice of anonymous cowards, Lizzie determined not to let their cruelty define her. Instead, as she reveals in this inspiring video captured at TEDxAustinWomen, Lizzie channeled the experience into a beautiful and fulfilling life.

The post A Beautiful Life appeared first on Zeldman on Web & Interaction Design.

The Conversion Issue

 ∗ Zeldman on Web & Interaction Design

A List Apart № 424

TURN visitors into committed community members, and decision makers into ardent advocates of web performance. It’s easy, with the info in today’s A List Apart for people who make websites:

Performance: Showing Versus Telling

by Lara Hogan

The technical aspects of performance optimization are indisputably important. But the social work—convincing peers, managers, and clients that performance optimization merits their attention—often gets short shrift. Lara Hogan shows us how we can go beyond charts, graphs, and numbers to show performance rather than merely tell it—and effect a genuine culture shift in the process.

The Risky Business of Onboarding

by Rick Pastoor

Attracting—and keeping—new users is a delicate dance. Too many obstacles and people don’t sign up; too little interaction and they don’t come back. The ideal onboarding process turns potential users into loyal ones—by thoughtfully identifying new users, teaching them to use your product, and giving them a reason to return. Rick Pastoor shares his onboarding framework and what he’s learned about the difference between a good onboarding process and a great one.

The post The Conversion Issue appeared first on Zeldman on Web & Interaction Design.

This Week In The Death of Publishing & The Web

 ∗ Zeldman on Web & Interaction Design


Apple, like Facebook, has entered into a standoff with the publishing industry and the open, if for-profit, web. And it’s being done under the aegis of design: choose a better reading experience on our curated platform, they offer, or let us clean up that pesky advertising on the open web.

Source: Apple Saves Publishing… For Itself

N.B. This is not the first time this conversation has arisen, nor will it be the last. Off the top of my head, see also:

⇛ Is the web under threat? Will Facebook or Apple kill or save journalism? Share your thoughts or your favorite links on the subject. Bonus points for older articles.

The post This Week In The Death of Publishing & The Web appeared first on Zeldman on Web & Interaction Design.

Give me file hierarchies, or give me chaos.

 ∗ Zeldman on Web & Interaction Design

IN “HOW DROPBOX Remains Relevant,” Khoi Vinh explains why Dropbox owes much of its success to subtly faceted, user-focused design:

Even in an age when the biggest operating systems in the world actively eschew file hierarchies, Dropbox is thriving—its service matters deeply to countless users. Why? In part it’s because the company works hard at making file hierarchies useful, that they focus on the outcomes of file management and not just on the files and folders.

Absolutely. Dropbox sweats the user experience details as commendably as it masters the considerable engineering challenges required to reliably sync files everywhere a user may need them.

But there’s another reason Dropbox succeeds. And it isn’t despite its emphasis on old-fashioned file hierarchies. It’s because of that emphasis.

⇛ ALTHOUGH Khoi may well be right that “smart passive management of design assets and working files seems inevitable,” I, for one, do not look forward to the day I no longer have direct access to my files and the ability to control where and how they are stored. To my way of thinking, passive management of file assets is okay for screwing around with iPads, where we’re mainly watching TV on Netflix or obsessive-compulsively checking the popularity of our Instagram uploads. But for real work, and even for passionate hobby work (like managing family photos), give me files and folders any day.

Stay with photos a moment. Consider snapshots. For my money, apps like Photos (and, formerly, iPhoto) that “save” me from the “inconvenience” of knowing where my images are do me no favors. Thanks, but no thanks. Let me save photos where I want to save them, not where the system thinks I should save them—typically on a laptop’s rapidly filling solid state hard drive with minimal storage capacity.

Dropbox, with its emphasis on good old-fashioned hierarchies, is superb at automatically saving one original of each photo I take, whether shot with a phone or a fancy camera. No loops, no duplicates, no confusion. In contrast, Photo’s cloud sync options, designed to spare the user the trouble of thinking, always trip me up. Like when, after syncing my phone to my home desktop computer, I tell Photos to delete the photos I’ve just sync’d from my phone. Photos obeys my command, and then instantly restores the photos to my phone from the “cloud.”

Why would a system expect a user who has deleted files to want those files restored a moment later? In what universe of scenarios can that possibly be what the user expects? [Your system may work differently from mine. Your deletes may stick. If so, good on you. You may have checked a different box in a hidden drawer of a preferences dialog, possibly in the app preferences you can set in the app itself, or possibly in the app preferences you set in the phone’s Settings app, or possibly online—say, in iCloud, or possibly in the iCloud settings in the phone’s Settings app. This is simplicity?]

Because my phone and iCloud restore photos as soon as they’re deleted, my Camera Roll is an unwieldly monster—despite my applying common sense, logic, years of design and computer using experience, and hours of conversation with a rapidly dwindling circle of friends—not to mention the hours I’ve spent scouring the web for hints. The whole situation reminds me of an article I saw on the cover of PC World years ago: “Plug ‘n Play: How To Make It Work.” (Hint: If you have to learn how to make it work, it ain’t plug ‘n play. And that’s kind of how I feel about the current state of passive file management.)

⇛ SYSTEMS designed to relieve you of thinking too often end up forcing you to think, and think, and think, without ever solving the problems their supposed simplicity has created for you. How much easier would photo maintenance on my phone be if Photos, like Dropbox, used file hierarchies? I could solve the problem myself in a second, with the click of a checkbox, if only Apple weren’t committed to chasing a future where nobody needs to know anything about how their computer works—and, as a result, some of us have no clue what to do when the computer doesn’t work quite right.

⇛ I UNDERSTAND that these are difficult problems to solve, and that confusion and frustration are the price consumers pay for innovation that may benefit them in the long run, once all the kinks are out. I’m not anti-innovation or anti-Apple.

But I’m a web person. I like files. I like editing a CSS file without necessarily having to edit an HTML file. I like fixing a problem by replacing a corrupted file with a clean one. Maybe I’m set in my ways, but I don’t consider it a hardship to open a folder or replace a file. I wouldn’t be quite as happy with a web where I didn’t “need” to “bother” writing CSS.

In the same way, I like deciding where files go—saving an image for Project A in a Project A folder, a text document for Project B in a Project B folder (and all of it in Dropbox). I’m glad Adobe Lightroom maintains a picture of my photo folder hierarchy in a sidebar of its interface, enabling me to see where my files live, and instantly choose a group of photos by date (instead of, say, scrolling through thousands of files visually). When it’s time to get dressed in the morning, I don’t throw myself into a giant room full of clothes. I pull socks from my sock drawer and shirts from my shirt drawer. I’ve been doing this since I was five years old. It’s not a challenge.

Khoi ends his excellent Dropbox piece thusly:

Maybe we’re all just set in our ways, but people seem at least resigned, and more likely just plain comfortable with managing their files. It may not be what future workflows are built around, but for working designers, the future is hypothetical, and Dropbox works today.

To which I say Amen. And add the hope that, so long as my career lasts, I can keep using a workflow I find easy and comprehensible.

Don’t make me think.” Absolutely. But, equally, don’t treat me like an idiot. Folders über alles.

Also published in Medium

The post Give me file hierarchies, or give me chaos. appeared first on Zeldman on Web & Interaction Design.

Thinking Responsively: A Framework for Future Learning

 ∗ A List Apart: The Full Feed

Before the arrival of smartphones and tablets, many of us took a position of blissful ignorance. Believing we could tame the web’s inherent unpredictability, we prescribed requirements for access, prioritizing our own needs above those of users.

As our prescriptions grew ever more detailed, responsive web design signaled a way out. Beyond offering a means of building device-agnostic layouts, RWD initiated a period of reappraisal; not since the adoption of web standards has our industry seen such radical realignment of thought and practice.

In the five years since Ethan Marcotte’s article first graced these pages, thousands of websites have launched with responsive layouts at their core. During this time, we’ve experimented with new ways of working, and refined our design and development practice so that it’s more suited to a fluid, messy medium.

As we emerge from this period of enlightenment, we need to consolidate our learning and consider how we build upon it.

A responsive framework

When we think of frameworks, we often imagine software libraries and other abstractions concerned with execution and code. But this type of framework distances us from the difficulties we face designing for the medium. Last year, when Ethan spoke about the need for a framework, he proposed one focused on our approach—a framework to help us model ongoing discussion and measure the quality and appropriateness of our work.

I believe we can conceive this framework by first agreeing on a set of underlying design principles. You may be familiar with the concept. Organizations like GOV.UK and Google use them to define the characteristics of their products and even their organizations. Kate Rutter describes design principles as:

…short, insightful phrases that act as guiding lights and support the development of great product experiences. Design principles enable you to be true to your users and true to your strategy over the long term. (emphasis mine)

The long-term strategy of the web is to enable universal access to information and services. This noble goal is fundamental to the web’s continued relevance. Our design principles must operate in the service of this vision, addressing:

  • Our users: By building inclusive teams that listen to—and even work alongside—users, we can achieve wider reach.
  • Our medium: By making fewer assumptions about context and interface, focusing more on users’ tasks and goals, we can create more adaptable products.
  • Ourselves: By choosing tools that are approachable, simple to use, and open to change, we can elicit greater collaboration within teams.

Reflecting diversity in our practice

In surveying the landscape of web-enabled devices, attempting to categorize common characteristics can prove foolhardy. While this breadth and fluidity can be frustrating at times, device fragmentation is merely a reflection of human diversity and consumers exercising their right to choose.

Until recently, empathy for consumers has largely been the domain of user experience designers and researchers. Yet while a badly designed interface can adversely effect a site’s usability, so can a poorly considered technology choice. We all have a responsibility to consider how our work may affect the resulting experience.

Designing for everyone

Universal design promotes the creation of products that are usable by anyone, regardless of age, ability, or status. While these ideas enjoy greater recognition among architects and product designers, they are just as relevant to our own practice.

Consider OXO Good Grips kitchen utensils. In 1989, Sam Farber, inspired by his wife’s arthritis, redesigned the conventional vegetable peeler, replacing its metal handles with softer grips. Now anyone, regardless of strength or manual dexterity, could use this tool—and Farber’s consideration for aesthetics ensured broader appeal as well. His approach was applied to a range of products; Good Grips became an internationally recognized, award-winning brand, while Farber’s company, OXO, went on to generate significant sales.

This work brought the concept of inclusive design into the mainstream. OXO remains an advocate of designing inherently accessible products, noting that:

When all users’ needs are taken into consideration in the initial design process, the result is a product that can be used by the broadest spectrum of users. In the case of OXO, it means designing products for young and old, male and female, left- and right-handed and many with special needs.

Many of the technologies and specifications we use already feature aspects of universal design. Beyond specifications like WAI-ARIA that increase the accessibility of dynamic interfaces, HTML has long included basic accessibility features: the alt attribute allows authors to add textual alternatives to images, while the object element allows fallback content to be provided if a particular media plug-in or codec isn’t available.

Examples can also be found within the W3C and WHATWG. A key principle used in the design of HTML5 concerns itself with how authors should assess additions or changes to the specification. Called the priority of constituencies, it states that:

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.

We can use this prioritization when making choices on our own projects. While a client-side MVC framework might provide a degree of developer convenience, if it means users need to download a large JavaScript file before an application can be accessed, then we should look for an alternative approach.

Bridging the gap

When makers are attached to high-resolution displays and super-fast broadband connections, it can be difficult for them to visualize how users may experience the resulting product on a low-powered mobile device and an unreliable cellular network. The wider the gap between those making a product and those using it, the greater the likelihood that the former will make the wrong choice. We must prioritize getting closer to our users.

User research and usability testing help us see how users interact with our products. Having different disciplines (developers, interface and content designers, product managers) participate can ensure this learning is widely shared. But we can always do more. Susan Robertson recently wrote about how spending a week answering support emails gave her new insights into how customers were using the application she was building:

Rather than a faceless person typing away on a keyboard, users become people with names who want to use what you are helping to create.

Having the entire team collectively responsible for the end experience means usability and accessibility considerations will remain key attributes of the final product—but what if that team is more inclusive, too? In her article “Universal Design IRL,” Sara Wachter-Boettcher notes that:

[T]he best way to understand the audiences we design for is to know those audiences. And the best way to know people is to have them, with all their differences of perspective and background—and, yes, age and gender and race and language, too—right alongside us.

Perhaps it’s no coincidence that as we learn more about the diversity of our customers, we’ve started to acknowledge the lack of diversity within our own industry. By striving to reflect the real world, we can build more empathetic and effective teams, and in turn, better products.

Building on adaptable foundations

By empathizing with users, we can make smarter choices. Yet the resulting decisions will need to travel across unreliable networks before being consumed by different devices with unknown characteristics. It’s hard to make decisions if you’re unable to predict the outcomes.

By looking at websites through different lenses, we can uncover areas of constraint that offer the greatest degree of reach and adaptability. If an interface works on a mobile device, it’ll work on a larger display. If data can be interrogated when there’s no network, an unreliable connection will be of little hindrance. If content forms the basis of our design, information will be available regardless of styling. Optimizations based on more uncertain assumptions can be layered on afterwards, safe in the knowledge that we’ve provided fallbacks.

Interface first

In 2009, Luke Wroblewski asked us to consider how interfaces could take advantage of mobile device capabilities before thinking about their manifestation in desktop browsers. Mobile-first thinking encourages us to focus: phone displays leave little room for extraneous interface or content, so we need to know what matters most. By asking questions about which parts of an interface are critical and which are not, we can decide whether those non-critical parts are loaded conditionally or lazily—or perhaps not at all.

Network first

In 2013, in considering the realities of network reliability, Alex Feyerke proposed an offline-first approach. Rather than treat offline access as an edge case, we can create seamless experiences that work regardless of connectivity—by preemptively downloading assets and synchronizing data when online, and using aggressive caching and client-side computation when not. Others have suggested starting with URLs or an API-first approach, using these lenses to think about where content lives within a system. Each approach embraces the underlying fabric of the web to help us build more robust and resilient products.

Content first

In 2011, Mark Boulton signaled a move away from our canvas in approach, to one where layouts are designed from the content out. By defining visual relationships based on page elements, and using ratios instead of fixed values, we can imbue a page with connectedness, independent of its dimensions.

Recognizing that having content available before we design a page can be an unreasonable request, Mark later suggested we consider structure first, content always. This fits in well with the Core Model, an idea first introduced by Are Halland at the IA Summit in 2007. By asking questions about a site’s core content—what task it needs to perform, what information it should convey—we can help clients think more critically about their strategic objectives, business goals, and user needs. Ida Aalen recently noted:

The core model is first and foremost a thinking tool. It helps the content strategist identify the most important pages on the site. It helps the UX designer identify which modules she needs on a page. It helps the graphic designer know which are the most important elements to emphasize in the design. It helps include clients or stakeholders who are less web-savvy in your project strategy. It helps the copywriters and editors leave silo thinking behind and create better content.

Sharing the toolbox

Having empathized with our users and navigated an unpredictable medium, we need to ensure that our decisions and discoveries are shared across teams.

As responsive design becomes embedded within organizations, these teams are increasingly collaborative and cross-functional. Previously well-defined roles are beginning to merge, the boundaries between them blurring. Job titles and career opportunities are starting to reflect this change too: see “full-stack developer” or “product designer.” Tools that were once the preserve of specific disciplines are being borrowed, shared, and repurposed; prototyping an animation may require writing JavaScript, while building a modular component library may require understanding visual language and design theories.

If the tools used are too opaque, and processes difficult to adopt, then opportunities for collaboration will diminish. Make a system too complex, and onboarding new members of a team will become difficult and time-consuming. We need to constantly make sure our work is accessible to others.

Considerate code

The growing use of front-end style guides is one example of a maturing relationship between disciplines. Rather than producing static, bespoke layouts, designers are employing more systematic design approaches. Front-end developers are taking these and building pattern libraries and modular components, a form of delivery that fits in better with backend development approaches.

Component-driven development has seen a succession of tools introduced to meet this need. Tools like Less and Sass allow us to modularize, concatenate, and minify stylesheets, yet they can also introduce procedural functionality into CSS, a language deliberately designed to be declarative and easier to reason with. However, if consideration is given to other members of the team, this new functionality can be used to extend CSS’s existing declarative feature set. By using mixins and functions, we can embed a design language within code, and propagate naming conventions that are understood by the whole team.

Common conventions

Quite often, problems of process are not a limitation of technology, but an unwillingness to apply critical thought. Trying to solve technology problems by employing more technology ignores the fact that establishing conventions can be just as helpful, and easier for others to adopt.

The BEM naming methodology helps CSS styles remain scoped, encapsulated, and easier to maintain, yet this approach has no dependency on a particular technology; it is purely a set of documented conventions. Had we foreseen the need, we could have been using BEM in 2005. A similar convention is that of CSS namespaces, as advocated by Harry Roberts. Using single-letter coded prefixes means everyone working on a project can understand the purpose of different classes, and know how they should be used.

A common complaint for those wishing to use software like preprocessors and task runners is that they often require knowledge of the command line. Tools tease new recruits with one-line install instructions, but the reality often involves much hair-pulling and shaving of yaks. To counter this, GitHub created Boxen, a tool that means anyone in their company can run a local instance of on their own computer by typing a single command. GitHub, and other companies like Bocoup and the Financial Times, also advocate using standard commands for installing, testing, and running new projects.

Responsive principles, responsive to change

Since responsive web design invited us to create interfaces that better meet the needs of users, it’s unsurprising that related discussion has increasingly focused on having greater consideration for users, the medium, and each other.

If we want to build a web that is truly universal, then we must embrace its unpredictable nature. We must listen more closely to the full spectrum of our audience. We must see opportunities for optimization where we previously saw barriers to entry. And we must consider our fellow makers in this process by building tools that will help us navigate these challenges together.

These principles should shape our approach to responsive design—and they, in turn, may need to adapt as well. This framework can guide us, but it, too, should be open to change as we continue to build, experiment, and learn.

Multimodal Perception: When Multitasking Works

 ∗ A List Apart: The Full Feed

Word on the street is that multitasking is impossible. The negative press may have started with HCI pioneer Clifford Nass, who published studies showing that people who identify as multitaskers are worse at context switching, worse at filtering out extraneous information, worse at remembering things over the short term, and have worse emotional development than unitaskers.

With so much critical attention given to multitasking, it’s easy to forget that there are things our brains can do simultaneously. We’re quite good at multimodal communication: communication that engages multiple senses, such as visual-tactile or audio-visual. Understanding how we process mixed input can influence the design of multimedia presentations, tutorials, and games.

When I began researching multimodal communication, I discovered a field brimming with theories. The discipline is still too new for much standardization to have evolved, but many studies of multimodality begin with Wickens’s multiple resource theory (MRT). And it’s that theory that will serve as a launch point for bringing multimodality into our work.

Wickens’s multiple resource theory

Luckily, Wickens saved us some heavy lifting by writing a paper summarizing the decades of research (PDF) he spent developing MRT. Its philosophical roots, he explains, are in the 1940s through 1960s, when psychologists theorized that time is a bottleneck; according to this view, people can’t process two things simultaneously. But, Wickens explains, such theories don’t hold up when considering “mindless” tasks, like walking or humming, that occupy all of a person’s time but nevertheless leave the person free to think about other things.

Several works from the late 1960s and early 1970s redefine the bottleneck theory, proposing that what is limited is, in fact, cognitive processing power. Following this train of thought, humans are like computers with a CPU that can only deal with a finite amount of information at once. This is the “resource” part of MRT: the limitation of cognitive resources to deal with incoming streams of information. (MRT thus gives credence to the “mobile first” approach; it’s often best to present only key information up front because of people’s limited processing power.)

The “multiple” part of the theory deals with how processing is shared between somewhat separate cognitive resources. I say somewhat separate because even for tasks using seemingly separate resources, there is still a cost of executive control over the concurrent tasks. This is again similar to computer multiprocessing, where running a program on two processors is not twice as efficient as running it on one, because some processing capacity must be allocated to dividing the work and combining the results.

To date, Wickens and others have examined four cognitive resource divisions.

Processing stage

Perception and cognition share a structure separate from the structure used for responding. Someone can listen while formulating a response, but cannot listen very well while thinking very hard. Thus, time-based presentations need ample pauses to let listeners process the message. Video players should have prominent pause buttons; content should be structured to include breaks after key parts of a message.

Visual channel

Focal and ambient visual signals do not drain the same pool of cognitive resources. This difference may result from ambient vision seemingly requiring no processing at all. Timed puzzle games such as Tetris use flashing in peripheral vision to let people know that their previous action was successful—the row was cleared!—even while they’re focusing on the next piece falling.

Processing code

Spatial and verbal processing codes use resources based in separate hemispheres of the brain. This may account for the popularity of grid-based word games, which use both pools of resources simultaneously.

Perceptual modes

It’s easier to process two simultaneous streams of information if they are presented in two different modes—one visual and one auditory, for example. Wickens notes that this relative ease may result from the difficulties of scanning (between two visual stimuli) and masking (of one auditory stimulus by another) rather than from us actually having separate mental structures. Tower defense games are faster paced (and presumably more engaging) when accompanied by an audio component; players can look forward to the next wave of attackers while listening for warning signals near their tower base. Perceptual modes is the cognitive division most applicable to designing multimedia, so it’s the one we’ll look at further.

A million and one other theories

Now that we’ve covered Wickens’s multiple resource theory, let’s look at some of the other theories vying for dominance to explain how people understand multimodal information.

The modality effect (PDF) focuses on the mode (visual, auditory, or tactile) of incoming information and states that we process incoming information in different modes using separate sensory systems. Information is not only perceived in different modes, but is also stored separately; the contiguity effect states that the simultaneous presentation of information in multiple modes supports learning by helping to construct connections between the modes’ different storage areas. An educational technology video, for instance, will be more effective if it includes an audio track to reinforce the visual information.

This effect corresponds with the integration step of Richard Mayer’s generative theory of multimedia learning (PDF), which states that we learn by selecting relevant information, organizing it, and then integrating it. Mayer’s theory in turn depends upon other theories. (If you’re hungry for more background, you can explore Baddeley’s theory of working memory, Sweller’s cognitive load theory, Paivo’s dual-coding theory, and Penney’s separate stream hypothesis.) Dizzy yet? I remember saying something about how this field has too many theories…

What all these theories point to is that people generally understand better, remember better, and suffer less cognitive strain if information is presented in multiple perceptual modes simultaneously. The theories provide academic support for incorporating video into your content, for example, rather than providing only text or text with supporting images (says, ahem, the guy writing only text).

Visual-tactile vs. visual-auditory communication

Theories are all well and good, but application is even better. You may well be wondering how to put the research on multimodal communication to use. The key is to recognize that certain combinations of modes are better suited to some tasks than to others.


Use visual-tactile presentation to support quick responses. It will:

  • reduce reaction time
  • increase performance (measured by completion time)
  • capture attention effectively (for an alert or notification)
  • support physical navigation (by vibrating more when you near a target, for example)


Use visual-auditory presentation to prevent errors and support communication. “Wait, visual-auditory?” you may be thinking. “I don’t want to annoy my users with sound!” It’s worth noting, though, that one of the studies (PDF) found that as long as sounds are useful, they are not perceived as annoying. Visual-auditory presentation will:

Mode combination

You might also select a combination of modes depending on how busy your users are:

  • Visual-tactile presentation is more effective with a high workload or when multitasking.
  • Visual-auditory presentation is more effective with a single task and with a normal workload.

Multimodal tension

A multimodal tug-of-war goes on between the split-attention effect and the redundancy effect. Understanding these effects can help us walk the line between baffling novices with split attention and boring experts with redundancy:

  • The split-attention effect states that sequential presentation in multiple modes is bad for memory, while simultaneous presentation is good. Simultaneity helps memorization because it is necessary to encode information in two modes simultaneously in order to store cross-references between the two in memory.
  • In contrast, presenting redundant information through multiple channels simultaneously can hinder learning by increasing cognitive load without increasing the amount of information presented. Ever try reading a long quote on a slide while a presenter reads the same thing aloud? The two streams of information undermine each other because of the redundancy effect.

Which effect occurs is partially determined by whether users are novices or experts (PDF). Information that is necessary to a novice (suggesting that it should be presented simultaneously to avoid a split-attention effect) could appear redundant to an expert (suggesting that it should be removed to avoid a redundancy effect).

Additionally, modality effects appear only when limiting visual presentation time. When people are allowed to set their own time (examining visual information after the end of the auditory presentation), studied differences disappear. It is thus particularly important to add a secondary modality to your presentation if your users are likely to be in a hurry.

Go forth, multiprocessing human, and prosper

So the next time you hear someone talking about how multitasking is impossible, pause. Consider how multitasking is defined. Consider how multiprocessing may be defined separately. And recognize that sometimes we can make something simpler to learn, understand, or notice by making it more complex to perceive. Sometimes the key to simplifying presentation isn’t to remove information—it’s to add more.

And occasionally, some things are better done one after another. The time has come for you to move on to the next processing stage. Now that you’ve finished reading this article, you have the mental resources to think about it.

On Our Radar: Continued Change

 ∗ A List Apart: The Full Feed

The Ada Initiative, which has long supported women in technology through workshops, discussions, and networking, is shutting down this fall. We’re sad to see them go, but grateful for the valuable role they’ve played in our communities, particularly in advocating for codes of conduct.

A woodcut image of Ada Lovelace.

Best of luck to their founders and supporters in their new ventures, and to everyone who will carry on the organization’s work in other venues. Their training materials are (or soon will be) available under Creative Commons Attribution Sharealike licenses, and there are many resources for continued efforts in their heartfelt and gracious goodbye.

Your weekend reading

  1. “It’s as though someone dumped a shipping container worth of LEGO on the floor and we’re working out what to make.” Ben Evans connects the dots on how smartphones change everything. —Jeffrey Zeldman, founder and publisher
  2. Planning and pricing complex software projects is hard, so I loved reading Darren Petersen’s take on how the Lullabot team estimates project budgets using ranges, confidence levels, and input from multiple people. I really appreciate that they shared their formula-filled spreadsheet so I can try out these concepts on my own projects! —Aaron Parkening, project manager
  3. In an article examining online accessibility for people with disabilities, s.e. smith calls the internet “one of our greatest post-ADA social failings.” New inventions like Dot, a Braille-based smartwatch, are fascinating and promising—but there’s a lot more work to be done (especially when we consider the range of disabilities that affect all of us). We need to think more inclusively from the start so that the internet is more than a “wasted promise.” —Lisa Maria Martin, issues editor
  4. “How come so few women are speaking at this conference?” The type community is starting to put pressure on this question—loudly and publicly. An important conversation unfolded recently on Twitter—the best place for such dialogue, in my opinion. —Caren Litherland, editor
  5. Last month, Chris Coyier invited people on Twitter to answer the question: “Front-end development is hard because _________.” The responses varied widely, and Geoff Graham helpfully brought them all together in a post on CSS-Tricks. —Anna Debenham, technical editor

Your must-see hashtag


Overheard in ALA Slack

“Look, maybe I am processing some feelings, okay? Maybe some browsers are emotionally unavailable.”

Your Friday gif

An animated gif from the movie 'Wet Hot American Summer,' showing a boy with glasses saying, 'You have definitely cast a level 5 charm spell on me.'

Reliably hosted by