Things which operating systems should be doing
I've thought a lot about the operating systems I use or encounter, mostly in the context of frowning upon unfriendly, inconvenient or antiquated behaviour and feeding my stack of inner hatred. As such, the following will likely have the undertone of a bit of a rant, but it is nevertheless presented as opinion with reasoning in the usual manner.

This is not necessarily a list of items which all modern operating systems are lacking. Indeed, some OSs may already satisfy a given item completely; the point is that not all do, and I believe these should be universal.

1. The function keys, at least in part, should be exclusively user-programmable.
  • As a suggested 'split', F1-F6 could remain as they are with any application able to respond to them, and F7-F12 would be reserved.
  • The reserved function keys would be completely undetectable by applications unless the user grants global or application-specific access.
  • The user can assign their own macros or actions to the reserved function keys.

I've noticed a problem which has emerged - background processes which are supposed to respond when an assigned key is pressed, but the foreground application itself responds to almost any possible choice of key one could make. Some examples of this would be taking a screenshot, switching scene while live-streaming, a push-to-talk button for VOIP, etc. Obviously the function keys don't have the best position for a push-to-talk, but the concept stands - I see many people using Ctrl or middle-mouse as a push-to-talk, and they inevitably end up zooming the document they're trying to scroll while speaking.

It would be difficult to achieve now that the twelve function keys are standard and applications exist which respond to them, but I do see room for improving usability if it were commonly understood that a few of them are reserved. That is, of course, without adding some non-standard buttons - by virtue of the application not being able to assume the presence of a given button, there will be no hotkey shortcut assigned to them by the developer. For this reason, I enjoy using gaming/programmable keyboards greatly (currently a Logitech G510S and previously a G15 v1).

In general, it would be nice to have an easy way to tell the OS that a specific keyboard button has been commandeered by the user, no longer performs its regular task, and now does exactly what the user wants it to do. Then, if you literally never use caps lock and you need an easily-accessible push-to-talk, the problem is solved.

Speaking of push-to-talk mechanisms...

2. The user should be able to command the OS to disable any source of audio or video input with a configurable button, both bistable and monostable.

'Sources of audio or video' are microphones and webcams. 'Monostable' is push-to-talk behaviour, and 'bistable' would be a latched toggle.

The idea here is to keep the user in perfect control of exactly when they are transmitting. At the moment, one has to rely on such functionality being built into individual programs, but it seems simple enough to me that an application which is listening to your microphone when you think it isn't or shouldn't can be trumped easily if the OS has a means of preventing the audio from being recorded at all.

More simply, if the application is just not very good (like Skype), you don't have to mod it for the sake of adding a PTT button. Skype were saying for ages how there was no demand for that, while dozens of gamers flocked to Ventrilo, before finally attempting to add it but managing to cock it up such that holding the button would mute instead of unmute. Don't use Skype.

Of course, one would have to be able to trust that the OS itself is indeed muting the microphone/camera, an issue where open source has a strong advantage. Basically, don't use Windows 10 either. The claim that its privacy intrusions can be disabled is worthless on the mere grounds that one cannot trust the setting options to do what they say they do; I don't even need to bring in the fact that it still calls up Bing when you search the application menu even with everything disabled.

3. The user should be able to copy (to the clipboard) any text rendered by the OS.
  • In particular, copying error text from a message box when using the mouse does not select the text by default.

If the user wants the rendered text in a transferable format, such that they can put it into an instant message or a search engine, they are going to achieve that goal by some means. An assured means exists; simply reading and re-typing that text into a text editor. At that point, since it is pointless to entertain the notion of preventing the user from copying the text for any reason, the OS might as well provide a more efficient method.

I am aware that some message boxes will respond to a Ctrl+C command by dumping their complete text onto the clipboard, but this behaviour is somewhat concealed and definitely not universal.

4. The OS has complete control over whether an application is allowed to be full-screen.
  • All applications are forced to open in a window by default.
  • A standard window option, next to minimise/maximise/close, allows the user to choose full-screen.
  • The user can specify individual programs which open full-screen by default.
  • By default, if a full-screen application refuses to match the native screen mode, the OS scales the image to fit.

Programs which are currently full-screen by default, especially games, have been causing inherent problems since the beginning and continue to do so now. Even if the automatically-chosen screen mode works fine, the program can still cause a hang if it attempts to connect to the internet and is stopped by a software firewall. Of course, even if it displays a pop-up with allow/deny, the full-screen overlay can obscure that and leave the user stranded. Good programs at the moment will have a separate launcher which gives configuration options, but in general it would prevent a lot of issues if the OS could just lock it in a window by default and let the user make it full-screen afterwards, with a functional escape route if needed (e.g. a 'task manager' key combination).

5. All windows should have resize, minimise, maximise, close, and a keyboard-accessible system menu which includes all of those features as well as keyboard window movement.
  • No windows should ever move or resize automatically without explicit permission from the user.
  • 'Always on top' should be a standard feature provided by the OS and operated only by the user.

Currently, at least in Windows, programs can decide selectively which of those buttons are available. This is a terrible situation; denying any of those to the user only serves to break an otherwise-consistent UI experience, and to frustrate the user. If the user resizes a window to smaller or larger than intended, it should be handled by the application using various techniques such as providing scroll-bars or resizing the content.

The keyboard operation is important in case of hardware failure. This could be direct failure of the mouse, but also applies to monitors; if the user has a dual-screen setup, and one monitor fails, the keyboard can be used to recover open programs from that monitor to the working monitor. Standard windows in Windows have this feature, albeit with a slightly convoluted key sequence (Alt+Space for the menu, M for move, then the arrow keys to move the window), but certain non-standard programs (such as Winamp) do not.

6. No window should ever appear atop a focused window, nor be able to take focus automatically.
  • Only user actions such as task-switching should cause a focus change.

Classic scenario - typing in a password on a website and an instant message chat appears with the reply box focused, and half your password ends up in the chat. Alternatively, just typing regularly and a yes/no dialog box appears pre-focused with Y and N as hotkeys for making a choice.

7. Modal dialogs should not prevent the user from moving parent windows.

A modal dialog is one of those child windows spawned by a parent application, where the parent window becomes locked while the dialog is open. Any attempt to focus back to the parent window will be ignored, and the title bar of the dialog window blinks rudely at you. The idea is understandable from the point of view of enforcing a particular work flow within the application, but is somewhat unhelpful when you still need to see the information in the parent window. With no forcible method of sliding the parent window out from under the dialog, you have to close the dialog, pre-move the parent, then re-open the dialog.

I've seen Linux allow this usage, and I must give a deserved mention to RISC OS (if anyone remembers that!), which in general let the user slide windows around without affecting their foreground/background order.

8. Optical drives should open/close when and only when the user presses the physical eject button on the device.

I haven't seen this problem for a while now, though Linux has historically had the shameful problem of preventing the user from ejecting a CD. I even understand the reasoning for that - the CD as a file system has been mounted, and one or more processes have an ongoing I/O operation which includes files on the removable medium. The problem here is that the eject button has one purpose - for the user to express a wish that the disc be ejected immediately. If some processes choke on an I/O error because of that, too bad, they need to handle it or be criticised as being poorly-made.

Of course, this is a two-way understanding - if the user wants to eject a disc during a write operation, the user has to accept the possible outcome that their file does not get saved. This is absolutely fine, as long as the computer as a whole does not have the insolence to defy such an explicit request from the user.

I do understand that optical drives are on the way out. Ironically, the replacement technology has a particularly nasty problem of its own...

9. When an input device is connected, the OS should inform the user that an input device has been connected and give the user reasonable opportunity to disconnect the device before any input from it is accepted by the OS.
  • To hasten the process, the user is able to use an existing, connected input device to enable the new input device without waiting.
  • For convenience, the OS remembers which specific physical ports have existing input devices, and allows a free pass on next boot-up to input devices on those ports.

This is entirely targeted at good old USB, and the problem here is not just any flavour of bad, but actually one of the worst possible security issues ever to exist within the subset of attacks which take advantage of physical access to the computer.

USB devices will report to the host some information about which type of device they are. There is an 'other' category, which is a way of saying that a custom/bespoke driver package is required, but devices such as keyboards and mice have their own standard type IDs which allow most OSs to understand their input (at least in some capacity) without additional software. The issue here is that there is nothing to stop an item which appears to be a memory stick from claiming to the host that it is actually a keyboard, and proceeding to send key commands automatically. It could also claim that it is itself a USB hub which has a keyboard and a memory stick connected to it, and this dummy keyboard could send commands to copy and run an executable program stored in the flash drive.

This is a nasty attack, in that it is so simple and OSs offer zero protection against it at the moment. If the OS would use a bit of caution before accepting a device as being a keyboard or a mouse, I would approve greatly.

Related note - never connect your mobile device directly to an arbitrary USB port when you only want to recharge its battery, especially when the USB port is in a public place and advertises itself as a station for recharging mobile devices. You can't see what the USB host is doing, and it will start reading your data. The solution is to get yourself a USB Condom, which you connect between the host and the device, with the effect of allowing the device to charge but leaving the data pins dead.

10. If an action is denied due to user permissions, the user should be given an opportunity to grant elevated permissions without interrupting the action.
  • This may also include logging in as a super user until the action concludes.

This amounts to the confirmation box on Windows systems which you see when changing system settings, amongst other activities. This could be improved by categorising the specific permission needed by the application, given that Windows currently has a single elevated level which gives just the application all permissions.

Linux has improved somewhat, in the sense that it often gives the opportunity to enter a password to confirm a sudo-type action in its settings UIs, but some tasks can still crap out at inopportune moments if they weren't started as root (or a 'sudoer') from the beginning. Of course, this depends on forward knowledge that the permissions will be needed. For me at least, this continued for years until I discovered the command sudo !! relatively recently (re-run previous command as super user), but having a program or script repeat an initial set of actions just for the sake of running it as root this time around is less than ideal.

Finally (for now?)...

11. An OS should never download or apply an update automatically unless requested/scheduled by the user.

Aside from the issue of this behaviour counting towards any data transfer limit the user may have, and that automatic updates have an uncanny ability to apply themselves at the worst possible times, the 'update-culture' really needs to get away from 'latest and greatest' and start thinking "I need to be absolutely sure that there's no devious shit in this update, and that it works properly and won't ruin my files if I apply it; better hold off for a bit". It's not so bad when the item being updated is something easily replaceable such as a browser, but in general no sensible human would choose to update something which is already adequately secure and performs all of the tasks they need without fault; there's simply nothing to be gained from it other than unnecessary exposure to risk.

Another related note - definitely never use a video driver if it was released only in the past few days. Unlike many other pieces of hardware, the video card has microprocessors with voltages and clock speeds which have safe operating ranges just as the host PC does, and the only thing preventing it from melting itself is the driver. Some early Linux tinkerers managed to destroy their video cards in that way, but if you're thinking it would never happen with an official driver update... it already did.

As likes to say, newer is not always better.
Comment thread »
Your caution about the recharging mobile devices via public USB ports is exactly why for charging purposes I don't plug mine into anything except an electrical socket, and for on-the-go needs have the adapters in my car, office, and backpack specifically for these situations. I also store addresses only in my non-hackable hand-written paper Rolodex and dump all the photos from my phone on a regular basis (I had a colleague years ago who had her phone stolen one day, and was absolutely spastic because apparently it had compromising photos on it that she was terrified would be leaked to the world. Why anyone is daft enough to keep photos like that on their phone, carrying them around everywhere, is beyond me).