Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Can I keep my OMI?

by pg (Canon)
on Nov 07, 2004 at 02:52 UTC ( #405841=perlmeditation: print w/replies, xml ) Need Help??

About a week ago, on the deployment night for the third release of one of our key applications, as always I stayed late in the company. Around 10:00 PM, I was talking with my key user, while we are waiting for the database to come up, and the system to come back, so she can do her acceptance testing.

When I asked about her list of top requirements and enhancements that she wanted for next release (reelase 4), she asked "can I keep my OMI"? Now OMI is an old application we had, which is written in COBOL and CICS, running on mainframe. This new application we were deploying was used to replace OMI, it is a mixture of web application (J2EE and Struts) and desktop GUI (written in OpenRoad and VB).

When I asked for the reason, she said that, the biggest reason was that, with the new application, in order to complete one business task, she has to go through 7 or 8 screens/pages, but with the old application, everything is on one screen. It is a big waste of time on user side. We were deploying the third release of the new application, so user traning is not the issue. She has already increased her staff to deal with the new application, and most likely has to increase again (so the labour cost is going up)

Mainframe CICS is a language allows you to create text-mode GUI applications. It was definitely not very easy to use from the programmer's point of view, and you can imagine that it is not visually pleasant. However as it is not easy to use for the programmers, they tend to create as less screens as possible. But as GUI design is getting more and more easy, programmers tend to come up more screens.

I came to realize one thing through this conversation and also other occassions that, when GUI PROGRAMMING is becoming more and more easy, GUI DESIGN is not. Users don't care what technology you use, or how greate they are, they care whether the application you created helps them, and makes their job and life easier, but not to jam their business processes.

Replies are listed 'Best First'.
Re: Can I keep my OMI?
by FoxtrotUniform (Prior) on Nov 07, 2004 at 04:21 UTC
    Users don't care what technology you use, or how great they are, they care whether the application you created helps them, and makes their job and life easier, but not to jam their business processes.

    Well put.

    Yet another good reason to keep one's users in the loop while developing a program. Had your key user been around to say "working with this interface is going to be a huge pain" when the GUI was first designed, it could have been fixed with minimal cost and minimal fuss.

    <preachy>We need to keep in mind that many programs are written to be used, not to entertain us with challenging and intricate implementation puzzles.</preachy>

    Yours in pedantry,
    F o x t r o t U n i f o r m

    "Anything you put in comments is not tested and easily goes out of date." -- tye

      "Yet another good reason to keep one's users in the loop while developing a program."

      Very true!

      That new application was something we bought couple of years ago, but with quite a few major enhancement added. By the way, that vendor bankrupted 2 years ago, which I think they deserved.

      We added couple of major enhancements through the years, and for the pieces we add, the design is better, as we always had users involved, and they saw the screens/screen flows on paper as early as design phase.

      The users are much more satisfied with the enhancements we made in house than what the original application delivers, but the original part still makes up 95 percent of today's application.

Re: Can I keep my OMI?
by cLive ;-) (Prior) on Nov 07, 2004 at 08:47 UTC
    A timely post!

    I'm currently in the middle of The Usability Engineering Lifecycle: A Practitioner's Handbook for User Interface Design and it's an interesting read (if a little dry in places for my normal tastes).

    I was interested to see that I'm already about 2/3 of the way there, and that most of the best practices that I'm missing have a lot to do with only having a small team - we all wear several hats.

    If you have a fixed user base (as opposed to pretty much anybody when it comes to web hosting that we have :) I think you'll get a lot of useful insights out of the first 50 pages alone.

    Actually, one of the ideas I'm exploring at the moment is building two user interfaces for each product from the very beginning, and allowing the user to set their preference on first run. One would be point, click, lots of questions. The other would be denser layout, less prods and keyboard oriented.

    Of course, being lazy, I want to be able to do this so that when we add apps, it would be transparent from a coders point of view.

    Whether or not this will be possible is still up for internal debate (internal as in inside my head internal).

    There are other ways I'm looking at tweaking the UI. The one I like the most (and actually think it can be easily integrated) is a password field preference. I'd like users to be able to set a preference so that when they are changing a password (email/FTP etc), they can either enter the password in clear text, or enter it twice "starred". If you're in a shared environment, you might go for the latter, but what purpose does that serve when you're on your own machine at home? Other than to slow you down a bit :)

    The other key element of UI design that gets harder as the project grows is consistency of layout. For us, having in house CSS helps, but I still find certain scripts every now and then that have buttons in slightly the wrong place, or actions that don't lead to intuitive conclusions. Allocating someone to keep on eye on these things is quite usefiul.

    As an aside (and rant), does anyone know a simple, well designed (that shuts out Totem :) media player for Windows or Linux, that maintains a clean, intuitive playlist that doesn't try to show you how "cool" it is. On Windows, I use WNP and WinAmp, and both just piss me off. If I'd wanted 8pt text I'd have set that in Window ty very much WinAmp :(. And WMP can't seem to decide whether to be skinned or not. Even when you choose no skinning, it likes to "fade away" if you leave it alone for a second. Grrr. I mean, how hard can it be to create an application that cleanly uses the OS's UI to actually create an app that's intuitive to a native OS user??? Rant over.


    cLive ;-)

      Media Player Classic has a very simple interface and works with just about any file. Couldn't get any simpler.

      For Linux, I prefer Totem, with the Xine backend. Gstreamer just isn't ready for production yet.

      concerning your rant aside: ever tried VLC Media player ( I'm pretty happy about it (not only because it's freely licensed and i can use it on my company thinkpad).

Re: Can I keep my OMI?
by knexus (Hermit) on Nov 07, 2004 at 13:42 UTC
    I find your assertion that the ease/difficulty with which programmers can create GUI screens is somewhat proportional to the number of screens created to be very interesting. It seems a fairly obvious but it had never occured to me before. ++

    Also, this reminds me of a rather important learning experience we went through in SW Eng at my company many years ago. We spent a couple of man-years designing and developing a great new application and set of management tools for our hardware product line. It was going to be the best thing since sliced bread. It was loaded with new and innovative ways to setup, manage, report, etc. on the system. We loved it! Everything a "user" could want... or so we thought.

    Well, long story short... Not too long after the release, we were puzzled why users were not switching to the "new and improved" software. It was a resounding flop! The users did not want it. Sure, they thought it was slick, clever and cool, etc. but not something they would use on a daily basis. It took them more time to do the old tasks and they were not really interested in the new features that the new process would bring to them.

    This may be cliche, but we learned the hard way the perils of living in the "Ivory Tower". Engineers, of which I am one, left to their own devices will at times design and create the most wonderful and amazing products that no one will want or buy!

Re: Can I keep my OMI?
by The Mad Hatter (Priest) on Nov 07, 2004 at 03:48 UTC
    Yep. This is why good user interface designers and standards are necessary for a good application. The usability of the UI makes or breaks an app.
Re: Can I keep my OMI?
by demerphq (Chancellor) on Nov 08, 2004 at 08:26 UTC

    Ive seen this problem many a time. Management, Engineering etc all get a brilliant idea for a new system. They spend vast resources or analysis, design, contracting out etc. Then they are totally shocked that the lower level managers and staff refuse to use the new system. In this less is more day and age of layoffs and staff reductions there is no place for new systems (no matter how pretty the reports are that senior management would get) that dont reduce workload. Even if the workload is the _same_ its too much as its a) different and thus people must be retrained b) different and thus people arent comfortable with the tools.

    I think there are two strategies that can minimize the impact of this type of thing. The first is get the programmers to actually use their programs for the tasks they are meant for. This can be difficult because normally there are barriers put up between production and developement staff but if this problem can be overcome it will pay off in spades. An example for me are two biling systems we have in our firm, one is a large well known all-singing all-dancing integrated billing system, the second is a custom tool designed to bill data customers. Both systems are used for the same purpose, however the first takes about 10 screens and about 45 minutes to provision a new customer and service, and about 30 minutes to deactive a customer, and about 25 minutes to issue an adhoc credit note if the customer would like to be deactivated early. On the second system all of these tasks take no longer than about 3 minutes (and usually a lot less). The reason? The programmer was given the task of USING the tool to add customers HIMSELF early in the process. Anything he didnt like to do would not be liked by the user base. End result, he spent an extra bit of time reworking the flow of his screens to actually reflect the usage cases of his customers.

    The second tactic is to actually design the app from the front end first. Forget about back end functionality, the front end screens should be designed in close partnership with intelligent and interested users who will be given the responsibility of running the software. IMO getting this to happen is alot harder than making the GUI design team eat their own dogfood.


      The problem with getting the good key users to work on your project is, that the good key users who know all the stuff are busy in the daily production work, and taking them away from the daily production means chaos and mayhem there, at least to the other, less structured cow-orkers. So the three best methods of subverting/creating automation in my experience are to either learn the job myself so I can analyze what can be automated, or to talk to a person knowing the process from end to end with analytical knowledge, who has ideas of their own what to automate and/or to implement various small applications that have no UI and that automate single steps of the whole process.

        Yeah I agree with all of this. I'm fortunate in that we have built into our rollout process a "dev-supervised-ops" period. This time which can last a couple of month but is usually shorter involves me or one of my colleagues _doing_ production on our systems. In my experience this has always lead to tweaking and minor (froma dev point of view) usability improvements.

        The other option that I like is to spend a few days doing production tasks with a member of the production team. Working through a set of queries using the tools gives you lots of opportunities to spot possible improvements and enhancements. (You mean you use it like that!?)



      The first is get the programmers to actually use their programs for the tasks they are meant for.
      The second tactic is to actually design the app from the front end first.

      Two excellent points! Although for #2, I wouldn't say "forget about the back end functionality", just don't get too attached to it before you design your UI. You don't want to design something that you can't build ;)

        To the user, the GUI is the application!


Re: Can I keep my OMI?
by periapt (Hermit) on Nov 08, 2004 at 13:59 UTC
    These are some great comments, and right on the mark. As a user who codes because he has to, one of my basic rules is Don't do in ten what you can do in two (no matter how satisfying it is). I learned this the hard way and it took a long time to soak in but it has served me well.

    use strict; use warnings; use diagnostics;
      I take it you mean ten screens there? I dread to think what a GUI would look like after it had been 'golfed' by some of the folks 'round here!

      I can imagine the user having to enter 137 keystrokes (most of them puctuation) and finding that release 2 now only needs 136 (although completely different). Quickly followed, later that afternoon, by release 3 which needs 135. Rumours abound that release 4 beta (130 keystrokes) trashed the dev server and there seems to be a big fight in sys admin.

      Please, just give me the ten screens!

      Update: fixed typo

        :o) :o) :o)

        The rule applies to screens, keystrokes, mouse clicks, menu options, pretty much anything.

        In general, I mean that more is not better regardless of what most people think. A user wants the fewest number of screens than it takes to complete a logical task (this is the users logic, by the way). Assuming that a user is already accomplishing a task using a tool, then ask any user if they want a particular feature added to that tool and they will almost always say yes. Ask any user if they will use a particular feature and they will almost always say yes. Come back six months later and see if they are using that feature, they almost always will not be unless the feature significantly cuts down on the number of screens they access, or the number of keystrokes or mouse clicks etc. (well, one might be but there is usually one odd ball in the lot).

        That's why it is a 10:2 rule to give a sense of proportion. (not absolute)

        use strict; use warnings; use diagnostics;
Re: Can I keep my OMI?
by freddo411 (Chaplain) on Nov 10, 2004 at 22:05 UTC
    Certainly one principle of "Good" UI design is that the fewer screens/keystrokes/navigation do-hickies the better. However, this assumes that the problem space is a repetitive task. If a user operates a UI only once or twice, the user might prefer a more verbose interface, with MORE screens that explained in detail what the options were.

    There is a dissonance between a "fast" interface (OMI in your example) and a "easy-to-learn" interface (Your modern GUI). Neal Stephenson wrote a short book that illuminates the subject nicely. In the book he extols the virtues of CLI's (Command line interfaces) as "fast" interfaces.

    However, GUI's have taken hold because they are exceptionally easy to learn; commands are easily identified and labeled, commands can often be done/undone non-destructively. Again, these virtues are most useful on the first few interations of using a program.

    As a power user, I've come to prefer CLIs -- partly because I have internalized enough knowledge of the commands in my head, but also because I have the tools (man pages, command line completion, google) to discover new and different commands.

    Nothing is too wonderful to be true
    -- Michael Faraday

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://405841]
Approved by atcroft
Front-paged by FoxtrotUniform
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (8)
As of 2020-05-30 11:38 GMT
Find Nodes?
    Voting Booth?
    If programming languages were movie genres, Perl would be:

    Results (171 votes). Check out past polls.