To enable a broad group of Web users to start creating applications, consumer programming is based on defining sequences of actions on graphical user interfaces of existing Web applications that act as components. An example of these applications are software widgets which are Web applications with a small graphical interface intended to be used on a container page like iGoogle, but the concept easily generalizes to more general web apps. As Web users interact with these applications on a daily basis through the same GUI, they understand all the intricacies of the interface and how it is supposed to be used. Therefore, defining actions that combine several of these applications giving rise to new and innovative functionality doesn’t require insight into software engineerig practices.
However, one of the challenges that arises in this environment is the overwhelming number of components avaliable for use. For example, there may be multiple components that provide similar functionality, and some of them might be more suitable for composition than others. Furthermore, the user might sometimes be completely unaware that some functionality exists in a component, but having had that information might have come up with an innovative way to use it.
One way to address these challenges is to design a system that recommends components to consumers. The basis for such a system is analysis of existing consumer programs. As consumer programs are based on connections between components, they can be represented by graph-like structures, from lists and trees, to undirected and directed graphs. These representations enable different kinds of analyses to be performed on the program database.
For example, as mentioned above, it would be useful to know that certain components are similar in functionality. However, most of these components are opaque to the system in the sense that they are JavaScript programs whose semantics can’t be automatically understood. A measure of similarity can be inferred from how these components are used in existing consumer programs. Informally, if they are often used in similar context, it is likely that they are in fact similar in some way.
Another example goal of program analysis would be to discover groups of components that are often used together or in a specific pattern. This information can also be useful for recommendation. If the consumer is composing an application from a set of components and there is a component that often appears side by side with some of these components, it might be useful to the consumer.
Several challenges arise in defining these analysis goals and reaching them.
- How to model the consumer programming process, i.e. the way that consumers create these compositions? This is important because different kinds of components might be preferrable recommendations at different stages of application development. Furthermore, this model is important for evaluating recommendations in a lab environment.
- What is the best representation of a program for a given goal? Representations that preserve more information about programs are inherently more complex which usually implies that analyses on them are prohibitivly expenssive over the entire program database. On the other hand, simpler representations are less expressive and provide less information about the program.
- What algorithms can be used on a representation to extract useful information?
We are researching all of these challenges with the ultimate goal of creating a component recommender system based on inferred component functionality and similarity.
