[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Diety UI draft



Manoj Srivastava wrote:
> 
>  a) Is there going to be an optional dialog/confirm/warning screen
>     when packages are installed or deinstalled? (I know it shows up on
>     the selection screen)

Are you asking whether the user is asked to confirm all changes to
the packages installed on their system?

If so, yes.  All changes are presented to the user for confirmation
in the installation phase of deity:

    http://www.verisim.com/~behanw/deity/deity-ui_0.10.html#install

(first list in this section)

>  b) The del/keep buttons are quite close (may or may not be a problem
>     ergonomically). Is there a (optional) confirm button for
>     deletions?

True, these buttons are close, but I've found through user tests that
this setup is very intuitive and easy to figure out.  And yes, there
is a confirmation phase (as previously stated above for question (a) )

>  c) If a package shown up in the dependency list of multiple new
>     packages, is the package information duplicated?

Yes it is duplicated.

This info is normally hidden unless the user expands that item
in the collapsible list.  If the user looks, however, it will indeed
be the same in both places.

>  d) Obsolete packages: I use the dpkg-ftp package to update packages;
>     I generally only get Packages files from Hamm on a regular
>     basis. It asked me if I wanted to wipe out the old list, and I did
>     Now all packages not in Hamm (non-us, for example) show up as
>     obsolete. I do not want these automatically flagged for removal.
>     The obsolete determination has to be better than looking at the
>     Packages files I happen to have on my machine.

Before you get too concerned, if you check Section 1.8, you will note
that it does not say anything about automatically removing obsolete
packages.  In fact, the only automatic behaviour (which can be turned
off in the user preferences) is trying to replace obsolete packages
with a package that "Replaces:" it.  Again, this is explicitly shown
and needs to be confirmed by the user in the installation phase.

You can check out the obsolete section at:

    http://www.verisim.com/~behanw/deity/deity-ui_0.10.html#obsolete

I think most people will find that they will choose a source list
that includes just about every source of deity packages that they
have access to.  As long as that package is available for just one
of those sources, the package can't be found to be obsolete.  In this
way, I think most people will never see their core packages shown
as obsolete unless they truely become obsolete.

Even if a package is shown as obsolete, that's all that will happen:
it will only be shown as obsolete.  The next time, once you have
restablished a connection with a source that has that package available,
the package will not be shown to be obsoelete anymore.

The default response to an obsolete package is to leave it be, but
show the user that it's obsolete.  (As I said previously, deity will
look for a replacement, but if none is found, no action will be taken)

I hope that clears things up for you.

Your reaction tells me that my document isn't clear enough. I will
try to tighten that up for the next version.


SirDibos wrote:
> 
> a)   Also, perhaps an option to do different setups?  So we have different
> default installations?  Eg, internet server, game machine, developement
> machine, generic machine, ham radio, engineering, everything and the
> kitchen sink... etc?

There is 2 partial mechanisms for this.  There are keyword profiles,
and importation of a package list from either a file or a URL.

Keyword profiles:
    There will be named profiles that define keywords that present
a list of packages that would be suitable for each of a list of various
common setups (such as the list you suggest).

    http://www.verisim.com/~behanw/deity/deity-ui_0.10.html#src

Import package list:
    ...

Whoops!  I just realized I hadn't added that part to my master document!
I had planned for this, when I took my notes, but did not expressly
add it.  Sorry about that.  (point for SirDibos!)

It seems that the only reference to this is in the menus for the
selection list:

    http://www.verisim.com/~behanw/deity/deity-ui_0.10.html#sel_menu

There should be abit in there about being able to import a predefined
package list from a file or a URL.

I will add that to my document shortly.


> b)  An option to "downgrade"

If a package is a downgrade for the user, this is shown on the
selection list.

If the user wants to downgrade to another version of this package
which is not shown on the selection list, but is available none
the less, they simply press on the "Choose Version" button on the
Status tabbed window and can choose from all the available
versions deity has access to.

    http://www.verisim.com/~behanw/deity/deity-ui_0.10.html#tab_status


I hope I have answered your questions to both your satisfacations.

Thank you for taking the time to review and comment on the Deity
UI specification.

Behan
(UI designer for the Deity project)

-- 
Behan Webster     mailto:behanw@verisim.com
+1-613-224-7547   http://www.verisim.com/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: