|
|
|
Well, speaking as someone who has been doing control system development for years, notifications (we call them alarms) are a Big Deal.
Typically in a control system you can:
I have long wished that computer software for desktops had these kinds of tools, rather than just displaying each individual notification as a separate dialog box. In SL, where you can have many many pending notification (unacknowledged alarms) this is even more critical. When you redesign these things, please keep in mind that there are non English speakers in SL. The current message/alert system are mixture of dynamic translation and static language texts. In the new scheme I want to see:
I'd vote for the email style list in the coms window, like has been mentioned on the sldev list.
I think group notices are a lot like emails anyway.  Argent: what you're saying makes sense, and in general is where we're trying to go. But I really appreciate the clear listing of desired behaviors and the conceptual tie to alarm systems. I'll pass that on to the interface design folks.
Alissa: yes, making all messages, even server-side messages, localizable is a key part of this redesign. You do ask for one thing that's more of a challenge – making even "God Shouts" translatable. It's hard to imagine how a concierge would handle shouting in 8 languages. I appreciate the problem – a couple of weeks I had to restart two region with people on them, in one case mostly Brazilian, and in another case mostly French. I speak French well enough to get the message across, but not Portugese – I had to find someone else to translate for me. I think one thing we could do is have a larger number of "canned" and pretranslated messages, such as "The region will be restarting in 5 minutes." If you or anyone wants to contribute a list of ideas for messages that we should have on that list, I'll try to work it in as part of this project. Here's a rough model that seems to make sense to me:
(1) Keep the basic UI much the same by default, with one additional control on the dialogs, a button or link (perhaps the triple chevron) that would open up the "notifications" window or tab. (2) When the notifications window/tab is open, notifications appear there rather than in dialogs. (3) The notifications would be displayed as a line of text, in chat/IM style, with buttons or links inline but otherwise as they are in the dialogs. This allows multiple messages to be displayed, in a conversational format that users should be comfortable dealing with. (4) On clicking a button, they would be removed from the notification, but the notification itself and any associated links would remain in the log for reference. (5) Pending notifications would be sorted ahead of completed or merely informational ones, so that they wouldn't get lost in the log. (6) A mechanism should be available to do things like accept or reject all notifications of a given type (for example, all inventory transfers for a given source), such as a button or contextual menu to accept/reject all events similar to the one selected. (7) Some kind of more sophisticated filter mechanism (using an interface similar to iTunes smart playlists, perhaps) would be desirable. In addition, I'd like that kind of filter to be applicable to other logs AND to my inventory. But that's outside the scope of this Jira. Someone just linked to this issue from a group in SL, and I have to say i'm very excited about what I'm reading. I like the ideas presented very much, and I thought I would go ahead and add in my two cents while I could. Personally I'd like to see notifications listed more in the form of just that: a list you can scroll through like you might an inventory list. I've attached a file of what I mean, and it's very rudimentary, but I figured as a sketch, it didn't have to be anything fancy. In basic principle, you would have high-importance notices at the top of the list (such as from lindens) and the ones you wanted to view, you would simply click on. Other options could be "decline all" or "decline checked" etc. There are all kinds of useful things you could do with such a layout.
Edit: Upon reading the user comments here, it seems like my general idea is shared by most of the posters here. Sorry for the repetition. No problem, Brandon, we appreciate your agreement and support. Some ideas are so good that people just keep getting them over and over again.
Perhaps LL should give priority to Jira entries that have many duplicates? That list looks rather unfriendly.
I think it needs some visual aids. A different icon for various type of notices, perhaps Paying/Buying Those are all I can think of. High priority notices should have a differently colored background in the list. red, I think. and force to the top. Oh, and also, I think the text should be left aligned. As I said, the image I posted was never meant to be fancy, or an all-out representation of exactly what I thought it should look like. I was simply presenting it as an idea of how the layout should be (a list ordered according to importance), regardless of the frills, whistles and highlights that might be added on top. If you have the time and desire to make an exact representation of what you would like, please feel free to. Mine was never intended to be anything more than a layout model.
Benjamin Linden at recent office hours presented a WIREFRAME mock-up of what future notifications might interact like. See http://wiki.secondlife.com/wiki/User:Benjamin_Linden/Office_Hours/2008-01-26
 for transcript including link to the flash mockup. That would be http://lindens.lindenlab.com.s3.amazonaws.com/malbers/1-notif-while-notif-open.swf
...
Benjamin, could you provide a link to the mockup images discussed in the chat online as well? This doesn't actually provide much more functionality than the current notification system. The problem is that the information you really need to deal with a large list of notifications can't be contained in a little tab icon. This does let you see a high priority notification, and it does bring all the notifications into the cycle (right now, for example, a "group invite" will block other notifications until you deal with it), but you still need a "list view". Think of how you deal with email. Would having a box that let you tab from one email message to another without ever being able to see a list of incoming messages be acceptable? Well, busy notification systems ("alarms", in control systems) have the same kind of requirements. Although the flash presentation does look nice, I agree with Argent. It's rather like looking at a list of emails with nothing but a little envelope icon to tell you it's an email, and nothing to say who it's from, what the subject line is, etc. Would you really want to, say, hover over each email button to get a popup of who it's from, or be able to just read it all at once? Again, it's a step in the right direction, and it looks nice, but I think there needs to be more information, even if it means abandoning tabs for something a little less GUI, like a list of buttons with an icon for the type of notification, and the person/group it was sent by.
I think any pay-type message, which includes the join-a-group-for-a-fee spammage should have:
a) be displayed in a different color, and in a different screen location - so if someone is rapid-clicking through unwanted messages not only will the visual cue be different, but a twitchy finger can't accidentally hit "Accept". b) require a confirmation message, also in a different screen location, color, etc c) have a backout procedure for any message sequence which was not initiated by the user (so if someone buys something from a vendor, they can't back out since they're the ones who started it). If someone gets a random group invite or wears a malicious HUD attachment, however, the money is temporarily held in escrow for a short period. Perhaps there can also be a "report this" option for a message, so if it is the result of a spamblaster, the sender's account can be automatically disabled pending investigation when X number of reports are sent in - if this becomes tied in to the escrow idea above then there would be no profit motive for a spammer since they would never get any money even from a throwaway account. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Normal
Notifications and Alerts redesign
1. Notifications at Login
2. System Notifications
a) Critical Messages
b) Client Help/"First Use" blue dialogs
c) System Messages Requiring an interaction/response to proceed
d) Script Driven Messages
e) Script Errors
3. Other Notifications
a) Alerts/Confirmations - generally the items in notify.xml and alerts.xml
b) Any alerts considered more "Important" or "Cautionary"
c) Teleport Offer
d) Friend is Online/Friend is Offline
e) Status Messages, e.g...
f) Upload Status
g) Region crossings
h) Parcel-based states (icons in the menu bar)
i) Avatar-based states (buttons appearing in lower left)
4. Group Communication
a) Group Messages which can include object attachments, scrollbars, render an insignia
b) Group Voting
5. A Person Has Offered You...
a) Inventory Transfer
b) Responses to an Offer
6. Help Windows (explanation dialog when clicking '?' help)