Problem statement and objectives

Setting the options of an app raises a difficulty which is neither technical nor linguistic: the person who sets them is not the person who wrote the app. She is handed a few values to decide — a threshold, a window, a language, a file of correspondences — named in a few words by somebody who knew what they were for, and she has to decide them before anything runs. What each of them does, what happens above or below, and what was there before she touched it are not hers to know, and today they are not shown to her.

The central problem addressed here is thus:

how to let a person set what an app will do, when she did not write that app — making every value intelligible before it is given, and reversible after.

The difficulty is sharpened by three conditions. The options are declared by the app and not here: one app offers three, another twenty, and an app written by somebody else offers whatever its author chose, and none of them is known in advance. They are typed but not bounded: nothing says that a threshold is a duration, that a duration is in seconds, or which values are absurd. And the same must serve where SPPAS runs on the machine of the person and where it runs on a server, a difference which is invisible until an option asks for a file.

There is material to work with, and it is already written. Every option carries a short text and a long description, both written by whoever declared it. The interface which exists today shows the first and has never shown the second.

That is why this is designed again, and not translated. Turning the wx panel into a web page would carry that silence over with everything else: a list of widgets, one terse label each, no way back to the value which was proposed, and a dialog which opens on a machine which may not be the right one. What is unsatisfactory there is not the toolkit, and changing the toolkit would settle none of it.

The objectives follow:

• to show, for every option, what it is for — in a few words, and at length for whoever asks — using what its author already wrote;
• to show the value which stands, before anything is touched;
• to give, for each kind of option, the thing which suits it, and to say that a value cannot be used at the moment it is given and not when the app runs;
• to let the value which was proposed be restored, for one option or for all of them, without anybody having to remember it;
• to serve an option which takes a file as the others are served, wherever that file stands and wherever SPPAS runs;
• to keep what was set from one time to the next, so that it is not set again;
• to guarantee accessibility, of what is shown and of what is operated.

This runs nothing, does not know what a value means, and does not judge which values make sense together: all three belong to whoever declared the option. It aims at one thing — that setting an option be a decision taken with what it takes to take it, rather than a number typed into a box.

Expressing the needs

The needs below come from two places: what the apps already declare and what the interface which serves them today does with it, and what a person doing the work runs into. None of them is a need of a machine, and none of them says how it is answered.

Deciding with what it takes to decide

A person who sets an option is rarely the person who declared it. The few words which name it were written by somebody who already knew what it was for, and they are read by somebody who does not: window, threshold, shift say nothing of what they measure, in what unit, or what happens on either side of the value. Whoever declared the option wrote more than those few words — a long description is part of what an option carries — and it has never been shown. The need is therefore not to document the tool: it is to put what was already written where the decision is taken. And the value which stands has to be visible before it is touched, because a person who cannot see what she is changing is not changing it, she is replacing it.

Giving a value in the form it has

An option is typed, and the type is not a detail of storage: it says what kind of thing is being decided. A yes or a no is not a word to be spelled, a number is not a string which happens to hold digits, a file is not a path to be copied by hand. The need is that what is offered to act on matches what is being decided, so that a whole class of mistakes cannot be made rather than being caught afterwards.

What cannot be prevented that way has to be said at once. An app runs for minutes on a set of files; a value it cannot use, discovered there, costs those minutes and the person has to start again with no idea which of the twenty values was the wrong one. The need is that a refusal reaches her where she gave the value, and names it.

Coming back to what was proposed

Options are explored. A person who does not know what a threshold does finds out by moving it, and moving it is only reasonable if she can get back. Today she cannot: once the proposed value has been overwritten, it is gone, and nothing in the interface says what it was. The need is that the value which was proposed remains reachable — for one option, when she has spoilt one; for all of them, when she wants to start from a state she can name.

An option which designates a file

Two of the six kinds of option do not hold a value: they designate a file. An app which maps SAMPA phonemes onto IPA is given a file of correspondences, and that file belongs to the person — it is her alphabet, her corpus, her convention. In the interface which exists, a dialog opens on the machine where that interface runs, which settles the question by making it invisible: the two machines are the same one.

They are not the same one when SPPAS answers from a server. The file is then on a machine which is not the one which will read it, and designating it is not enough. The need is unchanged for the person — to choose her own file, wherever it stands — and it is the need the provision of files answers, locally as well as online. It is named here, and it is answered there.

Setting once, running many times

An app is not run once. Somebody working on a corpus runs the same one on one set of files, then on another, then on a third, with the same options every time. Setting twenty values at each run is not a service rendered, it is an obstacle, and the person who meets it stops using the options at all and lives with what was proposed. The need is that what was set be found again as it was left.

This is a need of the machine of the person and of no other. What is set where SPPAS runs on her own machine is hers to find again; on a server, there is nobody to find it again for, and nothing of hers stays there.

Accessibility

Everything above rests on things being perceived: a label, a description, the value which stands, a refusal, the way back. Contrast, legibility, text alternatives, keyboard and screen-reader operation, and a stable terminology between what is shown and what an option is called are not qualities added to this domain: they are the conditions under which it does anything at all. An option which cannot be read is an option which was not offered.

Two of the needs listed below are not argued here, because they are the act itself and not a difficulty: that a person sets the options of an app, and that the value she gave is the one which counts.

Eliciting the needs

Eliciting the needs means turning them into things this domain names and shows. What follows is not a list of what the code will do: it is what the person is put in front of, and what each of those things is called here.

Concepts manipulated by this domain

Option

One thing which can be set. It carries a key, a kind, a value, a label, a description, and the value it was declared with. It is declared by an app and never by this domain.

Kind

What sort of thing an option holds, which says what suits it. There are six: a yes or a no, a whole number, a number with decimals, a text, the name of a file, the path of a folder.

Value

What the option holds at this moment. It is what is given back, and it is the only thing of an option this domain ever changes.

Declared value

The value the option was declared with. It is what « going back » goes back to, and it is never overwritten.

Label

The few words which name an option, written by whoever declared it.

Description

What that same author wrote at greater length. It exists, and it is what the interface of today never shows.

Refusal

What is said of a value which cannot be used, at the moment it is given, and about that value alone.

Container

The piece of page an app places in its own, holding the options it declared. This domain has no page: it has this.

One line per option, and three things on it

The need to decide with what it takes to decide is expressed by a line per option carrying three things and always the same three: what it is — the label, and the description for whoever asks for it; what it holds — the value, readable before anything is touched; and what it may hold — the thing which suits its kind, which is what is acted upon.

The order does not change from one option to the next and the three are never merged: a label which is also the control, or a value which is only visible once the control has focus, puts the person back where she was — changing something she cannot read.

What suits each kind

The last two are the ones which are not a matter of typing, and they are where this domain stops: designating a file is asked of the provision of files, which answers it on the machine of the person as well as from a server. What comes back is a file this domain hands on without opening.

The value which was proposed, and where it comes from

An option does not carry it. What an option holds is one value, and changing it overwrites what was there: nothing in what is declared today says what that value was at the start. The need to come back therefore cannot be answered by looking — there is nothing left to look at.

It is expressed here as the declared value: what an app hands over is not a value to be modified in place, but an option and the value it was declared with, the second being kept and never written on. Going back is then reading, for one option or for all of them, and it costs nothing.

This is the one point at which the elicitation asks something of the app rather than of the person. It is not a new kind of data: it is what the app already holds when it declares its options, and which it stops holding the moment it hands them over.

What is said when a value cannot be used

A refusal names the option it is about, says what was expected, and appears where the value was given. It never speaks of the others, and it never prevents them from being set: a person who has given nineteen good values and one bad one has given nineteen good values.

What is refused here is what the kind of an option settles — a number which is not one, a value outside the bounds an option states. What a value means, and whether it makes sense beside another, is refused nowhere here: this domain does not know it, and pretending to would make it the place where every app's knowledge accumulates.

Where the options stand when there are many (inferred need)

No person has asked for this, and it does not come from an expressed need: it comes from what the interface of today is. The panel which serves the options scrolls, in both directions, which is the shape a list takes when nobody knows how long it will be. An app which declares twenty options gives twenty lines with nothing to hold on to, and what is at the bottom is what is never read.

It is expressed here as a need which is inferred and stated as such: that the options of one app be given somewhere which does not require the person to hold twenty things in mind at once. Whether that is an order, a grouping, or something else is not decided by this chapter, and what decides it is what the apps actually declare. It is written down so that the day it is decided, it is decided on purpose.