HAILEY, Michael B., JORGENSEN, Jens E., FRIDLEY, James L. & HEIM, Joseph A.
Mechanical Engineering, University of Washington, Seattle, Washington, USA, 98195-2600, http://www.me.washington.edu/~jorgen/me395/
Abstract: Design education and design project execution requires teamwork and collaborative efforts to be successful. In an academic setting this has typically been achieved by frequent 'face-to-face' meetings between the student design team, faculty consultants, and the project sponsors. Modern technology, via the Internet, has made the collaborative team efforts independent of the constraints of common meeting times and the need for graphical collocation. In the undergraduate program in Mechanical Engineering at the University of Washington we have implemented a Web-based collaborative design tool1 for use in group design projects.
Senior undergraduate student teams involved in industry or university sponsored design projects utilized the Web as the media for exchange of ideas, design files, and project documents in a collaborative manner. This action was asynchronous and allowed the students to interact efficiently regardless of location and time constraints. The efficiency and productivity of these interactions are far better than the traditional lecture and common meeting interactions normally used. Early on in the design project 'face-to-face' meetings between student teams, faculty and client were needed to establish communication lines, trust, modes of operations, and the project objectives. Once agreement on these issues had been reached the process of initiating and moving through the design process, delegating task assignments, and provide progress on action items proved a far more efficient and completed in a timely manner. The added feature of the Web-based approach was the ability to provide on-line documentation of the project deliverables.
We present the process, procedure and operational characteristics of the Web-based approach to design project administration and execution and provide samples of its effectiveness. Outcome based assessment indicates that the majority of the students (80% and better) not only accepted this process as better but indicated that it gave them additional freedom from other time constraints, allowing them to carry out their work more efficiently. The industry and faculty consultants found the Web process to be beneficial, too, allowing closer contact with the student teams and resulting in improved project management. This included quicker response to data requests, consulting advice, and critical evaluation of the team’s work output at all stages of the design process.
Keywords: Product Design Education, WWW, Web-based Collaboration
A CHANGE IS REQUIRED: The ABET 2000 criteria requires a major design experience of our undergraduate student. In Mechanical Engineering at the University of Washington, the two core design courses, ME 395: ”Introduction to Design,” and ME-495: ”Capstone Design,” are intended meet this requirement; however, they have usually been taught as two distinct and separate courses. ME-395 typically addressed topical issues appropriate to design and not covered elsewhere in the core curriculum. Topics included the design process, innovation, economics, optimization, etc., and appropriate lectures and exercises have been developed to help elucidate the material. In ME-495, the students attempted to carry an open ended, industry-based project to a ”near hardware” implementation. Unfortunately, in the 10-week quarter system, this proved to be a nearly impossible task, unless the problem was either simplified or the design solution offered up front.
A NEW APPROACH: Starting in the autumn of 1997, we decided to link the two courses and make them both project-based. The course material drivers now become the design project activities and tasks rather than the chapters of a product design textbook. The topical issues in ME-395 are now presented and discussed on an ‘as-needed basis’ and textbooks, the Engineering Library and other design related materials now become resources for the students to investigate and acquire on their own. While this has shifted the learning responsibility more to the students it also represented a change and a challenge in how we, as instructors, manage the design activity.
At the beginning of the ME-395 course, students are presented with the descriptions of potential projects (requests for proposals, or RFPs). These projects have been solicited by the ME-395 instructor from companies around the Seattle area and from the University of Washington design community, as well as from some other non-local industry contacts. The students are able to meet with the sponsors of the industrial projects, and, having studied all the RFPs, select those projects on which they would like to work. The deliverable for the ME-395 class is a project proposal, which describes the completed design work of the past quarter, and proposes work to be implemented in ME-495 resulting in hardware or a prototype. The proposal, of course, must be reviewed and accepted by the client before progressing to ME-495, and often the goal, scope, and deliverables of the project need to be re-negotiated.
ME-395 and ME-495 present the students with the challenge of trying to solve a real engineering problem in the context of a group project: How can all team members best contribute information concerning the project? How can the various schedules of the members be accommodated? How can each member provide input on, or edit, common documents? How can each team communicate easily and regularly with its project sponsor? These questions are of particular interest to the project groups, for, as students, all have numerous outside commitments, and they find themselves trying to balance meeting their needs with those of their projects’ clients, the requirements of the course, and the expectations of the instructors.
THE INSTRUCTIONAL CHALLENGE: Additionally, design courses like these offer unique challenges to the instructor: How involved should the teaching staff be with the day-to-day workings of each group? How will the students be evaluated? How will enough meetings with every group be scheduled so that each team stays on track? What is the best way to communicate with the different teams? How is the proper level of client interaction successfully achieved? Overseeing multiple design teams is no small design project management problem itself!
In an effort to offer a potential solution to some of these challenges, and to explore the application of internet-related technology towards the design process, we decided to introduce a Web-based collaborative design tool to the ME-395 and ME-495 students for use in their project work. Any such tool would need to be easy to use, simple to configure, modify and maintain, and would have a relatively steep learning curve for both the users (students, clients, and instructors) and the managers (instructors) of the software. It was important, too, that the students have easy access to Internet-linked computers, in order to fully support this Web-based design activity, particularly in the classroom.
The chosen Web-based tool was set up to exist alongside the University of Washington Mechanical Engineering ”Product Design Education” homepage, which contains information regarding the structure of the courses (e.g. syllabus, project descriptions, lecture material, etc.); this can be viewed by anyone with Web access. Connected by a hyperlink within this homepage, the Web-based design tool was to provide the students with chatting, message posting, and document attachment and downloading capabilities; each team was to have a ‘private’ space, accessible only to its members.
WHY A WEB BASED DESIGN TOOL?: Ideally, this Web-based collaborative design tool would allow students to conduct ”virtual meetings,” where input is made via computer messages rather than around a table. Likewise, this tool would provide a place for the instructors and the project clients to view the progress made by each team, in real time, and to offer instant comments and suggestions, and to pose questions.
Theoretically, too, this Web-based tool would facilitate the joint composition, editing, and analysis of important team documents before their final production. Previous work using the Web in engineering design education either involved rather limited scale (Wallace, [1,2]) or was solely used in graduate design courses (Hong et al. [3,4]). But would it work in the undergraduate setting, for the complete design cycle?
Figure 1. The concept of Distributed Interaction in Design Projects
We chose to implement a product called ”WebBoard” as the Web-based collaborative design tool for use in the ME-395/ME-495 design course sequence2. The WebBoard program has been used successfully by several large companies as an effective tool for communication among employees working and residing in different time zones. The challenge was to see if this particular product could be implemented in the design project classroom setting. What follows is a brief description of the WebBoard program.
First-time users (or ”New Users”) of the WebBoard need to log-on to the program; this, in essence, is a registration process, during which each user chooses a login name and password and provides his or her name and e-mail address, and has the option to provide other information (e.g. location). The user will need to provide the login name and password for all subsequent entries into the WebBoard program. See Figure 2.
Figure 2. WebBoard Login Page
The WebBoard essentially mimics the ‘electronic bulletin board’ structure found commonly on the Internet. That is, having accessed the program, the user is presented, on the left-hand side of the Browser window, with different topics (called ”Conferences”), each containing messages (or ”Posts”) relevant to that particular subject. In selecting a Conference, the user then is able to view the ”Topic” of each post contained within that Conference (these topics are designated at the time of posting message.) See Figure 3.
Selecting a Topic within a given conference then reveals, on the right-hand side of the Browser window, the text of the given Posting. The user is able to view the posting date, name of the person submitting the message, and the body of the message. Also visible, at the bottom of the message area, are any attachments included with that particular posting. The user can quickly move between Topics and Conferences by using the Index on the left-hand side of the Browser, or by using the navigation buttons (”Next,” ”Previous,” ”Next Topic,” ”Previous Topic.”) in the Message window, or the Web Browser navigation buttons.
The WebBoard program allows users to easily post New Topics within a given Conference, or to Reply to messages already submitted; these new messages are organized and arranged hierarchically. Significantly, the WebBoard also facilitates the use of attachments: it is relatively simple to include any kind and number of files (e.g. documents, pictures, executable programs, etc.) along with the text of a message, though it must be noted that this is a bit tricky at first.
Having users logon to the WebBoard has several advantages. First, it allows the program to keep track of which Conferences you’ve visited and which messages you’ve read. This means that on a subsequent login, having marked messages as ”read”, the WebBoard will greet the user and direct him or her to New or ”un-read” messages. It is even possible to request that the WebBoard contact the user via email when a new message is posted to a given Conference. Secondly, it allows the WebBoard to be configured to grant access to certain Conferences only to designated users; this provides managers or administrators to divide the WebBoard into ”public” Conferences viewed by all who logon, and ”private” Conferences, whose contents are visible only to specific users or groups. Finally, it offers the administrators a means by which to monitor WebBoard activity: logins, postings, current users, etc.
Figure 3. WebBoard Layout & Hierarchy
Set-up of the WebBoard, complete with various public and private Conferences is relatively simple, though it can be time consuming for many Boards and Conferences. The manager or administrator’s area allows for straightforward editing and manipulation of the conferences, including adding or deleting users (for private Conferences), changing Conference co-ordinator status, or even deleting a given Conference once it is no longer needed.
After three quarters’ experience, and thus three design iterations, we believe that have identified a fairly robust procedure for successfully implementing our Web-based collaborative design tool into the undergraduate classroom. This process is composed of several key elements (roughly in order of importance):
The major result of our iterative work was the recognition that each project group required its own WebBoard. In order to effectively organize, manage, and analyze the large amounts of information being transferred as part of the product design process, it was necessary that each team have the ability to access, modify and create multiple directories (or Conferences). These partitions enabled the teams to create private work areas, public ”Display Cases,” and other topic-specific regions (e.g. ”Questions for the Client,” ”Brainstorming for Component X,” etc.) It is important to note that the student teams were truly responsible for the set-up, management and maintenance of their WebBoards: apart from a minimum set of standard Conferences common to all teams (see sample WebBoard, below), the groups were free to structure their WebBoards as they saw fit.
Paralleling the recognition that each team needed its own WebBoard was the realization that, in order to function efficiently, it was necessary that the instructional staff have its own WebBoard, too. It is in this WebBoard’s various partitions that class announcements are posted (in the ”Class Announcements” Conference, naturally), that handouts and other documents are made available, that groups deposit assignments and receive comments, that deadlines are posted, and so on. If multiple instructors are involved in the course, it is possible to create private Conferences in which they can discuss various aspects of the class. The creation of this WebBoard greatly improved the ease with which the instructors collected and critiqued the student groups' assignments, and also greatly facilitated the distribution of templates and handouts.
In order to ensure that both the instructional staff and the students would feel comfortable (or at least be capable of) setting-up, modifying and managing their own WebBoards, it became clear that it was important to develop a brief, introductory user's manual to the WebBoard. This reference text [6] was aimed at getting users familiar with elementary WebBoard functions (posting, attaching documents, downloading, etc.) as well as more advanced features, such as creating and editing Conferences. An orientation session was conducted at the beginning of the course, during which the manual was distributed and the basic procedures were discussed and practiced. Follow-up sessions were held with each team (and some instructors), gauging their respective progression. Additionally, students were encouraged to contact the WebBoard co-ordinator (the ME 395 and ME 495 teaching assistant) with their questions at any time.
As mentioned previously, the student groups were responsible for the structure and content of their WebBoards. However, we did set up a Sample Project WebBoard (see Figure 4), accessible from the Product Design Education homepage; each group was responsible for configuring their Board so that it at least had every Conference that appeared in the Sample Project Board. In this way, every group had a standard set of Conferences in its WebBoard, and this greatly aided the instructional staff in finding information quickly in a given group's project space. The Sample Project Board also demonstrated a WebBoard standardized document-naming convention for attachments that included the group name, posting date, and document revision number3. This standardization also made spotting the most recent version of a document-in-progress—which was often being modified by several individuals simultaneously—much easier.
Figure 4. Sample Project WebBoard
The final element that we identified as being critical to the successful implementation of a Web-based collaborative design tool in the undergraduate classroom was the development of Design Activity Templates. The impetus behind this work was the need for the student design groups to document their design activities in a consistent manner (in a way other than through the use of old fashioned design notebooks) that reflected both individual and group work. We developed templates for meetings with clients, vendors, instructional staff, and the team, as well as for peer reviews, Gantt charts, and for tracking project assignments. These templates, available on the course WebBoard, were used to document the design activities of each team; completed versions resided within the groups' WebBoard and were posted to the course WebBoard to be evaluated by the course instructors.
WEBBOARD USE: The WebBoard was used extensively throughout each course. Class announcements, deadlines, and other class information were frequently posted to the course WebBoard. The students were required to post group assignments, including work involving the production of a PowerPoint presentations, project report drafts, and meeting reports; they also submitted anonymous peer reviews. Typically, the design teams, having divided up assignments into various parts, used their WebBoard to present their work to each other in pieces, to be compiled into a final draft by the designated task lead. Several groups completed brainstorming sessions, started in class, via postings to the WebBoard; material was often scanned from design notebooks and then attached to a message. Some teams, having found relevant information at a particular Website, included that "http://" address into the text of their postings, and the WebBoard program instantly turned that text into a hyperlink. The instructors and clients, posting messages of their own, commented frequently on the students' work and also answered questions.
WebBoard use at the end of a quarter tends to increase greatly, as groups begin compiling their final project reports and work on their poster presentations. In most groups, various team members posted different portions of the report, and these were compiled into drafts that were then evaluated by the instructors. Students brainstormed and made suggestions for changes, often re-attaching updated documents to the WebBoard.
At the end of each academic quarter, the students were asked to fill out a survey [6] designed to evaluate the WebBoard as a Web-based collaborative design tool, and to offer suggestions for improving its implementation into the design classroom.
The results of the survey are generally quite positive in favor of both the WebBoard program and its implementation into the undergraduate design courses [6]. Below is a summary of the major findings:
The students rated the WebBoard for the following categories
(Scale: 0 = difficult, arduous; 7 = simple, fast):
|
Question |
Aut. Qtr. |
Win. Qtr. |
|
WebBoard "User Friendliness": |
5.4 |
5.1 |
|
WebBoard Ease of Posting: |
6.1 |
6.2 |
|
WebBoard Ease of Attaching Files: |
5.8 |
5.3 |
|
WebBoard Ease of Downloading Files: |
4.7 |
5.6 |
|
WebBoard Ease of Organizing Conferences4: |
4.1 |
4.2 |
The students also responded to the following
(Scale: 0 = very poorly; 7 = exceptionally well):
|
Question |
Aut. Qtr. |
Win. Qtr. |
|
How well was WebBoard introduced to ME-395: |
5.1 |
5.4 |
|
How well was WebBoard integrated into class work: |
4.8 |
5.6 |
|
View mandatory use of WebBoard in a design class: |
3.8 |
4.7 |
Most students greatly appreciated the ease of posting messages and especially of downloading documents, noting that trying to collaborate as they did this quarter, only using email and floppy disks, would have been considerable more difficult.
Overall, the WebBoard program itself, and its implementation into the University of Washington's Mechanical Engineering design classes, was viewed favorably. Many students commented that they really appreciated having a resource that allowed them to share information—in comments, documents and drawings—in a single location, accessible from any computer linked to the Internet. They indicated that they liked the flexibility that the program afforded, in allowing them to work outside of "business hours" (45% of postings), and from computers not on campus (44%).
Only one student, out of 67 who have responded, absolutely hated using the WebBoard. But many did have suggestions for improving its ease of use and implementation into the coursework. Most suggestions centered on improving the way in which the WebBoard Conferences could be organized: deleting postings, sorting messages, and grouping posts by topic. Several students indicated that the WebBoard file attachment feature could be improved, by better file-type recognition, allowing all typographical characters in filenames, and even the ability to edit attachments directly (without having to download, edit, and then re-post). The WebBoard also was criticized for not having an automatic recognition of postings that have been read (this needs to be done manually). There were other suggestions regarding the implementation of the WebBoard program in the design classroom, and about not making use of the WebBoard mandatory, especially for projects where all team members and clients are co-located.
Several of the comments from the earlier quarters were influential in our iterative improvement considerations, including establishing file-naming protocols, providing specific locations for the posting of documents, and allowing for better structure and organization of design project information.
In light of the student responses and the evaluation of the ME-395 instructors, it seems very clear that the WebBoard collaborative design tool has had a significant positive impact on the development of the student design projects. The instructors and students valued the ability that the WebBoard afforded in allowing feedback and input to be made while portions of projects were still in draft stages. The instructors were able to communicate easily to the entire class, or to specific teams, and they, too, appreciated the geographic and temporal flexibility the WebBoard program provided. The classroom implementation of this technology could be improved by refining the templates and integrating their use more seamlessly into the course.
In using the WebBoard, we were able to provide an organized structure for effective team operation and co-operation, and for more efficient use of student, client and instructor time and energy. We developed new ways of documenting and reporting both individual and group design activities. The implementation of the WebBoard facilitated communication between the primary stakeholders in the design projects: the student group members, instructional staff, and the project sponsors. The use of a Web-based collaborative tool in undergraduate design classes is highly recommended.
|
[1] |
Wallace, D., and P. Mutooni, ”A Comparative Evaluation of the World Wide Web-Based and Classroom Teaching’, Journal of Engineering Education, Vol. 85, No. 3, pp. 211 - 219, July, 1997 |
|
|
[2] |
Wallace, D., and S. Weiner, ”How Might Classroom Time Be Used Given WWW-Based Lectures”, Journal of Engineering Education, Vol. 86, No. 3, pp. 237 - 248, July, 1998 |
|
|
[3] |
Hong, J., Toye G., Leifer, L. "Using the WWW for a Team-Based Engineering Design Class," Electronic Proceedings of the 2nd WWW Conference, Chicago, IL, October, 1994. http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/Educ/hong/hong.html. |
|
|
[4] |
Hong, J., Toye, G., Leifer, L., "PENS: Personal Electronic Notebook with Sharing," Submitted to the Fourth IEEE Workshop on Enabling Technologies, Berkeley Springs, West Virginia, April 20-22, 1995. |
|
|
[5] |
Phang, F., Senin, N, & D. Wallace, ”Distribution Modeling and Evaluation of Product Design Problems”, Computer Aided Design, Vol., 30, No. 6, pp. 411- 423, 1998 |
|
|
[6] |
Hailey, M., "Getting started with the WebBoard", "WebBoard Survey", and "WebBoard Survey Results." See http://columbia.me.washington.edu:8080/~ProdDesEd/; enter as Guest. |
|
Funding for this project was provided in part by NSF Award #DMI 9726178. The help of Ms. Dongmei Gui in setting up and maintaining the WebBoard was appreciated. The WebBoard server was provided by a gift/grant from the Hewlett Packard Corp.
1 We used the Web discussion board developed by WebBoard, Duke Engineering and O'Rielly Assoc., Inc., ©1995-1998; Email: Software@oreilly.com
2 Developed by the Computer Science department of Duke University, the O'Reilly WebBoard program was recommended by Professor J. Heim.
3 The need for this procedure became evident when, in downloading the files submitted by each group for a particular assignment, we noticed that a majority was entitled "GanttChart.xls!"
4 These scores in particular illustrate the need for organizational flexibility. Accordingly, each team was given its own WebBoard, for the Spring Quarter class.