Community
Participate
Working Groups
In the new workflows, the user can get to the manage sites dialog from the install wizard. How does the user get here when checking for updates? Should the site list also appear in the preferences? Should it be accessible from some other command? Note this will be influenced by how we choose sites when searching for updates (bug #234213) and also how we present sites in general (bug #218534). Note that whatever we do here needs to be an optional contribution so that products that don't let users touch sites can configure this out. Likely a pref page contributed by ui.sdk
marking M5 for now, since the final answer depends on other issues. However we may find ourselves needing a temporary solution (pref page?) in the intermim.
OK, this is going to sound funny, but I think the first thought Laurel is going to have is "Why isn't the software I want listed here?". (Well, maybe she hasn't had her coffee yet.) Its not at all clear that "Add Site.." would be the obvious choice to find additional resources. "What's a 'site'?" So before anything else, I think the site management process within this dialog needs to be a lot more transparent and obvious. OTOH, nobody has found a good solution in the past. IIRC (trying to forget) p1 had a wizard approach were you identified the sites first. Then we had the approach in the universal dialog where sites were by default top-level for the checkboxes == no separation of concerns. So a couple of thoughts.. 1. Keep the "new software" flow continuing. a) So something like "Find Software At..". but *not* as a side button. I don't think people see side-oriented buttons as things that need immediate attention. So perhaps the head of a combobox that listed all of the current sites. Yes, it might get long and ugly, but plugin developers have got to be encouraged to clean up there act with regard to site names. b) Or have a label "Search for software at.." with Combobox below where default first item is "Ganymede" (And really it should say something like "Eclipse Project"). Then the last item could say something like "Somewhere else.." 2. As a simpler change... Make the selection of "Site, Category, Name" more obvious. It might be my Cocoa UI but I actually missed that option until I explored a bit more just now. Consider a set of radio buttons or something and maybe put them in front of filter. As a more outrageous / ambitious idea, why not have a top-level category system that includes external sites? Eclipse foundation could allow people to submit sites and then would list them under very high-level categories ala Eclipse Plugin Central. Why should Laurel have to google for some obscure site name copy it out of a webpage somewhere, click add site, paste it in click ok and then get an error because she missed part of the URL? This would get around licensing issues and alone would take care of my one most annoying task which is googling for the subversive update sites, getting misdirected, and so on. This likely involves Eclipse Foundation policy issues, but would be huge in terms of user acceptance and plugin growth. The App Store adds an enormous benefit to the the iPhone ecosystem.
I was thinking it should automatically search for updates with the sites it has available. If nothing is found, then the "No updates found" dialog could optionally have a button to add more places to search and then repeat the process. This way the workflow is simple for applications that have their sites pre-populated, and there is a clear path to add a site in cases where there isn't a site already in the list. Alternatively the extra button could guide the user to a preference page where the list is configured. This has the advantage of teaching them where to go to add sites. For the case of Ellen we don't want to expose her to this kind of functionality so there needs to be a way for a product to configure this (such as a preference that doesn't appear in the UI but can be set by a product in plugin_customization.ini.
(In reply to comment #2) > > 2. As a simpler change... Make the selection of "Site, Category, Name" more > obvious. It might be my Cocoa UI but I actually missed that option until I > explored a bit more just now. Consider a set of radio buttons or something and > maybe put them in front of filter. You're not the first to miss that. See bug 227789. > > As a more outrageous / ambitious idea, why not have a top-level category system > that includes external sites? Eclipse foundation could allow people to submit > sites and then would list them under very high-level categories ala Eclipse > Plugin Central. Why should Laurel have to google for some obscure site name > copy it out of a webpage somewhere, click add site, paste it in click ok and > then get an error because she missed part of the URL? This would get around > licensing issues and alone would take care of my one most annoying task which > is googling for the subversive update sites, getting misdirected, and so on. > This likely involves Eclipse Foundation policy issues, but would be huge in > terms of user acceptance and plugin growth. The App Store adds an enormous > benefit to the the iPhone ecosystem. There are some efforts going on involving "composite repositories" that aggregate content from other sites, but we haven't yet made the leap that these will support recategorization, etc. We also realize our usability could be greatly affected by things outside of the UI itself such as more helpful naming and categorization. There are some efforts underway to try to address this, at least for the participants in the Galileo release train. Bug 250745 discusses some of this, though it is also focused on technical details of the builds, etc. (In reply to comment #3) > I was thinking it should automatically search for updates with the sites it has > available. If nothing is found, then the "No updates found" dialog could > optionally have a button to add more places to search and then repeat the > process. This way the workflow is simple for applications that have their sites > pre-populated, and there is a clear path to add a site in cases where there > isn't a site already in the list. > > Alternatively the extra button could guide the user to a preference page where > the list is configured. This has the advantage of teaching them where to go to > add sites. For the case of Ellen we don't want to expose her to this kind of > functionality so there needs to be a way for a product to configure this (such > as a preference that doesn't appear in the UI but can be set by a product in > plugin_customization.ini. > This specific suggestion is tracked in bug 232107. And I agree we have to be careful about how we expose that, I'll make a note in that bug.
In bug #258132 we are discussing exactly how the UI prevents the user from trying to install/update/uninstall something while another p2 operation is in progress. The UI generally disables the actions that do this, and the bug is that we need to disable the handlers or else have them say "can't do this while you're installing something else." Problem is...if you can't open the wizards at all, then there would be no way to play with site management while some other operation is going on. In my case I was in the middle of a long upgrade and I wanted to export my site list for a different bug. Chicken/egg situations like this seem to confirm the suggestions made here and elsewhere that we put the site list in the preferences (see comment #0, comment #3, etc.) This way, the sites are always accessible from a top level construct independent from the particular workflows. We would link to the page where appropriate - from the "updates not found" message - from the Available software list - other places where we decide to make site suggestions This has the added benefit that we guide the user to a known place, preferences, vs. some random dialog that pops up. Also note that the goal is to have the UI code structured so that other product configurations could put the site view somewhere else if they decided to do so. (In reply to comment #2) > OK, this is going to sound funny, but I think the first thought Laurel is going > to have is "Why isn't the software I want listed here?". (Well, maybe she > hasn't had her coffee yet.) Its not at all clear that "Add Site.." would be the > obvious choice to find additional resources. "What's a 'site'?" Having a preference link also gives us more verbage to use to explain the link such as "Click here to control the sites that are searched for available software." This might help with Miles' concern. Such a pref page would also be a place to configure site-related preferences such as enabling discovery of new sites, etc. Thoughts, anyone?
cc'ing Kevin for comment.
Another scenario where this workflow is annoying and where a pref page would help: - there is a slow/dead site that I'm tired of dealing with - I want to delete it - I launch Install New Software so that I can click "Manage Sites..." and delete it, but arrrgh...I have to first wait for all the sites, including the slow one, to load. If I could just delete it from the preferences, life would be simpler.
Yes, I like it. Here is one more case that drives me crazy. Sometimes I want to just delete or modify a site without actually downloading anything. This happened recently for example because I was trying to install tasktop and a bug in M3 caused validation to fail. So you click on Installation Information and the Manage Sites, and then make the change. But after dismissing Manage Sites, the finish button is not highlighted. I have to cancel. That feels really weird. And what happens if I made a mistake? Persistence does this correctlym with the Apply / Defaults and OK Cancel setup. In fact, the more I think about it the more I think that there is no good justification for *not* having it part of the preferences system. There is the counter example of team tools, but I'm now also wondering why not? Oddly, you *can* specify passwords for sites there. Site location is persisted information. Persisted information should be part of some kind of consistent transparent management structure. In Eclipse those are basically workbench resources and the preferences store. There are odd cases like View mementos, but that again I think is a piece that should be exposed in some way as well.
+1, as I mentioned in comment #3 I like this. There are likely product scenarios where people want to lock down the sites, which they could presumably do by omitting the preference page (not sure if there is a mechanism to allow RCP apps to control preference page visibility).
> +1, as I mentioned in comment #3 I like this. There are likely product > scenarios where people want to lock down the sites, which they could presumably > do by omitting the preference page (not sure if there is a mechanism to allow > RCP apps to control preference page visibility). Perhaps another strategy would be to simply not include the P2 UI, right?
I've done a mockup of what the sites dialog would look like when moved to the preferences page. It is based somewhat on the existing "Help>Content" page, which is providing very similar function. http://wiki.eclipse.org/Equinox_p2_UI_3.5_workflows#Repository_Management Please provide feedback in this bug cc'ing some of the Help guys in case they have known usability complaints with their existing approach. Do you think your pref page is a good model for us or is this an area where you have usability issues?
I like it. Assume you will have some sort of link from installation page to allow users to add new sites. Or perhaps they can have a simple prompt to add new sites from installation and are referred to site page for more complex management? I agree w/ comments on commonality of look for various preference pieces. As an aside, I think "preferences" name is under-loaded. There is really much more covered -- basically all environmental stuff in this interface. A topic for E4 perhaps.
(In reply to comment #12) > I like it. Assume you will have some sort of link from installation page to > allow users to add new sites. Or perhaps they can have a simple prompt to add > new sites from installation and are referred to site page for more complex > management? I was assuming a link that was more than just "manage sites..." but something like "Click here to work with the list of available software sites." I was also wondering about having an add site... button, but I was little scared off by your previous comments on this: (In reply to comment #2) > OK, this is going to sound funny, but I think the first thought Laurel is going > to have is "Why isn't the software I want listed here?". (Well, maybe she > hasn't had her coffee yet.) Its not at all clear that "Add Site.." would be the > obvious choice to find additional resources. "What's a 'site'?" Or is it just a terminology problem? Would you like to have an add button here but not call it a site? > > I agree w/ comments on commonality of look for various preference pieces. As an > aside, I think "preferences" name is under-loaded. There is really much more > covered -- basically all environmental stuff in this interface. A topic for E4 > perhaps. I opened a platform UI bug on the particular inconsistencies that I noticed in bug 258380
(In reply to comment #13) > I was assuming a link that was more than just "manage sites..." but something > like "Click here to work with the list of available software sites." Right. I like the Hyperlink model that a few components use. For example if you select any project settings tabs you'll see a "Configure Workspace" link that when clicked shows a filtered preferences page. > I was also wondering about having an add site... button, but I was little > scared off by your previous comments on this: > > Or is it just a terminology problem? Would you like to have an add button here > but not call it a site? Yep, that's what I meant. See suggestion a. "Find Software At..". Or maybe "Look somewhere else.. (Another software site or downloaded plugins.)" Can do better than that, but that's the idea.
Created attachment 120640 [details] mockup of wizard with link for repo management This screen snap shows some code I'm hacking in my workspace, which changes the layout of the install wizard. It addresses several related problems. - changes "Manage Sites..." to a task-oriented link - changes layout of dialog to move from buttons to links - moves the links to Properties and Installation Information closer to where they make sense - gets rid of the subtle "view by" menu and replaces it with a "use categories" checkbox. The site view will no longer appear in the wizard - the resultant layout gives more space for the item names, which especially helps in cases where something important was at the end of an IU name (like "Incubation") More info at http://wiki.eclipse.org/Equinox_p2_UI_3.5_workflows#Moving_Repo_Management_out_of_the_Install_Wizard thoughts?
Kevin and I chatted a little about this. No conclusions yet but I wanted to capture some salient points. - deemphasizing sites seems good - Kevin believes a user should be able to use the mainstream product functionality without ever having to go to prefs. So not sure about prefs vs. a special site dialog. (Implementation note: Not all sites are stored in prefs so exporting prefs won't necessarily do the expected/same thing as exporting sites via p2.) - In places where we propose to link to the site list, consider instead a fast-path to the specific task. Usually the user wants to add a site. So make it easy to do that task, not just link to sites. Another example: if a site is not found/offline, let the user disable it from the error dialog rather than just link to the site list to manage it. For "updates not found," it is probably best just to go to the site list because there's not a clear alternate action. In the end, we think the main use case to consider is this one. Steve wants to run coverage tests and someone tells him "use Eclemma" and they send him the link to the Eclemma site. Steve rarely adds software, but when he does, it needs to be simple and obvious how to do it. He wants to be able to specify the eclemma site somewhere and have only Eclemma things show, or at least make it easy to see the Eclemma things. Points to consider: - this kind of task, though rarely performed for a user like Steve, is the very first experience he'll have with the p2 UI. - it's good to try to make sites invisible but then you need this starting step of being able to tell the system about new places to find stuff - it's ok to make sites a secondary thing in the Avail Software page but you can't make them go away completely because too much of the user task is tied to them. You can't make users know about them to say, find Eclemma, then try to pretend they don't exist, it leads to a discontinuity for the user's mental model. - A large population of users won't be allowed to install from new sites, so whatever we do in the wizard to make Steve's task seamless and consistent can't permeate the wizard with site concepts that will cause discontinuity for Ellen The best idea I have right now is to replace the "Find more software by working with Available Software Sites" link with a text field where the user can type/drop/paste and do quick-add. Something like: Find software here: [ entry field ] where the entry field is a paste and drop target and if the user leaves focus/hits enter, the site gets added and all the software from that site is made visible. We discussed instead some kind of combo/dropdown filter on the view Show software at: [All Sites] <add site> but this seemed too confusing and heavyweight.
Looks good. Assuming that all of the wording isn't finalized but general flow and look are exactly on. The only remaining workflow issue that I can think of -- and it conflicts with other goals and comments -- is that it would be nice to make things a little more direct for Steve and Super-Ellen who have the following brief case: Grab an Eclipse distro, and then install some customized bit of software on top of it. The only reason that I bring this up is that I tend to think in terms of "how many screenshots do I need to produce to tell someone how to do this?" The screenshot size is way down, but there are a lot of steps to take. I think perhaps this argues for retaining some kind of quick add site functionality. This is pretty common in the team stuff, where repos do exist elsewhere but you can add one inline. One rather lame idea.. For "Find more software by adding".. Change to.. "Look for software at [*Places I've visited*, "Somewhere else..."]" * [Link] Select _Available Software Sites_ *I don't know what widget if any works. Ideally a text box so that you could actually enter a site name *directly* into dialog. popup? Alternative is.. *Looking for software in places I've visited" _Somewhere Else_ which changes to: *Looking for software at http://eclipsehacks.com" _Somewhere Else_ As I said, lame, but it would be great if we could get down to two screenshots here!
(In reply to comment #17) > Looks good. Assuming that all of the wording isn't finalized but general flow > and look are exactly on. > > The only remaining workflow issue that I can think of -- and it conflicts with > other goals and comments -- is that it would be nice to make things a little > more direct for Steve and Super-Ellen who have the following brief case: > > Grab an Eclipse distro, and then install some customized bit of software on top > of it. Yes, I think this is the same use case I was trying to describe with "Steve hears about Eclemma." I've been hacking a bit on this problem this afternoon. The attached screenshot will show what I have working right now. It's a combo you can use to filter which repos you are looking at. Or you can drag/paste a new URL in there. If you drag, the view will immediately add the site and filter on that site content. If you paste, you'll need to push the add button and then it will add and filter it. Likewise with typing. If you push add when nothing is typed (or an already existing site is selected), you'll get the add dialog. That gives you one screenshot, I think, depending on how you count them. The downside is it's a lot of site-based clutter for users who don't care. But if the product is configured where repo management isn't allowed, that stuff will disappear from the top. I tried layouts where it was on the bottom and it didn't work (was ugly and you lose the point that the filter controls the list). I think we are converging here.... Kevin and I talked about this also, and felt it might be heavyweight but I think it's the only way to solve the problem of having a "quick add" and also provide the user some context about what site they are looking at and what happened when they added a site.
Created attachment 120781 [details] mockup of wizard with "quick add" and site filtering combo
> I think we are converging here.... Agreed. I was going to suggest at top as well. It really doesn't make sense to have it any other way. It might be possible to dispense with the add button. Sure would be nice as to me its confusing. I only have to select add when I enter something? I would assume that the new url gets added to available sites IFF the user selects and installs some piece of software form that site? But either that would happen now automatically or you would have weird case where entering text and clicking add always adds and draggin url doesn't. Question is if there is a decent HIG way for users to signal when they are down typing as obviously this can't be live. Would lose focus work? Prob. RETURN would be good because of Finish binding. Simple solution here might be to replace "Add Site" with "Update". You can que both of those very nicely with top message. e.g. changes to Warning/Info when user is typing saying "Do XYZ to update software list."
(In reply to comment #20) > > I think we are converging here.... > > Agreed. I was going to suggest at top as well. It really doesn't make sense to > have it any other way. > > It might be possible to dispense with the add button. Sure would be nice as to > me its confusing. Yeah, I'm struggling on this...that's why I wanted to code it and actually play with it a bit, see how it feels. >I only have to select add when I enter something? I would > assume that the new url gets added to available sites IFF the user selects and > installs some piece of software form that site? It's a chicken/egg issue. The user can't see what's in the site until we add it. So underneath it's an add, even if the button says differently. >But either that would happen > now automatically or you would have weird case where entering text and clicking > add always adds and draggin url doesn't. The way it's working right now is that dragging is like typing and clicking add. It's a more heavyweight operation, an "auto-add/filter by" operation. Drag into the combo and it gets added to the combo and selected, which means you'll only see that site's content. Same result as if you typed and then clicked add. > > Question is if there is a decent HIG way for users to signal when they are down > typing as obviously this can't be live. Would lose focus work? Prob. RETURN > would be good because of Finish binding. This is where I started...thinking Enter. Lose focus is too subtle, I think we want to the guide the user to go somewhere to make it happen. I think Lose focus is too subtle. And since we must add it in order to see it, I chose Add as the name, but I agree it might not be clear. (But no less confusing than current "Add Site..." button.) I was going to play with Enter a bit. Either way, we still might want an add site button somewhere for the user who wouldn't know what to type, and would want the file/dir browsers and validation that occur in the dialog. > > Simple solution here might be to replace "Add Site" with "Update". > > You can que both of those very nicely with top message. e.g. changes to > Warning/Info when user is typing saying "Do XYZ to update software list." > The message is kind of cool..if they typed in the field it would tell them to press enter or press add...
maybe just use the field assist info field on the left of the combo... And the hover says... "Select a site to see its content or type in a new site name and press <Enter>" No add button. User can link to prefs if they still don't know what to do.
(In reply to comment #22) > No add button. > User can link to prefs if they still don't know what to do. Yep. With perhaps a message up top that says same thing while user is typing. And you could still validate the URL format dynamically. The message thing up top is nice because after enter you could get an error message at top that says "No software site found at http://blah". That gets rid of one more modal. Assume default is still all sites added.
> Yep. With perhaps a message up top that says same thing while user is typing. > And you could still validate the URL format dynamically. yes. The key was that the user may not know they could type and an affordance would help. I'm going to look at some JDT wizards for comparison, they have a lot of these editable combos (some with content assist)...sometimes with an adjacent add action. >The message thing up > top is nice because after enter you could get an error message at top that says > "No software site found at http://blah". That gets rid of one more modal. Yeah, I'm not so sure about that part because it can take a bit of time to realize the site is no good...all we can validate up front is a well formed URI. Since a site error doesn't directly relate to the user's ability to finish (because you could decide to pick another site and move on), I was kind of leaning toward keeping the connection failure messages separate from the data entry/validation. Or at least we wouldn't show the error there if the selection had since changed before getting the error. btw, thanks for your thoughts on all this stuff, it's helpful to me to have the discussion.
fixed >20081222. I'm not sure we're fully there yet, but I think I had enough to go ahead and let users try it. In summary what I did was: - move site management to pref page and link from this page - rearrange the site management buttons into links as originally shown - provide a top-level combo that filters by site. Note this area is not shown if the product is configured such that user's can't manage sites - users can add a site by: - typing into the site combo and pressing Enter - pasting into the site combo and pressing Enter - dragging/dropping a URL or file into the combo - dragging/dropping into the list itself (as before) - pushing the add... button I'm still a bit concerned at the heavyweightness of the site filter area on top of the dialog. However, Kevin's point that you can't completely hide sites, yet have the user be able to add one, is well-taken. The improvements for the "add Eclemma, select the item and install" scenario outweigh the heaviness in my mind. I'm trying to balance a lightweight presentation with enough affordances that the user knows what to do. Kevin wasn't sure about sites in the pref dialog vs. some other dialog. The page can be easily rehosted in a non-pref page if we change our mind about where the link should lead. Miles was hoping for improvements with repo error reporting and that discussion has moved to bug 259604 So I'd like to close this bug, have everyone try it out, and open new ones for improvements...
