This is part 2 in a series about a new theoretical computer interface based on ideas borrowed from Object Oriented Programming. Part 1 is here.
In my last post I talked about the concept of an Object Oriented User Interface, or OOUI. The link above contains the full text of that post, but here’s a quick recap.
1. The OOUI is designed to deal with the shortcomings of modern UI’s, namely their inability to deal with projects involving multiple applications and multiple types of data, as well as the challenge of moving data between different kinds of applications (ie no easy way to extract all the images from a PowerPoint Pres short of copying and pasting)
2. The OOUI has three parts, a canvas, collections, and objects. Users create and save collections by arranging objects on a canvas. This process of manipulating objects is meant to be very fluid and natural, with Bump Top’s interface being a solid example of what it might look like.
3. The OOUI is Object Oriented, because it’s objects are much like objects in OOP. All objects are either made up of primitives or are a primitive. Objects have methods that users manipulate them with.
Now what you may have noticed in the last section was there was no mention of anything that sounded like a traditional application. None of the elements, objects, canvas, or collection, bear a direct resembalance to Microsoft Word, or Powerpoint, or any other of the applications we’re familar with. So what happens to the applicaiton in an OOUI?
To understand it’s best if we start by thinking about what an application now is. At it’s heart, an application is a couple of different things.
1. First an application is a set of tools to manipulate a certain collection of data, called a file. This manipulation may be just a matter of viewing, or it may involve editing
2. Second and application is an interface that displays the data and the tools.
What’s important is that in a traditional application these two elements are inseparable. The tools are directly tied to the interface. Adobe Photoshop offers a perfect example of this. Photoshop has a very powerful set of tools for manipulating images. You can color, stretch, erase, apply filters, etc. But you can only use these tools in Photoshop. If you copy an image into Microsoft Word, you can’t use Adobe’s tools anymore, not unless someone designs a plugin specifically to allow that sort of use. Instead you’re stuck with the rather meager image editing tools Word offers.
In short each application is a silo, and data has to move between applications before you can make use of the tools that application offers. What’s important to note, is that often you can’t import data directly into a secondary application, instead you have first open it in the primary application, and then drag and drop into a secondary one.
In modern UI, data is siloed into a certain file format. Unless import methods have been specifically coded, data can only move between application through manual drag and drop, not direct import.
To put it simply, a set of tools is tied to a specific interface, not to a specific type of data. As you move from interface to interface you gain and lose functionality
The OOUI however takes the philosophy that tools should be tied to data. You should be able to do the same things to an image in Word that you do in Photoshop. It’s just an image after all. Why does it matter what other pieces of content you’ve put it in relation to?
This radically changes the process of application development, basically completely abstratcing the challenge of data manipulation from interface design. Interesting though, this is the direction that programming has been going for years, to the extent where alot of modern application development uses one language to do interface (some sort of markup language, like XAML, or XUL) and one language for functionality. In some ways the OOUI is just the logical end point of the abstraction between functionality and interface.
So what does developing an application in a OOUI actually look like? Well the best way to explore that is with some sample applications, but before we do that, we’ll start with a breif overview. OOUI applicaiton development comes in three parts.
1. Object Definition – First the developer needs to write the object defitions for any complex objects the application will need or for any additional methods that the app will enable for primitives. For an image editing program, this might just be a new set of filters to change an image. For a powerpoint style program this might be more complicated. You might have to right the defintion for a slide object, which is a collection of images and text, and then a presentation object, which is a collectin of slides.
2. Canvas Definition – Then the developer needs to define a defaultof canvas designed for viewing and manipulating their data. For a calendar application, the canvas might be designed so that the background displayed the days of the month. Furthermore, the developer might design it so that you could only layout objects on a specific date, not anywhere on the canvas. It’s important to note though, that users should be able to move data off of this canvas.
3. Control Objects – Control Objects are a special type of object that are designed purely to give basic user interface points. On a music player application, this might be the stop, start buttons. and volume control. On other applications this might be a search box.
To design an application the developer writes a the object defintion, sets up the canvas, and the populates it with controls. The result is a collection with a unique canvas and application specific controls. The user opens this up like any other collection, and imports objects from the file system, either manually or using some kind of search based control object.
OOUI Based iTunes
To give you a better idea of what an OOUI app might look like, from both a developer and a user perspective, lets take a look at a sample application, an OOUI based music player like iTunes.
The first challenge to creating an OOUI based iTunes is to figure out what kind of data we’re working with. Obviously it’s audio files, but it’s really not that simple. Music files are more than just straight sound, they also contain alot of metadata, like artist name, album, etc. Beyond that, there’s also the need for playlists and radio streams. There are also podcasts. So for each of these we need to set up an object defintion.
Songs – A song has attributes for it’s audio content and it’s meta data, including album art. It would have methods for things like play, stop, add to playlist, queue as next song, delete from playlist, edit metadata, etc.
Playlists -A song has attributes listing it’s component songs, as well as textual metadata for playlist title, length. Like songs playlists would have methods like play, stop, add song, remove song, etc. Additionally the playlist would have some method for adding songs based on a search of your music library (ie like iTunes dynamic playlists feature).
Radio Streams – A radio stream would be somewhat similar to a song, except it would need to handle streaming content instead of local. Additionally, it might have attributes for history, storing information on the last few songs that placed
Podcasts – Again, much like songs, but might have additional attributes for the author, the originating website, etc. Could potentially be grouped with songs as a subtype.
Once we have these object types, the developer may want to define a default canvas for interaction. For some apps this might not be necessary. Our photoshop equivalent might simple have all of it’s tools as widgets available off of an image, after a right click or similar.
For our music app though, let’s assume the developer does want a default canvas. The result will probably something failry simple. A big space in the middle to display to currently playing media, in possibly a list, grid, or unorganized layout. A place along the side for other playlists. A control object that allows the user to type in a search term and get search results. Another place for those results to show up. A place for your volume, stop and start control objects.
Now the idea is that the user would load this “application” and be presented with this default view. However, the advantadge of the OOUI is that this view would not be static. The user could move anything around within the collection and even move items outside to another collection, including the control objects.
The point is that this idea of an application as a static entity that you open up, create or import a file, and then close out would become obsolete. Instead the OOUI “application” would be a collection of disparate entities. It would be a set of object definitions, that could be used anywhere on your computer, so that you could place iTunes songs alongside your own text and images. It would be a default canvas where you could work with both audio related items, and any other media you brought in. And finally it would be a set of control objects, like the music library search, that you could move between a variety of collections.
Now some applications would experience this change more than others. Image editing apps would almost completely disappear as a standalone interface. Since you’re usually only working on one image at a time, the tools for manipulating images would really only need to be acessible from the image. Maybe the user would right click and be presented with a traditional toolbar or similar to edit with; the details are not important. Other apps would remain much like traditional applications, but just with more funcationality. A calendar application for example, would still require a very specific interface, though in an OOUI you could do neat things, like associate images, text documents, audio files, etc with a specific date, giving you more information about an appointment. But overall, the boundaries between applications would become exteremely porous and flexible. To go back to an earlier statement, the tools to manipulate a piece of data would remain tied to that data even as the data moved between any number of totally unrelated collections. In short, you could use the features of Photoshop every you find an image, not just in Photoshop.
Part 3 of this series will deal with how OOUI based web applications would work, and how the web in general would benefit from a OOUI makeover.