A different approach to computing

I recently unearthed an old project of mine, and could hardly remember writing it. I’m publishing it here for posterity.

Motivation

This is an outline of an interface that will allow computer users to be much more productive than current technology offers. It will be easy to user for newcomers and power users alike, with a smooth, shallow learning curve between the two.

Much has been taken from Jef Raskin’s book “The Humane Interface”.

Much of today’s tools get in the user’s way and require a learning curve. Interfaces assume we understand how computers work. Furthermore, there has been insufficient adoption of infrastructure evolution into current operating systems, with many services bolted on or treated as applications and services rather than critical pieces of computing interfaces.

Many of the improvements will be attributed to a far shorter feedback loop between the user’s intention and the result; between attempt and eventual success.

Proposition

The application abstraction is not the best paradigm. It leads to siloed functionality and requires many application developers to re-implement similar or identical functionality, with varying quality. Much of this functionality has been absorbed slowly into some operating systems, but that process is tedious and constrained by the resources of a large organization.

Compass will not have applications. Instead, it will have commands that can be performed upon content, and transformations that can be applied automatically or manually to adapt content to the various expectations of commands.

Content

Content is anything that can be operated upon by a command or transformation.

Some content is simple: text, images, video, music, and such. Some content is richer, such as spreadsheets, relational databases, API endpoints, social feeds, etc. The most complex content are commands and transformations themselves.

Content does not live within an application, and the manner in which content is stored is invisible and even inaccessible to the average user.

Any of the following are typical examples of content:

  • my music collection
  • my amazon purchase history
  • the names, birthdays, and contact information for my friends and family
  • my credentials to various online services

Both commands and transformations can also be treated as content.

Commands

Commands represent something a user wants to do with content. Playing music, purchasing items, emailing a friend, manipulating a photo, even simply viewing a twitter feed is a command performed upon content.

Users interact with a command’s output via normal means; either a graphical representation, aural for music, or whatever format is most appropriate for that command and content pair. For example, viewing a twitter feed would display the feed as you’d expect. Cropping a photo requires some interaction with a cursor graphically, sending a message requires a recipient and message body in a window, listening to music would emit sound from speakers, etc, etc. This output will not be surprising and will encourage habituation.

Commands will work when expected to work, and will emit nonsensical output when the input is nonsensical (e.g., dividing by zero will emit NaN rather than displaying a dialog).

In these ways, commands will encourage the formation of habits and prohibit the expectations of the user from being broken.

Command output is persistent and easily undoable and redoable. If command output is indistinguishable from its input, then it is not persisted unless an explicity “duplicate” command is invoked.

Commands can be treated as content.

Transformations

Transformations allow content to be converted from one type to another. For example, an image may be converted to and from a format readable by a complex image command (the equivalent of converting into a PSD for use with Photoshop). Or an audio file may be converted into it’s lyrical text.

Transformations are used when a command is attempted upon content. If a transformation exists that a command understands, then that command succeeds with sensical output. If no such transformation exists, then the command’s output will be nonsensical. It is important to note the absence of a modal error message; the fast feedback loop will immediately illustrate the reason a particular command fails.

Transformations do not persist, since command output is persistent.

Transformations can be treated as content, just like commands.

Pipelines

Combinations of content sources, transformations, and commands can be labelled as commands themselves. It can be considered a sort of “graphical” way of doing programming.

Persistent Storage & Identity

The user will be unaware of how the system stores anything. Underneath, the system will use Dropbox as the main repository of user data. Users will log into the system using their Dropbox credentials.

Content will be stored according to mimetype in the /Content directory inside Dropbox. Commands will be stored in /Commands and transformations in /Transformations.

Everything stored within the user’s dropbox will be indexed for search and for browsing.

Navigation

Users can navigate either by searching or browsing their content. Searching is instantaneous and sorted by relevance, type, and any other possible dimensions (locality, proximity, etc.). When a user selects the result of a search, the “view” command is invoked on that

Browsing all content can be done according to type, contents, date, and possibly by collaborators. Collections can also be created to hold and organize content of any kind, to any degree.

The user should have no need to remember file names, remember file locations within the filesystem, or come up with new filenames. Indeed the user should not have to know that “everything is a file”.