In the Classroom edited by
Interdisciplinary Connections
Mark Alber Friends Academy Duck Pond Road Locust Valley, NY 11560
Interdisciplinary Educational Collaborations: Chemistry and Computer Science Ronald S. Haines* School of Chemistry, University of New South Wales, Sydney 2052 Australia; *
[email protected] Daniel T. Woo, Benjamin T. Hudson, Joji C. Mori, Evey S. M. Ngan, and Wing-Yee Pak School of Computer Science and Engineering, University of New South Wales, Sydney 2052 Australia
Research collaborations between chemists and other scientists have often resulted in significant outcomes, for example, the discovery of fullerenes (1). It is also clear that disciplines other than chemistry can contribute to chemical education (2). In each issue of this Journal in 2004 there were between four and ten individual authors who were not identified as chemists by way of their institutional affiliation. Less publicized and perhaps less common are collaborations between chemical educators and educators in other disciplines with the aim of enhancing learning for students in both disciplines. Chemical laboratories, classrooms, and chemistry students are all resources that students in other disciplines can use to learn their craft while generating significant benefits for chemistry students along the way. The opportunities for such interdisciplinary educational collaboration are increasing as, for a growing number of students, chemistry is less the core of their education and more a part of an integrated wide-ranging curriculum. As these students near the completion of their college or university education they often undertake research projects and their multidisciplinary background has prepared them for collaborative projects. By providing a worthwhile educational experience for nonchemistry majors we may also stem the perceived decline in the relevance of chemistry to other disciplines (3). Collaboration with a nonchemistry group provides an opportunity for the chemist to learn about new techniques and ways of thinking about aspects of the tasks that are part of chemical education. In a collaboration the chemical educator can often become the learner with consequent benefits for the chemist’s future students. This article documents a successful interdisciplinary collaboration with the aim of encouraging other chemists to seek and participate in such partnerships. Aspects of the collaboration that the participants felt to be crucial to its success and some unanticipated outcomes of the project are described. Developing Collaborative Projects There are considerations in developing a portfolio of research projects or topics that will be attractive to students and their supervisors in nonchemistry disciplines beyond those needed to run a successful project for a chemistry stu-
www.JCE.DivCHED.org
•
dent. Some aspects of the current collaboration that were essential to its success are listed below. • The project must have well-defined and somewhat more limited chemical aims and scope than a project for a chemistry major. This is necessary to accommodate the aims associated with the primary discipline of the student and the student’s supervisor. • The aims of the project should be realistic given the time and structure of thesis work in other disciplines. The time allocated for fourth-year project work varies between faculties and institutions, and being aware of the time available will allow the formulation of realistic goals. Do not assume that the structures of all fourth-year projects are the same as those of your institution’s chemistry program. • The project must require a limited degree of chemistry background. Students majoring in computer science, sociology, or psychology cannot be expected to have the same knowledge of chemistry as a chemistry major and such students will benefit from reassurance that they do not have to learn a large body of chemistry and that they will have easy access to assistance in learning the necessary chemistry. The chemist must reflect upon the chemical context of the project and develop the skill of explaining the chemical phenomena to the nonchemist. In the work described here only one of the four students working on the project had completed university- or college-level chemistry courses. Being the first student to work on the project, that student was able to pass on knowledge of the relevant chemistry to the other students. • When describing the project, document the benefits of the project to chemical education and to the discipline of the student carrying out the project. The most productive engagement between chemistry and other disciplines comes from a user-centered approach to formulating the project (4), where the chemist and chemistry students are the “users”. This provides a realistic working environment for the research student and hence a superior educational experience. The “real-world” experience gained by a student in a user-centered interdisciplinary project will set the student ahead of others in the eyes of prospective employers.
Vol. 84 No. 6 June 2007
•
Journal of Chemical Education
967
In the Classroom
Figure 1. The usability cycle.
Initiating and Executing a Project Initiating an interdisciplinary project involves finding a student and supervisor with an interest and commitment to working with a chemist. Networking with other academics and being perceived as approachable by the students you teach were factors that made possible the collaboration described in this article. Good preexisting relationships with colleagues enhance the likelihood of a positive outcome in any collaborative work. Close interaction with the student, the student’s supervisor, and other students in the supervisor’s group is valuable in becoming with familiar with their interests and the techniques used in their discipline. This also allows future projects to be developed that more closely match the interests of the supervisor and students and perhaps more importantly can introduce the chemist to new ways of approaching problems in chemistry. A chemist who can speak the language of the other discipline can frame projects with which nonchemistry students will be more comfortable. A Chemistry–Computer Science Collaboration The collaboration described here was initiated by a student (JCM) who had begun a major in chemistry, changed his major to computer science, and in the final stage of his degree was seeking a thesis topic that would combine both areas he had studied. The student approached his former firstyear lecturer (RSH), who also was familiar with the computer science lecturer (DTW) through previous professional contacts. The computer scientist’s area of interest was human– computer interaction and the usability of software. The chemist had experience in software development and interfacing instruments with computers and was involved in teaching spectroscopic techniques to undergraduates in a laboratory equipped with commercial UV–vis and FT-IR spectrophotometers. The software that controls these instruments is usually designed for an experienced and regular user, rather than a student who is concerned with learning the principles of the spectroscopic technique and may spend only a few hours with an instrument. The idiosyncratic user interfaces often found in such software can lead to frustration for the chemistry students and staff. This led to the specific project of developing easy-touse software for controlling a spectrophotometer. Even though the chemistry background of the student (JCM) was
968
Journal of Chemical Education
•
more than sufficient to start this project, the underlying theory of spectrophotometry was sufficiently limited in scope and independent of other areas of chemistry that future computer science students without an extensive chemistry background would be able to continue working on the project. This expectation was realized over the following three years as other computer science students (BTH, ESMN, W-YP) with little or no chemistry background were able to improve the usability of the software. As an aside for those interested in the details of this project, the spectrophotometer used was a Unicam Helios Gamma, chosen because the serial computer interface and command language were fully documented. More modern spectrophotometers usually do not provide the necessary details to allow development of software to control the instrument, however older instruments (which often benefit the most from upgrading their software) are more likely to have this information provided in their manuals. Software was developed for Mac OS X using the Xcode integrated development environment and the Interface Builder tool for interactive layout of the user interface (5). The C and Objective-C languages and the Cocoa framework (6) were used to develop the application. Highlights of This Collaboration The exposure to new concepts and techniques when collaborating outside of chemistry can lead to interesting and sometimes unexpected results. To illustrate this some highlights of this collaboration are described. These include the formal definition of, and the methods for testing, usability; the sensitivity of student surveys to unexpected sources of bias; and the application of cognitive theory to educational material. Because of the interest of the collaborators in usability, the testing of usability became a central topic in the project. Usability has been defined as “the ease with which a user can learn to operate, prepare inputs for, and interpret outputs of a system or component” (7). Although this definition is taken from an electrical engineering context, the study of usability extends into many disciplines, including document and Web page design (8) and occupational health and safety (9). There are many benefits from improving usability, for example, in the context of educational materials, better motivation of students to learn from the material and consequently better educational outcomes (10). Usability is central to the study of human–computer interaction but is an often overlooked criterion in designing materials for chemical education. The pivotal issue of usability in this project introduces the “usability cycle” (Figure 1), which sets out the steps needed in an iterative process to enhance the usability of software or any other system a person interacts with (11). In this figure scenarios refer to combinations of particular types of users and the types of tasks they are engaged in. In chemical education various scenarios could involve students with differing levels of chemical knowledge, or various levels of language and mathematical skills, or differing motivations for studying chemistry. Iterations of the usability cycle must be applied to as many scenarios as is possible. The usability cycle is reproduced here because it is central not only to software development but also to the prepa-
Vol. 84 No. 6 June 2007
•
www.JCE.DivCHED.org
In the Classroom
ration of thehttp://www.cur.org/pdf/pressrelease.pdf materials we use in teaching chemistry. The tools for assessing usability include ethnographic studies (on-site observations of users), interviews, surveys and questionnaires, and journaled sessions (12). In the course of this collaboration all of these tools were used to collect feedback from users. In some cases the chemistry instructor and laboratory support staff became clients to the computer science students during interviews or participated as subjects in testing prototype software during electronic journaled sessions (13), providing the students with a realistic learning experience. Surveys of students conducted as part of this work revealed an outcome significant for any educator who uses surveys as a tool in assessing aspects of their teaching. Early in the collaboration a group of 39 second-year undergraduate students were surveyed to obtain an indication of how usable they found the existing spectrophotometers. The survey asked for information about the students’ gender, language background, and computer skills, then listed a dozen assertions (e.g., “The labels on the buttons give a good description of what they do.”) about each instrument to which the students could indicate their agreement or disagreement on a five-point Likert scale (14). These assertions included both positive and negative comments about the spectrophotometer user interfaces. Early results from these surveys showed evidence of the students being reluctant to agree with negative statements about the instruments even if they indicated disagreement with matching positive statements. It was suspected this could have been caused by the fact that the surveys were given to the students by the teaching staff supervising the laboratory class. To test this hypothesis the survey forms were distributed over the second half of the semester by the computer science student carrying out the project. Five of the 12 questions showed a statistically significant difference (t test, >95% confidence) between the responses when the survey was distributed to students by another student compared to being distributed by a staff member, even though the survey prominently stated that the results gathered were not used for assessment of the students. For each of these five questions the responses were more critical of the instruments when the student distributed the surveys. This highlights the need for great care to be taken when using surveys to obtain student feedback, even where the material covered in the survey has no connection with assessment of the students’ performance or the performance of the teaching staff. The usability cycle was also applied to the surveys themselves. Before any surveys were administered to chemistry students, the usability of the surveys was tested using a mix of chemistry and nonchemistry students so that ambiguities and unclear statements could be removed. Another feature of this collaboration was the variety of interests that the nonchemistry students brought to the project. The work described here was carried out over four semesters by four computer science honors students. Two of those students concentrated on low-level software development that facilitated extensive changes to the program, such as changing the program from a “wizard” style with successive windows to a single-window with toolbar (Figure 2) overlaid as needed with a simple window for entering settings. The second student to work on the project (ESMN) added a tutorial covering an introduction to the theory and practice www.JCE.DivCHED.org
•
Figure 2. Evolution of the user interface: (top) initial style of user interface and (bottom) the user interface after two years of development and testing.
of spectrophotometry. This was in the form of a window displaying text and graphics with links similar to a Web page. The third student (BTH) converted this material into HTML, which made the material easier to edit, and did extensive reworking of the user interface. The fourth student (W-YP) reviewed the tutorial material in terms of cognitive load and the demands it placed on working memory (15) resulting in improvements such as combining text with graphics to reduce cognitive load and eliminate distracting duplication of content. Early stages of the design process utilized paper-based design techniques (16), rather than being focused too early on the development of the software system. Paper-based techniques are a form of low-fidelity prototyping and are relatively quick to implement and help understand user interaction issues early in the design lifecycle. The design focus is on workflow, terminology, and layout, all of which can be explored independently of building a software application. Paper design is also less intrusive allowing participants (potential users) to fully engage in the design process without feeling like they have to have software qualifications to make comments.
Vol. 84 No. 6 June 2007
•
Journal of Chemical Education
969
In the Classroom
Usability testing of the software system was conducted as part of the final evaluation. In one situation the software developer (BTH) was not permitted to sit next to the user during the software evaluation but instead could view the proceedings from behind a one-way mirror. The opportunity to watch a new user interact with the software without having direct communication proved to be powerful, clearly illustrating design assumptions that were made by the developer that were not consistent with user expectations. This resulted in a rapid set of modifications that were interleaved with additional user observations. Field tests (including some in our undergraduate spectroscopy laboratory) were also conducted where user interaction with the software was recorded remotely over a wireless network connection with video and audio recording to capture user responses and spoken feedback. This illustrates technology used in studying human–computer interaction that could be of value in studying the effectiveness of strategies in chemical education. Conclusion While the immediate outcome of this collaboration was a software development project that provided four computer science students with a realistic learning experience, the spinoffs in chemical education were significant—the development of an easy-to-use program for operating a spectrophotometer, the integration of tutorial material into that program, surveys of undergraduate students using the spectroscopy laboratory, and a raised awareness of usability as it applies to chemical education. Although difficult to quantify it is likely that exposure of a chemist to the techniques used to study human–computer interaction would improve the usability of their teaching materials. It is hoped that the experiences of the authors will serve to encourage chemists and their colleagues to initiate similar interdisciplinary educational col-
970
Journal of Chemical Education
•
laborations that could perhaps involve exchanges of chemistry students with students in other disciplines. Literature Cited 1. Cardellini, L. J. Chem. Educ. 2005, 82, 751–755. 2. Jones, L. L.; Jordan, K. D.; Stillings, N. A. Chem. Educ. Res. Pract. 2005, 6, 136–149. 3. Singh, B. R. J. Chem. Educ. 1995, 72, 432–434. 4. Nielson, J. Usability Engineering; Morgan Kaufmann: San Diego, 1993. 5. Cohen, M. E.; Cohen, D. R.; Ihnatko, A. The Mac Xcode 2 Book; Wiley Publishing: Hoboken, NJ, 2005. 6. Davidson, J. D. Apple Computer. Learning Cocoa with Objective-C, 2nd ed.; O’Reilly Media: Sebastopol, CA, 2002. 7. Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries; IEEE: New York, 1990. 8. Nielson, J. Designing Web Usability: The Practice of Simplicity; New Riders Publishing: Indianapolis, IN, 1999. 9. Leveson, N.; Turner, C. IEEE Computer 1993, 26, 18–41. 10. Najjar, L. J. Human Factors 1998, 40, 311–323. 11. The Hiser Group. The Hiser Element Methodology. http:// www.hiser.com.au/our_process/hiser_element_methodology.html (accessed Mar 2007). 12. Hom, J. The Usability Methods Toolbox. http:// jthom.best.vwh.net/usability/ (accessed Mar 2007). 13. Mori, J. C.; Woo, D. T. COAR: An Objective-C Framework for Usability Data Collection. In Apple University Consortium Academic and Developers Conference, Digital Voyages 2003, September 28–October 1, 2003; Apple University Consortium, Wollongong, Australia, 2003; pp 20.1–20.7. 14. Likert, R. Archives of Psychology 1932, 140, 1–55. 15. Sweller, J. Learning and Instruction 1994, 4, 295–312. 16. Snyder, C. Paper Prototyping; Morgan Kaufman: San Francisco, 2003.
Vol. 84 No. 6 June 2007
•
www.JCE.DivCHED.org
