Group Design Project 4
From VMT
- Return to Designing Social Interaction Software
Contents |
[edit] Instructions
- This week we begin the design process proper. We have looked at the issue of social networking for an online activity like VMT math chats or the knowledge-building synchronous interactions in this course. Now it is time to start to design some new functionality that will enhance the VMT environment to better support social networking related to the goal of the larger activity.
- The first major design phase is to begin to focus in on an area of computer support or a problematic area of interaction that your team would like to address. The traditional software engineering approach is to prepare a requirements specification. In our more user-centered approach, we want to describe the kinds of interactions we would like to see between users and computer interface or among users mediated by a new computer interface. We can do this by describing visionary scenarios of how our new system might be used. We can formalize this required functionality with what the textbook calls "use cases".
- An important characteristic of these approaches is that they do not yet specify details of the software implementation or even of the interface design. Once your group decides on one or more areas of functionality to work on, it will be important to be open-minded about a broad range of implementation possibilities. It will also be important to involve potential users in reacting to and discussing the scenarios and use cases. In our course, we do not have access to users other than the members of the class, who are using the VMT environment. So we will share the Week 4 postings and react to each other's postings.
- For Week 4, chat in your groups about what kinds of social networking functionality you would like to work on. Prepare brief but concrete scenarios of how you imagine things working and specify some core functionality in terms of use cases.
[edit] Comments on Group Statements
- Use cases are discussed in Chapter 10, esp. pp. 510-515. You should look at this for ways of formulating your use cases this week.
- Word smithing: The wiki provides an opportunity for everyone in a group to edit the text that one person posted. Some of the postings read like rough first drafts. The wiki allows everyone to edit these drafts so that the group ideas are more elegantly presented. Computer-support tools like chat systems and whiteboard textboxes encourage rushed and sloppy writing. The easy-to-edit-by-everyone style of the wiki allows you to refine posted texts. Good written communication almost always requires iterative improvement.
- Feedback on use cases Most of what is posted below are what I would call very brief scenarios, rather than use cases. I think of use cases as almost psuedo-code laying out the steps and the logic of a proposed operation as an interaction between a user and a computer. Here is what I have in mind roughly:
- Use case for UN-DO button
- User: wants to un-do the creation of a textbox with its content
- User: selects textbox
- Computer: indicates textbox is selected
- User: clicks on un-do widget
- Computer: checks if user is the creator of the textbox
- Computer: if user is not creator, display notice that user is unauthorized to un-do textbox because not creator -- end of use case
- Computer: checks if anyone else has edited textbox
- Computer: if anyone else has edited textbox, display notice that user is unauthorized to un-do textbox because someone else has edited textbox -- end of use case
- Computer: un-do creation of textbox -- end of use case
- Multiple whiteboards It is interesting that there is so much emphasis on multiple whiteboards below -- right before the release of an implementation of VMT that supports tabbed multiple whiteboards. This gives you an opportunity to really explore what a simple working prototype of this is like. Note the "+" button next to the tabs for creating more tabs. In addition to whiteboard tabs, you can also create two forms of browsers: One that uses IE and can display Flash and CSS, etc. but does not support referencing from chat and sharing. A simple browser that supports referencing. When you reference a web page, then that page's URL appears in the tab's pull-down history for everyone else. The referenced tab name appears in green, so other users know which tab to look at. If you want to design uses of multiple tabs, you can now try things out with your group. This is a great advantage in designing functionality for group usage.
- BTW, copy & paste between chat postings and textboxes and wiki sometimes requires you to hold down your ALT button while selecting text, before using Ctrl-C and Ctrl-V. This is because just selecting the text is used for other functions, such as referencing.
- Gerry 13:36, 6 May 2007 (EDT)
[edit] Team A Statement
- Olivia, Seth, Brian
- Seth_E 21:19, 25 April 2007 (EDT)
Knowlege building sychronous interaction: Problematic areas of interaction
The white board can easily become overwhelmingly unmanageable due to the synchronous activity of multiple users on the system. This confusion can occur when several group members are working or discussing a project which contains many aspects or problems to solve.
Solution/Functional requirement: A whiteboard that has a "master" whiteboard plus chat and the capability to add several sub-whiteboards which would be linked to the master white board. The sub-whiteboards would also have their own chat capability.
- A group would first collaborate on a project using the Master whiteboard, The goal of using the whiteboard is to define and break down the whole design project into sub-parts as much as possible. Users would determine how to arrange the layout of the Master whiteboard based on how many sub-whiteboards are necessary for that specific project. The main white board would be where the group would hold more general collaboration about the overall project. This area would also provide the team with a overall look of the project. Each sub-whiteboard area in the Master board would provide enough information from the sub-white board to briefly represent the board's content.
- The sub-whiteboard would further break down parts or aspects of the project/problem/major topic. The function of a sub-whiteboard is to provide extra space for more collaboration, interaction and documentation for specific part or aspects of the overall project represent by the Master whiteboard. Group members would be able focus chats to specific pieces or parts or the project, when in sub-whiteboards.
- In the end, the Master whiteboard would act as the interface between the parts of a project and each individual chat area and all participant input. This design is robust enough to allow the user to determine exactly how many subboards they want to include in their main whiteboard. Even while working on the project, they could delete or add subboards as necessary.
- The current white board quickly runs out of room for collaboration. With our new whiteboard/sub board setup group members are provides more space to store additional aspects of the project which are visual for the team members for quick preview. Just by click the part of the Master whiteboard for that part of the project. One function our group discussed, but decided not to implement, was the ability for participants to collaborate simultaneously in separate subboards. The reason we decided to reject this opportunity was the fear that participants would engage in more cooperative interaction, rather than collaborative interaction since they may end up working in separate subboards and just combine their work in the end. This capability would support larger and diverse specially teams/groups for a project and should be considered only in the case of an extremely large number of users/students.
Use Cases
- Use Case 1: Users want to organize their work by separating the information into separate windows.
For example, the project may be to design an interface for a certain subset of children with a particular disability. The group may decide to discuss different topics such as the problem statement, the conceptual design for the interface, and the physical implementation of the design. They can then opt to create three sub-whiteboards (one for the problem statement, one for the conceptual design, and one for the physical design).
- Use Case 2: Users want to present their overall work in one whiteboard (prior to copying over to Wiki)
The users can work on the project's sub-problems on the separate sub-whiteboards. When they finish up their collaboration, the work will be transferred over to the main whiteboard, where they can further modify the layout of the subboard content and resize the windows as desired.
- Use Case 3: Team X decides that they will "split-up" the work for an assignment by joining separate whiteboards to work individually and combine their results into one final product.
The design of the sub-whiteboards will prevent this type of cooperative work and will force all users to populate the same subboard so that they must collaborate on their work. This requires students to work together and learn from each other, rather than appending each other's separate work into one final result.
[edit] Team B Statement
- Kate, Elizabeth, Fernando, Dave
- Dave 21:00, 1 May 2007 (EDT)
[edit] Enhancing the formatting options on the whiteboard.
Editing on the whiteboard can be frustrating and difficult at times. To help alleviate some of the issues users may experience when working on the whiteboard, the following tools were suggested:
- Undo
- Bolding of individual words
- underline of individual words
- Text color of individual words
- hyperlinks for reference
- Highlighting
- Font size
- Drag and drop option
- Markup view
By enhancing the formatting options on the whiteboard, users will be able to edit their work with more ease, thus improving communication and productivity.
[edit] Enhancing communications in the chat
Communicating in the chat can be difficult due to several challenges: differences in typing speed leading to out of sync conversations and no sense of presence, when a user is away the other users are unaware. To resolve these the following modifications are suggested:
- Integrated audio chat (similar to skype)
- Presence indicator (online, away, be right back, on phone, etc.)
[edit] Use Cases
[edit] Use Case #1
Undo Typo/Erroneous Entry
Main Success Scenario: User is able to undo typo or insert of erroneous data.
Sally is new to the whiteboard and she is attempting to fill in an equation to calculus problem that many have been working on for weeks. After 10 minutes of typing and making changes she notices that her solution isn't correct and would like to go back to were she started. She clicks on the undo button and is able to get back to where she started without deleting anyone elses contributions. She now inputs the correct equation.
[edit] Use Case #2
Sense of Presence
Main Success Scenario: User is able to know when others are away or have returned.
John logs in to VMT. The rest of his group logs in. They start a discussion into use cases. Midway through the discussion John has a stomach ache and has to literally run to the restroom. He clicks on his name and sets his presence to away. Rose is just about to ask John a question but sees that he is away, she continues to discuss the use cases with the other group members. John returns and clicks his name to set his presence to online. Rose sees that John is online and proceeds to ask him if he posted yesterdays summary to the Wiki.
[edit] Use Case #3
Text Formatting
Main Success Scenario: User is able to format text (bold, highlight, color, italics, font, font size).
Jose is helping Sara with a simple equation. He is chating the instructions and then also writing the names of the processes on the white board. He wants Sara to be able to find the corresponding instructions about the processes in the chat discussion. He proceeds to use the formatting tools to color code the match the processes they are discussing with the names on the white board. Sara is able to follow along and using the color coded is able to match processes in the chat area with names of processes on the white board.
[edit] Use Case #4
Voice Chat
Main Success Senario: Users are able to communicate quickly, easily, with less confusion.
Brad logs into the chat with the other 4 members of his group. Soon they start a conversation on some of the items on the whiteboard. Brad being the slow typer he is is soon left behind as the others quickly respond and post questions to each other. Brad flags the groups and let's them know he is behind the chat. He clicks on the audio button and is now able to talk to the other group members. The other members are free to join Brad, though some continue to type while listening to his responses.
[edit] Team C Statement
Group statement on project. Group design project: Problem: One issue with the whiteboard is that it fills up too quickly with multiple people working on the same project or one group working on multiple projects at the same time.
Solution:The whiteboard could be changed to have multiple whiteboards so that users could either break up and each use a different board or use different boards for different projects. This will also assist with organizing information as the project is being worked on. To prevent confusion the whiteboards would need the ability to be named by members of the group. These named would appear on tabs at the top of the whiteboard area that could be clicked on to bring that specific whiteboard to the front and become viewable. Since this would create more viewable room to work with and users could be on the wrong whiteboard there would need to be a way of communicating which user is using what board. Instead of just listing the current user in the box above the chat our proposed solution would list the user and then what whiteboard they are viewing. The referencing tool for the chat would also have to be improved by adding a reference at the end of the chat text that includes what whiteboard the reference is linked too. Then if the user has that whiteboard selected the user would see the reference arrow but if the user had a different whiteboard selected then the user would know which whiteboard was being references and when that whiteboard was selected the user would see the arrow.
Use cases:
Case 1: Users want to break up and assignment to each work on different parts at the same time then combine their work together at the end. Each user could create thier own whiteboard and work on within it. Other users could change over to the whiteboard that other users create to add input and then change to another whiteboard. When the assignment is wrapping up the group could go through each whiteboard and discuss the work together then cut and past what they agree on into a final whiteboard for presentation.
Case2: Users have an assignment with multiple parts. The users want to work on each part as a group but must present all parts of their assignment at the same time. the users could create one whiteboard for each part of the assignment and move between the different whiteboards so there is plenty of space to work. The when the assignment is finished and presented each part of the assignment would have it's own whiteboard so the information would not get jumbled together.
[edit] Team D Statement
- Members :: Bertha, Jeeves, Eric
- Date and Time of posting : Eric 21:24, 25 April 2007 (EDT)
Group statement on project. Group Design Project Week 4:
Case 1) Creation of aditional Workspaces
Requirements: User controlled creation of additional pages/space in whiteboard on the VMT chat interface.Cut and Paste functionality between collaborative workspaces
Scenario: Adding information for multiple documents and separation of ideas through use of a mind map.
a) User enters information for a complete document into one testbox that takes up the entire screen to be effectively viewable. The user has to expand the text box to cover the screen as it does not support scrolling information within that space. b) User has to separate data based on mind mapping principles where proposed and definite ideas cannot be concurrent in a text box. c) Team members also need to be able to contribute to the same whiteboard and have it accesible to other members. d) User creates a new tab, and sets the permissions for the user created tab. These permissions include, read, write and copy access on a per user basis. e) Team members will be able to access the second page and copy/edit based on the permissions first set by the creating user. Multiple persistent tabs can be created to simulatneously work on multiple threads of information.
Case 2) Adding audio as an additional medium
Requirements:Implementation of a shared audio space in addition to chat and whiteboard.
Scenario:Audio input from users as a collaborative medium to augment and possibly replace the chat board
a)Upon entering the shared space of the Wiki or VMT environment users would be automatically added as a conference audio phone call. b)Users would give their screen names before being added to the group c)Users could speak or mute their input to listen to shared conversations d) Users can provide ideas at the same speed as speech, thus reducing perceived deficiencies in contribution time, if slower at typing than speach rate.
Case 3) Direct Posting and publication of collaborative efforts:
Requirements: Submission of text boxes to central server save text boxes in different formats to hard drive enter and build mathematical formulae directly into whiteboard, as a text, not figure.
Scenario: User has to save exact depiction of formulae and data from whiteboard to a local hard disk as backup, and submit the results of the collaborative effort directly to the appropriate location.
a) User has to enter a mathematical or scientific formula requiring the use of complex characters. Whiteboard does not easily show a way to enter this information directly. b) User edits and saves the contents of a text box to a Word, RTF or Text document. c) User and team collaborate on a single document by adding information to multiple text boxes, and then have to combine the text on each text box in a single document. However each text box takes up space, and requires multiple steps to complete, and needs to be able to save directly to the wiki server. d) User can read information posted for the topic in a user modifiable sized container that can be mounted on any point of the window.
- Return to Designing Social Interaction Software
