Project Report – Telementoring Workspace
PROJECT REPORT – TELEMENTORING WORKSPACE
Viil Lid and Matthew Sharritt
ICS 667, Fall 2002
Dr. Daniel Suthers
Table of Contents
1.Introduction
2.Requirements
2.1Root Concept
2.2Interview
2.3Artifact Analysis
2.4Problem/ Activity Scenarios
2.5Claims Analysis
2.6User Role Models
3.Design and Prototype
3.1Essential Use Cases
3.2E-R Model
3.3Context Navigation Map
3.4Contexts
3.5Interaction Scenario
3.6Prototype
4.Evaluation and Redesign
4.1Icon Testing
4.2Prototype Testing
5.Conclusion: Discussion of Methods
6.Appendix
1.Introduction
Telementoring is a mentoring relationship or program in which the communication between mentor and mentee is computer mediated, where mentoring is defined as a sustained relationship between a youth and an adult. In a well-structured mentoring relationship, the adult provides help, support and guidance to the mentee.
The idea of telementoring is to use telecommunications technology to support mentoring relationships between students and volunteering field experts. This is particularly useful in situations where face-to-face mentoring would be hard to carry out. We predict that telementoring, both within traditional education and the business world, will be a growing area in the future. It will connect mentees with field experts in a worldwide context. As there currently does not exist any customized software to support telementoring we believe this is a great opportunity to get a competitive advantage and lead the way for telementoring software. We will focus on the development of a new software tool for the use of educational telementoring.
Typically students of lower grade levels have teachers with knowledge of general topics in education. Therefore when students are working on projects or field studies that require expert knowledge of a particular field, their teachers cannot always provide them with the assistance they need. In these cases students are often left to seek additional knowledge via sources like the school library and the Internet, where the abundance, or possibly lack of, information can make it difficult and time consuming for the student to find what is relevant for their particular project. Scientists and other field experts may not be available in the local community, and students might not know where and how to get in touch with authorities within their field of interest. Currently the communication between students, teachers, and field experts in a telementoring relationship is primarily done by e-mail or in discussion groups. Our proposal is to make software specifically for telementoring, thus considering the needs of the various user groups in a telementoring relationship throughout the design process. The software will provide a workspace where this interaction between telementor and mentees can take place. Early attention was given to usability, since a key advantage over other existing tools will be that our tool is simpler for mentors and mentees to use.
The methods used throughout this project includes root concept, interview guide, user role modeling, artifact analysis, problem and activity scenarios accompanied by claims analysis, essential use cases, entity-relationship modeling, contexts, prototyping, and usability testing. We believe that prioritizing spending time on these methods allowed us to design a system that has clear advantages over existing systems. With a growing need for telementoring software due to the shortcomings of existing tools, we believe moving on this now will give us the opportunity to gain a key market advantage being the first to create this kind of tool. We have the opportunity to be the first and set the standard, as well as be the only offering such a tool
2.Requirements
We started out defining the root concepts of our project in order for us as a development team to have a common understanding of what we were trying to achieve. Then we continued to define the requirements for Telementoring Workspace software as we conducted interviews with representatives for the core stakeholders in our project. Based on the results of these interviews we were able to conduct a requirements analysis for the system.
We prepared a user role model document that describes the roles, backgrounds, expectations, profile, objectives and knowledge of the various stakeholders. We also prepared an artifact analysis that surveys some existing system offering features useful for telementoring. In addition to this we prepared three problem scenarios, three activity scenarios, and a derived claims analysis, which served to find problems with the existing technology and propose solutions to these.
The results of these methods can be seen in the appendix.
2.1Root Concept
The first step we took in our project was to write a Root Concept. This defined what the goals and aim of our project are. We defined our vision, rationale and our stakeholders for the project. Also, we defined our starting assumptions and constraints for the project. This part of the project gave us a starting point for the project- our starting point, what we envisioned ourselves accomplishing, why it was necessary, and who was involved.
2.2Interview
We wanted to interview users to gain knowledge of some of the limiting factors that we would have for our project. For example, we wanted to know what computer equipment our users had, what kind of Internet connection they had, and how much access they had to the equipment. This allowed us to get a feel for what their needs were. We also wanted to get an understanding for their knowledge background related to telementoring. We were able to find out if our sample users were familiar with telementoring (after explaining the definition), and see how they currently interact with each other for similar types of projects.
Interviewing also helped us to determine what type of information is exchanged in related activities so we can design a system that supports this type of information exchange in a more efficient manner than the existing tools. This lead us to ask our stakeholders what features on current systems were likeable or dislikeable, so we could design a system that had advantages over the existing technology.
In preparation for the interviews we made an interview guide which took into consideration the various stakeholders recognized in our root concept.
Because of the short time available for this project we decided to limit the interviews to a couple of representatives for each of our three main stakeholders; mentors, mentees, and the mentees supervisors. If there had been more time available for this project we would have liked to do more interviews in order to find general trends rather than individual preferences. As representatives for Mentors we interviewed two graduate students, as Mentees we interviewed a high school student and an undergraduate student, and two K-12 teachers and a university instructor represented the supervisor stakeholder group.
Before each interview we explained the term "Telementoring" to ensure a common understanding of what it is.
We found that half of the interview subjects have experience with telementoring / mentoring using Telephone, e-mail, and/or chat room. Most expect telementoring to be some sort of relationship between a student who could use help from an expert, and the expert with knowledge in a particular area, and they would all like a tool that is easy to use, and some expect some sort of a collaboration tool.
Most of our subjects expect a project to last from half a semester to a semester in length, with some sort of presentation at the end. Collaboration takes place throughout. All expect the outcome of the project to be students having gained knowledge on a particular subject, while utilizing tools such as mentors to aid them in their work.
All our interview subjects have access to newer computer equipment with a fast Internet connection whenever they wish. Some are experts, the rest have a moderate amount of computer expertise mostly using text editing software, browsing the Internet, and playing computer games. The subjects had varying likes and dislikes when it comes to software and features, but they all agreed that being easy to use is an important trait.
Most of our subjects liked meeting in person, and disliked using chat rooms because they weren’t private. All are familiar and like to use e-mail, and all but one are familiar with discussions, and think they have advantages / disadvantages, such as anonymity. All would appreciate a mixture of chat and discussions to accommodate the most number of people. Most would like to know whom they are working with, some personal information, and some credentials. If participating in a telementoring they would like to know some personal information, then some information on the details of the project. As a mentor they would like to know about the relationship between stakeholders, and the mentee’s general knowledge level, so information can be presented for their level, and they would expect to spend around two hours per week telementoring.
2.3Artifact Analysis
Because of the lack of existing telementoring software we did an artifact analysis of systems containing aspects and features useful for mentors, mentees, and supervisors that are looking for ways to communicate with each other. We found that the various tools are mostly poorly integrated. The free tools has a bonus for those with a low budget, but they all contain components which require downloading and installing software, which requires memory space and may for some users also require retrieving permission and assistance from a system administrator. Any of the three free suites above provide a bit of simplicity in the fact that you only need one login / password to access any of the services. But they all suffer from "sneaking featurism" because of their commercial nature and the expectations of continuously upgrading their products by adding more features. WebCT also has bundled features that are available under the same login and password.
We definitely see the need for a fully integrated system tailored for telementoring, offering artifact sharing and asynchronous and synchronous communication that can be archived in order to preserve useful information for the benefit of others. The system should be accessible to the users via an Internet browser, and not require installing additional software. The system needs to be easy to use and easy to navigate in order to retrieve information, and should be stripped for unnecessary features and functionalities that may confuse and distract the users.
2.4Problem/ Activity Scenarios
Based on the findings in the interviews we wrote three problem scenarios describing problems encountered by users when using software that is designed for other purposes than telementoring. Writing these scenarios was an iterative process as we consulted users in order to make them as representative as possible.
As a response to the problem scenarios we then wrote three activity scenarios illustrating how we proposed the Telementoring Workspace software to provide improved support for telementoring. These scenarios were presented to some users in order to get their opinion about the solutions they proposed
2.5Claims Analysis
Both problem- and activity scenarios were accompanied with claims analysis emphasizing the positive and negative aspects of the features presented in them. The claims analysis made it clearer what tradeoffs were connected to the various features present in the scenarios.
2.6User Role Models
For our User Role Model forms, we put our stakeholders into three categories: mentor, mentee, and supervisor. First, we viewed our mentor as the ‘outside expert’ who voluntarily was brought into a project to assist someone (the mentee) who is in need of expert help or guidance. Second, we thought of the mentees as those who would be benefiting from outside expertise- those with the projects that they would need expert assistance with. Typically the mentees would fall into the category of being in school. Our third stakeholder was the supervisor. We envisioned the supervisor role as anyone who was overseeing the project. In the case where the mentee is a student, the supervisor would probably be the student’s teacher / professor. The supervisor could oversee multiple projects, and interact in the communication if they chose to do so.
Overall, the User Role Model forms helped us categorize each of our three users, and see more clearly the properties of the stakeholder that we are designing our system for.
3.Design and Prototype
For the design phase we prepared some essential use cases, which served to isolate the design issues we determined in our activity scenarios. Further we created an entity-relationship diagram showing the components of the new system and how they inter-relate with each other. Based on these documents, along with the Activity Scenarios, we made some Contexts. The relations and transitions between the various the contexts were shown in a Navigation map.
After revisiting documentation from our requirements analysis and design process with representatives from our user group we developed an interaction scenario with a related prototype describing a new user's meeting with the Telementoring Workspace. In addition we have a second view of the same prototype showing an experienced user logged in at TW. Finally we did some usability testing of aspects of our prototype. The test results emphasized strength and weaknesses in the Telementoring Workspace software, and gave us a better impression what aspects of the system need to be improved.
The results of these methods can be seen in the appendix.
3.1Essential Use Cases
We developed Essential Use Cases for the purpose of re-designing some of the issues we came up with in our Problem and Activity Scenarios, and the Claims Analysis. The Essential Use Cases show the envisioned user action and system response required for the system’s ‘essential’ tasks. However, they are still very abstract, so that implementation decisions are not made. Our Essential Use Cases show the main features of our proposed system, such as using the chat, discussion, searching for other discussions, adding a friend to your ‘friend list’, uploading a file, creating new workspaces, and viewing recent activity. These Essential Use Cases provide us with an abstract picture of how our envisioned system will work. A lot of our design work was done on this part of the process, and takes one step closer to creating a prototype.
3.2E-R Model
We created an entity-relationship model showing the main components of the new system and how they inter-relate with each other. This was used as a communicative tool for the designers to have a common understanding of what the main elements in the system would be and how they would interact.
3.3Context Navigation Map
The Context Navigation Map provides navigation between the Contexts we created. On our individual Contexts, the dark purple bars designate links to external Contexts. All of these links can be seen together in the Context Navigation Map, and provide a good high-level view of the system and how one can move through it. For a description of the Contexts, see below.
3.4Contexts
Our Contexts were based on our Essential Use Cases, and are based on the nouns and verbs that were in the Essential Use Cases. The nouns turned into the items in the Contexts, and the verbs were the actions that one can perform. Our Contexts were drawn with four colors. Dark yellow designates the Context, light yellow designates a content display area, dark purple designates a command tool that takes you to another Context (see Context Navigation Map), and light purple designates a command tool that carries out actions within the current Context.
The Contexts took the design we came up with in our Essential Use Cases, and translated them into something visual that was very helpful to us in making a prototype.
3.5Interaction Scenario
Our Interaction Scenario describes some features that we felt were necessary to include in the Prototype that were not covered by the Essential Use Cases. Basically, they covered a user using particular features of the envisioned system. In our case, it tied in very closely to our prototype, and provided a glimpse of a hypothetical user using our system. We were able to link this to the prototype we made, so that when reading one can go back and forth between the two to clarify what is being read.
3.6Prototype
The prototype is an implementation of the system we designed in the steps above. Being an initial prototype, we expected some problems with the interface, which will hopefully be discovered later on in our usability testing. We conducted icon testing to see the effectiveness of our chosen icons, and followed with prototype testing for feedback on the complete prototype / implementation.
4.Evaluation and Redesign
Software development is an iterative process and user participation is recommended along the way. We conducted a usability test on the Telementoring Workspaces prototype, and received some useful feedback.
4.1Icon Testing
We conducted icon testing, for the purpose of evaluating the icons we chose to use on our prototype. We tested a handful of users, and based on their feedback, we were able to determine how effective our icons were. We tried to choose icons in our prototype that represented well the items they corresponded to, so that a new user would be able to figure out what an item was without too much investigation.