Bugzilla – Full Text Bug Listing
| Summary: | clean up our various messaging/error reporting/progress message UI strategies. | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Susan McCourt <susan> |
| Component: | Client | Assignee: | Project Inbox <orion.client-inbox> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | antonm, eclipse, jainnayna, john.arthorne, ken_walker, libingw, malgorzata.tomczyk, Mike_Wilson, Szymon.Brandys |
| Version: | 0.4 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
| Bug Depends on: | 376104, 377513 | ||
| Bug Blocks: | 344047, 371389, 371607, 372277, 382045 | ||
| Attachments: | |||
|
Description
Susan McCourt
*** Bug 371479 has been marked as a duplicate of this bug. *** I have another thing to unify or talk though, see bug 371607, but I think this is not the only place that would have this problem. The thing is that if there are status messages that should be shown one after another, for instance two simultaneous operations finished with an error, or like in bug 371607 one operation finished with an error immediately another operation starts, the second operation status overrides the error. We could think about access to those previous messages that may still be interesting for the user. (In reply to comment #0) > As far as UI goes, I'm wondering if we ever want to have a twistie for opening > the notifications (see your last one) or perhaps leaving it open, if you don't > like the blinkiness of appearing and disappearing. If we did this, then the > control that opens the slideout could also be a way to get to history (sort of > like taking the role of the current operation mini list icon). At least in git status page I found that the blinking is bit annoying. Sometimes you just want to stage a file while the mini log is still being loaded. You hover your mouse on a file but when you click, it turned out to be another file. (In reply to comment #2) > I have another thing to unify or talk though, see bug 371607, but I think this > is not the only place that would have this problem. > The thing is that if there are status messages that should be shown one after > another, for instance two simultaneous operations finished with an error, or > like in bug 371607 one operation finished with an error immediately another > operation starts, the second operation status overrides the error. We could > think about access to those previous messages that may still be interesting for > the user. (In reply to comment #3) > At least in git status page I found that the blinking is bit annoying. > Sometimes you just want to stage a file while the mini log is still being > loaded. You hover your mouse on a file but when you click, it turned out to be > another file. I think the problem in these two cases is that we are using the message service for things that perhaps belong in the content area. We've never been clear about the rules here, but in retrospect it seems to me that something like "loading status" or "loading repositories" or "loading git log" probably belongs in the space where the content will eventually go. So the user knows things are still filling in. If we then reserve the message area for notifications for user-initiated actions like "push" etc. then I think the reality is that there's not much competition for the message area and not much bouncing. I tried some short term experiments fixes for the bouncing and inconsistent error reporting in bug 370782 comment 8 but they weren't much better. Assigning this bug to me just to keep it on the radar, but I think we need a design discussion early in 0.5, as this affects: - message service - progress service/operations posting - rules for page writers etc.... *** Bug 370782 has been marked as a duplicate of this bug. *** *** Bug 349131 has been marked as a duplicate of this bug. *** I have to say the current progress dropdown is driving me crazy in the Git status page. The left half of the page jumps around several times as the page loads, and then every time you click a file to show in compare it jumps around again as it shows/hides the "Loading diff" message. Having links move out from under your mouse as you click them is disconcerting. This really needs to be in a static place where the page layout doesn't change when a message is shown. (In reply to comment #8) > I have to say the current progress dropdown is driving me crazy in the Git > status page. The left half of the page jumps around several times as the page > loads, and then every time you click a file to show in compare it jumps around > again as it shows/hides the "Loading diff" message. Having links move out from > under your mouse as you click them is disconcerting. This really needs to be in > a static place where the page layout doesn't change when a message is shown. There is a potential fix for this. (see bug 370782 comment 9). What I found is that it played quite well in git status, but seemed a bit odd in git log and repo page, where you ended up with some pretty meaningless messages that were semipermanent. Do you think we should pursue something like this for 0.4? In using git status and repo page a lot the last couple of days, I really think that having a strategy for "reporting progress for loading content" is the single biggest thing we could improve. Places that are just doing fetches tend to report things in place (nav loading, etc.) and places that use operations get the progress service. Perhaps we need a way to trigger an operation that fetches content and tell it where to report the progress (callback function)? Then the calling code can decide if it goes in the progress service, content div, etc. For example: - Git status page doesn't need to report "getting log" at the top of the page (bouncing or not). It should be reporting that in the empty hole where git log is going to appear. - Likewise with all the cases on the repo page that have to run an operation to fill a section. They are using "..." in the header (nice) but they are also getting the progress reporting (not as nice) via operations. - git status diff selection requires an operation but should probably report "getting diff" in the diff pane. If these "content filling" operations end up having an error/warning, we could still use the notifications area to post these. Note also that some of the operation info messages are important for the user to see (ALREADY_UP_TO_DATE) or (FAST_FORWARD) but the ones that just tell you that content got successfully fetched (Loaded branches...) don't add any information. You know the branches got loaded when the content fills in. This suggests to me that the code that calls the operations service should be able to provide progress reporting/error handling code and perhaps fall back to a default. I think this would significantly improve the user experience, but note it does nothing to solve the issue of multiple tasks needing to report failure. I think failures or warnings should be directed to the notification area but we need a way to get to the history of them. This should include all failures, whether from an operation or from a normal error. Created attachment 211524 [details]
mockup part 1: move content filling progress to the content hole
Created attachment 211527 [details]
mockup part 2: repo page
as best as I can tell, the main three messages on this page that overwrite important messages are:
1) Loading...
2) Getting git repository information...
3) Getting branch information...
If those were moved to the content area there would be little overwrite of the important messages like:
OK
MERGED
etc.
So I think the approach should be to get the content messages moved and then reassess what kind of history is needed.
Created attachment 211528 [details]
mockup part 3: link for notification history
Created attachment 211530 [details] mockup part 4: notification history if you open the notification history you see past notifications. Things to notice: 1) history is kind of useless if we don't have more context such as what the user was doing and the time 2) we should think about whether we want to keep informational messages such as OK (see also bug 344047) 3) we need to get the statuses consistent. Right now it appears the operations service considers a non-finishing an operation a warning (NOTHING to push) even if it is OK from a normal status point of view. So in this mockup it's possible that top notification would just be another info status much like the one below. The fact that the operation service adds more context (nothing to push) vs. generic status (up to date) is a very good thing, it probably just needs to be done more universally in all notifications (task context). I guess a key here is how this behaves as the content loads.. I would hate to see: 1) Content hole pops to a bigger size to fit progress message 2) Message goes away, and content hole pops to a smaller size 3) Now the content arrives, and it pops out to a larger size again. This could result in at least as much jumpiness as today, especially multiplied over a page with 4-5 content holes being filled in. I don't know how hard it is, but perhaps one way to make this less jarring would be a smooth transition rather than the current resizing "pop". I.e., like the inertial slideout in Anton's plugins page. Another thing more specific to the git repositories page would be forcing the content to load top to bottom rather than all asynchronous and fill them in as they arrive. This doesn't add much value because in reality the page isn't usable until I know I can safely click without the content moving out from under me. Having sections added dynamically at the bottom only is far less jarring and means I can safely interact with the parts of the page I can already see without it changing on me (think twitter or google+ pages). There is one more case for showing progress. git-repo page makes many calls to gather details to render some sections e.g. the branch section. It takes time, so this is why we have the section progress. I was thinking that I could populate the list when I get the list of branches and then show a progress indicator for each branch till extra details about the branch (e.g. last modification data) are loaded. And answering John's question I would load the content top to bottom and fill items with extra details when arrive. To start working with a branch we do not need its last modification date which is loaded in a separate call now (this could be improved btw). There would be already a placeholder for this extra details in the UI, so we would avoid popping. There's a lot to do in this bug, so we're breaking it into chunks. I talked to Szymon and we think a good first step is the following: - change the operation API so that the client can specify where progress and status messages go. Opened bug 376104 for this. - change the repo page to use this new API so that all content-filling messages are inserted in the DOM. (mockup part 2). If this proves successful, we can change git status per mockup part 1, and then start looking at the other issues of history, bouncing, etc. For now I'm assigning this bug to Szymon to be an API client for bug 376104 via the repo page. He can bounce it back to me or open new bugs as we move into followup steps. Created attachment 213603 [details]
screenshot of inline notification in a banking web app
Just wanted to capture this.
Here, a notification that looks a lot like our error notifiers is shown in-line at the place where the error occurred.
We discussed our current state and better ideas at the UX meeting yesterday. Anton is going to write up more detail and some mockups and we can post a link, but the ideas (independent of the visuals) that I captured were something like this:
- the spinner that shows operation popups is misleading, as it currently activates for any running operations, whether triggered by the page or not. Instead, we think the spinner should only be shown/active when the page content is loading (ie, the page is still working on something). Ideally you'd see other indicators as well (the ... or other content loading messages, etc.). The spinner tells the user "I'm not done, this page is not loaded" and that's all it is saying.
- not clear we need dedicated space for generic operations progress. If triggered from a page, it should appear as part of the command progress.
- when a command triggers an action requiring progress, the notification should be somewhere near the command. Today this is mostly true for commands in the main toolbar, since progress shows in the message bar (though we don't like the content shift) but not true for commands in sections. One idea is move the message bar to the section heading, in the same way that slideouts are local. Another idea is to show the progress in the command button itself. For example, it is bogus that "Fetch" from git status reports progress at the top when it was initiated below. If instead the "Fetch" button just showed that it was working, that might be enough until it is done.
- when a command operation fails, there should be a link or other suggestion for a fix near the command. The examples were:
-- click on "Format JS" and if you couldn't reach the server, you'd see the error indicator with a link to a login page.
-- click on "WebDav Content" in the navigator and if you needed to authenticate at another domain, you would see an indicator next to the item and clicking on it would take you to your webdav server authentication page.
- we need a notification service accessible from some fixed position on the page that could notify of feeds, server status, etc. Some discussion of bottom vs. top. Note that notifications ARE NOT the same as operations.
- for background operations, there is a need to get to the operations list for progress ("what's happening with my clone?") but this is not very common. However, for some background operations, it might make sense to report success (or failure) to the notification service. For example, start a clone, work on some other page, at some point the notification service tells you "your clone is done, here's a link to the content."
Not clear what we want to tackle for 1.0, needs more discussion.
Minimally I think we want to consider:
- provide a sectional message bar rather than doing all reporting up top
- make commands like fetch use the sectional bar
- make the message bar floaty vs. DOM shifting
- clean up meaning of the spinner
Not sure what still applies to the current state. |