Academia.eduAcademia.edu

Figure 10 – uploaded by Thomas Green

See full PDFdownloadDownload figure
Here we collect the comments made under each dimension. The columns give desirable profiles of dimensions for each of the types of user activity mentioned above. Notable Trade-offs

Table 10 Here we collect the comments made under each dimension. The columns give desirable profiles of dimensions for each of the types of user activity mentioned above. Notable Trade-offs

Related Figures (42)

What does the approach deliver?
What does the approach deliver?
Dimensions not treated in this tutorial
Dimensions not treated in this tutorial
\cceptable for transcription activity and for simple incrementation activity, but problematic fo: xploratory design and for modification activity.
\cceptable for transcription activity and for simple incrementation activity, but problematic fo: xploratory design and for modification activity.
In practice, potent combinations of knock-on and repetition viscosity are the type to be feared, turning up frequently in graphics structures. Although word-processors are steadily reducing the viscosity problem for document generation, drawing packages are not making comparable progress. Editing a drawing usually requires much tedious work, and frequently many similar alterations need to be made to different parts of the picture; automation tools, desirable as they might be, are not yet commercially available. Figure 4 This tree-chart, showing part of the J avaScript object hierarchy, illustrates both knock-on viscosity and potential repetition viscosity: if the ‘window’ box is moved to one side, all the lines connecting it to other boxes will have to be moved (knock- on). In most drawing systems each line will have to be redrawn individually (repetition viscosity).
In practice, potent combinations of knock-on and repetition viscosity are the type to be feared, turning up frequently in graphics structures. Although word-processors are steadily reducing the viscosity problem for document generation, drawing packages are not making comparable progress. Editing a drawing usually requires much tedious work, and frequently many similar alterations need to be made to different parts of the picture; automation tools, desirable as they might be, are not yet commercially available. Figure 4 This tree-chart, showing part of the J avaScript object hierarchy, illustrates both knock-on viscosity and potential repetition viscosity: if the ‘window’ box is moved to one side, all the lines connecting it to other boxes will have to be moved (knock- on). In most drawing systems each line will have to be redrawn individually (repetition viscosity).
Figure 3 A timetable showing which teacher is teaching which class. Timetables typically contain high knock-on viscosity. If Mr Adams’s Year 1 class has to be moved to the 10-11 slot, everything else will have to be re-organised.
Figure 3 A timetable showing which teacher is teaching which class. Timetables typically contain high knock-on viscosity. If Mr Adams’s Year 1 class has to be moved to the 10-11 slot, everything else will have to be re-organised.
The search cost for spreadsheets rises sharply with the size of the sheet and with the branching factor (average number of data-supplying cells quoted, per formula).:
The search cost for spreadsheets rises sharply with the size of the sheet and with the branching factor (average number of data-supplying cells quoted, per formula).:
Figure 9 Data flow representations make the dependencies explicit.
Figure 9 Data flow representations make the dependencies explicit.
Explanation The amateur signwriter at work:
Explanation The amateur signwriter at work:
Problematic in all contexts, except where the lookahead is not extensive. Probably one of the important differences between ‘novices’ and ‘experts’ in studies of design is that experts recognise potential problems much earlier, perhaps not from looking ahead but by familiarity with likely sources of difficulty. Research has shown that expert designers frequently treat potential trouble-spots differently, putting them aside for later treatment or attacking them early.
Problematic in all contexts, except where the lookahead is not extensive. Probably one of the important differences between ‘novices’ and ‘experts’ in studies of design is that experts recognise potential problems much earlier, perhaps not from looking ahead but by familiarity with likely sources of difficulty. Research has shown that expert designers frequently treat potential trouble-spots differently, putting them aside for later treatment or attacking them early.
Tuming to software examples, every amateur has met the problem of choosing categories for a database and then discovering that the world is full of exceptions. For example, my simple mailmerge list of addresses allows 6 lines per address. Now and again I meet somebody whose address needs 7 or more lines. What now? The first design of the database had to be based on guesswork, in other words I was prematurely committed. Telephone menu systems (“If you wish to make a booking, press 1 ...if you wish to reserve a seat, press 2... etc”) impose premature commitment on the long-suffering user, who has to decide whether to press key 1 before knowing what other choices are available.
Tuming to software examples, every amateur has met the problem of choosing categories for a database and then discovering that the world is full of exceptions. For example, my simple mailmerge list of addresses allows 6 lines per address. Now and again I meet somebody whose address needs 7 or more lines. What now? The first design of the database had to be based on guesswork, in other words I was prematurely committed. Telephone menu systems (“If you wish to make a booking, press 1 ...if you wish to reserve a seat, press 2... etc”) impose premature commitment on the long-suffering user, who has to decide whether to press key 1 before knowing what other choices are available.
Figure 10 A box-and-line editor (e.g. for entity-relationship diagrams). These editors frequently impose a type of order constraint: users can add boxes with no connectors, but cannot add connectors except between existing boxes. The dashed line is an example of a ‘free’ connector, that could not be drawn.
Figure 10 A box-and-line editor (e.g. for entity-relationship diagrams). These editors frequently impose a type of order constraint: users can add boxes with no connectors, but cannot add connectors except between existing boxes. The dashed line is an example of a ‘free’ connector, that could not be drawn.
That is equally true of interactive and non-interactive systems. Less skilled word-processor users wil avoid styles, auto-formatting, macros, advanced (pattern-matching) editing, and other forms o abstraction.These features could save effort, but they are error-prone and cognitively costly.
That is equally true of interactive and non-interactive systems. Less skilled word-processor users wil avoid styles, auto-formatting, macros, advanced (pattern-matching) editing, and other forms o abstraction.These features could save effort, but they are error-prone and cognitively costly.
Transient abstractions also include global find-and-replace commands, e.g.
Transient abstractions also include global find-and-replace commands, e.g.
Figure 13 Optional update in a diary system: the time of one instance of the weekly seminar is to be altered. A dialog gives options of which other instances to update. Sometimes, optional-update abstractions are available. Abstraction hunger and the abstraction barrier from it). Note the potential for hidden dependency here - if we cannot readily see which examples wil. be changed, we may be in for nasty surprises.
Figure 13 Optional update in a diary system: the time of one instance of the weekly seminar is to be altered. A dialog gives options of which other instances to update. Sometimes, optional-update abstractions are available. Abstraction hunger and the abstraction barrier from it). Note the potential for hidden dependency here - if we cannot readily see which examples wil. be changed, we may be in for nasty surprises.
Figure 14 Hidden dependencies in the Word 5.1 style manager: if | modify the definition of this style, | cannot tell which other styles will be affected.
Figure 14 Hidden dependencies in the Word 5.1 style manager: if | modify the definition of this style, | cannot tell which other styles will be affected.
Secondary notation has an equally valid place in interactive systems; a control system in which functionally-related controls are grouped together is likely to be easier to learn - to induce fewer slips of action too. Cost Implications
Secondary notation has an equally valid place in interactive systems; a control system in which functionally-related controls are grouped together is likely to be easier to learn - to induce fewer slips of action too. Cost Implications
Figure 15 Secondary notation in circuit diagrams: the left hand shows a schematic in which components have been organised to make their function apparent (redundant recoding). The right hand diagram shows the layout on the circuit board.
Figure 15 Secondary notation in circuit diagrams: the left hand shows a schematic in which components have been organised to make their function apparent (redundant recoding). The right hand diagram shows the layout on the circuit board.
Some of the classic design manoeuvres identified above are listed in the following table. Design Manoeuvres
Some of the classic design manoeuvres identified above are listed in the following table. Design Manoeuvres
Figure 20 A line indicates a trade-off relationship identified in the text above. Not all of these trade-offs are available in all cases, and the diagram does not pretend to identify all possible relationships.
Figure 20 A line indicates a trade-off relationship identified in the text above. Not all of these trade-offs are available in all cases, and the diagram does not pretend to identify all possible relationships.
indicating that the piece of music contains many note symbols, each of which has a height on the staff (the black border indicates a perceptual cue) and a note name. To transpose the key of a piece, every note must be rewritten. The approach even offers a symbolic computation of the cost of change:
indicating that the piece of music contains many note symbols, each of which has a height on the staff (the black border indicates a perceptual cue) and a note name. To transpose the key of a piece, every note must be rewritten. The approach even offers a symbolic computation of the cost of change:
Figure 21 Month view in NUD. Several different views are available, some by time unit (year, month, day) and some as lists of events. The most relevant ones are the month view, the day view, and the list view.
Figure 21 Month view in NUD. Several different views are available, some by time unit (year, month, day) and some as lists of events. The most relevant ones are the month view, the day view, and the list view.
Inserting a new event in the month view potentially causes both knock-on and repetition. There is no way to insert an event between existing events and have them all close up slightly to make space for the newcomer, and so the user has to adjust all the existing events manually (this is the knock-on viscosity). In the month view, each event has to be separately opened and have its start and end time retyped (this is the repetition). Figure 24 Defining a new event in NUD. To change the scheduled times of an existing event, this dialog box is re-opened and edited.
Inserting a new event in the month view potentially causes both knock-on and repetition. There is no way to insert an event between existing events and have them all close up slightly to make space for the newcomer, and so the user has to adjust all the existing events manually (this is the knock-on viscosity). In the month view, each event has to be separately opened and have its start and end time retyped (this is the repetition). Figure 24 Defining a new event in NUD. To change the scheduled times of an existing event, this dialog box is re-opened and edited.
Figure 22 The day view in NUD.
Figure 22 The day view in NUD.
Figure 25 Left, modifying a day’s schedule: coffee time is being extended. Right, rearranging the schedule by dragging ‘discuss life’ upwards. Note that overlapping events are shown side by side in the day view. Fortunately, the day view is less demanding. Times are mapped onto spatial layout in a simple table, in which the start and finish times can be dragged up and down with the cursor:
Figure 25 Left, modifying a day’s schedule: coffee time is being extended. Right, rearranging the schedule by dragging ‘discuss life’ upwards. Note that overlapping events are shown side by side in the day view. Fortunately, the day view is less demanding. Times are mapped onto spatial layout in a simple table, in which the start and finish times can be dragged up and down with the cursor:
The system does, however, give a representation for events that repeat (birthdays, weekly seminars, etc), and there are some potential dependencies for these events, since different occurrences are necessarily linked. If the start or finish time of an individual event is to be altered, NUD offers a dialog box allowing the user to change all the events or only the currently selected event. But if an event is changed from a type with a start time to one that has no fixed time (such as a Note), then all the other repetitions of that event are silently changed, and their start times are lost. Figure 26 Defining a repeating event in NUD.
The system does, however, give a representation for events that repeat (birthdays, weekly seminars, etc), and there are some potential dependencies for these events, since different occurrences are necessarily linked. If the start or finish time of an individual event is to be altered, NUD offers a dialog box allowing the user to change all the events or only the currently selected event. But if an event is changed from a type with a start time to one that has no fixed time (such as a Note), then all the other repetitions of that event are silently changed, and their start times are lost. Figure 26 Defining a repeating event in NUD.
/isibility for single events and classes is well handled. The day and month views illustrated above dea vith most events; a list view can also be obtained, in which all events of a given set are listed togethe nithout the visual framework of the calendar: Figure 27 The list view in NUD allows ‘timelines’ to be separated by displaying only the events of one category.
/isibility for single events and classes is well handled. The day and month views illustrated above dea vith most events; a list view can also be obtained, in which all events of a given set are listed togethe nithout the visual framework of the calendar: Figure 27 The list view in NUD allows ‘timelines’ to be separated by displaying only the events of one category.
of categories looks like the figure below. The list shows which categories are included in the set and what text attributes to use when displaying those events. Figure 28 The dialog for managing sets of categories of events in NUD.
of categories looks like the figure below. The list shows which categories are included in the set and what text attributes to use when displaying those events. Figure 28 The dialog for managing sets of categories of events in NUD.
Figure 32 Times in seconds to make equivalent editing modifications Inserting the material into LabView took a surprisingly long time because all the boxes had to be jiggled about and many of the wires had to be rebuilt. Prograph was able to absorb the extra code to deal with air resistance with little difficulty — certainly less than evidenced by LabView. This was because the new code was placed in new windows, and relatively little change had to be made to existing layouts. (Notice, however, that this causes poor visibility and juxtaposability, as mentioned below.) For Basic, the problem is just one of typing a few more lines. Overall time taken was as follows: LabView, 508.3 seconds; Prograph, 193.6 seconds; Basic, 63.3 seconds - an astonishing ratio of 8:1 between extremes. These are differences of a whole order of magnitude, and if the programs were larger we would expect them to increase proportionately (i.e. to increase faster for LabView, slower for Basic). Hidden dependencies
Figure 32 Times in seconds to make equivalent editing modifications Inserting the material into LabView took a surprisingly long time because all the boxes had to be jiggled about and many of the wires had to be rebuilt. Prograph was able to absorb the extra code to deal with air resistance with little difficulty — certainly less than evidenced by LabView. This was because the new code was placed in new windows, and relatively little change had to be made to existing layouts. (Notice, however, that this causes poor visibility and juxtaposability, as mentioned below.) For Basic, the problem is just one of typing a few more lines. Overall time taken was as follows: LabView, 508.3 seconds; Prograph, 193.6 seconds; Basic, 63.3 seconds - an astonishing ratio of 8:1 between extremes. These are differences of a whole order of magnitude, and if the programs were larger we would expect them to increase proportionately (i.e. to increase faster for LabView, slower for Basic). Hidden dependencies
The sequence of screenshots below I taken from an actual session in which a LabView user built the x =(-b +V (b? - 4ac) / 2a
The sequence of screenshots below I taken from an actual session in which a LabView user built the x =(-b +V (b? - 4ac) / 2a
Figure 33 ‘Visual spaghetti’. To avoid this, the programmer has to look ahead. This example is in Prograph, but the same problem occurs in LabView or any other box- and-wire language.
Figure 33 ‘Visual spaghetti’. To avoid this, the programmer has to look ahead. This example is in Prograph, but the same problem occurs in LabView or any other box- and-wire language.
Where LabView in turn meets trouble, however, is in the juxtaposition of related control branches. Th two branches of a conditional cannot both be viewed at once, and although a single mouse click wi take you to the next branch, the effect on comprehensibility is very worrying. Figure 34 A LabView conditional from the rocket program, showing both arms. In the LabView environment, only one arm is visible on screen at any one time.
Where LabView in turn meets trouble, however, is in the juxtaposition of related control branches. Th two branches of a conditional cannot both be viewed at once, and although a single mouse click wi take you to the next branch, the effect on comprehensibility is very worrying. Figure 34 A LabView conditional from the rocket program, showing both arms. In the LabView environment, only one arm is visible on screen at any one time.
Using the memory There is only one version of this widget - just compare its functioning with and without the memory.
Using the memory There is only one version of this widget - just compare its functioning with and without the memory.
Redefining a shape changes all the instances that have already been used.
Redefining a shape changes all the instances that have already been used.
580 California St., Suite 400
San Francisco, CA, 94104
© 2025 Academia. All rights reserved