CSE 134B: Client-Side Web Languages

Fall 2017 | University of California, San Diego CSE Department

Homework #1 - Practicing UCD

A key challenge of designing Web applications is acknowledging the significant power endusers have in dictating the success or failure of our software. Poorly designed web software is simply not protected by some “uninstall barrier” or other mechanisms of app incumbency that may allow us to get away with building user unfriendly software. Given the environment, we must at least have a passing understanding of user centered design (UCD) if we want to excel at client-side web development.

This quarter we will try to solve the problem of keeping track of a soccer team in some basic fashion. The general idea of the soccer tracking software we codenamed "TeamWatch" is to build an app to keep track of a single team including its players, games schedule and a variety of statistics related to the matches played and the activity of the players during said matches. Note: The name given here is just generic, you are free to call the app whatever you deem appropriate.

Your app should be designed to perform minimally the following actions:

  • Have a login/logout mechanism to keep the data of the team private to the players, coaches, parents or other concerned parties
  • Have a roster mechanism to keep track of the players on the team including their name, position, jersey number, photo, date of birth, and a player id number (some unique id). Meta data for the player may also include if the player is a captain, injured, starter or sub, and other things you may consider relevant. Given the variable nature of meta data a generalized mechanism may be warranted.
  • Have a schedule mechanism that lists upcoming and previous matches including date, time, opponent name, location, home or away status.
  • Have a statistics mechanism to summarize both team stats and player stats
    • Team stats would include win, loss, ties, goals for, and goals against
    • Player stats would include foul, red card, yellow card, shot on goal, goal, corner kick taken, goal kick taken, penalty kick taken, throw-in, appearances (aka games played)
    • Game stats would include aggregate fouls, cards, shots on goal, goals, corner kicks, goal kicks, possession time

    Note: Other stats may be possible but these are what should be specified in a base case. You do not have to address the activities of the other team as defined here expected in the sense of possession time requiring you to note when your team has the ball and the other does not. If you are so inclined you may want to track the other teams game stats to relate the advantage or disadvantage the tracked team faced.

  • Have a mechanism to gather the various statistics in real time during game play. Likely this feature would employ some game clock in conjunction with buttons or other mechanisms to collect statistics

Given the nature of the use of the application we might imagine some activities to take place off field and some on field. As such the application should be suitable for both desktop and mobile environments.

Warning: The login/logout mechanism and basic CRUD features of the app are fairly obvious. The game statistics and collection is not straight forward, in fact it is the Professor’s opinion that existing consumer apps poorly address the problem. Given this situation do not assume there is a single answer nor necessarily a clean one for this part of the assignment. This ambiguity is by design. This ambiguity allows you to add features or ideas as you see fit to meet the uses cases and user wants you uncover. The provided points serve as a base case to force some consistent level of feature set across submissions, it is likely however the best solutions are a superset or at least modified set of what is noted in this description.

To design the application we should perform the following actions:

  1. Define in our own words the general purpose of the application. Including our reasons for its use
  2. Define a set of users (coach, parent, player, etc.) that will use the application
  3. Define a set of user stories at least 3-5 for each user for the application. The user stories should be in the standard format (As a <user> ….) Wikipedia Entry
  4. Define wireframes for the screens we think represent our application. Wireframes should be in a low fidelity style. You may optionally have a high fidelity version as well, however you may not use this in place the low fidelity execution.
  5. Summarize any questions, concerns or worries we have about the application if we were to build it

The turn-in form of the design document should be a PDF file, but may also include links to online wireframes as appropriate. A tool like UXPin (uxpin.com) will be useful to produce such artifacts. Important Note: You are not implementing anything at this time. Students who build, code or overly concern themselves with technical execution in their discussion will be penalized up to 50% of the overall assignment grade. This stated penalty serves only as an incentive to help you free your mind to not worry (yet) about coding and focus instead mainly on end users and their possible needs.

Academic Integrity Notes:During the design process you are free to consult the screens and ideas of other applications currently available commercially or open source. Please provide the names of the sites/apps and URLs that you relied upon to help you come up with a solution in your turn-in. Also know that you are free to use the names, visuals, and branding assets of various soccer teams or players as you see fit as long as you include a statement that these assets are the property of the respective owners in your document/wireframes.


Back to CSE134B

Grading

  • 1pt for Problem Statement
  • 9pts for Persona definition and discussion
  • 9pts for User Stories
  • 20pts for Wireframes (Up to 5pts extra for added high fidelity version)
  • 1pt for Open Issues/Concerns Section
  • 10pts Format and clarity of execution

Total: 50pts We will award 10points extra to the three best executions in class. Features or ideas of these solutions may serve as part of our actual class project.

The assignment is due Sunday Oct 15 @ 9PM. Turn-in logistics will provided by the TAs in Slack