Dr. Dobb's Journal August 1999
Although I've been following visual programming tools for several years, I've never found a visual tool that met all my requirements. For instance, because I'm now a part-time programmer, I don't have time to learn a new language well enough to use it only once in a while. (I was a full-time software engineer for several years, writing real-time assembly/high-level language software for medical devices and security/control systems.) In addition to the difficulties inherent in learning another language, I have been avoiding writing software for the alternately hostile and helpful Windows environment. Writing software for PCs just isn't practical for me (beyond DOS batch files), even with mostly visual tools such as Visual Basic, Visual C/C++, Java, and the like.
Of course, simplified, nonvisual batch, macro, and scripting languages are less complex than standard languages, but I already have to use several macro/scripting languages (as part of the products I work with) and I'm just not excited about adding one more unless there are major benefits.
As a rehabilitation engineer, however, I constantly need to create small programs for my clients -- people with disabilities. These clients often have little or no exposure to technology, including typing. I also need to create temporary training programs to help people get up to speed very quickly with unfamiliar equipment and programs. Clients who are completely blind, have low vision, are physically impaired, or have mental limitations need the most custom software, even when they use assistive technology designed for them (for more information, see the accompanying text box entitled "Assistive Technology"). This is especially important when I am accommodating a new job for a person with a significant disability. In some situations, I am called upon to increase a person's productivity so that he or she can retain a job or continue to attend college.
Consequently, when it comes to programming tools, I need maximum productivity with minimum time invested. Luckily, I ran across Sanscript.
Sanscript, from Northwoods Software (http://www.trulyvisual.com/), is a fully visual scripting tool that requires zero coding. Scripts (called "flowgrams") are assembled from graphic functions connected together in a dataflow-like diagram. This approach is partly what attracted me to Sanscript; it's similar to dataflow and controlflow design methods. Data-driven tools are also easier to use (especially for beginning users) than event-driven systems, although admittedly not as powerful.
The functions are the primary component of Sanscript. Functions are represented by icons that include labels, inlets (data-entry points), outlets (where data leaves the functions), and other appropriate symbols. The icons indicate the action of the function; this works out better than I would have expected.
The premade functions include drive, path, directory and file management, text/string handlers, integer and decimal number tools, system utilities, and user-interface components. There are also functions for working with the Windows Registry, data lists, and compound data records. Sanscript Pro also includes functions for OLE/DDE that provide a mechanism to work with objects in other applications. There are over 200 functions provided; while this doesn't sound impressive, I'd guess Sanscript's designers asked, "What are the 200 most common functions that people really need?" In addition, Sanscript's web site provides additional functions for use with mainstream applications.
As Figure 1 shows, the Sanscript development environment consists of Overview, Catalog, and Canvas windows. The Overview and Catalog areas list folders of premade functions and example flowgrams. The Overview window can also display a top-down tree view of a more complex flowgram, which keeps the visible part of a flowgram down to a reasonable level of complexity. The Canvas window is where functions are wired together into flowgrams, which can be run and tested within the development environment. The Canvas expands automatically for larger flowgrams.
Building a flowgram is straightforward: You drag functions to the Canvas and draw lines between the inlets and outlets to route data. A "Hello World!" program is composed of a text constant and a Display Message function, connected with one line, which requires less than 10 seconds to complete.
Lines drawn between inlets and outlets tend to "snap" into appropriate locations automatically. Lines can be moved, stretched, and deleted in a simple CAD-like fashion and are automatically preserved as functions are moved around the Canvas. If you try to connect the wrong type of data to a function's inlet, an error message informs you that it can't be done -- and the improper line is automatically removed.
Some types of data are automatically converted when routed to a function's inlet; a small circle is placed in the line to provide a visual hint that data conversion occurs. The documentation warns that some automatic conversions can lose data, such as truncating a decimal number when it is changed to an integer. (This is one of the few places that I can see a nontechnical user getting confused.) You could say that Sanscript isn't a strongly typed language -- it's "automatically" typed. This is a major convenience to beginning users.
Comments, bug notes, and To Do items can be stored with flowgrams as text boxes. A Find feature can search through these boxes, as well as in function names and descriptions, inlets, outlets, constants, and catalogs.
Forms can also be inserted into a flowgram for more complex user interactions; several form controls (labels, buttons, text fields, and the like) are provided as well. I did have some trouble with manipulating forms; adding text fields caused several lock-ups. However, I contacted Northwoods Software and an update appears to fix this problem.
Sanscript's documentation is primarily contained in Sanscript.pdf, a downloadable User's Manual. While there's a fair amount of examples and lots of step-by-step instructions for basic tasks, there's less background material as to why a particular feature is useful. I'd like to see more screen snapshots and diagrams as well. There's also a downloadable Sansref.pdf reference composed of the Help entries for each function. The built-in function Help is more convenient to use, although it has a few typos here and there.
I have many blind clients who rely on screenreading programs to analyze a screen's contents, then send the most important information to an external speech synthesizer. The synthesizer then announces the information aloud to the user. (This is a lot like having someone read screens to you over the phone -- except you can't ask any questions.) When someone is just learning to use this equipment, such as one of my clients named Brian, they often forget to turn on the speech synthesizer -- resulting in a completely silent, apparently dead computer. (Remember, blind individuals don't see indicator lights; if the synthesizer is off, they won't hear any error messages either.) I wanted to audibly remind new screenreader users to turn on their synthesizers, but I couldn't find a good way to do this.
Browsing through Sanscript's folders, I found a Send Keys function that I could use to control another program. A text constant can send its data to the Send Keys function, which then sends the data as keystrokes to another program. If I recorded my reminder as a sound file, I could play it back with the Windows 95 Sound Recorder or Media Player applet. I also found a test program for this function in the System Example folder; I quickly modified it to play the .wav file ("Please turn on your synthesizer!") I created with Sound Recorder. The completed flowgram starts the Media Player with the prerecorded synth.wav file, plays it, closes Media Player, and starts the Window-Eyes screenreader; Figure 2 shows a portion of this flowgram. Note the dotted lines connecting functions in this flowgram; they represent control flow. The control flow is not shown by default; it is displayed by turning on the View Ordering Links option. Now Brian won't forget to turn on his synthesizer and I won't get any more panicky phone calls. (Did I mention that Brian lives about 200 miles away from my office?)
Another reminder program I needed was for Jayna, a low-vision client who has difficulty with directory locations. She uses a screen magnification program and an extra-large screen (31 inches) to enlarge the characters on her computer screen. This unusual equipment allows her to read her computer screen, but her vision is low enough (20/1600) that the characters must be about 5 inches high. As a result, she can see few characters at a time. (Try reading this article through a hole the size of a dime and you'll get an idea of how hard this is.)
To assist Jayna, I created another flowgram (Figure 3) and dragged a Display Message function to the Canvas. I double-clicked the Canvas to create a constant and typed in the reminder's text. I dragged the constant's outlet to the Display Message inlet so the text would be passed to the function. I then dragged in a Launch Application function to start the word processor she uses. Finally, I connected the Ordering links to force control to flow from Display Message to Launch Application, which means that Jayna will have to dismiss the message box (by pressing Enter) before the word processor can start.
To turn this flowgram into an application, select Make Application...under the File menu. Sanscript automatically creates a new folder for the application or you can select a different one. A confirmation box is displayed when the application is complete. The Remember application was created in less than a second. Sanscript also creates a shortcut and a DOS batch file to run this program. I just renamed the shortcut to "word processor" and placed it in the Start Menu's list of programs. When Jayna runs her word processor, she'll always see this reminder first.
Sanscript includes basic debugging features. The debug commands are basic but fairly complete; it's possible to single-step through a flowgram, jump into or over functions, and examine inlet and outlet data. The data is viewed by simply pointing the mouse cursor at an inlet or outlet; the value appears in a tooltip-style floating box. Also, pauses can be inserted in flowgrams to provide a breakpoint-like mechanism in complex or fast-moving programs. Of course, it's also easy to temporarily insert a Display Message function to show data at any point in a flowgram.
Sanscript also tries to make reuse of flowgrams easy; you can package a flowgram that performs a handy function and use it in other scripts. For example, there are fairly powerful error-handling functions that could announce errors in more understandable terms. (I always want to change error messages from the cryptic "Drive not ready" to something like "Please check drive A:. There may not be a disk in it. Press ENTER to try reading this disk again.") A general error handler could be created and stored in a package for consistent error processing among several scripts.
As someone who still uses DOS routinely, I was glad to see that Sanscript provides a way to use DOS commands when necessary. For example, I recently needed a simple program to duplicate floppy disks for Jason, a physically impaired client. While I was able to provide him with a way to use a pointing device, he cannot drag-and-drop files in Windows Explorer (even though he can change floppies).
The Quickcopy flowgram (Figure 4) creates a temporary directory, prompts users for the original disk, and copies all the files on the floppy to the temporary directory with a Run DOS Command function. Then users are prompted to insert a duplicate disk and the files are copied onto it. Finally, the temporary directory and files are removed. I used the Run DOS Command function simply because it was easier for me to throw in the DOS command to copy all files and directories. I'm sure that you can use Sanscript functions for this as well, but the goal of this tool is to save me time -- so why not use commands that I already know? I also realize that this program could have been written entirely as a DOS batch file, but Jason uses special Windows software to access his computer that can't see DOS messages or prompts.
I was recently asked for a typing drill program for blind individuals. Popular typing tutorials use floating cursors, animation, moving pointers, and other methods to indicate the letters and words to type. Unfortunately, these programs aren't compatible with screenreaders, which read the screen's contents out loud to users. I was looking for a way to display just a few letters or words at a time, set up the screenreader to announce them automatically, and then let users type them in. There should be no distractions; no ergonomic instructions, extraneous buttons, or status bar hints. This would simply be a screenreader-compatible typing program.
I decided to store the typing drills in a text file for easy revisions. In addition, the drills could be tailored for beginners or more advanced users who needed practice on certain keystrokes, such as the punctuation symbols. (I also recommend nonQWERTY keyboards on occasion; these keyboards may have an alphabetical arrangement or a frequency-of-use layout.)
Sanscript provides a File Open dialog box for an instructor to pick a drill file; default paths, filenames, and file extensions may be used to indicate where the drill files are located (see Figure 5). After a file is loaded, a form prompts the user to begin by pressing Enter.
A Repeat function encloses the Read Line function (emulating a subroutine), which pulls each line from the file and sends it to a form for display (Figure 6). This form is completely bare; only a text field shows the letters to be typed. (The screenreader reads them automatically.) Note the Filename connectors used to pass information in and out of this flowgram. These connectors appear on the higher-level view of this function as well. The Index connector is simply an indicator of the Repeat function that cannot be deleted. It can be connected to other functions, however.
The Read Line function terminates when an End-Of-File character is found; a Stop Repeat terminator forces a halt on activation. Control is then returned to the calling flowgram, which closes the file and presents a signoff message by labeling a button.
The letters entered by users are discarded; a future enhancement of this program would be to count the incorrect keystrokes. (I don't always want people to know how many mistakes they make -- especially when they're just learning.)
The training specialists I work with were enthusiastic about this program, especially since they can create any type of drills with Notepad. Also, this program can be used by low-vision clients who use screen-magnification programs, which also have great difficulty with standard typing tutorials.
Sanscript is much more powerful than I would have guessed. I like the intuitive operation; almost everything works as I expect it to. Sanscript's designers have carefully hidden unimportant program details and let you concentrate on a program's logic. The ability to quickly run and debug a flowgram within Sanscript's development environment is another plus, as well as the quick generation of an application. I'm still planning to create more reusable components and explore the DDE/OLE capabilities. I think the real power of Sanscript may be in its ability to simplify OLE, which doesn't strike me as easy to use at all.
While I did experience some minor trouble with installation and a few function bugs (that have already been corrected), I can't think of a glaring omission or major problem I ran into. I would like to see additional functions added in the future, although so far I have found a function for about everything I've needed. Additional background information on the advanced DDE/OLE features could allow more users to reap their benefits; I'd guess that most people who are attracted to Sanscript won't be able to handle this part of it.
In short, Sanscript is a great tool for someone like me who doesn't need or want to master a standard language. Sanscript strikes me as what I'd have created if I could. It's powerful enough to be useful and simple enough to be fast. I can't imagine how another tool could further simplify visual software creation and still accomplish useful work. Isn't this what software development is supposed to be?
DDJ