Bugzilla – Full Text Bug Listing
| Summary: | [ui] Additional IU affordances in the software updates dialog and install wizards | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Susan McCourt <susan> |
| Component: | p2 | Assignee: | Susan McCourt <susan> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | clin, david_williams, john.arthorne, Kevin_McGuire, max.gilead, milesparker, pascal |
| Version: | 3.4 | ||
| Target Milestone: | 3.5 M5 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Susan McCourt
Marking 3.4 so it stays visible, but this is just a "nice to have". The next/finish buttons will already indicate whether signing and licenses are there and must be dealt with, but this would be cool if they could see it all at a glance up front. removing 3.4 milestone. Nice idea, but won't make feature freeze. Other affordances: - something that indicates whether something is already installed, is an upgrade of something already installed, etc. Renaming as this now collects ideas for affordances for IU's across the UI (the main dialog and the wizards). *** Bug 228795 has been marked as a duplicate of this bug. *** cc'ing Kevin for any additional ideas *** Bug 236368 has been marked as a duplicate of this bug. *** Looking at this for M5. Which affordances are the most useful and where? What should the affordances be? 1. I think the most important thing is helping the user notice things in the available software view to help navigate through possible large lists of things. We've done some improvements in M4. There is now code in place to distinguish these three states: - you've never installed this, might be of interest - you have an older version than this installed, this is an upgrade - this is something you have already installed (or older), not of interest We currently filter out the latter (or else use the gray icon if not filtering) but don't differentiate between these first two. Should we introduce a column to show an icon representing these states? Or introduce a column for only one state (such as "this is an upgrade!") and use the existing filter/color to distinguish things already installed? Some Linux package management software uses color of the items themselves to distinguish these, but I think we need a combination of color and affordance. 2. By the time we get to the second page of an update/install wizard, we know if there are licenses that need to be approved. How important is it to show this affordance ahead of the user actually getting to the license page? (This was the original suggestion). (In reply to comment #8) > - you've never installed this, might be of interest > - you have an older version than this installed, this is an upgrade > - this is something you have already installed (or older), not of interest > > We currently filter out the latter (or else use the gray icon if not filtering) > but don't differentiate between these first two. Should we introduce a column > to show an icon representing these states? Or introduce a column for only one > state (such as "this is an upgrade!") and use the existing filter/color to > distinguish things already installed? It's useful to call out upgrades. I may be in the wizard to find new things assuming I was up to date. Discovering that there's an upgrade allows me to combine these tasks (which I'm highly likely to do especially to avoid dependency issues with getting the new case A stuff). I like the fact we filter out already-installed/nothing-to-do by default. I'm not really clear why someone would flip that option. However, for whatever reason I did, I'd like to spot them. As an aside: that option currently reads, "[ ] Include items that have already been installed" with default state unchecked. But the one above it is, "[X] Show only the latest versions" with default state checked. I think the first should be reversed, like, "[X] Hide items that have already been installed" so they match (when I see some things checked and some not I assume I changed it). I mention this in this bug because I think if we add affordances to call out these cases, then it's maybe helpful if there's more parallel-ness (affordances call out unusual state that you unfiltered). > Some Linux package management software uses color of the items themselves to > distinguish these, but I think we need a combination of color and affordance. You might consider - black (normal) for never installed - green for upgrades - gray for already installed You could treat the icon and/or the text. I'd recommend we start with just the icon. This should be enough and we don't generally use colored text. > 2. By the time we get to the second page of an update/install wizard, we know > if there are licenses that need to be approved. How important is it to show > this affordance ahead of the user actually getting to the license page? (This > was the original suggestion). My concern would be the clutter this could generate. I guess the question is, "How important is it to know the licenses beforehand?". We'd need to know the occurance of people getting to the license then quiting the install. Thanks for the comments, Kevin. I agree that right now the most important thing is calling out important stuff in the install list. Since we can distinguish the three states in the model elements, I added a graphic for the "update" of something. It's very subtle. I superimposed the "update" arrow that shows in the status bar when updates are available on top of the normal icon. I also faded the colors on the normal icon a bit so that the update icon would stand out. It is still very subtle, but I'm going with that for M4. For M5, I'd like to see us revisit these graphics completely. The icons used are from Update Manager, and they are very "plug-in" oriented. Now that we know we want to show these three different states for "things you can install," we might also look at simplifying the icon so that these states can be shown more easily and perhaps get away from the "plug-in" look. Just rechecked some of the Update Manager artwork and chose an "updates" icon they use that replaces the plug-in completely with the update arrows. This helps the state difference stand out, although I still think we want to come up with a different theme completely. (In reply to comment #9) > I like the fact we filter out already-installed/nothing-to-do by default. I'm > not really clear why someone would flip that option. However, for whatever > reason I did, I'd like to spot them. Not to complicate things even more, but Pascal and I were discussing the specific meaning of "Hide items that have already been installed." For example, the user installs GMF, which includes GEF. In Eclipse 3.4, we never indicated anywhere that GEF got installed. This helped some users and angered others, so we developed some user personas to help clarify. The 3.4 approach keeps things simple for users like Ellen, but Laurel thinks we have a bug because she knows GEF is installed (by function contributed, presence of the plug-ins themselves, knowledge of GEF, whatever). One major goal/challenge for Eclipse 3.5 was to try to satisfy both Ellen and Laurel. We are doing this with drilldown detail. (Ellen can ignore it, Laurel will use it). So in M4, when Ellen installs GMF she can drill down in the wizard to see GEF, but probably won't. Laurel will. Likewise, in the "Installation Information" page, GMF is shown at the top level. Ellen will never notice GEF (if she even ever goes to that page at all!), while Laurel will take advantage of drill-down to understand why GEF is there. So the question becomes...are we allowing the user to "Hide items that have already been installed" or "Hide items that I have installed" In other words, is GEF filtered out? In M4, I use the same filters..whatever the user can see in the installed list is filtered out (even the drill-down items). I think Laurel will like this because she understands that GEF is already installed. Ellen won't care. But perhaps Steve hears about "this GEF thing" and decides to install it, adds the GEF site, but nothing shows up in the list. Would he ever know to toggle the filter? He never cared before that GMF required GEF, never drilled-down. Now what? Pascal suggested we only filter out what *I* installed so that users like Steve can still see GEF, and that selecting GEF and installing it would result in a successful operation. Underneath, we would simply mark GEF so that it is now at the top level of the install list, not just a requirement. Steve and Ellen would be happy (Ellen is ignorant of the whole problem, Steve is lead to believe that what he wanted happened, even though it was already so)... This could confuse Laurel...why are you letting me install GEF, I know I already have it! What do we do for Laurel. Is there a subtle affordance we should use to differentiate things that *I* installed vs. things that *are* installed? Something Ellen and Steve won't notice but that might make Laurel understand better what is going on? What we choose to filter and signal in the affordances also affects what we do downstream in the wizard. Laurel or Steve selects GEF and presses Next Should the wizard - install GEF as if nothing strange happened at all - use an info status to report "Parts of GEF are already installed because of GMF. The remaining parts will be installed." > As an aside: that option currently reads, > "[ ] Include items that have already been installed" > with default state unchecked. But the one above it is, > "[X] Show only the latest versions" > with default state checked. I think the first should be reversed, like, > "[X] Hide items that have already been installed" Agree, and I even think the wording of the latter matters with respect to what we filter. If we decide to filter out only what the user has installed, then I think it should read [X]Hide items that I have already installed cc'ing Miles - any input on this? (John has suggested that we may want to rename our user persona "Dave" to "Miles") ;-) There is related discussion happening in bug 255984 comment 8. I don't know -- Dave sounds kind of boring. ;-) (In reply to comment #12) > For example, the user installs GMF, which includes GEF. In Eclipse 3.4, we > never indicated anywhere that GEF got installed. This helped some users and > angered others, so we developed some user personas to help clarify. Who was angered? Laurel? I think she understands software dependencies.. OTOH, if I know that hmm I won't mention names, but ComponentX breaks everything, I might have second thoughts. What about -- along lines of uninstall.. (User seescan finish at this point, but if she or he selects next, sees.. (Info box? I also dislike warning in this case..) "GMF requires the following components. They will be installed with GMF." "GEF" > So the question becomes...are we allowing the user to > "Hide items that have already been installed" or > "Hide items that I have installed" The former I'd hope. As in uninstall, I just don't care for the idea of differentiating between these. Who is "I"? Would this state really be kept between sessions? What about.. "Show only top-level (major?) components." > In other words, is GEF filtered out? In M4, I use the same filters..whatever > the user can see in the installed list is filtered out (even the drill-down > items). I think Laurel will like this because she understands that GEF is > already installed. Ellen won't care. But perhaps Steve hears about "this GEF > thing" and decides to install it, adds the GEF site, but nothing shows up in > the list. Would he ever know to toggle the filter? He never cared before that > GMF required GEF, never drilled-down. Now what? I'm not sure I see the issue. I think Steve would also be sophisticated enough to look at installation information to see if he already had. he understands software, just not the Eclipse specifics. As you say Ellen won't care. > Pascal suggested we only filter out what *I* installed so that users like Steve > can still see GEF, and that selecting GEF and installing it would result in a > successful operation. Underneath, we would simply mark GEF so that it is now .. > This could confuse Laurel...why are you letting me install GEF, I know I > already have it! Laurel is exactly right again. We need to educate Steve, not pander to him. :) I do not like the idea of changing around hierarchy at all. This sort of makes me wonder about the whole idea of combining Update and Install. See discussion in related bug but fundamentally we are trying to represent something that is hard in a simplified way. Let me go way off on a tangent here.. The fundamental issue is that Eclipse for better or worse doesn't have a formal system of usage levels. For an OS, I know if I am installing XYZ and only if I am a fiddler do I care what the non-top level pieces are. If I'm installing a Widget or a Photoshop plugin, I will also know about that, because I want to use "Advanced Image Effects". Eclipse doesn't do this and that is where a lot of confusion comes from. It should have a user-centric view. We need to differentiate "tool" from "enablement". *And those are orthogonal to current product structure. Its like the difference between "Industry" and "Market". Ellen (and perhaps Steve) don't care at all about GMF unless some systems administrator is helping them diagnose. They care about wether they can "Edit UML" or "Design Web Pages". If they uninstall UML and that uninstalls GMF, and that uninstalls GEF and that makes "Project PERT charts" suddenly no longer function, they want to know that. My fundamental user issue is when I tell Ellen/Steve that I want her to install my N-Dimensional Visualization Package. I'm trying to keep a product level focus for my plugins. That's going to need some other pieces from GMF, but also an outside project (e.g. oAW). This is the point where Ellen just doesn't care and Steve gets frustrated. Especially when they go to uninstall it and they find that that they need to uninstall "GEF" and "WTP Whatzit". "Well, if I get rid of "GEF" what else can't I do? This should be a major topic for E4 I'd think. > What we choose to filter and signal in the affordances also affects what we do > downstream in the wizard. Laurel or Steve selects GEF and presses Next > > Should the wizard > - install GEF as if nothing strange happened at all > - use an info status to report "Parts of GEF are already installed because of > GMF. The remaining parts will be installed." The latter. > > "[X] Hide items that have already been installed" > > Agree, and I even think the wording of the latter matters with respect to what > we filter. If we decide to filter out only what the user has installed, then I > think it should read > [X]Hide items that I have already installed Again, I see the user oriented logic, but it conflicts with my sense of transparency and predictability as the ultimate simplifying assumption. (In reply to comment #14) > The latter. > > > > "[X] Hide items that have already been installed" > > > > Agree, and I even think the wording of the latter matters with respect to what > > we filter. If we decide to filter out only what the user has installed, then I > > think it should read > > [X]Hide items that I have already installed > > Again, I see the user oriented logic, but it conflicts with my sense of > transparency and predictability as the ultimate simplifying assumption. OK, see my response in uninstall discussion, but Susan's explanation there makes this more sensible to me. I think what bugs me about this is simply that the user themselves may not have taken the install action, so its not always truthful. :) Perhaps a simple change like "Hide My Installed Items". Hopefully the subtle distinction is clear. Let me add my two cents as a regular user ;) (In reply to comment #12) > already installed. Ellen won't care. But perhaps Steve hears about "this GEF > thing" and decides to install it, adds the GEF site, but nothing shows up in > the list. Would he ever know to toggle the filter? He never cared before that > GMF required GEF, never drilled-down. Now what? Maybe include a notification popup (ideally Firefox-style 'Do you want to remember this password?' sliding popup-alike?) saying 'This install site contains some components that are already installed. Click _here_ to show them'. Showing empty list would be bad idea. Including a 'show already installed items' checkbox is some solution but not very user-friendly (I see you really care about less experienced users) so a popup might be the best idea. Useful for advanced users, clearly stating what's going on for newbies. > Pascal suggested we only filter out what *I* installed so that users like Steve > can still see GEF, and that selecting GEF and installing it would result in a > successful operation. Underneath, we would simply mark GEF so that it is now > at the top level of the install list, not just a requirement. No, please don't do that. It would be extremely confusing for advanced users who e.g. might have legitimate reasons for reinstalling a component. > Is there a subtle affordance we > should use to differentiate things that *I* installed vs. things that *are* > installed? I personally doesn't care and am only interested in what *is* installed, no matter if it was a dependency or my explicit action. > Should the wizard (cut) > - use an info status to report "Parts of GEF are already installed because of > GMF. The remaining parts will be installed." That sounds like a reasonable idea. > If we decide to filter out only what the user has installed, then I > think it should read > [X]Hide items that I have already installed Maybe it's just me but why is difference between what I installed and what is installed important? (In reply to comment #16) > > If we decide to filter out only what the user has installed, then I > > think it should read > > [X]Hide items that I have already installed > Maybe it's just me but why is difference between what I installed and what is > installed important? I think I figured that distinction out but it took me a few minutes. Correct me if I'm wrong, but P2 team is basically talking about an idea to base presentation on their gestalt. That is, "I" (someone) installed "SuperABC" on my machine. That happened to include GMF and GEF. But the user only *chose* to install SuperABC. So when we present the uninstall choices back to the user, we want to show them "SuperABC" not SuperABC, GMF, and GEF. "Where did that come from?" OTOH, a technical user who *chose* to install GMF and GEF would be shown those as well. I have mixed feelings about this but absent some higher level product oriented classification, it makes some real sense. But if distinction is confusing to us, it is going to be totally lost on new users. Perhaps it should explicitly say "Hide Prior Installed Items". Or perhaps on the other end of specificity just have an "Advanced Users.." or "Show Previous Installs" button. Or other way around something like "Suggest" that is on by default. This would alert user and others that this mode is simply there to make things simpler for the user. Because it does worry me as well that we can end up with two different machines, with the exact same configuration, showing two different setups. This is the kind of thing that gives Dave nightmares. Again, any simplificaiton like this has to have a lot of cues that it is just that. (In reply to comment #16) > Let me add my two cents as a regular user ;) > > (In reply to comment #12) > > already installed. Ellen won't care. But perhaps Steve hears about "this GEF > > thing" and decides to install it, adds the GEF site, but nothing shows up in > > the list. Would he ever know to toggle the filter? He never cared before that > > GMF required GEF, never drilled-down. Now what? > Maybe include a notification popup (ideally Firefox-style 'Do you want to > remember this password?' sliding popup-alike?) saying 'This install site > contains some components that are already installed. Click _here_ to show > them'. > > Showing empty list would be bad idea. Including a 'show already installed > items' checkbox is some solution but not very user-friendly (I see you really > care about less experienced users) so a popup might be the best idea. Useful > for advanced users, clearly stating what's going on for newbies. Interesting. Kind of like the "you have Caps Lock on" floater when a password fails. This would suggest an alternate solution to bug 258105. > I personally doesn't care and am only interested in what *is* installed, no > matter if it was a dependency or my explicit action. > > > Should the wizard > (cut) > > - use an info status to report "Parts of GEF are already installed because of > > GMF. The remaining parts will be installed." > That sounds like a reasonable idea. > > > If we decide to filter out only what the user has installed, then I > > think it should read > > [X]Hide items that I have already installed > Maybe it's just me but why is difference between what I installed and what is > installed important? There is a long discussion of this topic in bug #224472, but the basic statement is that "one man's major component is another man's implementation detail." So when showing the installed components, we have to start somewhere, and we currently start with what was selected/installed via the user (and a product build can designate what top level items are shown before the user does anything). From there we drill down into more detail. (In reply to comment #17) > Because it does worry me as well that we can end up with two different > machines, with the exact same configuration, showing two different setups. This > is the kind of thing that gives Dave nightmares. Again, any simplificaiton like > this has to have a lot of cues that it is just that. This is a really important point. Marking fixed. We've done everything we're going to do with respect to affordances and filtering for now. The work is described in comment #11. There was discussion of making new artwork, but I'd like to get more user feedback before embarking on this. A separate bug can be opened if this becomes important. There were two other important suggestions in this bug that I have moved to other bugs. - Max suggested using a floater/helper to cue the user when the available view is empty due to installed software being filtered out. I generalized bug 258105 to incorporate that suggestion, as it was dealing with a similar issue. - Miles is concerned that using the user's install choices as the roots of the "Installed Software" tree could mislead a system administrator. I moved this to bug 246875, where we are putting all the system views together in the about dialog. I think the original intention of this bug (to filter and provide affordances for what's installed, what is an update, etc.) has been addressed. |