I. Brief overview of sociotechnical problem space
According to the Computer Industry Almanac, as of September, 2007, PCs per capita in the United States “topped 80 percent in 2006 and will reach 98 percent in 2012” (c-i-a, ¶2). An estimated one billion personal computers are currently in use worldwide, making the number of children who have access to computers in the home at an all time high. Even children who do not live in households with computers can still encounter PCs in the homes of friends or relatives, schools, public libraries, and other community settings.
Initiatives such as One Laptop Per Child (OLPC) have made a commitment to placing computing technology in the hands of children worldwide at very little cost. A number of other inexpensive computers have been developed in direct competition with OLPC’s XO-1and XO-2 models for global markets, thus making computers more accessible now than ever before. For this reason alone – the sheer numbers of children who are and/or will soon be exposed to computing technologies – it is imperative that transparency be a critical value in technology design whenever children are involved.
The sociotechnical problem space addressed here is PC use by young people or novice users who are not yet able to articulate the nuances of information technologies, and who do not, in most instances, have a clear understanding of how PCs and software systems operate; through no fault of their own they simply do not speak the language of programmers or designers. The problem space is also one where children (and oftentimes their parents and teachers) place a good deal of trust in PC technologies because they are, for the most part, fairly simple to use and/or easily learned, and provide a source for information and entertainment. But despite ease of use, very few children and adult caregivers comprehend, except at the most basic level, how these systems work.
One might argue, most of us do not need or want to slide under our cars to understand how a suspension system works, all we need or want to know is that the car rides smoothly over bumps in the road. However, it is one thing to put our faith in a car, and quite another to place blind trust in information technologies imbued with functions and values determined by system developers and software designers in a profit-motivated industry. The problem space identified here is one with far-reaching consequences, which makes it essential we are able to understand, to be able to take apart, examine, and become consciously aware of the tools and capabilities that PCs and associated software afford us.
II. The value of transparency in interactions with personal computers
If we use PC software products without thinking very deeply about how these things work, then to what extent will they determine, limit or extend our capacity to learn? Transparency – as a value, and as it is being described here – is at the core of other human values such as empowerment, autonomy, creativity, self-esteem, and learning. Opacity, on the other hand, is antithetical to all of these, especially to learning. Transparency as it relates to learning will be the focal point of this conceptual investigation. Transparency marks vivid differences between open and closed source software: the right to know what it is we are doing (and conversely what is being done for us), how it is done, and most importantly, how to exert control and do it ourselves if we so choose. “Proprietary software keeps users divided and helpless. Its functioning is secret, so it is incompatible with the spirit of learning. Teaching children to use a proprietary (non-free) system [sic] puts them under the power of the system's developer – perhaps permanently” (Stallman, ¶7).
What I am proposing here is an interface that would eliminate secrecy and which I am calling a “Zoominable” designed to help us understand and analyze systems. It would, in essence, answer questions such as “How does this work?” and “What can I do with it?” in ways that enable a more in-depth, understanding of underlying design protocols. A Zoominable is not a tutorial because it will not be designed to teach a young person or novice user how to perform a task using a PC. It will be designed to act more like a magnifying device that will permit young people (or a parent and child together) to zoom in on how something works, to try it on for size, take it apart, put it back together, or experiment with it. A Zoominable will be a virtual tour guide through the “foreign language” of code that will make visible and learnable what is usually not easily viewed or is hidden in software.
Transparency in and of itself is not a new idea. Tanimoto (2005) writes, “Transparency is a valued attribute in software use because it demonstrates how things work, which in turn creates trust, allows for error detection, and promotes learning about how software systems work” (2). What I am suggesting here is transparency in PC environments should be paramount in interaction design where a) products intended for adults are also going to be used by young people, and b) for any new products designed specifically with children in mind.
Transparency assumes a constructivist or active approach to learning versus a passive, consumptive approach. It is a form of transparency that OLPC originally envisioned with its laptop initiative: “While we do not expect every child to become a programmer, we do not want any ceiling imposed on those children who choose to modify their machines. We are using open-document formats for much the same reason: transparency is empowering. The children—and their teachers—will have the freedom to reshape, reinvent, and reapply their software, hardware, and content” (laptop.org, ¶1).
Dr. Steven Tanimoto, who values transparency as an attribute, also argues it “can beget a desire to control,” viewing this as a potential weakness (Tanimoto, p. 4). He explains,
Exposing the intricacies of complex software systems to users can overwhelm or confuse them. Revealing a system's decision- making rules may invite users to game the system and lead them away from the main goals of their interaction. Facilities that interpret or explain the system may also rob users' attention that would otherwise be invested in achieving their primary goal. Transparency mechanisms may therefore need to be flexible and adaptable both to accommodate different users and to accommodate user growth” (Tanimoto, ¶1).
Though Tanimoto’s concerns are valid and must be taken into account when designing for transparency, the desire to beget control need not be thought of as a weakness if it occurs in a proactive way. Control that emerges from learning the language of code, could be viewed as empowering. A Zoominable would be designed in such a way to afford such control; adaptable for different uses and designed to accommodate user growth and experience. It would be non-intrusive and accessible at the start of a function. For example, the Zoominable icon or a pop up might appear asking, “do you want to know how this works?,” offering levels of code-cracking complexity from beginner to expert. Then it will be at the discretion of a young person (working alone or with a parent and/or teacher) to make the choice to learn more about a particular piece of software or operation, and to select the depth and breadth of what is revealed. The Zoominable would be designed with the goal of making PC technologies transparent, thus empowering children to play around with computer code and see what they can do with it without harming or causing irreparable damage to systems or software.
The ability to understand and, therefore, control our experiences with technologies is important if we are not going to be just passive consumers of these technologies. Placing a greater value on the kind of transparency that leads to fluency in the language of code can enhance and encourage critical interaction between humans and computers. Transparency, however, flexible enough so it does not inhibit or interfere with freedom of use; designed in such a way as to be able to be turned on and off at the discretion of the user.
III. Direct and indirect stakeholders
While it could be argued anyone who designs or uses PC technologies has a stake in whether or not transparencies are built into software or interface design, some will benefit more directly than others, some will benefit indirectly, and some may not view transparency as beneficial to the current business model for producing software. All three types of potential stakeholders are addressed below.
Direct stakeholders who stand to gain the most from a Zoominable interface include young people, parents, and educators. Children benefit by having a tool that allows them to unpack unfamiliar knowledge and learn how things work and how to make them work themselves – to actively participate in the learning process. Parents are also direct stakeholders as they, too, can learn more about technologies they are allowing or encouraging their children to use. Educational administrators benefit by being in a position to better evaluate educational software for use in schools. With real transparency, teachers given mandates to infuse technology into curricula are better able to understand how it works, and to demonstrate it to students. While it is unlikely all stakeholders will be interested in getting to the bottom of how systems and software works, it is important the option to do so remains open to them.
Indirect stakeholders who might benefit from transparency include government agencies, corporate policymakers, and/or small business operators who are considering new systems and would like to make more informed comparisons between what they have and what they are considering to purchase. Employees who work for these agencies and businesses may also benefit by being able to customize their experiences with technologies.
Finally, direct stakeholders benefiting least from the introduction of a Zoominable-type interface are the corporate entities and individuals that create and market software for PCs, and stand to lose proprietary information if code is open to anyone who wants to see it. This problem, however, will continue to plague the market whether or not transparency is built into system design. Open source software is not going away any time soon, and new and innovative ways to develop and sell product will evolve as things continue to shake out. One way to work around this problem might be to set time limits on proprietary software so that it can be opened up and made transparent only after a certain time period on the market. Another workaround might be for software companies to offer “for fee” services that support the use of open code software. The concerns of those who stand to lose the most will need to be addressed if transparency is to become an integral value in the design of PC technologies targeting or used by young people.
Sources:
Blankenhorn, D. (2005) “Open Source Transparency.” Corante. http://mooreslore.corante.com/archives/2005/04/19/open_source_transparency.php
Computer Industry Almanac, Inc., 2007, http://www.c-i-a.com/pr0907. htm
One Laptop Per Child. (2008) http://laptop.org/en/laptop/software/
Stallman, R. (2008). Can we rescue OLPC from Windows? Free Software Foundation. http://www.fsf.org/blogs/rms/can-we-rescue-olpc-from-windows
Tanimoto, S. (2005). Proc. Int'l Workshop on Learner Modelling for Reflection, to Support Learner Control, Metacognition and Improved Communic. between Teachers and Learners, in conj.with AIED2005, Amsterdam, July, 2005. pp. 2-4. http://www.cs.washington.edu/ole/111tanimoto.pdf
Tanimoto, S. (2005). “Transparent Interfaces to Complex Software: Helping Users Understand Their Tools.” p. 4. http://viscomp.utdallas.edu/vlhcc05/speakers.htm
No comments:
Post a Comment