One of the objectives with creating a diagramming framework in Qt is to be able to create some tools that can support classic desktop look & feel and be re-deployed on Web, tablet’s & phones. I want to take advantage of some experiences from Web based technology, but as mentioned before – I develop network centric control systems, not stand-alone devices.
Creating a HMI designer that makes it easy for anyone to create advanced user interfaces with little or no specialized GUI/Web development experience is the first step. The next is to mature this and build our own tools to support Plain/easyIPC.
One of my objectives is however a fully graphical programming language to sit on top of Plain. Obviously we need something like UML class diagrams or classic ERD to model data, but I also want to program logic using graphics. Tools like LabView or classic CASE tools already does so with some success.
The challenges with any graphical programming language are however often a surprise to many.
A graphic diagram makes things look easy and can easily create a delusion that using the tool also is easy. As most programmers will tell you even the simplest text editor is far faster than any graphic editor in creating logic. Your programming speed will initially drop by a factor of five, meaning that before you can benefit from increased productivity factors you need to compensate for this major disadvantage.
Choice of graphic language is often poorly made. What I will do is to introduce a new language that actually is not new at all, it’s one of the first languages that actually was created. A language that is instantly understood by anyone that see it. Classic flowcharts have standard limitations, so we need to create our own standard to achieve our objectives.
Readability of executable code is seldom addressed. Having a diagram is nice, but if you end up clicking in and out of screens to see the actual executable logic you have introduced yet another limitation that will slow down an experienced developer. I don’t claim to have a verified solution to this one, but I have ideas and awarness of the challenge.
Integration with a text based version is often not covered. Graphical programming tools are experimental and can get in your way because of of unintended limitations. Access to a text editor is often a life saver. The solution is to support Plain blocks directly as well as allowing the user to edit the actual XML used in the repository if need be. This simple trick will ensure that the graphic parts extend – not limit – a text based IDE. Also – we should not under-estimate the combined effect from hybrid tools.
As for the popularity of CASE tools in the past – I believe that the main reasons we see so little of them are lack of standards and lack of affordable tools.