Nicholas writes clean, elegant code. Paul contributes beautifully to interface interaction. Scott is a master of programming languages, and Manish and Manasi possess an enviable stick-to-itiveness attitude. Then there’s me.
Fumbling as I am in learning Rails and attempting to pick up Scott’s reigns, I realize that I have been very fortunate in my reliance on great programmers. So, if I haven’t said it to the guys and gals around me worthy of the title “programmer”, let me say it now, “My hat’s off to you!”
For two days and many hours, I slaved over a Ubercart issue that insisted I must have “javascript enabled” in order to display missing credit card fields. Posts on the Ubercart forum suggested I look for javascript errors that might conflict with the onclick display of the credit card pane. I sought but did not find.
I finally began to remove page elements from our custom template to ferret out the problem. Still the error persisted. Finally, I removed the entire custom template, and lo and behold, the heretofore unseen credit card fields appeared.
The problem? In our template, we needed to make one simple call:
< ?php $scripts ?>
This simple variable allowed javascript calls to be made and rendered on the page, but recognizing that fact took far too many hours. It’s these little issues that can make Drupal such a bear!
In software, usability refers to the design of the interface that reflects an intuitive relationship between what a user wants to do, and how to do it.
We are in the midst of the exciting redesign of one of our core services, ThunderTix, our online box office management system. In addition to creating an array of new functions for the software, we spent a considerable amount of time designing a streamlined web interface with responsive AJAX-y controls.
Yesterday, we were at a crossroads as to how to implement our seat pricing assignments. The evening before, I spent several hours fine tuning the layout of various pages, and I was struck by just how far our system had grown. Yet with that growth in great new features, we had also introduced more complexity. As a company whose roots lay in educating a largely non-technical user base and boiling down lots of functionality into simple excercies, I was a little worried that the new features might prove a little challenging to our clients.
During our discussion about pricing, we were weighing issues that might affect the performance of the system against usability. In a nutshell, in order to improve database performance, we had to introduce a new concept and series of steps to enable our clients to reach their primary goal–selling tickets.
Customer service time and training is a huge part of our business. And every minute we instruct users how to get up and running, we lose profitability. And for every second a user pokes about the interface trying to accomplish their goal, we are at the risk of losing a client.
So, we opted for a potential yet tiny performance drop for a greater increase in the ease of event setup. Because in the end, usability is performance.
