Team 11

From Cmsc434_s10
Jump to: navigation, search

A web application for UMD students to get sporting event tickets

Project Proposal

Users and tasks

  • Users: Currently enrolled students at the University of Maryland, College Park.
  • Tasks:
  1. Request Tickets
  2. Claim/print tickets
  3. View sporting event schedules
  4. Change passwords
  5. Pay for guest tickets
  6. Sign in to your account
  7. Cancel tickets
  8. View your tickets and ticket history
  9. Links to other UMD fan sites
  10. View season results
  11. Help/FAQ section

Existing solutions and their limitations

  • Right now the way that displays a lot of their information is by linking pdf's for things like the schedule and policies. The website currently uses a table to display the upcoming events that you can requests tickets for, which has a link for the actual request. To sign in you have to click a link at the top of the page that will take you to the sign in page which asks for the bar code on the back of your ID instead. The help is a link to an entirely different site with search and contents.
  • A new application is needed because current one is not user friendly and is unorganized. Most of the information that you are looking for is a link to a pdf which must be downloaded and takes up space and resources on your computer. Some of the links are .doc files which requires to open a word processor. The help for this website is so complicated that it has its own help page and is a different site altogether. The way that you sign in to site is by using the bar code on the back of your university id which is easy to forget because this is the only place that you use this information. These factors combined interfere with the websites flow of information and makes for a very buggy experience.

Meeting notes

  1. Make compatible on all browsers
  2. Customizable for user.
  3. Using space wisely
Information Access
  1. Tabs with drop down menu to display information better.
  2. Category Headlines in side bar
  3. Organize
  4. HTML instead of PDF
  5. Better way of displaying advertisements
  6. Footer for Security Info, and host info
  7. Group related information better
Input Informaiton
  1. UMD account username usable instead of barcode.
  2. Create new username and password once and insert barcode there.
  1. Better use of error notifications.
  2. Use error notifications to gently lead and help users.
Misc. ideas
  1. Make "Upcoming Events" more interactive - Have a calendar
  2. Use more explanatory vocabulary (Phase, Request, Ondemand)
  3. Show remaining tickets and availiblity.
  4. Have "street view" for statdium parking
  5. Not have user-options visible for guests who aren't signed in
  6. Alerts - Schedule, Delay, etc.....

User and Task Analysis

Part 1 - Data Gathering Techniques

There are many ways to gather information and data for user and task analysis. The three we feel work well are:

  • Survey/Questionnaire
  • Research
  • Direct Observation
  1. With the survey it would be best to get User's ideas on how good the site is, and how they would like it to be better. A good start with asking them to identify specific tasks which the development team feel should be added. It is also a good idea to get information about the number of games they attend, which alludes to how much they use the site. This can help us establish credibility and be more confident in our data.
  2. Research is fairly easy. There are a few sites out in the internet which provide similar services, if not the same services as the website you are trying to create. Go and look at a couple of them, find out how they are rated by other users, look at the site's pros and cons, and gather all the data. Try to fix the other sites' mistakes without making your own.
  3. Interviews are best done with people whom you trust to give you detailed responses. Admins are best for this, because they could give you a detailed tour of the site, and provide you with what is hard for them. (they have to do this everyday…) Admins can easily identify their tasks, and point out both the current design's pros and cons.

Part 2 - Survey Results

We chose to do a survey because we felt as thought it would be the quickest and most efficient way to gather our data. We used an online and a paper survey.

Our survey: Team 11 Survey

  • People Surveyed: 174
  • All Fans Average Rating of the Site: 2.70/5
  • Normal Fan Rating: 2.59/5
  • Super Fan Rating: 3.42/5
  • Other data is reflected in user classes we created
  • Participant's Comments

Part 3 - Classes

Class 1 Super-Fans
Age: 18-25
Education: Some College
Job: Student
Computer Skill: Avg 4.26/5
Computer Experience: Above Avg.
Location: On-Campus/Commuters
Motivation: To get tickets to attend games with least amount of stress
Attitude: 3.42/5 Used to the site but not thrilled about it.
Social context: Sporting events
Usage Pattern: During football and basketball seasons

Class 2 - Avg. Fans
Age: 18-25
Education: Some College
Job: Student
Computer Skill: Avg 4.17/5
Computer Experience: Above Avg.
Location: On-Campus/Commuters
Motivation: To get tickets to attend games with least amount of stress
Attitude: 2.59/5 Dislikes the site
Social context: Sporting events
Usage Pattern: During football and basketball seasons

Computer Skill:
Computer Experience:
Location: On Campus
Motivation: Get students tickets to the game with as few errors as possible
Social context: Sporting events
Usage Pattern: All year round

Part 4 - Persona's

  1. Batman is a 19 year old sophomore. He has been to every football and basketball game since his freshman year. He is an avid face painter at the games. He is already has his tickets but he wants to see when he can enter the game without looking at the ticket.
  2. Catwoman is a 21 year old junior. She has been to a few games here and there and she wants to go to the duke game. She wants know how long until the request period starts.
  3. Robin is a OIT employee and wants to upload the new football schedule for next season.

Part 5 - Other Stakeholders

  1. Sports Teams
  2. Employees of stadiums
  3. University of Maryland
  4. Parking Attendants

Part 6 - Tasks

List all the tasks you’ve identified. Name each task, describe its goal, preconditions, and subtasks. Also indicate its complexity (e.g., low, medium, high), frequency (e.g., only once, a few times, often, every time), and potential user errors (e.g., user entered a wrong password) if any.

Frequency Data Gained through survey data.
Low: Below 50
Medium: 50-80
High: 80 and above

Task 1
Goal: View Schedule

  1. Follow link to view schedule

Complexity: Low
Frequency: Average
Task 2
Goal: View Policy
Preconditions: N/A

  1. Click on View Policy

Complexity: low
Frequency: Low
Task 3
Goal: View Attendance History
Preconditions: Must have attended games to view stats

  1. Log In
  2. Click on View Attendance History

Complexity: low
Frequency: Medium

Task 4
Goal: View Your Tickets
Preconditions: Must have baught at least one ticket

  1. Log In
  2. Follow link to view.

Complexity: Low
Frequency: High

Task 5
Goal: View Your Information
Preconditions: N/A

  1. Log in
  2. Follow link to view info

Frequency: Low

Task 6
Goal: View Fan Guide Preconditions: N/A

  1. Follow link to view fan guide

Frequency: Low

Task 7
Goal: View Stadium (Seating & Gates) Preconditions: Know which statdium you want to look at.

  1. Follow link to stadiums
  2. Select Stadium you would like

Complexity: Low
Frequency: Low

Task 8
Goal: Cancel Tickets
Preconditions: Must have obtained ticket.

  1. Log in
  2. View Tickets
  3. Cancel tickets

Complexity: Low
Frequency: Medium

Task 9
Goal: Contact Office
Preconditions: Must have a reason to contact office Subtasks:

  1. Click on contact office
  2. Fill out form
  3. Click submit

Complexity: Medium
Task 10
Goal: Terrapin Club Information
Preconditions: N/A

  1. Click on link

Complexity: easy
Frequency: Low

Task 11
Goal: Requesting Tickets

  1. Log In
  2. View Schedule
  3. Choose date/event
  4. Request ticket if availible

Complexity: Medium
Frequency: High

Design Sketches

Part 1 - Creating Scenarios

  1. Ran heard that Terps are going to play with Duke, a rival of Terps and if we win this game, we may have a great chance to be 1st in the ACC, next wednesday, so she goes to to require a ticket. She knows how to get tickets because she used this system before. She clicks at the link on the left of the web page: require/claim the ticket. After that, a login page is shown and sherealizes that she needs to log in first. Suddenly she saw the user name is bar code on the back of her student ID card. Then, getting frustrated, she stands up and find her bag. She can't find the ID there. So she searches the table, still she can't find it. Finally, after a 10-minute search, the ID card is found in the pocket of her coat. She sits down behind the screen again, and get ready to enter the bar code. However, she forgets how many digits of the bar code shouldher enter. She has to click the "here to sign in the first time" link below the login box to see which part should be entered as the user name. Finally, she gets in the system and saw a table of schedule of the games. She goes to the second table which show the men's basketball schedule and finds the Duke game. After clicked the game, a form is shown. She fills out all the information needed to reserve the ticket.
  2. Scooby Doo hasn't been to a UMD Mens basketball game in a while (somewhat motivated) so he wants to compare the home games to his schedule so he can go (Needs). Mr. Doo goes online (context) to look at the Men's Basketball schedule (Task 1). This isn't his first time looking at the schedule (Frequency: many times throughout college career) so he knows where the link for the schedule is. He clicks the link (pre condition to Task 1) and is taken to a calendar that shows the current month and has today's date highlighted. Because he is not free for the remainder of this month he clicks the arrow (precondition to Task 2) to view the next month (Task 2). Every day that has a game is highlighted. Scooby then hovers over the day he thinks he is free (Precondition for task 3) so he can see the extra information about the the game, like start time (Task 3).
  3. Two days later, Scooby realizes he is going to be busy that day, and realizes he needs to remove his request, or delete the ticket he has already gained. He goes online (context) and to he logs in and is automatically taken to his "Home Landing" page which shows alerts and such... He sees the requests he has inserted, and the actions next to them. He deletes the request, and clicks yes that he is sure. Scooby does theinital step of finding and requesting tickets again to request a new ticket

Part 2 - Creating preliminary design sketches


Part 3 - Creating storyboards

Conceptual storyboard

UI storyboard


Paper Prototype

  • Risk assessment.
  1. Personalizing Home Screen with widgets. (Task 1 will test this)
  2. Being able to view schedule easily and add games. (Task 2 will test this)
  3. Being able to easily cancel tickets and keep track of the current reserved tickets. (Task 2 and 3 will test this)
  • Prototype photos. Digital photos of the pieces of your prototype. Show the prototype in interesting states; don't just show a blank window. A digital camera will be available during Testing Day for you to take photos of your prototype, if you need it. (Although you will iterate your paper prototype during this assignment, the photos only need to show one iteration.)
  • Briefing.

Here is the briefing we generall used: "We have recreated which if you don't know is an application used to request and claim tickets for the various UMD Terps teams. You can use your UID and password to log in!"

  • Scenario Tasks.
  1. Log in and personalize your Home Page by adding a Men's Basketball schedule widget.
  2. Claim a ticket for the Duke Game.
  3. Cancel the Duke game ticket.
  • Observations on the testing day.

After testing and carefully observing our users we got 3 main concerns:

  1. Minimizing and expanding widgets, how to keep track of which widgets user minimized. Our current implementation is a bit confusing for some users.
  2. Info section: 'Info' is a bit too general, "What is that mean, what is included in that category?"
  3. Adding Widgets to keep track of certain teams; "that way I know if my team is doing well and their stats."
  4. Charlene Wu, a junior in college, was one of our testers. The concern she had was that the "info" tab was a bit too broad and that she would like to know what comes under it before actually accessing the page.

Computer Prototype

Outline Screenshots



System requirements: This application is been tested on:

  1. Windows XP, Linux, and Mac OS
  2. Safari andMozilla Firefox Browsers
  3. The latest version of Adobe Flash

Starting Up Instructions:

To start using TerpTickets, the only thing you need is to remember your University ID (UID). First, you need to log in. (For the testing phase, the UID is set to "terps" and the password is "tickets". Then you will log in to the system. View game schedule: you can view the game schedule of the whole season by click the "Schedule" tag. Also, you may add certain schedule widget by simply click on the "Add Widget" button and choose for the game widget you'd like to add. To find details of a game: you can click on any game on the schedule table and then you will see the detail information. For other information and help: you can find them in "Information" tag.

Fidelity: For our computer prototype we have implemented the log in page where users can sign in with our given username and password. For the homepage, we have implemented the default homepage and "add widget" button so that you can add more widgets to the homepage. We have not implemented widget minimization and reorganisation, and the hovering feature for game dates. We have not yet implemented the "request and claim ticket" task. For our Schedule tab we have done a shallow implementation of the month bar, and we do not have all the schedules up for the Men's and Women's basketball teams. In the Information tab we currently have the links for Byrd stadium and Comcast center images working. We have not yet accounted for the user logging out and then back into the account, so the page that that user was on last will be the page that comes up first when re-logging in. This will be eventually fixed though.


Experimental Design

TerpTickets vs.

  1. State a lucid and testable hypothesis
  2. Identify independent and dependent variables
    1. Independent:
    2. Dependent:
    3. Controls: (list three variables you may want to control)
  3. Design the experimental protocol
  4. Choose the user populations


  1. It is easier for users to log in to the TerpTickets website rather that
  2. Identify independent and dependent variables
    • Independent:
      • User's satisfaction while logging into TerpTickets and
    • Dependent:
      • Amount of time it takes for a user to log in (when username, password is not saved on computer)
    • Controls:
      • Experience with ticketing website
      • Computer skills
      • Class standing
  3. Task: Tell students to log in to both the website within a certain time frame.
  4. Population: First time users and returning users


  1. TerpTickets is easier to navigate
  2. Independent:
    1. task to complete on sites
    2. computer
  3. Task: give user a task with a time limit. Then see which students are able to complete the task in that time frame. (between subject)
  4. Random University of Maryland Students


  • Claim: TerpTickets is more interactive than
  • Variables
    • Independent Variables: TerpTickets and
    • Dependent: Satisfaction of user
    • Controls: College students, their age, experience with
  • Population: University of Maryland College Students
    • Inclusion criteria: Must be a student
    • Exclusion criteria: None
    • How to sample: Pick people at random, find out type of user class they are a part of, rate their satisfaction
  • Task: give user a task and see if he/she is more satisfied with the experience TerpTickets offers of


  1. It is faster for a UMD student to get a ticket using TerpTickets than
  2. Identify independent and dependent variables
    • Independent:
      • what browser the user uses.
      • what operating system the user uses.
    • Dependent:
      • Familiarity with computers.
    • Controls:
      • Familiarity with existing ticket website.
  3. Design the experimental protocol
    • Ask user to request one ticket of a certain basketball game.
    • Time each of the users to perform the task (request the ticket).
  4. Choose the user populations
    • Who?
      • Current UMD students.
    • How to sample?
      • Classify the students into 3 groups depends on the familiarity with "": familiar, average and haven't use before. Then randomly choose from each group to sample.


Implementation Plan

UI: Must have

  • Aesthetics [Luis][Luis]
  • Adminstrative page to add, delete, and update data base [Luis,Monzer]
  • All Links in info screen created [Asmi]
  • Delete widgets in home screen [Ran]
  • Maintain User state from UI side [Monzer]
  • Redesign of the schedules page without months [Monzer]
  • Aesthetics of Schedules page [Luis]
  • Widget controls for widgets [Ran]

UI: Nice to have

  • Minimize and maximize ability for widgets
  • Log in: different view available if you log in as an administrator.
  • Drag and drop ability for widgets

Server: Must have

  • A way to keep track of user's previous state [Monzer, Luis?]
    • Add User
    • Delete User
    • Add user's requested tickets
    • Add user's claimed tickets
    • Cancel requests

Execution of the Plan

  • Aesthetics [Luis][Luis]
  • Adminstrative page to add, delete, and update data base [Luis, Monzer][Luis]
  • All Links in info screen created [Asmi][Asmi
  • Delete widgets in home screen [Ran][Ran]
  • Maintain User state from UI side [Monzer][Not Implemented]
  • Redesign of the schedules page without months [Monzer][Monzer]
  • Aesthetics of Schedules page[][Luis]
  • Widget controls for widgets [Ran][Ran]
  • Minimize and maximize ability for widgets[][Not Implemented]
  • Log in: different view available if you log in as an administrator.[Luis][Luis]
  • Drag and drop ability for widgets[][Not Implemented]
  • A way to keep track of user's previous state [Monzer, Luis?][Not Implemented]
    • Add User[Not Implemented]
    • Delete User[Not Implemented]
    • Add user's requested tickets[][Monzer]
    • Add user's claimed tickets[][Monzer & Ran]
    • Cancel requests[][Not Implemented]
    • Cancel claimed tickets[][Not Implemented]


User Testing and Analysis