Team Murder No Brain No Headache.


The Heartbreaking Exclusion Of The Noble Consumer From Better Design Decisions And Increased Stability

I'm actually a big fan of unifying APIs. I'm not a fan of the oft mentioned 'combine all distros or Linux is doomed' strategy most commonly referred to by those who haven't a clue. This is worsened by articles like this one over at that argue that the Portland Project will never work because Redhat's Bluecurve failed to unify desktops and blah blah blah. The lack of comprehension here is a little startling. The unified look and feel folks have been at it hammer and tongs for as long as I can remember and the claim that a lack of common interface will ruin the user experience, bring dark plagues to the land, and other ill considered predictions of doom is not by any means a new one.

The other part that is not new is the lack of understanding when it comes to the announcement of desktop initiatives. Yeah, theming and other eye candy efforts are usually the first things proposed when someone gets another brilliant 'unify the desktop environments' epiphany but making common APIs is not a bad idea especially given the fact that developers are in no way obligated to necessarily use them. That is one of the greatest strengths of the platform: the freedom to totally ignore Gnome's HIG specifications if they don't make sense for your application and also the freedom to ignore the junk in the trunk clutter of KDE's configure everything all the time interfaces. You don't need to follow any of them and there is no overarching part of either desktop environment that obligates you to follow all of their specs whether they are fantastic or terrible. None of things is a panacea and cannot be as there is no embedded desktop (for most distributions) that forces folks to design with a certain goal in mind.

In a few senses the post I'm talking shit about is correct: there is no single solution for this problem. Of course, the caveat here is the lack of a unified perception of discreet pieces being part of the desktop environment as a problem. For people slugging it out with code that needs debugging for, you know, actual functionality this entire drama has to seem like little more than a bad joke. It also shows how far along Linux really is in terms of desktop usage. For those of us who have logged a few years in the not-so recent past working with Linux machines, a lot of us remember when worrying about similar looking applications was the very least of our problems. It wasn't so long ago that simply getting an IDE CD burner to work was a SCSI emulating pain the ass. Most distributions these days pick it up on the fly if you have access to the root account. If you've never set up a USB connection with a PDA under Linux you haven't really had fun. I've spent more time fussing with the creation and subsequent deletion of /dev/pilot than I'm happy to admit. Most of that has exited the playing field and that is cause for celebration almost by itself. Hardware mostly works (more so than Windows given the lack of commercial drivers for most devices) and software is increasingly functional, powerful, and in many cases pretty damned simple to use. The appearance of things rarely concerns me although it is apparently a headache of some kind for new users who are already accustomed to most things working out of the box with the 'hard' operating system.

Better planned and more inclusive APIs will benefit the sort of folks who demand (despite the gales of sarcastic laughter issuing from behind the curtain) resemblance to certain commercial OS's in terms of similar functionality (copy and paste are always perennial targets) and behavior. You can't lose with more functionality that is similar being paired up with more applications. The applications get hacked less than the API which is kind of the idea but, like most things even tangentially related to Linux, the big design decisions remain largely in the hands of the developers writing the software and are not decided by focus group or committee. That flexibility seems to work better for developers who use the platform for the sake of being able to make their own fundamental decisions (among other reasons obviously) than it does for end users. I'm still not completely sure that Linux is the best fit for end users but I'm equally convinced that bending the direction of active development towards the wants (not needs and I cannot emphasize that enough) of users who don't contribute anything back unless you consider market share some kind of hot commodity is a really terrible idea. If nothing else formulating APIs like the Portland Project give people cranking out the code the option of adhering to a design principal and if users are captivated enough by these particular shiny objects then I guess you've got some degree of success.

I'm actually pretty happy that arbitrary standardization hasn't become an important issue for more than a few peripheral players and the obvious big money vendors like RedHat and SuSE. Considering the depth and scope of the internal changes that might make Linux some kind of desktop contender makes me a little less anxious every time I read some bitchy thread in a forum somewhere. It also makes realize that catering to the whims of the consumer is a job best left to third parties and not the main designers. This is why you can still buy cars that don't look like they were imagined by a three year old but every Auto Barn is full of adhesive backed spoilers and the like for those who can't imagine driving around the strip mall without some cheap plastic accessories plastered all over their cars. This is just good design in practice.

Comments (0) Trackbacks (0)

Sorry, the comment form is closed at this time.

Trackbacks are disabled.