[Top][All Lists]

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

Re: Installer UI advices

From: M. Uli Kusterer
Subject: Re: Installer UI advices
Date: Sat, 12 Mar 2005 08:11:54 +0100

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.
M. Uli Kusterer
       "The Witnesses of TeachText are everywhere..."

reply via email to

[Prev in Thread] Current Thread [Next in Thread]