|
|
|
Actually, you should just change this to a feature request, since you already have votes anyway.
No, she can leave this a bug. She told me several use cases that this new behavior breaks. While it was an intentional change, I believe it may have been a mistake.
The dialog system is used for the delivery of "time sensitive" information. It is not just for permissions requests and payment notices. System alerts, like "this region will be restarted in X seconds" come through this system as well. As do teleport offers, friendship requests, inventory offers, etc.
Programmers often use the dialog system for warnings. "You will be teleported home in 10 seconds if you do not leave this area". Simple, trivial notifications are sometimes given dialogs as well. "this attachment cannot be worn on the arm". Upload fees get dialogs, payments get dialogs, profit shares get dialogs. To know that a profit sharing vendor is working properly, you want to see "payment in" and in a few seconds "payment out". if you don't see that, you know your vendor is broken on some level. Many vehicles, jetpacks, and sex systems "re-menu".. meaning once you tap a button, another dialog pops up, so you can keep using it. Xcite works this way, as does Sensations. These systems utilize this behaviour, safe in the knowledge that anything "important" will pop up on top of their menu. By making this change, you've created a situation where a couple having sex, might miss an ultra important Linden notice that says "we are logging everyone off SL". Likewise, a programmer building a menu-based script, might have a menu open while making a chnage in their script, and miss a "the region will restart in ___ seconds".. The dialog system is SUPPOSED to be for timely delivery of information. By doing this change, you've turned it into a "when I get through the pile, I'll see it" system. That is absurd. If you want to change it because some random glitch allows you to click "okay" accidentally when a menu is rolling down.. change the rolling down behaviour, or make it so you have to click on the ACTUAL button, not where the button will be. Make it so, like the payment authorization, that other permissions dialogs are a bit longer, making the "ok" button not be in the same place. Or god forbid, do some real programming and make it so you can click the lower dialog if you can still see it. But don't break a system that people have depend on for years.. just because it annoys you that it's easy to accidentally grant permissions. Because, if I use a menu operated building assistant, I'll never see that the region is being restarted.. and never save my work. Because.. I sat ther Let me get this straight, there were 4 votes on this change.. And because someone could accidently click on an incoming dialog the order of display was reversed for the dialogs... And fundimental change was put into place that alterted the way thousands of items work.. That changes the user interface in a fundimental way, after many years of working on a last in on top method... It does not seem to me that this change recieved a proper review as to it's impact on the user interface.. Yes it does fix one problem, but in doing so it introduced many, many others...
As has been stated here, I very often have a menu open.. And I will now not see any new dialogs appear until I close that menu. But as it is a remenu type of menu it does not close until I am done with it.. Which may honestly be hours.. Sorry but this is a very bad change.. Users depend on the dialog system to inform them of recent events... Many, many items keep a menu open until the user dismisses it.. Now those items will block all incoming dialogs unless the user closes them.. But the reason they are remenu was to keep the user from having to repeatedly click on the item to display the menu... There were many other options to fix the accidental clicking of a new dialog.. Winter Ventura described several... This "fix" for that problem created an even bigger problem.. At least we need an option to have it as a preference... This sounds good to bring up at Benjamin Linden's bug triage. Info on how to do that here:
"By making this change, you've created a situation where a couple having sex, might miss an ultra important Linden notice that says 'we are logging everyone off SL'"
That's better than one of the couple trying to click a menu to change sexual positions, but instead hitting the event reminder/teleport offer that popped up mid-click. I don't know if you can live down showing up hovering in those poses in front of friends. There's definitely more work to be done here. Please consider going to Benjamin's hours as Torley suggests, or suggesting fixes here that don't reintroduce the old problems. The FIFO (First In – First Out) ordering is not only to prevent grief and mistakes, it's also important for reading saved group messages when logging in. Otherwise you might not know the earlier messages referenced in later ones, which is rather annoying.
If neither a pure queue (FIFO) nor a pure stack (LIFO) are what we want, a priority queue or a priority stack might come in handy. The priorities could be associated to the different types and sources of Pop-Ups (Scripts, Teleport Offers, Permission Grants, Linden/System/Sim Messages, Group messages just to name some. The ordering here is random and not a proposal of what priorities to give each type). Of course deque (http://en.wikipedia.org/wiki/Deque Another suggestion: Allow random access to the popups on screen.
You can read your Email and SMS in the any order you like, or even ignore some without fearing any consequences (apart from not knowing what they say, of course). Why not allow the same for all the blue pop-up boxes? Instead of placing the popups behind/in front of each other, place them on top of each other. Collapse every to a horizontal line of only some pixels width, so they won't take up too much screen space. On mouse hover, expand the one that's hovered, so one can read it and/or interact with it. Collapse it as soon as the mouse exits its area. (See the attached random_access_popups.svg for an illustration) New popups would attach to the bottom of the pile, so the popup you might be interacting with doesn't move when another one comes in meanwhile. This would also have the advantage of allowing you to could keep a popup-driven menu open for fast access without having it take up too much screen space. Came up at our UI triage,
 and imported for further discussion. [10:18] Oryx Tempel: question about 2010
[10:18] Iridium Linden: So how shall we proceed with 2010? [10:18] Benjamin Linden: sure, Oryx [10:18] Oryx Tempel: it's talking about ultra important notices like Linden shut down etc [10:18] Oryx Tempel: anyway to make those a different color and higher priority? [10:19] Oryx Tempel: and the rest just average [10:19] Iridium Linden: That's an idea, Oryx. [10:19] You: You know, that's interesting – since we DID change the appearance of the debit permissions dialog. [10:19] Iridium Linden: Wonder how hard that would be. [10:19] Oryx Tempel: yup [10:19] You: It makes sense to me. [10:19] Benjamin Linden: right Torley [10:19] Benjamin Linden: good idea Oryx ^ Oryx, or someone else, please create a subtask for this. I'm kind of glad that I haven't yet installed the voice viewer, because the new pop-under functionailty would drive me nuts. It's pretty clear that BOTH alternatives on the table here are deficient in different ways:
The old way (new popups appear on top of existing popups):
The new way (new popups appear under existing popups);
Some of these can be mitigated by cycling thruogh messages using that little cyan pair of >> arrows, but does anyone actually realize what those arrows do? Does anyone actually use them? or are a lot of you going "what arrows??" right now? That feature isn't obvious enough to truly mitigate the above problems. Both of the current alternatives suck for some pretty important reasons. We clearly need a new solution. We need a way to make it obvious that new messages have appeared while not necessarily pre-empting what you're staring at and currently interacting with. One suggestion attached above is that the popups get stacked like a column of cards in solitaire, so the first row of each popup above/below the current one is visible. This is good when coupled with a "summary line" because you can easily see the fact that there are popups waiting in line below/before this one. This kind of breaks down when you go to a previous popup, because it will be likely to cover all popups that arrived later, making it non-obvious that they're still there. The entire context of popups isn't obvious at a glance. Another option is to use an interface like that currently used in the preferences window. Tabs on the left, attached to each dialog, show you instantly where you are in the stack of popups. Careful rendering of lines shows you which tab connects to the currently opened dialog. You can easily see that you're at the top, bottom, or middle of the stack of dialogs, and the text on the tabs shows you a summary of what each tab contains, ie "Permissions request", "Gridwide Announcement", "Script Dialog", "Payment sent", "Payment received", etc. We'd still have to choose whether new items gain focus or not, but at the very least, it'd be possible for the user to intuitively tell, at a glance, what in the world just happened when a new popup shows up. That's really important. I think Soft Linden's argument about new dialogs suddenly sneaking under your mouse as you're clicking is kind of important. That means it'd probably be best to have new dialogs not gain the foreground as they show up, even though this causes a lot of problems with existing scripts. Alternatively, some "grace period" could be implemented, so that a newly appearing dialog ignores clicks for the first 50 or so milliseconds of its life. This could mitigate misclicks. If this isn't possible, we probably need to have old popups stay on the screen, but at least the tabs I described (or some other solution) would make it clear that a new popup has appeared. I don't like the idea of changing the way the current system works to have new popups appear below the existing popup since it will potentially break existing scripts, but I think it's necessary to do SOME kind of major reconsideration of the UI of these popup dialogs. They're pretty broken as they are, from a usability standpoint. Quick note: I don't like Boroondas' idea of expanding popups in the stack by hovering. This would require too much dexterity and would be too likely to cause a user to make a mistake, which good UIs should avoid. Clicking a popup to expand it would be a good substitute.
Sorry I couldn't join the UI triage.
My Idea wasn't actually to pile the popups like solitaire cards, but to rather squash their height. Like this, the squashed representatives of popups both newer and older than the expanded "active" one would be visible over and under the expanded one respectively (see the updated svg). Of course, a summary line on each of them would be good to have. Why I chose hovering over clicking, was because I wanted to grant faster access. If the current position of the buttons is kept, I don't think there's a too big chance to mis-click, as the buttons aren't very near to the popup's boarder (where the next one would be triggered to expand). Though this probably would have to be evaluated by testing it to make sure. This error is very annoying when receiving a teleport request or
when people send you a file, and theres a window open. It's so easy to miss now! Bueller?
I've been using Client 1.18.0.6 all this time SIMPLY because of how incredibly crippling this bug (and the communicate window) are to my SL business. Is something being done to fix this? I would just like to comment that this new "feature" has been difficult for me to deal with as well. I am getting a lot of customer questions and complaints about my products. I am having to spend a lot of time explaining to them how to work around this. I do understand why a change had to happen. But clearly what was done is problematic for it's own reasons. Please consider rolling back to the previous behavior until you have a better solution designed.
Ha, I was beginning to think I was going crazy. Yeah, unless the way these notifications are delivered is changed in some fundamental way, new messages should always go on top.
This doesn't exactly break my content, but I did design some content based on the previous behavior. I'm sure it will confuse players and will eventually require updates by me if it remains.
I also agree that newest on top is important. There are other ways to solve the perceived problem. It's obvious both ways have problems. Given th choice, thoguuh, i'd prefer the old behaviour.
But I think some new options are needed. Perhaps, a little flashing tab could appear when you have new (un viewed) dialogs. And dialog messages from system/second life/ any linden, should force themselves to the top AND be in a different color, as those are always important. Sample proposed stackable dialog boxes with side tabs
Top: normal priority (blue) Bottom: with urgent message (red) This is my first ever attempt to attach a file, so my apologies if it turned out rather clunky :/
To avoid the drawbacks of either FIFO or LIFO stacking, I suggest adding side tabs to the dialog boxes. Various tabs could be used for various kinds of dialogs, such as inventory offers, payments, group notices, permission requests, friendship offers, and so forth. Whether incoming messages stack on top or underneath previous messages, the side tabs would allow handling them in any order the user sees fit. I have tried to illustrate this in the top part of the attached image. At the same time, urgent messages such as shutdown notifications would automatically jump to the top of the stack, and be set off in a different color to catch people's attention. This is illustrated in the bottom part of the image. sorry the image is a bit messy and bulky, I'm still learning to use gimp Just tweaked Veronica's graphic to make it easier to load (yes, I know it would be readable at even smaller size and compression, but it was a quickie edit).
Must agree with the gist of Torley's comments (and pasting of discussion from bug triage?) here that the present blue boxes do present a challenge to most residents. I find it particularly annoying that they cannot be resized, moved or minimized. And their widespread use in user scripting seems to present a strong conflict (and a certain lack of predictability) when it comes to their use for critical system announcements, especially those that are essential to prevent data loss during unplanned shut-downs and the like. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Open
Major
Blue dialogs now display in reversed order
VWR-1344. I'm going to resolve this as Won't Fix since this is how the client is supposed to operate now. If you want it changed, though, I recommend filing a feature request to have the old behavior restored.