One of the complaints we hear about visualisation systems is that they are unintuitive. Most of them are unintuitive because, they are built for specialised applications. There are no general purpose visualisation systems.
NPL is also haunted by these concerns. Many do not like the NPL UI(at the moment) because it produces canned visualisations which are not always suitable to the way a person thinks. Hence, people need to have control over the visualisation. But the mechansim provided to customise the visualisation will ultimately decide the fate of a visualisation system. Here I introduce the "pay as you go" model for building visualisations which suits well with the way we develop software.
"Pay as you go" Model:
Instead of spending huge resources(or taking huge losses) upfront for a visualisation system, in this model the resources spent will be directly proportional to the intuitiveness of the visualisation. In this model, the basic features of the visualisation system will be free, where as the higher level views can be customised by a little effort from the user.
The effort can be minimised and returns maximised when
- The lower bound is free and acceptable for day to day chores.
- The resources needed to get better visualisations are little.
- The upper bound is(seems) achievable by(to) a average joe.
This model has the potential to make visualisation mainstream.
The Plan:
Though this model looks simple and straight forward, achieving them is no easy task. Here are some techniques i think will make this model work.
- The lower bound can be achieved by the following tasks:
- Designing the language to suit visualisation.
- Using designs which are easy to visualise.
- Good basic visualisation.
- Modifying Visualisation based on static and runtime anyalsis of programs.
- Custom look and feel for standard libraries.
- The incremental changes to visualisation can be provided by:
- A meta language which is turing complete and is similar to/same as the language we are coding in.
- Providing default visalisations which the users can use.
- Providing inspection of language structures in the meta-language.
- A declarative language, for making chores easy and quick. (Can this be same as the meta language?)
- The upper bound should not be too high, so that it is daunting for a programmer to even attempt for a perfect visualisation. The upper bound can be kept under check by:
- Providing mechnisms for customising visualisations rather than policies. This aids in keeping the number of visualisation primitives low.
- Providing tools.
