[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