User Interfaces for Infrequent Tasks

Paraphrasing an article by Barbara Nelson of Pragmatic Marketing, good software may very well be complex, but that complexity needs to be hidden from the user as much as possible. Nelson cites Intuit’s Quicken as a prime example. "They learned what regular people needed by spending time in people's homes, watching how they managed their home finances. Quicken was the first finance package to use the checkbook metaphor, something regular people already understood. Quicken was hugely successful, and even with dozens of competitors, managed to gain 75% market-share because it was easier to use. It was the first product to take a customer-oriented view instead of a data-centric view."

One way to hide complexity is through a guided UI (a.k.a. a wizard or an interview). A common misconception is that a wizard makes a good UI for novices, when in fact they are more properly employed to address infrequent tasks, and should have nothing to do with whether or not the user is a novice. Novices aren't novices for very long (when performing a frequent task). Writing a guided UI for a frequent task is bad, because it eventually bogs the user down. On the other hand, a guided UI is perfect for an infrequent task, especially a complicated, critical, or finicky one, no matter whether the user is generally regarded as a novice, intermediate, or advanced. You might say that when it comes to infrequent tasks, every user is always a novice.

Outsourcing Battle is a Red Herring

On Firday, Slashdot cited an article entitled "How India is Saving Capitalism" that sparked yet another argument pitting capitalism against patriotism. This kind of battle over outsourcing is a red herring. Executives who outsource to save money are failing to see the big picture, and anyone who chooses to fight on that battleground is wasting his time and contributes nothing towards "winning the war."

These executives keep asking the wrong question, "How can I continue to develop the same old crappy software, but do it cheaper?" They ought to be asking, "How can I develop better software?" "How can I develop it faster?" "How can I make it last longer and be more useful?" By improving the quality of their software it'll be more desirable. It'll draw more customers and can demand higher prices. Answering these questions can lead to a 100-fold improvement on the ROI versus any kind of cost-saving measure.

As an added bonus, better software is, well, better. If you want to talk about morality, let's talk about how much better our society will be when the software we use provides more intuitive user interfaces, adapts more easily to our needs, offers increased security, and performs faster.

The sad part is that the answers to these questions are right in front of our faces. All we have to do is open our eyes. The 'Net is a free, all-you-can eat buffet of best practices, high performance/high security open source frameworks, feature rich open source tools, design pattern catalogs, refactoring catalogs, ... you name it.

If you really want to keep the programming jobs at home, then quit sniveling and do something to make yourself and your fellow programmers more valuable. Pick one thing and explore it. Read up on a management methodology like XP, RUP, or Scrum. Or, become familiar with a tool like Eclipse. Or, try out the unit-testing framework that goes with your language of choice. Or, otherwise avail yourself of the wisdom of luminaries such as the Three Amigos (UML), the Gang of Four (Design Patterns), Martin Fowler (Refactoring), and Steven McConnell (Code Complete). Apply what you learn and pass it on. It's as simple as that. (Not easy, but simple.)

Levels of Indirection

Smokebreak TV is responsible for the best laugh I've had in a long time. It goes like this:

A group of my coworkers in the Tucson office started a cable access show called Smokebreak TV and released their first episode last week. My friend, Vlad, a coworker with me in the local office, reviewed the episode in his blog, offering up an E-for-effort appreciation of the show and noting the potential bulldada factor. Being unfamiliar with the term, bulldada, I tried looking it up on Merriam-Webster as well as doing a "define:"-style Google search. Both turned up empty. I then tried a regular Google search on "buldada means" and got a hit on a book review that defined the term. The book in question was "Galaxy 666" by Pel Torro, which Ken DeVries called the worst science fiction novel ever written. He said that it "does for literature what Plan 9 From Outer Space did for the cinema." Reading the quoted passages is what sent me reeling. So, thanks guys. I owe you one.

iPod Race movie

I just discovered the iPod Race (quicktime) movie from last December. If you are an iPod user and you haven't seen it yet, you gotta check it out.

Endo-Testing with Mock Objects

I finally paid attention to the buzz surrounding endo-testing with mock objects and read the introductory paper. I’m quite impressed with the concept and I can easily see how it’ll provide me with an easier way to unit test within complex states. I’m already convinced that test-driven development is the way to go, so I’m especially impressed with the idea that mock objects work especially well when employed as a TDD tactic.

By the way, for anyone still using Delphi, there’s a Delphi Magazine article on the subject.

You are Invited - Intro to UML & Design Patterns

I will be speaking on Tuesday, March 23 at 7pm in the city of Orange on the following topics: An introduction to UML followed by a very brief introduction to design patterns (which will, of course, be illustrated using UML diagrams). This will be at a meeting of the Orange County Delphi Users Group, although as you can see, the topics have nothing to do with Delphi, per se. OCDUG meetings are open to the public.

The Unified Modeling Language (UML) comes in multiple forms and serves many purposes. This presentation will describe UML diagramming in particular and discuss the uses for it. All 9 diagram types will be presented with an emphasis on the Class diagram. (That's the one that most people think of when you just say "UML diagram.")

Software design patterns first became popular with a book called "Design Patterns: Elements of Reusable Object-Oriented Software" by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (a.k.a. "The Gang of Four"). All software is designed according to patterns, whether or not the programmers realize it. This book sheds light on how patterns are used in software design and offers up a catalog of certain patterns that tend to recur in good code. Many other pattern catalogs have emerged subsequently, but the original GoF catalog is still considered the proper starting point. This presentation will cover: the general concept of patterns, the difference between patterns and idioms, and how patterns are described and catalogued. One pattern (Singleton) will be discussed in detail.

The OCDUG meetings are held at Red Brick Software, 1301 East Lincoln Avenue, Orange, CA 92865. [Directions]

Proposed Spammer Punishment

When we finally figure out how to catch and convict spammers (and virus writers), I propose that they each be punished as follows:

1. Lop off his or her head
   
2. Put the head on stake
   
3. Aim a web-cam at it as a warning to all other would-be spammers
   

That's not too lenient, is it?

Why Anti-Spam Technology Doesn't Work

Over half of all e-mail traffic is SPAM these days, and it's getting worse, costing businesses $20 billion a year in lost productivity. Most of it originates from a handful of organized spamming groups that the authorities are unable to do anything about because of ineffective laws. In the mean time, a number of technological solutions are being used/proposed, but, as this terrific article (and part 2 of 2) shows, none of them (will) work. What a mess! I sure hope somebody finds a way to deal with this soon.