GR6 - User Testing

Josh Duncavage, Tyler Singer-Clark, Stephen Zhang, Raven Clayborn

Design

The design of the final product was focused heavily around developing an intuitive UI. Many of the problems that plagued the UI was a lack of error messages as well as functionality that would be intuitively there but did not function properly. An example of this would be clicking on the names of athletes or of the "Select All Members" button but it would not actually act; it would only do something if the actual checkbox was clicked. This was fixed.

We redesigned the homepage of the website. Originally the calendar populated the front page, but it was too cumbersome to click to the home page every time the user wanted to change date he was working on, so we changed the calendar to be a popup from a header bar at the top.

We wanted our app to be easily broken down into 5 major sections: Home, Members and Groups, Workouts, Timing, and Results. These appear as large buttons along the bottom of the screen, because if the user (coach) is used to holding clipboards, he'll be holding the top of his iPad, and we didn't want accidental clicking of the large buttons.

Our pages utilize accordions to collapse and expand data on members, groups, and workouts. This is because a group can be large and potentially push data off the screen. This is primarily the make up of the workout and members pages. This is the result of users wanting to be able to collapse groups that they don't need at the moment.

Our timer page was probably the most interesting in terms of design. The idea was created off of a stopwatch, but the start and stop button being the same button really threw off our users. In addition, our method of timing was slightly different from the traditional clipboard method. Here, we have buttons for each player and tapping the button will take a time down for that user. This allows coaches to quickly take down times as opposed to writing down times on a clipboard quickly. This approach worked better on the computer and was still highly intuitive.

The results page is also relatively straightforward but the place where we would probably spend the most time improving. This is the place where we had the least amount of polish due to the time constraints and technical issues we ran into implementing this page (more on this in the next section). Primarily we focused around making it easy to select users, from multiple screens to a single simplified page. We removed the functionality of choosing groups and opted instead for giving the ability to batch select athletes. This way you receive the ability to view groups but without the extra complexity.

Implementation

In terms of Implementation, a large portion of our work was done using Jquery and Jquery-UI Widgets. This is due to the simplicity of our actual idea, and most of it could be captured with Jquery-UI's Datepicker. One limitation of it however was the ability to gather ranges of dates. In order to get around this, we had to convert the dates into Unix Timestamps, and increment the start Date by the milliseconds in a day and then parse it with Datepicker to revert it back to a calendar date. We do this for the results page to properly grab all workouts in between two dates. This was particularly difficult and ended up taking up a large amount of time to figure out and fix during GR5.

We used jquery-UI's accordion widgets on groups. One issue we encountered here is that all new groups that were made would not be accordions, and we could not dynamically convert only the new accordions to accordions. As such, our solution to the problem was to destroy all existing accordion widgets and then remake the accordion widgets for all groups. While this works for small sized groups (our expected value), when scaled up to group sizes much larger, there will be a noticeable delay between the destroy and recreate, possibly causing a jarring effect. However this is not exhibited in our work as far as we could tell through testing.

Another implementation choice we decided on was LocalStorage as our backend option due to the ease of use and the lack of necessity of setting up a backend. This led to a couple of issues because LocalStorage only stores strings and not ints or objects, whereas most of our data was stored as objects. We utilize various JSON parsing and JSON strings to store large objects as strings and then parse these strings for objects at the beginning of load for each page. This way we can keep the data consistent. However this led to a lot of issues early on.

Evaluation

Testing Scenario:

We tested three potential users for our application.  Test users were given a laptop with our application scaled to the correct size on the screen.   (None of our group members own a tablet).  As for our introduction to the application, users were given a modified version of the test scenario for our paper prototype.   Each user was simply given brief descriptions of each of the pages in our application, but was not shown any functionality such as adding members or creating or timing workouts.  Our data base was not populated and we required each user to create groups, members, and workouts.

Selection of users was based on our ability to find a diverse group of willing users.  Our test users included one track coach and two swimming coaches.  Two tests were done in person and one test was done electronically.  While we were initially concerned with the possibility of doing a test electronically in terms of consistency of testing, we concluded that we could normalize the testing process by giving each in-person tester a document describing each page rather than actually voicing our descriptions.  Furthermore, we thought that the electronic test was actually the most realistic, since that scenario is what typically happens when one buys an application; all they are given is the program and a quick read-me.

Our reasoning for not giving a demo was our attempt to be as realistic as possible.  We simply wanted to provide our users with a level of introduction to the program that would be on par with a one or two page read-me.  We felt that any sort of demonstration would take away from the realism and would prevent us from getting any useful real-world feedback.

General Feedback:

Overall feedback from each user was positive.  Test users were excited with the concept of moving all their athletes’ performance data into a computerized form.  They were pleased with timer page and quick overview provided on the charts page.  For the most part, concerns with the application were cosmetic, centering primarily on issues such as text visibility, labeling, and application navigation. One issue seemed to be somewhat structural rather than specifically application related; some users were not as technologically savvy and did not have the same intuitive responses that our peers at MIT had during the prototype phase.   Providing more hints or possibly including more of a tech demo for these users would prove invaluable.  After we conducted the test and gathered results, we showed them a more in depth demo and we noticed that they were much more comfortable with the application afterwards.  This would suggest that our interface does not have a steep learning curve, and even non-tech savvy users would be able to integrate our system into their programs once they were given a tech demo.

Learnability and Usability issues:

Homepage:

• Minor- Not sure what the home page should have but it seems somewhat odd the way it is now.
  • Made by two of our testers.  We had struggled with coming up for useful material to post on our homepage that wouldn’t clutter it up.  Perhaps more of a broad overview with quick links would be beneficial.
• Positive- I like the look of the buttons and the accordion style.
  • Yay!
• Major -It is not clear that you have to pick the top button to review results from other days or change the active day
  • This is where a demo would have come in handy.
  • Tooltips would be an option but we have to account for a tablet interface.  Changing the description on the top toolbar or providing prompts on other pages could ease the confusion.

Members Page and Workouts Page

• Cosmetic - The color scheme is darker than I would like or expect but maybe that was the look you were going for.
  • Could explore changing the background to a lighter color to increase contrast, or change the color of the text.
• Minor - It would be good if you could actually type in the workouts that you are doing.  Maybe just a comment section so you actually know what you are tracking, especially in the few results it really should just be tables if possible,
  • Comments would be easy to implement as as text field.  We could implement this in the results page as well to show notes when you click on a data point.  (Coaches seem to like to jot down notes during workouts)
• Moderate - Right now you can only compare progress in one length over time rather than just viewing results of all the workouts together.
  • Providing more filtering options on the chart page would allow for more functionality.  This however would require more work on the backend and could be somewhat difficult to implement.
• Moderate - Would it be possible to create a workout say named "8x400" be timed multiple times or does it only stay true for that day, this could be another way around the different lengths just have it be that one workout that would record results over multiple days of timing it and then this would be graphed?
  • Somewhat similar concerns voiced by other test users;  they wanted sort of a template workout that could be repeated multiple times but still be condensed as one workout.
• Minor - It would be nice to be able to save workouts that we create all the time.  For example if I always have my athletes do the same workout every Monday and Tuesday, it would be nice to be able to quickly add that workout to multiple days.
  • Very useful comment.  Would require some back-end but we could allow users to save workouts as a template, or alternatively add the ability to add the workout onto multiple days.
• Positive - Making new groups and members and workouts is really simple

Timer Page

• Minor- Reset Button button is slightly intimidating, it makes it seem like you are resetting everything.
  • Possibly changing it to just say “stop” would be more fitting.

Results Page

• Moderate -Displaying workout results on the home screen is not intuitive.  Instead, results should be summarized on the timer page or on the results page where you select a date range. Add a section on the pre-chart page which displays results from the current day? 
  • Add a quick list of results on the timer page after completion of a workout.
• Major - Dislike the display of the results page, not robust and not clear as to what I am doing.
  • This is a concern and was voiced by multiple users.  Adding a text dialog section below the title wouldn't take up much space and could help resolve any confusion.
• Minor - I think the results page should look like the home page does now and then have the option to graph SELECTED workouts this enables you to track different length workouts
  • This could be used as a possible solution to the above problem.  Another solution would be to have notes on each calendar day when you select them that shows what workouts were done that day.

Reflection

"Planning ahead is invaluable" - When the first step taken involves writing code, things get messy very quickly. It does not cost much (with regard to time, effort, etc.) to first think about general strategy and structure before even touching or thinking about specifics. This gives the project a much clearer direction, and allows you to focus on the specifics when they do finally become relevant.

"Group members working together in the same place works well" - Even when work is divided such that each group member is modifying different files and performing separate tasks, working in the same room increases efficiency significantly. Instead of getting stuck for long periods of time on trivial errors, chances are someone else in the group has encountered the mistake before and can save you unnecessary stress and wasted time.

"Users may be paranoid, and it is a designer's job to account for that" - When seeing an app for the first time, not all users are comfortable exploring freely. Some users only want to click things or try things if they are positive what will happen, so as designers we need to keep this in mind. There is no room for a lack of clarity. Things that seem obvious may not be apparent to first time users, and if that scares them, that's on us.

"The customer is always right" - Related to the above point, thoughts and ideas of the designer are generally conjectures, but do not mean anything if the user reacts differently than expected. Since the end game is about the user experience, the job of the designer is to listen to users and sincerely consider their feedback. (When this was discussed in lecture, it was pointed out immediately after that we are still the designers and sometimes the users do not realize what they truly want, but this idea should be handled with care.)

"Prototypes are a designer's best friend" - Instead of trying to implement everything immediately, an iterative design process involving multiple partially functional prototypes helps isolate specific issues, and gets many of the big things out of the way by the time you want to focus on details. The benefits of prototyping vastly outweigh the costs (if you are reasonable about how you go about it).

"Vast changes may be the most effective direction" - Getting too attached to an idea can bog you down. If too many users take issue with something, even if it's a big component of your design, it may be best to scrap it and try something completely different. This is related to users always being right, but just because a design idea is important to you, it isn't necessarily a good idea for you to keep.

"Given time constraints, prioritizing is key" - Certain issues users have are more important than others (hence the 4 categories the staff gave us: cosmetic, minor, major, catastrophic). When there are time constraints, dealing with every single issue can be difficult, if not intractable. When this is the case, identifying the most important issues to fix is a necessary process. There are millions of details that could be modified countless different ways, and being able to handle this situation in an organized and reasonable manner is key.