Friday, February 15, 2008

Why the diagrams mum?

Have come across this little article at a FormTek blog. The story is about the use of technical drawings to understand the capabilities of the thing you are buying, and able to use. They go into the issues of maintaining the technical drawings as essentially a revision control problem.

This is the issue of having technical diagrams on paper, they are a physical thing that is hard to maintain. But, they are easier to use than a notebook with the same data, as they do not require power, are not fragile (well paper does tear, but this doesn't mean that it reboots on you ;-)) and within reason can be carried anywhere that allows enough room to unfold the print.

However, just as we want paper free offices, we want to be able to remove paper in technical diagrams. Now that some flexible displays are coming, we won't need such laptop or PDA bound methods of working, and will be able to play with a piece of networked paper.

How would you interact with such a set of diagrams? What sort of tools would you need to manipulate such information on a paper-based display, that is automatically networked to headquarters. How do you play with such an interface with a number of people at once in an office?

Not only that, but what is the nature of a technical drawing when it goes live...

I think the time is nigh to stop thinking about technical diagrams in such a static manner, and begin to conceptualise the documents as living paper. Which makes me wonder why most diagrammatic representations of Business Processes are sooo dead in nature. They are simple 2D diagrams without many annotations to give extra information. In fact the information is the key (duh), so maybe it is the "display" technology that is the issue.

For instance, what about walking around with a HUD pair of glasses with annotations of your work place containing information about the processes in a spatial manner. Could be useful for process model verification and modelling for that manner.

Some work here to be done I think.

Ross

No comments: