That vision thing

So, after about two week days of work (and an extra weekday of post typing), here’s where I’ve ended up on the vision front. It’s exactly 50 words long, and I think it does the intended job pretty well. Clarifications about the various keywords will come after the break.

TOSP aims to provide a seamless work experience, by optimizing for simplicity, flexibility, reliability, automation, good manners, and quality software development. Having only ~6 years of development at a dozen work hours per weeks means it’ll have to be very efficient. Leveraging the proximity of the initial public should help.

Here are the details regarding what I meant with each keyword here:

  • Seamless: What is the difference between a good screwdriver and a bad screwdriver? Build quality itself only plays a role if it’s very good or very bad, but in the middle of the quality spectrum, what really makes the difference is how quickly and smoothly you reach your goal. If the screwdriver keeps going off the screw and damages it in the process, if a low-quality grip hurts your hand, and if you need an hour to get that screw to do what you want, then it’s time to buy a better screwdriver. Similarly, I wish computer software, including OSs, could make the trip towards my various goals as fast and painless as possible.
  • Work: We already know how to build OSs that are pretty good at entertainment. If all you want to do with a computer is play games, watch movies, and listen to music, the current-gen desktop and mobile platforms cover these use cases pretty well. On the other hand, I think there is a lot to improve in the area of productivity, when the main goal is to produce content instead of only consuming it. Here, most modern platforms don’t even support the basic concept of data interchange very well, and solely focus on touchscreens at the expense of the finer-grained input methods that become useful at later production stages. Thus, I think this is an area where there is research to be done for TOSP.
  • Simplicity: Complexity is not an enemy when handled properly. But when software ends up treating niche use cases and tiny details better than they handle the common use cases and the big picture, then there is a problem. I believe that in that sense, all productivity software should follow the example of Paint.Net: easy to learn for beginners, optimized for common tasks, and yet remarkably powerful under the hood. In modern software, I often feel a large gap inbetween “drafting toys” and “obscure professional software”, and I don’t think that this is a healthy dichotomy to endorse.
  • Flexibility: There’s a lot of diversity in personal computing today. We have workstations with enough horsepower to process and encode 4k video in real time while streaming it to multiple gigantic super-high-resolution displays, handled using weird 3D input peripherals, and we have tiny cellphones with hardware from last decade and a numeric keypad for input. Similarly, users exhibit a wide range of body capabilities and specializations. I accept the idea that there is such a thing as reasonable minimal requirements (for visual work, a large enough screen, an optional high-resolution input peripheral, and a good enough user eye come to mind). But I also believe that the diversity of personal computing is something that should be embraced, rather than feared or artificially limited, by the authors of OSs and software.
  • Reliability: Who has never lost a significant amount of data to a software bug, at a time where he didn’t exhibit the compulsive file-saving disorder that characterizes experienced computer users? How about losing a hard drive full of precious data to a nasty virus? Stuff like that really should not happen. In TOSP, I want to make various experiments towards treating user data and software uptime as a resource of paramount importance. That includes holding resilience to software bugs and security exploits to high standards, but also prevention actions through enforcement of good practices like backups and software sandboxing among users and developers.
  • Automation: Every periodic maintenance task should be automated, and ideally be performed in a perfectly silent fashion. Be it backups, software updates, or trash cleanups. Users should only get involved when such involvement is truly necessary. As an example of such good practices, there is a Linux backup tool called Deja-Dup, which can make scheduled backups of selected folders. If the backup drive is not plugged in at the right time, a short notification will pop up, stating that the backup will begin once it is connected. For a comparison, other backup software which I know of would either fail silently or display an incomprehensible error message. As such, I thought that this was a really good design, as should be expected for such a common use case
  • Good manners: There is a level of etiquette to be expected from software, as with any other entity that serves the human race. Software should take responsibility for its failures, even when it is able to partially recover from them. It should neither hide power away from its master nor try to govern him. It should be polite, and speak a clear language for its intended audience. It should, when possible, notice and point out possible problems before they happen. Software should not drown notification channels with pointless statements, nor refrain from communicating about truly important things. For the later, splitting notifications into multiple classes and letting the user choose which he wants to see could help with the problem of varying user interests.
  • Quality software development: OSs do not exist in developer vacuum. They are a platform upon which software can be built, in order to extend said platform’s functionality or hardware support. A core goal of OSs should be to ensure that every software developed for them is held to the same design principles and quality standards, so as to improve consistency and overall platform quality. Consequently, all interfaces between first-party and third-party code should enforce the same principles defined earliers, and any developer documentation such as coding tutorials should also put a focus on these principles along to and within its code examples. Beyond this focus on quality, software development itself is a task which should be treated as a first-class use case and held to golden usability standards, since developers who are treated well are likely to write better code and enjoy the task more.
  • Efficient: Here, efficiency means that I have to focus on what’s important and necessary, and avoid the temptation to jump on unimportant or unnecessary but tempting stuff. It also means that I have to make clever use of my development time, as an example by embracing development methodologies that make me go faster to the goal with less trial and error.
  • Initial public: For as long as I can envision, TOSP will start by being used by computer OS enthusiasts and relatives of these, who are frustrated with nowadays’ productivity OSs like me. This means that I’ll keep in fairly good contact with said user base. I shouldn’t hesitate to use this opportunity to perform frequent usability tests or carry out in-depth opinion polls on anything that looks like an important matter of debate.

3 thoughts on “That vision thing

  1. Brendan April 20, 2013 / 3:22 am

    But will it revolutionize rich synergies, reintermediate customized architectures and productize frictionless systems?

    :-)

  2. Hadrien April 20, 2013 / 7:59 am

    It was to be expected that the 50-word constraint which I set on myself would lead to some buzzwording :) But I feel that such a constraint is necessary so that the thing remains easily readable, and if you have the explanations which I’ve given below in mind, things remain pretty clear and not THAT far-fetched. I’ve seen most of these practices in action in other software, although never everything at once.

    The only guy which really worries me here is the software development bit. I’m not sure how, an an OS maintainer, you can lead other developers to do what you want, without going Apple and locking down software distribution channels. I have some ideas revolving around (ab)using sandboxing towards that goal, such as by flagging software which doesn’t use the system state-saving mechanisms as potentially dangerous for user data, or pointing out latency issues as “run-time warnings” during debugging, but I don’t think everything can be automated this way.

    And then, of course, there’s the issue of time. Lovely time, precious time… Sometimes, I do wish I lived in an era where it’s possible to make significant money out of homemade OSs and software alone. But then, I guess I’d miss physics research after a while.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s