A4OlgaLiskinMikelKingAntonioGonzalezWalterMahfuz

A4OlgaLiskinMikelKingAntonioGonzalezWalterMahfuz

To-Do

1. which was the most interesting idea/concept you learned from the article?
2. articulate what you did not understand in the article but it sounded interesting and you would like to know more about it
3. compare the ideas/argumentation/functionality for DODEs with the EDC demonstration given in the class meeting on February 11!
4. 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 concept that "formal" representations are unintelligible to end users due to mathematical and logical computer interpretations spoke to us. Not everyone is conditioned to think as a software engineer. End-users are usually trained to be experts in their fields of study, and to ask them to be proficient in programming is not only unrealistic but also would cause them to completely change their perspective. Thus, we think "formal" representations are not beneficial to the end-user or to the field. If DODEs can eliminate the overhead that comes with "formal" representations, DODEs could provide a win-win situation for software engineers and end-users alike. DODEs seem to have the potential to increase the value of the programmer as well as facilitate the creation of an end-product that is better suited for the users needs. We believe that with the constant evolution of hardware, soon enough we will have the processing power and storage that is fast and inexpensive enough to run the more complex DODEs. To us, DODEs provided the "Languages of doing" (Ehn, 1988) and seemed like a viable solution to many of the problems that arise with the use of "formal" representations. It seems like there is always an issue of overdeveloping and many times the voice of certain stakeholders get lost due to engineers assuming that users think like themselves. It was very interesting to see different methodologies to eliminate the "symmetry of ignorance." We liked how the article focused on collaboration because as the article states, no single stakeholder has all the answers.

What you did not understand

Most solutions aren't universal and so we saw the need for models other than DODE. For example, the Waterfall Model is not the newest and most comprehensive model, but there is a reason it is still being used. While its use might be dwindling, it still has its place in some places. The same is true for different programming languages. We would like to know more about which needs are best satisfied by DODEs, and which ones are best left for KBSAs. Is there a way to categorize two groups of necessities and based on this knowledge decide what design method to use?

Compare DODE with EDC

The EDC seems like a very good example of a DODE and in some aspects goes beyond it by allowing physical interactions. Like DODE, the EDC provides active communication between the different stakeholders and "a language of doing" that can enhance the discussion of a design. There are several similarities in the architectures of the EDC and a DODE. One is that the EDC provides a Construction Tool. It provides domain-oriented building blocks in the form of RF cubes and the projected images on the table provide palettes for the design. The peripheral screens provide critics in the form of statistics and computed metrics. It's the peripheral screens that make the EDC a real "design environment" instead of being a construction tool. The screens provide additional design knowledge through evaluating the current system state and responding to it in a context-sensitive way, for example by summarizing statistics, additional information about the currently selected topic, offer of different views.

One aspect that was mentioned in the article as a part of a DODE seems to be missing in the EDC: it does not really have a code generator. It seems like you cannot produce a "compilable" solution when you are done working with the EDC.

Further, it did seem to us that the EDC wasn't geared towards one particular set of end-users. We thought it was centered more on a specific set of tools rather than a specific solution, but the fact that this stone can kill more than one bird shouldn't be viewed as negative.

The EDC demonstration showed the impacts and benefits of a DODE, and how broad the range of applications is. It allowed the user to create a working space. Each space must have its own set of variables, and the EDC was flexible in this regard. Even the purpose of the EDC was programmable - at one point it was a tool for city planning, but then it became a game. Jeff Hoehl mentioned that the EDC could also be used as an "edutainment" tool, where kids could learn how to cook without the risk of burning themselves.

The EDC is not intuitive for every first-timer, but it certainly does not require someone to be trained in the arts of software engineering. We think most people could start exploring the EDC's potential with a short tutorial (that could be available at the beginning of every session). All this is possible without the direct interference of a software engineer.

Comment on the best role distribution

Based in our experience, we think that the best role distribution in a joint human-computer system is to always completely involve a human being. So far, and even with all improvements that software and hardware have had on the last few years, computers still work based on rules established by program designers or by learning methodologies imposed by them, therefore, we should see the computer just as an advisor and leave the final decision making to a human being. If we choose to let the machine to make the final decision or that those boundaries rule our design task we will end up with a really frustrated human being.