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/ _______________________________________________ usability mailing list [email protected] http://mail.gnome.org/mailman/listinfo/usability
