Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Equinox p2 UI 3.5 workflows"

(About)
(About)
Line 69: Line 69:
 
The About dialog in 3.4 allows the user to view details about the installation by feature or by plug-in.  In addition, it allows the user to open a detailed description of the configuration that can be used.  The proposal is to open up this implementation so that plug-ins can contribute views.
 
The About dialog in 3.4 allows the user to view details about the installation by feature or by plug-in.  In addition, it allows the user to open a detailed description of the configuration that can be used.  The proposal is to open up this implementation so that plug-ins can contribute views.
  
The feature and plug-in view buttons would be replaced with an "installation details" button
+
The feature and plug-in view buttons would be replaced with an '''Installation Details''' button
  
  
Line 81: Line 81:
 
*Consider a common "details area" for the selected item that can be filled in by the content provider.  It wouldn't appear if the contributor didn't provide details
 
*Consider a common "details area" for the selected item that can be filled in by the content provider.  It wouldn't appear if the contributor didn't provide details
  
A "plug-in details" view is provided by default.  This would be the only view in a simple RCP app that didn't otherwise contribute to this view.
+
A "Plug-in Details" view is provided by default.  This would be the only view in a simple RCP app that didn't otherwise contribute to this view.
  
  
Line 87: Line 87:
  
  
The IDE contributes the "feature details" view shown in the IDE about dialog today
+
The IDE contributes the "Feature Details" view shown in the IDE about dialog today
  
  
Line 93: Line 93:
  
  
Information from the p2 "Installed Software" view is contributed in an "install details view"
+
Information from the p2 "Installed Software" view is contributed in an "Installed Software" view
  
 
*Commands are registered for update and uninstall
 
*Commands are registered for update and uninstall

Revision as of 19:38, 9 September 2008

(Work in progress)

Workflow problems

Based on input in bug reports, mailing lists, design walkthroughs, and user definitions, these are the problem areas we see in the basic workflows of the 3.4 UI:

  • Many users who want to update the system are not authorized to add new content or do not care about adding content to the install. This suggests providing a simplified way to check for updates without exposure to update sites, available add-ons, etc.
    • Provide a fast path "check for updates" without having to launch a view of what's installed
    • Separate "installed" and "available".
    • Provide a button so that the "installed" view may be launched from the available view
    • Better affordances in the "available" list to depict what is already installed, what is an update, etc. would also help to answer questions that today require switching between the "available" and "installed" view.
  • Users who want to add software typically know the name of what they want to install.
    • A "site view" of the world is not important unless there is a problem with performance or availability of a server.
    • The default view of available software should be by name
    • From an implementation point of view, it suggests that most repositories are loaded by the time the user is selecting items for install which would move most of the "load repo time bombs" to the front of the workflow rather than during resolution of an install.
  • When working with a configuration problem, users want one easy way to provide info to help debug the problem.
    • Unify the information in the Help>About dialog and the information in the "Installed Software" list.
    • A log of the install actions taken previously (the revert history) might be useful in this view. It should be possible to update the system or parts of the system from this view.

Mockups of proposed changes

Separate install and update tasks

Include separate tasks for checking for updates and installing new software.

P2Menu1.jpg

We could also consider moving the entries to the top level of the help menu.

P2Menu2.jpg

Check for Updates

Choosing the Check for Updates... menu item launches the same wizard that the user sees today when notified of available updates, or when selecting items in the installed view and pressing the update button. Before this wizard appears, the user will see a progress dialog. The dialog can be sent to the background so that the user does not have to wait for all the repositories to be contacted.

P2Update.jpg

Install New Software...

Choosing the Install New Software... menu item launches a wizard that combines the repository browsing information previously shown in the Available Software tab of the 3.4 updates dialog with the install wizard.

All repositories would be loaded before the wizard appears. In the interim, a progress monitor that could be sent to the background will be shown. When the repositories are loaded, the wizard will be launched and the first page will show available software. Note we default to showing the software by name, but the user can still view by site or category, and can still use the filtering techniques made available previously.

Things to note:

  • Action buttons are included on the first page to work with detailed information
    • The buttons for adding, managing, and refreshing sites appear as they did in the 3.4 available software page
    • An additional button is provided to view the install details
    • The properties button may appear here, too although it is not shown in the mockup (depends on alternate methods for presenting detail about a selected item)
    • The layout of these buttons may change
  • Other improvements are planned for this page, but they are covered in separate bugs. These bugs include:
    • better presentation of the filters (currently shown as checkboxes)
    • improved affordances to indicate whether something that's available is already installed, is an update, or is something new
    • show the detailed information about the selected item in a details area as is done on the next page

The picture below is intended to show the overall workflow change, not other detailed improvements.

P2Install1.jpg

Once the user selects the desired software and clicks Next, they will see a progress monitor dialog that will show the progress in resolving the install. Since repositories are loaded, this should be considerably faster than in the current UI, where repositories may be loaded for the first time. The user will have the opportunity to cancel this dialog which will leave them in the first page of the wizard, but they cannot send it to the background since they are in the middle of the wizard.

When resolution is complete, the user will see a review page that looks much like the first page of the 3.4 install wizard. This is where resolution errors are shown if the selected items are not compatible with each other or with the current installation. Note the check boxes are gone from this view since the user can go back and change the selections from the first page.

P2Install2.jpg

The remaining pages are the same pages from the 3.4 install wizard.

P2Install3.jpg

About

The About dialog in 3.4 allows the user to view details about the installation by feature or by plug-in. In addition, it allows the user to open a detailed description of the configuration that can be used. The proposal is to open up this implementation so that plug-ins can contribute views.

The feature and plug-in view buttons would be replaced with an Installation Details button


P2About1.jpg


An integrated "Installation Details" view would be launched from this button.

  • Plug-ins can contribute their own content providers to provide different views of an installation.
  • Plug-ins can register commands that should be invoked against the selection in these views.
  • These commands could appear as context menu items or as buttons along the bottom (details TBD)
  • Consider a common "details area" for the selected item that can be filled in by the content provider. It wouldn't appear if the contributor didn't provide details

A "Plug-in Details" view is provided by default. This would be the only view in a simple RCP app that didn't otherwise contribute to this view.


P2About2.jpg


The IDE contributes the "Feature Details" view shown in the IDE about dialog today


P2About3.jpg


Information from the p2 "Installed Software" view is contributed in an "Installed Software" view

  • Commands are registered for update and uninstall
  • The details area shows additional information
  • Consider a properties action - depends on what is shown in the details area


P2About4.jpg


Information about the install history is shown in the "Installation History" view

  • The user can browse the snapshots that are shown today in the revert wizard
  • Additional detail about each snapshot is shown in a description (new function)
  • The details area shows the snapshot contents that are today shown in the revert wizard
  • A command for performing the revert is registered


P2About5.jpg

Back to the top