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 with a mouse. I have seen command buttons thrown upon a form as if the developer were throwing dice in a game of yahtzee! (http://en.wikipedia.org/wiki/Yahtzee%21)
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. This is a similar principal to using a pencil to guide one’s eyes as a speed reading method (http://en.wikipedia.org/wiki/Speed_reading).
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.
In most cases it is preferable to allow the user to see all of the controls upon a form including features they cannot access; features which can be disabled. If you hide controls upon a form you risk discombobulating your well organised form layout which violates the guideline of improving the user’s working experience. Even more disconcerting is hidden controls that magically appear in front of the user: Yes I know the controls have a visible property but it does not mean we have to use it.
In summation of the above:
- Well ordered and laid out controls are easier upon the eye and easier to navigate with the mouse cursor.
- Check for grammatical errors or inconsistency in the way words are used.
- Use written names instead of icons or images for a form’s controls.
- Use a uniform colour identifier for applications. Corporate branding colours are a good choice.
- Do not hide controls from the user. If the user cannot access a control then notify them of the limitation in a a non-intrusive way.
- Do not make controls appear and disappear upon a form.
For those interested in improving the grammar and punctuation within their applications I highly recommend the following book:
Renton, N.E. (2004) Compendium of Style & Good Writing - Third Edition, John Wiley & Sons Australia.
The older copies, of which I own one, were:
Renton, N.E. (1990) Elements of Style & Good Writing, Schwartz and Wilkinson, Melbourne, Australia.
Duane Hennessy
Senior Software Engineer and Systems Architect.
Bandicoot Software
Tropical Queensland, Australia
(ABN: 33 682 969 957)
Bandicoot CodeClipper, your code snippet organiser.
http://www.bandicootsoftware.com.au
Moderator of http://groups.yahoo.com/group/AccessDevelopers.