A4KateStarbirdDaraCunninghamMattSmith
A4KateStarbirdDaraCunninghamMattSmith
To-Do
- which was the most interesting idea/concept you learned from the article?
- articulate what you did not understand in the article but it sounded interesting and you would like to know more about it
- compare the ideas/argumentation/functionality for DODEs with the EDC demonstration given in the class meeting on February 11!
- one major objective of the article, the commentaries, and the reply is to understand the best role distribution between humans and computers in joint human-computer systems (or socio-technical environments)! Comment of this issues from your personal experience!
- Most interesting idea/concept
The most interesting concept from the DODE and JANUS models was that it was based off the idea of user-centered design before this became a major movement in the software development world. At the end of the article, Johnson even says that this form of computer-based modeling will be controversial to some. This envisioned model of a user-designed environment which can be manipulated by the users to fit their needs, without having to consult or hire a programmer, is an ideal model of human computer interaction.
Ning says he believes the JANUS example from Fischer's paper was an analogy, because DODE systems were intended for the design of software systems. Though JANUS is not much more than a CAD system with specific constraints, Fischer's JANUS system does not seem to have been an analogy. Fischer seems to be speaking of design in a much broader sense than the design of software systems. This misunderstanding between reader and author may be at the heart of several of these critiques which are all focused around software design and auto-programming - only a single domain of Fischer's much larger idea.
In Fischer's response to the comments received about his article, he further explained the role of designers in any field. As he explains, while the role of a designer is to determine how to achieve a final product that meets the stakeholders' requirements, simply meeting requirements is not really what design is about. A good design achieves gestalt, meaning the unified whole is greater than the sum of its parts. A designer's role is to take the requirements given to him or her by all of the different stakeholders and mold these into a graceful, but not literal, solution. Many design rationale models seem to lose this idea and concentrate more on simple requirements analysis.
- What you did not understand
The article champions a human-centered approach to system design. However, other models exist for incorporating all stakeholders in the design process - models that do not necessarily make designers out of all the stakeholders. For instance, user-centered interface design methods attempt to incorporate the needs of all stakeholders by conducting user research and usability testing with users at all levels of the system. Does this DODE model still exist as a commercially viable development option or have user-centered and participatory design become better solutions for involving stakeholders in design?
Setliff states in her comments on the article that "the crusade to empower, rather than replace, humans is already a point in fact" (Setliff 209). While many software engineers do hold the goal of enhancing human work through computing, there are many others who hold the goal of imitating or replacing human work with computing. The desirability of designing for empowerment versus replacement differs depending on the task involved and the user's point of view.
- Compare DODE with EDC
The EDC is an evolved example of a DODE. The design activities that the EDC was developed for include several city-planning exercises. Obviously, the EDC has been developed using the seed-evolve-reseed concept described in the original article. It has grown from a solution to a single design activity in a specific domain to branch out into other potential design domains. It resembles most closely the Janus system, constraint-based lay-out creation. EDC reaches out to incorporate more stakeholders synchronously, allowing several to interact directly with the design activity at once. Its system has evolved to give several types of feedback on multiple screens. The expert-system design of the original DODEs (Janus and FRAMER) is not as obvious in the EDC. Libraries of domain-specific information are not necessarily incorporated into the system - and they do not need to be as in this day and age, a designer in need of information can instantly access whatever they need through Google or another internet-based information store. The EDC achieves the original goal of DODE's, that of allowing more stakeholders to be involved in the design process, but leaves behind the DODE's outdated reliance on expert systems.
The first five decades of computer development and research saw a slow and steady exodus from the ideal of artificial intelligence (AI) towards the alternative of intelligence augmentation (IA). AI sought to have computers complete tasks automatically, while IA seeks to give humans tools that enable them to be more efficient, creative, knowledgeable, etc. The article and the work on DODEs are a mark in the timeline near the end of the shift away from AI, though the ideas presented in it seem anchored still in the tradition of AI, even as they attempt to break away from it. The EDC system exists outside the realm of AI and includes very little in the way of automation. The system is a set of tools designed to help a group of people complete a design task. Fischer's goal of creating viable domain-oriented design environments is perhaps coming to fruition, but first, DODEs had to break away fully from the AI tradition. Once this has been escaped, the critiques and responses to Fischer's article become irrelevant.
- Comment on the best role distribution
The article explains the transition from trying to make artificial intelligence an automated process to relieve humans of processing certain tasks into making it a collaborative process finding a medium between automation and human input that satisfies a human's needs. "Automatic programming in its ultimate sense is not only not achievable… but it may also be in particular situations not desirable, because humans enjoy 'doing' and 'deciding'" (Johnson 181). This statement sums up the issue. While it is nice to have some things automated now (like connecting phone calls), there are many things that humans still need to do to feel accomplished. The other part of the issue is that when things become more automated, there are human jobs lost in the process (for example, in the automotive industry). The article talks about creating automatic code writers, which sounds like a nice idea, but there is still the issue of debugging and creating the best algorithm for the fastest running time and the sense of accomplishment achieved when completing a piece of code. From hearing about the evolution of the EDC, we can see how the distribution in joint human computer systems has been tested and see the faults of each system. The modern EDC is a computer model which allows for multiple users to interact at the same time as a group, but also can lead to less social interaction because each can now work on his or her own problem without getting to know each other.
The Mac COCOA programming environment is a nice compromise between automation and augmentation. The environment provides an interface builder that allows application designers to drag-and-drop their interface components. There are toolboxes available that provide fully and partially functioning objects (like drop down menus, radio buttons, tables). The designer-programmer is not forced to reinvent the wheel each time she creates a new app. She can borrow these objects from the interface builder pallete, and then tinker with them at a code level to make them behave correctly within her application. Once this original design activity (the GUI lay-out) is completed, the designer becomes a programmer and creates the rest of the behavior for the program. At the end of the design process, auto-coding takes the interface layout and incorporates it with the programmer's code. The designer is still designing the application. COCOA gives her the tools to make her more effective, and allow her to spend more time in the creative process and less time coding and re-coding components that already exist.
Computer users who began using PCs in the early 1980s have seen many changes in the way computers look, feel, and function. While the new computers have much more power and are more convenient to use, there has been a loss of control that users had over earlier PCs. As computers become more advanced, they also become more and more difficult for the user to exert control over. If new socio-technical environments allow users to create programs or change their computer systems in an easy, relatively risk-free way, they may actually achieve some of the magic that older computers used to have.