[sldev] Notifications redesign

ordinal.malaprop at fastmail.fm ordinal.malaprop at fastmail.fm
Tue Feb 12 08:04:59 PST 2008


A packet injection exploit was demonstrated to me recently, which  
could send arbitrary blue box announcements to somebody else (not the  
usual llDialog boxes, the top-right and bottom-right ones). I don't  
actually know how this works apart from using some libsl component to  
add outgoing packets - this really isn't my area of expertise - but it  
does. Is this known about?

On 11 Feb 2008, at 23:24, Kent Quirk (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