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