[digdog dig];
I'm Ching-Lan HUANG (黃 青嵐), and this is my tumblr.
-
INFOBAR, a Different Android
Aside from the well known HTC Sense UI, now we see a totally different approach, widget based interface for Android from au.
But it reminds me WP7…
(Source: iida.jp)
-
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.
-
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. -
Filzus
Autumn Winter 2010-11, les queues de sardines.
-
Introducing the concept of “Places”
by Peter Torr.
The basic premise is that the phone (and hence the applications on it) consist of a set of “places.” A place is a “user-recognizable collection of persistent state” (thanks to Alan Bush for that succinct description!) or in layman’s terms it’s a screen that the user visits that contains information, content, or links to other places. Now since a picture is worth a thousand words, let’s take a look at the structure of a typical content-browsing application…
-
The Royal Opera House.
-
KID Collective icons by Celeste Prevost.
-
賈商求屋第一卷第二十三章
大師只在紙上草草畫了幾筆，看起來像是交錯的線條。鄉民急忙道過幾聲呢喃，便恭敬地捧起那片不起眼的草紙，喜形於色，小碎步離去。數日後，滿手金碧輝煌的，豪氣地哐噹一聲把酒杯放下，抬起不靈活的手指，敲了敲桌上那幾張剛沾到酒漬又似曾相識的線條：「我他媽低聲下氣求來的，不要給我搞砸了！一堆鬼畫符，幹！」
-
Design a framework or library like Apple
Require latest version of OS, and don’t look back.
- Don’t shit like “required at least iPhone OS 2.2, recommended iPhone OS 3.x”
- Just “required iPhone OS 4”
- And everybody moves on.
This is good for you, and your customers.
loading…
