Optimizing for work

As I stated previously, the main user-facing goal for TOSP is to provide a good environment for work scenarios, that is, the production of valuable content or services. Today, I would like to throw around a few ideas which I’ve been pondering in that direction, including older ones which I am reconsidering in this new light.

  • Reliability should be a given, with crashes that lose lots of data being an exception rather than a rule. No one can work efficiently with untrusted tools.
  • Distractions during work should be minimized. This includes reasoned use of notifications, adjunction of metadata such as priority so that the OS can best decide on if and when to deliver them, display of these through a subtle mechanism, and elimination of modal dialogs and other UI primitives requiring explicit user action or acknowledgement whenever possible.
  • Response to user input should strive to be instant (< 10ms), through clever use of real time constraints. In scenarios where that’s not possible today, such as large application startup or media manipulation, care should be taken to minimize the wait by only performing the minimal computation that is absolutely necessary now and doing the rest in the background later. In scenarios where that makes sense, stacking user requests in an asynchronous fashion instead of blocking the UI while a single task is pending should be preferred. Finally, when all that can be done to minimize actual software latency has been tried, perceived latency should also be worked upon, such as by offering the user to do something else while long computations are being performed. But that is a distraction from the task at hand, and should thus remain a last-resort option.
  • Frequent user actions which exist solely because of past technical constraints (such as manual trash emptying or Ctrl+S spam) should be hunted and eliminated.
  • The manipulation of pending or past works should be eased, by providing a general abstraction for something that is being worked upon, and putting it at the center of the OS’ user-facing mechanisms. That might be, as an example, an extension of the document concept, that can account for workflow that isn’t based on user-accessible data (e.g. web applications), or for workflow that requires the use of multiple applications at once (e.g. programming with library documentation on sight). As a key point, these “work units” should be easy to access, organize, and pass around to coworkers. Breaking this abstraction for communication with the outer world of users of other OSs is also an important scenario that should be thought upon.
  • While I’m talking about multi-application workflows, let me rant for a second about the increasing tendency these days to replace multiple simple and efficient specialized tools with huge bloated do-it-all programs which try to do everything and end up doing everything badly. While integration of multiple tools in a single package isn’t bad in and of itself, it seems to me that extra effort should be spent towards making applications work better together so that reimplementing stuff isn’t needed. As an example, an IDE shouldn’t feature a crappy web browser just to display library references, it should be able to open an instance of my web browser of choice that is integrated within the interface. Beyond this trivial example of application reuse, further-reaching implications could include stuff like making every tool within a graphics editing package an autonomous process in and of itself, communicating with the “core” process through a standardized IPC interface, allowing for UNIX-ish image editing process pipelines and reduced process crash impact.
  • Any kind of content creation process is naturally carried out in an iterative fashion. You do something, check the result, do something more, check the result again… However, in many case, the preferred form for making change to a content is different from that for displaying it and exchanging it with others, and the conversion between both can be quite lossy as users of word processors can attest. With this in mind, I think that it might be important to provide a standard workflow and usability guidelines for tasks such as switching between the editable and viewable forms, or adjusting the conversion parameters, so as to increase the predictability of this critical part of a creative work.

Just food for thoughts, and of course any comments are welcome as usual!

One thought on “Optimizing for work

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