Linux: Not Ready for the Big Time

User Interface Experience

Of course, GUI problems are only an issue if one is using the GUI to begin with.  In the Linux community there is still a prevalent attitude that every computer user should have, at least to some degree, a willingness to open a Command Line Interface (CLI) and type away at their computer.  This will not fly with an expanded userbase.  GUI and CLI are completely different types of interaction.  A CLI session requires an extremely large amount of recall memory, knowing exactly which, “magic words,” (i.e. commands, parameters and syntax) will create the desired effect.  Knowing these words is also a willingness to devote part of one’s memory to remembering them as is.  There are manuals, but needing to always refer to a manual removes from the experience and creates a hurdle for many users.

GUIs on the other hand provide the user with clues and feedback to help aid their memory.  You do not need to always remember which switch or button does what because many times they are labeled according to the action.  Menus use language that also aids in narrowing down possibilities to find what you want.  Instead of spending time remembering the magic words for each and every application you will ever need to use, GUI applications provide a much more comprehensive paradigm, where learning the paradigm once will translate into being able to understand and manipulate many more applications.  A far more practical use of memory.

Lack of Attention to Detail

Simply deciding to use a GUI over a CLI does not immediately prepare your application (or Operating System) for the Big Time however.  Once ported into a GUI, many Linux applications still fail in their lack of attention to detail.  For example, take the new Network Manager being used extensively in Ubuntu and Fedora.  It provides a very nice interface to ifconfig and iptables.  When I connect my USB 3G modem from one profile I am able to subsequently select, “Disconnect,” and it will sever the connection.  If I try to connect to a different profile, that disconnect function does not work.  I cannot think of a logical reason why this would be the case.  Network Manager only handles one modem connection, and in fact is only handling one connection period.  Should the disconnect not sever that one existing connection?  This is just but one example where expected behavior is not met, which would cause an average user to cry bloody murder, call the application stupid and move back to another operating system completely.

The lack of attention to detail also comes into play when Linux GUI applications fail.  When a Windows application fails, it tends to seize the whole system and require a complete reboot.  Users are accustomed to this, and usually know not to repeat the action that caused the seize (or at least some do…).  When a Mac application fails, many times it will simply close the window, claim that the application has performed unexpectedly and been closed, or ask if you want to force quit.  An upgrade from the Windows alternative, as it usually does not require a complete reboot, simply a restart of the specific application.

Linux applications have demonstrated, at least in some cases, a level even better than Mac (which in my opinion is a more graceful crash than Windows).  Linux applications, at least the GNOME and cross-platform apps I have used, when encountering an application-wide issue, will freeze a bit (oftentimes locking up the entire windowing system) but then resume operation, provide a crash report in some external window (or pop up a terminal), and continue on their merry way.  This action, though from a performance standpoint is very specific and does not crash an entire system, or even the app itself, is too much for the average user.

Crash reports can be scary, including scary messages, scary memory addresses, and scary words, which are often some obscure API class name or function call and are completely unhelpful in resolving the problem.  Popping up windows also confuses users, who may not be aware that that single warning frame has grabbed focus (even though it popped up behind the full-screened application).  Users are not accustomed to applications telling them what is wrong, and telling them what is wrong in computer-speak only is not a way to educate users as to their mistakes.  Until developers create more graceful and informative crash/error reports and dialogs, maybe it is better to just crash the app completely in a Mac-style way.

Advertisements

2 Comments

Filed under Linux

2 responses to “Linux: Not Ready for the Big Time

  1. Excellent article. We have a Linux (Ubuntu 9.10) box stand as our FOG imaging server, web server and Samba server (because of a lack of hardware). Seems as though every day I come into the classroom and have to wrestle with it just to make it cooperate throughout the day. I am learning Linux as I go, which is fun, but considering sustainability, I’m not sure how my counterpart will handle keeping the thing going after my term here.
    So, reading between the lines of your article, I have to whole-heartedly agree that Linux is not ready for deployment in the developing world. However, there is one keen advantage and that is that people in the developing world are not as reliant on proprietary formats. +1 for Linux.

  2. Glad you agree. The issues you described about your servers are very common place amongst new sys admins, but I promise you, once it gets up and running, it just works (a point that comes up next week).

    As for the developing world, I actually tend to disagree a little bit. I think Linux is ready enough that with proper instruction, we can teach more abstract computer use scenarios without locking people into the Windows mindset. It is what I am slowly trying to do. It just takes, like a server, a lot of setup to create situations where your students do not fall into the common pitfalls of Linux based distributions.

    I wish I could say the same about proprietary formats in Kenya, but this country is deluged by mp3 CDs and the most hideously encoded VideoCDs and DVDs I have ever seen. Even VLC has trouble handling most of them. Trying to convince some local artists I know to switch off of their illegal Fruitloops and MP3 was like trying to milk a bull: it just wouldn’t work for so many reasons!

    My third article in the series will hopefully be the most development oriented, so stay tuned and thanks for reading!