[openbeos-cdt] Re: .pkg installer user interface

  • From: "Waldemar Kornewald" <wkornewald@xxxxxxxxxxxx>
  • To: openbeos-cdt@xxxxxxxxxxxxx
  • Date: Sat, 14 Apr 2007 16:07:57 +0200

Hi Jon,
sorry, in advance, for the nitpicking. :)  I just think that apps
which every user will get in contact with have to be as good as
possible.

On 4/14/07, DarkWyrm <darkwyrm@xxxxxxxxxxxxx> wrote:
I'm not normally one to be completely inflexible, but no. The original
design is good and by staying close to it, development will be
signficantly faster because there will be no debates over new designs
to slow down the process. Minor tweaks here and there are OK, though,
especially if they are usable or speed up development. Just like R5 is
the target for Haiku R1, this should be also. If the original design
were bad, I'd say go for it, but if it ain't broke, don't fix it. :-)

Don't we have enough time for debates? The official coding period
starts May 28th and the students get nearly three months for coding.
The installer isn't a *huge* application and Ryan already did some
research on the .pkg format. I think we could spend one or two weeks
on discussing a better design.

If everyone disagrees, I'll concentrate on the most important issues.

> I think the tabs view should start at the same height as the list
> view
> (instead of its label) to make it more obvious that both views are
> connected. The list view's label could be replaced with a BBox to
> make
> this even more obvious.
No. BBoxes are used for grouping together controls which have belong in
the same category (try the Mail preferences window), not as labels --
that's what BStringViews are for.

In this case we have two fields that belong together (install type,
description/info) and the description already has a BBox around it
(which wouldn't be necessary, anymore).

Primarily, this was about making it more obvious that the tabs belong
to the list view by moving them down a little bit. What about that?

> There could be capitalization issues, but I don't think we have
> agreed
> on any rules, yet.
IIRC we officially changed from Apple-style capitalization rules to
GNOME style. I just haven't updated the HIG.

Ah, right, I remember (on the commits ML). Then, the labels were
correctly capitalized:
http://developer.gnome.org/projects/gup/hig/2.0/design-text-labels.html#layout-capitalization
But it should be "Installation type", then, if I've understood correctly.

Yes, we do. There are quite a few people that don't care what happens,
but I personally like to know what's being installed on my system *
before* I tell it to start. This is more of a feature for power users,
but it doesn't get in the way for others, so it IMO should stay.

Experts can still use the package builder (or we could have a simple
package inspector if there won't be a builder).

IMHO, it does get in your way because by providing this feature you'll
make a lot more people care (out of curiosity, just because it's
there) and waste time on something that isn't important (works well
without it on other platforms), makes the installer appear more
complicated for non-technical people (or will we change the design for
R2/R3?), and can't be changed, anyway.

I think this feature was added for one single reason: you couldn't
uninstall packages, so you had to know where the files go. As we had
discussed via the GSoC web app, we want to have a simple
uninstallation function (you couldn't have known this), so I don't see
a reason for making that information so prominent. A separate
inspector is more than good enough, IMHO.

> As far as I remember, many apps only have one single profile and
> there
> are rarely more than three profiles. IMHO, a list view is only
> appropriate if:
> * you expect to have many entries
> * switching between entries must be very efficient
> * you must have an overview of all elements
> I think that of those three only the last one might apply, but a
> pop-up field could be better suited for this task and result in a
> more
> compact UI.
Very reasonable idea, but in this case, I don't think it's really
hurting anything. In fact, if you asked me it's helping *because* it
isn't as compact.

The pop-up field could be replaced with a BStringView when there is
only one option, so you could easily recognize when multiple options
are available (if that's your concern).

Well, because of the installer's simplicity it indeed doesn't really
hurt, so I won't insist on it. I just think it's overkill in most
cases.

> Is there any need for splitting the installation volume and the
> installation folder ("Install on ... in ...")? Why not have one pop-
> up
> with the full path? The pop-up could automatically offer pre-defined
> paths for every volume and a "Custom..." item for choosing your own
> path (when paths can't be chosen "Custom..." would be grayed-out).
I believe that was the reason why -- if only the target volume could be
selected, the folder selection popup was not displayed. Combining the
two menus is a good idea only with two stipulations:
1) Common paths should be displayed for the boot volume.
2) Packages which only allow selection of the target volume display
only volume names and icons.

I agree, but *maybe* (1) should also offer other BFS volumes since it
could be a common use-case among experts to have multiple partitions.
What do you think?

Bye,
Waldemar Kornewald

Other related posts: