Category Archives: User Experience

Bootstrap CSS

I’ve been using Twitter’s Bootstrap in an internal project at VitalSource for a few months, and over the weekend I finally switched to using the CSS framework in Tweet Marker too. The layout now works in more browsers and provides a much better foundation for design changes. It also allowed me to integrate this excellent date picker.

Here’s a short screencast video showing the date picker in a new browsing feature in Tweet Marker Plus. I’m very happy with how this turned out — both the look and functionality. On the server the date ranges are implemented with a Sphinx query, so they can be combined with search terms to help find old tweets.

Saved tweet filters

When I created “Tweet Marker Plus”:, I thought I was creating a new way to search Twitter. Limit the search to just people you follow and you can store more tweets, and more relevant ones. But as I’ve been adding new features to it, I’m realizing that Tweet Marker Plus is really a new kind of Twitter client — a client that has search and filters at its core.

Here’s what the sidebar looks like in my Tweet Marker Plus account:

saved filters

Seems simple enough. But quickly switching between saved filters is very powerful. Because Tweet Marker is routinely fetching new tweets in the background, even when you haven’t opened your web browser in days or weeks, there are no gaps in the timeline. When I use a filter, it’s showing me everything that any of the people I follow have said since I first started using Tweet Marker Plus.

I’m excited about this. I’ll keep adding features and growing the storage, to make Tweet Marker Plus the best value $2/month could possibly get you.

10 years and 37signals

Every year on March 9th, as SXSW is getting started, I like to mark the anniversary of this blog. This time it’s the 10th year.

“My second post back in 2002”: was about a panel run by 37signals. I wrote:

“Ernest and Jason really get it — I hope they inspire some designers to think about web sites in a new way, and finally start focusing on usability and page load time and cut the fancy graphics, roll-overs, and animations.”

This was a couple years before they reinvented themselves as a software company with Basecamp. As the “new Basecamp launches this week”:, it’s fascinating to think back on how far 37signals has come. The web is bigger now and more complex. Subscription web apps are everywhere. But I think the focus on performance that drove Jason Fried and his original co-founders to promote simple design in that SXSW panel a decade ago is still very much at the heart of what 37signals does.

The Daily

“David Barnard chimes in”: on The Daily:

“The carousel is a fun bit of UI (at least in theory, it’s still a bit laggy and jittery for my taste), but there’s just no way to quickly deliver enough content to make the carousel usable. The front page and table of contents, on the other hand, could likely be fully delivered in the 4-5 seconds from the launch of the app to the end of the launch animation. Sending users directly to the front page (or potentially a redesigned table of contents, but I wont get into that) will make it feel as though the app has been magically filled with content.”

David makes some great points. Put another way, if some of their design decisions were too ambitious for their technical plumbing to keep up with, they should update the design and optimize it for speed. With such a mainstream app, though, you can’t really win. I’m sure if it was only fast and not fancy, it would have been criticized as too bland.

The initial criticism of “The Daily”: always seemed overblown to me. It’s not perfect, but they got some of the difficult things right: navigation that makes sense, original content, good layout, clear subscription model.

Off and on for the first few weeks, I would read several articles each day in The Daily. There were a couple crashes and glitches, but nothing that made the app unusable. If no one else had been complaining, I’m not sure I would have noticed anything so wrong it was worth mentioning.

They can make it faster and polish up the rough edges over a few subsequent bug fix releases. And maybe enough of the fundamentals are right that they can get pretty far even without the design changes David suggests.

Now that I’ve “written a few e-book apps”:, I can say with certainty that getting the basics right is more challenging than it looks. Other traditional companies moving their content to the iPad have launched much farther off-course than The Daily.


After about a day of using Tweetbot, “I said”:

“Tweetbot gets nearly everything in the UI right. Love it. But.. it’s a basic client. I still think the future for third parties is features.”

I only got a few responses, most defending Tweetbot as something special. I agree, and there’s a lot to be inspired by from it. In an odd way, though, just being the best Twitter client isn’t enough.

“Marco Arment writes more”: (following a “post from Ben Brooks”: about why Tweetbot isn’t for him despite being such a good client:

“A new Twitter client that essentially offers the Twitter app’s features, but in different places, isn’t enough of a difference for me to switch. If anything, it supports Twitter’s ‘don’t make full-featured apps’ position. Maybe they were right.”

The problem isn’t that third parties shouldn’t make full-featured clients; it’s that they shouldn’t make clients that have exactly the same features as every other client. If Twitter discourages all apps from being made just because many will fail, we’ll miss out on all the things Twitter will never add to their apps and platform.

I see three compelling reasons to use Tweetbot 1.0: the design, swipe for conversations, and related tweets. The last is actually in the Twitter API — I’ve been meaning to add it to Tweet Library — but it’s not yet documented outside of an email message to the dev mailing list. Congrats to Tapbots for being the first I’ve seen to add it as a high-profile feature.

Last September I wrote about “next-generation Twitter apps”:

“I believe we’re about to see a third generation of clients that will go way beyond what the web site can do. There was worry when Twitter bought Tweetie that it would destroy the third-party Twitter market, and sure, some developers will fail or be discouraged from trying to compete against a free official product. But really what it does is raise the bar — that to succeed Twitter clients should be more than just a one-to-one mapping between UI and the Twitter API.”

I hadn’t announced Tweet Library yet when I wrote that. Now that I’ve shipped it, I believe even more strongly that we haven’t seen anything yet from Twitter apps. Tweetbot is a great 1.0 and my go-to app on the phone because it’s better in lots of small ways than anything else. But that it’s not for everyone is actually great news. I hope there are plenty of unique features still to come from a variety of other apps.

Consider this: Tweetie already “won” the market. No matter what we do as Twitter API developers, none of us can ever have the most popular Twitter app. This frees every app to focus on its core strength. For Twitterrific, that’s a unified timeline; for Echofon, that’s last-read sync; for Hibari, that’s keywords; for Kiwi, that’s themes; for my own Tweet Library, that’s curation.

What’s Tweetbot’s core strength? For now, overall user experience, not standout features. But I’ve been a Tapbots customer long enough that I’m excited to see where they take it.

For more Tweetbot discussion, check out “this collection of tweets I made”: about the launch.

Tweet Library filters

“John Chandler wrote a nice post”: on the filters he uses in various Twitter apps. Here’s a clever one for “you missed it”:

“I try to limit how many people I follow so I can read most of what they say. So, if they preface a tweet with something like ‘If you missed it,’ or ‘In case you missed it,’ I probably didn’t.”

As I mentioned in the comments, I have a few filters I like too, such as filtering out all old-style RTs. I even experimented with filtering out all hashtags. It’s great when I want to completely un-clutter the timeline of gimmicky tweets, but I can keep the filter toggled off when I have more time to read.

The advantage of how I built filters in “Tweet Library”: is that they are dynamic collections inside the app, kind of like smart playlists in iTunes. This means while it filters the junk out of my timeline, I can still occasionally go and review what it filtered out.

(I just submitted Tweet Library 1.2.1 to the App Store with a handful of bug fixes. Hopefully it’ll be approved soon.)

Next generation Twitter apps

I’ve been thinking about and playing with the official Twitter app for iPad since its release last week. The best praise I can give Loren Brichter and his team for the UI “stacking” breakthrough is: I wish I had thought of it.

But it’s clear after an informal survey of friends, and listening to folks on Twitter, that the UI might be too clever for its own good. Many people can’t quite figure out if they love it or hate it. And on top of the UI risk, Twitter for iPad doesn’t bring any new features to the table.

Third-party Twitter clients won’t be wiped out by this. So now what?

The first Twitter clients (led by Twitterrific for Mac) provided a quick way to check on your friends without visiting the web site. The second batch of Twitter clients (mostly on mobile) provided a full replacement for the site.

I believe we’re about to see a third generation of clients that will go way beyond what the web site can do. There was worry when Twitter bought Tweetie that it would destroy the third-party Twitter market, and sure, some developers will fail or be discouraged from trying to compete against a free official product. But really what it does is raise the bar — that to succeed Twitter clients should be more than just a one-to-one mapping between UI and the Twitter API.

One feature is filtering. “TweetAgora for iPhone”: has muting and an interesting live aggregation view, like a client-side extension of Twitter lists. “Hibari for Mac”: recently shipped with an attractive UI and keyword filtering, muting, and integrated search results.

And there’s other stuff I want to see, like archiving tweets and better search and curation beyond simple favorites. I’ve been working on some of these too, in a brand new iPad app for Twitter. I can’t wait to share the details as it gets closer to release.

Not unlike “Marco’s post on the subject”:, my hope is that free apps and paid apps compete in separate worlds of the App Store. When Twitter for iPad shipped it jumped to the number 1 spot in free apps, but maybe you don’t have to compete directly with that. Maybe if you hold your ground somewhere in the top paid list, that’s enough to find an audience.

NetNewsWire production process

I like “this Flickr set from Brent Simmons”: showing the stages of building NetNewsWire for the iPad. It’s exactly the process I’m going through right now with my new app. Get some placeholder views and tables in there, then iterate, each time filling in more of the missing pieces.

iPad interface design is also proving to be much more difficult than I thought it would be. Concepts that work on the iPhone don’t necessarily translate to the larger device, and there are very few iPad apps to draw inspiration from. There’s no standout app from Apple’s lineup either, at least not in the way that iTunes 1.0 defined nearly every Mac app to follow. With the exception of some very basic ideas like splitviews collapsing in portrait mode, and a generous sprinkling of popovers, I’ve yet to see much consistency from new touch apps.

Apps that have had the biggest influence on me so far: from the iPhone, Birdfeed and Pastebot; and on the iPad, Mail and Twitterrific. Send me a reply “on Twitter”: if you have any other recommendations.

Clipstart is not iPhoto

I get a lot of great feedback about “Clipstart”: There’s value in almost every feature request, even the ones I don’t plan to directly implement. Some people also suggest that I should copy more from iPhoto. While I understand this — they want a familiar interface — it has always been my goal to be different than iPhoto. Why?

Two main reasons:

  • iPhoto never quite worked for me, and only by being different can you hope to be better. I took a few things that iPhoto did poorly (like tagging, video playback, and upload) and built the entire interface around them.

  • If I just created a clone of iPhoto but for videos, Apple could expand the video support in iPhoto one day and I would be left with nothing. If my app grows in a completely different direction, however, then even if they add video support to iPhoto my app will still appeal to people who aren’t satisfied with iPhoto’s approach.

I know I’m on to something because when I show the app to a certain type of person (who has thousands of short videos, or no quick way to share them) their eyes light up. It’s now just a matter of pumping out new versions to refine the interface and fill in the missing pieces. I have major features planned for the next few dot release (1.4, 1.5, and 1.6) to try to give customers as much value as I can, and execute on the potential for the application.

Both Aperture 3 and Lightroom 3 now have video support, but I’m not too worried. There’s plenty of room between iLife and $199/$299 for Clipstart to carve out a customer base.

iPad commercial

When “the iPad commercial”: popped up during the Oscars, I thought it captured the power and elegance of the device extremely well. But as I commented on Twitter, after repeat viewings you can see that it’s probably faked. The iPad must have been filmed on a stand or table and then composited into the shot later.

Contrast this to “Cabel Sasser’s”: video of the Nintendo DS Lite, which was a faithful presentation of how the game system feels to use and yet still “sold people on the device”:

Apple stretches the truth with all the iPod and iPhone ads and it never bothered me before, but this one seems wrong. How it feels to hold an iPad will be the difference between a good product and a great one. Can you hold it still with one hand? How easy is it to rotate it? What is the angle like when propping it on your legs?

This is a pretty minor complaint — I’ll be pre-ordering my iPad this Friday regardless and couldn’t be more excited — but I wish Apple didn’t feel the need to lie about such an important part of the product.

Removing features

“Lukas Mathis writes”: about removing features:

“You don’t _have_ to try to please everybody and eventually create an application that is liked by nobody. In fact, since your users are in all likelihood in a situation where they can switch applications easily, and since they probably are not locked in by the need to open a specific file format in its native application, it might be a really bad idea for you to go down the ‘simply add up all the requested features’ route of application design.”

He also links to “my Wii Transfer survey”:, so I thought I’d post a quick follow-up. I eventually did remove a feature, and the survey to customers served as a nice sanity check that the feature wasn’t heavily used. The interesting part, to me, is that the feature I removed was the entire 1.0 product for Wii Transfer. Literally everything that 1.0 did is now gone.

It’s been two weeks so far without any complaints. I like to think that it removes a distraction from the app — one less place in the app that could lead the customer down the wrong path. And hopefully it’ll eliminate a tiny part of my support load, as no one can ask me questions or have problems with that feature again!

On an internal company mailing list I once wrote:

“Products that don’t exist yet have a way of attracting new features because everyone sees the potential in something that has no form”.

I was talking about resisting the urge for everyone on the team to pile on their favorite features before 1.0, but I think this applies to apps with a minimal design as well. A simple app shows promise. A cluttered app with too much going on looks “done”, and sends a message that it is mature and maybe going in a different direction than what the user wants. In that way, the irony is that removing features (the wrong features) may actually make an application more appealing to new users.

Clipstart duplicates

Clipstart 1.0 tried to be smart about not importing videos that were already in your library, but it stopped short of actually giving you much control over whether to import duplicates or ignore them. I also felt like the window showing duplicates could be improved to provide more information about each file. At a glance you should be able to tell if Clipstart is doing the right thing.

So I put a lot of effort into this for the soon-to-be-released Clipstart 1.2.4, and the result is this window:

Duplicates dialog

It generates a few frames of the timeline for each video (both old and new file side by side), which turns out to be an excellent way to confirm that they are indeed the same file, and also shows the original filename even after Clipstart (or the user) has renamed it. Now I can scan through the window in about 2 seconds and I’m done. Contrast with iPhoto which prompts after each video is imported, instead of at the end of the batch, and if you blindly trust it by checking “Apply to all duplicates” then you have no feedback on whether you made the right choice.

The new duplicates window works with both volume-based cameras like the Flip and SD cards, as well as USB devices such as the iPhone 3GS and iPod Nano. I hope to ship version 1.2.4 soon, and there’s a “beta in the forums”:

Update: As pointed out by a customer, Ignore and Keep are actually pretty confusing verbs here. I’ve changed it to “Skip Duplicates” and “Import Duplicates” for the final release.

It’s like iTunes for…

Sometimes it seems like every app is trying to be “the iTunes for <insert subject here>”. I’ve worked on “an app that fits into this category”:, and there are countless more. iTunes 1.0 represents one of the biggest shifts in Mac user interface design we’ve seen — single window, source list, and smart groups.

While the iTunes UI is great for music, I’m not convinced it’s automatically great for all workflows.

“Clipstart”: goes out of its way to do something different, by twisting the traditional source list a little to promote tags as the most important part of the UI. At first I feared that some customers would find it worse, that the UI would fail and I would be forced to become more iTunes-ish for the next version. But I think only by trying something different can you hope to be better. I’ve been using Clipstart to manage my movies all year and the tag-focused UI really works, especially when you start building up your library and can search and find related tags across all your videos.

I released Clipstart 1.1.1 a few days ago with a bunch of bug fixes, and an “iPhone 3GS giveaway”: too.

MobileMe UI

I’m extremely impressed by this UI from MobileMe. All web-based, of course.

MobileMe upload

Excellent progress feedback, great attention to detail… But then they nearly ruin it with “item(s)”.

A fan for your unreleased app

Every product needs a believer. Not on the product team, but outside. A champion beta tester. Someone who sees the potential and will offer such constructive criticism and feedback early on that if you don’t make the app perfect you will be personally letting them down.

This is so critical, that many products succeed or fail to reach 1.0 on this point alone. Without inspiration from your peers, it becomes difficult to push through “the dip”:, the rough times in development when everything goes wrong and you can’t imagine how your app will ever see the light of day. Seek out that one person — friend, spouse, blogger, anyone — who will light a fire under you to ship a quality product.

Yes, I want to hear how much you like my app, but I also want to hear where it fails and frustrates you.

The feedback I’ve received for “Clipstart”: is astonishingly well thought out and helpful. I like to think the app is attracting the best kind of customers: articulate and experienced enough to know what they want. If I could only implement half the suggestions to improve the app it will evolve into something great.

Of course, great beta testers only go so far. We still have to work really hard. “Merlin Mann said it best”: “The only person who can sit on your ass is you.”

Tab click-through areas

It’s often true that the further away you get from an event, like the release day for the Safari 4 beta, the closer you get to a fair analysis. Initial Twitter reaction was gut level and some not even based on anything but screen shots. “My own post”: was admittedly slightly half baked, but I think it stands up fine.

Now we are seeing some more thoughtful analysis, including from “Dan Frakes of Macworld”:, and “Lukas Mathis”:, and of course the thorough “John Gruber of Daring Fireball”:

I wanted to revisit one thing with click-through. If you eliminate the mouse rollovers and click-through for inactive tabs, you end up with surprisingly few places to accidentally click. Here are two screenshots illustrating the difference between Safari 4 and BBEdit.

Safari 4 tab example

It’s true that the file icon needs a hold-and-drag, so it’s harder to click, and the hide toolbar button is off to the side and less dangerous than closing a tab. Nevertheless, viewed by pixels alone there isn’t a significant difference between the safely clickable area of these two window title bars if Apple makes this small change.

Update: If I left too much to the imagination, here are examples of the real Safari 4 clickable areas, not the way I wish it would be above.


And the extreme example with even more tabs:

Safari 4 tab extreme

The important point is that if you disable click-through for inactive tabs, the safe area does not change even with dozens of tabs, and in my opinion it is only marginally worse than other standard Mac applications, as shown in the first two screenshots. The current Safari 4 behavior, on the other hand, continues to degrade until the window title bar is nearly useless.

Defending Safari 4 tabs

The first reaction most people had to Safari 4 — especially the new tabs interface — was negative. I’m here to defend it.

But first, let’s get the mistakes out of the way, because they are substantial. Safari 4 tabs have several new usability problems:

Clicks to close or drag in inactive tabs should not be allowed. As Daniel Jalkut pointed out on Twitter, these “landmines” decrease the available space to click when dragging a window. And the problem only gets worse as you add more tabs. It requires too much thinking before being able to drag a window. (You can bet Apple has research that shows most people only have 1 or 2 tabs open at a time, but nevertheless you are going to sometimes have a bunch.)

Click-through should not be enabled. Same point as above, but don’t allow closing tabs or clicking the drag handle when Safari is not the frontmost app. John Gruber has written extensively on this issue, and this post from 2003 is a good place to start.

Title bar font is different than every other app. I understand this decision, but it’s unnecessary for small numbers of tabs. If you have 1 or 2 or even 3 tabs open, there’s no reason not to use the full font size so that Safari’s title bar is consistent with other apps. It’s distracting.

Too subtle. Because nothing in the content area of the window changes, it’s easy to miss the tabs. They are in a more prominent place but somehow fade into the background. I’m not sure whether this is a good or bad thing yet, but I’m leaning toward bad.

There are other largely aesthetic complaints about the new tabs, such as how the default wider tabs look odd compared to previous versions of Safari, but a lot of that is just unfamiliarity and doesn’t point to a specific usability problem.

So why do I like what Apple is doing here? Because I’m hopeful that this is the first experiment to bringing system-provided tabs to applications.

Here’s what I wrote about this issue in 2005:

“Instead, Apple should have built upon Exposé to offer system-wide window grouping state, so that in any document-based application the user is in control of how windows are tabbed. Actions like dragging to rearrange tabs could be implemented once and work consistently across all applications.”

In the last 4 years the problem has only gotten worse. Developers are rolling their own tab solutions and there is no consistent behavior or keyboard shortcuts that I have seen. Worse, coding fully-featured tabs with the ability to drag windows in and out of a tab group is very difficult, and most apps don’t go that far.

The Safari 4 tabs are conceptually the right way to go. It’s not “tabs” at all. Instead, think of it as an efficient way to dock multiple windows together.

Getting the tabs out of the content area of the window is also the first real step to making this available to other developers. While I don’t think you should stamp this on to all applications, certain classes of document-based applications could “opt-in” to this new system and get it mostly for free, with consistent UI and behavior provided by the system. Developers who had special requirements or wanted a custom tab look-and-feel could continue to build their own tabs without worry that their UI would be interfered with.

I have no idea if this is the direction Apple is going in, but the Safari 4 design makes me think that at least someone at Apple has this in the back of their head.

App Store new version UI

Centralized app update notifications on the iPhone were a great idea, right? Turns out, maybe not. My App Store icon has a “26” badge on it. I have no idea which apps have a new version available until I click and scroll through the list, or use iTunes. The reality is that at least 3/4 of them are for apps I downloaded but don’t use very often. I now have to set aside some time to weed through this list of apps.

I’d much rather get a friendly reminder of a new version when I launch the app itself — maybe even outside the app’s control, near the top of the screen just like when a phone call is in the background. There are a few apps I use every day that were updated weeks ago, but I continued to use an old version because the notification was lost in the noise of dozens of other junk apps.

Tagging survey

Last month “I asked on Twitter”: for opinions on comma-delimited vs. space-delimited tagging. I didn’t get very many responses, but what I did get was pretty interesting.

Consensus: most people like commas and everyone likes Flickr. (The second takeaway here is that the service or app is more important, since Flickr uses spaces and everyone seems to cope just fine, even that 66% who prefer commas.)

Tag survey chart

You can see the “full report stats on Wufoo”:

Wil Shipley on bugs

From a “Wil Shipley post”: a few months ago:

“Software is written by humans. Humans get tired. Humans become discouraged. They aren’t perfect beings. As developers, we want to pretend this isn’t so, that our software springs from our head whole and immaculate like the goddess Athena. Customers don’t want to hear us admit that we fail.

“The measure of a man cannot be whether he ever makes mistakes, because he will make mistakes. It’s what he does in response to his mistakes. The same is true of companies.”

I’ve been thinking about mistakes and bugs as I beta test “Sifter”: Since it’s not ready for launch yet I won’t comment on it specifically, except to say that despite many bug systems becoming very mature (in some cases, too mature) every developer still has a different set of needs. There will always be a new bug system promising to fix all your problems, and for many of us we have to keep reminding ourselves not to code our own. Been there done that.