[Aptitude-devel] Towards better upgrading.

[Obey Arthur Liu]

Daniel Burrows a écrit :
> >   Right now, the upgrade procedure for aptitude-gtk users is
> > something like this:
> >
> >   (a) start aptitude.
> >   (b) push the upgrade button.
> >     if there are broken dependencies,
> >   (b.1) click "resolve dependencies" and enter the dependency resolver
> >   (b.2) click "apply"
> >   (c) click "apply changes"

I was going to post something related to this but I've been too busy
preparing my FOSDEM talk..
Basically, I was thinking about smoothing out the upgrade process a
little from an user experience point of view.
Right know the process looks like:
1) Click Upgrade button
2) Wait for new screen to pop up
3) Look for notification below
4) Realize that what the notification says is important
5) Click on notification button
6) Go back to step 2)

The introduction of the Upgrade button was to create a more
workflow-oriented and less feature-oriented interaction possibility.
The problem is that we chose the "notification balloon" metaphor: this
metaphor is usually used to point out informational and optional
information. Many users pointed out that they don't know what to do next
because they didn't notice that the notifications were actually (nearly)
mandatory prompts.

We need to point out more clearly what to do next. I have two propositions:
1) use wizards
2) use new tabs with tab highlighting (blinking?)

Clearly, the usual path is :
1) Show upgradable packages
2) Display resolver
3) Show a preview of the changeset
4) Show the download process
5) Show the dpkg run

We need:
1) Get the executed steps out of the way
2) Highlight the next step

So, what do you think?

I like the tab highlighting idea because it can be reused to, for
example, highlight infotabs which packages changed state (say, to broken).

> >   I'd like to smooth this out and make it more along the lines of
> > "safe-upgrade".  Here's what I imagine:
> >
> >   (a) start aptitude.
> >   (b) push the upgrade button.
> >   (b.1)
> >     if there are broken dependencies, as many packages as possible are
> >     marked for upgrade.  A notification appears saying something to the
> >     effect of "some upgrades couldn't be installed without taking
> >     'risky' actions.  Fix manually?"  (or "no upgrades could be ..."
> >     as appropriate)

I'd describe supplementary upgrades as "additional actions" and actual
downgrades as "risky actions", but fine.

> >     The user can either
> >   (b.1.1) click "apply changes" to immediately install the upgrades, or
> >   (b.1.2) click "resolve dependencies manually" and enter the dependency
> >         resolver, then click "apply" and "apply changes".
> >   (b.2)
> >     if, instead, there are no broken dependencies, the preview screen
> >     will appear as usual with the view / apply changes buttons
> >     available.
> >   (b.2.1) click "apply changes".
> >
> >   The big change is that manual dependency resolution is no longer
> > *required*; users can opt for the safe, default solution or try to
> > find a better one manually.

Well, that's a fine idea by me.

> >   I'm looking at whether it's possible to equip the resolver with the
> > ability to reason about "hypotheticals", so that it can run in the
> > background without altering the current package states.  I haven't
> > decided whether this is actually desirable in this case (with
> > upgrades), but it's not too hard a hack and may be useful in other
> > circumstances anyway.

And give us a 3D tree with keeps/upgrades/installs as x/y/z-axis ?  :)

Arthur

P.S.: I just can't remember to Reply to All..

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://lists.alioth.debian.org/pipermail/aptitude-devel/attachments/20090203/c07e4f60/attachment.pgp