Slashdot Mirror
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."
Linux is an OS that was and will always be for a few academites plus thousands of system administrators. The path from OS to regular users is long and hard. Just look at OS/X...and notice, people were *paid* to do all that work.
Since we are the ones programming them, doesn't that mean that they've been conditioned to think the way that we do? After all, they're running our logic. Kind of like a small section of our minds...
Stop the Slashdot effect! Don't read the articles!
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.
READY.
PRINT ""+-0
Bruce
Bruce Perens.
I had this same argument with Steve Jobs in 1999. Today we have more people on the Linux desktop than on OS/X, and Steve stood in front of a slide saying "Open Source, We Love It!" at MacWorld.
Bruce
Bruce Perens.
There is a great article at Ars Technica by John Syracusa on this subject of the paradigm that the computer interface is based on, specifically spacial interfaces versus hierarchical interfaces:
About the Finder...
As a Linux user (and user of OS X at work) I have, like most of us here, am very comfortable with flying around in and out of the hierarchical nature of the file-systems on our computers. When giving my mother tech support over the phone, she is continually amazed that I can just list to her (while driving down the road) the series of directories that she had to go through to find her necessary document. A little after this, I read the above mentioned article which gets into why the finder in Apple's OSes =9 were so "user friendly" and got some new insight.
Like many of us, when using OS 8-9, I was always annoyed with how the icons would never line up and you very soon built up this annoyingly HUGE mess of windows whenever searching very deep for something. What I missed about this system in my attempts to over-ride it, are Syracusa's main points: - There is ALWAYS a one to one correspondence between folders and windows. I.e., you can't have the same folder open in two windows. - The contents of a folder ALWAYS look EXACTLY how you last left them, even if that causes some weird overlap or scrolling nastiness.
The result of the absolute consistency of the above two things is that when you interface with the computer, you can build a visual sequence of landmarks to your data. Something akin to driving your route to work. You may not know the names of all of the streets (directories), but still find your way because you can recognize the arrangement of streets, like taking the third one after the blue house. Syracusa gives the example of light-switches. After a couple of days in a house, you don't need to hunt for them because our minds have developed over millions of years to recognize these sorts of visual information so that we can find things in the world around us.
Contrast this with your the file browser in OS X, Konqueror, Windows, etc. When you open up a given directory you really have no idea what the contents will look like. This depends on the view options you chose in the parent directory as well as auto sorting and all of these such things. Because of this lack of visual consistency, you are forced to remember the file names of every parent of the file that you are looking for. While I do well with this and am perfectly comfortable keeping the whole darned thing in my head and navigating from the cli, MOST people aren't. This is one of those things that should be heavily researched (anyone doing a psychology PhD and need a thesis topic?) in order to move not just Linux, but computing in general forward.
"When ideology and theology couple, their offspring are not always bad but they are always blind." -- Bill Moyers
You can't accomodate them all with a single UI.
What is really needed is a virtual layer between the (G)UI and app that would allow GUI "themes", similar to the way that KDE and GNOME have themes for their WMs.
For example, say that I am using a program that displays various objects that can be moved, copied, etc.
Rather than receiving events like <KEY C with CTRL modifier> or <MB1 with mouse coord> , the program would receive events like <COPY> or <MOVE with delta/coord>
Then, the GUI theme that I was using would determine what keys/mouse movements generate what events.
Some programs already allow users to customize keyboard shortcuts and menus.
This would be like that, except that, instead of customizing per-application, it would customize across all applications.
The problem is determining the domain of events that the virtual layer would support.
Operations like copy, paste, and move are easy (and have already been done for things like text boxes); file open/save operations are semi-standard in that many apps use <CTRL+O> and <CTRL+S> (but not necessarily customizable, and certainly not globally); other, less common operations (e.g., drawing a line from point A to point B, adding to or subtracting from the current selection, etc.) could be handled using some sort of modular system (ala XML XPointers, etc).
Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana
Mod this guy up.
The only way the Linux desktop is going to become consistent, and not only from a GUI perspective but from a config file and usability, and application integration (i.e. clipboard) perspective, is for EVERY application that is available for UserLinux to filter through a single point of contact.
This group would then standardise (with regards to the GUI, config files etc) EVERY application that is submitted.
I dont see any other bullet proof solution. It would be a ton of work (and really shitty work at that) but it *would* work.
It's basically what distros are doing already with their different package management implementations, but taken to the next level; i.e. instead of making sure the package compiles/binary is not left with missling libs, you make sure of not only that but also the applications all have the same file dialog, windowing toolkit etc.
Invoicing, Time Tracking, Reporting