A More Natural UI: Part 3 The OOUI Web

This post is part three in a series on a new theorhetical user interface, called an Object Oriented User Interface, or OOUI for short. Part 1 and part 2 are available in earlier posts.

So at this point we’ve discussed just what this idea of an OOUI looks like. We’ve looked at it from both the user, and from the developers perspective. We’ve hit upon the central point of an OOUI, that tools to manipulate a type of data are tied to the data itself, and not to a specific interface. We’ve discussed how the OOUI borrows heavily from object oriented programming, so that you have objects with specific definitions.

So far though, we’ve left out the internet. There’s been no discussion of a web browser, or hyperlinks, or anything like that. Is the OOUI something that only works on a local computer? Is it doomed into obsolecence even before birth as web applications rise into the limelight?

No. In fact the concept of an OOUI is very at home on the web. There’s nothing that says that the collections a user is accessing has to be local. A collection of photos is a collection of photos, no matter where it is located. The basic information about that collection (it’s component objects, their default layout, it’s name, etc.) could easily be stored on a remote server which a user accesses over the net. Just like the internet now, users could point their collection browser to some remote website and pull up a collection, just like a web page. Going beyond a web page, users could even rearrange the layout of a collection, storing the configuration data for their own personal version on a local computer (if the collection designer enabled it.)

This vision however, would only work if the user had the object definitions for every type of object in the collection. What if I built a collection using an object you’d never encountered before, say a news object, which had a news article and information about it. Then, in a local model, if you wanted to view this collection, you’d have to download the news object definition.

What would make more sense, is if the server could process the object definition for you, or let you processes it on the fly. Either way would work, from a technical perspective, basically being the difference between php and javascript. The web seems to be leaning to more client side scripting these days, so the second is more likely, but the end result is a identical. The user can interact with complex collections that are entirely remote. For an example let’s take a look at an OOUI style search application, modeled after Google

OOUI Google

The user would point their collection browser to the Google collection site. On load the collection would consist of one control object, a floating search bar with the Google logo near by. Typing in search results would cause a list of results to load in another part of the collection. Pretty basic stuff so far huh?

Here’s where the OOUI concept can really make this simple search site shine though. Maybe you can set it up so that search results only load in one portion of the canvas, say the left half. If I see something ineteresting then I can drag it over to the right. Once I’ve scrolled through a few pages of results, and I can perform a new search, and drag items from that into my collection of results. I can pile those results up, group them together, arrange them however I like. Then once I’m done, I can take my collection of search results, and move them into another collection, maybe one for a document I’m working on. You might say I’ve downloaded the results into a local collection, but that would be misleading. The results are still out there in the cloud. They’re still getting their definition, even their content from Google’s servers. I’ve just moved them into relation with some local data. But even so, the results conform to the central principle of an OOUI, tools follow data across interfaces even when one interface is “remote” and one is local.

In fact the OOUI offers a new strategy for the web in general, making mashups a seamless part of the interface, not some complex challenge for a webdesigner. Users can grab data in and out of the cloud on the fly, from multiple sources, rearranging it with easy. Of course if I’m offline, that means parts of my collections won’t work, but who is offline enough these days for that to be a big deal.

This concludes my examination of the OOUI and the web. Again, I think that the OOUI offers a compelling vision of what a better, more natural, more flexible, more powerful user interface would look like, just as it has in the other areas we’ve discussed. I also think for now this brings my discussions of the OOUI in general to a close. I’m going to do one more post on the subject, giving sort of a recap of my thoughts, some background of where this idea came from, and where I’d like to see it go, but as far as content about what an OOUI really is, this is it for now. I’d love to hear your thoughts on the idea. Does it intrigue you as much as it does me? Do you want to see it built? Do you have the skills to build it? Let me know.


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 )

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s