That’s right.  The most powerful piece of software that could ever be made!  It’s a command line program.  You type in machine code instructions and it executes them!  This program can literally do anything a computer can be programmed to do.  Here’s a nifty screen shot:

This exciting instruction moves the value of 2 in 32-bit to the EAX register in preparation to calculate 2+2.

All you have to do to use it is learn hexadecimal, memorize the entire binary instruction set for your computer’s processor, and spend months typing in a few hundred million instructions before it does anything useful.

Ok, so I didn’t really make a program like this.  But the point is I could, and it would only take me a day or two.  And it would literally be, by definition, the most powerful and flexible program ever made, but it is obviously impractical.  And if you can write machine code in hexadecimal, you might as well save it as an .exe file and execute it directly.

The reason I’m talking about this is to illustrate a point about software that is actually not that far from being as absurd as the above program.  I have found that software that is regarded as “powerful” and “flexible”, but is archaically impractical due to its lack of a good user interface and requirement to learn custom command syntax and edit configuration files that have their own custom syntax, far outnumbers software that is both powerful and intuitively easy to use.

I think there is something seriously wrong when the thought “You know, I could write a better program to do this that would be much more practical to use in about half the time I have already spent trying to figure this program out” crosses my mind when I try most programs, especially open-source or freeware programs.  To me, saving time has always been one of the primary purposes of software, if not the primary purpose.  A program that takes more time to learn than it would take to write defeats the whole purpose of software, because it wastes time.  And haven’t we moved out of the stone age of command prompts and editing INI files?  I thought we transitioned into the realm of flexible, informative, intuitive graphical interfaces ages ago.

Is it too much to ask that a program come standard with an intuitive, time-saving, simple yet powerful graphical user interface?

But what’s wrong with a command prompt?  Don’t get me wrong, I love a good command prompt from time to time.  I use PowerShell just about every day for various things, because it’s a good alternative to coding an entire program from scratch that you’re only going to use once or twice.  But the problem with command lines and configuration files is that it is difficult if not impossible to make them intuitive.  Now since “intuitive” can be a rather vague term, let me define what I mean by it with regard to software: A user interface is intuitive if it can be easily learned by a user without instruction of any kind.  That instruction includes, but is not limited to, verbal instruction or written instruction from books, the internet, help files, or the program itself.  The instruction does not include information related to the software’s domain.  For instance, it is reasonable that a person using a VPN server or client would need to know something about VPNs (the software’s domain), but given that he or she knows about VPNs, how to use the software to set up a VPN server or connect to one should be self-evident, not requiring instruction or research.

But how could that be accomplished via command prompt?  The program could give initial instructions when you first start it, but no matter what it would be inherently limited in its ability to self-evidence its use.  Asking the user to know through intuition what commands to enter with what syntax is like asking someone to enter somebody else’s password in.  There’s a reason passwords are used for security, because it is inherently difficult to know through intuition what to type in.  What if our security mechanism was to put a button on the screen somewhere that said “Let me in” and the user had to just know to click that button?  That would not be secure, because it would be ridiculously easy to figure out.  That’s what a graphical user interface does.  It makes things, by comparison, ridiculously evident.  A program displays all its options in front of you.  You don’t have to know what command to enter or even what command displays a list of available commands.  The information can be organized in any way that makes sense for the given domain.

As the phrase goes: “A picture says a thousand words.”  And the great thing about that picture is that you get the sense of it after glancing at it for a second, while it would take minutes to read a thousand words.  (Actually, this post is about exactly one thousand words.  If only there was a picture to convey the importance of user interfaces so people wouldn’t have to read my thousand-word post…)  While I’m not promoting fancy, stylish graphics, a functional graphical interface can communicate so much more information in much less time due to its graphical nature.

“But I don’t like making user interfaces.  I make great back-end code and I like to focus on that.”  Congratulations, you’ve made what we developers call a “class library”.  Find somebody who makes good user interfaces to make a front-end to use your library.  Then you’ll have a complete program.  Some people think the user interface is like the paint and polish on a car—it just makes it look pretty.  But a program without a user interface is actually like a car without a steering wheel, pedals, or other controls of any kind!  It’s of no use to the driver without the interface components.

The user interface is an intrinsic part of a complete and useful program, and it both requires and deserves as much attention as the other pieces.