Re: [equinox-dev] [prov] How best to help the user through incompatible/

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

Susan said:
> Are you suggesting that you'd rather see the update
icon/red X without the popup in the second case? Interesting....

The popup is ok, as long as it's non-modal,
appears at the bottom of the window, doesn't steal focus, and eventually
disappears on its own if I ignore it. The current popup seems to follow
all these, except for perhaps the eventual closing itself. However, there
are some cases where it would be better to silently retry a few times before
creating a popup. For example, I may be on a plane and not be able to reach
the metadata repository. I guess the trick there is distinguishing this
case from other update failures.

John

Susan Franklin McCourt <susan_franklin@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

02/13/2008 11:57 AM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>, equinox-dev-bounces@xxxxxxxxxxx
Subject	Re: [equinox-dev] [prov] How best to help the user        through        incompatible/bad provisioning plans

John said:
> It would be nice if there as an unobtrusive way to let the user know
though - such as a trim widget that gets an error overlay added. 

this is similar to the path I am exploring. 
To clarify - you'll never get told of an update if you don't have the pref
on. The pref guides how often we check, whether we download before notifying,
etc. But if you have the pref on, I was thinking of:

- for updates with no problem - notify the user with the usual popup and
status bar affordance
- for updates with a failed plan - the status bar affordance has a red
X, the popup is worded differently (the trick is the wording, a way to
inform without scaring, and to make sure the user knows that clicking the
popup just lets them browse the updates, nothing bad will happen automatically).

Either case, clicking on the popup gets you the update dialog, and in the
second case it has an error condition (bad as a general rule, but more
informative than not telling them).

Are you suggesting that you'd rather see the update icon/red X without
the popup in the second case? Interesting....

For the manual checking for updates, install:
Today we report the error if the plan fails. I was considering reporting
the error with an option to "launch the wizard anyway" (and a
toggle to remember the pref).

Pascal said:
>don't let the user click the install button until the proper things
have
>been selected. This means that the validation is done as the user selects
>and unselects things in the UI.

This is what we do once inside an update or install wizard (as you check
and uncheck items, the plan is recomputed).
But if what you mean is to compute the plan while making selections in
the "available features page," I don't think that really helps.
It is expensive, and noisy (you have to show progress somewhere). And if
we just gray the update/install button, there is still all the same questions
about how to show what's wrong. 

So my thinking is that the ability to launch the wizard anyway gives the
user a place to try checking/unchecking things and recomputing the plan,
rather than going back and starting over. And it keeps the basic workflow
of browsing for what's available less cluttered by not doing full resolution
all the time.

susan

John
Arthorne <John_Arthorne@xxxxxxxxxx>

John Arthorne <John_Arthorne@xxxxxxxxxx> Sent by: equinox-dev-bounces@xxxxxxxxxxx 02/13/2008 07:39 AM Please respond to Equinox development mailing list

To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx> cc: Subject: Re: [equinox-dev] [prov] How best to help the user through incompatible/bad provisioning plans

This is definitely a tricky problem. A likely scenario is that they have
installed some additional plug-in, and that plug-in has a constraint that
is not compatible with constraints in the updates (The extra plugin requires
version 1 of "foo", and the update requires version 2). The problem
is, our solver might not be able to come up with a simple explanation that
makes any sense to the user (they likely know little about the various
IUs they have installed). Until we can come up with an explanation that
allows us to guide the user through correcting the problem, I would opt
for keeping quiet in the automatic update case (just log it). Personally,
it drives me crazy when applications have uninvited and unsuppressible
modal popup dialogs about updates. If the update can proceed silently it's
fine. If I explicitly asked for an update, it's ok to prompt me about problems.
But if I didn't ask for it, don't bother me about it. It would be nice
if there as an unobtrusive way to let the user know though - such as a
trim widget that gets an error overlay added. In the updates dialog, we
would presumably still show the updates, and the user can try the update
from there if they want to. 

John

Susan Franklin McCourt <susan_franklin@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

02/12/2008 05:33 PM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To	equinox-dev@xxxxxxxxxxx
cc
Subject	[equinox-dev] [prov] How best to help the user through incompatible/bad provisioning plans

Hi, everyone.
I've been struggling with how to handle the case where the user has automatic
updates on, we find updates, but the resulting provisioning plan for those
updates is not OK. Meaning, there is some incompatibility/problem. Do we
tell the user? Do we let them try to update anyway? etc. etc...

This issue also applies to provisioning actions the user selects. They
select A, B, C and say "Install..." but the resolver can't find
a plan that satisfies everything. What then? We currently just report the
(often cryptic) error. Should we let them try anyway, or at least open
the wizard and let them check/uncheck things until they get a good solution?

If you have any thoughts in this area, could you please read and respond
in this bug?
https://bugs.eclipse.org/bugs/show_bug.cgi?id=217927

thanks,
susan_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev