[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