This We Can Fix Now...

When I was approached by the folks at Texas Linux Fest to present the keynote, I was a bit surprised.  My focus from the "geeky" side of Linux shifted to the social aspects when I began The HeliOS Project.  I put away Eric and my Gedit scripts and began "working the streets" to get Linux onto more computers and those computers into the hands that needed them most.

Six years and over 1200 computers later, I believe that HeliOS has gained some significant insight into how people react to the Linux Desktop.

That insight is what we discussed during the keynote.  It wasn't my best public speaking engagement.  I'm having some issues with my throat and larynx so my presentation wasn't exactly smooth.  It didn't help that I changed some of the subject matter at the last moment so I may have rambled a bit.

Fact is, I was a bit disappointed with my showing, but we got our point across.

I think this would be a good time to talk about them.

The biggest fixes are the simple ones.

Given the development models within the Linuxsphere, it's a wonder that Linux exists in a workable fashion.  The fact that Linux is gaining slow but sure market share stands as a testament to the brilliance and tenacity of those that develop our software.

However, having sat with hundreds of people in the past six years as they explore and learn the OS, I've noted that there are dozens of problems and inconsistencies that are universally present.

What I note here is just a couple of things that should or need to be addressed.  There are hundreds of examples throughout the Linux Desktop.  I'm not picking on any particular project or system...I'm simply pointing out things that have been obvious in my experience.  The Linux Desktop is ripe for many of these easy improvements, and often they will be easy to fix...

If only the people in command of the GUI take them seriously.

One of the first things we do when we introduce a student to Linux is to show and demonstrate Open/LibreOffice.  This office suite has improved greatly over the years but often, there is one issue that creates a bottleneck or confusion.

The saving format.

Like it or not, the majority of people who utilize an office suite are accustomed to using the Microsoft offering.  More often or not, the user isn't concerned with the format of the document as they assume any other user of MS Office will be able to read the document.

You and I know that this isn't true.  The state of Texas, within its various agencies has fought this for years now.  Many agencies still use Office 2003, which creates minor havoc when another agency using Office 2007 or 2010 tries to open the 2003 document...

But those problems are seemingly taken in stride.

However, if this happens with a Linux user sending a MS Office user an ODT document, the entire problem is laid at the feet of the Linux user or system.

That's just the way it is...

Many times, the fact that the Open/LibreOffice user needs to make a choice is not made clear.  I can't count how many times we've been contacted with this problem.  This could be fixed simply with a line or two of text within the save dialog.

Let's take a look at it.

 Note the annotated red arrow and bold text to the right.  We've added this simply as an example of what can be done to cue the user.  Sure, some see the drop down menu to the right, but just as many or more do not.  Just adding some text here would drop the end user confusion down to a rounding error.

You are not speaking our language.

I think one of the most significant issues we've encountered is the way we communicate with our users within the GUI.  Problems are going to manifest themselves when we assume the end user understands our language.

I want you to think back to the first time you encountered a Linux desktop after using MS or Mac environments.

Let's take a simple term such as "mount point".

I can tell you for a fact that this simple term in itself has caused a lot of confusion and inertia.  We can see an example of this in one GUI right away.

 Note at the bottom of the GUI, the instructions state to "Select the mount point of the Bluray Disk."

Now, some would argue that this stands as a learning opportunity for the user, and maybe in this specific instance it does.  Maybe it tends to teach the user what a "mount point" is.

However, in my experience, the term mount point is used in an isolated environment where there is no frame of reference by which to match it.

I argue that it's just one more alien term that reinforces the myth that Linux is a system built by geeks for other geeks.  I further argue that it isn't our "job" to teach a new user our language.  Our "job" should be to provide intuitive software that doesn't get in the way.

Instead of the instructions offered above, why not change it to:

"Click below to choose your Bluray player."

The results are the same and they are presented in a language that the new user understands.  It wouldn't take much effort to implement this change, but unfortunately, in our development community, I don't think the mindset of language will be taken seriously at all.

That's too bad.  It discourages the new user from exploring further.  Sure those most adept at using a computer will trudge on...much like you and I did, but keep in mind, we are a minority.

Probably on par with Linux Desktop market share.  I'd be interested to see how the market share of Linux matches up with the number of Windows Users who make the switch permanently.

Now let's get personal.

I've talked about the way we name our applications and programs before.  I've been told that what we name a program isn't near as important as how the program works.

That's not true.

Three weeks ago, I accepted a reference from the Dell Children's Hospital to deliver a computer to a 12 year old girl.  Valyncia is an A and B student and home schooled.  She is home schooled for a good reason.

She has a rare, incurable and terminal blood disorder.  She won't live to see her 15th birthday.  On top of that she has Cerebral Palsy and she lives her waking hours in leg braces.

Had I not known that she suffered these afflictions, I would have marched into that house and found a great deal of discomfort in showing her how to use The Gimp.

You're going to say that this isn't a big deal.  You're going to say that this doesn't happen enough to merit any real consideration.

It does in my world...

And in Valyncia's.

Roughly 15 percent of the kids we serve have debilitating disabilities.

Until you are constantly faced with the same situation, don't tell me it doesn't make a difference.

Fact is, we are in the process of removing The Gimp from our custom distro.  In its place, we will insert the application Pinta.  I'd rather suffer the wrath of a few open source people for our choice of a Mono app than offer The Gimp to a little girl in prosthetics. 

Will this have any bearing or impact on getting app names changed?  No, probably not and that's not my intent.

What I would like to see happen is some simple forethought.  forethought in how we present our GUI, how we present our language, and ultimately, how we present ourselves.

You are probably unaware of the positive impact your software is having on people, but I am fully aware...I see it hundreds of times a year.  It's a damn shame you present your work with such an irreverent or unthoughtful manner.

Many would assume you just don't take what you do seriously.  Some of these application names seem to be the product of you and your friends, passing around the bong and seeing just how goofy of a name you can come up with.  Given the names of some of the apps in the Linux environment, I can see why some people would think that.

Just a few simple fixes...

All-Righty Then