In this paper we present Alligator, a Web system for distributed visual programming. Based on a client-server extensible modular architecture, its purpose is to allow people without any particular computer skills to build their own applications, by connecting to a Web site and visually composing data-flow programs.
Web-based programming environments, distributed programming, distributed services, end-user programming, data-flow visual languages.
Nowadays, direct manipulation paradigms typical of iconic interfaces have become natural even for children, while interaction mechanisms based on the use of mouse and direct access to information have found in the World Wide Web a breeding ground for new communication opportunities. Sometimes, however, net users would like to go beyond simple information retrieval, to more actively interact with the Web, maybe to create personal applications. By providing a Web-based visual programming environment, the Alligator project goes towards such direction.
The data-flow programming language used is very simple and guides the user in program composition. When dealing with users who are not experienced at using computers, data-flow visual programming can play a very important role, as it is generally simpler and more intuitive than the "traditional" (textual) one. In a previous work , we demonstrated that, by composing simple data-flow visual programs through the VIPERS programming environment , it becomes especially easy to build simple Web applications. Alligator goes a step further, by allowing the user to work within a Web site (without the need for installing any specific program) and by providing a distributed mechanism for the execution of functional elements ("blocks").
The Alligator visual programming environment is basically characterized by two frames, one showing the available libraries (on the left), the other displaying the programming area (on the right). Pages relative to libraries are dynamically generated by the Alligator's main server, where all the blocks available for program composition (whether they reside on the main server itself or have corresponding functionalities provided by other machines) are stored in a database. By selecting a specific library, the corresponding blocks are displayed in a page in the left frame (Figure 1).
By choosing any block in a library and clicking on a cell of the programming grid, the block is placed in it. The visual program is therefore built, which results in a special data-flow graph without explicit links. Graphically, blocks appear to be fitted one in the other, like in LEGO® building blocks (from which the name Alligator stems), and data is intended to flow from up to bottom. The use of this simple strategy eliminates the undesired "spaghetti" effect typical of data-flow graphs. Each block is characterized by an icon, enclosed within a colored frame, reminding its function.
Alligator is a client-server application composed of three kinds of machines: the main server, execution servers and clients. Clients are the user machines, i.e. those on which visual programming is carried out through a Web browser. The main server takes care of managing requests from clients and invoking processings on execution servers, where the actual execution of some blocks occurs. Execution servers take also care of returning their results to the main server. The architecture just proposed is schematically represented in Figure 2.
The main server's functioning is based on dynamic pages written in CFML (ColdFusion Markup Language, a powerful extension to standard HTML). Moreover, two databases are exploited, the first containing information relative to execution servers and blocks provided by them, the second holding codes, data and parameters of visual programs.
We have tested Alligator in different application scenarios, such as Web applications development and basic image processing. For example, Figure 3 shows a program which receives a JPEG image and, after converting it into the PGM (8 bit gray levels) format, produces its histogram (indicating the distribution of gray levels over the 256 possible values).
A second histogram is then calculated for the same image after it has been normalized, to show the difference. Referring to the figure, from top to bottom, blocks have the following purposes. After requesting to the user the path name of a JPEG image file, the first block sends it to the Alligator main server, where it is converted into the PGM format (second block). At this point, processing follows two different paths. In the left branch of the graph, the converted image is saved (so that it can be displayed in the result page), the gray levels histogram is extracted and then it too is saved. The same processing is carried out in the right branch, but, this time, after a normalization. Block STOP, at last, halts program execution.
In this paper we have described Alligator, a system for distributed Web-based data-flow visual programming. By allowing blocks' functionalities to be defined anywhere within the Internet, the system lends itself to incremental library development, thus becoming exploitable for a large variety of potential applications (which we will explore shortly).
Some aspects of the project are still in a development stage and will be the object of future research. In particular, usability tests we will carry out on the implemented prototype will allow the human-machine interface and the interaction mechanism to be better defined.