...
In our initial paper prototypes, there was a much less of a focus on the bulletin board. In addition, each Bucket had a different 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 (see GR3 for details), 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 the screenshot Figure 2 above.
Drop-down Menus
Figure 23: Drop-down Menu to Sort Tasks
Before the heuristic evaluation we only had the 2 right drop-downs in Figure 23, 'My Buckets' and 'My Alerts', to let users sort through their tasks. 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 5: Zoom-in List of Tasks on a 'Bucket Paper'
Another comment in heuristic evaluation was that users wanted to be able to open multiple pieces of paper at once, as depicted in Figure 3. Thus, if a 4. In response to this feedback, we decided that if a user clicks a task or bucket from a drop-down menu in the final implementation, it opens 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 3: Multiple PapersFigure 4: Zoom-in List of Tasks on a 'Bucket Paper'
Based 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.
We also added a "help" button, based on the heuristic evaluation. This question-mark seen in Figure 5 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
Figure 56: Help '?'
Implementation
- Describe the internals of your implementation, but keep the discussion on a high level. Discuss important design decisions you made in the implementation. Also discuss how implementation problems may have affected the usability of your interface.
Our implementation involved involves separate objects for all of the various entities each entity in our UI: papers, stickies, the board itself, notes, tasks, and buckets. These objects contained all necessary identifying information for those entities and allowed us to find the item on the board and manipulate it according to the user's specifications. Originally our implementation limited the number of papers open at a time to one, but after doing user testing on our computer prototype, we learned that users wanted to be able to open multiple papers at once, so we changed our implementation to allow for many papers, each of which is individually closableWe 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.
We use node.js to allow clients to connect with the server. We use the Express framework, with Cradle to connect with our CouchDB database, for simplicity. 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 a user had too many papers open at once. If this became a common problem for users, we could add some 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 interfaceIn addition, we had to make some tradeoffs in the interest of time. 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
- Describe how you conducted your user test.
- Describe how you found your users and how representative they are of your target user population (but don't identify your users by name).
- Describe how the users were briefed
- and what tasks they performed;
- if you did a demo for them as part of your briefing, justify that decision.
- List the usability problems you found, and discuss how you might solve them.
...