Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Equinox p2 UI 3.5 workflows"
(→Install New Software...) |
(→Workflow problems) |
||
| Line 5: | Line 5: | ||
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: | 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. | + | * 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. |
| − | * Users who want to add software typically know | + | **Consider separating "installed" and "available". |
| − | * When working with a configuration problem, users want one easy way to provide info to help debug the problem. | + | **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 == | == Mockups of proposed changes == | ||
Revision as of 17:37, 9 September 2008
(Work in progress)
Contents
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.
- Consider separating "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.
We could also consider moving the entries to the top level of the help menu.
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
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.
The first page shows the available sites. 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.
Once the user selects the desired software and clicks Next, they 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.
The remaining pages are the same pages from the 3.4 install wizard.
