Presentation is loading. Please wait.

Presentation is loading. Please wait.

Announcements Design Jam schedule Project – Evaluation due Fri July 30 th 11:59pm Paper presentations Paper/System presentations. Takers? – Tue: Eisenberg.

Similar presentations


Presentation on theme: "Announcements Design Jam schedule Project – Evaluation due Fri July 30 th 11:59pm Paper presentations Paper/System presentations. Takers? – Tue: Eisenberg."— Presentation transcript:

1 Announcements Design Jam schedule Project – Evaluation due Fri July 30 th 11:59pm Paper presentations Paper/System presentations. Takers? – Tue: Eisenberg et al.’s “Apatite: A New Interface for Exploring APIs” CHI.pdf – Tue: Daughtry et al.’s: “API usability: Report on Special Interest Group at CHI” _MYERS_STYLOS_SEN_2009.pdf

2 Supporting programmers: Cognitive Dimensions CS352 Summer 2010

3 Cognitive Dimensions Analytical technique to evaluates visual programming languages (VPLs) VPLs – let users create programs by manipulating program elements graphically rather than by specifying them textually Examples?

4 Alice

5 Simulink

6 Yahoo!Pipes

7 Dimensions Outline Abstraction Gradient: What are the minimum and maximum levels of abstraction? Can fragments be encapsulated? Closeness of mapping: What ‘programming games’ need to be learned? Consistency: When some of the language has been learnt, how much of the rest can be inferred? Diffuseness: How many symbols or graphic entities are required to express a meaning? Error-proneness: Does the design of the notation induce ‘careless mistakes’?

8 Dimensions Outline Hard mental operations: Are there places where the user needs to resort to fingers or pencilled annotation to keep track of what’s happening? Hidden dependencies: Is every dependency overtly indicated in both directions? Is the indication perceptual or only symbolic? Premature commitment: Do programmers have to make decisions before they have the information they need? Progressive evaluation: Can a partially-complete program be executed to obtain feedback on “How am I doing”?

9 Dimensions Outline Role-expressiveness: Can the reader see how each component of a program relates to the whole? Secondary notation: Can programmers use layout, colour, or other cues to convey extra meaning, above and beyond the ‘official’ semantics of the language? Viscosity: How much effort is required to perform a single change? Visibility: Is every part of the code simultaneously visible (assuming a large enough display), or is it at least possible to juxtapose any two parts side-by-side at will? If the code is dispersed, is it at least possible to know in what order to read it?

10 Dimensions Outline  Abstraction Gradient: What are the minimum and maximum levels of abstraction? Can fragments be encapsulated? Closeness of mapping: What ‘programming games’ need to be learned? Consistency: When some of the language has been learnt, how much of the rest can be inferred? Diffuseness: How many symbols or graphic entities are required to express a meaning? Error-proneness: Does the design of the notation induce ‘careless mistakes’?

11 Abstraction Gradient Abstraction Gradient: What are the minimum and maximum levels of abstraction? Can fragments be encapsulated? An abstraction is – a grouping of elements to be treated as one entity Examples? – Functions, classes, types, control abstraction like loops, conditionals, … Abstraction-hating (e.g., flowcharts) – Only contain decision boxes and action boxes; you can’t have other abstractions Abstraction-tolerant (e.g., C) – Can be used exactly as they come, but also allowing new abstractions of several kinds to be created Abstraction-hungry (e.g., SmallTalk, C#) – To start writing a program, you first modify the class hierarchy – Every program requires a new abstraction – The novice programmer cannot simply map problem entities onto domain entities.

12 Abstraction Gradient (cont’d) Finding the right balance is not easy Downsides of abstractions: – Hard for novices – Delayed gratification Upsides: – Right abstractions increase comprehensiveness of a language – Closer map to the problem

13 Dimensions Outline Abstraction Gradient: What are the minimum and maximum levels of abstraction? Can fragments be encapsulated?  Closeness of mapping: What ‘programming games’ need to be learned? Consistency: When some of the language has been learnt, how much of the rest can be inferred? Diffuseness: How many symbols or graphic entities are required to express a meaning? Error-proneness: Does the design of the notation induce ‘careless mistakes’?

14 Closeness of mapping Mapping = mapping between a problem world and a program world Close mapping is good

15 But how close? An example – Java/C# (general purpose) vs. spreadsheet (domain specific – maps directly to the problem)

16 Dimensions Outline Abstraction Gradient: What are the minimum and maximum levels of abstraction? Can fragments be encapsulated? Closeness of mapping: What ‘programming games’ need to be learned?  Consistency: When some of the language has been learnt, how much of the rest can be inferred? Diffuseness: How many symbols or graphic entities are required to express a meaning? Error-proneness: Does the design of the notation induce ‘careless mistakes’?

17 Consistency Consistency = ? = when a person knows some of the language structure, how much of the rest can be successfully guessed?

18 Dimensions Outline Abstraction Gradient: What are the minimum and maximum levels of abstraction? Can fragments be encapsulated? Closeness of mapping: What ‘programming games’ need to be learned? Consistency: When some of the language has been learnt, how much of the rest can be inferred?  Diffuseness: How many symbols or graphic entities are required to express a meaning? Error-proneness: Does the design of the notation induce ‘careless mistakes’?

19 Diffuseness/Terseness = How many symbols or graphic entities are required to express a meaning? Esp. an issue w/ VPLs b’c of real estate Too diffuse: – more material to be looked at  smaller the proportion can be held in working memory  greater the disruption Too terse: – Different programs hardly differ visually  difficult to look and tell

20 Dimensions Outline Abstraction Gradient: What are the minimum and maximum levels of abstraction? Can fragments be encapsulated? Closeness of mapping: What ‘programming games’ need to be learned? Consistency: When some of the language has been learnt, how much of the rest can be inferred? Diffuseness: How many symbols or graphic entities are required to express a meaning?  Error-proneness: Does the design of the notation induce ‘careless mistakes’?

21 Error-proneness = Does the design of the notation induce ‘careless mistakes’? Examples of preventing errors: – Type systems – Program won’t pass compiler if it uses uninitialized variables – Auto-complete instead of having to type every word –…–…

22 Dimensions Outline  Hard mental operations: Are there places where the user needs to resort to fingers or pencilled annotation to keep track of what’s happening? Hidden dependencies: Is every dependency overtly indicated in both directions? Is the indication perceptual or only symbolic? Premature commitment: Do programmers have to make decisions before they have the information they need? Progressive evaluation: Can a partially-complete program be executed to obtain feedback on “How am I doing”?

23 Hard mental operation  Are there places where the user needs to resort to fingers or pencilled annotation to keep track of what’s happening? Consider the following sentence: Unless it is not the case that the lawn-mower is not in the shed, or if it is the case that the oil is not in the tool-box and the key is not on its hook, you will not need to cut the grass....

24 Hard mental operation (cont’d) A broad-brush test for hard mental operaion is: 1.if I fit two or three of these constructs together, does it get incomprehensible? 2.is there a way in some other language of making it comprehensible? (Or is it just a really hard idea to grasp?) If the answer is Yes to both, then it counts.

25 Dimensions Outline Hard mental operations: Are there places where the user needs to resort to fingers or pencilled annotation to keep track of what’s happening?  Hidden dependencies: Is every dependency overtly indicated in both directions? Is the indication perceptual or only symbolic? Premature commitment: Do programmers have to make decisions before they have the information they need? Progressive evaluation: Can a partially-complete program be executed to obtain feedback on “How am I doing”?

26 Hidden dependencies  Is every dependency overtly indicated in both directions? Is the indication perceptual or only symbolic? Dependency – relationship between two or more things Bad examples: – a function surreptitiously altered the value of a global variable – formula in a cell tells which other cells it takes its value from, but does not tell which other cells take their value from it – GOTOs (absence of come-from)

27 Dimensions Outline Hard mental operations: Are there places where the user needs to resort to fingers or pencilled annotation to keep track of what’s happening? Hidden dependencies: Is every dependency overtly indicated in both directions? Is the indication perceptual or only symbolic?  Premature commitment: Do programmers have to make decisions before they have the information they need? Progressive evaluation: Can a partially-complete program be executed to obtain feedback on “How am I doing”?

28 Premature commitment  Do programmers have to make decisions before they have the information they need? An example: – Forced to choose what features to have when first installing a piece of software When does this problem arise? 1.the notation contains many internal dependencies 2.the medium or working environment constrains the order of doing things, and 3.the order is inappropriate

29 Dimensions Outline Hard mental operations: Are there places where the user needs to resort to fingers or pencilled annotation to keep track of what’s happening? Hidden dependencies: Is every dependency overtly indicated in both directions? Is the indication perceptual or only symbolic? Premature commitment: Do programmers have to make decisions before they have the information they need?  Progressive evaluation: Can a partially-complete program be executed to obtain feedback on “How am I doing”?

30 Progressive evaluation  Can a partially-complete program be executed to obtain feedback on “How am I doing”? Novices need to evaluate their own problem- solving progress at frequent intervals Experts can usually live without it if they have to, but even they prefer to have it

31 Dimensions Outline  Role-expressiveness: Can the reader see how each component of a program relates to the whole? Secondary notation: Can programmers use layout, colour, or other cues to convey extra meaning, above and beyond the ‘official’ semantics of the language? Viscosity: How much effort is required to perform a single change? Visibility: Is every part of the code simultaneously visible (assuming a large enough display), or is it at least possible to juxtapose any two parts side-by-side at will? If the code is dispersed, is it at least possible to know in what order to read it?

32 Role-expressiveness Can the reader see how each component of a program relates to the whole? RE describes how easy it is to answer the question ‘what is this bit for?’ How to enhance RE? 1.By use of meaningful identifiers 2.By well-structured modularity 3.By the use of secondary notation (doesn’t contribute to the running of the program, e.g., comments) to signal functionally-related groupings

33 Dimensions Outline Role-expressiveness: Can the reader see how each component of a program relates to the whole?  Secondary notation: Can programmers use layout, colour, or other cues to convey extra meaning, above and beyond the ‘official’ semantics of the language? Viscosity: How much effort is required to perform a single change? Visibility: Is every part of the code simultaneously visible (assuming a large enough display), or is it at least possible to juxtapose any two parts side-by-side at will? If the code is dispersed, is it at least possible to know in what order to read it?

34 Secondary notation Can programmers use layout, color, or other cues to convey extra meaning, above and beyond the ‘official’ semantics of the language? SN is carries extra information by other means than formal syntax

35 Find examples of secondary notations from this Indenting Commenting choice of naming conventions grouping of related statements

36 Dimensions Outline Role-expressiveness: Can the reader see how each component of a program relates to the whole? Secondary notation: Can programmers use layout, colour, or other cues to convey extra meaning, above and beyond the ‘official’ semantics of the language?  Viscosity: How much effort is required to perform a single change? Visibility: Is every part of the code simultaneously visible (assuming a large enough display), or is it at least possible to juxtapose any two parts side-by-side at will? If the code is dispersed, is it at least possible to know in what order to read it?

37 Viscosity: resistance to local change The ‘viscosity’ of a fluid is its resistance to local change. V here means how much effort is required to perform a single change? Why viscosity matter? – changes and revisions infest the whole course of programming activity, from specifying to designing to coding

38 Dimensions Outline Role-expressiveness: Can the reader see how each component of a program relates to the whole? Secondary notation: Can programmers use layout, colour, or other cues to convey extra meaning, above and beyond the ‘official’ semantics of the language? Viscosity: How much effort is required to perform a single change? Visibility: Is every part of the code simultaneously visible (assuming a large enough display), or is it at least possible to juxtapose any two parts side-by-side at will? If the code is dispersed, is it at least possible to know in what order to read it?

39 An example of high viscosity

40 Dimensions Outline Role-expressiveness: Can the reader see how each component of a program relates to the whole? Secondary notation: Can programmers use layout, colour, or other cues to convey extra meaning, above and beyond the ‘official’ semantics of the language? Viscosity: How much effort is required to perform a single change?  Visibility: Is every part of the code simultaneously visible (assuming a large enough display), or is it at least possible to juxtapose any two parts side-by-side at will? If the code is dispersed, is it at least possible to know in what order to read it?

41 Visibility Is every part of the code simultaneously visible (assuming a large enough display), or is it at least possible to juxtapose any two parts side-by-side at will? If the code is dispersed, is it at least possible to know in what order to read it? Related to visibility is juxtaposability, the ability to see any two portions of the program on screen side-by-side at the same time. A bad example: – Spreadsheets, with their two layers (data and formulae), have asymmetric visibility.

42 In-class activity Pick three of dimensions and evaluate Yahoo!Pipes using them (http://pipes.yahoo.com/pipes/)http://pipes.yahoo.com/pipes/ 10 minutes: register for a Yahoo! Account if you don’t have one, and play with a couple of pipes programs 15 minutes: go through the interface and write down the problems you find for each dimension.

43 Trade-offs among dimensions? E.g., heat up air to change temperature causes increase in its volume unless compressed, which in turn causes change in pressure.


Download ppt "Announcements Design Jam schedule Project – Evaluation due Fri July 30 th 11:59pm Paper presentations Paper/System presentations. Takers? – Tue: Eisenberg."

Similar presentations


Ads by Google