Front Page

Team Fresh City

About

This is the website for Team Fresh City, part of the HFID class in Fall 2009.

Links

Needs Analysis

Introduction
Information Gathering
Process
User Goals
Lexicon
Concept Model
Personas

Inspirational Designs

Inspirational Designs
SVN
Google Docs
OneNote

Design Development

User Script
Design Process
Usability Report

Design Refinement

Cognitive Walkthrough
Prototype
Design Refinement Presentation
Design Refinement

Usability Testing

Usability Testing

Final Refinement

Final Prototype Refinement
Generation 2 Prototype
Usability Testing
Final Prototype (Generation 3)
Final Presentation
Final Report

Division of Labor

Division of Labor

Archives

01 Dec - 31 Dec 2009

Search!

Stuff

Powered by Pivot - 1.40.7: 'Dreadwind' 
XML: RSS Feed 
XML: Atom Feed 

« Usability Testing | Home | Final Presentation »

Final Prototype Refinement

15 12 09 - 17:03

Through various value tests, Team Fresh City implemented a number of revisions to our high-fidelity prototype to improve its performance. These are documented in this section.

Second-Generation Tradmin- Responding to the Heuristic Evaluation

Following the development of our first-generation prototype, the team conducted a heuristic evaluation and received a list of feedback from other members of the course unfamiliar with our prototype. In addition, the team struggled with implementing interface redesign into Microsoft Expression Blend, and wanted to implement more functionality into Tradmin. This second generation of the interface refines the prototype in response to issues identified by the team and heuristic evaluators.

 

[Generation 2 Prototype]

General System Changes    

In our Heuristic Evaluation, some problems of severity-3 included the inability to undo in our interface. Because we want our interface to be integrated into the word-processor, the undo functionality should be native to the software program it is added into. For example, in Microsoft Word, anything the user wishes to undo (changing/deleting comments, accidental collaborator removal, etc.) should be the same as undo-ing anything else, either using Ctrl-Z or the undo button.

[Tradmin Undo Feature]

In addition, the team identified some general visibility items to facilitate navigation. We condensed the ribbon to look consistent with the Microsoft ribbon.

[Tradmin appears native to existing word processor]

We also created a little light indicator in the screen to remind the user that the project they are working on is a shared Tradmin project.

 
[Tradmin Light Indicator]

Lastly, the Heuristic Evaluators noticed that we had an “Enable” button and a “Show/Hide button”, which disrupted consistency because it appeared that “Enable” turns on and “Hide” would turn Tradmin off. We have eliminated confusion by only giving the user “Enable” when they start the project and only “Show/Hide” once they have started the project. The green connected light is another way to remind people they are using Tradmin even if they hide the frames.
 

Buddy List

The team’s original buddy list was a series of buttons in the top of the frame. In our paper prototypes, we allowed people to add collaborators by typing a name and an email address. Removal occurred by checking names and clicking to remove them. Our first prototype used a dropdown where we type to remove a collaborator (due to implementation issues). This opens the possibility of error, as our Heuristic Evaluators noted. In the second revision of the high-fidelity prototype, we have implemented the original buddy-list plan. The only hack now is that the user can still remove themselves, which we do not intend to be the case in a real interface. The heuristic evaluators also asked if they could edit their collaborators information.

 
[Generation 2 Add and Remove Collaborators]   

Comments Pane

Between the first high-fidelity and second prototype the comments pane has undergone much revision. Incorporating feedback from the heuristic evaluators and our own original plans we have this new pane. The biggest usability issue from the HE was that it is unclear how to make comments. Because we were struggling to implement good comments, we addressed this need in our third prototype.
We have extended the lines from comments into the text to make it clear what the comment refers to. We are also considering having highlighting in our final prototype:

  
[Comment Highlighting]

The comment pane is no longer colored red. In addition, we have developed buddy list functionality, where the user can choose to look at everyone’s comments or just look at specific ones (here Bob’s comments are shown and then hidden). In addition, people’s responses are color-coded with their buddy list color to enhance visibility of who is making comments and where they are made in the paper.

[Toggable Comments]

The HE noted that the default location for comments is on the right-hand side because users read from left-to-right. However, we chose the left side for the comments because our users had said that they read the comments first, before reading the paper. We imagine flipping the pane would look something like this:

[Flipping the Comments Pane]

However, we want to conduct some usability testing before considering switching the comments pane location.

Discussion Box

We have extended color-coding into the discussion pane in order to help enhance the visibility of who is leaving remarks.

 

[Discussion Pane Uses Color-Coding]

Private Messages Box

In response to the HE, we have included auto-complete into the Private Messages Section to make the program easier to use.

 
[Auto-Complete]

We have also created feedback for the user. When a user composes a message and sends it, a copy appears in the box.

 
[Private message appears in Inbox]

We also have made each message more obviously click-able in the interface. When the user puts the mouse over a private message, the mouse becomes a mouse-over clicker.

 
[Clickable objects]

In our first revision, we responded to the most severe usability issues. In our next refinement we will use our usability testing and increased knowledge of Microsoft Expression Blend to revise the interface.                

Third Generation of Tradmin- Responding to the Usability Testing

Following the development of our second generation test, the team conducted usability testing to assess the value of the features of Tradmin. Our results indicated that many of our features were promising, but we discovered some things we believed were worth changing. We discovered that the private message space was used less frequently than the discussion. While we believe that having e-mail functionality within Tradmin is still extremely important, we have decided to give more framework space to discussion.

 

[Final Prototype (Generation 3)]

Comments Pane

We tried to make comment creation more obvious to our users by giving instructions during their first time usage of the pane. We believe that users of Tradmin only need to learn how to create comments a few times to retain that memory. Once our users had seen one comment generated, it was easy for them to continue to do so.

 
  [Increasing commenting generation visibility]

 Also, to make commenting even easier, we’ve made it so that upon generating a comment the cursor is by default in the text field to allow the user to type immediately.

[Comments are ready for typing]

Private Messages

During our usability test, we discovered that users who wished to use Private Messages found it insecure. To increase the feeling of security, we have added a drop-down menu to the “To” section of a Private Message, so that it is harder to choose the wrong individual. This has the added benefit of reducing the user’s cognitive load; they no longer have to glance at the top pane to remember what collaborators are part of the shared project.

[Increasing private message security using drop-down menus]

Buddy List

The usability test revealed that users wanted to be able to exit the add and remove collaborators menu by clickiing off of it, without having to click "Add" or "Remove". We modified the interface so that the user can just click off the menu and it will disappear, giving the focus back to the main project screen.

Future Considerations

In addition, there were a number of things we would like to consider implementing in a new prototype. Because our users tend to read the comments in the paper first, before doing anything else, it would be great to have some sort of scrollable comments feature that moves from one comment to the next.

 
[Scrollable comments]

Also, while Tradmin users typically do not work simultaneously, our usability testers mentioned that they might also like to use the discussion feature as a chat option if others were online. To handle more communication capabilities, we can adapt our buddy list to show what individuals are working on the project when the user is logged in. Shown in the figure below, green would mean available, yellow-idle, and red-busy. A lack of color would mean that the collaborator does not have the Tradmin project open.

 

[Available collaborators indicators]

In addition, some of our users described the need to call their collaborators from time-to-time to discuss particular sections in more detail, that they believe phone facilitates best. Perhaps exploring some of the features that Skype has available (including the tabbing for phone calls vs. having chat screens open) could be included into a future generation of Tradmin. Below is a first-pass idea for call capability.

[Phone calls with Tradmin]

Through our usability testing, we also discovered some users had less of a need for some screens than others. Rather than allowing the user to just “Hide” and “Show” all of Tradmin, we want to include some customization capabilities. The user should be able to hide screens that are not in use:

 
[Hide/Show individual components]

Here the user can click the right arrow to move the screen, and then hit the arrow again to pull it out.

Lastly, users suggested we develop a task list pane that would allow them to keep track of what they need to address in a given paper (or assign people to tasks). Tradmin’s original goal was to centralize communication so that ideas and action items would not get lost in the stream of different methods of discussion. Creating a tasks pane would be the natural extension of our interface. This would require some more thought towards the best way to implement it, so we have tabled this idea for future work.