Re: [Usability] Tab Glow States

[Thorsten Wilms <t_w_ freenet de>]

On Thu, 2010-09-16 at 15:41 +0800, Allan Caeg wrote:

>         -Asynchronous notifications: you want to look directly at the
>         app tab to see
>         if it contains new information (web feeds, twitter).  You ping
>         it.
>         -Synchronous notifications: the app tab actually needs to get
>         your attention
>         (im chat incoming, calendar event about to occur).  it pings
>         you.

Looking at what synchronous and asynchronous usually mean regarding
communication, I consider this choice of term troublesome. What exactly
is synchronous about a notification that can be left sitting there all
day?

What is this really about?
Something happened in this tab and the user might want to be aware of
this fact,
  VS
A process in this tab can't continue until the user does something.
Where you might get to see a modal dialog.

I think animations should be avoided for the first case. Too high risk
of being annoying for things that are not important enough.


Maybe we should use the term "notification" only if there is explicit
information provided, going beyond a look-at-this-tab thing?

Glow-state, emphasis, highlighting?


> I'm not aware of any GTK+ app that has tab glow states due to
> notifications. Whether they already exist or not, what do you think
> should be the convention for tab glow states? Let's come up with
> something that we can put on the UI Pattern Library so Firefox can
> follow our convention for this and other GTK+ apps can also take
> advantage of it.

Ideally, "glow-states" should be a standardized set, so all apps can do
the same thing in the same (or similar) circumstances and all
"glow-states" would be theme-able instead of having hardcoded
appearance.


-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/