Précis: Usability Analysis of Visual Programming Environments …

Before changing topic, here is a paper that goes a more into cognitive dimensions.

T. R. G. Green and M. Petre: Usability Analysis of Visual Programming Environments: a ‘cognitive dimensions’ framework. Journal of Visual Languages and Computing, Vol. 7, No. 2, pages 131-174 (1996).

The complexity of programming environments is not handled well by HCI techniques, which take into account low-level details. In an attempt to illustrate cognitive dimensions approach, the authors perform an exhaustive analysis of the visual programming languages LabView and Prograph. These are also compared with Basic to emphasize differences with respect to text-based languages.

The authors characterize LabView, Prograph and Basic in terms of thirteen cognitive dimensions. The way information is presented is described by the following dimensions: closeness of mapping, abstraction gradient, role-expressiveness, secondary notation, hidden dependencies and diffuseness. Other dimensions related more to the effort required from the user include consistency, visibility, error-proneness, hard mental operations, premature commitment, progressive evaluation, and viscosity. In general the dimensions are utilized to organize the analysis but this does not diminish the need for references or experimental data.

The interrelations between different dimensions are explored, specifically, the influence of the level of abstraction on resistance to local changes; the distance between the notation and the problem domain; the complexity of mental operations; and the visibility of code portions and dependencies. However, future work is necessary to define the relations between dimensions precisely and to decrease the degree of intersection between them.

The authors conclude that cognitive dimensions should be used in combination with GOMS and programming walking analyses. These two other approaches will make it possible to evaluate low-level details of interaction and to assess how much knowledge is required from users.


Précis: Cognitive dimensions of notations

This week précis is not related to how developers use diagrams but to possible methods to evaluate notations according to their usability.

Green, T. R. G.: Cognitive dimensions of notations. In Proceedings of the Fifth Conference of the British Computer Society, Human-Computer interaction Specialist Group on People and Computers V (Univ. of Nottingham), pages 443 – 460. A. Sutcliffe and L. Macaulay, Eds. Cambridge University Press (1989).

Usability studies have been described in a significant number of papers, but the need for general methodologies persists. The author proposes the concept of cognitive dimensions as a partially conceived tool for evaluating in the context of programming languages how well a notation can assist its users.

Cognitive dimensions are defined as attributes that depict the structure in which information is presented. The principal examples of dimensions discussed in this paper are related to the visibility of dependencies, the resistance to local changes, the risk of premature commitments, the differentiation between roles, and the inability to avoid complex mental operations. However, this set of dimensions is not complete and should be refined taking into account the iterative and unpredictable order that governs the designing process.

Based on the characterization of object oriented languages through cognitive dimensions, the author concludes that these dimensions can be utilized to argue about practical problems. Moreover, he emphasizes that the environment supporting the notation must be taken into account.

This is an introductory paper that illustrates with examples the implications of particular features in programming language notations. Though the methodology behind cognitive dimensions is not clearly defined, the vocabulary presented is still in use.

Précis: Let’s Go to the Whiteboard …

The following is the first précis I had to write on the Scientific Writing course that I am taking this summer:

Cherubini, M., Venolia, G., DeLine, R., and Ko, A. J.: Let’s go to the whiteboard: how and why software developers use drawings. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, pages 557-566, published by ACM. (2007)

Regardless of existing knowledge about the use of diagrams in other fields, their application in software development has not been explored. The authors carried out a study to determine the reasons which lead developers to draw diagrams, and to reveal details about the context in which the diagrams are produced. This study was conducted at Microsoft Corporation and included nine interviews with developers who use diagrams often. To validate the feedback, the authors developed a survey and administered it to 427 employees of this corporation.

During the interviews, eight software development tasks were identified as those in which diagrams are typically utilized: the comprehension of existing code; the design previous to the implementation of a feature or a bug fix; discussions about complex changes; spontaneous meetings among developers; the training of novices; interactions with customers; discussions with other interested parties; and the creation of documentation.

Based on an analysis of quantitative data from the survey, the authors concluded that there was infrequent use of standard notation, computerized drawing tools, and reverse engineering tools. For the eight software tasks, whiteboards were the most common means for producing diagrams. However, among all the activities, the use of reverse engineering tools was more frequent in the creation of documentation, analysis of complex designs, training of novices, and the study of existing code.

Unfortunately, other results derived from the interviews will need to be validated because the number of participants was small.


Data collection and the Graduate Scientific Writing Course

Ten days ago I received the approval from the Office of Research Ethics. A lot of people have read my call for participants and today I will meet my 7th participant. During the next weeks I will be meeting all the people with basic knowledge in database queries that want/can participate in the study (let me know if you are interested). Since each participation takes around 30 minutes, I had too much free time (really!). That’s why I just enrolled in the scientific writing course that is taking place this summer at the Bahen Centre.

I will try to get the books I need for the course as soon as possible because it started on May 4, and I am two lectures late. Tonight I will be working on my first assignment (due this Friday) and going through the course’s instruction manual. I love language courses (probably because I have good memories from the ones I took in Cuba), and after meeting with the professor I think that I will learn a lot in this one.

Call for Participants!

Query by Example

While representing a database query, one of the alternatives is to use fake data (i.e. examples of data) that does not necessary fill all the cell of the tables. In this approach we iteratively exclude rows according to the values of the columns mentioned in the WHERE/HAVING/ON clause. The exclusion of rows can be done either with different marks over one table or by drawing a set of intermediate tables.

The distinctive feature, of this way of representation, is that the fake data is generated such that it makes the representation as unambiguous as possible — though this is not achieved all the time. It is possible (not proved yet) that the process of generating this fake data helps the programmer to reason about the database query.

One of the assignments I got from the last meeting with my supervisor was to check if this was related to the use of the term “query by example” in the literature. Let’s see what I found.

Unlike what the name suggests, “query by example” is associated, in Raghu Ramakrishnan and Johannes Gehrke’s “Database Management Systems” book, to a database query language developed at IBM, in which each query is represented by tables that only contain data directly extracted from the query. Let’s analyze the representation of one query to see some of the main characteristics of this language:

Sailors sid sname rating age
_Id > 25
Reserves sid bid day
_Id _B ‘8/24/96’
Boats bid bname color
.UNIQ _B Interlake P.

This query find the colors of “Interlake” boats reserved by sailors who have reserved a boat for 8/24/96 and who are older than 25. The notation uses “P.” to denote which columns are selected, “.UNQ” to represent the DISTINCT clause, variables like “_Id” and “_B” to represent values that must be equal, and literals with comparison operators to represent the WHERE clause.

See also:

Experimental Setup

In the past days I have been considering several options about how to record the order in which the elements of the diagrams were drawn. After a few experiments with laptops, PCs, webcams, rolls of paper tower, walls, rotating chairs and a transparency projector, I have a nice setup at my desk: a webcam over the display, a bunch of papers and pens in the table and cheese taking photos (it is simple but it works really well). Two of the three computers in which I have tested the webcam were unable to record video. However, that is not going to be a problem in this case, since a set of pictures will be enough. As the last “ingredient”, here is the script that I am using to make Cheese take pictures until I stop it. I uploaded and example of the pictures that I will be able to capture to

PS: I submitted a second version of the ethics forms today after receiving comments from the Office of Research Office.

See Also: