Chandler UI

I just posted a comment on Michael Toy's weblog. Why I didn't put it here, and trackback ping his piece, I don't know. Because I should be eating, not sitting at the computer, perhaps.

Here's what I wrote, so I have it in the future:

I'm not saying this is easy to achieve, and when everyone is clamouring for this feature from here, and this feature from over there, it might be impossible, but ...

Simplicity *is* power.

Wherever I see real power, the sort of power which can actually be put to use without fear of losing a hand, I see a system which starts with a few basic rules and builds *everything* up from there. No exceptions. Problem is, which rules? Because it's getting the right simple rules which makes the difference between brain dead and extraordinary.

http://hamish.blogs.com/mishmash/2003/09/platform_surfac.html

I fear you're right. The UI sketches for chandler look to me as if they aren't copies of Outlook -- that's good -- but there are too many panes, to many concepts, too many ways of slicing data, *too much interface between me and my data*. The power is coming before the simplicity, and that's not good.

A multitude of panes is not, to my eye, evidence of a good, simple, consistent theory. Ever tried driving Outlook with voice recognition? There are whole panes where VR can't go. That gave me a whole new understanding of how badly Outlook sucks. Panes say "disjointedness". Get between me and my data.

Sorry to go on (and on) about it, but this is quite a different first impression than that which Haystack gave me. Haystack says *different*, *consistent*, *simple core, uniformly applied*.

OK, not totally different; it still sits in a window, and makes use of familiar widgets. But there are some genuinely novel ideas there, and I'd love to hear some comments from the Chandler camp about them.

http://lists.osafoundation.org/pipermail/design/2003-September/002692.html

Oh, and just looking the UVC interface gives me ulcers. Busy busy busy doing nothing. That this screenshot is an advert amuses me; "look, see how complex our software is, it must be good".

Keep on dreaming, and *please* try to move the mountain. If enough people push, maybe it'll be moved right out of the way one day. Process recreates what already exists, only individuals can have the insights, the inspiration, to come up with something new.

The second of those links is to an email of mine to the Chandler design mailing list:

Interesting looking stuff in 0.2.

I just had a read through the CPIO overview (http://tinyurl.com/orvn), which 
contains some novel ideas. The level of configurability proposed is 
important, and being able to build and share parts for it is potentially 
powerful.

I recently looked at Haystack as well, and there are two aspects of the 
Haystack interface which deserve serious consideration. One is _essential_, 
and should be easy: _wherever_, for example, reference is made to a 
particular entity (obvious example: a person), the same context menu should 
be available. Haystack builds context menus from the hierarchy of components 
where you click; if you click on the senders name in an email (or on the 
senders name in a line of a list of emails) you will get a menu with things 
you can do, first, with that person's details, second, with that email.

The second idea is fascinating and potentially very powerful, namely UI 
continuations. The idea is that when you start a task which requires more 
input, instead of opening a dialog (if I decide to do something else first, 
or need info from within the application, I have to close the dialog and lose 
what I've done already), a continuation is added to a stack (in a side bar in 
Haystack's case). I can then leave it there until I'm ready to finish filling 
it in and apply the operation.

Haystack have a document describing the UI:
http://haystack.lcs.mit.edu/documentation.html

As well as not having to have all the info to hand for a task at once (and 
without access to the rest of the application) this again leads to an 
improved level of UI consistency. Whenever I need to find info about a 
person, I use the same method; I find it in the main application. I can then 
DnD anything I need into the continuation, which sits there in the side of 
the screen all the time.

And so on.

A thought regarding documents and contexts. If, say, I'm looking at an email, 
it might be reasonable to expect a double click on a sender's name to take me 
to that senders record. How would it choose which context, and which 
document, to show that in, from the potentially many available?

Cheers,
Hamish