Community
Participate
Working Groups
Build ID: I20080530-1730 Steps To Reproduce: 1. Go to Help > Software Updates 2. The dialog box has an inconsistent/confusing layout compared to the rest of the UI for Eclipse for both the "Installed Software" and "Available Software" tabs. [See the more information section for explanation] More information: [Available Software Tab] The "Install" button is positioned at the wrong place. Currently it is positioned in the topmost position amongst a row of other buttons. Instead it should be positioned at the bottom right corner together with the "Cancel" button. I can't find the exact Apple Human Interface Guidelines (HIG) clause for this but this <http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGLayout/chapter_20_section_2.html#//apple_ref/doc/uid/TP30000360-CHDBBEIG> is close enough. It mentions that the action button has to be in the bottom-right corner. Having the "Install" button at the top-right corner is confusing since it is supposed to be an action to be performed for the entire dialog unlike the other buttons ("Properties", "Add site...", "Manage Sites...", "Refresh"). I think this applies for Windows/Linux as well but I am not familiar enough with their HIG to provide a link. The proper behavior was present in Eclipse 3.3/3.2 which makes me suspect that this was an honest mistake in creating the new Software Update dialog for Eclipse 3.4. The proper behavior is also maintained throughout the other dialog boxes in the Eclipse UI. [Installed Software Tab] The same argument applies to this tab. The "Update" button should be positioned on the bottom right corner together with the "Cancel" button.
The button placement is intentional and was settled on during HCI review (bug 229364). I don't quite see how the referenced guideline applies since this is not an alert dialog. There are several applicable long-running action buttons in this dialog. Note also that many of the Properties dialog pages have a similar button layout. In any case, passing along to our UI experts for further comment.
Thanks for forwarding this to the UI team. I realize that with HCI matters things can be rather subjective. Here are some addition comments why I think that button should be moved down to the bottom right corner. I am referring to this window as a dialog box because it seems to be "Application Modal" meaning that it takes control of the entire application and I cannot do anything else until I dismiss it. There might be a different term to refer to this particular UI element in the Eclipse parlance but I am not familiar with it. 1) Each of the other buttons ("Properties", "Add Site...", "Manage Sites...") in this new dialog box affects the contents of the table. For instance, clicking on "Properties" will reveal a new window based on the selection in the table. And clicking on "Manage Sites.." will open a new dialog that allows you modify what appears in the table. However, the "Install.." button is different. It does not actually affect the table at all. The "Install..." doesn't just install the currently selected element in the table, it installs everything that is currently checked. Moreover, it affects the *entire* dialog box - it lets you perform the *action intended* for this dialog: installing something. Therefore, I don't think it should be grouped with the other buttons which only affect the table and not the entire dialog. Now the question is where to put the "Install" button? According to the "Dismissing Dialogs" at <http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGWindows/chapter_18_section_7.html#//apple_ref/doc/uid/20000961-BABCAJID>: [As John commented, this section specifically talks about the Alert dialog but I think this can apply in general to all dialogs] "Usually the rightmost button or the Cancel button is the default button. The default button should be the button that represents the action that the user is most likely to perform if that action isn’t potentially dangerous...". And in this, the action that the user is likely to perform is to install something. After all, that is why a user would open this dialog in the first place! 2) Secondly, this new UI element seems to go against the layout of the previous "Software Update" window in Eclipse 3.3 and other dialogs in Eclipse 3.3. I realize that the previous "Software Update" window was actually a Wizard vs a dialog box but then it had a more consistent flow to it. It had well-defined pages for the steps and there were the "Finish" and "Cancel" buttons at the bottom right of the screen that let me know that I could always dismiss the wizard by clicking on those buttons. It was immediately clear the buttons on the bottom right corner would change the current view. The same arguments apply for the "Installed Software" tab. ----- Nonetheless, I realize that this new "Software Updates" is a new element. It is different from the Wizard in the previous versions of Eclipse so it could be that you want to design a new HIG to fit this new element. I can understand that. Perhaps you could let me know where else this new dialog is being used. That would help me understand the benefit of such a layout and where else it is being used consistently with good UI results. Again I am not a UI expert but this new dialog box seems to be rather confusing and inconsistent. I appreciate your time in looking in this matter and I completely understand if you wish to stick with the current UI. This UI has caused me some annoyances because I had (multiple times) accidentally clicked on the "Close" button when I actually intended to install something since I am accustomed to clicking on a button on the bottom right corner to perform an action. PS: I wasn't really sure what you meant by "Note also that many of the Properties dialog pages have a similar button layout...." Which properties dialog? I clicked on the "Properties" button in the "Available Software" dialog and the "Cancel" and "OK" button to dismiss the dialog appear at the usual bottom right location. I have not encountered a button that could close the current window/dialog that was not positioned near the bottom right corner. Thank you.
I was referring to other properties dialogs in the platform. For example if you right click on a java project and select properties, the Builders, Java Code Path, and Javadoc Location tabs have a similar button layout. Having said that, I think the Software Updates dialog is a bit unique. It is a bit like a wizard, except there are several wizard-like things you can initiate from the dialog (install, uninstall, update, revert....). So, it doesn't have quite the same linear progression as a wizard. Anyway, I'll let Kevin and Susan comment further. I believe they are doing a walthrough with the Eclipse UI design working group so this might be an interesting question to bring up.
Other factors to keep in mind: - We want similarity between the "Installed" and "Available" page. The installed page has two actions that affect the checked items..."Uninstall" and "Update". So placing the buttons at the bottom doesn't make sense there, and yet we want those two pages to be compatible. - Originally this dialog was modeless (a "dashboard"-like dialog) and implementation problems forced us to make it modal. One issue under general UI review is the modality of this dialog. And yes, we are doing a walkthrough on this design with one of the first issues being the general flow of the sequential/wizard approach used by UM vs. the current implementation, including issues of modality and such. Once we have a good story for the optimal workflow, things like button placement can be discussed in that context.
*** Bug 239713 has been marked as a duplicate of this bug. ***
*** Bug 239714 has been marked as a duplicate of this bug. ***
Assigning 3.5 milestone. The notes from the UI walkthrough in June are located at: http://wiki.eclipse.org/Equinox_p2_UIWG_Walkthrough There will be ongoing discussion/proposals about these workflows on the wiki and in a future walkthrough. Comments are also welcome here.
I'm working on a workflow proposal for how we might separate the available and installed software views, and integrate the installed view with the about dialog. It's still a work in progress, but the following section gives you an idea of how the button layout might change... http://wiki.eclipse.org/Equinox_p2_UI_3.5_workflows#Install_New_Software...
This bug will be addressed in M3 as part of the new workflows
work is in progress in the branch p2UI_WorkflowAndContributionReorg, in the projects org.eclipse.equinox.p2.metadata org.eclipse.equinox.p2.ui org.eclipse.equinox.p2.ui.admin org.eclipse.equinox.p2.ui.sdk
Created attachment 113763 [details] patch to pde target provisioner I'm running with this target provisioner patch in my workspace. It is no longer necessary to specify a repository manipulator when creating the available IU group.
Created attachment 113799 [details] Updated patch for pde.p2.ui plugin Updated patch so that it applies to HEAD. The new UI API for the most part works and is simpler in code, so it's definitely a good thing. However, the checkboxes now show up in the UI (they didn't before), so I had to change my validation code to use checked ius rather than selected ius. This wasn't a problem and frankly makes more sense, but I did find a bug. If I check a site, even though all of the children are checked, getCheckedLeafIUs() returns an empty set. As soon as another selection is made, the correct set of checked elements is returned.
Thanks for trying this so fast, Curtis. > However, the checkboxes now show up in the UI (they didn't before), so I had to > change my validation code to use checked ius rather than selected ius. Yes, when I first added the checkboxes I made it configurable (and you had to explicitly ask for checkboxes in the more specific constructor, hence PDE didn't get them). This is all historical junk, so while cleaning up this code I'm trying to remove old options that don't make sense anymore. So I have code that mocks up a selection provider that looks like a normal selection provider but is really mapping the checkboxes into selection events. On my to-do list was figuring out if this was needed anymore and what impact that would have on clients (as you found). I'm hoping it will be explicit, where clients will have to distinguish between selection and check, as you assumed, and I'll remove the mapping selection provider. >This wasn't a problem and frankly makes more sense Good, I was hoping you'd see it that way > but I did find a bug. If I > check a site, even though all of the children are checked, getCheckedLeafIUs() > returns an empty set. As soon as another selection is made, the correct set of > checked elements is returned. Thanks, I'll look into that...I have some cleanup to do surrounding the selection provider, etc.
I opened up bug #249545 against PDE to track the changes caused by this work. I'll put a modified patch in that bug and we can discuss details there.
I've released the first set of workflow changes into HEAD >20081007. It implements the split depicted in http://wiki.eclipse.org/Equinox_p2_UI_3.5_workflows#Install_New_Software... which helps with the button confusion in the Available Software view. However the installed view still has button layout issues, which need to get resolved in the context of bug 246875.
(In reply to comment #15) > I've released the first set of workflow changes into HEAD >20081007. > > It implements the split depicted in > http://wiki.eclipse.org/Equinox_p2_UI_3.5_workflows#Install_New_Software... > which helps with the button confusion in the Available Software view. > > However the installed view still has button layout issues, which need to get > resolved in the context of bug 246875. > Moving milestone to M4, as that is when the corresponding work will happen in bug #246875. Leaving this bug open for now to represent the changes that will need to be made to the p2 contributions to achieve a decent button layout.
I just wanted to say that the changes so far make a huge difference. I'm not sure for example if everyone appreciates how much easier it is to tell a user to select the "Install New Software.." item on the help menu then it was under prior versions. Yes, I can see that for some people who already understand how P2 works, the UI might seem duplicative but for most users it is much more task oriented and I really think it will go a long way to overcome the cognitive dissonance that my users have been experiencing. I also want to say how useful and transparant the workflow process has been as I've seen noted elsewhere. I think this could be a real model for how the Eclipse community plans for complex UI interactions. Unless you really understand what the users want seperate from the context of existing or planned UI, and then accomodate them, you're going to end up with somethign that makes sense to p2 (or more broadly Eclipse PDE) developers, but not to the broader commmunity. So +10 to the p2 team.
thanks, Miles, the feedback really helps. From a technical point of view, it's easy to say, "what's the big deal, we just moved some stuff around a little." But trying to solicit the input and figure out what people expect/want is the hard part! Let us know if you have any thoughts wrt to your users on some of the remaining workflow issues. For example, we still have button/task layout issues in the installed software dialog, but at least less users should have to go there to do anything apart from look at the information. We're also concerned/looking for feedback on bug #250316. If we do our job right, users wouldn't need to worry about sites unless they are adding new software, but I'm not sure we're there yet.
*** Bug 256567 has been marked as a duplicate of this bug. ***
update: integration of the "Installation Information..." dialog into the Help>About dialog will probably happen in the next I-build. In the meantime, is there any feedback with respect to the button placements for update, uninstall, and revert? Does the layout at the bottom help? What about ordering? These buttons are layed out by the common about dialog, so we don't have complete control over the layout, but we can control the ordering and consider any other layout advancements that might make sense for all of the about dialog pages.
moving to M5 awaiting completion of bug #246875 and subsequent feedback.
moving to M6 awaiting completion of bug #246875 and subsequent feedback.
Marking fixed along with the release of the common about dialog in bug #246875. Installation pages can now contribute their own buttons, which are layed out to the left of the Close button with some additional spacing provided between the page buttons and the close button. The Installed Software page layout is now fairly similar to the layout used in the "About Features" and "About Plugins" dialogs. Admittedly these button layouts are still not typical, but they are at least consistent with each other and there is a bug open (bug 265212) to discuss further development of the layout for installation pages.
