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.
Difference between revisions of "Equinox p2 UI 3.5 workflows"
| Line 1: | Line 1: | ||
(Work in progress) | (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. In other words, consider separating "installed" and "available". Providing a link to the "installed" view from the available view may be useful. 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. | * 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. In other words, consider separating "installed" and "available". Providing a link to the "installed" view from the available view may be useful. 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 about something in particular that they want. They don't really care about a "site view" of the world unless there is a problem with performance or availability of a server. This suggests a default view of available software by name, perhaps with immediate filtering. Even better, a fast path to get from a plug-in reference on a website into the install. 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. | * Users who want to add software typically know about something in particular that they want. They don't really care about a "site view" of the world unless there is a problem with performance or availability of a server. This suggests a default view of available software by name, perhaps with immediate filtering. Even better, a fast path to get from a plug-in reference on a website into the install. 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. This suggests a unified presentation of the information in the Help>About dialog and the information in the "Installed Software" list. It also suggests that 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. | * When working with a configuration problem, users want one easy way to provide info to help debug the problem. This suggests a unified presentation of the information in the Help>About dialog and the information in the "Installed Software" list. It also suggests that 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 into higher level Help menu entry points === | ||
| + | === Check for Updates === | ||
| + | === Install New Software... === | ||
| + | === About === | ||
Revision as of 16:46, 4 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. In other words, consider separating "installed" and "available". Providing a link to the "installed" view from the available view may be useful. 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 about something in particular that they want. They don't really care about a "site view" of the world unless there is a problem with performance or availability of a server. This suggests a default view of available software by name, perhaps with immediate filtering. Even better, a fast path to get from a plug-in reference on a website into the install. 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. This suggests a unified presentation of the information in the Help>About dialog and the information in the "Installed Software" list. It also suggests that 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.