TITLE: Embarrassed for My Discipline AUTHOR: Eugene Wallingford DATE: August 18, 2005 6:59 PM DESC: An hour with my university's financial information system was enough to cause me a little embarrassment to be a software developer. The non-software folks in the room didn't hold the sins of my discipline against me, but maybe they should. ----- BODY: Earlier this week, I learned a bit about how to use my university's financial information system. It is an application built almost entirely out of the box using Oracle E-Business Suite tools. By the time I left the room, I was embarrassed for my discipline. My college secretary gave an informal tutorial to me, another new head, and our acting dean. We learned that it is not straightforward to do most of the tasks that we might want to do. What was worst, from most point of view as a software developer, is that the complexity of the interface matched or exceeded the complexity of the underlying data. The primary users of this system -- secretaries and office personnel -- seem to be good troopers. They acknowledge the complexity of the system with mostly good cheer and seem intent on mastering the complexity of the interface. Then again, perhaps they are just being kind when they speak to me, a "computer person", and are burning their mousepads -- and me in effigy -- when I'm not around. I wouldn't blame them. The administrators I've talked to, who have to use the system to manage their budgets and personnel, openly grumble about the system. To be fair, this software solves a very large problem in our medium-sized institution. As an undergraduate, I worked as a programmer in administrative computing at my alma mater. The database with which we worked seemed uncommonly complex at the time. Of course, it wasn't; I was just inexperienced in the ways of computing. Financial information systems these days are even more complex, managing the interactions among several classes of employees and supervisors, payroll and grants and foundation accounts, departments and units and colleges, .... On top of that are issues of security and responsiveness. I don't doubt that our financial information system is more complex than any IS with which I have worked. But users shouldn't have to see any more of this complexity than necessary. Users of our system seem to see nothing but complexity. Layers of jargon-laden links that serve as menus. Several cryptic codes that must be entered before you can reach data on any form. Few, if any, defaults. Few, if any, shortcuts. The giveaway that the system is too complex for its own good? Regular users have asked system administrators to create a "cheat sheet", a page containing advice of the sort, "If you want to see data on x, do the following..." Why can't frequent, knowledgeable users find their way to commonly-needed data already? The good news for users here is that the team that administers our system has produced good on-line training material. (Someone at OracleAppsBlog thinks so, too.) Good. But why should the main focus of a software unit be to produce good documentation? As we in the agile community know, the need to write better comments usually indicates the need to write better code. The need for excellent training materials implies a need for a better interface. I don't want to be too hard on Oracle. I know that the task is complex, and I know that Oracle isn't the only computing company producing software that users can't use, at least comfortably. This system is just one example, albeit a very good one, of a general problem in our industry. But I guess I do expect more from "the world's largest enterprise software company" ... And I'm certainly not complaining about the UNI folks who have assembled our information system. They built the system on a relatively small budget using standard Oracle code, interface components, and style sheets. But, as a user, I wish that we could do better. Even sadder in these days of budget cuts in higher education, my university has almost certainly sunk in excess of $100,000 into this system and thus are committed to the long-term costs of keeping it functional. When I add in training costs, the total cost probably goes up significantly. When I add in the cost of the time lost battling the system ... I don't want to think about it. We in software development do a disservice to users when we tell them, explicitly or implicitly, that things have to be complex, hard to use, uncomfortable, painful. We tell them that they don't understand. We tell them that they must just not be smart enough to use technology. We are wrong, and they should be told that. In thinking about concrete, relatively low cost steps we would take to improve the quality of user experience, a friend and I focused on the fact that most accesses into the system recurring. While I was being "trained", I repeatedly heard "you don't need to worry about these options. You'll never use them. Focus on this subset of options...." How about something simple, which Mac OS has had forever: an easily-accessible recent items menu? Or a "most-frequently accessed reports" menu? I am guessing that, within a few uses, most administrators would never have to venture outside one of these lists. More frequent users might need a longer list, but that's no problem. Upon further inspection, it seems that users of our system can build their own shortcuts lists, by "customizing" their own "portlets". (Portlet?) But I am not yet certain how to use this interface feature properly. I must not be smart enough to use this system. Maybe I don't understand. Sorry, I don't believe that -- about me or about any of the regular users of this system. We know how to do better. Most developers know better -- or should. -----