[sl-ux] Feedback on the Notifications Redesign project

Lex Neva slux at lexneva.name
Wed Jul 2 14:52:59 PDT 2008


Thanks for getting back to us, Michael!

On Tue, 1 Jul 2008, Michael Albers (MAlbers) wrote:

> Keep in mind that things happen in the prototype more frequently than one 
> normally sees in real life. That is, you do not normally see this amount of 
> notification activity in one minute of in-world time.

Don't rely on that too heavily, though... beacuse notifications can be "bursty", 
and users will probably experience many notifications coming in 
simultaneously at least occasionally.

> Direction C is the current direction. The focus rules in the current UI 
> Design Spec are that focus in on:
>   * whichever notification the resident has selected, clicked on, or is 
> hovering over w/ the mouse
>   * the temporal notification that will ?time out? soonest
>   * the critical notification that arrived most recently
>   * the normal notification that arrived most recently
>   * back to the Viewer component which most recently had focus
> As has been noted, it is impossible to know with complete certainty when a 
> ?resident is interacting with an existing notification?. This uncertainty can 
> appear to a resident as the system acting randomly. This could give the 
> resident less confidence in the overall system and no one likes working with 
> an untrustworthy partner.

That's my biggest fear.  With that many rules, it's hopeless to expect the user 
to even come close to understanding intuitively what makes the system choose 
what to do.  I can't emphasize enough how detrimental this will be for the 
interface.  While it looks like it may technically solve the problem of making 
sure residents see important dialogs, in practice residents might well 
compensate for what they perceive as an out-of-control UI by always dismissing 
things that pop up over what they're reading.  That'd make the problem worse.

>
> Direction B is the option favored by most of the comments.
> For the sake of brainstorming, the biggest open question for me within 
> Direction B is how to treat temporal or critical notifications. That is, how 
> do we handle things like Region Restarts and God Shouts (grid-wide 
> announcements by Lindens). The original intent was that these are the most 
> important things happening right now. Since there is a risk of data loss 
> and/or financial loss, we wanted to make sure people were notified.
> Brainstorming a tweak for Direction B:
>   * whichever notification the resident has selected/clicked on
>   * the temporal notification that will ?time out? soonest
>   * the critical notification that arrived most recently
>   * the normal notification that arrived earliest
>   * back to the Viewer component which most recently had focus
> This only has the one change.
> Alternately, taking out all the exceptions for temporals/criticals, we get:
>   * whichever notification the resident has selected/clicked on
>   * the notification that arrived earliest
>   * back to the Viewer component which most recently had focus
> This causes the smallest amount of visual noise, puts the resident in 
> ultimate control, but the risk is that something critically important will be 
> missed.

I think Q's wording was along the lines of "display notifications in the order 
they arrive, but make it clear when new notifications have arrived".  There 
might be room for a pretty good compromise here.  How about this:

* Always display notifications in FIFO order.
* If a new notification shows up, create a tab for it, like in the IM window
* When this happens, briefly display a summary in a speech-bubble.  This should
   be small and should fade out within a few seconds, and ideally should avoid
   covering much of the notification that's currently being displayed.  It should
   just have the first few words of the notification, such as "teleport offer
   from Fred Smith", "Jane Doe is online", or "region restarting in 4 minutes",
   and should dismiss if the user clicks it.

This way, users can see what's happening and react if they want to, but they 
need not have their entire frame of concentration interrupted suddenly.  Maybe 
this won't appeal to users, but I think it might be worth running through a 
usability test.

> As always, thanks for all your (past and future) feedback and ideas. I know 
> it benefits many of you to be involved in these discussions but you are 
> investing your personal free time in SL. Thanks.

No problem :) I love this stuff.  I'm glad I can help.


More information about the SL-UX mailing list