Now blogging at diego's weblog. See you over there!

anticonvergence

Russ posted an interesting entry on 'anticonvergence', the idea that specialized devices will actually be more important than integrated devices. This is the idea that the spaces design is based on, with its current (and more importantly, future) synchronization capabilities.

Although I didn't have a name for it, I first became interested in this idea around the time at was working at IBM Research designing a new portable device. UI researchers have expected this kind of separation between devices for a long time, and for a good reason that can be summed up in one word: affordances.

As I mentioned earlier affordances are natural extensions for functions on a given system; for example an affordance for the 'open/close" function in a door is the handle, it naturally (through training and our physical disposition) makes us want to grab it, and it moves only in the direction in which the function is "activated" ie, to open the door when it's closed, and viceversa. (By the way, Don Norman's book, The design of everyday things which I also read when at IBM, is an incredibly good introduction to many deep issues in design and in particular to the idea of affordances and specialized user interfaces).

The problem with affordances is that they work best when they are little (if at all) 'overloaded' that is, when they represent a single function in the system. When an affordance has to match two different functions it becomes confusing and, as more functions are piled up, diffidult to operate. One only has to take a look at current Microsoft product to see how overloading of an affordance can lead to disastrous results. (This is one of the reasons why I try to keep the UI of spaces clean and simple.)

For example, people that have been working for years on designs for intelligent homes never, ever create "control centers" for the different things that have to be controlled, there are always many user interfaces spread throughout the house, in the kitchen (fridge door, oven, etc), in the living room (TV, media center), in rooms, and so on. 'Entertainment' devices such as cameras or MP3s are really good at what they do and while it makes sense to have some limited cross-functionality (say, a simple camera in a PC) you'll never beat the 'hardware UI' of a camera with a cell phone. It's simply a matter of ergonomics.

That said, there are some functions that definitely make a lot of sense for integration, in particular PDA-cellphone functions. But more integration than that is overkill and unnecessary. Eventually, single-purpose devices like the Blackberry will eventually win.

It can be summed up in one phrase: To each task its device, and all of them seamlessly and transparently connected.

Categories: technology
Posted by diego on February 7, 2003 at 7:49 PM

java & openoffice

Following up something I remembered from a couple of months ago... I've been looking with some detail at the different APIs exposed by OpenOffice/StarOffice, in part to provide support for connections between OO/SO and spaces, and in part since I've been working on the design for a similar API for spaces itself. OO/SO goes pretty much along similar lines to what I was thinking: two APIs, one for compiled code and one for scripting.

The "compiled code" API is called UNO and it's a bit overreaching, supporting basically every major language out there and then some. As the web page describes:

UNO (Universal Network Objects) is the interface based component model of OpenOffice.org. UNO offers interoperability between different programming languages, different objects models, different machine architectures and different processes either in LAN or via the internet. UNO components can be implemented in and accessed from any supported programming language.

Currently [there are] bindings for Java, C, C++ (compiler dependent, please see http://porting.openoffice.org for a list of supported platforms), OLE Automation and Python(in a alpha state).

A bit too much isn't it?

It seems to be a design more influenced by the "all things to all platforms" mentality of CORBA rather than Java's simplicity. I'd sure would like to see a simple, streamlined Java-only API. Burdening Java with a framework that has to support the complexity (and potential ugliness) of C++ makes no sense to me.

The scripting framework appears to be a bit simpler and more targeted towards Java, and an early developer release is available for download. It is expected that these APIs/frameworks will carry on unchanged from OpenOffice to StarOffice.

Categories: technology
Posted by diego on February 7, 2003 at 12:40 PM

JDK 1.5 features

Simon posted a short summary of the most important additions to JDK 1.5. Of those, Generics, (ie., templates) Autoboxing (automatic conversion of primitive types to and from their reference type equivalent) and Type-safe Enumerations are the most useful, and will IMO vastly improve the readability and development of Java code. The enhanced for-loop, a simple way of iterating through collections, is slightly confusing I think (as it always happens when you "overload" keywords in this way), but useful nonetheless.

Categories: technology
Posted by diego on February 7, 2003 at 8:46 AM

Copyright © Diego Doval 2002-2011.