Re: The Deity tree widget
Jason Gunthorpe wrote:
>
> On Mon, 17 Nov 1997, Behan Webster wrote:
>
> > Ok! I've now _finally_ seen the current tree widget!
>
> Ah, we are making progress!
Indeed!
> > I hate to say it, but unfortunately it bears very little resemblance to
> > what I was hoping for. There are 4 areas in which I would like to see
> > changes:
> >
> > 1) Collapsible listes lines
> > 2) Collapsible list controls
> > 3) action bitmaps
> > 4) radio buttons and checkboxes
>
> I'm just going to make a broad statement that 'there are no bitmaps yet'
> so that should defer a number of your questions for a bit ;>
Noted. I might still mention where the graphics will be, but I won't
expect any... yet! 8)
> The text version looks pretty much the same as the X11 version, so if for
> now you could explain what ASCII chars I should use in all these places
> that would help too. I can't use any special ascii characters though
Well, I don't know exactly how, but something along the lines of what's
below (I knon I've seen this done well before, but I can't remember
where 8( ). Unfortunatly in the text version there won't be much space,
so it can be simplified tremendously.
+ foobar
+ blah
- baz
> > 1) What I was hoping for was a collapsible tree widget (not unlike what
> > linux eplorer uses, but using the little triangle controls from the
> > MacOS). The little lines between the open/close bitmaps show the
> > relationships bewteen different lines very clearly. For an example of
> > these lines checkout:
> >
> > http://jungfrau.ptf.hro.nl/explorer/
>
> Okay, what column do you want these in? How should the section items look?
> My experiments suggest that without the horizontal line they tend to get
> lost in the display.
I kinda show how this is setup in my web page. It should be in the
column in which the package names are.
If I understand you correctly, you are talking about horizontal lines
that separate rows? I don't think they are needed. I have yet to see a
UI that uses them, and I think tree widgets like this work fine without
them.
> Should section headings include the vertical bars? Should there even -be-
> vertical bars? Linux Explored doesn't use vert bars in it's columns, but
> it's columns are more regular. Here I have seen all fields clipped at once
> so without a bar they tend to run together..
Personally, I'd prefer no extraneous lines. The vertical ones
especially detract from the fact that the data on each row is associated
with each other. There should be a flow from left to right in the data
and a vertical line detracts from this flow.
I think once the icons are in, they will separate some columns better
than a vertical line.
> > 2) If you look in the currently available UI spec you will notice that
> > the bitmap infront of each item in the tree is also potentially
> > different. There is a different triangle to represent whether the list
> > will expand a group heading into a list of packages, or whether you are
> > expanding a list of dependencies. (one triangle is currently grey, and
> > the other has a red dot in it. These precise bitmaps need not be used
> > in the final product, but it is importants to make the distinction in
> > what part of the list you are about to expand.
>
> Hm, this is a bit unusual, but okay. Have you considered a 'normal' +/-
> tree but using special icons for the various sections? That could work out
> well, we could get a number of stock icons for all the sections..
Not so unusal. The mac has used the triangles for years. I find the
+/- icons, although more common, much more confusing. It is always
instantly obvious whether a list is open or closed from just the
triangle icon. I find that this instant recognition is not there with
the +/- icons.
The only advantage of +/- icons is that they can also be easily used in
the slang version of the list. We could do it the way Linux Explorer
does it with +/- and then a little icon though. Perhaps that would be
best. People are already used to +/- I suppose from windows.
> > - For a new package there should be a little new graphic
> > - For an obsolete package there should be a little "x" (or something
> > like that)
>
> This is going to get it's own email :|
Pardon?
> > - For a package which is already installed there should be nothing in
> > this column (not even a version number)
>
> Erm? Is that right? Right now an installed package will show nothing in
> the inst-version field iff there is no new version. If there is a newer
> version it will be shown and the checks will be set to 'I'.
You didn't quote the line above, but the example you're thinking of is
an upgrade. That case was handled by a previous item. (Item 1 of the
five I listed I believe). What I was trying to get across is that if a
package is installed, and there is no version to upgrade or downgrade,
and if it is not new or obsolete, then the Inst-version field is just
empty.
> > 4) The left three columns should consist of radio buttons and checkboxes
> > (depending on what the row represents. It is important that these
> > controls are very obviously either a radio button group or a single
> > checkbox. This is because not all options are available in each
> > situation. Having a single kind of check control is not satisfactory
> > for this design.
>
> Okay, how do you want this too look? Do you actually want 3 radiobox like
> items?
Yes. I want it very obvious which columns will actually do something.
All three controls are not necessarily available on each line (please
see my design again).
> > - For an upgrade there are 3 radio buttons (del, keep, inst)
> > - For a downgrade there are 3 radio buttons (del, keep, inst)
>
> > - For a new package there is one checkbox (inst)
> > - For an obsolete package there is one checkbox (del)
>
> Right now for a new/obsolete package I put a check
> in 'Keep' to indicate that there will be no upgrade.
You will find that this is contrary to the design I specified in my
design page.
We're working with a user's mental model here. You have to think as
they would think.
How can you delete or keep a package that isn't installed? Hence there
is a check box for inst only.
You can keep a obsolete package, however, keep is more akin to the
deselect hold, therefore I've changed it so that you can only delete an
obsolete package.
> > - For a package which is already installed there is one checkbox (del)
>
> How are you going to indicate the more permanent 'held' state?
There is no "held" state. There is an implied held. By pressing "keep"
you are asking deity to not auto-upgrade until you press inst again
(presumably sometime in the future). Effectively, as a user, if one
time I decided not to upgrade samba (for whatever reason) I would not
like it to default to inst the next time it runs either. I would like
it to stay in the keep state until I say othrwise. It all has to do
with deity keeping the controls in the same state as the user left them
the last time.
> > My preference is for radio buttons to be round and checkboxes to be
> > square, as this is the way they look for most widget sets and people
> > understand these shapes and what they do already.
>
> Sure, but do you -really- want radio buttons for this case? It might make
> things look too busy? I can try it, lose some of the lines and chuck in a
> few circles.. Do you mind Diamond shaped radio buttons? They are slightly
> simpler to draw at this stage.
I've already tried it, and I think it looks fine with radio buttons. So
do the people I tested this part of the design on. The last test
subject I tried the final version on got the whole interface without any
propting from me.
I'd prefer circles (I personally don't like the diamonds; they're not so
obviously radio buttons), but diamonds will do for now.
The difference is immediately obvious from circle to square. A Square
on one corner is not so immediately different from a square. Our mind
see's 4 corners and we think square! That's a checkbox! no wait! it's
on one corner! That means it's a radio button. Shape does matter in
recognizability.
> Ah, we need an artist too.
Yes. I think this shouldn't be too hard to find if we ask in
debian-devel.
Thank you,
Behan
--
Behan Webster mailto:behanw@verisim.com
+1-613-224-7547 http://www.verisim.com/
Reply to: