User Friendly: a Meditation

Carl Milsted, Jr on Sep 29 09:04:50

View QTML

Many people upon seeing this web site comment that the style is "retro", "old school", or "dated."

Guilty as charged. Your honors, before you sentence me, I'd like to present a character witness: Bilbo Baggins.

The old that is strong shall not wither.
Deep roots are not reached by the frost.

From the ashes a fire shall be woken.
A light from the shadows shall spring...

You get the drift. I grew up reading C.S. Lewis, and later J.R.R. Tolkien. I don't believe in monotonic Progress.

True progress happens. But so does error, dead end experiments, pointless fashion, and outright regress. Some of the design elements are meant to evoke memories of a more civilized time, when RAM and CPU cycles were precious, and programmers paid attention to such. The bright green on black menu bar above is meant to evoke memories of old school dashboards, glowing oscilloscopes, VT52 compatible computer terminals, and the bridge of the original Starship Enterprise.

The Future was supposed to be shiny with laser like pure colors, not assorted shades of gray paper with drab inks.

With this intentionally retro look and feel, I am also revolting against a trashy design paradigm which infects our age. To this we turn next.

The Three Pillars of User Friendliness

User friendliness has three pillars:

1. Novice Friendliness
2. Expert Friendliness
3. Interface Stability

By "Expert" I don't mean world class expert or even higher than average IQ. I just mean someone who has read the directions and used the product for a while.

A product can be super Novice friendly, yet horrible for the long term user. For example, consider this transportation device:

This device is super stylish, more stylish than any modern car under $50,000, and it is so easy to learn that a toddler can master it in less than hour. But in the long term, it's a terrible mode of transportation. Walking is faster.

There are much more efficient forms of transportation which do involve a serious learning curve at first, but are easier to use in the long run, such as this:

A bicycle (or automobile) is not novice friendly, but it is vastly more expert friendly than the Retro Rocket toddler toy.

The ideal user-friendly product is both novice friendly and expert friendly.

This ideal has been largely forgotten. Today, the experts equate user friendly with novice friendly. Gone are the manuals and left brain logic of yesteryear. Instead, features are to be found through Discovery. The radioactive descendants of Clippy, the Annoying Paperclip are behind the scenes ready to tell us what to do next.

The result is software which is bloated, buggy, slow, and often extremely hard to use in the long run. But at least modern design is good for job creation. It takes an armies of nerds and gigabyte of weekly updates to keep modern software running.

I'll give a host of examples is just a bit. But first, let's look at the third leg of true user friendliness: interface stability.

The Importance of Stability

Once upon a time, computers were very expensive, so expensive that computers and computer software came with manuals. And not just mere brochure kind of manuals, but nicely bound thick books.

When I bought a 60 MHz Pentium computer from Gateway 2000 back in the day, it came with Microsoft Word, and this manual for Microsoft Word

That manual is over 750 pages long! And I read a good chunk of it, as Word was a powerful product and with mastery of Word you could do cool things, and I did.

This was not unusual. Computer software -- even games -- usually came with one or more bound manuals. MS-DOS came with something like a foot of shelf space of manuals back in the day. Pre Visual Microsoft C/C++ compilers came with at least 20 shelf space inches of manuals in the early 90s. I learned enough of the Win16 API to be dangerous from said manuals.

The amount of manual reading to master Conntects is microscopic compared to what was common 30 years ago. I have friends who appreciated the Show Codes feature of Word Perfect back in the day who are now unwilling to learn the basics of QTML today.

What happened?

Change happened.

Stupid change.

Change for Change's sake.

I invested the time and brain sweat to master Microsoft Word. I read a great deal of the manual pictured above. I learned how to create styles, save them into .dot files and apply .dot files to new documents.

And then the nincompoops who now run Microsoft decided to throw all my hard won mastery into a wood chipper and completely redid Microsoft Word. It may be possible to use old school templates with today's Microsoft Word, but Microsoft has masterfully hidden how to do so underneath eight feet of gorilla poop. Today, you are expected to go online to choose from 8027 style sheets to make the document you desire.

I have switched from Microsoft Word to Libre Office, and it's not because of the monetary price of Microsoft Word. Libre Office is more stable than Word. Word has changed so much that I'd rather type a formal letter on a manual typewriter than try to figure out how to write a letter using the 8.2 billion options on Microsoft's web site.

I exaggerate slightly on the literal numbers. The emotions are real.

And Microsoft has ruined more than Word. Microsoft juggled around the toolbar so that PowerPoint is a foreign program to long time users. Microsoft Windows 8 attempted to downgrade desktop machines to gigantic cell phones. Microsoft restored some of the usability of Windows 95 to Windows X, but not enough. I still use Windows 7, and when that's not longer an option, I'm going linux only unless ReactOS becomes truly functional.

Interface stability is a crucial leg of the User Friendly Tripod.

And that's why I eat the cat food and strive to get the Conntects user interface into an Excellent for Experts level early in the development cycle. Once I get there I will tweak it to make it easier to learn for novices — and yes, there are lot's of places where pop-up help buttons will be handy, and other changes which improve both novice and expert friendliness.

But I won't bloat or break the fundamental layout for the benefit future novices. Instead, I'll commission others to make better teaching materials for future novices while I focus on performance, new member acquisition, and equipping my underground lair with sharks with lasers.

With stability and enough early adopters on board, the second wave of users will realize that some overhead is worth the effort in order to have a better product.

Without stability, however, Novice Friendly is indeed equal to User Friendly.

When innovation in electronic products hit a breakthrough pace and prices plummeted, it made sense to skip the manual and just use the intuitive features. Why master a product that you are going to replace in a few years? Besides, modern appliance manuals are mostly safety boilerplate plus garbled instructions converted into English using Google Translate.

I am not trying to build a fashion-conscious bleeding-edge do-everything product. I am building a sleek, fast, and dependable product. A utility. A near passive cash generating machine that funds yachts, mansions, underground lairs, political campaigns and/or giant laboratories for the owners.

The High Cost of Low Overhead

Mastering multiplication is hard. You have mindless memorization of multiplication tables and you have to understand the cryptic process of carrying and whatnot.

Technically speaking, multiplication is unnecessary. All you need is addition. That is, you can replace

$493\times 7$

with

$493+493+493+493+493+493+493$

Actually, you don't even need addition! All you really need is counting. Count out seven piles of 493 rocks each. Then count the total number of rocks. Baby stuff!

Or maybe, just maybe, learning a bit more math up front saves work in the long run...

My Camera

I have a camera, a Sony camera, a magical camera, a camera which focuses all by itself, a camera which determines the exposure and whether a flash is needed. It's a very clever camera.

And I want to replace it as soon as Conntects becomes profitable.

I take out the camera. I push the button. And something happens...eventually. The pause can be long. Or it can be short. Maybe my camera is checking on the weather report, or maybe my camera is writing an essay on the mating habits of Albanian armadillos. I am uncertain. But what I am sure of is that my camera is an utterly terrible tool for action shots or capturing fleeting expressions.

And auto focus can be a curse. I awaken one morning to find vultures rolling a basketball in my back yard. I run and grab my camera. I point it out the window. And after the usual hesitation I get an in focus shot...of my window screen. After some fight I was able to get this shot:

Fun, but the best action was already over before I won my fight with my magical camera.

I want a camera which obeys me. I want a camera which is a bit more expert friendly.

Computer Madness

In the beginning was the command line. It was not novice friendly. It wasn't even expert friendly unless you became a true expert.

Then came the GUI—the Graphical User Interface. For many tasks, it was a huge improvement.

But not for all tasks! GUIs and loops do not mix. If you need to do a task a dozen times, then doing the same sequence of points and grunts is the way to go. If you need to do the same sequence hundreds of times, it is time to write a program.

Alas, learning to program is hard, and there are few shortcuts. A good programming language is unnatural, and thus hard to understand at first. And so many attempts have been made to create natural languages which are easy to learn.

First there was COBOL. I have heard stories, and they aren't pleasant.

Then there was SQL, the natural language database language which sends me to the manual every time I have to do anything nontrivial.

A good programming language is precise, unnatural.

Computer Generated Code

Then there were attempts to minimize coding by having a framework and an Integrated Development Environment to generate the boilerplate code.

I did my first Microsoft Windows programming using the WIN16 API directly. It was weird, and times tedious, but I learned while I coded, and eventually wrote the first version of the Enhanced Precision Political Quiz in 2D using the WIN16 API.

Then I "learned" Microsoft Foundation Classes. The tutorial was delightful. In a few hours I went from nothing to having a working simple drawing application. It was like painting by numbers.

Literally.

Painting by numbers.

I used MFC in my day job for years without ever feeling like I understood what I was doing. Stay within Microsoft's framework, and MFC worked. But go outside the framework just a bit, and life became difficult indeed. Accidently modify the special IDE generated code and the IDE is no longer your friendly servant. Better have a backup handy.

Never again.

The bad idea won't go away. First there was Ruby on Rails. During my previous attempt at creating a social network, I wasted precious months learning Ruby on Rails. It was MFC all over again. It's no wonder that Rails programmers get paid a lot. And it's no wonder that the folks at 37 Signals dropped all their products except Basecamp. Just like MFC and its Scribble tutorial, you can go from zero to working web app in no time using Ruby on Rails.

But stay within the lines or you are doomed.

And now people are using Artificial Intelligence to generate code. This excites me about as much as the MacBook Wheel's Predictive Sentence Technology.

Scripting Language Silliness

Scripting languages are great—for their original intended purpose. I have fond memories from my defense contracting days learning Tcl/Tk and going from nothing to a working demo in a few months. It's amazing what you can do in just a a small amount of code using a good scripting language. And Tcl has the wild flexibility of Lisp while still being readable.

If you want to make simple Graphical User Interface programs, I highly recommend learning Tcl/Tk. Get the first edition of John Ousterhout's Tcl and the Tk Toolkit. It is one of the best written computer books on my bookshelf.

But scripting languages do not scale. Compiling is indeed a bother. But running a program until it crashes because of a stupid typo that a compiler would catch is a much bigger bother. (Now that I have become old and too farsighted to see my keyboard clearly, I make a fair amount of typos. I need a compiler to do big code!)

Ten years ago, after I gave up learning Ruby on Rails, I tried writing a social network prototype in PHP. This effort did not last long. I like PHP. For simple web sites, PHP is a fantastic language. It's not the most beautiful language, but it's very well documented and has tons of useful libraries for doing web related things.

But it's a scripting language. Mistype a variable name and you have magically created a new variable. I found myself in debug mode way too early in the development process. I looked for a compiled alternative.

I seriously considered writing a server in D. ( The D Programming Language by Andrei Alexandrescu is another extremely well written computer book.) But the lack of libraries in D held me back. Then I somehow learned about Google Go language and fell in love. Go retains much of the elegance of C while also adding memory management, modules, super strong type checking, objects, delegates, and the delightful defer statement.

I got a working, but clunky prototype working, but then went back to my old day job.

Ten years later I have thawed out my Go knowledge for web programming and have created the site you now see in less than a year and a half.

Making a single web page using Go is WAY harder than a single page in PHP. The overhead is significant. Go is not the most novice friendly way to build a simple web site.

But Go is incredibly expert friendly. The language is simple, elegant, and stable. Even the Go standard library is simple and stable. When the documentation is inadequate, it's pretty easy to figure out what's going on by reading the library source code. (This is definitely not the case with the C++ Standard Template Library!)

And between strong type checking and the defer statement I don't need an IDE or even a debugger. All my code is written in command line windows using the vim editor, and I trace bugs by adding log statements. (I do, however, use a debugger extensively for the unavoidable JavaScript code. JavaScript is a horrible language, but it's the only dynamic language that runs inside browsers since Java applets were discontinued. Why anyone in their right mind would use node.js on the server side is beyond me.)

The Glueware Solution

One way to avoid real programming is to reuse other people's code. Have gigantic libraries for just about everything. The idea has some strong theoretical backing, since code that gets reused is code that gets debugged.

But there are also downsides. When you use libraries which depend on each other, then you need to use the correct version of each library. Welcome to DLL HELL.

I rarely use Windows 10, but when I do, I have to wait for the computer to process gigabytes of updates. That's the colossal .NET libraries attempting to maintain self-consistency.

For those who use Python to glue libraries together, there is the delightfully monstrous Anaconda application to keep things straight.

And if you want deploy your glued together system, there's Docker. What fun!

While a good standard library is a wonderful thing, and so is a well vetted special library, at some point it is cheaper to write your own code than to import yet more libraries. Beyond the DLL Hell problem, learning how to use a library has a cost. And if that library is a moving target, it is an ongoing cost.

I kept things simple with Conntects. Go generates statically linked executables. No DLLs! I can plop the executable on another linux box and it just works.

Back to Conntects

I want Conntects to be truly user friendly. To date this has meant focusing on being expert friendly, since expert friendly is far easier than novice friendly, and I want to be largely feature complete early, so we can iron out the flow of the user interface before deploying the paid version. Interface stability is an important leg of user friendliness.

But because I have neglected novice friendliness, there is lots of room for improvement in this regard that does not sacrifice expert friendliness and future stability.

I've spent the past couple weeks beautifying the site to entice new users. I now await questions and complaints from new users and modern interface experts in order to make the learning curve more pleasant.

Complain away!

Tags: overhead user friendly