Human Interface Design

Legacy Application to Windows - Challenge of design

I’ve discovered the greatest challenge of my application programming and design career,  (Hopefully I haven’t met my match!).  My latest project involves a rather large legacy character-based system which has evolved over the past 20 years or so.  The source code directory lists some 800+ pieces of source code, with close to 500 being actively used, and others that were basically copies of some “active” source with minor modifications - mostly in the screen layouts for entry programs, and header footer changes on reports.  In all, a lot of code to evaluate. Continued »

Simplicity is Power

Seems like I’ve expounded on this topic ever since my first encounter with software and software development.  Keep it Simple (Stupid) - aka the KISS approach is, I believe, always appropriate when looking at development of a business application.  It has always been my goal that users of applications which I’ve developed not need any “training” in the use of the application, but rather (assuming they know the job which they are expected to do) they just get into the application and start using it. 

I’ve written before about how simplicity at the interface and user level does not necessarily mean simplicity behind the scenes at program core, but that in fact many times it adds to the complexity behind the scenes, putting more responsibility on the developer.  Certainly consideration must be given to the complexity behind the scene as well that it not become a tangled, unmanageable mess of what has been dubbed “spaghetti code”.

Todays emphasis on simplicity has really been brought to the forefront as the result of checking out a book recommended by Avery in a previous post reply.  The book,  Getting Real by 37 Signals triggered my mind into over-drive thinking about how strongly I believe in simplicity of design.  You might want to check out the link for yourself. 

Actually, it seems that I made reference to Getting Real in my post a year ago entitled “Getting Real” is UnReal!.  (I knew I had remembered something about less being more!).

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.

The Danger of Over Simplication

How many times have you heard “I have an easy request for you…” from either users or the non-technical manager with no concept of what it takes to create an integrated software application?  Most of us that have been up and down the development block have experienced this I’m sure, and also for many of us the request has actually been easy!  :-)  What a relief when it is!

But then … there are those other times which fall into a couple of different categories.  The first category is the category where as the developer, after looking at the request more closely you determine (much to the dismay of the requestor) that to accomplish the task will really require some major changes - lots of work - and of course that also means time and money!  After close consideration the idea for the change is either re-designed and re-considered, or scrapped.

Then there is the second category — I call it the “…seemed like a good idea at the time…” category.  This is the project which is stated very simply, and upon further investigation as the developer you decide that it will in fact be a great enhancement to the program, and will not take much to implement.  WRONG!  This is the killer project!  Not until getting into the finite details of the application do you realize that it is a monster!  After spending double the time you expected on the project with no definitive end in sight reality has hit hard!

Very simply, the requirements were over-simplified, the review before the project was over-simplified, and the execution anything but over simplified.  Oh well, chalk it up to just another day in the world of software development.  Cheer up, there’s another project coming along right after you finish this one - if you ever do that is!

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!