[openbeos-cdt] Re: .pkg installer user interface
- From: "DarkWyrm" <darkwyrm@xxxxxxxxxxxxx>
- To: openbeos-cdt@xxxxxxxxxxxxx
- Date: Sat, 14 Apr 2007 14:16:17 -0400 EDT
> 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.
I do, too.
> Don't we have enough time for debates? The official coding period
Do we really want to go through with them? I don't know -- maybe it's
just that I'm cranky from not having had much sleep last night and
shouldn't be dealing with people right now. :-) If I sound irritable,
please keep that in mind -- I'm really not trying to be a grouch.
> 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.
We could, but wouldn't it be better to see if we can do a little
"hacking ahead" on some R2 packaging stuff?
> 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?
Maybe I'm not sure I completely understand the issue at hand, but I
thought
> > 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).
Yuck. As it is right now, once in a while I end up having to open a
file up in PackageBuilder to get just one file out of a package or to
inspect its contents. I hate it. It'd be worse if I had to do that any
time I wanted to look at the contents before I installed something. I
wouldn't want to have to open a separate app at all -- it disrupts
workflow.
> 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'm not so sure that it'll make as many people care as you think. One
of the things I've learned about non-technical users (from having to
deal with _so_ many of them) is that the majority of them have sadly
been conditioned to not explore an interface. Most concern themselves
with getting the job done and have a sort of tunnel vision which blocks
out any extraneous information. When they come to a complete roadblock
(often a MessageBox with some technical crap), they ask someone that
knows more than they do.
> 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.
Quite possibly. Then again, the logfiles may have been that way also. I
don't really think that a second tab (and not the default one at that)
is all that prominent.
> 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).
That doesn't sound like a bad idea. :-)
> 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.
The only reason that I even mentioned it was for certain edge cases
which even I find confusing (and have run into on occasion). Let's say
you have a package that installs things in multiple locations, none of
which go under /boot/apps and have a fixed location (such as ~/config/
lib). It would make no sense whatsoever to list a choice of folders or
even mention a folder at all. Showing any folder would not and could
not accurately describe where things were going. *shrug*
--DW
Other related posts:
