On Thu, Mar 1, 2012 at 7:22 AM, Mark Shuttleworth <m...@ubuntu.com> wrote:
> Going deeper: what matters with these numbers is not the number itself, > but the *change* in the number. Think of any example, like the number of > updates to an app. What matters is that you've gone from zero to 3 or from > 2 to 6. Going from 13226 to 14323 isn't at all interesting. > > So, we shape the system not for "mathematical accuracy" but for "eyeball > relevance". If you've got big numbers dancing around, this mechanism is not > the mechanism you want to be using. That knowledge allows us to do better > design for the cases where it *is* the right mechanism. > I wonder if we really need to redesign a hourglass (nightmare from the past: http://www.google.co.uk/search?hl=en&biw=1920&bih=1083&tbm=isch&sa=1&q=hourglass+pointer&oq=hourglass+pointer&aq=f&aqi=g1g-mS2&aql=&gs_sm=3&gs_upl=20420l20420l0l20747l1l1l0l0l0l0l67l67l1l1l0&gs_l=img.3..0j0i5i24l2.20420l20420l0l20747l1l1l0l0l0l0l67l67l1l1l0). I reckon progress bars and spinners are the more elegant evolution. At the moment, when a gtk progress bar doesn't know the end, we have this continuos pulsing (Knight Rider) animation. If this animation was more tight to the actual progress it wouldn't be much different than an increasing number, would it? Best, chr
-- Mailing list: https://launchpad.net/~unity-design Post to : unity-design@lists.launchpad.net Unsubscribe : https://launchpad.net/~unity-design More help : https://help.launchpad.net/ListHelp
