Petre, M. Why Looking Isn't Always Seeing: Readership Skills and Graphical Programming. Comm. ACM 38, 6 (June 1995) 33-44.  Home/Search   Document Not in Database   Summary   ACM   TOC   Related Articles   Check

....is especially important to a user s task, or if it is highly critical to the overall structure of the information, it is helpful to present a high level view in a perceptual form, while simultaneously presenting the intricate details in symbolic notation. Blackwell et al. BWG99] and Petre [Pet95] have proposed some cognitive dimensions for visual language design. Example dimensions are closeness of mapping, consistency, and visibility. Storey et al. developed a cognitive framework of design elements to be considered during the design of a software visualization tool [SFM99] This ....

....transitions even though all the information in the overview could be deduced from the structure and content of the rest of the specification. This is an example of the gestalt effect in cognitive psychology in which providing an overview makes overall structure or relationships visible or clearer [Pet95]. 6) Support alternative problem solving strategies A principle of cognitive psychology is that the reasoning paradigm is distinct from the representation paradigm. The cost of reasoning about a particular representation may vary, depending on how the programmer s reasoning shifts [BWG99] ....

[Article contains additional citation context not shown here]

M Petre, "Why Looking Isn't Always Seeing: Readership Skills and Graphical Programming", Comm. of the ACM, 38(6):33-44, June 1995.

....computer systems present time series data to human users either graphically or as tables. In contrast, when a human presents time series data to another human, he or she often uses language to do so. This is especially true when the recipient does not have a lot of domain expertise; as Petre [11] pointed out, graphical presentations of information often work better for experts than for novices. Textual summaries are also useful when information (such as weather and stock market reports) needs to be communicated over low bandwidth devices such as mobile phones. We are developing ....

Petre, M. Why Looking Isn't Always Seeing: Readership Skills and Graphical Programming. Communications of the ACM, 38(6), pp.33-44, 1995.

....can include in a program to clarify its meaning, such as comments in traditional languages. Changing an instance of secondary notation, such as a textual comment, does not change a program s behavior. Petre argues that secondary notation is crucial to the comprehensibility of graphical notations [Petre 1995]. The use of secondary notations allows clarifications and emphases of important information such as structure and relationships. Four such devices are measured by SN1 and SN2: optional naming, layout devices with no semantic impact, textual annotations and comments, and static 44 graphical ....

M. Petre, Why Looking Isn't Always Seeing: Readership Skills and Graphical Programming, Communications of the ACM 38(6), June 1995, 3344.

....comprehension [2, 5] By supporting welldefined cognitive processes employed during a comprehension task, graphical representations of software could have a beneficial effect on comprehension efficiency and effectiveness. Visualization in and of itself, however, is not necessarily beneficial [9]. There are many issues that influence the utility of software visualization. Some are practical and cognitive issues relating to the user of the visualization and the process of human comprehension [1, 4, 13] Other issues include those which relate to the nature of a particular visualization ....

Petre, Marian (1995). Why looking isn't always seeing: readership skills and graphical programming. Communications of the ACM, 38, 6, pp. 33-44.

.... It has been suggested, for instance, that graphs of software structure are more readily understood without extensive training and effort [509] Research on graph based representations have instead indicated that graphbased representations require years of experience to read properly [506, 509]. Thus some graphical representations may be easy to read due to extended experience and familiarity, rather than due to inherent qualities of the graphical representation. Now imagine a tools researcher explaining their good performance as being a result of the natural superiority of graphical ....

Petre, M. Why looking isn't always seeing: Readership skills and graphical programming. Communications of the ACM, 38(6), June 1995, pp. 33--44.

....during system development. Aesthetics and secondary notation: Since descriptions of conceptual architectures are made for the human reader, informal criteria for diagram quality must not be ignored. Valuable layout cues, called secondary notation, are crucial for comprehensibility [8]. Architectural diagrams will be studied by many persons, so making a clear and appealing layout is worth the effort. Therefore, the notational elements of an architectural description technique should support proper layout including the easy formation of graphical patterns. 3. The FMC approach ....

M. Petre, "Why Looking Isn't Always Seeing: Readership Skills and Graphical Programming", Communications of the ACM, vol. 38, no. 6, June 1995, pp. 33-44.

....and for presenting it in such a way so that details can be ignored where needed. However, graphical notations, by virtue of using their layout for imparting information, rather than textual symbols, suffer more from secondary notation, such as layout and typographic cues, than textual notations [21]. It is this secondary notation that sometimes appeals to users, and causes confusion in interpreting such notations. We aim to avoid use of secondary notation in the design of our graphical notation. 3 Overview of Timed CSP We will now describe the textual notation of Timed CSP. Timed CSP has a ....

M. Petre. Why looking isn't always seeing: Readership skills and graphical programming. Communications of the ACM, 38(6):33--44, June 1995.

....regardless of what language people speak. However, empirical studies did not find visual programming inherently superior to text based programs; the extent to which a given notation is suitable for expressing a particular task depends on the context in which the language is employed [3, 4, 5]. Early work on visual programming, although promising when applied to toy problems, ran into difficulties when the methods were tried on problems of realistic size. Two approaches for alleviating this problem were followed: a number of researchers applied visual programming languages to limited ....

M. Petre. Why looking isn't always seeing: Readership skills and graphical programming. Communications of the ACM, 38(6):33--44, June 1995.

....underlie this pursuit: graphical representations are better than textual explanations, and dynamic graphics is better than static graphics. But either of these is far from obvious [1] For instance, Petre persuasively argues that reading graphics is an acquired skill that experts are better at [2], a notion at odds with the often unstated assumption that novice students will grasp an algorithm better if it is graphically presented. Such concerns aside, most algorithm animation research papers present interesting algorithm animations or novel systems for creating and viewing algorithm ....

M. Petre (1995) Why looking isn't always seeing: Readership skills and graphical programming. Communications of the ACM 38, 33-44.

....between different areas that exists in the mind of designers and users, i.e. on a metaphor. Many designers and users implicitly assume that visualization is helpful only because it provides clear visual images, although some researches are skeptical about this still popular approach (for example, [27, 28]) At present, it is rarely discussed which visualization is needed (it is assumed that good visualization is needed, or standard methods are used) There is a number of works studying both design techniques and quality evaluation of visualization systems. However, these works are usually based ....

Petre M. Why looking isn't always seeing: readership skills and graphical programming // Communications of the ACM. Volume 38, No. 6 (June 1995) pp. 33-44

....channels. The main limitations of this approach is that the designer has to use two visual representations, and the structure description contains too little information about the program behaviour to allow analysis and evaluation [6] Another important issue has been discussed in a recent study [7] which has shown that the adoption of a graphical representation instead of a conventional textual representation can sometimes reduce productivity even in (traditionally) graphical appli cations such as circuit design. One reason can be the complexity of the graphical representation but also ....

....Receive Action Send Action Parameters for the Send Action Text Associated with the Send Action Figure 1: Representing components and actions. at which the actions are executed. It is not our intention to provide a fully visual language, especially considering the results presented in [7], which show that visual languages should be supported by certain textual representation. In our language, only the essential behavioural aspects (actions) are represented visually. The other details, usually the sequential code, are described textually. In the current version of our language, ....

M. Petre. Why looking isn't always seeing: Readership skills and graphical programming. Communications of ACM, 38(6):33--44, June 1995.

....starting point is a method based on the graphical representation of the design which provides rules for verification and transformation. It is important to point out that, unlike many graphical programming notations, ours has a 1 occam is a registered trademark of INMOS Limited. formal semantics [16]. The method also encompasses important software engineering principles. It did not include, however, any performance engineering activity. This paper explains how certain steps were added to the method to allow the generation of performance measurements which can guide the designer when taking ....

M. Petre. Why looking isn't always seeing: Readership skills and graphical programming. Communications of ACM, 38(6):33--44, June 1995.

....the criteria with which we judge the utility of a visualization. Finally, we put it all together into a three step approach for e#ective visualization design. 4. 1 Overview Perhaps one reason why the visual representation of information has been shown to not always be e#ective [Larkin Simon 87, Petre 95, Vessey 91] is that very little research has focused on the factors that make a visualization useful. Only in the last 10 15 years, as the amount and availability of data has dramatically increased, have researchers begun to focus on the utility of visual designs. Yet we are still absent a ....

....experts. To achieve this goal, our preliminary system requires user specifications of the base type and data requirements. It then determines the assignment of the data sets and data values to appropriate encoding methods. As discussed previously and demonstrated by many research e#orts [Petre 95, 92 UrbanView Figure 5.4: Specification interface for a bar graph visualization. Larkin Simon 87, Tukey et al. 90, Pinnel et al. 99] the utility of a visualization is dependent on an individual s preferences and experience. Thus, the user interface does not completely insulate the user from ....

M. Petre. Why looking isn't always seeing: Readership skills and graphical programming. Com. of the ACM, 38(6):33--44, June 1995.

....a more familiar representation of the knowledge be ing constructed. Despite the well known disadvantages of natural language as a knowledge representation language, there is strong evidence to suggest that text offers a clear advantage over graphics for understanding complex knowledge structures [ Petre, 1995 ] This problem thus becomes one of how to achieve symbolic authoring with the advantage of a textual interface but with none of the disadvantages of textual interpretation that continue to hound Machine Translation. 3 Authoring multilingual documents with wysiwym This talk presents a new ....

M. Petre. Why looking isn't always seeing: readership skills and graphical programming. Communications of the ACM, 38(6):33--42, 1995.

....to effectively convey these components and their interactions, and allow developers to focus their attention on parts of a system at any time. However, primarily textual modeling languages, such as CSP or B, achieve these intended uses more concisely without the problems of secondary notation [26]. It is this secondary notation (e.g. layout and typographic cues) that sometimes appeals to users, and causes confusion in interpreting graphical notations. There is an increasing amount of work on the subject of visualisation in a software development context [7,8,25] It is largely ....

Petre, M. Why looking isn't always seeing: Readership skills and graphical programming. Communications of the ACM, 38(6):33--44, June 1995.

.... structures and has been used successfully in a number of cases, both by Kutar, Britton and Wilson v PPIG 2000, Cozenza Italy www.ppig.org Green himself (Green, 1991; Green, Petre Bellamy, 1991; Modugno, Green, Myers, 1994; Green Blackwell, 1996) and by other authors (Shum, 1991; Petre, 1995; Roast, 1997; Yang et al. 1997) We have, ourselves, found cognitive dimensions to be useful and effective in evaluating two different mechanisms for structuring specifications written in Z (Britton, Jones Lam, 1998) Cognitive dimensions are intended to support the evaluation of any type of ....

Petre, M. (1995). Why looking isn't always seeing: Readership skills and graphical programming.

....poor because they failed to utilise such secondary notations or, in particularly awful examples, were especially confusing through their mis use of the common layout conventions adopted by the experienced engineers. This study and others are discussed in detail in recent work by Petre [Pet95] where the relationship between textual and graphical language and their respective bene ts and limitations are presented. A major conclusion of this collection of studies is that the use of secondary notations is a signi cant contributory factor in the comprehensibility of graphical ....

....of Esfahani and Kellet [EK88] which permitted the user to structure knowledge via associative networks. While such systems often were preferable to text only interfaces the use of graphics did not generally consider human cognitive needs and as such is open to the general criticisms of Petre [Pet95] discussed previously. Consideration to cognitive needs and the ecacy of graphics was present in some systems however, as evidenced in the review of early interfaces by Jones [Jon88] Graphical interfaces for the presentation of any information are likely to be successful in any application area ....

M Petre. Why looking isn't always seeing: Readership skills and graphical programming. Communications of the ACM, 38(6):33-45, June 1995.

....textual comment, does not change a program s behavior. The benchmarks in this group are derived from the Secondary Notations CD, and are also related to the Role Expressiveness CD discussed previously. Petre argues that secondary notation is crucial to the comprehensibility of graphical notations [26]. For example, the use of secondary notations such as labeling, white space and clustering allows clarifications and emphases of important information such as structure and relationships. This group of benchmarks focuses on the subset of a VPL s secondary notational devices that are static. ....

M. Petre (1995) Why looking isn't always seeing: readership skills and graphical programming. Communications of the ACM 38, 33---44.

....their methods, generally ignore issues concerning the cognitive complexity of inference, and indeed leave out any consideration of the inferential mechanisms that operate over the sentences or diagrams of the languages whose semantics is being speci ed. Theories of the second kind (for example, [3, 12, 22, 32]) generally lack a fully speci ed formalism and semantics on which they could base a computational account of how the system of representations is embedded in a user s performance of some task. An attempt, not to claim any complete theory of diagrams, but rather to sketch a larger structure which ....

....were especially confusing through their mis use of the common layout conventions adopted by the experienced engineers. These conventions, termed secondary notations in [23] are shown in [20] to correspond directly with the graphical pragmatics of [16] More recent studies, reported in [22], of the users of various other visual languages, notably visual programming languages, have highlighted similar usage of graphical pragmatics. A major conclusion of this collection of studies is that the correct use of pragmatic features, such as layout in graph based notations, is a signi cant ....

[Article contains additional citation context not shown here]

M. Petre. Why looking isn't always seeing: Readership skills and graphical programming. Communications of the ACM, 38(6):33-45, June 1995.

....an e#ective representation is one which is well matched to what it represents. That is, an intuitive, or well matched, representation is one which clearly captures the key features of the represented artifact and furthermore simplifies various desired reasoning tasks. It has been demonstrated in [7, 20, 22] that pragmatic features of diagrammatic representations (termed secondary notations by Green [6] significantly influence their interpretation. A particular concern of the exploration of [11] was the importance of accounting for such pragmatic aspects of diagrams in considering when they are ....

.... detection (e.g. action Checks monitors the state of the lift and raises the boolean signal Fault whenever a fault occurs) More recent studies of the users of various other diagrammatic languages, notably visual programming languages, have highlighted similar usage of graphical pragmatics [22]. A major conclusion of this collection of studies is that the correct use of pragmatic features, such as layout in graph based notations, is a significant contributory factor in the comprehensibility, and hence usability, of these representations. Diagrammatic Reasoning: SFC Example One of the ....

[Article contains additional citation context not shown here]

M. Petre. Why looking isn't always seeing: Readership skills and graphical programming. Communications of the ACM, 38(6):33--45, June 1995.

.... These conventions, termed secondary notations in [12] are shown in [10] to correspond directly with the graphical pragmatics of [8] More recent studies of the users of various other visual languages, notably visual programming languages, have highlighted similar usage of graphical pragmatics [11]. A major conclusion of this collection of studies is that the correct use of pragmatic features, such as layout in graph based notations, is a significant contributory factor in the comprehensibility, and hence usability, of these representations. 2 Sequential Function Charts A concrete ....

.... of the artifact (membership of some behavioural mode) is directly captured by a representing relation in the diagram with matching logical properties (membership of a spatial region in the plane) Note that, in this case as with the expert designers of CAD diagrams and visual programs studied in [12, 11], it is the pragmatic features of the diagram (layout being chosen so as to suggest conceptual regions) which are exploited to carry this information. Indeed, in the original SFC diagram from [6] of which our example is a simplification, these regions were strikingly well delineated. Secondly, ....

M. Petre. Why looking isn't always seeing: Readership skills and graphical programming. Communications of the ACM, 38(6):33--45, June 1995.

.... conventions, termed secondary notations in [113] are shown in [110] to correspond directly with the graphical pragmatics of [94] More recent studies of the users of various other visual languages, notably visual programming languages, have highlighted similar usage of graphical pragmatics [112]. A major conclusion of this collection of studies is that the correct 98 Wait Move Start Brake Halt true Alarm Checks ChkFault Fault level=FloorCall Stopped FloorCall 0 Ready Fault Figure 6.1: Example SFC diagram (lift controller) use of pragmatic features, such as layout in graph based ....

.... of the artifact (membership of some behavioural mode) is directly captured by a representing relation in the diagram with matching logical properties (membership of a spatial region in the plane) Note that, in this case as with the expert designers of CAD diagrams and visual programs studied in [113, 112], it is the pragmatic features of the diagram (layout being chosen so as to suggest conceptual regions) which are exploited to carry this information. Indeed, in the original SFC diagram from [86] of which our example is a simplification, these regions were strikingly well delineated. Secondly, ....

[Article contains additional citation context not shown here]

M Petre. Why looking isn't always seeing: Readership skills and graphical programming. Communications of the ACM, 38(6):33--45, June 1995. 154

.... termed secondary notations in [PG92] are shown in [Obe96] to correspond directly with the graphical pragmatics of [MR90] More recent studies of the users of various other diagrammatic languages, notably visual programming languages, have highlighted similar usage of graphical pragmatics [Pet95] A major conclusion of this collection of studies is that the correct use of pragmatic features, such as layout in graph based notations, is a significant contributory factor in the comprehensibility, and hence usability, of these representations. For diagrammatic languages, and particularly ....

....concerns features and properties which impact upon the cognition of the user. These more cognitive studies have typically studied either users of highly specialised diagrams (such as Venn diagrams, and simple visual programming languages [BWGPss,Goo99,SO91,ZN94] or generic HCI issues [BG99,Gre89,Pet95] Our approach is based on the studies of [GLS98,Gur99] which seek to unify the two dimensions of these earlier studies. More recent work has demonstrated the potential, and benefits, of formalising certain pragmatic aspects of diagrammatic software engineering languages [GT99] We are not aware ....

M Petre. Why looking isnt always seeing: Readership skills and graphical programming. Communications of the ACM, 38(6):33--45, June 1995.

....classes, then the classes (and their relationships) should be visually represented. The same can be said about objects at runtime: relationships between objects are better understood when made visible. An environment should make use of both graphical and textual representations. Studies (e.g. [2]) have shown that neither text nor graphics can be considered generally superior for representation tasks. Both have their place. The advantage of adding a graphical notation is the ability to provide richer secondary cues. Graphical secondary notation (such as proximity, grouping and white space) ....

Petre, M., "Why Looking Isn't Always Seeing: Readership Skills and Graphical Programming," Communications of the ACM, 38(6): 33-44, 1995.

....entire field of IT. It is clear that in many situations string based specifications are preferable; often the common practice of using graphical schemas as a high level informal language is quite relevant so that there is no need to employ graphical images as logical schemas (see a discussion in [38]) Actually, it is a question of experience and cognitive science research which should be qualified as Problem 4: when, where and to what extent employment of graphical schemas as formal logical specifications is effective and convenient for a human. A way of studying this problem is to seek ....

M. Petre. Why looking isn't always seeing: Readership skills and graphical programming. Communications ACM, 38(6):33--44, 1995.

....name but a marker hung on the left bottom node of the schema. Semantics of the marker is to constrain the node to be the empty set. Since there is only one empty set, 5 in fact, this is a special case of the deep problem: how to facilitate understanding graphical images by the human mind (see [25]) the node s name is not essential and may be suppressed. The sketch (f) asserts disjointness of the subsets A and B of the set U . Finally, the sketch (g ) specifies a binary relation of special kind: it constitutes an association between sets A and B while markers on p and q mean that each ....

M. Petre. Why looking isn't always seeing: Readership skills and graphical programming. Communications ACM, 38(6):33--44, 1995.

....introduced in Section 5 before the final section draws the conclusion. 2 Visual Languages in Systems Design For a long time it was argued that a picture says more than thousand words . Recent works are more realistic since these 1000 words are mostly not the same for each viewer of one picture [14]. Generally, we can say that textual languages are better for precise and concise specifications whereas visual languages are more adequate for systems structuring and the representation of complex interrelationships [13] More precisely, visual languages are best for the design of complex ....

M. Petre. Why looking isn't always seeing: Readership skills and graphical programming. Communications of the ACM, 37(10), 1995.

....extended to Petri Nets [Moher93] 1 Languages such as VisualBasic and Visual C are useful for development of graphical user interfaces, but still require textual programming. Draft Do Not Cite 4 with similar results. Petre provides an excellent summary of experimental results in this area [Petre95]. 3 Experimental Design To investigate these two hypotheses, a two factor experiment was necessary: 2 programmer versus non programmer subject types, and graphic (visual) versus textual form of decision statements. This design is a variation of that of [Green92] and [Moher93] 3.1 Experimental ....

M. Petre, "Why Looking Isn't Always Seeing: Readership Skills and Graphical Programming", Communications of the ACM, vol. 38, no. 6, June 1995, pp. 45-56.

.... difficulty succeeding at it (Brown Gould, 1987; Nardi Miller, 1991; Eisenstadt, 1993) There have been several studies of other aspects of visual programming languages (Cunniff Taylor, 1987; Green, Petre, Bellamy, 1991; Moher, Mak, Blumenthal, Leventhal, 1993; Pandey Burnett, 1993; Petre, 1995; Modugno, Corbett, Myers, 1996; Whitley, 1997) but the effects of liveness on debugging (or on any other task) in these languages were not studied. Our evidence connecting liveness to engagement in enhancing the persistence with which subjects pursued bugs is consistent with the findings of ....

Petre, M. (1995). Why Looking Isn't Always Seeing: Readership Skills and Graphical Programming.

....technologies. It is clear that in many situations string based specifications are preferable, and often the common practice of using graphical schemas as a high level informal language is quite relevant so that there is no need to employ graphical images as logical schemas (see a discussion in [17]) Actually, it is a question of experience and cognitive science research: when, where and to what extent employment of graphical schemas as formal logical specifications is effective and convenient for a human. ....

M. Petre. Why looking isn't always seeing: Readership skills and graphical programming. Communications ACM, 38(6):33--44, 1995.

.... perception user s mental model action mapping query of traits extraction input User Model database data spatial update Process Information Set Information Flow Figure 9: Communication system in GIS, adapted from [LS92] Many of the cognitive issues are common to other application areas (e.g. Pet95] In fact, several researchers in mental models are concerned with the use of colors and the relative positioning of the objects in a presentation. For instance, one should take care about the intensity of adjacent colors in a presentation: depending on the contrast offered, the user may be ....

M. Petre. Why Looking Isnt Always Seeing: Readership Skills and Graphical Programming. Communications of the ACM, 38(6):33--44, 1995.

....level of complexity. Models should be able to cope with very different software processes organ ized in accordance with the wide range of established software engineering methods or methodologies 3 . 2 As is argued in [Hennemann 91] p. 24 25 this usually helps to a better understanding. In [Petre 95] however, there is an interesting discussion on this viewpoint. 3 There are 2 different interpretations in literature for the term software engineering methodology. Sometimes a methodology refers to a consistent complex of different methods. In other discussions the term is reserved for its ....

....[Royce 70] This is one of the attractive features of diagram matic techniques like the dataflow model: it gives a kind of high level intuitive grasp on the complexity of processes, sometimes using rather loose associations. Note however the danger in using these associations, as discussed in [Petre 95] Functional Modelling in SOCCA 13 Of course in any realistic software engineering process there is a distinct possibility for this to occur. Here however a simple measure could be taken to prevent this by handing the modified design to the ModifyCode and ModifyUnitTest steps only after it is ....

Marian Petre, Why Looking Isn't Always Seeing: Readership Skills and Graphical Programming. In: Commun. ACM 38, 6 (June 95), p. 33-44

....tools for managing knowledge bases remain at best a compromise solution. Diagrams may be easier to understand than logical formalisms, but they still lack the flexibility and familiarity of natural language text, as empirical studies on editing diagrammatic representations have shown (Kim, 1990; Petre, 1995); for discussion see Power et al. 1998) This observation has led us to explore a new possibility, at first sight paradoxical: that of a symbolic authoring system in which the current knowledge base is presented through a natural language text generated by the system. This kills two birds with ....

M. Petre. 1995. Why looking isn't always seeing: readership skills and graphical programming. Communications of the ACM, 38(6):33--42.

....preferred Multi Win even for the smaller test programs. This confirms other experiments that compared graphical and textual representations of software. In those experiments, user performance did not improve with graphical representations, even though the users perceived them as more effective [8]. The questionnaires ranked the Multi Win interface over the SHriMP interface for the larger Monopolyprogram. This Fish Hangman Monopoly Command Line Multi Win SHriMP Test Program Usability Score Better Worse Figure 4: This chart shows the usability scores for the overall questionnaire category. ....

M. Petre. Why looking isn't always seeing: Readership skills and graphical programming. Communications of the ACM, 38(6):33--44, June 1995.

....use graphical visualizations to communicate information about software systems. Although a graphical representation of software architecture may be more accessible and appealing for some users, some experiments have shown that graphical formalisms may not be as effective as textual representations [115]. Although pictures may be ideal for showing a gestalt view of the information, they are not as precise as textual views. Despite the fact that graphical views are open to interpretation, there seems to be a general consensus (at least among the designers of these tools) that graphical ....

....avoid node and arc intersections. Graph layouts for nested or compound graphs are presented in [103, 132, 160] For the purpose of visualizing software, the graph should have esthetic appeal and it should also make use of secondary cues (colour, layout, white space) so that it is meaningful [115]. The layout of the graph is crucial to the information it communicates. Tukey describes a list of general principles that should be adhered to when designing good graphic displays [168] They include the following: objects are perceived in relation to their surroundings; straight lines are easier ....

[Article contains additional citation context not shown here]

M. Petre. Why looking isn't always seeing: Readership skills and graphical programming. Communications of the ACM, 38(6):33--44, June 1995.

....validation task with sophisticated users not familiar with the particular graphical language. Both user groups showed semantic error rates between 25 and 70 for the separately scored areas of entities, attributes, and relations. Relations were particularly troublesome to both analysts and users. Petre (1995) compares diagrams with textual representations of nested conditional structures (which can be compared to OO modeling in the complexity of the paths through the system) She finds that the intrinsic difficulty of the graphics mode was the strongest effect observed (p.35) We therefore ....

Petre, M. (1995). Why looking isn't always seeing: Readership skills and graphical programming. Communications of the ACM, 38(6):33--42.

....technologies. It is clear that in many situations string based specifications are preferable, and often the common practice of using graphical schemas as a high level informal language is quite relevant so that there is no need to employ graphical images as logical schemas (see a discussion in [24]) Actually, it is a question of experience and cognitive science research: when, where and to what extent employment of graphical schemas as formal logical specifications is effective and convenient for a human. A way of managing this problem is to seek for those DB problems whose abstract arrow ....

M. Petre. Why looking isn't always seeing: Readership skills and graphical programming. Communications ACM, 38(6):33--44, 1995.

.... 14 Jerding and Stasko [Jerd96] also created a visualisation system that used colour and text in two dimensions. Again the system was capable of showing both overview and detailed information. They applied this to program code and other forms of data, including textual documents. Petre [Petr95] makes the argument for the combined usage of graphics and texts, rather than graphics alone. She writes Both graphics and text have their uses and their limitations. Pictorial and graphic media can carry considerable information in what may be a convenient and attractive form, but ....

M. Petre. Why Looking Isn't Always Seeing: Readership Skills and Graphical Programming. Communications of the ACM, Vol. 38, No. 6, pp 33-44, June 1995.

.... and Ambler 1994] and ICBE [Zloof and Krishnamurthy 1994; Krishnamurthy and Zloof 1995] The representation design benchmarks are a concrete application of several of the cognitive dimensions for programming systems by researchers from the field of cognitive psychology [Green 1991; Green and Petre 1995] The cognitive dimensions provide a foundation that is appropriate to the cognitive issues of representing programs, and provide an increment in formality over previous ad hoc methods. We based our measures on the particular cognitive dimensions that could be applied to VPL static ....

....to VPL static representations, and added three kinds of refinements: we provided concrete ways of measuring several of the cognitive dimensions at design time, directly focusing them on the static representation part of a VPL. 2: Related Work Cognitive dimensions (CDs) Green 1991; Green and Petre 1995] are a set of terms describing the structure of a programming language s components as they relate to cognitive issues in programming. The CDs, which are listed in Appendix A, provide a framework for assessing the cognitive attributes of a programming system and for understanding the cognitive ....

[Article contains additional citation context not shown here]

M. Petre, "Why looking isn't always seeing: readership skills and graphical programming", Communications of the ACM, 38(6), June 1995, pp. 33-44.

....backward questions using two textual notations. The LabVIEW notations did exhibit the expected match mismatch effect, but the effect size was less than anticipated. Instead response times were twice as long in comprehension questions using the visual notations. In subsequent articles, Green and Petre (Petre 1995; Petre Green 1993) argue that secondary notation accounts for a large part of the (un)readability of a visual notation, and that the ability to read a visual notation and its associated secondary notation is dependent upon training. Secondary notation the use of layout and other informal ....

Petre, M. (1995). Why looking isn't always seeing: Readership skills and graphical programming. Communications of the ACM, 38(6), 33-44.

....of this kind, the use of mental imagery during problem solving is not universal. Individuals differ in terms of their memory, transfer ability, cognitive preferences, repertoire of notational conventions, and so on. It also appears that just as perceptual skill in notation use can be trained (Petre, 1995) imaging ability can also be developed (for example in expert abacus users Hishitani, 1990) In order to capture this range of variability, the current study uses as broad a definition of imagery as possible. Wherever the participants in this study describe inspectable mental representations, ....

Petre, M. (1995). Why looking isn't always seeing: readership skills and graphical programming. Communications of the ACM, 38 (6), 33-44.

....skills: Does visibility lead to effective interpretation There is increasing evidence, from sources ranging from data interpretation to visual programming, that visibility doesn t guarantee effective interpretation, particularly for novices. Interpreting representations is an acquired skill (Petre, 1995; Petre Green, 1993) Arnheim (1969) makes this argument in the context of interpreting paintings; the issue is more critical in the precise interpretation of software visualisations. Novice readers tend to lack search and inspection strategies, and tend to be distracted by surface features. ....

Petre, M. (June 1995) Why looking isn't always seeing: readership skills and graphical programming.

No context found.

Petre, M. Why Looking Isn't Always Seeing: Readership Skills and Graphical Programming. Comm. ACM 38, 6 (June 1995) 33-44.

No context found.

Petre, M., 1995. Why Looking Isn't Always Seeing: Readership Skills and Graphical Programming. Communication of the ACM 38 (6), 55--70.

No context found.

M. Petre, "Why Looking Isn't Always Seeing: Readership Skills and Graphical Programming," Comm. ACM, vol. 38, no. 6, pp. 3344, June 1995.

No context found.

M. Petre. Why Looking Isn't Always Seeing: Readership Skills and Graphical Programming. Communications of the ACM,38(6?+ June 1995.

No context found.

Petre, M. (1995). Why Looking Isn't Always Seeing: Readership Skills and Graphical Programming. Communications of the ACM, 38(6):33-- 44.

No context found.

M. Petre, "Why looking isn't always seeing: Readership skills and graphical programming," Communications of the ACM, vol. 38, no. 6, pp. 33--44, June 1995.

No context found.

M. Petre, "Why looking isn't always seeing: readership skills and graphical programming," Communications of the ACM, Vol. 38, No. 6, June 1995, pp. 33-44.

No context found.

Marian Petre. Why Looking Isn't Always Seeing: Readership Skills and Graphical Programming. Communications of the ACM, 38(6), June 1995.

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC