Controls

Contents

• Contents
• Control types
  • Text
    • Delimited text
  • Multi-select
  • Data
  • Sorting
• Validation
• Disabled controls
• General behaviour
• Backwards compatibility
• Staying ahead of the curve

Contents

A comprehensive controls library is a fundamental requirement to any good graphical user interface.

The controls are likely to have their own library separate from any other OS component. While there is an argument to be made for having the ability to have interchangeable control libraries (to swap out the control behaviour for one from another OS), the complexity of controls means that this is unlikely to be sensible or practical. Thus, while it may be possible to have the general desktop environment mimic that of another OS, the behaviour of controls is unlikely to change.

Control types

Text

Text boxes will support proper multi-level undo (not the single “flip-flop” undo as in Windows) as well as triple-click for line select.

Undo will be per-stride, not per character. There is a horrible habit with some software where undo reverts every last thing you typed, rather than the most recent word, paragraph or the most recent few seconds.

Delimited text

Various systems and applications present fields for entering delimited text. Examples of such fields include credit card numbers, dates, times, IPv4 addresses and serial numbers. Almost invariably the implementation of such fields is terrible. Commonly a separate text box will be used for each field, preventing the overall value from being copied. In some instances the software is clever enough to paste a single value across all the text boxes (often seen with application serial numbers) but not always.

Delimited fields will be a standard option. They will use only a single box with pre-filled delimiters. This means that the user interface must use a typeface with monospace digits (common but not true of all typefaces). These controls will treat the delimiters as regular characters for the purposes of select and copy, allowing copy and paste to function as close to normally as possible. Pasting a value will fill as many fields as possible. When typing, pressing a delimiter character will simply move the text cursor to the next field except where it is already at the start of a field, in which case the keystroke will be ignored. The delimiters will be included when the value is copied.

Such controls will offer clarity to the user without impeding their ability to use them effectively.

Multi-select

Microsoft’s first attempt at multiple-select, preserved for eternity in HTML, was a list box where you can have multiple items selected at once. This is finicky to use, and has a poor overview as the user can’t observe what items are chosen once the list gets too long.

The Event Viewer in Windows Vista introduced an even more painful option, using tick boxes to select the items. Type-to-find does not work, and there is still poor overview of what has been selected.

There needs to be a much more practical multi-select control. This must have type-to-find or even type-to-filter and selected values should move to the top so that they can be observed and de-selected.

Data

This general classification covers tables and related views. Such views will allow the columns to be resized and rearranged and for columns to be shown and hidden. The column state will be a record (transparent or opaque) that can be saved into the program’s state and restored on next use.

Being able to character-align values will also help, for example decimal alignment (aligned to the decimal point or decimal comma) and simple unit alignment (to the right-most space character).

Ideally, all columns should start out at a sensible width. Whether the default width should be to the column heading or column contents is not clear, as a column heading much wider than the column values wastes space, but sizing the column according to its contents would then truncate the heading.

A system of hierarchy with selectable expand and collapse as used in Sysinternals Process Explorer will be availlable.

This control or control family must be sufficiently capable as to avoid as much as possible programs needing to reinvent it over and over. This will never be fully possible but sufficient examination into existing software should help reduce its necessity.

Sorting

Column sort will rely on either callbacks or internal sortable values to accommodate sort orders that are not directly alphanumeric, such as dd/mm/yyyy dates. One or more columns can be locked into place at one side to ensure that row headings and related data remain visible even when the table/grid is scrolled to the right.

Using complement-click (see under pointing devices) on a column heading will append a subsort: the data will be sorted by the first normal sort (the initial sort or the most recent sort applied with the primary mouse button) and the sub-sorted by each addition column specified.

Validation

Potentially each control could provide a set of validation options, including the possibility of regular expression matching or a callback for greater flexibility.

Validation options include input type (integer, positive integer, positive integer or zero) and input limits (character limit, numeric limit).

Validation errors will prevent a form from being submitted, but switching tab within a dialog box will emphatically not be blocked by the control validator, as this is needless and extremely irritating.

Disabled controls

In present designs, there is no visible difference between the following:

• A disabled control whose value is not relevant and will be ignored, but remains set as such so that if you make a change that re-enables the control, the prior value is not lost.
• A disabled control whose value is relevant and applicable but cannot be changed due to restrictions imposed by other controls.

As such, a user cannot immediately (if at all) determine whether a control’s value is active or not.

Further, as noted under the GUI: experience page under command availability, it is not necessarily clear why a control is disabled, and what the user needs to do to be able to make it available.

General behaviour

Where a check box or radio button enables another control, setting the check box using the mouse ought to automatically focus the control that was enabled. This is not viable with radio buttons under keyboard control, as it stops you from cycling through radio buttons.

Backwards compatibility

A major factor in homebrew controls is the lack of backwards compatibility in control libraries. Should it come to light that a more advanced control is needed, programs will only be able to adopt this control so long as it is also available in whatever older versions of the OS are still being used. Having the graphical controls library be a package in its own right would allow updated versions of the library to be made available to older versions of the OS, so long as the library remains fairly independent of the OS version, since it won’t be able to rely on any other new features that have been introduced since.

Forwards compatibility will not be required, as both versions of the control library package will co-exist and each program will receive the most suitable version.

Staying ahead of the curve

The control library is perhaps the most important part of a graphical system for staying ahead of the curve. The other major factor in homebrew controls is when application software needs to make demands of the control library that have not been met by the OS vendor.

There are multiple approaches to dealing with inadequate controls. Depending on the implementation, it may be possible to create hybrid controls by combining existing controls to simulate the control type needed. On classic Mac OS, combo boxes were commonly achieved by placing a list box next to a text box, and making the list box only the width of its drop-down arrow, using it only for its menu, and copying the contents into the adjacent text box. This technique is fragile as it abuses a list box control in a way that it was not designed to be displayed or used.

Again dependent on the implementation, it may be possible to “subclass” controls, by introducing behavioural modifications. This can be dangerous depending on the extent to which this is formally supported, and to which such overrides will continue to work as the control implementation evolves.

Finally, developers can build completely custom controls, using the visual primitives offered by the control library. These will be the most robust implementations but at a cost of not matching the behaviour of any native implementation that may be introduced at a later date.

It will never be possible to think of every control type that may be necessary, but greater consistency will be achieved by researching the kinds of controls used in existing software and ensuring that the same objective can be met with some form of control, even if not visually the same.

A robust subclassing system allowing for fully legitimate and supported control enhancements will also help.