Community
Participate
Working Groups
In bug #247950 a user was surprised that the new menu items (Install New Software... and Check for Updates...) contacted the repos before launching the UI. From that bug: > The new UI in 3.5 is confusing. When I click 'Install New Software...' I expect > that a dialog opens where I can put in something and start the install. The > three dots in the menu entry indicate this. Instead, the user gets the progress dialog immediately (or no dialog at all if they've previously set the preference to run all jobs in the background). The intent here is to let the user keep working while the expensive stuff is going on. This has been received well by some users, but surprises others. What should be done here? - at a minimum we need an hourglass immediately. If the user has the "always run in background" preference on, there is no immediate feedback that anything at all is happening. It seems to take a second or two before you see anything. (A good comparison is Team->Synchronize, where this can also happen. They use an hourglass). - The "Install New Software..." wizard doesn't have to preload repositories before coming up. This was a requested feature to prevent all the "Pending..." and waiting that happened afterward. The intent was that the user could keep working and not see the UI until it was ready. Should we have a toggle preference that comes up and offers the option to load the repos first? This might be just as disconcerting - "Check for updates..." can't report anything meaningful until repos are contacted. I don't see changing the workflow, but should the ellipsis not be there?
Kevin, I cc'ed you since you are "ellipsis guy", but also any general feedback on handling this workflow is welcome.
FWIW, Firefox uses "Check for updates..." and this also brings up a progress monitor. However there is not the pause that you can get with the background job dialog.
I know enough to avoid wading into an ellipsis debate, but I just wanted to mention that I think pre-loading the repositories before opening the install software dialog is a huge usability improvement. We previously quickly opened a dialog that was mostly useless until the repositories had finished loading, thus preventing me from doing anything. I can now do other things while the repositories load, and when the dialog opens it is immediately usable and responsive. I wouldn't want to revert that change just so the ellipsis makes more sense ;)
I'm think we should do the following: 1) take the ellipsis off of "Check for Updates..." for these reasons: - no further input from the user is required, it is going to check for updates as soon as you choose this menu. - which dialog you see next and how soon depends on your preferences for progress dialogs and whether the repositories are already loaded. Whichever dialog you see next, it's the "result" or "progress" not something asking you for more information. - conceptually we are similar to "Team>Synchronize with Repository". That action does the synchronization with the same progress characteristics. And the end result is also driven by preference (whether you switch perspectives when done, etc.) 2) ensure an hourglass comes up immediately when we decide to start a preload repo job. This gives the user immediate feedback that something is going on. The hourglass would disappear once the job was scheduled so the user could keep working. (Note that Team>Synchronize keeps the pointer/hourglass combo in the package explorer during synchronization and the normal cursor everywhere else, but we don't really have a triggering view for this operation so I don't see doing this.) 3) Leave the ellipsis on "Install New Software..." In that case, more information is required from the user to complete the operation. Whether you immediately get the dialog or first see a progress indicator or see nothing, the truth is that you have to supply new info to complete the install. Note this doesn't solve Martin's surprise that actual work happened before he was asked what to install, but at least there is feedback immediately. 4) Remove the ellipsis from "Installation Information..." That is more like a properties dialog or about, where the action itself is to see the dialog. More info is not required. Note this menu item will disappear once our dialog is hooked into Help>About (note the lack of ellipsis there, too). Kevin - what do you think with respect to the ellipsis decisions?
(In reply to comment #4) > I'm think we should do the following: > > 1) take the ellipsis off of "Check for Updates..." for these reasons: > > - no further input from the user is required, it is going to check for updates > as soon as you choose this menu. > - which dialog you see next and how soon depends on your preferences for > progress dialogs and whether the repositories are already loaded. Whichever > dialog you see next, it's the "result" or "progress" not something asking you > for more information. > - conceptually we are similar to "Team>Synchronize with Repository". That > action does the synchronization with the same progress characteristics. And > the end result is also driven by preference (whether you switch perspectives > when done, etc.) I noticed that iTunes also does not use an ellipsis.
Susan, I agree with your four recommendations in comment #4. Take the ellipsis off "Check for Updates". Their purpose is to inform the user that more input is required from them, which in this case it isn't. Their purpose is *not* to indicate a secondary dialog is going to appear, and in this case as noted may or may not happen based on preferences. I do have a concern though about feedback, or lack thereof, for running in background. The busy cursor flash is ok. I wish we could do more to draw the user's attention to the fact that work is happening. That's a general problem though not specific to this bug, so I logged bug #257139. In its absence we should still proceed with Susan's recommendations. Another option of course is to remove the ability to have them always run in background but others have noted that they seem to like this feature.
Fixed in HEAD >20081202. The addition of the hourglass is only marginally helpful, since the hourglass will only show in views that haven't reset the cursor. For example, if you choose one of the p2 menu items and that leaves your mouse pointer in an editor, you won't see the busy cursor, but if your mouse pointer is in another view, you'll see it. I mentioned before that the feedback is better if you have a particular view that triggered the operation.... > (Note that Team>Synchronize keeps the pointer/hourglass combo in the > package explorer during synchronization and the normal cursor everywhere else, > but we don't really have a triggering view for this operation so I don't see > doing this.) But we don't have one, so I really don't know how to make the feedback better for this particular case. I do like Kevin's ideas in bug #257139
verified on WinXP, Build id: I20081209-0100 during test pass (with the caveat noted in comment #7 - the hourglass is not visible if your mouse is in an editor)
