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"
(New page: (Work in progress) These mockups demonstrate some of the changes we are mulling over in the p2 UI. Based on input in bug reports, mailing lists, design walkthroughs, and user definition...) |
|||
| Line 2: | Line 2: | ||
These mockups demonstrate some of the changes we are mulling over in the p2 UI. Based on input in bug reports, mailing lists, design walkthroughs, and user definitions, these are the problem areas we see in the current UI: | These mockups demonstrate some of the changes we are mulling over in the p2 UI. Based on input in bug reports, mailing lists, design walkthroughs, and user definitions, these are the problem areas we see in the current 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. | ||
Revision as of 16:41, 4 September 2008
(Work in progress)
These mockups demonstrate some of the changes we are mulling over in the p2 UI. Based on input in bug reports, mailing lists, design walkthroughs, and user definitions, these are the problem areas we see in the current 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.