You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

Design

Describe the final design of your interface. Illustrate with screenshots. Point out important design decisions and discuss the design alternatives that you considered. Particularly, discuss design decisions that were motivated by the three evaluations you did (paper prototyping, heuristic evaluation, and user testing).

Implementation

Reflection

Discuss what you learned over the course of the iterative design process. If you did it again, what would you do differently? Focus in this part not on the specific design decisions of your project (which you already discussed in the Design section), but instead on the meta-level decisions about your design process: your risk assessments, your decisions about what features to prototype and which prototype techniques to use, and how you evaluated the results of your observations.

Implementation

As a web application, our project was implemented with HTML, CSS, Javascript and JQuery (and JQuery UI) on the front end.  For the back end, we used the Python framework, Flask.  While all the pages are written with HTML and formatted with CSS, most of it is generated on the server side with Flask and Jinja2 templating.  Through the use of Flask and Jinja templating, we were easily able to make each page within our site inherit a set of properties, notably the header bar that included the BrackeTracker logo and icons.  Similarly, all the tournament (active, create, and join) pages were generated on the server side with the relevant tournament information.  Any of the changes on the page that were made after being loaded were dynamically updated with Javascript and Jquery, while simultaneously sending the updated information to the server in order to persist the data.  We persisted the data on the server, with the Python Shelve module instead of implementing a full database.  For the small scale of the project, Python Shelve worked better than a database would have.  With only a single user, the amount of stored data would be minimal.  Python Shelve allowed us to store Python objects in a mock database.  These Python objects stored the states of each Tournaments (information such as name, description, members, etc) and the Notifications on the home page.  

One of the design choices we made during the implementation was to only implement one type of interactive.  We decided that this would be sufficient because the different tournaments are similar enough in concept that fully implementing the interface for a single tournament type would illustrate how to interact with the other tournaments types as well.  While this design does not allow the user to explore every possible scenario that a fully implemented site would offer, it does allow the user to experience one course of action (for that given task) fully.  

Another design choice was that we did not implement user accounts.  While this does limit the amount of social interaction user would have on this site, it does not prevent the user's experience for the main tasks.  While many of the possible tasks in the site are social, these are not the primary focus of the site's interface.  Our implementation has a single user, and supplies enough scenarios to give that single user the experience of the three defined user types (i.e., tournament administrator, player, and administrator+player). 

Describe the internals of your implementation, but keep the discussion on a high level. Discuss important design decisions you made in the implementation. Also discuss how implementation problems may have affected the usability of your interface.

Evaluation

Describe how you conducted your user test. Describe how you found your users and how representative they are of your target user population (but don't identify your users by name). Describe how the users were briefed and what tasks they performed; if you did a demo for them as part of your briefing, justify that decision. List the usability problems you found, and discuss how you might solve them.

User Testing Description:

Users were 

-how conducted/found 

Briefing

Competing against friends is fun, but putting together a formal tournament is often a tedious task. Organization through methods such as email and Google Docs, or even paper and pencil are time-intensive and have low degrees of automation. BrackeTracker is a site that aims to fix this issue by streamlining the creation, upkeep, and management of these competitions. On our site, you will be able to create tournaments, invite your friends to them, visualize the progress of tournament members, and keep track of match outcomes, head-to-head records, and more. Through use of our site, we hope to help take the hassle out of tournament organization so you can spend more time playing and less time worrying! 

Scenario Tasks

Create a Tournament 

Search for/Join a Tournament 

Update a Tournament 

Manage a Tournament 

View a Tournament 

Create a round robin tournament with your friends Moe and Curly 

Join the "Office Ping Pong" Tournament 

You have completed your match against Moe. Update the score in the tournament 

Make Curly an Admin for the tournament and then boot Dave from the tournament 

Check the status of the "Office Ping Pong" tournament 

First Iter

Observations on First Iteration

User

Create a Tournament

Search for/Join a Tournament

Update a Tournament

Manage a Tournament

View a Tournament

Overall Comments

User 1

  • Assumed that if the join period was left blank that it would close immediately and only 
    invited people would be a part of the tournament.
  • Assumed that if the join period was left blank that it would close immediately and only invited people would be a part of the tournament.
  • Wanted some sort of confirmation that they had completed creating a tournament
  • There was no “JOIN“ button on the tournament info. page, which led to confusion about how to join a tournament.
  • Did not think that the separation between your tournaments and global tournaments was necessary for the search results. Suggested just have all results on one page.
  • User was confused about where they should click to update score, on tournament image/where in the round robin image vs. on the expanding sidebar.
  • Tried to click on the names visible in the tournament image.
  • Felt that it seemed odd to have both a score and winner/loser option.
  • User was confused about where they needed to go to manage tournament details (i.e. boot a player, make a player an admin)
  • Was not sure if the player names were clickable.
  • Wanted feedback as to whether or not their action was completed. (i.e. if player was actually booted or made an admin)
  •  No issue here
  • User felt that the bi-panel homepage setup was not needed.  However, also mentioned that this could be due to the tasks given, since most of them did not require interaction with the notifications half of the homepage.

User 2

  • confusion about the significance of the join period.
  • wanted confirmation that the task was done.
  •  confusing regarding the results of the search.  Suggested having both search results from your tournament list and all global results.
  • Order of password popup & tournament info page seemed confusing.  Suggested that we change the order so that you click join on the tournament info page, which then takes you to the password popup.
  • Clicked on the score box on the tournament page.
  • Questioned if both score both and checking off winner/loser was both necessary.
  •  Wanted some sort of feedback as to whether or not Moe was made an admin.
  • Suggested having an icon next to people's names to differentiate b/w player vs. admin
  • Removing player should result in immediate removable of name from the player list.
  •   No issue here
  •  Is there a concept of friend?

User 3

  •  Confusion about the difference b/w email and friends on the invite members popup.
  • Confusion about the necessity of filling out the join period.
  • Wanted feedback to confirm that the tournament was actually created.  Perhaps have a create button.
  •  Confusion regarding the results of the tournament search. Initially thought that the tournament search box was for on your own tournaments.  Also, did not click on the see all results.
  • Tried clicking on the tournament icon located on the header bar.
  • Suggested potentially having tabs on the search results to differentiate b/w local and global search results.
  •  Confusion regarding how to dispute a score/ who is in charge of updating scores if incorrect.  Suggested possibly having both approve and reject buttons for the score update popup.
  •  Wondered why the list of players/tournament info sliding sidebar was not visible by default.
  • Suggested different ways to draw attention to the side bar including: (1) animating sliding out/in (2) having a boucing/glow effect when initally loads (3) checking the browser width & determining if there is enough screen real estate to show both the tournament info and the tournament visual.
  •   No issue here
  •  Don't have affordances that do nothing.
  • What do all the icons in the header bar do? i.e. Is the logout button going to turn off my computer?

Prototype Iteration

Task analysis

There are a few main tasks involved with the Bracketracker.  These tasks include:

  • Create a tournament
  • Update a tournament
  • View a tournament
  • Search for and Join a tournament
  • Manage a tournament

 

Create a Tournament

Search for/Join a Tournament 

Update a Tournament

Manage a Tournament

View a Tournament

Goal  
& Subtasks

To create a new tournament among friends & create a new bracket.  

To join an existing tournament.

To update the score after a match.   

  • Send score confirmation request to opponent
  • Confirm score request

To ensure the tournament continues in a timely manner.   

  • Boot inactive players
  • Correct scores
  • Change tournament details

To assess the state of the tournament.

  • View leaderboard
  • View scoreboard
  • View current bracket
  • View notifications

Preconditions

Type of tournament  

Tournament name; If tournament in "joining" stage

Tournament name; Player in tournament, which game/match; Score

Desire change; Manager in tournament

Tournament name; Player in tournament

Location

On website

On website

On website  

On website  

On website  

Frequency of Use

Once per tournament

Once per tournament

Multiple times per day

As many as needed; many times a day

As many as needed; many times a day  

How Learned

By doing or watching

By doing or watching

By doing or watching

By doing or watching  

By doing or watching  

Possible Errors

Non-Unique tournament name

Wrong tournament name; Missed "joining" period

Updating wrong game or score

Updating wrong feature or game

Viewing wrong tournament

Time Constraints

None

Within "joining" period

Within scope of tournament

Within the scope of tournament

None

Who Else Involved

None

None

Opponent

None

None

Reflection

Discuss what you learned over the course of the iterative design process. If you did it again, what would you do differently? Focus in this part not on the specific design decisions of your project (which you already discussed in the Design section), but instead on the meta-level decisions about your design process: your risk assessments, your decisions about what features to prototype and which prototype techniques to use, and how you evaluated the results of your observations.

User analysis

Listed below are three different types of people who might use BrackeTracker.  We interviewed three people, each representing one of our three different personas:

  • The Manager
    • The manager has coordinated a variety of tournaments, both small scale and medium scale tournaments (~10 participants and ~35 participants respectively).  He is most experienced in running small tournaments, being the go-to guy with his friends for setting up brackets for tournaments that take only a few hours to complete.  He has run a handful of medium sized tournaments for larger groups, but is by no means an expert.  In the medium sized tournament, the hardest aspect of managing and running the tournament was figuring out the tournament structure and generating the matches.  With that many teams, there were many different possible tournament styles: single elimination, double elimination, round-robin, etc.  Because of the unusual conditions of the tournament, three-player matches (1v1v1) instead of two-player matches (1v1), he decided that the simplest, yet still fair, tournament structure was a round-robin tournament with one player having a bye to the second round.  At each stage of the tournament he had to manually generate the next set of round robin matches.  The small scale tournament was a simpler, single-elimination bracket.  This smaller tournament was much more well defined and as a result much easier to maintain.  Using a simple whiteboard, players would write down the winner of each match after it was played.  
    • Lessons Learned: 
      • Generation of a bracket is often difficult without prior knowledge
      • Tedious to have to generate all next set of rounds for large numbers of participants (especially in round robin tournaments)
      • Updating winners/scores easy under certain conditions (small scale tournament with few participants and on a small time scale)
      • Running a longer tournament single-handed takes a lot of time
      • Different set of difficulties in running small and large tournaments.
  • The Player
    • The player is always up for a tournament among friends.  Whether it is ping-pong or pool, the player is ready to show off his skills and hopes to end up the winner.  He travels in different circles, spending his free time between his co-workers, college friends, and dance buddies, which sometimes results in participating in multiple tournaments at once.  He needs to keep track of his scores, report them to his friend in charge, and find out who his next opponent is, but this can get confusing at times.  Being a busy guy in multiple tournaments means having to remember multiple sets of scores and names all while trusting that his friend in charge will spot any score discrepancies and constantly update him on the tournament status.
    • Lessons Learned:
      • Needs a way to keep track of different tournaments
      • Wants to be able to easily view his record
      • Would rather not have to rely on word-of-mouth conversations, emails, and text-messages for updates (which sometimes get lost in his memory/inbox)
  • Manager/Player
    • The Manager/Player (so called because she typically both manages tournaments, as well as playing in them. These are typically smaller, more impromptu tournaments between friends. Usually she turns to Google Docs to keep track of the tournament, and although it works sufficiently well, it require more setup and maintenance than she'd like. For instance, she is now the point person for creating the Google Doc, inviting others to view the tournament, and prodding those falling behind in their scheduled games to get their games finished. Doing this again and again can get tiring, especially since this Manager/Player wants to play her games in a timely manner as well. 
    • Lessons Learned:
      • The Manager/Player would really love to have a largely automated solution that would require little extra effort on her part as the creator of the tournament
      • She's not looking for any amazingly advanced features, but rather a simple yet effective setup that doesn't require everyone to make new accounts and receive invites, and allows everyone to log in quickly.
      • Inviting people to games should be as simple as emailing or sharing a link or code to anyone you'd like to be in the tournament (ie. you don't need to know their Gmail addresses or be friends with them on Facebook)

Our general demographic can be very varied. As such, the following broad user profile characteristics represent our potential Players, Managers, as well as Manager/Players:

  • Age, gender, culture, language:
    • The user base can span any age, gender, or culture. The website is mainly geared towards an English-speaking audience, but is not heavily dependent on large quantities of text, so non-English users will likely still be able to use the site without much hassle.
  • Education (literacy/ numeracy):
    • Does not require any significant advancement in literacy or numeracy.
  • Physical Limitations:
    • There are no special physical prerequisites - as long as the user can use a computer keyboard and mouse effectively, he or she should face no problems.
  • Computer Experience:
    • Must have basic proficiency with computers.
  • Motivation, Attitude:
    • People who are excited and motivated about the tournament at hand, and want the administrative work cut out!
  • Domain experience:
    • No previous tournament management experience needed per se; however, familiarity with basic tournament types (elimination, round robin, etc.) will allow you to set up the tournament faster.
  • Application experience:
    • No previous application experience necessary.
  • Work Environment:
    • This website is appropriate for almost any environment, from the workplace to a casual group of friends, to an extracurricular club, and more...
  • Relationships with others:
    • Since this sets up tournaments between friends, members need to be in email contact. However, other than a one-time email inviting people to the tournament, there are no other essential emails that need to be sent. Therefore, a tournament can be executed between people who are never in the same room (eg. if you were putting together an online chess tournament).

Task analysis

There are a few main tasks involved with the Bracketracker.  These tasks include:

  • Create a tournament
  • Update a tournament
  • View a tournament
  • Search for and Join a tournament
  • Manage a tournament

 

Create a Tournament

Search for/Join a Tournament

Update a Tournament

Manage a Tournament

View a Tournament

Goal 
& Subtasks

To create a new tournament among friends & create a new bracket. 

To join an existing tournament.

To update the score after a match.  

  • Send score confirmation request to opponent
  • Confirm score request

To ensure the tournament continues in a timely manner.  

  • Boot inactive players
  • Correct scores
  • Change tournament details

To assess the state of the tournament.

  • View leaderboard
  • View scoreboard
  • View current bracket
  • View notifications

Preconditions

Type of tournament 

Tournament name; If tournament in "joining" stage

Tournament name; Player in tournament, which game/match; Score

Desire change; Manager in tournament

Tournament name; Player in tournament

Location

On website

On website

On website 

On website 

On website 

Frequency of Use

Once per tournament

Once per tournament

Multiple times per day

As many as needed; many times a day

As many as needed; many times a day 

How Learned

By doing or watching

By doing or watching

By doing or watching

By doing or watching 

By doing or watching 

Possible Errors

Non-Unique tournament name

Wrong tournament name; Missed "joining" period

Updating wrong game or score

Updating wrong feature or game

Viewing wrong tournament

Time Constraints

None

Within "joining" period

Within scope of tournament

Within the scope of tournament

None

Who Else Involved

None

None

Opponent

None

None

lsdfjlajf

  • No labels