Revised 18 March 2003
If Linux is to achieve world domination, it must have One Frickin' User Interface (1FUI): a single user experience / interface behaviour and a single underlying UI toolkit API / widget set. World domination means putting Linux into corporations, schools, PDAs, and cell phones. This will only happen with 1FUI, and if this upsets the nerds, too bad. History clearly shows that if a platform/system offers a choice of user interfaces, the potential users will choose a different system.
The 1FUI does not have to mean throwing away all existing code. It will be possible to emulate most existing APIs, but not the look and feel, sufficiently well to make rewriting not too painful. But again, if world domination means that a large number of crappy X programs no longer run, too bad. Tens of millions of new users are far more valuable than an existing user base of thousands of nerds.
Which of the current user interfaces will become the 1FUI? This is an issue over which much virtual blood has already been shed. Frankly, it doesn't matter which, especially with API emulation, just as long as there is only one. Without 1FUI, Microsoft has a major competitive advantage over Linux.
The 1FUI will require the backing of a major vendor as champion and enforcer to succeed. An explicit purpose of the 1FUI will be to help Linux vendors and application developers sell more systems. If you believe I should be referring to "GNU/Linux" instead of "Linux", stop reading now.
A last point: this was prompted by a Free Standards Group Future Linux Survey, and Linux certainly is the most talked about of the various free operating systems. But you could substitute "BSD" for "Linux" throughout and the argument still stands. Jealous FreeBSD developers take note: here's your chance.
The current state of Linux GUI toolkits is complete chaos. There are the big two: KDE and Gnome, and a number of smaller UI toolkits: FLTK, wxWindows, TK, Lucid, and others I don't know about. Same for window managers: Enlightment, FVWM, whatever. Individually, they all have good points and were created by well-intentioned and hard working designers. Collectively, it's a disaster.
History shows that on every previous occasion competing UI toolkits were on offer for a single operating system, none of them won.
Case 1: VisOn vs GEM vs Windows. Winner: Apple Macintosh.
Throughout the mid 80's there were two or three competing GUI toolkits for MS-DOS, and OS/2 on Presentation Manager as well. The clear winner in this timeframe was the Apple Macintosh. It wasn't until Microsoft had finally buried the others in the 90's that GUIs on Intel were any kind of competition.
Case 2: OpenLook vs Motif. Winner: Microsoft Windows
The Unix workstation market had its own GUI war in the late 80's. The application developers, and customers, went with Windows instead. (Along with some Macintoshes.)
Case 3: SunView vs OpenLook. Winner: Motif.
In the closest parallel, Sun Microsystems was for a while in the interesting position of competing with itself. Like Linux today, you had a choice of developing for either SunView or OpenLook. They both lost, and Sun eventually were forced into using the Motif based CDE.
There are some bizarre contortions in the thought processes of the Linux community here. The mere possibility that the Linux kernel might fork will generate panic, and Linux advocates point to the existence of one kernel as a major advantage over BSD. Yet somehow multiple UI toolkits is all about choice and evolution.
Offering a choice of user interface toolkits is about as useful as offering car drivers a choice of which side of the road they want to drive on. I could use photocopier paper, VCRs, traffic signs, electrical power supplies, or shipping containers for examples of why consistency matters, but since most people reading this are probably geeks, consider network protocols.
Linux has a TCP/IP networking stack in the kernel. The developers of said stack chose to implement the IETF TCP/IP protocols and the BSD socket API, exactly as specified, rather than design something new. Why isn't there a massive outcry about this failure to innovate and lack of choice? Or why get upset by Microsoft creating extensions to HTML that only work in Internet Explorer? Doesn't this kind of competition improve every system in the long term? (Yes, those were rhetorical questions.)
There's a tendency among Linux advocates to think of the Windows majority as mindless sheep, brainwashed or coerced by Microsoft into buying their software. Well, I know a fair number of Windows users and system purchasers, and they are not sheep. They are well aware of the dangers in being locked to a single vendor, but the benefits - of which a consistent user interface is one of the most important - outweigh the risks.
User interface consistency was, and remains, the primary reason for the success of the Apple Macintosh. It was so productive that organisations were willing to dump huge numbers of PCs in favour of Macs. Microsoft had to spend a fortune developing Windows to compete, and then another fortune porting their Macintosh office applications across. The companies behind the dominant office software at the time, Lotus 123 and Word Perfect, didn't think a consistent GUI mattered. They're gone now.
User interface consistency is, I suspect, the main reason why the announced large scale deployment of Linux in Mexican schools was cancelled, and why those corporations currently evaluating Linux will most likely return to Windows. Deploying ten thousand copies of RedHat or any similar Linux is easy. Then you have to explain to ten thousand users that the Copy and Paste commands work from Mozilla to KOffice, but to go the other way you have to use Copy and middle mouse button instead. And why the Open File dialog in Acrobat Reader has different columns for directories and files, but in KWord there's just the one which serves both purposes. And why...
Geeks like us tend not to see what the problem is, because we spend huge amounts of time learning about and dealing with the complexities of computer systems. If you have to memorise the intricacies of programming language syntax and command line options, what's the big deal? For everyone else, this kind of training and support is hugely expensive.
It is amazing that so far Microsoft have not emphasised their own 1FUI in their "competitive evaluations" of Linux. I can only guess that good UI design is not highly thought of in Redmond either. But this blind spot cannot be assumed to last.
First, let's distinguish between choosing a UI and choosing an API. The UI is the user experience, look and feel, behaviour and appearance: what the users care about. The API is what the application programmers write to.
In the Windows and Macintosh worlds there is a core UI widget set and API. This core API remains stable over time, but the UI can be changed. NT 3.5 to 4 was a UI switch but not API, as was System 6 to System 7. (Yes, there were new additions to the API, but the old code ran with the new appearance.)
The core API for both Windows and Macintosh is procedural C language. Alternative APIs such as MFC or Cocoa are written on top of the core API, ensuring that the UI will still be exactly the same and that the program will automatically inherit any new UI behaviour. Regardless of whether you write Windows code in straight C to Win32 or with C++ and MFC, you always get a single consistent set of menus, buttons, and other widgets.
In Linux, each API has its own widgets and distinct UI. KDE menus aren't quite the same as Gnome menus which aren't quite the same as Lucid menus... From the outside, it is hilarious. From the inside, tragic. How can the open source community claim to be a superior development model with such a massively bloated and wasteful reinventing of wheels going on?
Linux must move to the successful Windows/Macintosh model if it is to achieve world domination: one library, one widget set, one API. This won't interfere with your sovereign right to run your own window manager if you really, really, want to, just as you can rip out TCP/IP and run only AppleTalk if you want. You will have the source.
The first step is to pick a UI. I have my own thoughts on this later, but frankly it doesn't matter too much which one is chosen. There are times, and this is one of them, when any decision is better than none.
That said, there are some requirements for the UI:
It must be possible to implement on top of Xlib. Yes, X Windows is horrible in lots of ways and it is very tempting to just throw it all away and start over. But like it or not, XFree86 is the only viable choice right now for building a graphical Linux environment on. There are a lot of hard working people involved in XFree86, and no evidence that any new graphics layer will be so much better to make changing worth the pain. With modern extensions like TrueType fonts and Xrender, Xlib itself is bearable.
The core API has to be a C language binding. This doesn't mean developers are forced to write everything in C. The goal is to make it possible to write 1FUI applications in any language: C, C++, Python, Java, Objective-C, Perl, whatever. C libraries are the only ones that can be called from every programming language, so if the 1FUI API is to be used by everybody, it has to be C. (The implementation of the 1FUI core widgets can be done in C++, provided that a pure C API is always and automatically generated as well.)
100% compatibility with existing code is not a requirement. The transition to the 1FUI should be as painless as possible, but some rewriting will always be required and is acceptable as long as the benefits outweigh the cost. And let's be honest here: no one outside the nerd community has the slightest interest in most of the existing X/GUI software for Linux. Losing the ancient junk would be an improvement.
It has to include window management, desktop management, interapp communication, file typing, printing, and fonts. "Well written X applications will run under any ICCM compliant window manager" is crap. The window manager and file/desktop manager are part of the UI. Cut and paste, drag and drop has to work with every application, every time. "Mechanism not policy" is crap: designing the UI is setting policy. If forcing UI choices on people makes you uncomfortable, don't worry. All you need is one arrogant know it all user interface designer such as myself to make the choices for you.
Which brings us to the last requirement: it has to be an existing, well known, stable UI. The goal here is not to design the perfect UI, or even a better UI. It's to pick one, right now. Open source projects are good at many things, but closing the feature set and saying "it's finished" are not among them. With the 1FUI there won't be arguments or debates about what the window title bar should look or where the buttons are placed in a dialog box. The answer will always be "whatever the original does." Improvements can wait.
An obvious possibility is to choose one of KDE or Gnome. If the former, we write a 'knome' emulation library on top of KDE/QT. If the latter, the KDE developers have to drop Qt and use 'GKDE' instead. All development work on KDE/Gnome has to be put on hold until the 1FUI is complete. Either way, a huge pool of useful and at last consistent applications is created. The developers of FLTK, Tk, and Lesstif will see the light and rewrite their own libraries as wrappers around the core widget set as well.
Regrettably, if it was that simple, it would have already happened. Choosing either KDE or Gnome is guaranteed to seriously annoy too many people from the other side. Neither wants to admit 'defeat.'
When I first wrote this I thought it would be better to choose a third 'neutral' UI, which would at least leave everyone equally dissatisfied and with an equal amount of rewriting to do. Since then I've spent some time with the newer versions of both, and changed my mind.
Gnome 2 is the 1FUI for LinuxThe Gnome project started as a bunch of gnerds trying to prove their ideological purity and adherence to the path of RMS. They got us into this mess in the first place.
Somewhere along the line, though, the Gnome project has been taken over by real people. It's actually become simpler, unlike KDE. And companies like Sun and RedHat are willing to do the hard, boring, but absolutely essential polishing and fine detail, for instance in accessability.
One more step has to happen. A major company needs to act as champion and enforcer of the 1FUI by bringing out a distribution that runs only Gnome apps. I say a company, because it has to provide carrots to help persuade the other developers to undertake the task of rewriting, and the stick of being left out of a high volume distribution if they don't. It might even be better to concentrate on getting Lesstif and the other smaller toolkits rewritten first and generate a snowball effect while KDE is left to slowly die.
Gnome 2 would be the best choice for the 1FUI, but there are other candidates which could be used to break a Gnome vs KDE deadlock, or as the standard for making design decisions.
My first choice would be NextStep, the only Unix ever highly regarded outside university computer science departments. It was heavily based on Display PostScript but we wouldn't necessarily have to continue that as OpenGL and TrueType provide similar scalable vector graphics capabilities on todays systems. (And you never had to actually write PostScript unless you wanted to: setting up menus, dialogs, etc didn't require it any more than creating a menu in KDE or Gnome requires Xlib programming.) NextStep would also have the considerable advantage of being similar to the current MacOS X Cocoa API, which would encourage Macintosh developers to port to Linux. A disadvantage is that the core API is in Objective C which is unfamiliar to most developers, but a straight C API could be generated, as Apple have demonstrated with MacOS X.
Swing is in large scale use with a lot of applications written for it. Yes, I know it is Java. But it is a good modern design and a native C/C++ implementation might even be blessed by Sun as it would make Java applications run faster and integrate more cleanly into existing systems. Or if Sun won't cooperate, how about the IBM SWT Java toolkit?
A real wild card would be the Amiga. Seriously, it had menus, buttons, dialogs and all the other standard widgets we use. And the most fanatical user base on the planet, which helps when taking on a task of this size.
The One Frickin' User Interface isn't essential for Linux to survive and prosper, only for Linux to achieve any kind of world domination. Without it I expect the future will look more or less like it does today. Linux will remain the operating system of choice for servers and computer science workstations. KDE and Gnome will continue their pointless competition. Cell phone and PDA manufacturers will choose Linux as the core OS and write their own proprietary and closed UI toolkits to run on top, although there is a good chance that they will find it easier to license PalmOS or CE instead. And Microsoft will retain their 90% or better share of the home and business PC market, while Linux advocates keep chanting "any year now."
Back to Writings