Bugzilla – Full Text Bug Listing
| Summary: | Why is operation icon used to communicate status information instead of message service? | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Susan McCourt <susan> | ||||
| Component: | Client | Assignee: | Malgorzata Janczarska <malgorzata.tomczyk> | ||||
| Status: | CLOSED DUPLICATE | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | libingw, malgorzata.tomczyk, susan, Szymon.Brandys | ||||
| Version: | 0.4 | ||||||
| Target Milestone: | 0.4 RC2 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | 369977 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
Susan McCourt
and one step further, if we use the message area to report operation failure, then do the reasons for having the "operations/none" icon to launch the minilist go away? Just trying to sort out the sequence. - user initiates operation - progress icon animates and progress messages would go to notification slideout - then a message would in slideout would describe success/failure - icon has stopped spinning - user can close slideout At this point, operations icon would be muted, I suppose it will still let you go to the minilist, and then a few seconds later it disappears. What is the information that would be needed by the user that they didn't get in the slideout? Susan, I'm not strongly attached to idea of changing the icon on task failure. I had two reasons why I didn't want to put the operation result in the message service * message service usually shown an outcome of the operations that was just made, tasks may finish after much longer time and it may not be clear for the user what is the message about * there may be few tasks running simultaneously (see repository page) and one messages from one task will be overridden by messages from another The scenario from comment 1 is good when you have one task only, but when there's more some of the messages that we don't want to show on the minilist may be overridden so fast user won't be able to notice them. This is why I decided to pop up the minilist showing all the errors. So I'm fine in reducing the number of operation icon to spinning/not spinning, but displaying errors is something we should still think about. The best idea would be to find somewhere between popping out the minilist and dispalying the last message on message service. Moving to RC2, because in RC1 we don't have enough time to decide on what changes are required. yes, I ran into some situations since opening this bug where some message got overwritten, so I see what you mean. The long term solution could be in the message service I think. Some kind of message history, because I don't see that this is special to operations. If there were some icon that showed you had something important to see, you could open a slideout or whatever and see the messages. So maybe the issue is that your solution is right, but it should be used more universally. For the short term...hmmmm... is there anything to gain (or anything lost) by retaining the current behavior but also having the operation service post the status message to the slideout when its completed? At least then you'd get the "expected" notification and we'd still have the history preserved in the mini list. I opened bug 371261 to discuss the long term issues. (In reply to comment #4) > For the short term...hmmmm... > > is there anything to gain (or anything lost) by retaining the current behavior > but also having the operation service post the status message to the slideout > when its completed? At least then you'd get the "expected" notification and > we'd still have the history preserved in the mini list. maybe it's safest to leave this alone for 0.4. I just put in the new icons and it looks better. I just use the standard error/warning and it plays a little more naturally to me than seeing those overlays and wondering what's different about this error vs. other errors... You can close this bug if you'd rather not bother with the "repeat message in slideout" idea. Created attachment 211058 [details]
patch
experiment, not that successful
I was talking to Gosia earlier to see if we could think of any short term fixes to two problems: 1) messages overwriting each other 2) blinking/bouncing (such as in git status when loading logs). She tried an experiment posting message results to the operations popup. It didn't play well. I tried several experiments: 1) never close the notifications page once you've posted something and make the user responsible for closing it. This reduces "bounce" but the "empty notifications area" looks strange. It just didn't really help and makes you kind of wonder what that area is for if you weren't paying attention to the messages. 2) have the progress service post progress results to the message area rather than clearing the message area. This also reduces bounce but you end up with info messages that are of little concern, like "Branches retrieved." So it reduces the mystery of the empty area by putting info in there, but the info is fairly useless. 3) have the progress service service post progress results that are warning/error. This doesn't help the git status case but could potentially fix my original concerns in this bug. That is what the patch I just attached does. but it seems that the message and progress service parse severity differently. For example, when I tried to push from git log with no pending commits, I got a warning in the operation minilist but I got an info message in the message service. So I think we just live with the issues in the short term (sorry). I tried a variation of #2 that changes the info message color to gray (the same as progress). This looked much nicer, and in fact looks really great on the git status page. But on git log, and repository, it looks kind of dumb to have messages like "generated branches" hanging around. I guess I'm giving up for real. Susan, it seems we don't really have ideas to solve it all for 0.4. Maybe we could postpone it to 0.5? (In reply to comment #10) > Susan, it seems we don't really have ideas to solve it all for 0.4. Maybe we > could postpone it to 0.5? yes, I kept trying alternatives throughout the day yesterday and kept running into similar roadblocks as described in comment 8. Let's mark this duplicate and work on the big picture in 0.5. That bug refers to salient points in this one. *** This bug has been marked as a duplicate of bug 371261 *** |