...
Before the heuristic evaluation we only had the 2 right drop-downs in Figure 3, 'My Buckets' and 'My Alerts'. Based on feedback from the heuristic evaluation, we added the option to sort by due-date. These drop-down menus can easily be opened and closed, and do not take up unnecessary room on the bulletin board (as the list of tasks in the initial design did). Buckets / dates can be expanded to show the tasks within them, as was requested by users.
Bucket / Task Papers
Figure 4: Multiple PapersFigure Figure 5: Zoom-in List of Tasks on a 'Bucket Paper'Task / Bucket Papers
Another comment in heuristic evaluation was that users wanted to be able to open multiple pieces of paper at once, as depicted in Figure 4. In response to this feedback, we decided that if a user clicks a task or bucket from a drop-down menu, it would open a new paper. This makes the action more obvious, and lets users view multiple tasks at once, if desired. Its also easy to close these papers, with the little 'x' in the corner.
Figure 5 shows a close-up of the left-side of a Bucket Paper, displaying the list of tasks in the bucket. It is extremely easy to add a task, simply by typing the name of the task and hitting enter. In early designs we considered having a form to fill out, but decided against it for the sake of simplicity. Users also have the option of assigning a due-date, or they can leave the due-date blank for ongoing tasks. Based on the Heuristic evaluation and another round of user testing, we also changed the layout and information presented on the paper. Specifically, we added the edit and calendar icons. The edit icon (instead of having the task name always be editable), added the affordance of being editable and ensured users are aware that they can edit tasks. The calendar icon removed clutter on the paper, and allows users to easily select due-dates and view what day tasks are due.
Collaborators 
Figure 7: Add Collaborators
After noticing that some users were confused about the difference between Bucket Papers and Task Papers, we attempted to make this more clear. We put an image of a bucket on each Bucket paper, and a check-box on Task papers. We added a link back to the Bucket paper from each Task paper, making it easier for a user to both remember what Bucket the task is in, and get back to that Bucket. These changes were all based on the heuristic evaluations.
Figure 5: Zoom-in List of Tasks on a 'Bucket Paper'
Figure 5 shows a close-up of the left-side of a Bucket Paper, displaying the list of tasks in the bucket. It is extremely easy to add a task, simply by typing the name of the task and hitting enter. In early designs we considered having a form to fill out, but decided against it for the sake of simplicity. Users also have the option of assigning a due-date, or they can leave the due-date blank for ongoing tasks. Based on another round of user testing, we also changed the layout and information presented on the paper. Specifically, we added the edit and calendar icons. The edit icon (instead of having the task name always be editable), added the affordance of being editable and ensured users are aware that they can edit tasks. The calendar icon removes clutter on the paper, and allows users to easily select due-dates and view what day tasks are due.
Collaborators
Figure 7: Add Collaborators
Adding collaborators to Buckets or assigning tasks to users is also very easy. During evaluation, users commented that they did not want to be required to remember the user-name of all people they Adding collaborators to Buckets or assigning tasks to users is also very easy. During evaluation, users commented that they did not want to be required to remember the user-name of all people they may want to add. To solve this problem, we implemented a drop-down menu of the user's 'friends' (anyone they have ever collaborated with before). They can simply check of users in this list to add them to the Bucket, begin typing to narrow down the list, or type a new name to add a collaborator they've never worked with before. Assigning tasks to users is similar, but the list is populated with collaborators on the Bucket instead of all the user's 'friends'.
Help
Figure 8: Help Question-mark Button
We also added a "help" button, based on the heuristic evaluation. This question-mark, seen in Figure 8, is always present in the bottom-left corner of the screen. Clicking it opens a new paper, with information about the main aspects of BucketList (including 'alerts', 'buckets', 'due-dates', etc). These topics were chosen by evaluating the website with users and observing what concepts confused them.
Implementation
...
Post-it Notes
Based on the final round of user testing, we made some modifications to post-it notes. We decided to sign each note with the Bucket or task that they correspond to, in order to help users remember the significance of notes on the board. In addition, double-clicking on a post-it now opens the corresponding task / Bucket paper.
Help
Figure 9: Help Question-mark Button
We also added a "help" button, based on the heuristic evaluation. This question-mark, seen in Figure 9, is always present in the bottom-left corner of the screen. Clicking it opens a new paper, with information about the main aspects of BucketList (including 'alerts', 'buckets', 'due-dates', etc). These topics were chosen by evaluating the website with users and observing what concepts confused them.
Implementation
Our implementation involves separate objects for each entity in our UI: papers, stickies, the board itself, notes, tasks, and buckets. These objects contained contain all necessary identifying information for those entities and allowed allow us to find the item items on the board and manipulate it them according to the user's specifications. We also have user objects, containing all the information relevant to each individual user. These objects are stored in a CouchDB database, and transferred to the client on connection. The client then stores the objects for the remainder of the session to decrease latency, as the user does not have to request information from the server every time a new task or Bucket is opened.
We use node.js to allow clients to connect with the server. We use the Express framework with to organize our code using model-view-controller, and Cradle to connect with our CouchDB database. These frameworks were chosen for the sake of simplicity . and organization of the code. We also decided to use socket.io for server-client connections, even though a persistent connection isn't strictly necessary once the user object is transfered to the client. The reason we made this decision is to allow for more frequent client-server updates, and therefore less of a chance that two users editing at once will result in conflicts. The alternative was simply writing all relevant information to the server when the user logs out or closes the window, but we decided this was overly restrictive to the collaborative multi-user aspect of the application, as users would only see other users' new updates on login.
...
We made sure that each of the users who participated in final user testing use to-do lists on a regular basis and have a need to keep track of group projects, thus they all fit perfectly into our target user population. Since BucketList targets such a wide range of users, we also made sure our test subjects came from varying demographics with respect to age, location, gender, education, and technological expertise, so as not to limit ourselves to other MIT students who think too similarly to us. Many users in our evaluation were MIT student (by far the easiest to find), but we also included professionals and high-school students (found by speaking with friends and family) , who we believe would benefit from BucketList.
...
Once you have an account, you can create "Buckets" - categories to put your tasks in. You can then add tasks to your existing buckets. This application is different than most task-management applications you've probably used in the past, because you can also share buckets with your friends. So, for example, you might create a "Final Group Assignment" bucket, which you will share with the rest of your group. You can then assign each person in the group individual tasks, like "do research" or "outline presentation", and monitor your progress, as a group, towards completing the project. You can also write and share notes about each task, to make sure you're all on the same page, and you can even send alerts to make sure your friends don't miss important notes.
We are going to describe a scenario for you, and ask you to use BucketList to help you accomplish your goals. This shouldn't take more than 10-15 minutes. Do you have any questions before we start?"
Tasks
Please imagine that you are a junior in college, taking 4 classes, and editor of the student newspaper. You already have an account with a 'Newspaper' Bucket, shared with all other students on the newspaper staff.
- You were just assigned a final project in your Computer Systems class. You need to write
- Your teacher reminds you
- blah blah
completing the project. You can also write and share notes about each task, to make sure you're all on the same page, and you can even send alerts to make sure your friends don't miss important notes.
We are going to describe a scenario for you, and ask you to use BucketList to help you accomplish your goals. This shouldn't take more than 10-15 minutes. Do you have any questions before we start?"
We decided not to do a demo as part of the briefing, as we really wanted to see if users would be able to figure out how to accomplish key tasks, so we didn't want to show them first. Our application is simple enough that users can figure it out themselves, without needing to see others use it first.
Tasks
Instead of giving users specific tasks to accomplish, we decided to give them a scenario with less guidance, and observer how they would use BucketList to help organize themselves. This allowed us to see which features are more important, and which features users don't attempt to use - something that would not be obvious if we specifically prompted them to use each feature. We structured the scenario in such a way that it would require the use of the entire system.
The following instructions were given to users:
Please imagine that you are a junior in college, taking 4 classes, and editor of the student newspaper. You already have a BucketList account with some ongoing projects.
- You were just assigned a final project in your Computer Systems class. You need to write a report for next Friday, and give a presentation the following Monday.
- Your teacher reminds you that the presentation cannot be longer than 5 minutes, and must include a visual aid.
- You just submitted the proposal for the group final project in your French Literature class.
- You remember that Tracey needs to return the book your group borrowed to the library.
- You check what articles are scheduled to be written for this Thursday's newspaper publication.
- You decide that there should be a newspaper article about MIT 150 this week, and assign Jason and Matt to write it. It needs to be completed by Wednesday night.
- You realize that Pat went home for the week, and reassign the article his article on
student in 6.813, and your group decided to switch the focus of your project, so you have to redo GR1. You were also just assigned GR2. And in your busy schedule, you somehow also just got a UROP.
...
who keep to-do lists and must manage group projects (exactly our target audience), who we found by asking our friends. We began by asking some questions about how they currently do to manage to-do lists, and got answers ranging from "I write everything on my mirror or on scraps of paper" to "I use MGSD for group task-management, and then I import everything to Google tasks for due-dates and reminders". This ensured that some test subjects were familiar with shared task-management applications, while others just keep their own to-do lists, so that we got a wide range of responses.We decided not to do a demo as part of the briefing, as we really wanted to see if users would be able to figure out how to accomplish key tasks, so we didn't want to show them first.
Reflection
- Discuss what you learned over the course of the iterative design process. If you did it again, what would you do differently? Focus in this part not on the specific design decisions of your project (which you already discussed in the Design section), but instead on the meta-level decisions about your design process: your risk assessments, your decisions about what features to prototype and which prototype techniques to use, and how you evaluated the results of your observations.
...