Community
Participate
Working Groups
Build I20030304 There has been much discussion elsewhere about insufficiently visible progress indications for builds. I'd like to raise a more general issue about the kind of feedback that will help novice users of Eclipse. If it helps, think of my mom as the user (you can imagine that she's not too comfortable with computers<g>). The problem is that when the user performs any command that will complete sometime later in the background, whether it be build, synchronize, or whatever, she needs to know this immediately. I mean "in your face" immediately. A smoldering cigarette in the lower right corner of the screen does signal this to the novice user, even when accompanied by a slightly larger hover. Something as unmistakable as a 2.1 modal progress dialog is what we're talking about. The reason why its so important for the novice is that they expect the commands they give to happen in the background (a more sophisticated notion). Novice users are more familiar with simple turn-taking UIs. The other nice thing about the old progress dialogs is that they automatically went away when the operation was done, and that told the user that it was again their turn. Here's one way I could see addressing this problem: - Workbench preference "Progress dialogs for background operations" vs. "No Progress dialogs for background operations". Default value: Yes. - Background operations initiated by the user's direct command (as opposed to periodically scheduled operations like bg refreshes or indirectly triggers operations like table tree widget population) are covered by a progress dialog of the familiar size unless suppressed by that users preference. - The progress dialog is non-modal, and will close automatically when the operation is finished. The dialog reports progress on the user's direct command, and has a Cancel button. The fine print at the bottom of dialog could inform the user that they are free to wait or to do other things as they choose (i.e., it hints that it's non-modal). - If the clicks on the workbench window, the progress dialog disappears behind it, and the user can go ahead and explore. - When the operation completes, the progress dialog closes automatically whether or not it is visible. - If the operation fails, the user needs an in-you-face notification. - If the user issues another long-running command that runs in the background, an additional progress dialog should open for that operation, and disappear when it's done. If you combine this with the other progress mechanisms added in 3.0, I think we end up with something that will satisfy the needs of novices and gearheads alike.
See bug 52617 for a discussion that shows that in some cases even sophistiated users need prominent confirmation of background operations starting, running, and completing.
Important correction to original text: > The reason why its so important for the novice is that > they *never* expect the commands they give to happen in the > background (a more sophisticated notion).
As an example of this approach, compare with long running operations in Windows Explorer. They open a progress dialog, but the main window is not blocked.
Another good example is Symantecs popup at the bottom of the monitor that lets you know something went on in the background
*** Bug 52468 has been marked as a duplicate of this bug. ***
See also bug 52468 for some good suggestions from Martin along these lines.
Download managers are another example which have the added advantage of showing multiple jobs in the same window. I can demonstrate the one in Mozilla Firefox (previously known as Firebird). Using a separate window has other advantages, e.g. showing % complete in the task tray by updating its title.
I20040310 If I press Save and have the option set to perform background builds on resource modification then this is a good message to see in the status bar: Building Workspace: 5% done But if I do Project > Build All it's not as good because I did what I logically think of as a foreground operation but nothing obvious happens and it's hard to tell when it's done. Also the progress messages in the status bar are often hard to decipher, for example, when updating something from CVS it said: Refreshing 'CVS ...pace': 24% done Performing a CV...ources: 1% done Searching for m...s view: 0% done There was a dialog that came up when the CVS sync was done but it was annoying so I turned it off. But now I kind of have to wait for the progress bar to stop updating and the CPU in my task monitor to go down in order to know when my update is done. Finally, the distinction between a user task and a system task is hard to understand, and I don't agree with the way they're categorized all the time. For example, Decoration calculation and Searching for markers seem like system things to me but they're marked as user. Tasks marked as user show up in the status line.
Agree that decoration calculation should be a system task. This one has bugged me in the past. (the other points you make are good too. :-) )
see also bug #52471 for a discussion on the system jobs vs. user job separation.
Should we differentiate between status line progres and modal dialogs? In 2.1 we made an effort to move away from progress dialogs and instead tried using the workbench status line to show progress. How would this effect Jim's suggested workflows? For example, would there be a category of operations, such as a build, that shouldn't be shown in the non-modal progress dialog? If we can agree on some of these details IMHO we should try and do this for 3.0 if the new background operations are to be useable not only for novice users (my mum included) but for everyone. A good example of the non-modal progress dialog can be seen with Outlook. This bug isn't assigned to a milestone, is that on purpose. Are we postponing post 3.0?
One case that's important to get right is Save. Prior to 2.1, this brought up a progress dialog, which if you didn't have autobuild on would just flash briefly. In 2.1, we fixed it to use the status line. It would be a mistake to start using a dialog again for this case. Now with background builds, the user doesn't have to wait as long if autobuild is on. But we've lost the indication of how many errors/warnings were fixed/found, unless the user goes to the Progess view or hovers over the progress indicator.
It would be nice if (some of) the status line jobs started as modal jobs with a "[always] minimize to status line" option so novice (or migrating 2.1) users can (1) get a feel for the jobs that are taking up CPU and (2) learn about the status line. One thing that really confused me as an upgrading 2.1 user (to 3.0M7) was the backgrounded CVS checkout. I ended up checking out my project 3 or 4 times before I noticed the process meter in the bottom right. My first assumption was that something was broken in the IDE because I didn't get any foreground feedback to my input. Had there been a dialog I would known that eclipse was processing my request and I could have also backgrounded it (and all future CVS dialogs) and would never have been confused.
I don't see this as a P4 problem. Several teams (notably both Team and JDT) have been adding workarounds for this issue in their code. If this is not fixed, then the we risk having a number of inconsistent solutions.
We need to decide what if anything is to be done within the M9 timeframe (preferably very early in M9). Anything not done by M9 will have to be deferred to 3.1.
This will be resolved early in the M9 timeframe
I have added a new "user job" flag to jobs. Job.isUser() should return true only for jobs that were directly initiated by user action, and for which the user may reasonably want to wait for completion rather than continuing to work. I anticipate that this new flag can be used to decide for which jobs we open this progress dialog. I suggest that all build jobs can be the initiate set of "user" jobs to prototype this. If successful, we could then begin to mark other jobs (such as explicitly requested CVS operations) as user jobs.
John, what's the vision for the relationship between: a. the large progress indicator in the status bar (the one with a proportional graphical slider and a stop button), and b. the smaller progress indicator in the status bar (the one with a text percentage, an animating image, hover window, double-click to get progress view, no stop button)
I'm trying to stay out of the vision business <g>. As far as I know, there are no plans to bring these together into a single widget. As you've noted, they have very different characteristcs. a) is modal, cancelable, only shows one thing, and has a reasonable approximation of progress. b) is non-modal, not directly cancelable, shows multiple jobs, and has no estimate of progress. While it does seem weird to have two distinct progress areas on the status line (especially when both of them start moving at once, I don't know if there is a way to reconcile the two considering their different requirements. Someone on the UI team may be able to comment further.
Please see http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui- home/responsive-ui/M9proposal.html for the proposed solutions to the outstaning progress issues in M9.
This dialog has been implemented and is avaialble by default.
