Design

BucketList allows users to easily create Buckets, share their Buckets with others, add tasks, write notes, and view and organize all this information at once. The final design is centered around the bulletin board metaphor, giving the UI a clear and unique focus. Our design also prioritizes efficiency and simplicity, as this is what most users requested during initial surveys and user analysis (see GR1 for more detail on user analysis).

In this section we will highlight the different aspects of the interface, and comment on our reasoning for making the choices we did.

Figure 1: Login

The first thing the user sees when opening BucketList is a plain bulletin board with a large piece of paper asking them to log in or create an account. We always planned on having the initial landing page be simple, and there were no problems with it during testing, so this part did not change very much based on user feedback. 


Figure 2: Main Screenshot of BucketList

While using BucketList, the user remains on the main bulletin board screen at all times. We chose this design, instead of having multiple pages to navigate through, as it makes the website more efficient - users can easily and quickly accomplish all key functions from one place. During final user testing, users also commented that this made the application easier to learn, as everything the user needs is always right in front of them.

In our initial paper prototypes, there was a much less of a focus on the bulletin board. In addition, each Bucket had its own board instead of having one main board with all the user's information. A lot of the feedback we got on our paper prototype centered around the bulletin board, and the consensus seemed to be that users liked the bulletin board but didn't like how we were implementing it (see GR3 for more details). We tried two different designs of the bulletin board (splitting the screen with an "all notes" and the bulletin board, and having tabs to go between "all notes" and the board) for the paper prototype, and took all the comments into account when designing the website for GR4. Based on feedback we decided to switch to the 'one main board' approach and we split the screen into 3 sections (side list of buckets, bulletin board on top, and list of notes / tasks on the bottom). After coding this, we did another round of user testing before GR4 was due. Many users commented that they wanted more room for the bulletin board and thought that always displaying the notes / tasks in the bottom and list of buckets on the side was a waste of space. Based on this feedback, we redesigned to look more like the website in Figure 2 above.

            
Figure 3: Drop-down Menu to Sort Tasks

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.

   

Figure 4: Multiple 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. 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.

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 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'.

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. 

     
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 contain all necessary identifying information for those entities and allow us to find the items on the board and manipulate 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 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 dealt with concurrency issues between different papers on the same board by having a "refreshBoard" function that refreshed every paper and note on the board, and the dropdown menus, whenever anything was changed. We also called the "refreshBoard" function after periodically pulling information from the database backend, ensuring that users would have up-to-date information that collaborators add from other computers. This worked well for our testing purposes, since it made sure that there was never inconsistent information about a task or bucket on the screen, but it also had the potential to slow the system down a lot.  If this became a common problem for users, we could add logic to make only papers with information that might change got refreshed and written to the database.

There are a couple of remaining implementation problems which may affect the usability of our interface.  Unfortunately, we never quite got to work on the "Alert" functionality.  Having all of the affordances of an alert system without an actual alert system is obviously a usability drawback of our interface, but it highlights some important not-yet implemented functionality that will improve user experience in the future. In addition, our system does not handle real-time collaboration properly yet - whenever a client makes a change it gets written to the database on the server immediately, however clients only pull changes every couple of minutes. This means that one user may over-write another user's change if they are editing at the same time. This problem never came up during testing, though, since we only tested our system with one user at a time.

Evaluation

User tests on the final BucketList website were conducted with 5 different users, from varying demographics. 

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. 

The following short briefing was given to each test subject before we began the evaluation:

"BucketList is a shared task-management application, allowing users to easily create group to-do lists.

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?"

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.

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. 

  1. 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.
    1. Your teacher reminds you that the presentation cannot be longer than 5 minutes, and must include a visual aid.
  2. You just submitted the proposal for the group final project in your French Literature class.
    1. You remember that Tracey needs to return the book your group borrowed to the library.
    2. You decide Fatima will take over your responsibility to prepare the presentation.
  3. You check what articles are scheduled to be written for this Thursday's newspaper publication.
    1. 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.
  4. You plan what you will do tomorrow, and then go to sleep.

The Good

  • Most of our users loved the look and feel of the website. The metaphor of using a bulletin board with stickies and paper.
  • The idea of task notes and general notes was well received also
  • The addition of due dates and the calendar was intuitive
  • The idea of having collaborators in a bucket was understood by all users

The Bad and Ugly

  • Bucket Metaphor
    • Sevierity - Minor
    • Explanation - Most of the users didn't not know what a bucket was, it had to be explained to them.
    • Possible Solution - We could revert to something more common like categories
  • Long Names
    • Severity - Cosmetic
    • Explanation - Some users seem to use long titles in their tasks and did not like the fact that it showed a scroll widget after 2 lines. They wanted it to be symmetric with the short named tasks
    • Possible Solution - We could truncate to single line and have ... at the end. This decreases visibility, but opening a task will show the full name again
  • Draggables
    • Severity - Major
    • Explanation - Sometimes, some draggable items on the screen do not get released and follow the mouse indefinitely. This annoyed a lot of the users
    • Possible Solution - More work on the JavaScript.
  • Creation of Buckets
    • Severity - Minor
    • Explanation - Because the bucket metaphor failed, most users didn't create buckets for each classes in the task, they just added the tasks in one of the two pre-made buckets.
    • Possible Solution - Demo video or quick interactive instructions after login.
  • Task Collaborators
    • Severity  - Minor
    • Explanation - Assigning tasks to collaborators was misunderstood by people. Most of the users failed to realize that a collaborator in a bucket isn't the same in a task. When asked to assign a person to a task, they would single click the task, then check a collaborator in the bucket view
    • Possible Solution - Explain to them - again, demo video or quick interactive instructions
  • Notes Vs Tasks
    • Severity - Minor
    • Explanation - Even thought users loved the ideas of having notes and tasks, they weren't sure when to uses a note or make a task, or if other people would see the notes
    • Possible Solution - Explanation, demo video, or quick interactive instructions.
  • Enter to complete
    • Severity - Minor
    • Explanation - A few users weren't sure how to commit their typed tasks, this is done by pressing enter. They were searching for a done or OK button. But after a while, it was learned. One user asked how to enter a task in.
    • Possible Solution - Either put a done button, which could decrease efficiency but increase familiarity. OR explain to users. Adding both is an unnecessary redundancy. 
  • Note Edit
    • Severity - Cosmetic
    • Explanation - Most users expected that clicking in a note would edit it. They didn't actually notice the pencil edit icon on the bottom right corner.
    • Possible Solution - After explaining the reason for that was because of the dragging feature, they were ok with it.

Quotes

"How do i access my other bucket again"
"What is a bucket?"
"How do i do that?" <- After being asked to complete task 1
"You gotta fix this drag issue"
"Oh wow, looks like a bulletin board, nice"

Reflection

The most important thing we learnt is that user testing is really important!

If we had to do it again, I think a heuristic evaluation of our initial designs would have been useful, to get some very early feedback on our design (GR2) before even doing the paper prototypes. We spoke to some classmates about our design, but a more in-depth review would have pointed out some obvious problems that we could have then avoided in the paper prototypes. Since this would have been relatively low-cost and easy to do, we would definitely incorporate it in the future.

We would also have done more rounds of testing with paper prototypes. We ended up throwing away a lot of code after doing a round of informal user testing on our initial design (before GR4), and a 3rd round of paper prototype testing would have brought up these issues before we began coding, saving us lots of time. At the same time, some issues became much more obvious once we actually wrote some code (for example, the paper prototype was very big, which hid the fact that screen real-estate was actually very limited in our initial design). Thus writing code and testing that was useful, and it was good that we weren't afraid to throw away code and restart during the early stages of coding.

Reviewing the heuristic evaluations and deciding what advice was important and what we should ignore was also important. Some of the advice we got in our heuristic evaluation was very useful, but other advice was misguided (perhaps because the back-end functionality wasn't working yet, so users had difficulty evaluating some parts of the application). If we had blindly followed all the advice we got, I think we would've ended up scrapping a lot of key features that were important to our design but not clear in implementation as of GR4. Having a relatively advanced prototype as of GR4 helped a lot in this respect, though, because testers could get a better sense of our application.

Another aspect of the design process that was very important was the initial project proposal and analysis, background research, etc. Speaking to users and figuring out what they would actually want was really important and helpful in focusing our application and deciding what features were important. This also let us design our initial prototype with these features in mind, and get feedback on what to include and what to scrap. 

Finally, starting early and planning ahead was really important. GR4 and GR5 required *a lot* of work, so starting on them early was extremely helpful.

  • No labels