A4ToddMytkowicz
Last modified by
Hal Eden on 2010/08/20 11:32
A4ToddMytkowicz
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 notion that DODE environments can be built using general and universal design principles is interesting. I would not have expected this to be the case. But, after some thought, this makes sense. I would like to explore this idea in greater detail, understanding whether or not this "universality of design" is indeed general enough to apply to disparate domains.
For instance, the modern Eclipse IDE is in some sense a DODE and embodies most of the aspects presented in this paper (domain specific projects like windowing toolkits, cooperative tool support like CVS, an interactive and rich hypermedia help system...). This environment is incredibly useful for large programming projects. However, it has some issues that I think many DODEs embody. For example, its toolkits let a novice user get up to speed quickly and built large projects with great ease. However, the toolkits and widgets (e.g. the construction kit) put restrictions on an expert user. It would seem that there is a dichotomy between catering to novice vs expert users in a DODE. Where do we draw the line and how do we evaluate our choice? These are interesting questions I would love to explore. Take for example the UNIX programming environment. Here its construction kits are very simple (e.g. the C programming language, command line and UNIX Pipes). Through these simple constructs an expert can solve complex and domain dependent problems quickly. However, the novice user would spend a long time trying to get up to speed with UNIX before s/he is able to match the expert's agility.
- What you did not understand
- The last question begins to detail my main question: how do we know that a DODE is effective. What are the constraints that are put on expert vs novice users and how do we know that a particular way of design is actually "good". This is not an easy question to answer. Consider something like Object Oriented programming. This is a form of a DODE (specialized objects are construction kits, javadoc is the rich hypermedia help system, object types and the compiler provide critics and hits to users on how to use objects), however in all its years of being a major component of software design, I have never seen a paper evaluate its effectiveness for certain types of problems.
A question would be: How do we evaluate such systems? Certainly this is possible and I would argue useful. So why as a community have we not done this in some 20 odd years…
- Compare DODE with EDC
- It seems that the EDC is born out of the research on DODE. The EDC provides a rich, programmable domain dependent environment whereby a system administrator can build different DODE for the different problems one might encounter. The EDC, however, provides something above and beyond the DODEs in this paper---that is the EDC focuses on tactile collaboration while the paper focuses on virtual collaboration.
- Comment on the best role distribution
- I don't think there is a best role distribution. The role distribution changes with each problem we face and need a computer to help solve. For instance, typical AI planning problems do not need a lot of help from a user---a user basically sets up the domain and lets the AI search the best it can, pushing the role of problem solve onto the computer. However, this is certainly not the case in environments/problems like the EDC fire simulation whereby the computer is simply providing a visualization for human collaborators to discuss and solve the problem.
It seems that in dynamic domains---ones that cannot be encoded apriori with set rules and actions, a computer's role is to provide visualization and support to the human's role as decision maker and designer.