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 

« Final Presentation | Home | Prototype 2 »

Final Report

15 12 09 - 17:20 Academic paper collaboration is a large space involving many different researchers, collaborators, and reviewers. The paper-writing process involves many different major steps: choosing topics and collaborators, writing grant proposals, conducting research, writing/editing papers, and submitting the paper to journals for review. Team Fresh City decided to focus on the edits-and-revisions aspect of paper collaboration.

Technical and non-technical professors communicate edits and revisions through a number of different means: e-mail, phone, comments within a paper, MS Word track changes, SVN, etc. These communication methods frequently are unlinked to the physical paper. Keeping track of the ideas and problems that need to be fixed can become disorganized, especially given the busy life of faculty members. Currently, there is no program that centralizes collaborators and their communication about the paper.

Solution Overview

To address the needs of academic professors in the academic paper writing problem space, the tool “Tradmin” was developed.  Tradmin is a word processor add-in meant to be compatible with many common programs like Microsoft Word, Pages, etc.  With Tradmin, a collaborative paper lives in the cloud, on the internet, as opposed to living on individuals’ hard drives.  This way, all collaborators can share and work on the most recent document or version.  Tradmin aims to facilitate collaboration and communication by closing the gap between different communicative tools such as email, phone calls, tracking, wikis, etc.  This tool incorporates a number of features that hope to consolidate the mess of files, conversations, and notes about collaborative papers.  Specifically, Tradmin features a buddy list, comments pain, discussion area, and private messaging client to create a multidimensional workspace. 

Personas & Scenarios

Personas

After completing a number of user interviews, the information was gathered and distilled to create three personas.  The development of personas created a baseline for user understanding and gave the team three characters to judge and implement the designs with.  A detailed description of these user interviews and personas can be seen in the Needs Analysis section of the website, or more specifically the persona entry

Throughout the semester, the original personas maintained their initial identity, however, some of their scenarios were altered as more was learned about the users.  Below is a brief description of the three personas: Frank, Stephen, and Janice. 

Frank

Frank has established his career as an academic and due to his success holds many positions at his university.  However, be he burnt out and tired.  Frank is hesitant to learn new technology and doesn’t have time to write and collaborate on major papers.

Stephen

Stephen has just begun his career as a professor, and to say the least, is excited.  He loves biology and wants to spend a lot of time doing it.  Because of his age he is on the cutting edge of technology.  Stephen has to establish himself and build prestige; there is a lot of pressure to publish produce top notch research.

Janice

Janice loves being a professor, she loves to teach and share her knowledge.  She loves to mentor her graduate students and does everything she can for them.  She is pushed to use new technology in order to keep up with her students.  Janice goes as far to sacrifice her position as first author on a paper for her students.

Scenarios

As mentioned above, over the course of the semester, the personas’ scenarios have altered to further demonstrate needs and values. 

Frank needs a tool in which he does not hold all of the responsibility.  At this point he wants to act as a collaborator, but not hold any more responsibility than that.  A tool for him must be based on familiar applications and programs he is used to using like email and Word track changes, it must have a shallow learning curve.  Usability is most important to Frank.

Stephen needs to manage his collaborators, and ensure that their work will reflect well on him.  His reputation is on the line, and he wants as little clutter and technical glitches to get in his way.  He needs something that is going to help him organize, as well as take control of his papers. Stephen is most concerned with usability and utility in any sort of paper collaboration tool.

Communication and learning are Janice’s top priorities.  She needs a way to capture and neatly display her feedback for her students.  Her tool needs to have a fun aspect to it, as well as offer room for detailed and lengthy feedback.  Janice is looking for good accessibility and utility in her tool.

Conclusion

Overall, the use of personas and scenarios were most valuable during the paper prototyping stage.  This is when values and needs were being revisited.  It was found that needs and values in terms of the personas were often most true to the user group.  Using the scenarios was a great way to evaluate the prototype in light of each persona’s preferences.

Final Interface Design

Functionality

The goal of Tradmin was to offer a number of features that would close the gap between communication during academic paper collaboration and offer a workspace in which collaborators could work and communicate about a paper.  Based on user values and needs, the final generation of Tradmin accomplishes these goals, and has received positive feedback from users.  Tradmin incorporates four main features which together provide a valuable workspace for users. 

Tradmin is a word process add-in which is maintains the functionality of your word processor, for example formatting, referencing, undo, etc.  In addition to these functions, it puts your paper in the cloud, where all collaborators can work on and edit the most recent version.  Once enabled, Tradmin is comprised of four main panels which surround the paper: the buddy list, comments, discussion, and private messages. 

The buddy list is used to manage collaborators.  It located above the paper and allows the administrative user to add and remove any number of collaborators.  The buddy list asks for the collaborators name and email address, and upon any addition assigns each collaborator a color.  This color coding is carried throughout Tradmin for easy visual tracking and recognition. 

The comments feature is the entire left hand column beside the paper.  The comment feature is where paper specific comments can be written.  These comments are tied to an exact part of the paper, be it a word, phrase, sentence or paragraph.  After a comment is created any collaborator can respond to the comment, in a threaded chat like feature, or delete a comment.  Comments are automatically sized and organized beside the paper to keep the space as neat as possible.

The discussion pane is located at the top, and to the right of the paper.  The discussion is used for general or higher level comments or tasks related to the paper as a whole.  These types of items don’t necessarily have an exact location or tie to the paper.  This pane functions as a traditional chat space, where a user simply types their thought and posts it.  The discussion items, much like the comments can be seen by all users. 

The last feature is the private messaging space, located beneath the discussion panel on the right of the paper.  The private message feature functions as a standard email client, but lives inside of Tradmin, instead of on its own.  Private messages is used for private or personal messages intended for one or a few collaborators.  This space is secure, and cannot be seen by the other collaborators.  If need be, these messages can also be copied to external web clients, in the case of an underactive collaborative.

Interaction Flow

To describe the interaction flow of our interface, it is necessary to first describe the environment in which it will be used. Our interface is designed to be an aid to a user writing a paper in a word processor. As this in and of itself is a highly nonlinear process, the difference facets of our interface needed to act independently of each other, while still maintaining cohesion and consistency. So, in order to describe the interaction flow of our interface, we must dig one level deeper, to describe the individual interaction flows of each feature.

Additionally, each interaction has very few steps. This was a conscious decision on our part - because the main goal of our users is to edit and revise their paper, any tasks that are too complicated or take too long are not worth doing. So, each interaction takes only a few clicks.

Comment pane:

  • Adding a comment: Click on the paper, click on the comment bar, type the comment, hit enter
  • Responding to a comment: Click the text entry box underneath the comment you want to respond to, type the response, hit enter
  • Deleting a comment: Click the "X" in the top right of the comment
  • Toggling comment visibility: In the buddy list (top center), click the name of the person whose comments you want to toggle

Discussion pane:

  • Adding a statement: Click in the text entry box, type the statement, hit enter
Private Messages pane:
  • Send new message: Click "New Message" button, click "To:" field, select collaborators to send message to, click confirm, click in text entry box "Type your message here...", type message, click "Send"
  • View message: Click on message in Private Messages pane
  • Reply to message: Click on message in Private Messages pane, click "reply", type message, click send

Buddy List pane:

  • Add Collaborator: Click "Add Collaborator", click to focus and type in Name and Email address, click "Add"
  • Remove Collaborator: Click "Remove Collaborator", select collaborators by clicking, click "remove selected"

A quick glance at these interactions shows that none of them take much more than four steps. The longest interaction - sending a private message - is long because our users commented that they want to feel more secure in what they're doing, to make sure they don't make a mistake. This is why we added the extra layers of interaction - to give the user a chance to catch any mistakes they may be making.

Unimplemented

There were some interaction elements that we did not have time to complete.  First, each pane should be togglable as a whole. Some users may not want to have a private messanging pane on their screen, so we'd like them to have the option of hiding it (or any other element) permanently. Additionally, we'd like to have the option of toggling the entire Tradmin interface on and off. The button for doing this is implemented, but the functionality is not.

As far as undo-ability is concerned, we'd like to fully integrate all the Tradmin elements into the word processor. So, for example, if I create a comment accidentally, I should be able to Ctrl-Z it away. This goes for all aspects of the interface.

Finally, on the list of things that we have not yet implemented, we'd like to allow the user to track versions of their paper. We have not yet fleshed out the precise interface elements to do this, but we imagine there would be some button on the Tradmin ribbon that would allow the user to snapshot their paper and the Tradmin elements, and save that snapshot along side the original in the cloud.

Development Tools

 To develop this project, we used Microsoft Silverlight, "a powerful development platform for creating engaging, interactive user experiences for Web, desktop, and mobile applications when online or offline". We used the markup language xaml with a background of C# to code a Silverlight application on the .NET framework.

This approach has both its advantages and disadvantages. Straight away, one of the disadvantages to it was that no one on the team had ever coded in C# or xaml before, and no one had ever written a Silverlight application. We began the coding process with no knowledge of the tools we were using. We chose these tools because we thought we could stay away from most of the C# by using a program called Microsoft Expression Blend, a GUI for creating Silverlight applications. We were wrong. We had to delve into the C# and the xaml, and many of the GUI features of Expression Blend proved not very helpful (a UI flaw on their part, if you ask us).

So naturally, one of our biggest hurdles was learning C# and xaml, but once we accomplished that, it turns out that we actually chose a prototyping tool that was very well suited to what we were trying to accomplish. The markup language xaml allowed us to focus mainly on the large scale aspects of our interface very easily, like placement and size of objects. The actual functionality was accomplished in C#. C# in the .NET framework, while having a bit of a steep learning curve, provided us with a large number of options for GUI elements (taken straight from Windows) that we took advantage of.

In hindsight, having knowledge of our tools before we started using them would have been nice, but we ended up with a nicer and more complete prototype than we would have been able to otherwise produce.

Design Evolution

We focused on simplifying Tradmin over the course of our design process. We began by sketching multiple screens and menus for Tradmin. We then moved to a complex paper prototype, with dozens of pieces and overlays. We received very critical feedback, so we immediately revised our paper prototype into a second and then a third version. We found that a very streamlined, communications-focused prototype was far more appealing to our users. We turned this third paper prototype into our first digital prototype. The digital prototype covered the basics of Tradmin, but lacked the polished interactions we had planned. Our current, final prototype is as simple as the first, but is more refined, with elements such as auto-completing menus and correct focusing behavior.

Our initial sketches focused on editing and reporting. Our focus was on the middle and late stage process of editing a paper. We envisioned a series of tools which allowed a professor to make comments, sort comments and track changes made to the paper.

We discuss our three paper prototypes in length in our usability report: Usability Report.

To sum our findings, our paper prototypes required significant revision before we were comfortable moving into a high-fidelity prototype. We threw out a large number of unnecessary features, allowing us to emphasize the features that were valuable to our users. During the paper prototyping phase we encountered far more implementation and conceptual problems, instead of usability problems as we originally expected.

We moved forward by creating a fourth, refined paper model for our own use:

We used this model directly to create our high fidelity prototype, which we implemented in Expressions Blend.

As we implemented this design, we stuck very closely to our original plan of interpretation. However, we had to sacrifice certain aspects of functionality to make it work. One of the largest changes was omitting lines from the comment to the paper’s text: this made it difficult for our users to recognize what the comment referred to. However, we made sure to keep the larger framework of our design, giving us a prototype that very heavily resembled our paper version:



Between our first and final high fidelity prototypes, we implemented primarily minor interaction changes and cosmetic changes. Our first prototype was buggy – for example, you could only add four collaborators, who could only sometimes be removed. We made sure to address the major issues that were found by our heuristics testers: which were almost all bugs, such as buttons not responding properly. Many of these problems were relatively minor to fix, such as adding comment lines, but had a large impact on the final usability of our design. We focused on improving consistency in comments, making our color coordination very clear. Notably, we also renamed “inbox” to “private messages,” which was more clear. Version two appeared similar to version one, but was refined and significantly less buggy:



Finally, we addressed several minor cosmetic and interaction concerns to create version 3, our final delivered version. We added, for example, colored lines to indicate who wrote a particular comment. We also found that users rarely used private messages, so the private message widget was reduced in size.



By focusing on larger usability issues early on, we eliminated many substantial problems with our paper prototypes long before we needed to code. This made paper prototyping the most valuable tool in our design process. These early paper prototypes forced us to reevaluate the core goals of our program. Because it was so easy to create a new low-fidelity model, we were able to test three separate paper prototypes, receiving significant and meaningful feedback for each. This was very useful, as we did not need to wrestle with large issues (such as what to include in the program) when we were focused on code. Without these early, rough tests, we would have wasted dozens of hours attempting to rearrange our final design – and it would undoubtedly be significantly less polished. Our users were very happy to provide harsh, critical feedback on our early prototypes, which they may have avoided if we presented something more refined. Yet each new paper prototype gave us new and vital insight into our problem, which ultimately made our final prototype more cohesive and powerful.