Accountability

Contents

• Sub-principles
  • Documentation
  • Error handling
  • Scheduling
  • Session-level tasks
  • Hidden state

Sub-principles

Documentation

The user must always have access to relevant documentation, including proper explanations for each control in a window. Microsoft-style documentation—that states that a checkbox named “X” will “Enable X” without in any way elaborating on what X denotes—is wholly unacceptable: the documentation must explain each concept involved and provide guidance for the usage of each option and command including any notes on best practice or caveats.

Error handling

Error messages presented to the user must include as many as possible of the following important aspects:

1. The nature of the failure, e.g. “file does not exist”
2. The subject of the failure, e.g. the path to a missing file
3. The context of the failure: what the program was attempting to do when the error occurred, such as what type of file is missing and why it is needed
4. What the user should do (if possible) to correct the problem

Error messages that note only “File not found” are unacceptable, as the user does not know which file is missing, why the program was trying to open the file in the first place, and how the user can replace the file or instruct the program not to look for it any longer. Error messages that refer the user to contact a system administrator are also unacceptable, as the system administrator will not know what the error means either. If additional details are available that are too extensive to display interactively, these must be logged (and realistically, the original error should also be logged in case the user misreports what they read or conceals the existence of the error message) and the error message should note that further details have been placed into the application’s log.

Scheduling

All scheduling for all applications should (where possible) use the system scheduler so that there is (in conjunction with other related practices) a clear indication of the source of all activity that was not directly initiated by the user. There should never be guesswork as to why activity has occurred.

As a counter-example, Sage 50 Accounts in Windows has a built-in backup system that uses its own internal scheduler. This breaks the global accountability principle on the basis that the computer is performing tasks of its own accord without any clear cause.

The same owner tagging used with files (see under MDFS) should also be extended to scheduled tasks for global accountability and automatic clean-up.

Where there is already a background service (daemon) that is to perform the task, the message-passing system will allow for scheduled tasks to be defined (directly or via trivial scripts) as messages passed to the existing service to initiate a task.

Session-level tasks

Background tasks that are started within a user’s logon session (typically during sign-in) must all be defined in a single place. Windows has a proliferation of ways to launch a program on login, with ever increasing complexity and obscurity. There is no excuse for this.

Hidden state

Application and system state must at some level be manageable. This ensures in particular that bad state can be rectified as needed. Having centralised state management will help ensure that this is always the case, as there are often times when a program ends up in a confused or damaged state from which it is difficult to recover without being able to inspect and manage state or simply clear the program’s state. A common example is a window opening off-screen, although this will be addressed directly by the window manager. The same ability to manage state should be true of the operating system as a whole.