Pattern Name

Descriptive Label Pattern

Intent

To save space on screen and render a set of data in a more human readable form.

Motivation

Usability of computer systems has a lot to do with speed. Speed of rendering screens, speed of access to data, speed of networks, speed of file transfers and speed of User Comprehension. We can aid User Comprehension by rendering data which describes familiar things in a familiar way.

If we consider that all we must do is render data for output, ignore input then the problem of presenting that data is simplified. If data is read much more often than it is input then it makes sense to optimise a system for reading (output).

Consider the problem of an Address. The format of an address varies according to the type of building, the location, country, type of land and property use. In fact it is often quite hard to codify address information in a completely satisfactory manner. For example Post codes or Zip codes are different in every nation. In order to properly codify an address in a system, you must present a complex set of input fields to capture the information. You must label those fields appropriately so that the User knows what is expected in each field.

However, if someone passed you a handful of envelopes addressed to various destinations, the chances are that you could read and interpret each one correctly, despite the fact that you had no field labelling information. Nothing to tell you which piece of text represented the street, or the number or the post code. You just know.

Applicability

Use Descriptive Label

• when data is read much more often than it is input
• when there is a commonly used real world rendering which is not sufficiently structured to be usable as an input
• when data from separate but related objects can be easily rendered together for reading purposes

Consequences

The main consequence of using Descriptive Label pattern is that you must build two screen components for each object that you wish to render as a label. You must build a label renderer for output and an editor or dialogue for input. This will mean additional engineering effort.

However, there may not be much additional work as you often have to do this anyway, if there is a requirement to summarise a collection e.g. fill a list with some summary output and "pop-up" the complete details when a list item is selected. So building descriptive labels doesn't carry a high development penatly.

Implementation

We take a look at how Descriptive Label pattern can be implemented and some of the alternative design options which it brings to a design. All the examples given here have been coded using Java JFC (Swing). The Look and Feel is predominantly Metal L&F with some additional styles. The actual presentation of these examples is largely irrelevant. The approach will work equally well on MS-Windows, Macintosh or Motif.

Basic Implementation

Consider the problem of inputting address data. For a specific type of address you may produce a data input screen which looks like this

You may have a variety of such dialogs or panels for slightly different formats depending on country, building type, land usage, e.g., a multi-storey would be a different format to bungalow which in turn would be different to unit inside an industrial or science park.

Now consider how you might write this information, were you to send a letter to the address stated

When data is read much more often than it is entered, it seems more sensible to render it in a panel which looks like an address on an envelope

For this example, white is a good colour choice for the background. It gives the appearance of a real address label.

This second example shows a subtly different rendering using a 3D relief border (or bezel).

Creating, Updating & Deleting

Creating, updating & deleting of address labels varies slightly across different look and feel techniques but the basic principle is the same. Here We take a look at three possible ways to create, update and delete. Reading is taken care of by the label as we have shown. So here we are doing a C-UD analysis rather than a CRUD analysis.

1. Object-Action

Let's look first at a traditional Object - Action presentation as you might expect to find in any Windows based application. Assume that we start with a blank panel for Addresses.

First we offer a set of buttons

Initially only the "New Address" Button would be enabled. When its pressed we get a dialogue asking for a selection of the appropriate input format

Which leads us to the full input dialog as shown earlier. After the input is complete and "OK" is pressed, we get a new Address Label on the panel like this.

We can then select this component by clicking-on with the mouse. Some indication is given that it obtains the focus and then the "Edit" and "Delete" buttons will be enabled. Pressing "Edit" will pop open the Input Dialog. Pressing "Delete" will after confirmation, remove the Address Label.

2. Webtop - Pure Direct Entry

In 1997 Sun introduced a style of User Interface called Webtop in a White Paper for Hot Java Views by Frank Ludolph et al. This moved away from the Object-Action style to a more direct approach which removed the concept of select an object, then select an action. In Webtop you simply select the object and the action is implicit. This Direct Edit approach is interesting, so let's take a look at this.

So what is the Direct Edit approach for the Create action?

Naturally, a blank label. This fits exactly into an Address Label metaphor. If you want to create one to put on an envelope, you would start with a blank one. So provide a single blank label on the panel. The act of clicking onto the label would then prompt the dialogs in the same fashion as the Object-Action design.

Once the dialog is confirmed and the label can be populated with data, simply create a new blank one, to allow additional Create actions. This works very well providing that you ensure that the blank label is always available on screen.

You will realise that there is a problem with this. No Delete action is available. We could solve this by introducing a pop-up menu at the time when the label is selected.

I decided not to pursue this option. I felt that it was not intuitive for novice users and particularly for those users who are older and not particularly computer literate.

3. Revised Webtop - Direct Explicit Actions

Fortunately, the Address Label component saves so much space that it is actually possible to append each Address Label with its own set of action buttons. Buttons are particularly good for elementary Users. They really understand the simplicity of a button. Press it and something will happen. So for the time being, I finalised my design choice on this style

Special Attributes

From our original input dialog it was possible to indicate whether the address was the registered address ( for legal purposes ) or simply a mailing address. Other types could exist e.g. Billing address, Delivery address. There are many possible combinations. We can indicate special attributes like this using a tag, icon or highlight:

A different rendering of the tag might look something like this

Collection of addresses

Consider for a moment the problem of displaying a collection of addresses for a Customer. Either the addresses over time or all the address which are current, or even both. The set is probably not huge but it could be 6 or even 10. How might we go about this in a traditional line of business style application?

Here we attempt to show two Address data panels side-by-side. There are perhaps other approaches for browsing address such as displaying a list and allowing a selection with pop-up details. The approach shown would allow us to view two side-by-side. Lets speculate that there were 6 addresses to be shown. We would need to introduce a scroll pane. or find an alternative design. The data simply would not fit on the screen. If we introduce a list with a selection mechanism, we cannot see all the addresses together.

Now consider a collection of Address Labels.

As you can see, two labels can be fitted easily. In fact 6 will fit easily into an 800 x 600 display.

Different renderings are possible, depending on the look & feel required. Here are two more examples

Example of usage

We can add an Address Label anywhere that it might be useful. In this example it forms part of an overall customer summary.

The use of Address Label here has enabled us to pack more additional information into this panel, which is designed to fit on the bottom half of an 800 x 600 display. Leaving the top half of the screen free for example, to display a table of search results. Without Address Label we would have to make the panel larger or remove some of the other data. In this example, the requirement had specified this set as the minimum mandatory set for a Corporate Customer.

Now it would be reasonable to ask, "Why do we not choose to render this whole panel as a label? Why only address label?" Like all patterns, usage is a design decision. Due to the re-usability of address and the large space saving gained Address Label is a natural choice, the rest of this panel is used for both input and output. It is not re-used elsewhere in the system, and therefore it was not considered economic to build it with a label rendering. ( refer to the Consequences section above )

Descriptive Label applied to a different problem

Consider Point of Contact information for a corporate customer. This is the type of information which you would lift from the business cards of a member of staff or a representative of the organisation.

In this example, we have introduced a scroll bar. Actually, the scrollbar is unnecessary for the rendering shown but is introduced to show that the label component can be set into a scrollpane and can then accommodate data which is larger than the fixed size of the label on the screen. The graphic rendering could perhaps be improved here to give the label a closer look to a real business card.

Or consider the problem of displaying not only an address but the description of a whole property. Using descriptive label it may be possible to produce a screen layout like this

This example is again rendered with a scroll bar on the label but here again, it is actually unnecessary. The scroll bar is shown simply to indicate how it is possible to fix the size for the label in a larger panel and not worry too much about the size of the data to be rendered inside the label.

With JFC components the scroll bar will only display when necessary. In these examples the code has been written to force the scroll bar onto the screen.

Technical Implementation

The examples in this paper have been implemented in Java using JFC. The Table and Tree components in JFC introduced a pattern for delegating the rendering and editing of a table cell or tree node to a separate class. Objects of the appropriate type i.e. implementing the appropriate interface can be used to provide the Rendering and the Editing. This means that suitable Renderers and Editors can be selected at runtime and can be plugged-in to provide the appropriate look or feel desired. This style of plug-in is sometimes referred to as Strategy Pattern in OO Modelling.

In this first example, we show a Problem Domain ( model ) Class - Address , with its Human Interface ( view ) Class - AddressLabel. The Address Label delegates its rendering for reading purposes to AddressLabelRenderer and its editing to AddressLabelEditor. In Java the Renderer and Editor would actually be Interface definitions and the Classes would be implementers of the Interface.

The Address Class provides two methods for returning its attributes in a human readable form. The asWords() method would return a comma delimited string. The asLabel() method would return a <CR> delimited string. In the example shown, only the asLabel() method is used. The AddressLabel Class echoes the method signature so that the AddressLabelRenderer can call it and the AddressLabel then delegates to the Address class to retrieve the correct data.

There is an argument to suggest that Problem Domain classes should not contain methods to support Human Interface Classes (Views). In general I would agree with this but would argue that here is a logical and acceptable place to break that rule. The asWords() and asLabel() methods are actually View independant and could equally be used by a Printing class or other classes. They are also re-usable across several View classes and finally, where else would you put such methods. Placing them elsewhere would essentially break encapsulation as some other class would need to understand the internal workings of Address for example.

In the second example, we introduce the Property example from above. This second object model has both an Address Class and a Property Class in the Problem Domain. The Property Class holds a reference to the Address. This second example shows clearly how the Renderer/Editor Pattern is re-used to provide the technical building block for the UI Pattern - Descriptive Label.

In this example, the Property.asLabel() method will first get the Address details from the Address.asLabel() method. The Human Interface Class PropertyLabel will delegate to the PD Class Property when asked by the PropertyLabelRenderer for the asLabel() data.

Again, in this 2nd example, PropertyLabelEditor and PropertyLabelRenderer would be defined as Interfaces and a Class implementing the Interface would be plugged-in at runtime. The developer would provide a default look for the PropertyLabel by providing a Class called DefaultPropertyLabelRenderer which implements IPropertyLabelRenderer Interface.

You will see from the 2nd example that the HI Classes (views) for Address are not required by the PropertyLabel. They are completely independent. You will also observe that the delegation design allows for a very flexible selection of rendering and editing. In fact the selection of appropriate renderer and editor could be made dynamically dependant on the client hardware.

Known Uses

General

• Point of Contact / Calling Card
• Addresses
• Real Estate/ Property Descriptions
• Remarks / Notes

Banking

• Security Descriptions

Bank customers borrow money to buy many, many types of things. Consider the renderings for securities such as:

• 100 shares IBM
• 3 Bedroom apartment at 101, Arcacia Ave
• Assorted machinery including 1 flow solder machine, 2 chip placement machines and a forklift truck

Pattern rather than Metaphor

When I first started to use this pattern, some of my colleagues used the term Address Label Metaphor. In fact, this image was so vivid that it stuck deep and hard. There was initial resistance to the use of the pattern for other types of data. The argument was proffered that this was Address Label Metaphor and that using it for other data types broke the metaphor.

The argument was simple. Sticking to the basic premise that Descriptive Label ( Address Label as it was then known ) was to provide a more human readable form for the data and to save valuable screen real estate in cases where reading was much more common that data entry, it is possible to think beyond Address Label as a metaphor. The metaphor was a characteristic of the rendering. If you render the read version as an address label then that is Address Label Metaphor; if you render the read version as a yellow sticky note, then that is Sticky Note Metaphor; if you render the output as a business card, then that is Business Card Metaphor.

For example:

This example introduces an icon to improve the visual affordance and meaning of what is being displayed. This is a similar technique to the tagging of the address labels from earlier. Arguably there is a separate pattern at work doing the decorating here and a possible topic for another article.

We have discovered three methods for additionally typing Descriptive Labels. We have tagged them - as with address. We have decorated them with an icon - as with the Yellow Sticky above. And we have decorated them with a background graphic - as with the attachment description shown here

Pattern transcends metaphor

Pattern transcends metaphor. Metaphor is a graphic rendering choice and nothing more. It may aid the understanding and recognition of the User. If it does then it achieves its aim. If it does not then it should not be used.

In the examples given, the engineering and principles of Descriptive Label Pattern are not broken by any metaphor used. However, if you get too hung up on metaphor, then you might argue that introducing a scroll bar is wrong because it breaks the original metaphor, e.g., Address Labels don't have scroll bars.

Thinking beyond metaphor allows us to develop better techniques in User Interface Design, whilst using metaphors to support the ideas and improve user understanding.

Acknowledgments

Although the initial idea for this pattern was mine, the pattern was heavily influenced by the White Paper, "Designing The Hot Java Views User Environment for a Network Computer", by Don Gentner, Frank Ludolph and Chris Ryan, Sun Microsystems, Inc. 1997.

The work has further been enhanced by the input of my colleagues. James Tan built the first Address Label and demonstrated the tagging feature in late 1997 using an early Swing Beta. Lynette Lim implemented the entire solution including the blank label for input and all the many input format dialogues. Yow Sai Cheong made the 2nd of the 3 Applicability observations. Tan Siow Boon devised the technical mechanism for a Renderer and an Editor based on the Swing model for TableCell whereby a table cell has a TableCellRenderer and a TableCellEditor. He also implemented the Yellow Sticky Component after James Mitchell had recognised that the Address Label Pattern could be re-used for that purpose. Ideas by James Mitchell lead to the development of the decorating by icon and by background graphics which were both implemented as Swing Components by James Tan.

Finally, thanks to Stephen Palmer and Jeff de Luca for acting as reviewers on this article.

<< Page 1