Operating system design principles
Caveat
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.
No doubt there is 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
Several principles underpin all the design intentions. Stating goals is the easy part. Unfortunately, the software industry is driven by greed, incompetence, pride, arrogance and stupidity. Consequently, each facet of the system must do its best to ensure that developing high-quality software is easy. This means that the software development tools must guide developers towards correct practices, and each subsystem must be at a high standard such that there is no reason to sidestep it.
Accountability
The primary principle is accountability. The user must never be left playing stupid guessing games about their computer. All operating system tools and included applications at an absolute minimum must have the highest standard of error handling and error logging. The UI must ensure that the user is never in doubt as to whether any keyboard or mouse command was accepted. A good counterexample: it’s not uncommon to choose an item from the Start menu in Windows and watch while nothing seems to happen, as the start menu appears to simply ignore the request while the program is being launched. Either the menu must immediately close, or some visual cue must be shown to indicate that the command was accepted, for example a busy symbol or (as seen in Linux) a taskbar button added in advance.
Where possible (and not including the Web), refresh will not be necessary in any application.
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:
- The nature of the failure, e.g. “file does not exist”
- The subject of the failure, e.g. the path to a missing file
- 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
- 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.
Consistency
An installed system must present the minimum cognitive load to the user. Computers can never be easy again due to the proliferation of hardware and protocol complexity, but they can at least reduce the user’s mental workload as much as possible. Key to this is maintaining the highest level of consistency so that users need to learn each task only once and apply that process to all applications.
All terminology will be consistent, both in principle and in practice. The semantics of terminology will indicate the nature of what is being described: the names of system components for example will reflect the nature in which they function. (Some component names listed within these notes will change if the components change in implementation between a process, a shared library or a kernel feature.) No option or command will appear in two different places with two totally different names, as the user will not know if they are two different options or commands, or the same option or command duplicated under confusing terminology.
Discoverability
The graphical user interface should be as self-evident and thus as discoverable as possible.
Process discoverability
Given a particular task to solve, it should be fairly apparent to the user how to complete this process within the graphical desktop environment. In particular, this requires a small number of high quality tools instead of a myriad of confusing ones. Searching the Windows Start menu for “System” returns the bewildering System Information tool which is not really of use to anyone (compare the far superior Apple System Profiler). System Information competes against Device Manager, the latter having management capability but very little in the way of useful information on devices. Device Manager in turn competes with the inaccurately-named Devices and Printers which has a faulty notion of what a device is (since most of them do not appear). Unlike Apple System Profiler, none of these let you view USB connections, and thus none of them allow the user to understand what is connected to the computer, as each USB device can have multiple endpoints. Devices and Printers competes with even less helpful Settings panels in Windows 10. Instead of improving any tool, Microsoft just add another, and another, each one still only able to do part of the job. There is no real overview of devices in any meaningful sense. Hilariously, the computer itself is a device inside Device Manager. Even in Devices by container mode, Device Manager is full of complete gibberish entries and meaningless categorisation.
Data discoverability
In addition to discovering processes, the user should be able to discover all the relevant data belonging to the system. Getting a list of installed programs on the command line should be a trivial and reliable process, for example.
Flexibility
Even though there will be only one permitted default configuration (unlike the myriad of competing Linux distros that are impossible for anyone to make sense out of) the user must also be completely free to customise their system to the maximum extent possible. This demands a level of abstraction between system processes (such as window management and system configuration) and the tools that users interact with. Although nested packages with complete replacement user interfaces are perfectly acceptable, each aspect of the default GUI can be swapped out individually for any available replacement tool.