Re: Installer UI advices

[M. Uli Kusterer]

At 23:39 Uhr -0500 11.03.2005, Jeremy Tregunna wrote:
> Because Unix (and Unix-like systems) have a certain filesystem 
> hierarchy that they're bound to. For sake of simplicity (in 
> developing said systems) it's generally easier to go with 
> convention, then trying to implement something completely different, 
> that may or may not be more intuitive to the user. Millions of us 
> have "grown up" with the way this is done, and having it done any 
> other way would just seem silly (as you have just pointed out)... 
> It's a matter of perspective.

 Just to put another (slightly polemic) spin on this: By this 
rationale, since everybody grew up with Windows, we should just let 
them use Windows, because they know that best. They have "grown up" 
doing that, and having that done any other way would just seem silly.

 The whole point in GNUstep is that, back in the 90s, a charismatic 
if slightly hard-to-handle ex-Apple-co-founder assembled some 
promising students around him and created an operating system that 
did lots of odd things neither Windows nor MacOS did at the time. And 
then, later, some people used this system and realized it was so much 
more convenient for them, and helped them make so much more effective 
use of their time, and when it went under they said: "I want to 
create something like that again, because I can't stand using 
anything less anymore.

 The main problem the Mac and NeXT were/are facing is that Windows, 
KDE, GNOME and all the other desktops these days look exactly like 
them on the surface. Only once you've used them you notice how much 
better they are. Before that, when you're mucking around with MFC, Qt 
and PowerPlant, you think any improvements can only be superficial 
and aren't wort the expenses.

> > This is mindset of the typical user. Put the power in their hands 
> > to do what they want with their computer, and don't make the 
> > computer invade into their lives and space.
>
> Then you run into problems with user X having files in location 
> /foo/bar, while user Y and Z may have them in 
> /my/gosh/my/files/are/so/organized. However, 40 thousand other users 
> may have 40 thousand other different places to put the same files, 
> it makes for hell.

 Not necessarily. Remember, many computers are used by only a few 
people. Everyone who spends a lot of time on their computer usually 
has a computer of their own these days, and probably would have only 
one user account set up if their computer didn't come configured with 
several accounts out of the box, like root, an admin account, the www 
account and who-knows-what-else. I certainly never log into any but 
my own main account.

 If there's only one effective user, there's no problem with the way 
the files are organized. Nobody else will see them. It's different in 
client-server accounts in computer pools and companies, where it'd 
make life harder for the administrators, but how many desktop 
computers actually are set up that way?

> > This invasion of the computer's world into the user's world is not 
> > exclusive to *nix. Windows is the same way, so countless people get 
> > used to having to see their workspace littered with things they 
> > shouldn't have to deal with. I don't think that's right. They 
> > should be able to manage their computer as they see fit, not how 
> > the computer sees fit. The computer should be invisible.
>
> 99% of the time, a user need not navigate outside their "home 
> directory" (under windows, this would include my documents, my 
> pictures, etc; under Unix systems, would be /usr/home/joe_user (or 
> wherever you keep your home dirs). And you can organize this however 
> you like, more power to you; but changing the where the system files 
> are, is just silly in my opinion. Leads to more problems (with 
> regards to upgrading programs) than its worth.

 Applications aren't system files. They're tools. Why force everyone 
to hang their tools on that big workbench there, when most 
applications are only used by one particular person, and only in 
concert with certain files? If I constantly use my drawing 
application on the files for my comics, why shouldn't I be allowed to 
just put the app next to them in the same folder for easy access?

 Things like an Applications folder were necessary way back in the 
command-line days, because there had to be some way to decide what 
command got executed when you typed a command in the terminal. But 
GUI applications have no *technical need* anymore to be in such a 
centralized repository. Some of their support files, yes, but bundles 
have made that unnecessary. If NeXT introduced this flexibility for 
some apps, why not try to extend that to more, and more complex apps?

> Not all package managers are as abhorant as some are when installing 
> files (but some are, and some are worse... just means we need to get 
> rid of those package managers).

 Wasn't that the main point of Installer.app? To provide a nice means 
for installing packages? And if we're rolling our own in just 
improving on an existing manager, why not aim high? There's no 
problem with apt-get and similar systems being used under the hood by 
Installer.app, but if you really want to make this more than just 
"yet another GUI on top of a standard package manager" (and GNUstep 
already has at least one of those), it helps to try and rethink the 
current metaphor.

 As Matthew Thomas, I think, said once: "When was the last time you 
installed a piece of paper?" As long as people still understand that 
sentence, there are still improvements possible in package manager 
design.

> That's perfectly  fine, Unix systems aren't for everybody, and 
> anybody who claims the contrary is full of it. (I'll continue this 
> thought in the next section.)

 Okay, this is a different argument :-) If you're saying that GNUstep 
really is just another *nix system, and it *should* be hard to use 
because anyone who doesn't understand this simple stuff has no 
business using such a complex and dangerous system without being a 
walking security risk, there's not much I can say against that, 
except maybe "it doesn't have to be that way".

 I'm a geek, but while I occasionally have fun working out the 
configuration of certain packages, my main goal eventually is to 
achieve certain tasks. These tasks are complicated enough already, 
and people can only solve one problem at a time (they can 
"multi-task" when doing stuff they already know, but solving new 
problems requires more brain-power). So, the less I have to think 
about the computer and the more I can just focus on my task and get 
work done that will actually get my rent paid, the better for me.

 So, agree to disagree, I guess.

> Sure it can be done, and probably more easily than some might think, 
> but the problem doesn't end with project X. Fixing project X is one 
> thing, but what about the 100 thousand other possible pieces of 
> software (and more) that the user may choose to install on their 
> system. Logistically speaking, it doesn't make much sense to try and 
> impose this on a large scale, not unless you're willing to do this 
> large amount of work. Personally, I got better things to do, like 
> spend time with the family, and work on functionality, bug fixes, 
> etc for other projects.

 All we can do with GNUstep and any of the peripheral or 
desktop-related projects is make an offer. We can't "impose" 
anything, and if we could, we wouldn't want to. But for all 
"mainstream" applications and tools and packages, we'll want to have 
installers. If one person writes an easy-to-use installer framework, 
and if each packager takes the time to take advantage of this 
framework, then that means that, while the packager may end up 
spending more time than he would have, this time spent will still 
save all other people who download and install the package hours.

 After all, when a packager spends 1 hour on additional improvements 
to the installation process, *everyone* gets to benefit from that. 
When the packager doesn't, *everyone* has to perform the same 
additional steps to install the package, and that means what was 1 
hour suddenly turns into 1 hour * <number of downloaders>. And 
usually, the packager is much more knowledgeable, so what took her 1 
hour may take the average client of the package 3. Users aren't 
stupid, they simply have different strengths, just like my physician 
is not a good web page designer, but I wouldn't dare trying to do 
surgery either.

> > No, better than that. We need to think _like_ them.
>
> I don't think there's one single developer on this list who couldn't 
> possible comprehend what a user wants. With this statement you seem 
> to imply that developers aren't users either, when, we are.

 He seems to, but what he actually is saying is one of the 
foundations of good user interface design: Developers are definitely 
users, but they're atypical users, because it is their job to be 
computer users.

 Talk to a sports professional, and you'll quickly notice they 
encounter and solve problems each day that anyone doing this sport 
just as a hobby probably never knew existed. Same with developers and 
the average user: The average user is a professional in some other 
field who has branched out into computers to help them do their work. 
They have enough to do with their own problem domain that they can't 
be expected to heap a whole ComSci degree on top of that.

> This kind of thing is already done (80%) by almost every package 
> manager. They don't tell you where the software is installed (at 
> least any I've seen) unless you dig into their package list, which 
> as you point out, no user should have to do. This is a weakness that 
> can be solved, but it's not as easy as you may think. Might work 
> fine for 50 applications, but then you'll run by one that it just 
> won't work with, what do you do then? Eventually you can only adapt 
> a system so far before it turns into an overly complex piece of crap 
> that barely does its job well anymore, not to meantion leaves a lot 
> to be desired when it comes to maintaining it.

 This problem can be solved the same way slowly running programs can: 
Profile. Find out where your users are spending their time, where 
most users run up against a wall. If you improve those spots for 
them, their overall performance will increase. If one app is so 
incredibly complex it requires a specialized installer, there's not 
much we can do about that. But we needn't make life miserable for 90% 
of users who'll never use that app just because we can't solve it for 
this one.

> This is why God ... I mean Steve Jobs and friends spent much time 
> working on systems that do just what you want. I doubt your Mom is 
> going to have any need to poke around the file system much more than 
> looking for her documents, opening up her "Applications" directory 
> to start an app, etc... (Though admittingly, I don't know your 
> mother, so that's only a loose assumption.)

 The point of simplifying the file system or installation processes 
is not to make it easier for Mom to poke around in them. Rather, it's 
to make it easier for her to ignore it. If there's only one system 
folder, it's easy to tell her "don't touch that" and let her mess 
around with the rest.  The more dangerous folders are around, the 
easier it is for mom to mistake "Library" with her "Books" folder, or 
"Desktop Backgrounds" with her "Desktop Designs" folder because she's 
a little distracted right now. And if that already hoses the system, 
the system is too dangerous for her to use.
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
       "The Witnesses of TeachText are everywhere..."
                   http://www.zathras.de