Summary
Khoi Vinh ponders in a recent blog post why usability is seldom a key requirement for enterprise software.
Advertisement
Most developers care about good design: Much discussion about languages, static vs. dynamic typing, and APIs boil down to how suitable a tool is for a task, and how pleasant it is to use a tool for one's daily work. Some of the most successful consumer technology products, too, owe their popularity in part to their outstanding design and usability.
Enterprise software, it can hardly be debated, is pretty bad stuff. The high-dollar applications that businesses use to run their internal operations (everything that falls under human resources, typically, but also accounting, communications and, at one time or another, just about everything else) are some of the least friendly, most difficult systems ever committed to code. If you work at a big company and you’ve ever had to do something that should be simple, like file an expense report, make changes to your salary withholdings — or, heck, if you’ve ever tried to apply for a job at a big company — then you’ve probably encountered these confounding user experiences. And you probably cursed out loud.
This is partly because enterprise software rarely gets critiqued the way even a US$30 piece of shareware will. It doesn’t benefit from the rigor of a wide and varied base of users, many of whom will freely offer merciless feedback, goading and demanding it to be better with each new release. Shielded away from the bright scrutiny of the consumer marketplace and beholden only to a relatively small coterie of information technology managers who are concerned primarily with stability, security and the continual justification of their jobs and staffs, enterprise software answers to few actual users...
Presumably, IT managers are enthusiasts of technology and the Internet as much as designers, if not more so. It’s understandable that they mail fail to explicitly grasp the design principles that inform good interfaces, but surely that same exposure should make them aware that the software they’re buying and rolling out is not as easy to use, right?
Do you agree with Vinh that usability is not a top priority in enterprise software design? To what extent do you think an enterprise developer's job would be different if design and usability were more important considerations for enterprise software?
I think this is a very accurate observation. A lot of enterprise software is, to be blunt, faecal. I suspect that part of the reason is how it is marketed. Typicall acquisition projects include: panic on part of senior management about an aspect of business/technology being out of control, and a rush to visibly do something. A comparative product evaluation that includes a checklist of functionality and presentations to senior management. There is often wishful thinking / group delusion that product X will be a silver bullet that fixes the root issue.
A decision to purchase is usually made by an individual manager or small group. The eventual users of the system usually don't make the decision. In an average or below average organization the underlying problem will be seen as being addressed at the time the purchase is made. The poor quality of much enterprie software means that a successful purchase depends upon training and consultancy. Many enetrpise software companies are ill-prepared to be effective at this.
Shelfware is often the eventual home of enterprise software.
Exceptions: it is pretty easy to see which enteroise software vendors are selling to the eventual users versus selling to teh boadroom. The vendors who want to avoid shelfware invest in message boards or mailling lists that stimulate community expertise. BEA systems is a good example of a company that aims to give developers what they want. If you look at some of their competition you will see examples of J2EE or JMS vendors that are much less user-focused and rely on their ability to market to a boadroom.
Freakishness is an understatement. Most enterprise software sucks.
Wow! Great post and worth volumes in response. However, I'll try to hold back some of my enthusiasm. This topic is IMO critical to the growth of our field.
There is no single problem with enterprise software usability. Multiple problems, and my list is by no means exhaustive, create a sum effect of a bad user experience.
Requirements Not Well-defined
End users have a hard time defining what they want - in the instances when they're actually consulted. Quite often they don't have a well-documented set of processes/business rules. Knowledge of the processes is handed down verbally and no one person, from say Accounting, has a complete knowledge of them. (Forget Sales where deals are made on a case-by-case basis.) From a developer's perspective, we're trying to design for jobs we don't do. In my own experience, design flows from requirements. Without a better knowledge of the requirements, I'm blindly designing for a community.
Process Engineering Not Occurring
Re-writing (or better yet first-time writing) of software for a business is a good opportunity to review business processes and see which ones are archaic, having been based on paper-based systems, older technologies, or constrained network bandwidth. In one situation I was involved in, the users described how they would use a screen we were designing. They described a customer faxing an invoice to their department and then someone from their department typing the invoice in the system through our screen. It was surreal for me that they'd want to continue this process when technology makes more efficient ways possible, making unnecessary the screen as well as some of the safety checks we were coding against user error.
Let's take some responsibility for not educating our users about technology and its possibilities. In my experience, many IT workers don't even know about technology or imagine its possibilities.
Buy vs. Build: Each with Its Own Problems
My current employer is a buy only shop. However, we have custom requirements for data. Our major vendor allows us to customize some web pages but with extreme constraints. For instance, we can only pose Yes/No/No Response questions. One particular question we ask is highest education level achieved. Due to the vendor's constraints, we need separate questions for high school, associate's degree, bachelor's degree, etc. It's horribly ugly and unintuitive. As a user I'd be confused and turned off by the amateur look of it - these users are our revenue stream so we're playing with fire in this instance.
On the other hand, building in-house is a long process with no guarantee of better results as I've seen on another project with another employer. Just getting application domain requirements was a frustrating exercise and harks back to some of my previous points.
Paradigms
Frankly, I'd like to see attempts at new user interface paradigms that involve more graphics and less reliance on menus. Menus are not intuitive and the menuing structure tends to change over time. "Pictures" tend to be easier for users to relate to. I realize this one is difficult because it's a major upheaval to everything we've done since the dawn of IT, but some clever graphics designer must have ideas for a better user experience.
My list is by no means exhaustive but I'll stop here before I create a work as voluminous as "War and Peace".
> Buy vs. Build: Each with Its Own Problems > > My current employer is a buy only shop. However, we have > custom requirements for data. Our major vendor allows us > to customize some web pages but with extreme constraints. > For instance, we can only pose Yes/No/No Response > questions. One particular question we ask is highest > education level achieved. Due to the vendor's constraints, > we need separate questions for high school, associate's > degree, bachelor's degree, etc. It's horribly ugly and > unintuitive. As a user I'd be confused and turned off by > the amateur look of it - these users are our revenue > stream so we're playing with fire in this instance. > > On the other hand, building in-house is a long process > with no guarantee of better results as I've seen on > another project with another employer. Just getting > application domain requirements was a frustrating exercise > and harks back to some of my previous points.
I'm in a somewhat similar boat but the software we have bought constantly fails to meet our business needs. WE are at the mercy of numerous vendors to keep up with a rapidly changing business and the plain fact is that they are not up to the challenge. For example, we've been waiting for a patch to add important functionality for more than a year and I just learned that they still haven't started to write it.
Your point about building is valid but I think one of the issues here is what build means and what buy means. People tend to think that you must build it from the ground up or you must buy a complete solution. No vendor can produce a product that meets everyones needs without delivering a something that is configurable in a Turing complete way. And building an entire enterprise application from the ground up is a doomed pursuit.
Personally I think IT tends to try to act like a software company when it builds it's own software. It uses the same processes that a shrink-wrap software company uses and tries to use all the latest and greatest technologies.
IT departments should build like they are making a collage, not a oil painting. Acquire as many pieces as possible from 3rd parties (OS or otherwise) and 'glue' them all together with simple, proven techniques. The hard part is getting some vendors to agree to produce modular software but if everyone demands it, they will do it.
> Your point about building is valid but I think one of the > issues here is what build means and what buy means. > People tend to think that you must build it from the > e ground up or you must buy a complete solution. No > vendor can produce a product that meets everyones needs > without delivering a something that is configurable in a > Turing complete way. And building an entire enterprise > application from the ground up is a doomed pursuit.
True enough. Just saying "buy" vs. "build" can cause confusion. The trick is to buy something that allows augmentation while being close to the application requirements. Right now I'm dealing with coding issues that should be child's play but due to the lack of ability to augment the vendor's code, some ugly coding is going on.
> Personally I think IT tends to try to act like a software > company when it builds it's own software. It uses the > same processes that a shrink-wrap software company uses > and tries to use all the latest and greatest > technologies.
A past employer liked to "roll their own". The problem was that the business units had no patience for the time that a fully customized enterprise system takes: we were given 4 months to go through analysis through to implementation for a large, custom loan system using J2EE on an iPlanet infrastructure (Oracle backend). Needless to say we didn't make it. Two years later what was left of the team finally implemented a product. The business unit was wild. This was what I referred to as build in-house problems.
> IT departments should build like they are making a > collage, not a oil painting. Acquire as many pieces as > possible from 3rd parties (OS or otherwise) and 'glue' > them all together with simple, proven techniques. The > hard part is getting some vendors to agree to produce > modular software but if everyone demands it, they will do > it.
It's funny, everytime I start a new software project at home, I find that someone has already done what I'm trying to do so I find no motivation to code it. I think enterprise software is much the same. So your collage comparison is very appropriate. Writing your own was necessary in the days of the "Wild West" of programming, pre-95 or so. Nowadays someone out there always has a solution ready.
The main problem boils down to: PHBs are convinced that software never wears out, so keep using it. Thus, much of what gets called Enterprise Software is 1970-era COBOL programs batch processing VSAM files. Only, the data has been dumped into some database (often, DB2, since it is the overwhelming choice for mainframes; why is a long story) to look just like those files. Such data structures involve million record/row never-normalized files/tables. Maintaining such using point&click can't really work. PHBs, since they never actually need to use it, think that spending 10s of millions of dollars pixilating is cheaper than building something that can actually work.
So, now SOA gets invented. Purpose: be the lipstick. We don't care what the data looks like, only that it have a pretty pixilated face. Worse, lots o 3270 screens get scraped into some GUI generator. "The process" is already written, so the story goes; no need to risk rebuiding it.
> So, now SOA gets invented. Purpose: be the lipstick. We > don't care what the data looks like, only that it have a > pretty pixilated face. Worse, lots o 3270 screens get > scraped into some GUI generator. "The process" is already > written, so the story goes; no need to risk rebuiding it.
I can understand this cynicism but I think SOA is actually a way out of COBOL. For a couple reasons:
1. SOA is a really popular buzzword so you can get support from management. 2. By abstracting away the details of how things get done, it's possible to migrate parts of it without migrating the entire thing at once. One dude can move a thousand bricks in a day by moving a few at a time. But if you force him to move all of those bricks at once, he cannot succeed. 3. SOA is vague enough to let you work out the details. Unlike N-tier and the other fads of yesteryear, it doesn't force you into a one-size fits all path. Unfortunately a lot of people equate SOA with ESB or BPM so that can be a hurdle.
Because of 1, I think there's little time to hesitate. You never know when SOA will be replaced by pneumatic tubes as the thing to throw money into in the "what's hot and what's not" issue of CIO magazine.
The problem is that the business world is a highly changing one...business requirements tend to change on a daily basis, and thus little time exists to think about usability.
The most significant technological factor which contributes to bad enterprisey programming is the lack of sophisticated programming/design tools which are accessible on site, at the client.
There is no much better to way to communicate an idea than to visualize it. As the Chinese say, a picture is worth a thousand words.
Imagine a web development environment where the developers could go to the client, open a screen, draw the gui, specify the information flow, encode processing algorithms, and all that by using only graphical tools!
In this way, all requirements that exist in a client's head would be transformed directly to programs.
> Imagine a web development environment where the developers > could go to the client, open a screen, draw the gui, > specify the information flow, encode processing > algorithms, and all that by using only graphical tools!
It's a beautiful dream but the reality is a landscape of tools that are cumbersome today. It's ironic that we want users to work with the enterprise systems we give them and yet many developers eschew IDE's for simple text editor/command-line compiling environments. (It's as if we're unconsciously rebelling against the perdition we put our users into.)
For C development, I prefer vi/gcc/gdb(or dbx). I'm taking a class at night that provides Visual Studio with recommendations from the professor to use it. It took one time of trying to create a simple one .c file program to make me want to throw the computer. (It seems to require non-standard header files and it wants to throw a bunch of templated code in when I don't want it. By comparison, Eclipse is more intuitive and stays out of your way.) Visual Studio pales in comparison to the complexity of what you're envisioning so I'm skeptical it's realizable.
> There is no much better to way to communicate an idea than > to visualize it. As the Chinese say, a picture is worth a > thousand words. > > Imagine a web development environment where the developers > could go to the client, open a screen, draw the gui, > specify the information flow, encode processing > algorithms, and all that by using only graphical tools!
I'm a naturally visual person and prefer diagrams to text to explain concepts, processes, etc. Given that I prefer text based development tools to all graphical tools that I have used.
It's not that I don't like pictures. I prefer them as a state above. The problem is that all of these graphical tools are so limiting that any gain from the visualization is lost many times over in the unwieldy nature of the tool.
I think there are a few changes that would improve things.
1. Stop pretending that GUIs make programming so simple that anyone can do it. It's a tool and possibly a better one but the real challenge of development (problem solving) is unchanged. This also means including features in the tool that allow for sophisticated approaches. No more one-size-fits all solutions.
2. Allow users to work with the GUI and with a deterministic and easily readable text file that can be modified by hand. This should be canonical format of the source. Until regex, diff, merge, etc. for guis is created, any other approach is 100% unacceptable. The source needs to be compilable too. I don't want to use a GUI to deploy my code. Moreover, I don't want to have to sit with some QA or Ops person and show them which buttons to click in order to deploy my code into production.
3. Create a Turing complete graphical language. Maybe UML is Turing complete (I really don't know) but I can't take any suggestion to write an entire application from the ground up in UML (only) seriously. Who has that kind of time and patience?
> Moreover, I don't want to have to > sit with some QA or Ops person and show them which buttons > to click in order to deploy my code into production.
Great point. Exactly when did it become smarter to let a person having no experience with the application or technology deploy the application? In my paranoid, conspiratorial moods, I begin to believe it's a continued effort to splinter off developers' responsibilities to try dumbing down the role of developer so low-wage help can do it.
> I think there are a few changes that would improve > things. > > 1. Stop pretending that GUIs make programming so simple > that anyone can do it. It's a tool and possibly a better > one but the real challenge of development (problem > solving) is unchanged. This also means including features > in the tool that allow for sophisticated approaches. No > more one-size-fits all solutions.
IIRC, both PowerBuilder and VB (and others I've never heard of, likely) promoted themselves as point&click app builders. Still hasn't worked out that way, but the notion that one can declaratively create a useful application remains the Holy Grail.
PHBs remain adamant that "users" (read: cheap) hands can do anything, if given a simplifying tool. As if the tool made the complexity of the function go away. PHBs of developers have the same agenda. DragNDrop, Point&Click, etc. became defined as what's simpler. Along with this came the venerable Bound Data Control, amongst other things. And, oh yeah, XML configuration HELL; my favorite.
Lastly, while I don't recall a cite, I do recall seeing an article or two asserting that some PHBs were beginning to question the wisdom of putting data structure and workflow definition in the hands of "users". Once bitten, twice shy; perhaps.
OTOH, I remain in the crowd who think that applications (of the business process sort, anyway) can be generated from the catalog of a true relational database. My particular 7% solution. Have a look at Andromeda.
> OTOH, I remain in the crowd who think that applications > (of the business process sort, anyway) can be generated > from the catalog of a true relational database. My > particular 7% solution. Have a look at Andromeda.
I've been waiting for someone to explain to me how the catalog of a DB can generate an app that receives data in many different formats, transforms, validates against complex business rules and puts into one or more target systems. Or on the other hand to generate data to send out in different formats and structures at the appropriate times.
To me, the information stored in the structure of the DB is pretty rudimentary. All it tells you is what data is there. It doesn't tell you what to do with it.
If you are saying that a basic front end for entering data into a database can be largely generated from the catalog, I agree for the most part. But that's just a really small part of what a business apps do and not really all that surprising. I fully agree that way to much micromanagment of data usually goes into building such apps. For example, I'm I had to update a stored procedure the other day. Then I had to add the new field to a Java class. Then I had to add code to another Java class to get that field and put it in the XML message. Then I had to modify a stylesheet to get the field into the result document. 4 changes to add a field. There are only two legitimate changes there (IMO): get the field, transform. The middle two steps add no value and add a lot of overhead when changes are needed. The Transform step could even be static if the target wasn't chaotically defined.
> > Moreover, I don't want to have to > > sit with some QA or Ops person and show them which > buttons > > to click in order to deploy my code into production. > > Great point. Exactly when did it become smarter to let a > person having no experience with the application or > technology deploy the application? In my paranoid, > conspiratorial moods, I begin to believe it's a continued > effort to splinter off developers' responsibilities to try > dumbing down the role of developer so low-wage help can do > it.
Personally I'd love it if they could do it without babysitting. It would be great to send a request and go home. It never works out that way. Well, I've seen it work when you have a script that they run. When it's some pirce of shit GUI tool, I'm sitting there with them: "click 30 things. Type these 200 things. You misspelled 'http'. How are your kids? This shouldn't take too much longer. Any big plans for the weekend? How long have we been waiting? It timed-out. [Sigh] Go back to the beginning. Type 200 things."
> > Imagine a web development environment where the > developers > > could go to the client, open a screen, draw the gui, > > specify the information flow, encode processing > > algorithms, and all that by using only graphical tools! > > > It's a beautiful dream but the reality is a landscape of > tools that are cumbersome today. It's ironic that we want > users to work with the enterprise systems we give them and > yet many developers eschew IDE's for simple text > editor/command-line compiling environments. (It's as if > we're unconsciously rebelling against the perdition we put > our users into.) > > For C development, I prefer vi/gcc/gdb(or dbx). I'm taking > a class at night that provides Visual Studio with > recommendations from the professor to use it. It took one > time of trying to create a simple one .c file program to > make me want to throw the computer. (It seems to require > non-standard header files and it wants to throw a bunch of > templated code in when I don't want it. By comparison, > Eclipse is more intuitive and stays out of your way.) > Visual Studio pales in comparison to the complexity of > what you're envisioning so I'm skeptical it's realizable.
Why complex? it need not be complex. What I am dreaming of is a language-independent IDE which one can design the program graphically, then hit a button to convert it to some real code.
Most, if not all, distributed applications, can be nicely represented by graphs anyway.
Flat View: This topic has 31 replies
on 3 pages
[
123
|
»
]
Previous Topic
