unity-design team mailing list archive

[Christian Giordano <christian.giordano@xxxxxxxxxxxxx>]

On Thu, Mar 1, 2012 at 7:22 AM, Mark Shuttleworth <mark@xxxxxxxxxx> 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