The Edge Case Usability Conundrum


A Usability quirk that is going to get me arrested one day

My blackberry has a button for “Place Emergency Call” on the front screen when the device is locked.  I can understand why it doesn’t require unlocking the device with my password to use it. Perhaps I’d need to call 911 using my elbows in the event that  severed all my fingers.

However, the downside is that I have more than once “pocket-dialed” 911 and recently while grabbing the phone, accidentally mashed some of the buttons, and it made a previously unfamiliar strange kind of beep. The display said “Emergency Callback mode” to which I freaked out and pulled the battery out so the cop couldn’t find his way over to tase me.

Insufficient Idiot Proofing

My first instinct was to write critical post about the poor UI design, but as proof of my subtle progress towards maturity as a blogger, and the fresh lessons learned from my overly hasty with criticism of DVD authoring software,  I took a step back and looked at the issue more objectively.

The authors of the BlackBerry firmware did put some effort into addressing the accidental 9-1-1 call.

  • Confirmation prompt must be dismissed before Emergency call is placed.
  • The default is “No” on the confirmation prompt.
  • It makes an obnoxious and distinct tone when you start an Emergency call.
  • The screen clearly displays “Emergency Callback Mode” when dialing so you don’t have to know the meaning of the auditory warning.

In the case of my button mashing, these precautions were effective. They alerted me the situation and guided me without confusion to a course of action to remedy the situation. However, it isn’t hard to come up with scenarios that could easily thwart these protections:

  • Pocket Dialing in a noisy environment
  • Child/Pet playing or chewing on the phone

Apparently I’m not the only clutz in the word either:

Suggested Design Improvements

Conflicting requirements is a key reason why it is so difficult to design effective Human-Device interaction. Here, the device needs to provide quick and easy access to the emergency call function while making it difficult to accidentally trigger it.

In this case it is clear to see that a compromise was necessary and the downside of not being able to get help in an emergency was clearly worse than an inadvertent emergency call, though still objectionable.  However, I do still see some room for improvement.

Idea 1:  Add a dedicated emergency call button to the physical device with a sliding door that clicks closed

Whenever the consequences of accidental activation of a feature are especially undesirable, I prefer a strong forcing function to a weak one like a confirmation dialog. Overloaded controls are inherently weak implementations of forcing functions because they don’t zap the user into a higher state of awareness that is necessary for doing big scary things.

That is exactly why the launch missile buttons have little acrylic covers on them. Unlike hitting a Y or N in response to a confirmation prompt, which the user is likely to blaze through out of habit because they have been pecking at they keyboard all day, the need to open the cover forces the user to engage in an activity that is markedly different to jar their brain into an attentive mode. Launch Button

This also works well, for prevention of accidental activation, which makes it relevant to the emergency call feature of the cell phone. In fact, I’d argue that it is a good fit whenever the following are true:

  • Very Undesirable Consequences
  • Infrequent need to activate functionality.

Idea 2: Get Rid of the Keyboard Shortcuts on the Confirmation screen

Shortcut keys have a very specific purpose, to speed up frequently used operations and thus make the operator more efficient. For the hypochondriac or drama queen, perhaps I would recommend a JitterBug or LifeAlert device instead. Adding multiple ways to confirm a function with big consequences is just asking for trouble.

Idea 3:  Make it vibrate when initiating an emergency call

This helps to solve the problem of pocket dialing in a noisy place.

Idea 4: Add a ten second countdown after activating emergency call mode

This would give the user time to react to the beeping and vibrating device and abort before any damage is done.

Why is DVD authoring software so horrible?

 I started to write this article as a usability critique after attempting to use NCH Software’s Express Burn software for DVD authoring. I fumbled about with it trying to memorialize my wife’s recent performance in “Wonderland” at the Bastrop opera house.

I kept insisting to myself that there is no way that any software company would let a UI out that required the user to watch the entire movie in real-time to insert the chapter labels. That’s right. No rewind, no fast forward. If you click too slow, well buster, you are starting over.

My wife finally got it to work and explained to me that “all I had to do” was burn a copy of the DVD as an image to the hard drive, then watch the movie using its unique timeline, dutifully write down each time-stamp when a chapter should start, save that into a file and then import the file into the software. Simple!

It made me want to get a management job at NCH software and fire everyone responsible for this software on my first day.

Update:  Turns out I was a bit hasty in derriding the design choices of this program on this particular element. It looks like it is merely a bug in the software and not the intended functionality (as evidenced in the help file) so I’ll cut them a little slack. However, my point about  this type of software being particularly crashy, freezy, and otherwise annoying stands.

Lowering the bar

Apparently this problem is so systemic that even the reviewers are making excuses for the software vendors.

DVD authoring software is computer system intensive and program shut downs are not uncommon. We looked for software that crashed less frequently and still created great DVD videos.


Abstractions? What Abstractions?

Another area where this class of software seems to underperform is protecting its abstractions. I have to know too freaking much about the DVD formats and options at a technical level to use this software, for example:

  •  The nuanced differences between DVD-R, DVD-RW, DVD+R, DVD+RW, BD-R, BD-RE, BD-R DL, and BD-RE DL.
  • Whether PAL or NTSC make more sense for my video.
  • Data CD, Movie CD, or Movie on a Data CD?

Granted, some of these answers I know. However, why should I *Have* to?

Couldn’t all of these options be presented in a wizard that asks questions like “Different countries have different DVD formats, so I need to ask: What country will this DVD be used in?” They could even provide an expert mode where the acronym savvy guys who were in the A/V club in high school can get hyper-specific to their heart’s content.

Working Theories

I am working on a theory of why this general class of software is universally horrid and crash prone and my best theories so far are:

* The same buggy OEM software is built into all the major DVD authoring software.
* This is consumer grade software (meaning low priced) to do professional grade tasks. When cost cutting is afoot, it isn’t hard to see who typically feels it first. “Why are we wasting valuable resource on QA when our last three releases of the software didn’t have any major bugs?”


Appeal To Those in the Know

I’ve got to have at least one reader with inside knowledge of software companies that make this type of application. Do you work with this type of software or know someone who does? Am I missing some major reason that no one can create a stable platform to burn a DVD?

Shortcuts for registering COM objects or NET assemblies

TipsHere are a few shortcuts to simplify working with assemblies (either COM or .NET) that I have found especially useful over my years as a developer.






Tip 1: Associate DLL and OCX file extensions with RegSvr32

If you are still working with COM style objects regularly, associating the DLL and/or OCX extensions with RegSvr32.exe (in the Windows\system32 directory) allows you to register or re-register them quickly by double-clicking the file in explorer.

Associate RegSvr32 with DLL Extension - Step 1

Step 1: Right-Click a DLL file and choose the "Open With..." command.



Step 2: Browse to WindowsWin32Regsvr32.exe


For those of you who work with managed assemblies more often, but still do a lot of interop work, an alternative is to associate DLL files to Regasm.exe or Regsvcs.exe


Tip 2: Use Windows “Send To..” folder for quick access to unregister a DLL

So now you can register components easily, what about un-registering them? That’s a snap too.

Just create a shortcut in the C:\Documents and Settings\{profilename}\SendTo directory with the target attribute set to %windir%\system32\REGSVR32.EXE /u and name the shortcut “Unregister DLL”

Shortcut to Unregister a DLL

Here it is in action


The He-Man Muggle Haters Club for Programmers (part 2)

This is the second article in a two-part series. If you haven’t already, please read Part One first.


 Protecting Our Interests

Although we may be loathe to admit it, we want and need programming to be sufficiently complex to keep the unwashed masses out of our clubhouse. The trouble is, we need a barrier to entry to support our value as programmers. Unlike lawyers and doctors who have expensive degrees and trade associations to protect their earning potential and aura of authority, it is not uncommon for a programmer to make a good living without the benefit of academic credentials or a formal endorsement of an organization. It is the magic of our craft that makes us feel special and separates us from the muggles and wanna-be’s like your boss’s nephew who is really good with computers.


Shhh! Muggles Are Everywhere

Fundamentally, I think this is a quite valid concern and admit that I sometimes succumb to these same territorial instincts. Especially when provoked by ignorant statements that undermine the investment programmers continually make in a Red Queen’s Race to stay on top of their game.





The Salman Rushdie of Programming?

Be Honest. How many of you have the urge to burn  this guy as a heretic?

There’s no reason why office workers, homemakers, professional engineers and pizza delivery persons shouldn’t be able to take advantage of their own hand crafted custom computer programs to work faster and smarter. It shouldn’t take a ‘professional programmer’ (whatever that is) to do the job. You know what needs to be done better than anyone else. You can do it yourself! (And I say this as someone who has spent many years writing programs for other people … ‘professionally’.)
VB Programming for the non-programmer!

Before everyone starts jumping on the VB dogpile in the comments, I should clarify that the referenced article is actually about VBA, and not VB proper. I’m sure, however, that many of my readers will question whether that distinction is meaningful inspiring yet another battle in the platform wars. This brings me back to my point.

 Why do many programmers despise tools like Access and VB, and even those that use VB look down on those who do too much drag-drop programming. The concept of a non-technical person using tools like this to build a useful software drives some of us nucking futs. Why? Shouldn’t we welcome usability to simplify the task of software construction?

Perhaps because it opens that clubhouse door a bit too wide for comfort.


"Sir, you can't let him in here. He'll see everything. He'll see the big board!"- General "Buck" Turgenson

Sir, you can’t let him in here. He’ll see everything. He’ll see the big board!

– General “Buck” Turgenson





Gold Plating The Secret Handshake

It is my contention that this effect has played a role in driving recent trends in programming technology. After years of considerable progress towards simplifying the physical act of programming (ASP.NET), recent developments in technology built for programmers has decidedly shifted towards better implementation of computer science-y stuff like functional programming, MVC and lambda expressions into the more pedestrian programming languages.

Also, the attention of developers is increasingly turning to the haute couture*technology of the day. Ruby? That is so two years ago, don’t you know we are using Scala now? (Haskell)

* The use of haute couture in this blog is not sanctioned by the French Government. For my French or Bostononian readers, please substitute the phrase “Wicked Awesome.”

This seems to drive programmers, who like woodworkers often build their own tools/jigs, to devote our time to constantly moving goalposts rather than reducing the required expertise to build functional software.


The Consequence and My Conclusions

I’m not saying that new programming languages don’t add value, just that this type of progress is more about fine tuning than making programmers generally more productive. My inner pragmatist makes me question the need to sharpen our tools to such a degree when the majority of the programming work seems to be centered on developing CRUD apps.  Additionally, given the very real threat of “low-cost” outsourcing options for programmers, it also makes me wonder if perhaps our priorities are not aligned with our best interests.


Don’t Go Away Angry

I fully realize that I have engaged in some very controversial conjecture in this series, and want to emphasize that the intent of this article is is not to drive a particular agenda. Rather, I’m merely trying to encourage introspection into some aspects of our trade that may have otherwise gone under-examined. I am not certain that I even agree with all of the opinions I have offered here, but found musing on them interesting and hope you will too.

The He-Man Muggle Haters Club for Programmers (part 1)

Little Rascals - He-Man Woman Haters Club

In his satirical and quite humorous article, “How to Write Unmaintainable Code,” Roedy Green raises an interesting question that really got me thinking about some things I had previously taken for granted with the the physical act of creating software.




“Why is programming still done primarily in a text editor?” 

 Before get rolling with my analysis of this question, please take a moment to read his conjecture on the topic. I’ll meet up with you again at the the other end.

Imagine having an accountant as a client who insisted on maintaining his general ledgers using a word processor. You would do you best to persuade him that his data should be structured. He needs validation with cross field checks. You would persuade him he could do so much more with that data when stored in a database, including controlled simultaneous update.

[Now] imagine taking on a software developer as a client. He insists on maintaining all his data with a text editor. He is not yet even exploiting the word processor’s colour, type size or fonts.

Think of what might happen if we started storing source code as structured data. We could view the same source code in many alternate ways, e.g.  as a decision table, a flow chart, a loop structure skeleton,  Java with various levels of detail or comments removed, as Java with highlights on the variables and method invocations of current interest, or as Java with generated comments about argument names and/or types.  You could see code with additional or fewer parentheses, (depending on how comfortable you feel with the precedence rules).

You could use the full colour abilities of the modern screen to give subliminal clues, e.g. by automatically assigning a portion of the spectrum to each package/class using a pastel shades as the backgrounds to any references to methods or variables of that class. You could bold face the definition of any identifier to make it stand out.

You could ask what methods/constructors will produce an object of type X? What methods will accept an object of type X as a parameter? What variables are accessible in this point in the code? By clicking on a method invocation or variable reference, you could see its definition, helping sort out which version of a given method will actually be invoked.You could do quite a bit of code writing by point and click.

He has some interesting points, doesn’t he? The comparison to an accountant using a word processor to create journal entries really struck me. I began to think about the Sisyphean labors of applying language/compiler specific markup in our code to satisfy our brutal task-master. It is easy to start thinking about programming IDE’s and compilers as a special class of software that is exempt from the normal  usability considerations because it is geared towards computer experts, but that just isn’t true.

Put Themselves in our Shoes

Consider the reaction of your users if you required them to enter data in your application using a big text-box using well-formed XML to provide context and meaning to each individual item. Sure they’d complain because they can’t remember the relevant attributes and always forget to close their tags, but that would be easily solved by updating the text box to have Intellisense!

Actually, no it wouldn’t. Clearly the intellisense solution addresses only the symptom, not the problem.

We Deserve Better

So why is it good enough for us?  Don’t programmers deserve good usability in our tools too?  Is it really necessary to spend valuable time matching up brackets/parens and chasing down missing line terminators?  Worse yet, if you frequently use different languages, the mental context switches force you into all sorts of mental gymnastics to keep it straight,  and incite a scolding from your compiler.

Why do we have to keep syntax ideosynchracies in our heads?

var myInteger //This is a Javascript comment
Dim myInteger as Int 'This is a VB comment
int myInteger  //This is a Java or C++ comment
myInteger=5 # This is a Ruby Comment
DECLARE @myInteger int --This is a t-SQL comment

Creating good visualizations for scoping, variable declaration and module interfaces is not an unsolvable problem. Also, the benefits of one more level of abstraction extend beyond increased productivity. For example, consider the portability that the increased normalization of code could produce.

Or Maybe Not…

At this point I am sure that many of you are still skeptical, and I am about to slam the door on the open mind of the remainder of you. What I am describing here is effectively form-based (a.k.a “drag and drop”) programming.

That Whooshing is the sound of this article entering free-fall from angry programmers down-voting it on Reddit.

This is exactly why we are still programming in glorified text-editors, because that is exactly what we want. And unlike programmers who write software for marketing people, the developers who create programming languages and IDE’s understand very well that other programmers emphatically prefer some additional complexity to even the remote possibility of democratizing software development.

Homework Assignment

As a mental exercise and preview of the finale of this article, consider this diagram showing the general sense of  superiority among programmers in the style of the famous Geek Hierarchy poster and ask yourself which direction the arrow would go in terms of general usability of the tools for each type of programmer.

Hierarchy of the World According To Programmers

Hierarchy of the World According To Programmers


To be Continued…

In part two of this series I discuss the psychological and frankly pragmatic reasons that our techno-brethren are so committed to keeping the field of programming as exclusive and specialized as possible.