Tools in Support of Creative Collaboration Position Paper Clif Kussmaul Muhlenberg College 2400 Chew St, Allentown, PA 18104-5586 [email protected] 1-484-664-3352 ABSTRACT

can often be tried and either adopted or discarded quickly, which facilitates experimentation. Conversely, disciplined tools often require significant investments of money and time, although their long term benefits may be greater.

This paper expresses my interest in participating in the workshop on tools in support of creative collaboration, and describes my relevant interests and background.

This tradeoff is clear in user interface prototyping [2, 25]. Early in a project, paper prototyping allows stakeholders with diverse backgrounds to rapidly explore a wide range of options, although the level of detail is limited. Later in the project, teams may be better served by mock prototypes, developed with custom tools or common office applications, which can provide greater detail, but a greater investment of time. Still later, teams may create code prototypes, which require greater effort but provide the most detail, as illustrated in Figure 1.

Author Keywords ACM Classification Keywords

INTRODUCTION

This paper expresses my interest in participating in the workshop on tools in support of creative collaboration, and describes my relevant interests and background. INTERESTS

I have several interests related to collaboration tools, described below. Agile Tools

I am interested in agile tools and approaches, which are easy to learn, focus on specific tasks, and can be combined and adapted to a variety of environments and projects. This was a well known design philosophy for utilities in the Unix operating system. It is also consistent with recommendations for creativity support tools [24]. In contrast, disciplined tools provide a broader range of capabilities in one package, but often assume or impose a specific viewpoint or process. (The terms agile and disciplined also describe software development models [5].) To support creative collaboration, it is often necessary to balance agility and discipline. This balance can differ for different projects, and even for different phases of the same project; thus, we need to understand how to match tools and approaches to specific situations. For example, agile tools

Figure 1: Tradeoff between effort and fidelity for various prototyping approaches.

However, this figure oversimplifies the relationship between approaches; there is still debate about their relative strengths and weaknesses [e.g. 3, 20, 23, 29, 30]. Barriers to Adoption

I am also interested in how people and groups come to embrace or resist collaboration tools, and particularly in specific barriers that can affect such adoption. To quote DeMarco and Lister [7], “the major problems of our work are not so much technological as sociological” (pg 4, original emphasis).

1

In helping other people and groups start to use wikis and similar tools, I have observed several types of barriers: •

There is not a critical mass of users; it takes two to collaborate, but a tool may require more to be effective.

•

There is not enough urgency; users don’t recognize the tool’s potential, or don’t have a compelling reason to get started.

•

The tool requires a different process or mental model, and users are reluctant to change how they work, or unsure how to do so.

•

Technical problems prevent users from getting started quickly; this can be something as simple as a password problem or unclear instructions.

These barriers may be common to a wider range of tools for creative collaboration. Education & Training

I am also interested in helping people learn to make effective use of collaboration tools, and to use such tools to support educational or organizational goals. Clearly, tools can support and facilitate teams [4], especially virtual teams [8, 21, 22] or teams that require swift trust [17]. In any context, however, it is important to ensure that participants learn not just how to use tools, but when and why [10]. Using collaboration tools in traditional educational contexts presents additional challenges. First, the academic schedule is compressed, and one course typically represents 20-30% of a student’s effort, so one person-day of training could consume several weeks of class time. Thus, it can be hard to effectively use tools with steep learning curves. Second, students often have less experience with collaboration and the problem domain than business users, so the benefits and risks of collaboration are less apparent. However, both of these factors can make educational settings effective test beds, particularly since students may be more accustomed to learning new tools quickly. BACKGROUND

I briefly summarize my relevant background below. Interdisciplinary Collaboration

I enjoy and value interdisciplinary collaboration. In graduate school I studied and worked in research teams on topics such as electro-acoustic music, music perception, and cognitive neuroscience. In industry, I have worked on, led, and managed virtual teams for software projects and products in a variety of application domains. Similarly, my current academic collaborators include faculty at other institutions in engineering, marketing, music, psychology, and religion. Collaboration Tool Use

I have extensive experience using collaboration tools. I have led and managed global software development teams

that depended on collaboration tools including instant messaging, web conferencing, version control systems, and ticket tracking systems. In 2004 I received a Hewlett Packard Technology for Teaching grant to investigate and extend the use of wireless laptops with open source collaboration tools, including the Moodle course management system [19] and several wiki platforms [e.g. 16, 18, 28]. This interest and activity has led to a wiki of resources for entrepreneurship education, a wiki of best practices for teaching adult learners, and a project to investigate using wikis to support reading and writing [9], which we hope to expand to address more creative literary forms [1, 6]. Collaboration Tool Development

I have also developed and extended collaboration tools. I have developed simple extensions for Moodle and several wiki platforms, and supervised a student project that prototyped a multimedia wiki. My experience with software projects and products emphasized the importance of capturing user requirements and prototyping user interfaces, and the need for effective tools to support these activities. In response to this need, Elegance Technologies, Inc. developed Lucid Spec, a software tool to prototype, annotate, and simulate user interfaces and related specifications [15]. We seek to make Lucid Spec easy for non-developers to use, to help them communicate more effectively with developers, and to follow recommendations [24]. We have had numerous requests for new features to support collaboration, which we hope to address in a future release. Thus, we are actively looking for advice and best practices on how to provide such functionality. In particular, we want to avoid adding unnecessary complexity. Education & Training

I use a variety of open source collaboration tools in my teaching, including Moodle, wikis, and Trac [27], a wiki and issue tracking system that interfaces with Subversion [26], a version control system. This is particularly true in my team project-based software engineering course. I have developed and presented workshops [e.g. 11, 12] on collaborative techniques and technologies, including user interface prototyping and wikis. SUMMARY

The workshop would benefit from my experiences in interdisciplinary collaboration, and my experiences with using and developing collaboration tools. Finally, many of my experiences in academia and industry have been with relatively small teams formed around specific issues or questions; this may provide a useful contrast to researchers and practitioners who focus on larger systems and organizations. I would benefit by learning about other contexts for creative collaboration, tools to support them, and ways to help others learn to use such tools effectively.

15. Lucid Spec. http://www.lucidspec.com.

REFERENCES 1. Aarseth, E. J. Cybertext: Perspectives on Ergodic Literature. The Johns Hopkins University Press, Baltimore, MD, USA, 1997.

16. MediaWiki. http://www.mediawiki.org. 17. Meyerson, D., Weick, K. E., and Kramer, R. M. Swift trust and temporary groups. In Trust in Organizations: Frontiers of Theory and Research. Sage Publications, Thousand Oaks, CA, USA, 1996.

2. Arnowitz, J., Arent, M., and Berger, N. Effective Prototying for Software Makers. Morgan Kauffman Publishers, San Francisco, CA, USA, 2007. 3. Bailey, B. P. and Konstan, J. A. Are informal tools better? Comparing DEMAIS, pencil and paper, and Authorware for early multimedia design. SIGCHI Conference on Human Factors in Computing Systems, ACM Press (2003), 313-320.

18. MoinMoin. http://moinmoin.wikiwikiweb.de 19. Moodle. http://www.moodle.org.

4. Bikson, T. K., Cohen, S. G., and Mankin, D. Information technology and high-performance teams. In Supporting Work Team Effectiveness: Best Management Practices for Fostering High Performance. Jossey-Bass, Hoboken, NJ, USA, 1998.

20. Neilson, J. Paper versus computer implementations as mockup scenarios for heuristic evaluation. IFIP Third International Conference on Human Computer Interaction, North-Holland (1990), 315-320. 21. Pinsonneault, A. and Caya, O. Virtual teams: What we know, what we don’t know. International Journal of eCollaboration, 1, 3 (2005), 1-16.

5. Boehm, B. and Turner, R. Balancing Agility and Discipline: A Guide for the Perplexed. Addison Wesley Professional, Boston, MA, USA, 2003.

22. Powell, A., Piccoli, G., and Ives, B. Virtual teams: A review of current literature and directions for future research. ACM SIGMIS Database 35, 1 (2004), 6-36.

6. Bolter, J. D. Writing Space: Computers, Hypertext, and the Remediation of Print (2nd ed). Lawrence Erlbaum Associates, Mahwah, NJ, USA, 2001.

23. Rudd, J., Stern, K., and Isensee, S. Low vs. high-fidelity prototyping debate. interactions 3, 1 (1996), 76-85.

7. DeMarco, T. and Lister, T. Peopleware: Productive Projects and Teams. Dorset House, New York, NY, USA, 1999.

24. Shneiderman, B., Fischer, G., Czerwinski, M., et al. Creativity Support Tools: Report from a US National Science Foundation Sponsored Workshop. International Journal of Human-Computer Interaction, 20, 2 (2006), 61-77.

8. Duarte, D. L., and Snyder, N. T. Mastering Virtual Teams. Jossey-Bass, Hoboken, NJ, USA, 2006. 9. Kussmaul, C. and Albert, S. Reading and writing with wikis: Progress and plans. 6th Creativity and Cognition Conference (2007), to appear.

25. Snyder, C. Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces. Morgan Kaufmann Publishers, San Francisco, CA, USA, 2003.

10. Kussmaul, C., Dunn, J., Watnik, M., and Bagley, M. Using technology in education: When and why, not how. College Teaching, 44, 4 (1996), 123-126.

26. Subversion. http://subversion.tigris.org

11. Kussmaul, C., Howe, S., and Priest, S. Using wikis to foster team communication, cohesion, and collaboration. American Society for Engineering Education Annual Conference (2006).

27. Trac. http://trac.edgewall.org. 28. TWiki. http://twiki.org.

12. Kussmaul, C. and Jack, R. Prototyping in web development. In Software Engineering for Modern Web Applications. Idea Group Publishing, Hershey, PA, USA (in press).

29. Virzi, R. A., Sokolov, J. L., and Karis, D. Usability problem identification using both low- and high-fidelity prototypes. SIGCHI Conference on Human Factors in Computing Systems, ACM Press (1996), 236-243.

13. Kussmaul, C. and Jack, R. User interface prototyping: Tips and techniques. Journal of Computing Sciences in Colleges, 21, 6 (2006), 188-190.

30. Walker, M., Takayama, L. and Landay, J. High-fidelity or low-fidelity, paper or computer medium? Choosing attributes when testing web prototypes. Human Factors and Ergonomics Society 46th Annual Meeting (2002), 661-665.

14. Kussmaul, C., Jack, R., and Sponsler, B. Outsourcing and offshoring with agility: A case study. Extreme Programming and Agile Methods – XP / Agile Universe, Springer, 2006, 147-154.

3