Use Cases

Case 1

Products with no dependencies on each other in Available Products List

This is the simplest use case. The user is offered choices to select one of more components and click Add. On Clicking 'Add' the component name is transferred to the right 'Selected' side and removed from the left 'Available' side. If one product is selected on either side then a description for that is displayed in the Description area.

Case 2

Products with dependencies on each other in the Available Products List

Assuming product B and C are hard pre-requisites for A - If product A is added, B and C are automatically added from Available side to Selected side. If A is removed from Selected side, B and C are not removed.

Case 3

A Product with dependencies on one or other of some component is in the Available Products List

Assuming one of product B or product C is a hard pre-requisite for A - If product A is added, only product A is moved to the Selected list. When the user finished selection by clicking the Next button on the page, he/she is asked to choose one of B or C before proceeding.

Q: What happens if both B and C are selected by user in this case?

Assumptions

1. CUI PSP determines the limitations on features which are implemented.
2. Sub components are presented in the available list with higher level components without any distinction. The selection process automatically selects and moves the requisite subproducts.
3. There is no indication if a subproduct is being selected due to an upgrade requirement.

Prototype by XDesign

PSP Prototype by Xdesign (Requires Powerpoint for interaction to work correctly)

Page Flow Mechanism and Product Selection Page

Based on the product selections in the PSP, the product configuration pages may need to be shown or hidden.
For PSP to influence the display of these pages, it sets a special tag with the convention

[<product ID>_is_selected]

for each product that gets selected. The pagesquence allows the install developer to specify arbitrarily complex boolen conditions based on these PageFlow tags in combination
with other tags they can set. For example.

...
    <page name="ProductSelection"/>
    ...
    <page name="TestProductA">
      ..
      ..
      <!-- Show TestProductA page only when it was selected in PSP -->
      <when> [TestProductA_is_selected] </when>
      ..
    </page>
    <page name="TestProductB">
      ...
      <!-- Show TestProductB page only when it was selected in PSP or if it is HAPPY_HOUR. where HAPPY_HOUR is
      assumed to be set by code in a pre-existing XCS page. -->
      ..
      <when> [TestProductB_is_selected] || HAPPY_HOUR </when>
      ..
    </page>
    <page name="TestProductC" defaultViewMode="skip">
      ...
      <!--
         Show TestProductC page if it was selected in PSP or if TestProductB was selected but only if it not HAPPY_HOUR .
       -->
      ..
      <when><![CDATA[

             ( [TestProductC_is_selected] || [TestProductB_is_selected] )

             && ! HAPPY_HOUR

      ]]></when>
      ...
    </page>
    ...

API

Current Status and TODOs and open items

First cut of the implementation is avaiable. The following TODOs / open issues remain.

1. Update sample product completely to be aware of the partial selection now. This is only an xcs change.
   1. Make only config pages for selected pages appear.
   2. Make sure to have all the sample products be available on all platforms.
   3. Sync zip and regular sample products
2. Have a way for the user to choose to install localizations (maybe by a single checkbox). The localizations are not individually selectable.
3. Make sure the uninstall sequence works with PSP.
4. Make the product descriptions be localizable. Currently the descriptions are embedded in dependency XMLs.
   1. This is some addition work on both dependency manager and SIMS first. The work proposal is at openInstaller Product Description Localization .
5. Add attributes for PSP behaviour. Some cases are - Done.
   1. We currently auto select and move sub-features to the selected page when a higher level feature is selected. This should be toggleable in apt:psp tag maybe.
   2. We currently allow de-selection of a sub-feature without affecting the higher level feature. This should be toggleable in apt:psp tag maybe.
   3. We currently do not show dependencies (requirements), only feature (provides). This should be externally toggleable in apt:psp tag maybe
6. Persist settings on back button
7. Code cleanup, comments for new code and removal of commented out or non-functional code.

Dump of email to Jen @ XDesign

oI's (or JES^WSWI or Portal) product hierarchy has

• A product can optionally provide other sub products (Features)
• A product can optionally require other sub products (Dependencies)

Now, to facilitate display of suites, the current oI PSP implementation is assuming that a top level fake product is created which only provides features. Which means that there is a top level container product say
"SampleProductPack" like so

SampleProductPack
  Test Product A
    (require Shared Component Foo)
  Test Product P1
    (Provides Component P1S1)
    (Provides Compoent P1S2)
  Test Product X

etc.

1. The PSP is ignoring the SampleProductPack and displaying the Features contained within, and the sub features. Though this works for suites, it might not be suitable for any products which have only a single product to install. What are your thoughts on this? We can switch to either of the behaviors in our code (thought an install developer or end user currently can not).
2. We only display 'Features' currently and not 'Dependencies'. Again this is a somewhat stylistically uninformed decision on our part. We can show both Features and Dependencies or none as needed. What would you suggest we do by default though, we plan to provide this control to install developers to pick the behaviour.
3. When somebody deselects (or rather unchooses for install, since select is a loaded word in this UI) a component from the right side, it's parent component or sub components are not unselected. The rational being that there may be subfeatures which need not be installed or maybe there are alternate features which can be picked (like alternate web containers). Currently, if the user's selection is

2000
not valid,
2000
we silently complete it and install the required dependencies etc. anyway. But this is something that could be though out more from a design point of view.

Screenshots (Older)

Note: These screenshots show only the content area mockup of the PSP and not a typical full installer page.

GUI with no user selection

GUI with one product selection showing description

GUI with multiple selection

CUI mode (older screenshot)

multiple-selection.png (image/png)
cui-mode.jpg (image/pjpeg)
no-selection.png (image/png)
gui-description.png (image/png)