Category: Design

Unread Counts

Published on by Nick Bradbury4 Comments

NetNewsWire creator Brent Simmons on unread counts:

Nick Bradbury, FeedDemon author, and I have talked many times over the years about how we’d design an RSS reader were we starting over. The first thing we always say: No unread counts!

It’s true: showing an unread count was something I regretted. It was one of many things I did to make FeedDemon work like an email client so it would seem familiar to new users. I’m sure it did make it seem familiar, but in the long run it was a mistake I never overcame.

Treating RSS like email makes it a chore to read, but customers were so used to FeedDemon working like an email client that any attempt to make it less email-like was met with resistance. So instead I came up with things like the Panic Button which were just band-aids that didn’t address the underlying problem.

Looking back, I wonder how RSS readers would’ve fared if their developers hadn’t followed the email client design. It’s partly because we did that the RSS reader (but not RSS itself) is now considered dead.

Broken by Design

Published on by Nick Bradbury4 Comments

When I was a kid, my parents had a table you couldn’t cut things on.

You also couldn’t set glasses on it without a coaster, and anything hot needed a pad under it. It was a beautiful table, but guests didn’t know this because it was covered with a table cloth for protection.

I was an annoying child, so I constantly pointed out how ridiculous this was. The purpose of a table was to eat and drink on, I would proclaim, yet this thing would be harmed by those actions. It was designed to look great without concern for how it would be used.

I’m reminded of that table by a lot of apps I see these days. They look stunning in videos, and the first time you use them you’re blown away by the beautiful animations. You almost feel like you’re using works of art.

But the more you use them the more annoyed you get because they’re designed to look great without thought for how they’d be used. Those mesmerizing transitions you used to love are now slowing you down. The layouts which used to seem so clean are now awkward because things are placed where they’d look the best instead of where they’d make the most sense.

They’re broken by design.

A few years ago a lot of software suffered from lack of design. Now it suffers from too much design. Surely there’s a happy middle ground where software can look and behave in delightful ways without undermining its purpose?

Optimistic Connectivity and Sleight of Hand

Published on by Nick Bradbury

A huge pet peeve of mine is mobile apps which make you to wait after you do something that requires a server API call. For example, you tap a “Like” button and are forced to look at a modal “Liking…” dialog that doesn’t go away until the app knows the like has been received by the backend.

Apps which do this are unnecessarily pessimistic about connectivity. Why make the user wait when the most likely outcome will be that the API call succeeds? I think it’s better for the app to show the new “Like” state immediately, and then deal with the rare failure in the background.

This optimistic approach is one that the folks at Instagram have touted, and I’ve followed it in all of my mobile apps.

Sometimes, though, you really do want to make the user wait, at least a little bit. In these cases, it’s often better to resort to sleight of hand which distracts the user instead of blocks them the way a modal dialog does.

I’ve found animation to be the most effective form of this trickery.

Suppose it really is important to make the user wait a couple of seconds after clicking a “Like” button to give the API call a little time. In this situation, animate the “like” button for a second or two – have it bounce, or spin, or zoom in and out.

Users will wait for the animation to end before doing something else in the app, and by the time the animation is done there’s a good chance the API call has completed. The user still waited, but because they waited by choice it doesn’t feel the same as being so obviously blocked by an annoying modal dialog.

PS: I should add that I only recommend this approach when making very lightweight requests. For heavier requests (especially ones that upload large amounts of data), a background service is a far better choice.