Uses a mountain as a metaphore of the irregular complexity curve required to first use a computer system, then tinker with it, then program it.
User-tailorable systems: pressing the issues with buttons
paperUses a mountain as a metaphore of the irregular complexity curve required to first use a computer system, then tinker with it, then program it.
For each "terrace" in this mountain it defines a different culture and skill level on the programming field
Worker
No interest in the system, just wants to get the work done
Tinkerer
Enjoys exploring the system but may not fully understand it
Programmer
Understands the system inside out
With this in mind, explores ways in which end-users can tailor their systems to themselved by developing a system based around on-screen buttons.
Users are just screen objects in Xerox Lisp which look "pressable" and when pressed carry out an action. The Buttons architecture allows users with little or no programmin experience to modify various aspects of buttons for themselves (the labels, te graphical image, aspects of the actions).
The Tailoring culture
We stress the importance of building a community with a culture of changing the workstation environment.
Helping the users find good solutions
When users are asked to carry out what might seem a simple interface design task - designing a set of abbreviations for a given command set - they do a very poor job. Users typically have more problems with the abbreviations they produce themselves than they do
with a set which has been designed to conform to a simple abbreviation rule structure.
One approach to help users better understand the possibilities for tailoring would be to design a system so that the range of variations and their consequences were a salient part of the design
Cooperating with users
The approach we employed here was to have a member of our design team (the “handyman”) working closely with the target users. This arrangement provided a mechanism for the designers to take careful account of the users’ real requirements and for the users to gain a better understanding of how their working environment could be different by helping design it themselves.
Tailoring techniques
One role of the handyman was to seed the environments of users with buttons appropriate for their own personal day to day activities.
For example, one of our administrative staff had the task of sending theweekly EuroPARC calendar out by email to a number of different people, to the nearest printer for some other people, and distributing hard-copies to yet other people. A button was produced to carry out most of these tasks with a. single mouse click.
a remarkable amount of tailoring can be done simply by “begging, stealing or borrowing” appropriate buttons and placing them in strategic places on the screen.
Situated creation
It relies on capturing relevant aspects of the system state into a button for later re-use. The idea is that the user carries out some task using normal manual methods, and is then able to encapsulate relevant parts into a button without doing anything which looks like programming
Differences with [ Robotic Process Automation ]
Unlike programming by example, this approach allows the computer to regenerate the state in the most efficient way (if the user got there through a long-winded route, that route is not preserved in the button).
Copying and Specialising buttons
[users] may have a button of their own, or one provided by a colleague, which does almost what they now want, “except for…“
Instead of using OOP-like inheritance, buttons are copied and edited.
user who wants to create a variant of an existing button would typically copy the entire button and then change a few details as necessary.
By making individual buttons independent objects they are conceptually simpler for the user to understand. In addition, if a user wants to send a button to someone else by email, it does not require the recipient’s environment to already contain a complex hierarchy of classes on which the button relies.
Tailoring-Oriented architectures
Boxer, DiSessa ues a concept, which he calls shallow structuring,meaning that “...anything the novice is likely to need to use or modify must be near the surface of the environment”
Modifying program code
Since the relevant piece of Lisp is encapsulated within the button, someone who has some feel for programming and who wants to carry
out minor modifications to the button is faced with a relatively small piece of code and so can be quite happy working out which part of the Lisp expression to change.
Building blocks
we need to encourage a constrained approach to creating new buttons. One obvious example is that we want a consistent interface style for users to interact with buttons.
We provide a set of user-interface building blocks that can be used when the button action causes some interaction with the user. For example, they provide information to the user, ask for yes/no responses, ask for string input and so on.
The buttons user's view
early on, users talked about Buttons as being “not my personal buttons” or being “sewn to the screen” (i.e. not under personal
control).
Later, we started getting quotes such as “I don’t know what I’d do without my Buttons" or “Buttons are my friends, always there...“. Note the use of “my” in these quotes. Buttons became perceived to be very personal
Realising the tailorability promise
Multiple ways of tailoring are good, they add "terraces" to the complexity curve "mountain".
A major reason for our success in enabling non-programming users to tailor their own workstation environment is that we have produced an architecture which supports a large number of tailoring techniques.