Thursday, February 16, 2006

The Score is the Piece, The Score is the Data

The OSI model for network communication got me thinking recently. It is robust. The physical layer can be swapped out and the system still runs, so long as the new medium implements the correct interface to the other layers. What the OSI model doesn't seem to nicely do is allow for repetition of layers. Seven layers seems pretty good, but some interfaces use less and some more. In fact, it sometimes seems that the layers are really instances of a single layer idea, so that the OSI model really just describes a way of inserting your own or replacing another with your layer into the stack, whether your layer is part of the communication level or just a visual interface at the top. The thign that fascinates me most about the model is that TCP and UDP both came out of it, which are so very different in terms of data communication since one has error checking and the other doesn't. That those could be built to conform to the same model is testimony to its robustness.

I'd like to use sound as the physical medium for a project. I'm interested in classical usage of modern technology. By classical I guess I just mean non-electronic, and by that I mean whatever we could do up to, say, the 19th century. The idea is to set up devices in a room that will act as nodes on a network. Each has a speaker and a microphone. The microprocessor controlling each device (yes, inspired by classical usage, not actually...) can target another device by using a certain frequency, and employing a sort of morse code or binary pulse system to send messages on that audible tone.

I propose sending a musical score over this network. However, the transfer of the score is the score itself. In other words, the score dictates the audible tones, which performs the musical score and simultaneously transfers the score to a new location.

Thursday, February 02, 2006

Calm Technology and Software Devices



Software interface design has slowly solidified since the dawn of graphical user interfaces. Operating systems have been defined by the windows and menus they use. I view major operating system upgrades in the past (for example to the Mac's System 7, to System 8, to Mac OS X) as being characterized mostly by refinements to the visual display. Apple, for one, has long published user interface guidelines that describe not only what sort of window a developer should employ, but also the exact pixel spacing between interface elements, etc.

This was a triumph for calm technology. It meant consistency of user interface, which meant the user could always rely on the same functionality residing in the same place. It meant unobtrusive user interface, which meant that the user could focus on the content at hand without being distracted. And it meant a smaller learning curve for new users of software. All of this was flexible of course, and bad interfaces or software that tried to capture too much complexity without considering interface design suffered. In my opinion, Microsoft Word's paper clip was the antithesis of calm technology, as were their myriad icons and palettes that created information chaos at the top of the screen.

Since the beginning, however, a few pieces of software have always laid outside these guidelines. Take, for example, the calculator that has been present since very early versions of the Mac OS: it had a black window title bar. This was to signify that it was a utility that sat outside the conventional document-based workflow. This was probably to emulate its representation of a physical object. It was more of a software device than a software application.

Since that time and likely before, software has more progressively (and aggressively) tried to present itself as devices, instead of as applications. Most dramatic in this history was probably the extension Konfabulator, which populated a user's screen with "widgets." The idea was rolled (or rather appropriated) into Mac OS 10.4 and went mainstream.

Widgets are drastically different from most computer applications, and their name is important. They sit on the screen, in our periphery, at all times. They are the focus of our attention only when we actively want their information (at least in priciple). We can discern the weather out of the corner of our eye without ever consciously taking the time to do so. This is a great development in the function of software, and it is funny to me that it works because these pieces of software go against the user interface guidelines and instead try to emulate hardware devices.

Having hardware devices on your computer screen is an interesting idea. A good example of a rather successful implementation is Propellerhead's Reason, which emulates audio hardware to the point that the cables connecting the hardware sway when you move them. This interface appeals to me, but what of the newer generations that grow up having gone straight to hardware, never using traditional audio pedals and hardware? This software to them implements something that doesn't exist, and perpetuates these strange physical ideas in a word where they are arbitrary.

The danger here is that all the user interface guidelines get thrown out? What is gained is a kind of familiary and excitement. Even a simple weather display was recently exciting in how it broke people's expectations of what was possible. With all this new color and animation and new buttons to learn, the devices run the risk of being very un-calming. Somehow the first generation of these widgets passed the test, in my mind. Developers are not as restricted by cumbersome development tools anymore, and can focus on design and meaning and functionality in their software.

So what is needed is some sort of new cross between interface design and industrial design. I'm not sure what will ultimately succeed, but it seems that software that feels like hardware is a good thing. It has boundaries in its interface. It drives a specific task. It can be networked underneath the hood, but that is irrelevant and doesn't need to be explicit in the interface. It needs to sit quietly. We are designing products. What happens when we push this design aesthetic enough to drive out unnecessary emulations of real-world objects (like using LED-segments on software alarm clocks, or drawings of guitar cable) but still deal with notions of object and boundary? I'm looking forward to the next iteration of software devices.