This working document is designed to assist early adopters in understanding the rational behind Eclipse Update interface changes and learning how to perform standard tasks. The document will evolve with the UI and will eventually be rolled into the official user documentation. We welcome community feedback while we are going through this process.
The implementation of Update Manager that can be found in Eclipse 2.1 release is fairly polished but very confusing from the usability point of view. Too many capabilities are readily presented to the user when this perspective is opened, making it very hard for a novice to figure out what to do. Some of the complains are:
Interestingly, for the longest time the development team didn't understand the complaints. Knowing what the underlying mechanisms are, we liked the UI because it did exactly what we wanted it to do and could see everything we wanted when we wanted. When a new developer joined our team and started getting into the details of the component, he revealed this blindness to us. We realized that the current UI is a thin veil over the Update Core API. There is almost 1-1 mapping between APIs in Update Core and the way things are presented in the Update UI. Since we were comfortable with Update Core (knowing its every nook and cranny), we could not see how this direct mapping can be confusing to anybody.
Since we realized that it should be easy to simply update the installed product to the latest fix pack, the current UI does have a 'one-click' update alternative (Help>Software Updates>New Updates). However, anything else requires switching to the Update Manager - a major learning curve.
As a corollary of the one-dimensional UI layer on top of the Update Core, everything is immediately accessible - simple and complex tasks alike. Case in point - previous and saved configurations. They are visible all the time in the Configuration view even though as a concept they are only needed for the 'revert' operation.
These two views were part of the Update perspective and seemed too similar - both contained features (with the same icons), both were driving the same Preview when clicking on objects etc.
Users tend to think that new features that they can install also qualify as updates (as opposed to strictly limited to new versions of the existing features). This concept (that Update developers find so strange) revolves that anything useful that can be added to the product is an 'update' (although we could argue that a more precise term would be 'add-on' for things that didn't exist before, compared to the real 'updates').
Since Eclipse 3.0 Milestone 1 build, we have provided a new set of actions that launch a redesigned Eclipse Update user interface that begins to address the above listed problems. These two actions are available off the Help>Software Updates menu and both have 'experimental' in the label.
First thing that is immediately obvious even from the labels of these actions is that we have separated the concept of 'updates' and 'configuration'. When you need to browse or change your current configuration (things you have installed in your product), you use Configuration Manager. To install new features into your product (either strict 'updates' or the ones not previously installed), you use 'New Updates' wizard.
Since all Update tasks are now handled by these two UI parts, Update Manager and all of its views are gone.
When a new Eclipse-based product is installed, the first (and most frequent) task you are likely to perform is to search for updates. In 2.1, you could do this in two ways: using 'New Updates' action that immediately started the search, or using a more powerful searches in Update Manager. In 3.0, search is unified and simplified in that all the ways to get it to start result in bringing up the same wizard.
The usual way to start the update search is from the Window>Software Updates menu. Selecting the action 'New Updates (experimental)' brings up a consolidated search wizard:
The first page offers a choice between a plain update search or a search for new things (not already installed). The default choice is compatible with the old behavior of 'New Updates' action i.e. plain search. Since no more information is required to commence the search, pressing 'Next' will cause the search progress and the review page to appear. Unlike before, you can now see results as they arrive in the list. When the search is over, you will end up with 0 or more 'hits':
This page now replaces all other ways of viewing features on servers before installing into the product. Short feature description is shown below the result list. Feature properties (license, os/ws/arch/nl coverage, general information, copyright etc.) can be viewed by double-clicking or by selecting 'Properties' button. If a feature has more information in HTML form, 'More Info' button will show it in a resident browser. More than one feature can be selected in this page (although invalid feature combination will be flagged as errors).
Update search algorithm has been modified to pick up patches (e-fixes) in addition to valid updates (updates are pre-selected, while e-fixes are not).
When one or more features are selected, pressing 'Next' takes you to the standard set of pages known from 2.1 release (license, optional features, target install location).
What is particularly new in Eclipse Update 3.0 is that searching for new features is not very different and involves the same wizard. It starts by selecting the second radio button in the first wizard page. When 'Next' is pressed, a different page will show up. It allows you to define the scope of the search - which update sites to include and (optionally) which categories to exclude from the search:
Initially, the list of sites is pre-loaded with those found in the currently configured root features as 'discovery' sites. New sites can be added later using 'Add Update Site...' button and providing the site URL. Local sites (file system, CD-ROM) can be added using 'Add Local Site...'. This button will allow you to find a directory that contains 'site.xml' using the standard system file selection dialog.
The list of sites is persisted. Sites that are checked will be searched. Optionally, users can expand the site (this results in network activity as site.xml is downloaded and parsed to detect available categories). By default, all categories are checked. Users can uncheck some if they want to exclude them from the search.
When sites and categories to search are selected, pressing 'Next' shows the same Review page as in the case of the search for updates. The search progress will be indicated using the wizard's progress monitor, and results can be seen as they arrive. The rest is the same as before.
For the sake of simplicity and consistency, there will be more launch points in Eclipse Update 3.0 that will result in opening this wizard. Typically, they will configure the search in such a way that no further user input is required. Consequently, the wizard will open directly into the Review page, with the search already in progress. The goal is to have a single way of installing new features (either updates or really new ones).
Addressing one of the problems mentioned at the beginning, browsing and managing your configuration is now done in a completely different visual part - Configuration Manager. We discarded the Update Manager perspective because there was always a nagging feeling that what we are doing there is very different from other perspectives. We wanted to make it clear that configuration management is something that requires clear break in the normal work while important decisions regarding the configuration are made.
Since Configuration Manager is a separate window (rather than a perspective), there is no confusion that you need to do something other than development in it. It has no detachable views, you cannot show any of its views in another perspective, and no views can be repositioned or closed (it really has only one view housed in a modal window).
Configuration Manager window is modal to underline that you should not be doing any thing else while it is open. On the surface, it uses similar metaphor to the old 'Install Configuration/Preview' pair, but with some important differences:
The left half of the manager contains the familiar configuration tree from the old UI. It shows the current configuration, with install locations (product, extensions, private locations) as children, and features as their children. Feature hierarchy can be browsed. New for 3.0 is that this hierarchy can be simplified (both install locations and included features can be individually filtered out from the tool bar).
The right half of the window is occupied by a simplified preview. It shows the name, the description and the available tasks of the selected object on the left. Available tasks are accessible as hyperlinks with descriptions. We believe that the old preview had a very low signal-to-visual-noise ratio and that a more compact one in 3.0 is better. The rest of the information that used to be presented in the old preview is now accessible as object Properties (or double-click).
Almost all of the tasks available in 2.1 are still available here. Features can be enabled or disabled (in 3.0, they can also be uninstalled). Install locations can be enabled or disabled as a whole (very handy for turning product extensions on or off).
As before, it is possible to revert to one of the previous install configurations. However, in the spirit of progressive disclosure, we decided to hide the configuration history until really needed. When 'Revert to Previous' task is selected, a dialog appears:
It shows the past configurations (excluding the current one) going backwards in time as far as the configuration stack permits (by default, 50 configurations). Activities for the selected configuration are shown in the second table.
Due to the generous capacity of the default configuration stack, we were of the opinion that the ability to save a configuration is almost never used and hence it was not worth migrating to the new UI. It may also be safer not to since saved configurations may grow stale after a while (i.e. point at features that are no longer present).
The (still experimental) Update UI described above has been made available for early feedback in the stable Milestone 1 Eclipse 3.0 build. Since the progress marches on, we already went a bit further. Here is a preview of the UI enhancements to come in the integration builds after M1:
As users perform Update operations, we preserve past configurations within the capacity of the configuration stack (configurable in the Preferences). When the capacity is reached, old configurations are recycled. However, Update maintains an ever-growing log file containing configurations and their activities. This file is compact but not very easy to read (or find). We will add an action in the Configuration Manager that shows this history in a resident browser. In case of problems, users can save the HTML history page and send it to service/support for analysis.
Web-triggered updates is a loose term that describes Eclipse Update's ability to react to queries from a web browser that result in install wizard being opened and primed with a specific feature for installation. This capability is available in 2.1 but in 3.0 UI we had a problem with browser launch points. Since we don't have Feature Updates view any more, we have no bookmarks to use as a launch point for encoding servlet host and port information and passing it to the resident browser.
We will use the Software Updates menu for this purpose instead to show Update web site bookmarks in a more traditional fashion. Update sites that have the 'web' type computed from the installed features (as 'discovery' sites) will be shown there by default. Users will be able to add new bookmarks and organize them later. Since these bookmarks are used solely for passing the callback servlet information to the Web pages that can use it, we will automatically start the Eclipse application server and get rid of the Web-triggered updates preference page:
We will allow update search to be initiated from within the Configuration Manager. For example, it will be possible to select an installed feature the start a search for updates only for that feature.
If you want to experience the new UI in detail but have no suitable update sites to point at, we recommend using our new test scenarios. The steps are designed to be self-sufficient and should expose you to various Update capabilities.