Proposal Section: Appropriation Support and Collaborative Design
of Appropriation Support Research will be added later, as it is still incomplete.
I can help with the English, but I prefer to do it in Microsoft Word, so you can check my changes.--Brad
Hi Brad, I hope put your paragraph in the right place. --Christian
Brad: Fine, I fixed it up a little
Research in the area of participatory design lead to many different approaches how designers and users can design a system collaboratively. Christiane Floyd demanded already in the 1980s that software has to be developed cyclic [Floyd 1989]. Since then, many methods of the modern software engineering research and software distribution extend the evolutionary and participatory design [Bleek 2002, Nichols 2003, Ritterbruch 2002]. The approaches differ for example in their term of use during the software lifecycle [Muller 1997]. Some approaches can be used before or while the system is being implemented, while others can be used after system was implemented. The U-SAY project involves both approaches, because service assemblies are created during use time of the system, but they involve the end user performing some implementation tasks. Increasingly, ethnographic methods such as c ontextual inquiry
[Beyer 1998] are being used to discover the target users' real tasks, needs and vocabulary. These are often augmented with studies in laboratories to try to understand the basic usability tradeoffs of various techniques. Put together, this generates new knowledge that can drive design, and allows design to be based on real data about the users' needs and characteristics. For example, a Contextual Inquiry study highlighted some properties of what makes code libraries and frameworks hard to use, which were refined and verified in laboratory studies [Ellis 2007]. Another study discovered that communication among programmers and discovering the design intent were significant barriers among programmers in the field [Ko 2007].
Another approach we will use is called remote evaluation.
It is similar to usability studies, but users process no given tasks. Instead, usability specialists track users’ problems during their daily work. The approach should be used to complement classical usability studies. Hartson et al. insist on objective reports and therefore decline the discussion of discrepancies between users and designers. The term “remote” indicates that users and usability experts can work in different spaces, but also timely separated. Nichols et al. [Nichols 2002] describe another method for the execution of usability tests, called participatory usability
. Users are enabled to create a usability report, whenever they think that it is necessary. The tool for the creation of such reports is integrated into the application itself, making it easier for users to create a report. The report consists of two parts. The first part contains objective data of the program state and is generated automatically. The second part contains subjective data, which is entered by the user. After sending the report, the user is able to track it, keeping him informed whether his issue was already processed and if it will be fixed or not. Quite similar to the participatory usability approach are crash reporting tools
. These tools are also integrated into the application and provide designers with objective information about the application in case of a crash. In contrast to the participatory usability approach, the decision, if a report will be generated or not is done by the system and not by the user. Sometimes crash reporting tools provide a feedback channel to the users, providing them with web-links, emails, etc. Usually these tools are used to increase the stability of an application and not to redesign it. The next approach is called e-prototyping
. In this case, users participate in the design process because of their experiences in the use context, using the already implemented system. The approach is usually embedded in a participatory, evolutionary development processes. The decision, if a requested feature will be implemented, is done within the development process and is not part of the e-prototyping approach.
Besides these formal participatory design approaches, open source development
activities show how participatory design works in practical settings. In this case, there is no hard separation between the group of designers and the group of users. Every user can be a developer at the same time and vice versa. If a user becomes a developer, he has to face the same complexity of software development, as all other developers have to face. At this critical issue, the Adesa project will tie in with a new, less complex approach of collaborative design
, which treats users and developers, in contrast to classical participatory design approaches, as equal partners. Adesa will provide end users with a domain-specific service assembly environment, using appropriate service composition representations and metaphors. The environment enables users to assemble services much like they know it from business process engineering. The created service assemblies could be used to adapt and extend existing programs or to create new programs. The utilization of users’ knowledge in process engineering decreases – compared to open source development – the complexity of developing programs. These user driven assembly activities should furthermore be supported with communication, collaboration and delegation tools. These support tools serve two purposes. First, the assembly activities of users are in most cases collaborative activities, as studies have already proven. Second, the tools should support, like participatory design methods, the communication between users and programmers.
The FP6 Project “inContext” addresses a similar problem like Adesa, because they “[…] will develop a novel scientific approach focused on a new blend of human collaboration and service-oriented systems […]”
. In contrast to inContext, Adesa not provide autonomic service adaptation methods, but will enable users to construct service assemblies by themselves, leaving design power in their hands.
[Nichols 2002] David M Nichols and Michael B Twidale. Usability and open source software. page 16, 2002.
[Muller 1997] M.J. Muller, J.H. Haslwanter, and T. Dayton. Participatory Practices in the Software Lifecycle, chapter 11, pages 256–297. Elsevier, 1997.
[Ritterbruch 2002] Marcus Ritterbruch, Gregor McEwan
, Nigel Ward, Tim Mansfield, and Dominik Bartenstein. Extreme participation - moving extreme programming towards participatory design. PDC2002 Proceedings, 2002.
[Nichols 2003] David M Nichols, Dana McKay
, and Michael B Twidale. Participatory usability: supporting proactive users. pages 63–68, 2003.
[Bleek 2002] Wolf-Gideon Bleek, Martti Jeenicke, and Ralf Klischewski. Developing web-based applications through e-prototyping. In COMPSAC '02: Proceedings of the 26th International Computer Software and Applications Conference on Prolonging Software Life: Development and Redevelopment, pages 609–614, Washington, DC, USA, 2002. IEEE Computer Society.
[Floyd 1989] Christiane Floyd, Fanny-Michaela Reisin, and Gerhard Schmidt. Steps to software development with users
. In ESEC '89: Proceedings of the 2nd European Software Engineering Conference, pages 48–64, London, UK, 1989. Springer-Verlag.
[Beyer 1998]H. Beyer and K. Holtzblatt. Contextual Design: Defining Custom-Centered Systems
. San Francisco, CA, Morgan Kaufmann Publishers, Inc. 1998.
[Ko 2007] Ko, A. J. DeLine
, R., Venolia, G. "Information Needs in Collocated Software Development Teams." International Conference on Software Engineering (ICSE), May 20-26, to appear.
[Ellis 2007] Brian Ellis, Jeffrey Stylos, and Brad Myers. "The Factory Pattern in API Design: A Usability Evaluation". International Conference on Software Engineering (ICSE'2007)
. May 20-26, 2007. Minneapolis, MN. To appear.
- 24 Apr 2007