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/User Interface"

< Equinox‎ | p2
Line 1: Line 1:
 
__TOC__
 
__TOC__
 +
This page captures user scenarios in the p2 User Interface and discusses problems and issues in the workflow.
  
== Milestone plans ==
+
== Original Goals ==
UI planning information has moved to [[Equinox p2 UI Plan]]
+
Most of the goals were derived from problems observed/reported in the previous UI (Update Manager)See [[Equinox p2 UM workflows]] for the equivalent scenarios.
== Goals of a new Provisioning UI ==
+
With the delivery of a new provisioning infrastructure must come a new UI.  The following goals have been driving the development of the UI for p2.
+
* Gradual discovery.  "The best update UI is no UI."  Consider the user of an eclipse-based RCP product in addition to SDK.  The update UI should be unobtrusive and the RCP app user shouldn't even have to know about it to get their basic updates and work done.
+
* Operate using modeless interaction and background processing to keep from blocking user when performing network operations
+
* Most update functions should be consolidated in a simple "dashboard."  Managing the current configuration and looking for what's out there should be better integrated.
+
* Code should be structured so that eclipse-based products can easily extend, reuse, assemble their update UI without having to rewrite.   
+
* Notifications and errors reported should be understandable by the user. If something wasn't directly triggered by user, the notification should not interrupt their work.
+
* Make it easier for the user who finds something cool via the web to get it into Eclipse
+
  
== End user workflows ==
+
== Goals ==
Different workflows drive the development of this UI.  The first priority is to deliver the equivalent functionality of the current Update Manager UI.  Note that we are not saying we are solving all of these problems.  Part of defining the workflow may be saying that we aren't addressing it yet.
+
* Automatic updating should not interrupt workflow
* User is looking for a specific software component to add to their environment
+
* Make it easier for users to get content they find on the web
** Simple install
+
* Integrate "what do I have" with "what can I get"
*** user browses repositories for software to install/update
+
* Integrate "what do I have" with "what updates are available"
*** UI precomputes info such as required software, download size/time, etc
+
* Separate repository management from browsing available content
*** user accepts licenses, etc.
+
* Remove unnecessary detail regarding required software libraries
** Install requires updating (or downgrading) of existing components
+
* Automatic dependency resolution
** Conflicts arise in the requirements for various components
+
* User-oriented error messages, higher level explanations
* Software updating
+
* Code structured for multiple levels of integration (pluggable policies, different host dialogs, building blocks)
** User looks for updates of software already installed
+
** User wants automatic checking/notification of available updates
+
** Silent/automatic updating, user never sees the update UI, it just happens
+
* User wants to remove a software component from their environment
+
** Simple uninstall
+
** Associated uninstall of required software
+
** How much does the user care about complete rollback (downgrading components that were upgraded by an install, etc.)
+
* User wants to know what software is available for download (browse, search by function or name, etc.)
+
* User's environment is defined explicitly by someone external (administrator)
+
** Upgrade or install to a new specification
+
** Compare current installation to required one
+
* User wants to return to some previously known state (rollback to a named state)
+
  
== How to Run the UI ==
+
== Scenarios ==
The update UI (aka the "end user UI") appears as a new menu item '''Software Updates (Incubation)...''' in the help menu of your eclipse application.  To include this UI in your eclipse application, you want to include the plug-in '''org.eclipse.equinox.p2.ui.sdk'''.
+
=== Check for updates ===
 +
=== What can I get? ===
 +
=== Here's something cool on the web ===
 +
=== What do I have? ===
 +
=== Automatic Updating ===
 +
=== What's wrong? ===
 +
=== Repo management ===
  
There is also an "admin UI" which allows the p2 team to drive the p2 infrastructure in a multi-profile scenario.  This UI is also used as the provisioning agent in the current milestone builds.  It can appear as either a perspective in your Eclipse workbench, or as a stand-alone RCP app.  Since the intention of this UI is to help the team develop, test, and use the provisioning infrastructure, the UI exposes the underlying infrastructure and associated terminology to the end user, which is definitely not the approach we expect to take for end users.  To include this UI, you want to get the plug-in '''org.eclipse.equinox.p2.ui.admin''', or else run the RCP version of the app.
+
== Problems ==
 
+
* Implementation has same performance problems as UM did (user may have to wait a long time for content to fill in or for resolution to take place).
Currently, if you include both UI plug-ins in your launched workbench, or you include the sdk UI in the launch of the RCP app, you can operate the admin UI and still launch the end-user UI using the menu item in the help menu.  If you do this, you will notice multiple property pages for repositories and IU's, one with developer/implementation info, and the other with more end-user info.
+
* Too much repo management forced on user
 
+
* We haven't improved error reporting (some find it worse) - need to decipher resolution errors and report in user-friendly way
==Plugin Structure==
+
* We removed detail about software requirements/underlying libraries. Some users want to knowInconsistencies remain due to late-breaking issues (need to show licenses for all things even though user doesn't see those things anywhere else).
* '''org.eclipse.equinox.p2.ui''' contains code we think is useful for any SWT/JFace-based provisioning UI.
+
** Content and label providers for showing provisioning objects in views
+
** View filtering
+
** Widget groups for creating/editing provisioning objects
+
** Common drag/drop adapters with pluggable prompting
+
** Reusable actions and operations for provisioning commands
+
** Pluggable update and install UI
+
** Issues not addressed yet
+
*** Evolve the current undo support to use the underlying engine history, not UI-level implementation
+
*** Scalability issues - lazy content providers for repo access (iteration vs. collection)
+
*** consider UI forms vs. dialogs
+
*** Input validators for provisioning info (repo URLs, capabilities, touchpoint types, etc.)
+
*** Automatic checking for available updates with pluggable notification style
+
* '''org.eclipse.equinox.p2.ui.sdk''' contains the update manager replacement UI.  You'll see terminology such as "feature" and "site" used in this UI.
+
* '''org.eclipse.equinox.p2.ui.admin''' is the current developer/administrator UI.
+
* '''org.eclipse.equinox.p2.ui.rcp''' is an RCP application of the admin UI
+
 
+
== Tooling issues ==
+
There are issues outside of the scope of end users that are not covered in the end user UIIt's not clear whether these will be added to the Admin UI or whether they are separate tools for builds or publishes.
+
* Repo management
+
** Create and populate repos
+
** Manage repo content
+
** Category definition
+
* Defining and persisting profiles for mass deployment to users
+
  
 +
== Questions ==
 +
* tweak the problems or step back?
 +
* unfolding of detail
  
 +
== Milestone plans ==
 +
UI planning information has moved to [[Equinox p2 UI Plan]]
  
 
[[Category:Equinox p2|User Interface]]
 
[[Category:Equinox p2|User Interface]]

Revision as of 13:10, 19 June 2008

This page captures user scenarios in the p2 User Interface and discusses problems and issues in the workflow.

Original Goals

Most of the goals were derived from problems observed/reported in the previous UI (Update Manager). See Equinox p2 UM workflows for the equivalent scenarios.

Goals

  • Automatic updating should not interrupt workflow
  • Make it easier for users to get content they find on the web
  • Integrate "what do I have" with "what can I get"
  • Integrate "what do I have" with "what updates are available"
  • Separate repository management from browsing available content
  • Remove unnecessary detail regarding required software libraries
  • Automatic dependency resolution
  • User-oriented error messages, higher level explanations
  • Code structured for multiple levels of integration (pluggable policies, different host dialogs, building blocks)

Scenarios

Check for updates

What can I get?

Here's something cool on the web

What do I have?

Automatic Updating

What's wrong?

Repo management

Problems

  • Implementation has same performance problems as UM did (user may have to wait a long time for content to fill in or for resolution to take place).
  • Too much repo management forced on user
  • We haven't improved error reporting (some find it worse) - need to decipher resolution errors and report in user-friendly way
  • We removed detail about software requirements/underlying libraries. Some users want to know. Inconsistencies remain due to late-breaking issues (need to show licenses for all things even though user doesn't see those things anywhere else).

Questions

  • tweak the problems or step back?
  • unfolding of detail

Milestone plans

UI planning information has moved to Equinox p2 UI Plan

Back to the top