User Interface

Application Over Design — Is there such a thing?

Yes there is ladies and gentlemen!  End of story, NOT end of post!

While doing some “cleaning up” around the office recently I ran into a design spec that I had the misfortune to encounter some 20 years ago.  It was submitted as a “Preliminary Draft”, weighed in at about the birth of a child (…only kidding, but over 100 double sided pages of small print), and was supposed to describe (as an overview) the specifications desired for a new manufacturing and inventory control system.  The project was scrapped after a number of months as not “fitting the budget”, which come to find out really couldn’t possibly have supported much more than that design specification itself.  I kept the document around to serve as a reminder to me of how NOT to design an application.

If a picture is worth a thousand words, then I figure that had the specs been graphically portrayed in that specification document, rather than verbal, its birthweight might have been reduced to that of a rodent.  As a side benefit, it may also have been read (…resulting in understanding)!  What a concept!  Then there might have been more of a budget for actually getting the project off the ground!

However, at that time the powerful time-saving and graphical development environments we have available today were more a dream than reality.  While I knew of COBOL programmers who seemed to think in terms of 80 or 132 columns and 24 to 80 row grids, and thus could very quickly place items properly on screens and reports, they were a special bunch!  Todays tools very much support the ability to a certain extent, to “design-as-you-go”.  It’s a wonderful time for development!  Anyone ever wonder what we’ll be using 20 years from now?

Application Design for Tight Operator Control

In these days of exceptionally “busy” screens within which operators can usually choose many options (…and sometimes ones which they shouldn’t), I have been placed in a position where I am being asked to create an application with minimal functionality entry screens!  This design approach reminds me of the very simplistic (…also efficient, lean and mean) entry screens of the character-based applications I was designing in the 70’s and 80’s.  No surprise here since the application being designed is truly a system based upon that early design approach and technology — and my customer describes himself as a “control freak”, and describes a co-worker as “even more of a control freak” than he is!

OK, so you’ve now got a general picture of a design criteria — Keep It Simple Stupid!  Continued »

Can applications be too Automated?

As a custom application developer working mostly with small businesses, users often look at “Why can’t the program do this?”, or “How about having the program add this, subtract this - when it’s this, then add a percentage…” yada, yada, yada.  Perhaps you recognize the pattern.  There can be arguments for doing much in the way of accommodating the requests, but in my opinion there can become a time when an application is too automated. Continued »

Legacy Applications - What Keeps Them Running?

It can be a huge leap from the highly customized legacy application (which for many have been in use double digit years), to the newer graphical point and click or web based AJAX type application.  So my question today is “What keeps them running?”,  or perhaps a better question is what is it about them that keeps them in place for so long?  My questions arise once again prompted by a vist with a new client now running their legacy character based system well into the double digit year mark. Continued »

Applications - Why User Documentation?

I’ve stated before that my goal with applications I create is to provide an application so intuitive that if one knows the job for which the application was designed that the interface be so intuitive that no training would be required.  This is a lofty goal for sure — and not one easily achieved.  It might be better to set the goal to be more like 95% of the time “…the interface be so intuitive that no training would be required…”, or 98% or something like that.  My first answer to “Why User Documentation?” would have to be that it is what covers the shortfall percentage of design that just doesn’t measure up to the lofty goal.

Secondly I believe that most applications will have those activities which are only seldom performed, or performed only as a “fix” to something gone wrong.  The infrequently performed operations which just don’t fit into the everyday flow of the business function, and therefore also not of the business application should be documented for users.  Of course, any documentation available will be only as good as its availability.

Ready availability of documentation for an application, or more explicitly documentation specific to a particular operation is crucial.  As long as I’ve been around applications this has always been an issue.  First off, creating good user documentation (read this as usable user documentation), is not an easy task.  It can also be a costly task.  Ineffective and it won’t get used, unavailable and it won’t get used, confusing and hard to find answers and it won’t get used!

More often than not what I’ve seen is an attitude of “Why document - nobody ever looks at it anyway”, or, “Document the obvious, don’t worry about the details - let them (users) ask!”.  Personally I think application users deserve more respect than that.

Changes, Users and Resistance

Let’s face it, software development and design is complex - even when it’s simple

There are some areas where it seems that no matter what is done there will be unhappy users - at least for a while.  I found myself in that category last week when it was announced by Data Access Corp that their beloved newsgroup forums were going to be moving away from the “old fashioned” newsgroup format to a new web-based format for their Dataflex and VDF (Visual Dataflex) groups.  Almost immediately the resistance began showing - and I was surprised to see myself as one of those initially disappointed to see the move.  I had a lot of company!

Once I realized my resistance I immediately recognized my behavior as like that I’ve experienced from users of my custom applications.  “If it ain’t broke…” - you know the rest!  I realized that I had become very comfortable with the status quo - after all, it had been in place for many years, was reliable, and known.  I have become proficient working with it, using it in the way I most needed to - it has been serving my purposes just fine.

However, as with the rest of life, change is inevitable.  While we welcome some changes, it is our nature to be disturbed by others - we get to make the choice of how we make the most of it.  The reasons for change may vary greatly, but through my rose colored glasses I find that most are made for good reasons (…though not always reasoning that I agree with ). 

I suspect that once the changes are made to the Dataflex newsgroups I will become comfortable with those changes, but until then I’ll be one of those grumbling.  Hopefully it will help me to tolerate better those resistant to the changes in applications which I make.

Application Design and Expectations

I believe I’ve stated before in this blog that at one time while working with some ERP software I became known as the man who “…wouldn’t have designed it that way!”  Well, yesterday I saw that same user frustration and amazement (I’m being nice) with regard to an application that my friend was (trying) to use.  He was somewhat under the gun to get setup, and the software wasn’t working the way he expected or thought that it should.

Now, I don’t know this friend well enough to understand his computer preferences and depth of experience as an end-user.  I do know that he does do professional programming.  Perhaps he’s a “Mac” guy trying to run software on a “PC” — but clearly the application software was not living up to his expectation, and he was frustrated.  Seeing his frustration reminded me once again of the difficulty which can be experienced when trying to develop that “perfect” application! 

It just so happens that the software he was using matches my expectations - I find it easy-to-use, intuitive and structurally together, and therein lies what I’ve come to appreciate as one of the biggest difficulties with creating application software.  Yes there are certain “standards” to be used, and using them results in ease-of-use for those familiar with those “standards”.  Where application design seems to break down in my opinion is when there is the need to do something “special”, for example use some functionality for which the software is designed, but functionality that is seldom used, “out-of-the-ordinary” in that respect.

It seems to me that these kind of operations just don’t seem to clearly “fit” in any one place, so to get to them a user may have to go to something like “Options”, or maybe “Setup”, or maybe it can only be found through a menu 4 or 5 levels down.  Perhaps the functionality is so independent (although related) to the main application that it actually acts as if it were an independent application.  These are problem areas for users — and as developers it is important for us to get as much feedback as we can (if we can) regarding where to place access for the “out-of-the-ordinary” functionality.

A well-designed help functionality can sometimes be a support for this — in my experience, forget help in the “manual” — you probably wouldn’t be able to find it if in fact it once existed !

User Flexibility vs Simplicity

Once again I have found myself really struggling with what seems to be conflicting requirements for an application currently being developed.  I have blogged on more than one occasion here that to create an application which “hides” the complexity of its workings from its users is no trivial task, yet I believe, one that is truly worth the effort.  Providing flexibility for users can also be a challenge during development if the developer is “looking ahead”.

By “looking ahead” what I mean is that the developer might be working on a custom application with a particularly narrow functionality focus, yet be very aware that the functionality desired now will probably NOT fit the needs in the future, perhaps as soon as a few months.  While in the program where possible it may be desireable to build in the functionality desired for the future, but somehow “turn it off” for the current application iteration.  Doing this of course assumes a long-term commitment to the application and maintenance of it.

A common way to create an application which can be “flexible” in this manner is through the use of what might be called “switches” — or another term I’ve seen used is “parameters”.  These have proven to be quite effective — to a point at least.  There does come a point in time I believe that the value of “switches” is no longer useful.  I actually worked with some software where there were so many “switches” to be set (they bragged about having over 4000!), that a week of “training” in setup was required.  Unless the application is going to be used in a large environment with a dedicated IT department that would be (IMO) excessive.  Additionally this software had many dependencies built into those “switches” - i.e. if parameter 2003 is set to true, then 3014 and 4002 must be set to false.

As with so many things in software development, there are always tradeoffs, as well as a multitude of considerations.  I believe that the more of these types of considerations that are taken into account throughout the entire development life cycle, the better will be the resultant software.

Software Application Speed and ADD Users

ADD — aka Attention Deficit Disorder — is, some say, an altogether too common ailment in today’s society, at least in the U.S. While I certainly don’t intend to debate that issue, a recent experience got me to thinking about how children with ADD do and will grow up to be computer application users. These thoughts in turn had me thinking once again about application interface design and user needs.

Much is written about interface design. For years we’ve worked hard to provide intuitive “user-friendly” interfaces for our applications. Much has been written about visual presentation, and many options for changes to the visual presentation such as “skinning” have been introduced.

Perhaps, however, the most important of all the considerations for an application should be the application response time. I’m not aware of any user who doesn’t get impatient with poor response - defined here as a response time meeting their personal expectation! As more and more users (ADD or otherwise) become frustrated with either speed issues OR for some, the cluttered screen, it seems imperative that we as developers be constantly on the alert for signs of this frustration brewing. My experience would indicate that most computer applications used in a business environment are not being used by “computer” users, but rather by users who understand the task or job they are required to do, and (in some case, regrettably) must use the “computer” to accomplish the task.

Application design is no trivial task!

User Experience, User Interface or Human Interface Design?

I have written quite often over the past year about user interface issues. One of my blog posts worked with the question of whether the interface should be busy or sparse. I also provided a link to a fellow developer white paper which dealt with some simple ideas regarding layout of fields on an entry screen. The user interface has always been something of interest to me, since the users I deal with are looking for simplicity — yet simplicity with powerful functionality.

As a result of reading a post in one of the newsgroups which I follow regularly, I discovered of all things a new (to me) acronym — UX. Now my definition for UX up until today had been UNIX, but now I find it is being used for user experience. (…proof once again that you learn something every day — IF you “show up”). The post which I read had a link to a detailed article named “Label Placement in Forms” –and this article in turn introduced me to a new website www.UXmatters.com. Readers of this blog may find the article, and the website of interest.

Anyway, no matter what you call it, design of an application interface is critical. Not only must an application be fully functional for the task to be performed, but it is important that it be visually functional as well.

I know various developers who from time to time can very quickly get on a soapbox regarding interface design preferences. In my explorations today I found an interesting blog regarding user experiences — “The user experience soapbox“. Enjoy!