Skip to content

TOSP-wide plans, part 2: Everyday life

June 30, 2013

Following upon my previous post in this series, regarding how to optimize the first contact between potential users and a finished TOSP build, this post will introduce a first batch of user stories regarding what everyday TOSP use should be like. In effect, it can be considered as a short summary of what was discussed in the past few months on this front.

Edit: Oh, and since moving existing documentation to GitHub would be premature as long as I haven’t defined what the current plan is, I have taken the “migration in progress” post away from the front page.

An UI that is responsive, efficient, and powerful

  • When the computer is turned on, user wait should be minimized
    • This involves minimizing boot times, by keeping the boot process minimal and providing a usable environment as soon as possible
    • Early log-in would also allow users do something else during initialization
  • Reboot should only be necessary upon microkernel updates
    • All other system processes should support on-the-fly updates at run time
    • Future releases could remove the requirement from kernel updates too
  • The UI should provide access to user data, system controls and applications
    • User data is everything that is stored on a user-accessible storage device
    • System controls direct application-agnostic settings such as screen brightness, sound volume, safe disk removal or network connections
    • Applications which are not designed to be used directly should be hidden or left in a power user-specific corner (think “Advanced” buttons)
  • It should do so in an understandable, predictable and helpful way
    • Understandable means that it is clear what each control does
    • Predictable means that it will always do it in the same way
    • Helpful means that the chosen way of doing things is efficient, powerful, and respectful of the user, in compliance with basic usability rules
  • Items which are likely to be accessed should be directly accessible
    • Users should have the last word regarding which items are put on display
    • But automated machine assistance is a plus, if it can be done right
  • Just like for boot, users should not wait for system response to common actions
    • UI latency should remain below the human perception threshold (10ms)
    • This does not mean that all tasks should be performed in 10 ms, only that UI controls should have “answered” within that timeframe
    • Though in general, the more common a task, the faster it should be done
  • Non-UI tasks which take time to perform should display progress indicators
    • UI can, if necessary, automatically show “spinners” after some delay
    • But above a few seconds, precise progress indicators become necessary
  • Precise progress indicators should not lie, even for very long tasks
    • Multilevel indicators are better than running through a progress bar twice
    • Observed progress should grow at a relatively regular speed. If remaining time estimates are displayed, they should be reliable
    • The indicator should grow smoothly, and neither stop before the maximum value nor remain at this point for a perceptible time

Optimization of work scenarios

  • Software should be considered as a disposable mean to an end
    • Thus, software perfection will be achieved when users cannot tell which software they used to achieve some goal
    • For this to work, paths to developer recognition other than fancy in-your-face user interfaces must be investigated
  • Users shouldn’t need to care much that they are using a computer
    • Thus, any computer maintenance task, down to basic things like file saving or data backups, should aim to be fully automated
    • As many automations will require some set-up procedure, perhaps it’s a good idea to centralize them in a single system-wide setup procedure
  • Computers’ superior abilities should be used to serve users, not distract them
    • Background software notifications should thus be appropriately prioritized, remaining very subtle in the common case
    • On the flip side, design emphasis should be put on the way computers can do things better than other tools for a given job
  • The current lack of reliability in consumer software should be adressed
    • First law: Software should not harm user data, nor let it exposed to danger
    • Second law: Software should follow orders when allowed to by the first law
    • Third law: Software should strive to keep running, recovering automatically from errors, to the extent permitted by the first and second laws
    • I believe that this can be achieved through application sandboxing, and by providing abstractions for automatically saving fresh input data
  • Saving current work should not be limited to locally edited files
    • As an example, think of how modern web browsers can recover opened webpages on a crash, but available down to single page granularity
    • Could technically be based on fine-grained application state saving
    • From a usability point of view, such saved states could appear as files, but how a user should create one still has to be investigated
  • “Saving” and “loading” multi-application workflows should be investigated
    • In a nutshell, take a bunch of opened windows, associate them to a single “work file”, restart the computer, and be able to recall all of them at once
    • Technically, once you have fine-grained state saving, it’s quite easy to do this, the problem lies in how to present such functionality in the UI
  • In general, improvements in multi-application workflows should be investigated
    • These are good for usability, because packing everything and the kitchen sink inside of a single UI invariably makes it hard to grasp and use
    • They are also good from a technical point of view, because small programs are easier to write, debug, and improve upon
    • The goal here is to take cross-application interoperability and UI coherence beyond the basics of copy and paste and drag and drop
    • Think of a modernized UNIX workflow : data pipes, applications scripting one another, all that in a package that is usable without using a CLI
  • Application updates should be a perfectly transparent process
    • Perhaps some sort of software certification would be in order here, since some third-party developer involvement is required on this front
    • “Level 0″ applications might have issues if they are updated while running, or randomly break backward compatibility with their own files
    • “Level 1″ applications silently receive updates that are applied on restart, and promise in writing to provide backward compatibility for N years
    • “Level 2″ applications are updated on-the-fly, as they are running, without state loss or significant UI lag during that process
About these ads

From → OS development

One Comment

Trackbacks & Pingbacks

  1. TOSP Quarterly, issue 2 | The OS|periment

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

Follow

Get every new post delivered to your Inbox.