As discussed earlier, one of the major steps which I intend to take towards improved management of TOSP is to have more structured plans, built on four different time-scales: the whole project (several years), milestone releases (a few months), iterations (a few weeks) and everyday work. This allows me to use an appropriate level of detail at every scale. Here’s where I’ve ended up on this front…
It’s hard to predict what the future will bring, even with a very low level of detail, more than 5 years away. However, one thing which I can tell for sure is that due to the way women’s biological clocks are set up, and taking into account how far my girlfriend is in her own studies, I should expect us to have kids from 6 to 10 years away from now. When this happens, a look at other developers’ blogs tells me that any major project in my life is going to take a hit, and that I may have to stop working on the largest ones, like TOSP.
I do care about this project a lot, however, so I wish that at this point, I will be able to pass that project on to a younger person. But that won’t happen unless I manage to get it into a state that is advanced enough for the offer to actually sound attractive. Let’s be pessimistic here and give me a total time budget of 6 years to do that. If I end up with more, I know I’ll find a way to make use of the extra time anyway. 6 years is about 313 weeks, so assuming that I can keep up with a work schedule of 10h dedicated to TOSP per week, that gives me a work hour budget of about 3130h. It sounds like a lot right now, but I’m pretty sure that I’ll wish I had more many times in the future.
Now, let’s start to brainstorm user stories, and make it more clear why I have called the blog post you’re reading that way
Meeting the users
If we are to design things from a user-centric point of view, then we should start with the first occasion at which this OS and its user will make eye contact. Myself, I consider first impression to be even more important for software than for people, since if the first impression which a software leaves on its user is bad, chances are that this is also the last impression which it will ever leave. You cannot close and throw away people nearly as easily as software.
For an OS, first contact occurs at installation time. In fact, it can even occur a little bit before, if a technical user creates an OS installation media by himself. As far as TOSP is concerned, here’s what I think the key points of this encounter should be:
- TOSP should run on most work-oriented computer hardware of its days
- This entails that core functionality should only rely on standardized hardware interfaces, that are available everywhere
- Hardware requiring specialized drivers can be supported, but shouldn’t be required unless a task explicitly mandates it
- TOSP should be able to boot off at least one widespread external storage medium. Preferably a single one that works with every computer out there
- Today, USB pen drives would be the best fit, but this could change in the future (e.g. to some variant of SD card)
- It should be easy to generate an installation medium from the main productivity OSs of that time, and of course from TOSP itself
- Virtual machine testing is common these days, so a VM disk image generator could also be a good feature to have
- Like Linux LiveCDs, the TOSP installation medium should be a usable copy of the system, having feature parity with an on-disk install
- Writable installation media should thus be favored: they help performance, usability and overall feature parity greatly
- Trying out the OS through the live session should be a first-class use case: no persistent slowdowns, no live session-specific bugs
- On today’s hardware, a longer initial loading period and a bit of wasted RAM are probably better than recuring lag
- At first boot, TOSP should let users perform minimal configuration (language, input, current time…), and hint at how further tweaking is done
- Such settings dialogs should be clear for first-time users, without being annoying for experienced ones. Only extensive user testing will tell
- The selection of settings to be adjusted on first boot must also be thought out very carefully. Not too little, not too much
- Once users have tried TOSP as much as they want, if they like it, there should be a readily available way to install it permanently on the machine
- Installation first involves making room for the OS on disk, either automatically or with a user-controlled partitioning layout
- It also involves copying the OS files. On-disk installs should mirror the live session which they originate from: no duplicate configuration
- Finally, the boot configuration should be adjusted, in a multi-boot setup, so as to let TOSP boot without breaking existing OS installs
- Since installation is not always performed by the end user, there should also be a way to flush personal data away from the installed OS
- Beyond mere testing and installation, it would also be nice to be able carry a live media around and use it on multiple computers as a “portable OS”
- For this to work, TOSP and its software shouldn’t care if hardware configurations changes massively across reboots
- Easy user data exchange between a live session and an on-disk TOSP install is also something to be considered if this idea goes anywhere
I think that with this, I have a pretty good picture of the all-important first user-OS encounter. With a few refinements, I also think that these brainstorming results could work pretty well as user stories (which is what I wrote them for, after all).
Next in my big TOSP brainstorming, I think I will consider the second user-OS encounter. And the third one. And the fourth one. More seriously, I’ll probably discuss what TOSP should do in order to be a pleasant work environment for everyday use. Unless another equally important subject springs to my mind more easily, that is.