Advertising Feature: XP Menu - A Simple And Extendable Clarion User Interface

Posted September 26 2002

Printer-friendly version

The following advertising feature about XP Menu, a commercial third party product, is written by the author of that product. It is not a review, and does not constitute part of anyone's paid subscription, nor is it an endorsement of this product by Clarion Magazine.

In this article I describe a user interface, which can be (and in part already is) implemented in the Clarion templates and source. This UI is consistent and extendable, both for the programmer and the end user. It uses a side menu, like an XP Menu, which replaces almost all user input action controls like buttons and tabs on a window, leaving more space for data. One obvious advantage for this is functionality can be automatically focus driven; the developer can disable all items that are unavailable, yet the end-user can still see all of the functionality provided in one place. The design solution I present here is template driven, and templates can be written to extend a window's functionality using the XP Menu for controlling and accessing that functionality. The XP Menu is a commercial third party tool, available on www.compad-software.com/uk/developer. This article will be about writing templates for extending functionality using the XP Menu.

Introduction

Clarion is a powerful tool for building database applications. But in all the Windows versions, not that much has changed by way of user interface (UI) for the ABC and Clarion templates. Basically, a browse is a browse, and a form is a form. You can browse through a list, and edit and print data.

The standard Clarion UI is, in my opinion, not good enough for current users and not flexible enough for current programmers. Even though Clarion offers a way of extending functionality by changing templates, or writing additional templates for third party products, I doubt if this is done by the majority of Clarion developers. Mostly, I suspect, Clarion developers enter code copied that code into other embeds, over and over again. A lot of third party vendors offer products to spice up an application. But merely changing a background and adding icons will not make a program better. More controls, more icons and scattered, different sized controls will only draw the users attention away from the data

Let's face the truth: most Clarion programmers (myself included) are not UI specialists nor graphic designers. We do not have the money nor the time to do user group tests, keep up to date with new UI principles, or design icons. But most programmers can do excellent analysis, write a dictionary, create some functional windows, and sell the program. So what's the big deal?

Support

Most of my clients are happy at first just using a program. Instead of reading a manual, they just start and see where they end. The more difficult and the less consistent a UI is for an end user, the more problems the end user will experience, and the more he/she will call/mail you.

My users do not read manuals, and they get confused if I tell them there are several ways to access some particular functionality. So, a program should state clearly what functionality is provided and what functionality is temporarily disabled. And it would be nice if there's just one place to look.

Maintenance

From a maintenance perspective, the more difficult the UI , the messier it gets when you make changes later. If you already have a lot of buttons on a window, and you need another one, where do you place it? Is there enough room in the window?

As said earlier, a UI should be consistent. But it takes some programming discipline to re-create every UI piece in the same way for every window, especially if you add functionality. Wouldn't it be nice to just have to worry about the functionality itself, and use one standard way to provide access?

Getting the picture

Take for example a browse box. A browse box simply displays records. Being able to update a record requires three buttons: Insert, Change and Delete. If you add tagging, you will need at least another button: Tag/Untag. You may want to add Tag All and Untag All buttons also. Printing records requires another button. That makes six buttons, all of which focus on that single browse box.

Now imagine a child browse box in the same window. Now there are 12 different buttons, with duplicated functionality, focusing on different data sets.

To cut a long story short, here's what I think we really need:

• One control for one user action, which can be used for different targets (Insert can be used for different browses, depending on which browse has the focus).
• A disabled or hidden state for a control under certain conditions, focus driven (i.e. the user can't change a record if there is no record)
• The ability to visually group functionality. Doing something with a record (insert, print) is something different than selecting another tab for displaying other data.
• The ability to easily extend functionality without having to redesign a window.

A solution

While thinking about these problems, I saw the first Windows XP Screenshots. And there was the solution: an XP Menu. As opposed to an Outlook menu, which takes too much space and hides most of its functionality, an XP Menu is compact, and still flexible. An XP menu is always visible, and context sensitive, for you can hide menus or disable menu items when they are not applicable. Still, a user can pretty much see most of what it has to offer. You can group functionality, and an end-user can control what is visible.
The idea is that every window has it's own XP Menu. The menu can mimic controls (like buttons and tabs). The mimicked controls are hidden and accessed by clicking an item in the menu. Actually, the XP Menu post an event (Event:Accepted in most cases) to the (hidden) control. This behaviour is more or less copied from the PopUpClass. The XP menu can also post events based on a condition, or only if a control is visible. Menu's can be hidden automatically, based on a condition. Items can conditionally be enabled or hidden, and conditionally setting an icon for a menu item is also possible.
In future updates, an XP Menu might be extended to control other UI elements in other procedure threads. (I'm thinking about that).

Take a look at the interface in Figure 1. This window contains 2 browse boxes, where the lower is a parent of the upper browse box. The browse box with focus is blue, and the browsebox without focus is colored gray, just like the MS Outlook.

Figure 1. An XP-style menu with two browses

Both browse boxes have hidden BrowseUpdateButtons. If a user clicks an item of the File actions menu, the menu automatically mimics the update button of the browse box with focus. If the user clicks on a record in the parent browse box, it will automatically get focus, turn blue, and will receive future file action clicks from the menu.

If you want to extend the functionality, you just add another item to the file action menu, and that item can be also focus dependent. No buttons, no extra resize strategies, and no messy window. And the end user will search the functionality on the only spot he/she knows: in the menu.

The Tab 1-3 menu is an automatically generated menu, which simulates tabs on a given sheet. Especially if you have a lot of tabs (say, a large update form), it can be nice to have them all in a single list, instead of having multiple tab rows (or use scroll buttons). The names presented in the tab menu are taken from the text on the tabs (?Tab3 is named 'MyTab'), and the for the sheet, PROP: NoSheet and PROP:Wizard are set. More appropriate names are required though.

Browse functionality

This example shows that the menu is not merely a replacement for buttons and tabs on a window. Even user-controlled selection lists can be implemented in the menu, using the menu to easily control complex behaviour.

For example, I recently found myself creating keys and locators for new fields in the database, in all the windows where the file is used in a browse box. Really, I wanted the end user to be able to choose which fields should be displayed. This way, if I add another field, it's initially not displayed, but at least the end-user can choose to display it at run-time, and I do not have to test every browse box at compile time. I call this field selection.

Also, an end user should be able to choose a sort order from the fields that are displayed in the browse box. Multiple fields can be chosen, just like a key has multiple components, and it should be possible to also select fields for which no key is defined (that may take a little longer at run-time to sort, though). I call this functionality sort selection.

There's one more thing: If the same type of data is used in different browse boxes, the same set of field and sort selections can be applied. If for example, I have a browse with orders, I can use this browse box in a BrowseOrder window, and in a BrowseClient or UpdateClient window. In the first window, all orders are presented, and in the additional windows, only those orders belonging to that client are presented. So there is a browse box with orders, and in some cases, the order list may be range limited while displaying the same columns. Technically, the fields and sort settings should be usable in different browse boxes when the same view is used.

Field and sort selection - visual implementation

The window in Figure 2 updates a Dossier record. (Dossier is a table in a patent registration application I created) The code and title fields are actually fields from this table, and the list box (on the invisible tab 'Contract') shows contract child records, which belong to the dossier. This window contains a lot of tabs, but the Extra menu here is set to show a maximum of six items (that's changeable by the end-user at run-time per menu though).

Figure 2. The Contract "tab" on the Dossier update form.

Note that the File actions menu applies to the browse box with focus, which is the contract child browse box. Note also that I added the 'count' functionality, the result of which is displayed at the top of the window.

More interesting is the Columns menu. In this menu, the end user can define column presets (Both field and sort settings) for the browse box with focus. Right clicking the Standard item reveals a popup menu, as in Figure 3.

Figure 3. The Columns popup menu

Now, the user can create a new column set, change the name, or delete the column set (if there is more than one). For the new and change options, the user can edit the name:

Figure 4. Adding a new column

Then, from the properties item, a window is shown in which the end user can select the fields to display as columns, the order of these fields in the list box, or the fields on which the list has to be sorted (with multiple sort levels possible). These settings are stored per column set. In the end-user version, the field names are replaced with a short description of the field, using the data dictionary short description field.

Figure 5. Setting the column fields

Removing all fields except CTR:Code and CTR:Name, and setting CTR:Code as the field to sort on, will result in the Contract browse in Figure 6.

Figure 6. The Contract browse with the new column set.

Notice that the end-user now can switch very rapidly between the two column sets (Standard and New column set). An end user can use the column sets also for setting different sort orders while displaying the same information. An end-user can also use the column settings for saving filters, which I'll describe later.

The bullet icon more or less resembles a radio control, showing which set is selected, and indicating that only one item can be selected at a time.

Now, in every other window where there is a browse box showing contract records, these column settings can be used, and the items Standard and New column set will be shown to the user.

From the programmer's perspective, the browsebox is given a BrowseID, which should be unique for every unique view configuration. If the same parent and child files are used in a view, the same BrowseID can be used and the same column settings can be shown to the user.

In my implementation, column settings are unique for the window logon, so if someone else logs onto that machine, they can create their own settings.

Summary

Support can be reduced by building a consistent User Interface. An XP Menu can be used to build a consistent User Interface. To the programmer, a.User Interface using the XP Menu can easily be extended with other functionality. The XP menu can reduce the number of controls on a window, focusing the user on the actual data. A menu item can be focus driven, so that one menu item controls multiple other controls (list boxes). A menu can also be used for other purposes than mimicking a button. An example is the column set list provided in this article.

XP Menu Web Site: www.compad-software.com/uk/developer