Jump to page content

Standard input

Caveats

Most if not all pages are just rough notes, and these pages as a whole are far from complete. More notes will be added in time, eventually, maybe.

If, from reading these notes, you conclude that I am off my rocker, you won’t be the first, and you may even be right. These pages may simply position me as an acolyte to the late Gene Ray.

No doubt there are a dozen and one reasons why none of this would ever work, but perhaps somewhere deep down there is a tiny fragment that could be used for something.

Contents

Overview

There are various stock forms of input that need to be made available in some form. Exactly what form this takes depends on the outcome of the considerations noted on the dialogue page.

(This is the site’s second pun on standard input.)

Standard inputs

In theory, inputs could be presented as object-orientated class interfaces, such that so long as the input implementation accepts the correct specification and returns the correct data, the actual presentation is not relevant. This works fine with a single-design system but fails when programs expect to customise the inputs in ways not supported by the interface.

Colours

This is deceptively simple. The user will be given the ability to choose or amend a colour. The result will be a colour. The format of the resulting colour, however, is not so easy to define. The standard colour model is 24-bit RGB (also known as 8-bit colour, denoting eight bits per channel, not the old 256-colour palette-based system). What would happen if one wished to expand the input to include alpha channel, or directly return another model such as HLS, CMYK (for print work) or OKlab (for the Web)? How would 10-bit colour be supported? This will depend in part in the language framework adopted.

The input itself should accommodate a reasonable number of options, for example CMYK, HLS, HSV, etc. Colour selection should be based on the OKlab mathematical model so that colour blending works properly.

See Colour Selector for a compact colour selecting and mixing tool that offers multiple custom mini swatches. Should the colour input support custom swatches and, if so, a single one (like the Windows colour dialog box) or multiple named swatches like Colour Selector? Should the swatches be program-specific or user-specific, or either/or?

There is a lot to consider when creating a standard colour input feature.

Files and folders

This will include:

There are lots of questions raised by this alone. On Windows, files not matching the specified filter are hidden, which leads to user confusion. The change from (for example) .doc to .docx in Office would cause Save dialog boxes to show empty folders where existing work should be seen, as no files had yet been saved under the new format. The Macintosh simply disabled and dimmed any files that did not match the filter; this had the side effect that the user could not click an existing file to capture and re-use its name.

There are lots of sub-features that such inputs could support, including (and not limited to):

When a program supports choosing multiple files (or even folders), the UI must make this plainly clean (Microsoft Windows does not).

It is common for programs to wish to customise such inputs, for example to show a thumbnail panel or customisation options when saving a file. Where possible, these behaviours should be made native so that they are consistent between applications and do not need to be injected into the window. This will require a whole investigation into itself to see what behaviours are not suitable for standardisation and how such necessary customisation should be implemented in a way that minimises the fragility of such customisation, i.e. to allow the underlying window to be improved without breaking the customisation.

Fonts and styles

This is also deceptively simple, even more so than colours and files. The more advanced the software, the more advanced its typography and presentation will be. It is not going to be possible to provide a standard font input that caters for what all developers may need of it. There is also the matter of the input offering formatting choices that are not possible in the underlying implementation, e.g. strikethrough and double underline in software systems that cannot show such formatting.

To some extent, it may be that a flags field is needed that selects which formats are to be eligible for selection.

One reason for wanting to centralise the font input is to accommodate typographic management, e.g. proper handling of type families and support for user font sets. Another consideration is that Unicode is often supported by way of culture-specific typefaces, and the user may wish to be able to filter the fonts by locale. Users may also wish to filter fonts by style family.

As much management as possible should be centralised so that developers are not required to continually re-implement it.