[digdog dig];
I'm Ching-Lan HUANG (黃 青嵐), and this is my tumblr.
-
Browsers have now reached the maturity of 1950s American cars. They more or less work, still break too much, use too much fuel, and have lots of chrome and tailfins.
Slashdot: The Next FireFox UI
Comment by @Animates
-
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.
-
DDShareViewController and FrostyPlace 2
For those who want to see how DDShareViewController can be customized, now you can try FrostyPlace 2.0.
It’s a $0.99 RSS reader for frostyplace.com.
And I extended DDShareViewController to support Facebook, Twitter and Plurk at the same time. You can see how the word counts and title description placed in Twitter and Plurk view controllers, while Facebook view controller still kept the original privacy button.
Once I cleaned up the source code, I will commit the changes back to DDShareViewController project over github.
-
Proposal of a better Code Snippet Library for Xcode 4
By design, the bottom right corner of Xcode 4 is reserved for Libraries pane, which contains different libraries, includes:
- File Template Library
- Code Snippet Library
- Object Library
- Media Library
And each library has two different views: one is List View, provides detail description for each item, like title, summary, filename, etc.; the other is Icon View, which only shows the item icons.
Over Simplified Icon View
And it looks fine on most of the libraries, except the Icon View of Code Snippet Library:
As you can see, Code Snippet Library’s Icon View only has two kinds of icons, one default snippet, and the other is user custom snippet. Unlike other libraries, you can hardly tell the difference between each item in here:
The information of the snippet icon is insufficient.
However, you can’t just put the source code on top of the icon, that will be damn too ugly.
Proposal
To extend the existing concept (two code snippet icons, default snippet and user custom snippet), let’s check the snippet editor first:
If you look closer, the code snippet still has several metadata, shorter ones, that can be used on top of the icon, like:
- Language Type
- Completion Shortcut
If Apple placed these two on top of the icon, the icon view indeed looks better:
Still Not Perfect
This proposal isn’t perfect, it has some worst user cases:
- When language/shortcut is too complex
Current icon size is not enough for this, needs new icon layout design, e.g. remove the block, and put the text or icon between braces like ‘{TXT}’ or ‘{Core Data Icon}’. - When code snippets are same language
This is a step back, you can’t tell the difference.
But still, I think this will improve the accessibility of current icon view design, and give us a better Code Snippet Library when using Xcode 4.
I had submitted this to radar://8689562.
-
New iOS UI Component: DDActionHeaderView
Recently, I released 3 different iOS UI Components on github.
They are
And I haven’t had a chance to talk about them all, but let me show you the first one, which is also my favorite: DDActionHeaderView.
Story of DDActionHeaderView
Back to December 2009, that’s almost one year ago, I was struggling to create my first serious iPhone utility app, lots of proof of concept design and user interface experiments ongoing back then. And one of my ideas was to create a new UI component that:
- Combine the core concept of UIToolbar and UINavigationBar.
- Keep the simplicity and accessibility at the same time.
- And users can use it fast.
Rapid, is a very important notion for designing utilities on small iOS devices like iPhone or iPod touch. Those little gadgets should launch fast, do things fast, and go away fast.
For example, you don’t want your users to waste time looking at strange icons on the toolbar and trying to figure out (or just by guessing actually) what those icons do. And meanwhile, there’s no much space for you to add description next to the icons.
Icons on toolbar seems to be a simple interface with clear functionality, but things could be worse when you have four or five different looking icons on the toolbar, and the situation gets even worse when each icons are bringing up their own UIActionSheet.
It becomes some kinds of crazy knock’em down games in carnival booths, and you’re not going to win prizes from your users for that.
And DDActionHeaderView is the solution…
One Icon to Rule Them All
The gray circle on the right is called Action Picker, it contains action items. Users can tap to expand that action picker and look for actions that can be executed.
Once users tap the action item icon, the action picker shrinks back to normal, and action executed. So now:
- You saved lots of spaces for you app on screen.
- You got users focus on what they want when they want.
- Action Picker designed to look like an extra layer hidden under the skin.
- A well chosen default icon (first one) for Action Picker to display, can provide more detail information for underlying action items.
Eat Your Own Dog Food
DDActionHeaderView’s variants (e.g. dataSource protocol version) were first used in my iPhone app QR+Emoji, and the version you saw on github is a simplified version that is used in my newly released app: FrostyPlace.
Requirement
- iOS 4.0 SDK or later, demo project is using iOS 4.2GM SDK.
- QuartzCore framework.
DDActionHeaderView uses Blocks, Quartz 2D, CALayer, CAGradientLayer, CAAnimation and UIGestureRecognizer.
Screenshots
License
DDActionHeaderView and other two projects are released under MIT License.
Source code and demo are available on github. -
Microsoft Office 2011 Word Preferences
Ok and Cancel?! Are you serious?
When Apple is trying to remove “save” from Mac OS X 10.7’s edit menu, the “ok and cancel” presents the “latest” visionariness of Microsoft.
loading…
