[sldev] Re: Notifications redesign

[email at secondlifePMsands.com]

I look forward to using the planned features you described.  Sounds great.
Thanks Q. 

1 cent:

Would be helpful to me (for lesser important group notifications, etc) if I
could use some sort of roll out (auto hide) dock to organize hud gadgets
(+button link to ll provided mySLmail page),  (+ button to backup inventory
to my local drive)  

–err, sorry for the escalating expectations. 

(wait, my favorite button would be a button that would send an electric jolt
every time that guy kept replying to this mail list a month ago to be
removed, then he would get more angry when he would not be removed by the
fictional python mail list admin –to clarify, I would like a button that is
able to go back in time and zap that guy)  o:0  

(and another button to go forward in time and thwart out of office auto
replies to this mail list).


========================= 
 
PM Sands  

SL Consulting 
Linden Lab Solution Provider 
Full Service Company 
secondlifePMsands.com 

=========================

Message: 1
Date: Mon, 11 Feb 2008 18:24:14 -0500
From: "Kent Quirk (Q Linden)" <q at lindenlab.com>
Subject: [sldev] Notifications redesign
To: Second Life Developer Mailing List <sldev at lists.secondlife.com>
Message-ID: <47B0D91E.9060402 at lindenlab.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

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