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 teh 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 particular 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

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