anti patterns

Anyone who doesn't know what anti-patterns are should look at :

http://en.wikipedia.org/wiki/Anti-patterns

I don't know whether to laugh or cry when I read some of them. I have encountered much misery in projects where anti-patterns where being used with free abandon. The manager usually has no clue about this and thinks that re-factoring is just simply a time waste and developers should persist with using what's already there.

If you are non-tech then you should read the management anti-patterns.

The Ideal GUI Architecture

The above diagram is what I consider to be the ideal GUI architecture. The database or persistance layer has been ignored but I have included the middle layer, or application layer. The most important aspect about this diagram is that the client layer is completely seperated from the middle layer, and within the client layer a further seperation exists that seperates more complex functionality from the GUI that the user sees.

A number of J2EE patterns can exist in this ideal model, however one pattern, the business delegate pattern is one of the most important conerstones of this design.
Discussion of some concepts represented in the diagram :

• Business Delegate : All business functional calls are exposed in the interface to this class, which is based upon the singleton pattern. For example methods such as getCustomers(), saveCustomer(Customer), getTrades() etc. exist as methods within this interface. As applications can be very complex, a number of business delegates may exist eg. CustomerDelegate, CompanyDelegate, FixedIncomeTradeDelegate etc.

• Cache : Some calls to retrieve data during the lifetime of a users session, may only need to access the data once, and then not have to worry about retrieving it again from the back-end. The cache stores this information. The Delegate worries about this functionality, so again, the GUI does not have to be concerned about whether or not the data needs to be pulled from the database, or accessed from the cache, every time getXXXX() is called.

• EJB: The delegate pattern handles all the instantiations of EJB interfaces, be it through the service locator pattern or otherwise. Calls to EJBs are typically synchronous calls, ie. a user clicks on a button to retrieve some information and the system hangs until the retrieved data is shown on the screen, however synchronous calls can also appear asynchronous to the user; programatically the GUI can be designed so that the user can continue working with an "un-frozen" GUI while data is retrieved. More on this later!

• Message Listener: Of course in an ideal world we wouldn't have to worry about asynchronous data feeds, however in a lot of situations, including high performance multi-threaded trading systems where the GUI needs to be updated in real-time, messages or feeds submit data to be updated on the clients screen at arbitrary times intervals. A message listener can be added which resides in the client, and listens for messages (via JMS or otherwise), and via the business delegate, gains access to the relevant GUI component and updates it. There is a LOT more to asynchronous GUI developement which I can't go into here, since this is article is a simple overview.

One thing omitted from this diagram is exception handling. There are many patterns, but commonly a helper class, with access to the central GUI frame, accessed by the business delegate solves this problem; all exceptions are handled and sent on to display a dialog with a judicious error message displayed.

So that's basically all that entails a well architected front end rich client GUI. It's only an overview, but it has a central theme: seperation!... seperation!.... seperation! The GUI developer is seperated from many complexities and can concentrate on what's important: what the user sees.

Information Chunking

This article discusses ways of organising related information on the screen. For some what I am going to discuss may seem incredibly intuitive, but the main motivation for writing this article is that I see poorly designed GUI still being built today. A GUI is a user's view into the system, and if the underlying data is being displayed in a warped way on the screen, then the user has a warped understanding of the system.

Information can be 'chunked' in a number of ways. There are many ways, however there are 4 commonly used ways of organising related information on the screen.

• Panes
• Tabbed Panes
• Frames
• Tables

Panes - panes represent an oblong section of real estate on the GUI. Related information can be organised in one of these panes. An entity in an object model translates well to a pane.

Tabbed Panes - are like a pane but uses a folder divider metaphor whereby the user can quickly flip through different panes. Tabbed panes can hold huge amounts of information related to how many folders used.

Frames (or dialogs) - Are like a pane, however a frame is seperated out of the current application frame, into another frame. This is a more extreme form of information chunking and should be used to emphasise that we are dealing with a very seperate area of the business domain model. Frames can also contain a seperate transaction process.

Tables - tables need little introduction suffice to say that they can be used to display summary information of business entities, most typically a row on the screen represents a row in a database table. Further actions upon a row can release further information to a user (ie. double clicking a row).

Panes and Tabbed Panes

Consider the following simple BDM (Business Domain Model)

This is a simple one to many relationship. If you wanted to represent this information in a GUI, what would be the best approach?


The above example shows a customer entity represented in a pane in the application. If the number of accounts a user has is small (ie. 1 to 3), then a tabbed pane approach such as above would be an ideal solution. Tabbed panes have a horizontal way of grouping data.

Borders are very important. The fact that the customer border 'captures' the account tabbed pane indicates to the user very quickly that the group of accounts belongs to the customer. It's a subtle thing, but using borders effectively translates the meaning of how information is grouped and how the information is represented in the system.


Tables

Consider the following simple BDM.


This is a one to many relationship where a supervisor has a minimum of 10 employees to supervise with no upper limit.


Because there are a large number of employees that belong to one supervisor, a tabbed approach is not recommended. Although it is possible to have many rows of tabs per tabbed pane (in most developement environments), it is not recommended as it can create confusion for the user. Some tabbed pane systems allow the panes to scroll off the edge of the frame, while others (see Windows -> Control Panel -> System) stack tabs on top of each other.

Tables generally map one row to one entity in the business domain model as can be seen. As the number of employees increase, the system can simply tack them on at the bottom of the table, or use a scroll bar if the numbers get really large. Tables have a vertical way of grouping data.

Again borders have been used to emphasize that the supervisor entity 'contains' a group of employees. Borders emphasise OO design!

Frames

One problem with using tables is that each entity recieves one row of space to display its information. Often it is not enough to display all the desired information. Maybe seven or eight properties of the employee can be displayed in a table row, when in fact there is a whole screen of information that needs to be shown.

One way to do this is to display all the information in another frame.

A user could for example double or single click on a row, or highlight a row and then click on a 'View Details' button.

This appears to be a popular use of frames; ie. expanding an entity from a row in a table. From a usability point of view it is important that the frame/dialog that pops up does not obscure the whole screen.

Another way of expanding an entity's information from a row in a table is to apply 'expandable' / 'collapsable' behaviour on the rows. That is, when a user clicks on a row, the row expands to reveal all the information, and when the user clicks on the row again it collapses. This approach is commonly seen on the web where frames are used less. 'Expandable'/'Collapsable' behaviour is also commonly seen in menus and tree-views.

Another arbitrary example....

We can nest panes and tabbed panes, since they are basically containers. ie. containers can contain containers. The following is a GUI protoype I would come up based on the BDM.

It's simple really. The account container 'contains' Credit Union containers. The Account entity aggregates Credit Union entities. This example doesn’t really explore this model any further, it's simply presented in a view for the user so it helps them understand what relationships exist under the hood. Domain models can of course get much more complex than that, however the GUI designer has to decide what the GUI user sees related to the user's particular role within the system!

Recursive Entities

Recursive entities translate to tree-like data representations, as they are inherintly tree like. For example an employee of a company can manage other employees and so forth.

A common approach for graphically representing this situation would be to have a collapsable/expandable menu system on the left, and on the right a pane display information for the instance of the selected entity. Clicking on a menu-item on the left will bring up the corresponding information on the right.

And that's about it for 'information chunking'. What this document has tried to illustrate with the examples shown is that the Business Domain Model dictates the logic of how the GUI presents itself. In an ideal world that is not always possible, however GUI designers should strive to represent information on the screen based on the relationships in the business domain model.

Graphical User Interface Design - The Right Way

Having been in the software industry for over five years now, I notice that development of high quality GUIs is low on the agenda when it comes to delivering software to a client. This is a shame, and real problem, when it comes to delivering succesful solutions, because the GUI is what the business user sees. It is their window to the system, and basically bridges the software user to the underlying system.

Developing GUIs is a real art that requires creativity, high technical expertise and a high knowledge of the business domain. Above all it requires developers who are not purely insulated in a world of technical ideals, but rather, while the technical side is important, the GUI developer should have one foot in the business side of the system, have a willingness to interact with business users.

Business Domain Relationship to the GUI.

The rather crude, highly figurative diagram at the top of this page is supposed to represent a business domain model being converted into a GUI. Each of the business entities is rendered on the GUI how it appears in the domain model. Through the use of panels, component chunking and deft artistic touch, the business model can be rendered into a screen where there is a logical visual layout that links well to the user's understanding (or forces the user to understand in a certain way) the underlying business model. This graphical realised representation of the abstract business domain helps everyone achieve a common understanding about what the software is supposed to do.

Coming soon : 'component chunking'.