Thursday, September 6, 2007

Ever though how little help there is for direction manipulation interfaces?

A Component Framework for Direct-Manipulation Editors

Ever though how little help there is for direction manipulation interfaces?

If you want to write an on form to fill in it is easy to use a dialog box. BUT if you want to say have something that gets dragged or selected you have to go to a much lower level ( mouse down ,mouse up and so on).

it struck me as very strange that you can get a standard tree component but not a direct maniuplation component. Strange that both the PC and the Mac have a 'finder' - a direct file manipuation program.

You might expect that this should be included in any basic GUI tool kit and I wonder why not.

More strangely most of the standard GUI systems have a Drag and Drop - the interaction of direct manipulation between two applications mostly the finder/file system with an application. So you get fragments of a direct manipulatoin tool kit but not a frame work for the whole thing.

Why not - is it hard to do why am I expected to build my own draggng icon application but not write my own button class. Is it some kind of programming problem or is it cultural ( i.e programmer cultural) ?

As I pointed out to Paul this is important - Direct manipluation turns up in an number of good applicatoins (iMoive,iTunes, graph editing applications, drawing programms, 3D programs ) but it is the life blood of tangables and table top interfaces. If there is some usablity reason why you should NOT make a tool kit for direct maniplation then we need to know what it is and why shareable interfaces look like they will be highly direct manipulation.

No comments: