[sldev] Notifications redesign

[Brandon Lockaby]

Interesting and a bit exciting, thanks for the words!

I want to add something:

The way I dream of the dialogs, you could view a list box of all of them,
and select one or more at a time... that way, if someone griefs you with 5
dialogs, you can view the list, select all 50 at once and close them or
whatever.

Just a thought... Keep up the good work! <3

On Feb 11, 2008 6:24 PM, Kent Quirk (Q Linden) <q at lindenlab.com> wrote:

> Hi, folks. We're about to embark on a project to redesign the way that
> notifications and alerts work in the SL client. I wanted to tell people
> that we're looking at it and give you a chance to get in your two cents
> while it's still early.
>
> Notifications and Alerts are the boxes that pop up on external events,
> from the little temporary ones in the lower right corner to the things
> that warn you when someone wants to take money from you. They have
> several problems that need a redesign and reimplementation. These include:
>
>    * Code shortcomings:
>          o Group notifications and Notifications have two separate code
> paths for very similar behavior
>                + there's some awkward code to make them more similar
>                + they fight with each other for priority display, and
> in certain weird instances could cause viewer to crash
>          o Alerts can't take server-side parameters and still be
> translatable
>    * UI shortcomings:
>          o The way alerts and notifications stack up is highly
> confusing, especially for new residents
>          o Too many different places on screen to look for messages
>          o They could use a new graphical appearance, particularly to
> be compatible with http://wiki.secondlife.com/wiki/Dazzle
>          o Too much detail up front for new users -- would be nice to
> allow summary / detail levels
>          o Reduce the potential for griefing through scripted object
> notifications
>          o No differentiation between system (Linden)-created
> notifications and resident created/initiated notifications
>          o The discoverability is low on how to scroll through Active
> Notifications; or dismiss Passive ones early (Did you know you can?)
>    * Functionality shortcomings:
>          o No history- so if a notification is missed it can not be
> recovered
>                + If the client is exited or crashes with active
> notifications they are lost along with attached inventory
>          o No way to get additional information from a passive
> notification
>          o No hyperlinks in notifications
>
> With that in mind, my intent is to:
>
> 1) Redesign the API for notifications and alerts. First, we'll unify the
> call structure so that all notifications and alerts go through a single
> unified call looking something vaguely like:
>         NotificationSystem::displayNotification(string
> notificationname, LLSD data)
> This first pass will simply unify the call structure and the input XML
> files so that all notifications go through this path. That change should
> only be of interest to the people working in the source; there will be
> essentially no user-visible changes from that change.
>
>  2) Next is to unify the rendering process so as to eliminate the old
> LLNotifyBox, LLGroupNotifyBox, and LLAlertDialog classes. We'll also
> change the rendering so that we'll only render the "top" notification(s)
> in the queue, rather than rendering them all. This will also give us an
> improved ability to scroll back and forth through the list of pending
> notifications. There will be some user-visible changes at this point to
> bring out some new features in the API and make the existing
> notifications fit with the evolving look and feel of the UI. But my
> intent is that they'll be relatively minor and noncontroversial.
>
> 3) Then we'll want to do a full revisit of the rendering code for
> notifications which will almost certainly change the way they work in
> ways that should improve usability and reduce the potential for
> griefing. Our Resident Experience team will be developing a unified
> design for the system, and as they design it we'll want to bounce it off
> people here in advance before we code it.
>
> In the long run (which -- fair warning -- is several months away), we
> hope to have a notification code path that is comprehensible,
> extensible, localizable, and unified, as well as a UI that is attractive
> and works well.
>
> So we'd dearly love your constructive feedback, in particular if you
> think there are additional considerations I haven't mentioned.
>
> Thanks,
>
>    Q
>
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080211/665514cf/attachment.htm