So far the Freedombone home server project has been aimed at people who know how to use GNU/Linux and are not terrified by the sight of a commandline, but for the next release that's going to change.

The next release will have a simplified web based user interface suitable for the mythological "average user". The previous menu system will still be available, but will be for the more advanced users.

I'm not actually a web developer and my knowledge of front end web technologies is very limited. In a job interview not that long ago one of the interviewers berrated me for never having learned Django, saying something like "I do not find it credible that you have not learned Django yet and have not been making money doing that".

To avoid the mess of dependencies which many contemporary web apps appear to entail, for the Freedombone web user interface I've tried to keep it very basic and follow the principle of do the simplest thing possible. I decided early on to avoid javascript. Although it's popular, Javascript often isn't trusted and many people block it altogether with NoScript. So the software architecture of the new web interface is HTML, CSS, a small amount of php and a daemon in the background made with bash. The daemon does all the important stuff, like installing apps or making backups.

Experienced web developers will probably laugh at the crudeness of this implementation, but it works and should be straightforward to maintain. The design can be simplified because it's only expected to be used by whoever is administering the system, so concurrency of inputs doesn't need to be handled.

As a general principle I've tried to keep only a few objects on each screen of the web interface. This keeps the cognitive workload down and the number of things within the buffer size of biological working memory. If there's too much screen clutter then that will make it hard to use. I've stuck to a simple color theme which is hopefully high contrast enough for low vision, and the amount of wording on each screen is kept as small and as direct as possible.

A tricky part of the new user interface was the backup system. If you're running a server then keeping a backup of data is essential. The previous system required making separate keydrives and backup data drives and also included a LUKS formatting step. For a mass market type of system I thought this was too complex, involving too many steps and with too much chance for someone without scrupulous opsec to make mistakes. So I redesigned how backups happen. They're still encrypted with GPG, but the keys are stored on the backup drive and encrypted with a password. This means that it's possible to buy a USB drive, plug it into the server, select "backup" and it will work without any separate formatting step. If you leave the USB drive plugged in then it will make backups automatically once per day. If you later lose the backup drive then the password still protects the keys and therefore the rest of the data.

Another thing about passwords is that I've followed the existing policy of by default not allowing the user to select their own password. This is different from most other systems, including FreedomBox. Instead on first startup the system gives you a random password and tells you to write it down or store it in a password manager. I'm going on the assumption that if the user chooses their password they will choose the name of their cat, or password123, or something else which is trivial to crack.

I've also been rearranging the website such that it assumes a mass market type of deployment, with a mockup of a boxed product in the admin guide.

Whether Freedombone actually does become a mass market thing remains to be seen, but this is a first attempt at moving it in that direction.