The interface is the face of the application behind which all of our instructional code is hidden; the interface between the user and the machinations for data crunching. It is imperative that the interface is well organised and easy to traverse hidden wiki link with a mouse. I have seen command buttons thrown upon a form as if the developer were throwing.
Ugly or disheveled design does not entice a user to utilise the application we put our blood, sweat and tears into and after all of our effort we want to motivate the user to utilise our application as much as possible.
One of our purposes as programmers is to improve the user’s experience of their working environment. Well ordered and aligned controls upon a form and well spaced details within a report will be easier upon the user’s eye and easier for the user to navigate the information presented. The user often uses the mouse cursor to guide their eyes around the display screen in a more focussed way.
It is important to understand the psyche of the user. Most users live in a very different work space to us developers. A user who works for Administration services relies heavily upon grammatically correct written language and a particular spatial sense of proportion and balance with regards to information printed upon a report which also extends to an application’s forms. Inconsistent use of capitalisation within a report or spelling mistakes within an application will be revealed by the user or client. Some programmers may conclude that the user or client is being pernickety but would we want this type of grammatical or syntactical error to appear within our code? For instance; would we want to find the word employee to be misspelt as employea and appearing as employea or Employea within a case insensitive language?
Accurately named buttons upon a form are preferable to images. An image can speak a thousand words but what does an image of a tree say? I’ve seen trees and fish used as images upon buttons. Really, it is not kindergarten and images are always open to interpretation. Write out a button’s intentions clearly in written language. Images are useful for toolbars or coolbars and there are well defined and almost universally acceptable sets of icons available for these purposes and I suggest buying a quality set of icons from a graphics house like IconExperience or IconFactory.
Application colour is also a critical aspect of usability and application identification. Brand colours of a client’s organisation or your own is often a good choice. You can give the user the option of changing the primary colour of an application specific to their PC. The main proviso in colour choice is consistency and as few as possible. I have seen many programmers first attempts at an application become a fairground of diversely coloured forms or having a form within the application that changes colour from green to red during data validation errors. My first application was an example of the full colour spectrum. When I first started programming, colour computer screens had not long been on the market and I used the new functionality to it’s fullest extent! It drove the user batty and someone else edited the application to use more uniform colours.
Limitations to a user’s access to data within an application needs to be made obvious. If a user cannot access a control’s data then disable that control and colour it a non-intrusive grey. Profligate use of error notifications with phrases like “Access Violation!”, “Warning!” or “Security Breach” when a user clicks a control that has data they do not have access to, is an absolutely ridiculous waste of time and an unnecessary cause of user anxiety.