“You can have two for the same price as one, but you may not like either of them” …

Climbing … Tied to the other end of my rope, and 120 feet above me, Jim is standing on a ledge rigging a belay with the rope to catch me if I fall when I climb.  He’s fiddling.  Fiddling makes me nervous.   

He clips a piece of gear into the rope and stares at it; it sparkles as he flips it over, frowns then starts re-rigging again.    He just bought a new belay device (a widget), and with his busy schedule has not spent time practicing with his new toy.  I know that Jim already owns 4 older equivalent devices and he does know how to use them.  Some climbers just like buying new gear; it’s good for the economy; not so good for rising healthcare costs.  

Finally, he shrugs.  He either figured it out or gave up.  

He yells, “Climb when ready, Dave”.

 

UI Design and Climbing are similar in that there are many of cool widgets and techniques to play with.  It’s temping to add more widgets even if what we already have does the job.   Sometimes, having more really is better, but it always carries practical risks for performance because performance teams are rarely staffed to optimize the extra code.  

For example, a team writing a program to manage a customer profiles might have two basic UI options for an Update Customer Profile function:

1)       Where the user selects a Profile from a list, then selects “Edit”.
2)      Where the user opens a Profile Editor and uses a drop-down list to choose the Profile to edit.

Customers are polled: “do you like option 1 or 2?”  Results: 50% prefer option 1, 50% option 2.  In the absence of an electoral college, the easy UI design solution is to do both.  

While the functions are conceptually identical, the implementations are different.  It’s the separate sets of code that leads to performance issues:  the performance analysts are too overtaxed (who isn’t) to fully test and optimize both sets of code, so they are forced into one of two bad choices:

1)       To fully optimize one of the two options and probably make half of the customers angry.
2)      To partially optimize both and possibly make all of the customers angry. 

There is a third choice; the UI Designer has the ability to remove this extra risk of poor performance.  It goes like this: “design the UI with option 1 or with option 2 but refuse to design both.”   What makes this so often the best choice independent of their voting habits for GUI options, most user’s really want the UI be solid and FAST.

 

For best performance a UI will be nearly orthogonal – every function is done with only one set of code.  The Performance team can focus on that one bit of optimization giving it the best possible performance – the users get one FAST way to do anything.