This post is a summary/conclusion regarding my series on user interface. The first post is available here.
This post is more than a little late, seeing as wrote my third post in a series on the idea of an Object Oriented User Interface, almost a month ago. It wasn’t my intention to leave the idea (and my blog) fallow for such along time, but as I explained last week, it was a much needed mental necessity. I want to return to the topic of user interface though, for a breif summary and some concluding thoughts on what has been a very interesting series for me to write.
The idea for an OOUI came to me really out of nowhere, just as the result of some late night boredom and web stumbling. The idea evolved as I wrote about it, so that points that probably should have been in my first point ended up in the second. As a result I think it may be worth it for me to recap what I see as the most important point.
In a traditional UI, data moves between a variety of tools and applications, causing the user to lose and gain functionality depending on which application is currently accessing the data. However the OOUI takes that stance that tools should follow data, no matter where the data goes. A picture is a picture is a picture, no matter if it’s part of a presentation, a text document, or standalone.
And while I believe my posts have done a good job of exploring many of the implications, possiblities, and benefits of this central idea, they’ve left one big thing unaddressed. How do we get there from here? How do we move from a traditional UI to an OOUI?
Honestly, I don’t know. I am not technical enough to fully understand the programming challenges, not business savy enough to understand how to bring something like this to fruition. At this point I’m really nothing more than a wild eye’d dreamer with what I hope is an interesting idea.
I have some thoughts, and it seems to me that there’s potentially for an open source project here, since I doubt many commercial groups would be willing to make the gamble of time and money that such a project would entail. And part of me is considering trying to build up the necessary technical chops to get that kind of open source project started. But ultimately I’m not sure how much really bringing the idea to fr tuition interests me. I think ultimately I’m more likely to use it in a story than I am to write it out in code.
But this isn’t the result of some persistent personality trait, marking me as a dreamer rather than someone focused on the practical job of figuring out what to do next. In fact, at work I often finding myself playing the role of the firm anchor to the current situation. Most of our executive are big picture people who often think up very impressive long term plans for improving our procedures and processes. However, sometimes these plans outstrap our resources to execute them right away. So I often find myself pulling people back to the topic of “What can we do now?” so that we can immediately start improving.
This strays far from my opening for this post, but that’s something blog posts are apt to do. And I think in some ways there is a tie back. Ultimately its hard for us to flip back and forth between the big picture question and the what next question. For any given problem we’re probably going to focus in on one perspective.
For complex problems like user interface design, this means that more and more we’re going to need multiple people attacking a problem, so we can get both perspectives on the issue. Problem solving will need to become more modular, aided by internet based communication to help people collaborate.
The ramifications of this are many fold, and I can’t really explore any one of them in this post. But I think the best thought to sum it up with might be a song that I’ve just downloaded, listening to coincidentally for the first time. The song is by Ben Lee, and the line that just caught my fancy is the following.
It’s quantum physics baby/
We are all in this together
Quantum physics and problem solving, let’s figure this out together.