Obviously you can't be friends with a piece of software. Or if you can, you need to be given a long rest somewhere in the backblocks of some place where they can't tell a RAM chip from a potato chip. Fans of SimonT please keep your keyboards shut.
So for a piece of software to be user friendly, it really means that it will be polite, obliging, helpful, and inclined to help or support. In other words, it needs to do what the user wants done, with as little fuss as possible.
That's fine in theory. But I'd like to make the proposition that there are two vastly different (in fact mutually exclusive) approaches that software builders can take when planning a package to be user friendly.
Imagine, if you will, a computing expert who will do at least 150 different tasks on a typical day. Each task requires the running of a separate program. What would be the best user interface for such a person, from which they could call on any of those programs quickly and simply?
And imagine also, a blonde secretary who will typically use an email client and a word processor and not much else, but occasionally need to work with a spreadsheet. What would be the best user interface in that case?
In the first instance, the best user interface would actually be the old style command line - invented by IBM in the 1960s. 150 commands could each be given a two letter code, and the engineer could simply type in the code, hit Enter, and be ready to go. At a good engineer's typing speed of 100 words a minute, the computer will know what the user wants it to do in about half a second.
In the second case, a point and click Graphical User Interface is sufficient. To choose between two most-used programs and even up to ten sometimes-used, the user only needs to pick from a short list, which can be done simply and easily.
If the engineer's 150 options had to be crammed onto a GUI, the result would be bedlam. If the secretary's two plus ten options were put into a command line, it would take a written reference sheet to remember how to do any unusual task.
So, the level of user friendliness of a piece of software depends on the usage style of the user.
Let's take this a bit further. How did the engineer start using those 150 options? It probably didn't start that way, but as responsibility and workload increased they gradually added more tasks to the list. But what if a brand new engineer had to learn all those two letter codes? It would be written reference sheet time.
In actual fact, it would be a lot easier to have a GUI, with several levels of menus and a help file. But didn't I describe that as "bedlam" just a few paragraphs ago?
Yes of course. The old engineer, knowing how to fire up any of those 150 options in half a second, doesn't want to sift through multiple layers of menus. The new engineer's needs are different from the old one's. So, the usage style of the user can change over time, making a piece of software that had previously been highly user friendly become a disadvantage.
Let's look at a few practical examples - input devices that exhibit the different approaches to user friendliness.
1. The touch screen
Highly expensive in its early days but coming down in price (and up in functionality) by the day, the touch screen is the ultimate in Secretary-type user friendliness. There's the option right in front of you, go ahead and touch it. You can also drag, flick and (depending on lawsuits) pinch. Just about anyone can pick up a touch screen interface and learn to use it in a few minutes. But after that few minutes, there's practically no advancement. You can't be all that much better or worse than any other touch screen user no matter how many years you've been using them.
2. The mouse
The mouse is really quite similar to the touch screen, with the difference that the user's hand is kept away from the screen, allowing them to see what they're doing. Some users find it difficult to translate the desired pointer movement into a hand movement, and highly accurate mouse movements are a skill that only comes with time. However, the mouse and the GUI (they really go together) are still an expression of Secretary-type user friendliness.
3. The keyboard
The keyboard is unlike either of the other input devices, in that its layout and position are fixed. Also, if designed correctly it can be used as a "one way" communication device - the user can receive all necessary feedback by feel, and continue to work at full speed and productivity even when blindfolded. Thus the communication only happens one way - from the user to the computer. With the mouse and touch screen, communication is two-way - the user has to see the result of each millisecond's input before deciding what to do next. The keyboard, and the user interface that goes with it, the command line, are expressions of Engineer-type user friendliness.
So, to all software developers out there - one size doesn't fit all. Think about your target market and the way they will use your program. Design accordingly. If in doubt, provide both - it's not rocket science, the GUI can be a wrapper for the command line. DB2 can do it, why can't you?