I gave a long hard thought to next generation user interfaces.
Two things are clearly part of such interfaces:
Where do we find such interfaces?
So, let us say we have a directory in our filesystem that has about 25 folders and another 50 files. Traditionally, one list view or icon view is used to display the contents of that directory level. Sorting by single or multiple parameters is used to further refine the searching process. Desktop searches are used. If you are really savvy or so, you will use tagging. Another way of representing the structure is by using an interface like Filelight. Still another interface is that used for visualization of network topology.
But the problem in each of these representations is that exactly the same icon is used for similar entities.
So essentially, you are wasting valuable pixels useful in representing data uniquely by not using a unique icon for every single object.
However, making every icon unique would be impractical and troublesome in several ways.
But now think about another place where you visually handle lots of complexity without batting an eyelid – photos.
You click or see lots of photos, but you still remember exactly the one photo that was clicked at the correct angle so that the scene got the best lighting effect and simply, it looked great. But how?
My analysis is this:
Because we process “normal” or “day-to-day” visual data very differently from the way we process artificially created visual data.
In the artificial case, we introduce logical thinking at every instant of cognition of new data, thereby considerably reducing the speed of data interpretation and storage. That is why for example, when you travel along the countryside on a train or by road, you remember interesting scenes without straining yourself much, but while remembering a 10-node network diagram, you feel a bit of a strain.
So, how is this problem to be solved? Simple, replace the 10-node artificial graph with a corresponding natural scene. And so you can store information as a *landscape* photo!
Of course an unnecessary amount of extra data will be stored, but retrieval and identification will be much simpler. This kind of storage is useful when visually interpreting the data quickly is more important than cost or availability of storage. Or when storage is imply not going to be done. Keep this last thing in mind for a moment.
For example, let us suppose that we represent our source code like that. Which means, represent a top-level package in your huge program by the photo or *realistic* 3D model of a mountain. Then replace the next level by the distant image of large trees. The next lower level, a close-up, and by branches. Still lower levels by leaves and so on.
Then, to make the pictures look really natural, use sufficient iterations of [random numbers + fractals] which will make the scene look real and where, most importantly, everything has a unique *pictorial* form, much like a UUID or a GUID or whatever you call it in your language.
So, this mountain and that mountain always look different. No two mountains are allowed to look the same either, just like no two files can have the same *full* path in any operating system. Here, since the visual landscape is probably to be treated as flat in hierarchy, it means that the name (the picture in this case) itself is the full path. So no two mountains or trees can ever look the same. Ah yes, to a casual observer, the two might look same, but that is much like not realizing that just one character in the two longish names is different.
Now, in this “natural” picture, add some interesting protocols.
That mountain over there is a rock mountain, because it will not compile. The moment it compiles, it suddenly becomes a green vibrant mountain with all details visible. (Not the other way round, which is counter-intuitive.)
Till it does not compile, the one place where it first fails, that is, the place where your stack trace starts, is shown in flaming red like lava, showing that the compile error lies at that spot. Then those parts of the program which fail due to dependency on that spot are shown as mildly red and so on. So, tracing the stream of lava or red, back to its source is essentially looking up the stack trace. A pane on the right side can actually show the text of the error given by the compiler.
A syntax error is shown as a small yellow stone. A logic error is shown as a long red cloud of gas (since logic errors propagate through the system wildly, much like gaseous pollutants) and so on.
A divide by zero would be a flash of lightning!
And now, we can make very complex rules of programming available for simple users to do “natural programming”. Dragging trees onto lakes means piping the output of the tree-represented packages to be the input for the lake-represented packages. Or you could do an ordered fill-out-the-dots sequence to make a complete chain of shell command operations.
Then you are really, well and truly a *wizard* at shell scripting. You just move trees and plants over clouds and lakes and produce the day’s database backup for your web application!
Now to workflows. Workflows are very well documented in strategy and civilization kind of games. So why not use those visualizations to manage standard office workflows as well. Of course, you do not get the all-important privilege to shoot your boss mercilessly, but then if it is open source, you can always hack around at home and shoot him at leisure! And as many times as you wish.
I can hear the media wanting to shout:
Open source makes it possible to shoot your boss in workflow engines.
And some research will show that it is an excellent management strategy as well. And it will be wildly popular as well.
Say it again: Opensource allows you to shoot your boss! Nice fun 🙂
Oracle, SAP, ERWin, are you *game*?
And no, I am NOT drunk.
As usual, I hereby release this idea as free for everyone and anyone to use in any legitimate way, no fees, no rights, no attributions, no patents, no Intelligent Phony Rights, nothing.