UIDickBar, An Awful Idea

Update

Problems underlying the UIDickBar are analyzed and concluded in here: Problems and the Solution for UIDickBar.
On March 31, 2011, Twitter removed the UIDickBar from their iPhone client version 3.3.3.

About

#dickbar, “Twitter’s mainstream consumer client experience,” now available for your iOS apps too.

Feedbacks

This project got lots of attentions since this morning (thanks, @justin), and here are some great retweets:

“Never laughed so hard at a GitHub page.” - @jordanekay
“UIDickBar is f-ing awesome!” - @lynkynpark86
“Awesome - you too can now easily drive your users mad/to other apps with no effort at all.” - @mdales
“This whole #dickbar thing is getting out of hand! (love the screenshots!)” - @lieven
“Want to kill your iOS app ? Here is UIDickbar.” - @romac17
“I’m laughing my ass of xD” - @smarag
“We really need one indeed, and then you can stick a UIDickBar anywhere in your app as easily as you would put a Share button.” - @damiendeville
“For the luvapete, don’t ever use this.” - @objectivec
“The best screenshot on Github.” - @stevestreza

And UIDickBar becomes the #1 trending repos within 24 hours, also the #1 featured repos on github.com.

Thanks again for all the warm welcome!

Thoughts

For those who want to create custom notification view, any forms of design similar to this are really bad idea, really, no kidding.

Because notification is a kind of interruption, it breaks the continuity. Unlike UIAlertView, UIDickBar uses disrupting way to interrupt information, and users feel confused when dealing with two different information flows at the same time. If you want to know more details about problems underlying the UIDickBar, read this.

Please think for your users before using it.

Requirement

iOS 4.0 or later (Sample project was created from by Xcode 4 GM 2)
Use LLVM Clang 2.0 compiler

Usage

You simply init UIDickBar with title, badge and an action block:

UIDickBar *dickBar = [[UIDickBar alloc] initWithDickTitle:@"#DickBar" dickBadge:@"Stupid" actionBlock:^{
    // Anything you want to do after UIDickBar tapped
    [[UIApplication sharedApplication] openURL:[NSURL URLWithString:@"http://digdog.tumblr.com"]];
}];
[dickBar showInView:self.view];
[dickBar release];

Then you call -showInView: to display UIDickBar that originates from the specified view.

Features

Look like real #dickbar.
No fancy animations.
Support rotation.
Support Blocks.
Use UIDickBar to get tons of one star reviews, priceless.

Where to Download

UIDickBar is available on github.

License

UIDickBar is released under MIT License.

Problems and the Solution for UIDickBar

Update

On March 31, 2011, Twitter removed the UIDickBar from their iPhone client version 3.3.3.

I try to analysis the problems underlying the UIDickBar, the design that Twitter recently used in their Twitter for iPhone.

It’s All About Timeline

Twitter is based on timeline, users have several different timelines on going asynchronously:

Tweets from whom user followed.
Tweets created by user.
Tweets mentioning user.
Retweets by others, by user, and user’s tweets that retweeted by others.
Lists by user or lists following user.
Searches.

How to Discover New Hash Tags

Twitter also has “Top Tweets” and “Trending Topics”, these are tweets and hash tags that users might/does not care about. However, Twitter gets money from clients to promote for them in Trending Topics’s promoted hash tags. They want users to know about these tweets and hash tags.

In what way? I think they tried before, for example:

We have trending hash tags listed in Tweetie’s search tab.
Later Tweetie got acquired by Twitter, they added the “Trending Now” horizontal UIScrollView in search tab to show the “Top Tweets”.

But non of them work to increase the visibility of promoted hash tags. Because when users want to do a search in twitter, he/she won’t happen and like to know current hot topics. Only when users want to know more about hot topics, then those promoted hash tags get a chance to be seen by users.

The Annoying UIDickBar Came to Rescue

Twitter is working really hard to address this issue, they want to increase the visibility rate of promote hash tags, and they comes out with this stupid idea: UIDickBar.

By using UIDickBar, they treat those trending hash tags as notifications, force people to receive them when browsing timeline. But turns out users feel annoying, why?

Trending hash tags are not always what people care about, and users are now forced to see them, annoying.
You won’t know what hash tag is about, unless you clicked it, and read it’s tweets in another timeline, second layer of annoying.
UIDickBar is semi-transparent, it makes covered tweet hard to read, very annoying.
UIDickBar covered latest tweet in timeline, and won’t goes away unless you scroll a bit. But it’s hard to read the timeline when scrolling, so you have to do it in two steps, scroll and read the latest tweet, which happened to be the thing user cares most, major annoying.
When dealing with notification, Apple uses UIAlertView, it interrupted current view on UIScreen, and become the top most view. So users are able to focus on the notification 100%, while leaving current view in behind. But UIDickBar isn’t, it acts like In-Call status bar, but instead of expending from UIStatusBar, UIDickBar floating on top of current view, showing along with the main information flow synchronously and disruptively, extreme annoying.

Think Again for the Notification

Just like I said previously, notification is a kind of interruption, it breaks the continuity.

Let’s take iOS for example, the original design of push/local notification is to let users to know something happened to the application that isn’t in running in the foreground. They are time-based events, interests that users should know right away regarding the states he/she is on.

And Twitter’s trending hash tags are not the time-based event. They do have the “trending” timing property, but they are not designed to notify user at specific time. They are just promoted items or popular items Twitter wants users to know. That’s the major different.

Possible Solution

So, how could Twitter address these terrible user experiences?

They should give up UIDickBar completely, and start treating trending hash tags in totally different way. Here’s my suggestion, go back to where Tweetie (or Twitterrific) did before:

Treat trending hash tags as tweets, mixing them into current timeline.
It doesn’t have to be in the tableViewHeader (leave it for UISearchBar and their famous pull-to-refresh), or at the bottom of the UIScreen (like iAd banner).
Trending hash tag will randomly appeared in the UITableView, as a special and similar looking UITableViewCell next to other tweets.
And there’s always a trending hash tag UITableViewCell in current visible rows, but not placed in the first row (first row is reserved for latest tweet).

There’re several advantages for this solution:

Users see trending hash tags among with other tweets, they’re merged into, not disrupted, the information flow.
Trending hash tags’ weight can be adjusted by changing the row position to make it closer to or away from the first row.
It will be like placement marketing in movies, actor who drinks coca-cola, not the stupid animation banner (UIDickBar) on TV shows’ corner says next show is coming up at 10pm.

Conclusion

By the time this article written, Twitter for iPhone 3.3.1 is out. They update dickbar default behavior to not overlap tweets in timeline. This is not helping anything. Unless they get rid of the dickbar completely, you will still feel annoying.

[digdog dig]; — UIDickBar, An Awful Idea

See, that’s what the app is perfect for.