Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 290972

Summary:

[ui] Updates wizard should optimize layout for the "only one thing to update" case

Product:

[Eclipse Project] Equinox

Reporter:

Susan McCourt <susan>

Component:

Assignee:

Susan McCourt <susan>

Status:

VERIFIED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

aniefer, b.muskalla, codex69, contact, greg.johnson, gunnar, hjoensson, iloncar.ml, irbull, jin.phd, justin, kai.toedter, pascal, patrick, prakash, qwang, remy.suen, simon_kaegi, slewis, steffen.pingel, susan

Version:

3.5

Target Milestone:

3.6 M7

Hardware:

OS:

Windows XP

Whiteboard:

Bug Depends on:

Bug Blocks:

281226

Attachments:

Description	Flags
update wizard mockup	none

Description Susan McCourt

2009-09-30 17:14:54 EDT

Bug 281226 discusses different things that can be done to make the update UI of an RCP app simpler. A lot of this can already be done in existing p2 code, it's just not obvious.

But one thing we don't do (and should) is optimize the available updates wizard for the case where there's only one thing to update. We already do this today in the license page. When there's multiple licenses we show a list of licenses and you click on each one to see the license. When there's only one license, we just show it.

Why not do the same thing in the updates wizard? If there are multiple things, you click on the list and see the details. If there is one thing, you should just see its name and the details.

Of course, the details area today just shows the IU description text and links to the properties, which link to the optional descriptive URL's. As part of this, we should consider checking the description URL and showing it in the details area if its available, and fall back to text.

All this means that in the single update case, you'd get a wizard that said the update for XYZ was available, but the bulk of the page would be the browser showing you the provider's description of the update (complete with snazzy graphics). In the multiple updates case, we would show the same snazzy graphics in the details area. There is already a splitter for making the details area bigger, we could consider readjusting the proportions of the wizard.

In today's metadata, we have an IU description, IU description URL, and an update description which as description text. Ideally we would support an update description URL, because some providers will need to distinguish the generic IU description from an update description.

For RCP apps, reusing the description URL as an update description URL is probably ok (since you never install the RCP product into something else), so we can start by reusing the description URL.

Comment 1 Susan McCourt

2009-09-30 17:51:21 EDT

(In reply to comment #0)
> In today's metadata, we have an IU description, IU description URL, and an
> update description which as description text.  Ideally we would support an
> update description URL, because some providers will need to distinguish the
> generic IU description from an update description.  

I opened bug 290976 for the metadata and publishing issue.

Comment 2 Susan McCourt

2009-09-30 20:25:40 EDT

See also bug 274342 which touches on the "rich details area."  

Showing the details area only when there is only one IU to be updated will only look cool if the details area is rich.  So that part of the problem can be covered in that bug and this bug can focus on the "only one is shown" issue.

Comment 3 Susan McCourt

2009-10-07 13:27:36 EDT

Created attachment 149011 [details]
update wizard mockup

I was already playing around with an embedded browser details area in https://bugs.eclipse.org/bugs/attachment.cgi?id=149009.  while I was at it, I decided to do a very quick cut/paste into the existing update wizard.

In this example the existing wizard banner graphics remain at the top, but the generic message is replaced with the name/version and description of the update.  The details area is a browser that shows the content in the theoretical update descriptor URL (or for now, the description URL).

If the UI was configured to manage licenses (and the license had not already been approved/remembered), then the next button would take you to the existing license page.  We would never traverse to the current "drill down/confirmation/error" page because there's no ability for the user to change what is being updated and therefore no need to re-resolve the install and show errors.

If the UI was configured not to manage licenses, then presumably we could get rid of the wizard buttons and just show OK/Cancel.

Comment 4 Susan McCourt

2009-12-01 13:12:41 EST

Changing milestone (to 3.6 to track for this release).  Two reasons:
1) the p2 API changes happening in the branch won't be released until after M4.
2) we need to figure out our story for bug 295273 before proceeding with the branding issues.  Questions discussed there include:
- does the Mylyn connector support updates (if so this blurs the line between the work going on here and the connector work)
- does the Mylyn branding data move into p2 or is there an extra branding/discovery publishing step on the part of a product

Comment 5 Susan McCourt

2010-03-18 19:03:38 EDT

fixed in HEAD >20100318.
This turns out to be a separate wizard and page completely, because there's no reason to inherit all the table-viewer and "choose from a list" logic in the other wizards.

Also, it's not clear that we want to have this mode "magically appear" for free.  Just because there is only one update doesn't mean that we abandon the list presentation.  

For example, in the SDK we give the user the list of updates.  There may be one, there may be many, depending on what the user has installed. If there is just one, well, there is just one.  But we don't want to change the notifier if only one happens to be available.  If its update descriptor metadata is not rich, then we'll actually get a pretty shabby looking notifier.

I thought about using this mode "for free" when there is only one root that can be updated, but this means if the user installs something later, the update notifier will change.

So it really needs to be up to the app to decide when to use this wizard.  The app developer knows what metadata they intend to use, etc.  I am in the process of updating the cloud example to use this...

Comment 6 Susan McCourt

2010-04-26 11:50:21 EDT

verified in 20100425-2000, Win7.
This wizard is used in the rcp.cloud example.