[sldev] Notifications redesign

Kent Quirk (Q Linden) q at lindenlab.com
Wed Feb 13 09:04:01 PST 2008


Tateru Nino wrote:
>
>
> Jason Giglio wrote:
>> Argent Stonecutter wrote:
>>> Well, speaking as someone who has been doing control system 
>>> development for years, notifications (we call them alarms) are a Big 
>>> Deal.
>>
>>
>> You bet.
>>
>> My only concern with this unified manager is that communication of 
>> severity becomes a little trickier.
>>
>> If we flood it with every "failed to rez because your camera wasn't 
>> pointing at the floor just right", or "you entered a different region 
>> version"... people will just ignore it.
>>
>> I look forward to your input there, I know management of severity of 
>> messages is big in industrial engineering.
>>
> Seems to me there's a fairly firm dividing line already in evidence in 
> message severity:
> * Messages that do not require any action on your part
> * Messages that require you to make a choice and respond.
>
> 'offers' seem to be about half-way - part informational, and part 
> choice. I'd say they fall clearly into the second category.
>
> A third category is administrative notices/alerts from estate 
> managers, grid-monkeys and the like.
>
> If it were me - actually when the new system rolls out, I guess it 
> will be me - I'd like to see an option to suppress the informational 
> messages as popups, and have them just run straight to the chat 
> history instead of appearing in the notification floater or popping 
> up. Choice/decision messages I'd like to be able to suppress them 
> popping up, but still have them appear in the notification floater. 
> Administrative alerts, I'd like to still see pop up, appear in the 
> notifications floater, and in the chat history.
A couple of notes:

a) Currently, we render all open notifications every frame, which is a 
waste of drawing resources, and then when they're no longer current 
they're gone. While here may be reasons to render more than one at a 
time (critical notices, popups, etc), it seems clear that we shouldn't 
be rendering more than one of any given type at once.

b) The JIRA ( https://jira.secondlife.com/browse/VWR-4832 ) has a 
categorized list of notification types.

c) We want to allow browsing the set of notifications without 
acknowledging them, and to be able to see history as well as the 
unacknowledged list. This means that we will have an internal priority 
queue of notifications with flags for type and time and status and 
priority; alternative viewers (as well as our own!) could reasonably 
present variant UIs for different notification types. In fact, it's a 
design goal of the project to separate the notification queue management 
from the UI presentation layer.

d) We want to support the idea of collapsing redundant notifications 
into a single entry, for those sorts of things where that makes sense.

e) I doubt that Linden is likely to convolve notifications into the chat 
stream; that seems more confusing than helpful, especially for 
non-expert users. But see c) above -- the information would be available 
for an alternative client to choose that path.

    Q   


More information about the SLDev mailing list