Building Digital Experiences: AIML vs Inform


of the myriad lessons from this class I have taken is how to best design an experience for a program’s user. Two languages I’ve learned for projects have been more keen on developing my ability to author such an experience: Inform and AIML. Both allow the user to explore stories, and thus making the experience as important as the content; however, each is suited to allow the user to explore a particular type of story: Inform, a digital space, and AIML, a personality.

Both Inform and AIML are geared for authoring rather than building. I see building a program as the process of starting with a very large library of more abstract tools/methods/classes to create anything; whereas, I consider authoring to be about using a smaller set of tools to accomplish something more specific. Authoring would therefore allow more focus on creating the experience than making the program exist and function properly.

Inform is stronger and easier to create an experience for the user than AIML thanks to its larger library and functionality. A digital space story is composed of the space itself, navigational abilities, objects to interact with, personalities to interact with, and the plot itself. The plot, a composite artifact, is not explicitly typed in; rather, it is created by the order in which the user is allowed to interact with these constituent materials. Many of the functions shared by high-level languages like Java and C are available in its own Inform flavor.

AIML fails especially here, lacking many functional analogs to what most programmers take for granted: flexible code. Loops are difficult to construct or unavailable, readability is poor, and input must be handled with the utmost explication. On the user’s end, the program is as clean as it could be; however, on the programmer’s end, the AIML environment is rather unpleasant. The story authored here is based on a constructed personality for the user to chat with. Every situation must be accounted for in the code to make a successful chatterbot. The easiest way to ensure this is to use wildcards (“*” or “_” in AIML) with other keywords; however, AIML has a rather lame parsing ability, lacking string searching and thus an “includes” method. In order to find a particular keyword in a sentence, four blocks of code must be used to determine whether the string includes that keyword: beginning of string, middle of string, end of string, and itself as a string. The verbosity of AIML is incovenient for general handling; however, this does allow flexibility for a very specific response for a very specific input.

Aside from these more specific cases, the overall environment and feel of programming in these two languages differ in flow. Not too unlike Perl poetry and linguistic arts, the readability of a language is a sort of double coding in that the reader abstracts the program’s typed code to relative ideas to the reader. This way, the reader can easily understand its purpose and flow. Inform succeeds in this way with very simple and followable terminology combined with the same flow as writing a story to be read. Ideally, a programming language should read this way – as if it were a story written for a book. The issue with this is brevity; easily attainable with the terse single-character operators (e.g. curly brackets, colons, mathematical operators) of many languages, but hard for more verbose applications like spoken language.

Despite some problems with verbosity, Inform is very easy to start from a skeleton and work up to a complex story complete with interactive objects. As recommended in our Inform project, the programmer may start with a room diagram and duly code skeleton, adding people and objects as successive phases. Finally, once all nouns (spaces, characters, objects) are instantiated, the plot glue that is narrative, interaction, and descriptions may connect all these to allow the user to traverse them. Inform is superior to AIML in the ability for one situation to follow another thanks to its more robust code encapsulation via rooms.

AIML is not quite as skilled with keeping things tidy, as the only way to prevent one response from overriding another is by ordering the response in the code itself and providing <that> or <topic> clues for the compiler to recognize as the user inputs information. Also in Inform, the programmer creates the experience and lays out all possibilities (and by extension, valid input) for the user. This is somewhat similar in AIML; however, while the programmer still creates the story (the personality), it is the user who creates all the input and it is up to the programmer to account for as many different inputs as possible and make the experiences convincing enough to pass as an experience. This responsibility can lead to hundreds of lines of very similar code that accounts for minor variations in user input; however, the flexibility of specific responses is where the planning and robustness lie in AIML.

Both Inform and AIML are excellent tools for introducing the user experience-centric view of creating a program, and each are better at creating a program with a perspective of such a view: story and scope in Inform, and feedback and immersion in AIML. On the programming side, they have their own nuances that indicate what they are more suited for, and it is obvious what may not translate well in such an environment. With this in mind, the programmer can use each language’s strengths to build a program most suited for creating experience-rich programs.