Steve Mumford considers the user interface of our prospective label printing application

Now that we've investigated the methods of displaying Draw graphics within the RISC OS environment, we can take a broader look at the construction of the label printing application itself and make some educated decisions about the data structures we're going to use.

These will influence the directions in which the application can grow, so it's worth thinking about the implications before we start. We also need to look at the methods of data entry; it's no use creating a flexible data format if you have to go through seven hells to get the information in there in the first place.

Several months ago I mentioned that my proposed user interface to the label database would take the form of a stack of index cards; this technique is one that many people have been exposed to, so should be one that can be picked up instinctively. To navigate between the fields of a particular record, one can either click in the appropriate place or, especially if a lot of data has to be entered, by pressing Return or Tab to cycle through the available fields.

In our case, the design of the label, including the number of available fields along with their positions, is created by the user, so matters might not be quite so straightforward. However, if we assume that the fields are going to be arranged in a sensible order on the form, stepping through them in this manner will still be useful.

Originally I had planned to use the available size of each label to allow the program to guess at the number of lines of text it could squeeze on and position the fields appropriately, but it quickly struck me that this method would be far too inflexible to be of any real use. Having said that, arranging the fields on each new label by hand would be too time-consuming.

The best solution would seem to be the implementation of a 'master label' which is defined by the user when they first create the database. At this stage they can decide how many fields they want to include, as well as their positions, font sizes and so on. Once this has been designed, the gross layout can be copied over to each new label as it is created - assuming that no changes have to be made. This will allow the user to enter their data quickly without having to worry about setting out each new label.

Although having a 'master' to control the overall format of the labels is desirable, allowing the user to change field position, font type or size, it would still be beneficial to allow each label to be modified individually. By copying the characteristics of the master label rather than referencing them directiy, we can retain this ability at the expense of some memory space.

This does pose an additional problem in that some of the advantages of having a template are lost if the labels are freely modifiable after creation - if the layout of half of the records have been edited since their creation and the master label is then changed, do we reimpose the master's formatting on those modified labels, or leave them be? This potential problem could be solved by forcing the user to 'check out' any records he or she wished to tweak, and at that stage the affected label would no longer be linked to the master. Reversing the operation would remove any supplementary changes and restore the master formatting.

When considering the application's data structure, it can be seen that several natural levels exist. At the top of the tree we have information that has an effect on the entire program, such as label or paper size. The next level would include the layout of the master label, with a standard set of field positions, along with any non-editable labels or borders if necessary. Finally, there's the level that contains the bulk of the data - the actual text for the fields of each label and any bits of additional clipart.

Within these levels, particular data units repeat themselves, so we can develop the idea of a text or graphics 'object' which, for instance, might consist of an (x,y) coordinate, a string of text and a parameter block holding information such as font size or type. These objects can be used throughout the data structure to standardise and simplify data manipulation, as well as providing the database flexibility we're after.

When we're ready to store all of this data in memory, we can take the pre-prepared blocks outlined above and string them together to build the data tree. The label data could be stored as a linked list or an array of pointers to 'label' structures; each one of these would then contain lists of text and graphics objects. We'll look at an appropriate set of data structures next time - see you then.