What Might UserLinux Look Like?

Lucky writes "This story at Linuxworld talks about some of the potential features of UserLinux, as well as Bruce Peren's proposed community desktop project and its potential features. There's some exclusive commentary by Perens there, too."

Comments

UserUtopia?

[tarquin_fim_bim]

If there were a problem with Linux distributions per se it wouldn't be with the Desktop, that's fine in most distributions, it would be in the diverse configuration file locations, they all seem to have differing ideals here, perhaps a more powerful and consented POSIX definition would be an advantage, rather than the current continued divergence. Apt,portage or rpm etc. working on any distribution would be my idea of UserLinux.

Re:UserUtopia?

[Neo-Rio-101]

I think there needs to be more unification and simplification over the way things are installed in , not only Linux, but the BSDs as well.

I think everyone agrees that rpms suck. Most of the good code comes in source tarballs - configurable for any *nix... but this is where the user experience falls apart. What person is going to want to dig out the command line to compile source code, and will he or she know about all the ocnfigure options... and then, will there be dependency issues (or should the source contain the dependencies too?). Then there are the legal issues of bundling dependancies... and then there will be future commercial Linux apps which won't want to include source code.

In an ideal world, packaged installs will be a compressed single file, containing all source code, configurable on any *nix like normal source code EXCEPT that now there's a graphical interface so that setting compile options, creating desktop shortcuts, and "Make clean, make install, make uninstall" now all work under X with a point-and-click.

PLEASE! Will someone serious about standardizing Linux installs do something about this... or desktop Linux will never take off.

A good thing

[LordKazan]

I see a lot of talk (whining/b1tching.. take your pick) about "reinventing the wheel" when it comes to new desktop environments - that make it easier for John and Jane Doe to use linux. --- This is counterproductive, it's not "reinventing the wheel" to write a new window system because you think the previous ones "suck" as far as the average user is concerned. If Motif/Lesstif were really enough, would Gnome, KDE, etc even exist? NO

The UserLinux initiative is an excellent chance for us to penetrate into the mainstream desktop market and start making software houses recognize and implement for linux - because their target audience can finally use the system.
The list posted in the article looks to be a rather [complete] connonical set of programs. --- This has been just a few, incomplete, thoughts ---

hmmm

[nomadic]

How about they make it not ugly?

Linux could do with a few less 37337 coders and a few more artists and graphic designers, people who have an understanding of what colors work together, and most importantly what proportions are pleasing to the eye. The thing I like least about linux is how so many little aesthetic things are off. Dialog box fonts are a little too big for the dialog box, the borders between windows are too narrow, nothing matches like it should.

Hmm....

[Faust7]

What Might UserLinux Look Like?

Well, if the link's any indication, UserLink will look very rectangular. And white. Did I mention white?

And who's Bruce Peren? Nice to see a new name bursting onto the Linux scene!

Where to begin...

[Preach the Good Word]

Typical Linux Geek thinking ease-of-use = dumbing down and that a good interface means pretty icons.

Ease of use means making the computer work the way PEOPLE think, not forcing people to work the way COMPUTERS think.

Linux geeks and other developers, who have been conditioned to think like the computer because of the work they do, have the mistaken notion that advanced computer user means a user who has learned to force the natural human way of doing things into the artificial machine way a computer does things.

Any interface that doesn't force this paradigm is "dumbed down."

The truth is, the Linux geek has simply been conditioned to do things the difficult way, not the natural way. Designing the interface to do things the natural way is not dumbing it down, it's making the Linux Geek's paradigm obsolete. Of course, the Linux Geek doesn't like this, so in a fit of human ego, he looks his nose down on anything that points out the stupidity of his position (working the way the computer demands; being the tool of the computer), and calls it "dumbing down."

Linux Users

[Anonymous Coward]

What might a Linux user look like?

Re:Best answer...

[Xarius]

Y'know there is more to what you said than joke actually. A previous comment suggested computers don't work like the human brain--you are just conditioned to think like a computer.

The command line works more like a humans way of thinking than a GUI, for example:

$ mkdir my_files

which is pretty sensible, aside from the contraction of the words "make directory". A user wants something done, they TELL the computer what to do. IMHO this is more intuitive than, say,

right click on an unoccupied are of screen,
select create new folder,
enter name for new folder,
refresh screen to see new folder.

bah, I'm probably wrong.

Better standards and documentation

[Nailer]

The Linux Standards Base already deals with file locations and packaging formats. The main problem is that it isn't comprehensive enough. There's still no way you can reliably determine where the IP address for your network card lives across distros.

Something else that'd increase desktop Linux: accurate, up to date documentation. Man pages are hopelessly out of date (read man resolv.conf and find out that most machines should be running local copues of Bind, or the various setting up a SLIP PPP connector on kernel 2.0 docs on TLDP).

Re:Better standards and documentation

[joto]

Man is out of date for a reason - it's deprecated and hasn't been used for ages. Try info instead, that's where you'll find up to date documentation for most things.

Good troll. Now, about the only person who seems to think man is deprecated is RMS and his cohorts, and as you say, they seem to prefer their own obtuse documentation system info.

While info might sound like a good idea for some developers too lazy to write man-pages, or a real manual in a readable format, it's completely ridiculous for the rest of us.

First, GNU documentation guidelines state that an info manual should be both a tutorial and a reference, which flies in the face of any advice you could get from both people experienced in reading or writing manuals. While man-pages are at least good for getting a complete reference of something, info-pages are almost always completely confused about their purpose, being as comprehensive as the average man-page, but much more wordy, making neither a good introduction nor a good reference.

Second, there is the file info.dir, which must either be manually updated, or gradually fall into a long unorganized mess of links pointing everywhere, but without any comprehensible organization.

Third, there really aren't that many programs having an info-file. While you can expect almost everything to have a man-page (and possibly point you at the info-manual), the other direction is not as common. A good documentation solution should probably have some way of accessing info-files, because of their historical significance, but it should not be based upon it, as it is quite despickable. The same can of course be said of man, but man never tried to be everything you need.

Last, the GNU info program has a loathsome user interface, with keybindings as intuitive as those found in dselect. The emacs version is slightly better, but requires you to run emacs. But apart from the other problems with info, this is actually fixable.

In conclusion; there are serious problems with GNU info. It is certainly not better than man, in any way. Man makes it easy to incorporate it as part of a better help-system. Info makes it hard, and instead tries to be everything for everyone, but fails completely at the task. A good documentation system should cater for the user, info seems to only care about the person writing info manuals.

Consistency and control

[gidds]

The problem AISI (from a distance :) isn't so much that individual apps, widget sets, &c are ugly, but that they're inconsistent - they're all ugly in different ways.

What's really needed IMO is consistency. Dialog boxes, for example should have the same style across applications &c. - and that doesn't just mean the font size, or even the font; it means having a similar layout (where appropriate), with buttons in a similar order, the same default focus, similar keyboard controls, similar positioning. And the same principle applies right across the GUI, from having the menus arranged in a similar fashion with common menu options in similar places, to similar behaviour of toolbars and palettes, and so on and so on.

The trouble with this is control. This sort of consistency would mean developers willingly going with someone else's design principles and UI guidelines, and too many developers seem too keen on doing their own thing to let this happen, whether from a desire to make their app stand out, thinking (rightly or wrongly) that the usual principles don't apply to their app, incompetence, or just sheer stubbornness.

Not everyone has graphical skills or UI design skills, so IMO we need a way of working where developers who want to can do so without needing those sorts of skills, but without inflicting that lack on their users. I think this is one of the fundamental problems that the free software community needs to address. GUI toolkits are a step in this direction, but clearly don't go far enough.

Maybe we should consider some fundamental reorganisation. With everything split by application, each has its own way of doing things; what if there was some other way of doing things? What if application developers yielded ultimate control of their GUI to a separate project of some kind? I've no idea how this might be done technically, and even less idea how developers could be brought on board, but IMO it's the only way to achieve the sort of consistency, predictability, and least astonishment that more centrally-controlled systems have.