From Will Oremus’s insightful story How Facebook’s news feed algorithm works:

Facebook’s data scientists were aware that a small proportion of users—5 percent—were doing 85 percent of the hiding. When Facebook dug deeper, it found that a small subset of those 5 percent were hiding almost every story they saw—even ones they had liked and commented on. For these “superhiders,” it turned out, hiding a story didn’t mean they disliked it; it was simply their way of marking the post “read,” like archiving a message in Gmail.

This reminds me of a story I read a while back about how tons of people flagged and reported news stories about Lance Armstrong for “drug abuse”. This is why qualitative research is so incredibly important. Analytics can never tell us the whole story.

It’s interesting to see the web vs apps pendulum swing back to the web in recent months. From Larry Seltzer’s Can Web standards make mobile apps obsolete?:

What’s the alternative? Well, perhaps the best answer is to go back to the future and do what we do on desktop computers: use the Web and the Web browser. Updates to HTML apps happen entirely on the server, so users get them immediately. There’s no window of vulnerability between the release of a security fix and the user applying the update. So with a capable, HTML-based platform and a well-designed program that makes good use of CSS, one site could support phones, tablets, PCs, and just about anything else with one site.

The primary issue with moving back to the web is mainly what the web has become in recent years. As Maciej Cegłowski points out, we have a website obesity crisis. The talk (which you shoud definitely read) starts like this:

What do I mean by a website obesity crisis?

Here’s an article on GigaOm from 2012 titled “The Growing Epidemic of Page Bloat“. It warns that the average web page is over a megabyte in size.

The article itself is 1.8 megabytes long.

We can’t have it both ways, unfortunately. The only way that the web can become a better mobile platform than apps is if we take the obesity/performance crisis seriously. Otherwise the “it’s too slow!” argument will always win.

For an example of how this idea could work sensibly, see Addy Osmani’s excellent Getting started with Progressive Web Apps.

I just published my first article on UX Booth. For The Next Step for 3D Touch I did some digging on where we might be headed with the 3D Touch feature in the new iPhones. I got particularly fixated on the idea of reducing an app’s UI to only the icon on the home screen:

So what would happen if 3D Touch became an app’s main UI? What could happen if we created apps solely comprised of shortcut actions and dynamic actions—and nothing else?

Read on for more…

My latest column for A List Apart was published today. From The Analog Revolution:

So I wonder. I wonder what would happen if we felt the weight of responsibility a little more when we’re designing software. What if we go into a project as if the product we make might not only be done at some point, but might be something that lasts for a while? Would we make it fit into the web environment better, give it a timeless aesthetic, add fewer unnecessary features, and spend more time considering the consequences of our design decisions?

It’s not the best thing I’ve ever written, but I have to say, it’s one of my favorites. This is something I’ve been thinking about for a very long time, and to condense those thoughts into just over 1,000 words that include subtle references to The Hobbit and Zoolander feels pretty good.

Here’s some solid pragmatism from James Archer in Why is it so Easy to Get “Mobile First” Wrong?:

Mobile-first design isn’t, in itself, the right answer. It’s just an efficient answer. If you can design for one device and then tweak it to more or less function on other devices, you shave a lot of time off the design process. With the cornucopia of possible devices you’d otherwise have to design for, that’s definitely a good thing.

I find the common meme of “Oh, that’s ugly—a developer must have designed that” pretty misguided (and I’m not even a developer). The reason is that most developers I know have exceptional ideas (and taste). So these words from Marty Cagan really resonated with me:

I consider this mindset of the product owner (or more generally, the CEO or stakeholders) as the only one that can determine what to build, as toxic to teams, and a major reason for the lack of innovation. I’ve tried to explain many times that often the best single source of true innovation are our engineers. That doesn’t mean every engineer is going to be like this, but the mindset where no engineers can do this is a very serious problem. The engineers are working with the technology every day and are in the best position to see what’s just now possible. They are also disproportionately very bright people. When you combine this deep knowledge of technology, with a first-hand experience of the customer problems, great products can result.

“The best single source of true innovation are our engineers.” True that.

In my latest column for A List Apart, called The Distance to Here¹, I discuss a theory I’ve had for a while now:

The larger the distance between people who build a product and people who make decisions about the product, the harder it is to make a good product.

The post goes into detail on how I think companies can continue to make good products as they grow.

In Design Thinking Comes of Age Jon Kolko describes one of the biggest (and most important) shifts we’re starting to see in enterprise software:

To build empathy with users, a design-centric organization empowers employees to observe behavior and draw conclusions about what people want and need. Those conclusions are tremendously hard to express in quantitative language. Instead, organizations that “get” design use emotional language (words that concern desires, aspirations, engagement, and experience) to describe products and users. Team members discuss the emotional resonance of a value proposition as much as they discuss utility and product requirements.