[sldev] Notifications redesign
Ramzi
ramzi at lindenlab.com
Mon Feb 11 15:44:27 PST 2008
Also appearing in jira: https://jira.secondlife.com/browse/VWR-4832
. That may be the best place to structure feedback and discussion!
I will try to link various earlier feature requests that relate to the
current shortcomings that Q did a great job to articulate.
best,
Ramzi Linden
Project Manager
Q Linden 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
More information about the SLDev
mailing list