FodnessMemo10

All of my citations were entered through Zotero.


 * Collins, Harry, and Trevor Pinch. The Golem at Large: What You Should Know about Technology. Cambridge, UK: Cambridge University Press, 1998.**

The Golem at Large: What You Should Know about Technology is the second book in Collins and Pinch’s The Golem series (the first of which is about science). The book is written for a lay audience. The book explains how technology is like the golem of Jewish mythology - that is, not intentionally good or evil, but lumbering and stupid, requiring constant guidance from its masters in order to do good works without unintentionally harming its masters in the process. The focus of the second Golem book is on how technological decisions were made in a variety of case studies, and how good intentions resulted in bad outcomes, and how technological decision making occurs. The Golem series was designed to bring the concepts of social construction and human agency in science and technology to a broader audience, to demonstrate that the decisions made about science and technology are not done in a vacuum, and are made by humans. My research will draw on the style of explaining technological decision making in order to explain how decisions were made with regard to software design that affects individuals with disabilities. For example, the decision to not integrate the functionality of JAWS assistive software for the blind into the design of operating systems, and make it an expensive software package that needs to be purchased by blind people using computers, instead of a cost that was shared amongst all people purchasing the operating system. My research will contribute to books like The Golem, because I intend for the book I will publish to be accessible to laypeople in an effort to demonstrate the problems with the current method of software design, and to show that The Golem of technology has unwittingly dealt blows to the disabled through the decisions of human actors to exclude designing for accessibility from the core of their design strategy. With luck, the next edition of The Golem may contain an excerpt of my research.

8: In the Gulf war, Scud missiles (modified Russian) were fired at American bases, Saudi Arabia, and Israel - Patriot missile fired to stop them, unclear if successful 12: The Patriot missiles were originally designed to take out aircraft, and had to be custom-modified in a very short period of time to take out missiles, wich is very hard 15: The Scud missiles were cobbled together, and would behave erratically - wobbling when entering the atmosphere, or breaking into pieces, which confused the Patriot systems 20: One of the main arguments for supporting the success statistics on the Patriot was that Saddam Hussein believed that they were working, so we should foster that belief 26: The official Army statistics can confirm only one warhead kill, and they are "confident" about 9% of the Scuds were killed by the Patriot, even though intercept rate high 33: Challenger explosion as a result of O-ring failure was debated prior to launch, and the launch went ahead as planned because of consensus on the safety of the launch 36: Two O-rings were present to seal the sections of the rocket for redundancy - due to "joint rotation", there would be a momentary gap created when the rockets ignited 38: The joints were tested using repeated pressurized water blasts while the engine was horizontal - blew out eventually - chalked up to being an unrealistically hard test 44: Live test occurs when the shuttle is launched in a test run - first time is fine, second time the O-ring is partially burnt through from hot gases through the putty 47: Cold-weather hypothesis - there was more blow-by on cold days, causing burned O-rings, than on warm days, but it was within the acceptable tolerance levels, so ignored 52: Hardy, the man in charge of the launch, turned down Thiokol's recommendation not to launch below 53F, because it wasn't supported by any data on O-ring performance


 * Lessig, Lawrence. Code Version 2.0. New York, NY: Basic Books, 2006.**

Lawrence Lessig's Code Version 2.0 is an update to an earlier edition that he wrote, which includes information compiled from readers of his earlier book through a wiki. The new edition is substantially longer than the old edition, and includes information on technologies that either didn't exist at the time of the first writing, or were not widely used. The book concentrates on the ways in which individuals are enabled and constrained through the use of technology - especially the Internet. Lessig's central argument is that code structures cyberspace, and enables certain actions while preventing others. He says that the architecture of software is malleable, and could be used (in much the same way as Collins and Pinch envison the Golem) as a force for good or evil, depending on who is in charge of the code. If the government is in charge of the code, it could be used as a force for repression and control, but if individuals are in charge of the code, it would tend to be more libertarian. Lessig is a constitutional law scholar, and thus has framed most of his analysis around constitutional interpretation of code structuring cyberspace. My research will draw on the core argument of code structuring cyberspace, and more importantly, the argument that code can be structure differently to yield a different experience in cyberspace. My research will add to Lessig's body of work by explaining how code structures cyberspace and software environments in general for the disabled, redefines what it means to be disabled in the context of cyberspace and software in general, and that if code were structured in a more egalitarian fashion, disability would present less of an obstacle to interacting with software programs and cyberspace. My analysis will focus on how cyberspace and software are not accorded the same protections for the disabled that physical space is, and how if cyberspace and software programs were structured more like existing law for physical space, the experience and construction of cyberspace and IT devices in general for the disabled would be a much more fulfilling experience.

2: Cyberspace represents the promise of a libertarian environment with no serious government or business intervention - belief in "rough consensus and running code" 3: Belief in the "libertarian gotcha" of cyberspace - the government requires cyberspace to prosper but can't regulate it - Marxist overthrow of the bourgeoisie 5: In cyberspace, code is law ("Lex Informatica") - software and hardware that allows cyberspace to be what it is controls cyberspace as it is - enables / constrains 123: Individuals are regulated by the forces of the market, architectures, norms, and law 127: Architecture of spaces is regulated by ADA to permit access to the disabled - Paris redesigned with wide boulevards to put down insurgency - L'Enfant designed WDC 128: Geographical separation of courts from legislature - speed bumps to reduce speed - Robert Moses and the buses - Nader and seat belts 130: Forces of law / architecture / norms / market can affect each other - law of sex education changes norms about sex, law of seat belts changes norms of seat belt use 132: Roe v. Wade has guaranteed the right of a woman to have an abortion, but the government seeks to limit that right as much as possible 133: Reagan administration had family planning clinics that were partially funded by the federal government banned from discussing abortion as an option 135: Architectures enforcing racism - railroad tracks, highways without easy crossings, etc - replaced title laws where properties could only be sold to whites


 * Norman, Donald A. The Design of Everyday Things. New York, NY: Currency Doubleday, 1990.**

Donald A. Norman's The Design of Everyday Things (previously published as The Psychology of Everyday Things) is a kritik of design of many everyday objects, such as doors and clocks. The analysis of everyday things is meant to show that some things are designed poorly, but remain in use due to the fact that society at large has learned how to use them in a certain (nonintuitive) way, and that they are reluctant to change. He uses as an example the metric system versus the English system of measurement - the metric system is far more intuitive, but the costs and barriers to change in the US are so high that it is unlikely that a switch will be made anytime soon. Norman extends his analysis of everyday things to the design of software programs, and explains how the visual / aural representation of software systems can be tuned toward usability by a greater audience by making better design decisions focusing on specific areas of design theory. The book is strongly rooted in psychology, usability, and user centered design research. The book was renamed from The Psychology of Everyday Things to The Design of Everyday Things because the focus of the book is really on design, using psychology to explain why certain designs work and others don't. The sub-arguments of the book are that design should be intuitive and obvious, shouldn't require memorization, that the system state should be obvious to anyone using the system, and that systems should be designed for use by everyone, not a highly educated and highly trained fully able individual. This work strongly integrates with my thesis that systems should be designed for the disabled as well as the abled, and that the same system should be able to work for everyone without substantial code changes. His concentration on the methods of design will be integral for my analysis on the failed design of cyberspace and software systems in use today, and will provide some grounding for my recommendations on how to improve. My work will give back to Norman and the design schools by re-examining design of software systems twenty years after Norman's book was published, and demonstrating ways in which software design has improved, and ways in which it has failed to heed Norman's advice and warnings.

188: Four tenets of good design - "Design should: - Make it easy to determine what actions are possible at any moment (make use of constraints). - Make things visible, including the conceptual model of the system, the alternative actions, and the results of actions. - Make it easy to evaluate the current state of the system. - Follow natural mappings between intentions and the required actions; between actions and the resulting effect; and between the information that is visible and the interpretation of the system state." 190: Manuals are often written hastily after the product is made - they should be written first, and should dictate the design of the product 194: If the task is too difficult, simplify it by changing the nature of the task - instead of having shoes that tie, have shoes with velcro - accomplishes the same goal, easy 197: Don't take away control when creating systems design - using a paintbrush to paint is more natural than a computer mouse, so emulation of that style is good 198: Actions should match intentions - the system state should be readily visible or audible so users always know what the state of the system is - should be intuitive 200: Assume that any error that can be made will be made - design for errors such that it is easy to reverse actions and it is difficult to perform irreversible actions 201: For tasks that can't be automated or made to be intuitive, standardize them - analog clocks are not intuitive, but they are standardized, so we know how to read them 204: Some things should be deliberately difficult to use, such as medicine bottles (to prevent children from opening them), doors meant to keep people in (elderly, insane) 214: With an explosion of features comes the difficulty of managing those features in a control system - the new smart houses being planned are very complex 216: Exploit constraints so that the user thinks that there is only one possible action - the right action - and that performing the right action is intuitive and obvious