Homework 2: Design

You know that problem you defined in Homework 1? It's time to envision a solution to it. Your task for this homework assignment is to design a solution to it that has the following characteristics:

Constraints

• Your design should adequately address your problem. It doesn't have to a perfect solution to a big problem; a meaningful, incremental solution to a small problem is just fine. The focus of this class is on engineering, not design.
• Your design must be interactive. It cannot be static content; it must accept and respond to some form of user input.
• Your design should be something your team can implement in 4 weeks of part-time effort. Your solution should be a minimally viable product Links to an external site., which provides value to your target audience, but doesn't necessarily achieve all possible functionality. That means real functionality and real content (if appropriate), but not all the functionality you can imagine or all of the content you can imagine. Think of YouTube, but just video playing, basic video uploading, like and dislike buttons, and ten of the best cat videos you've ever seen. That's enough to provide the smallest possible value that YouTube can provide (and probably pretty close to what they initially launched).
• You should be able to build your solution using free components and services. Don't spend your own money. You can if you want, but you're not required to, and if you do, be sensitive to your teammates' concerns about this.
• Your solution must be build for the web. At the end of the quarter, you'll deploy your solution, and sharing should only require visiting a single link on a website. No mobile apps allowed, since those aren't possible for every student in the class to download and use (largely because of the complexities of deploying to iOS, but also because this course's prerequisite is web development).
• On the front end, your solution must use HTML, CSS, JavaScript, and React. This is to both build upon the INFO 340 foundation, but also simplify the instructor's ability to provide support.
• On the back end, your solution can use whatever you like. However, because this course does not require INFO 441 Server-Side Development, only do solutions that require a backend if you have someone on your team with experience, or you're willing to spend a lot of time learning independently. There are many things you can build as front-end only single-page React applications.
• What you build doesn't have to be a graphical user interface. If you want to build something command line based or even an API, that's okay too. You still need to specify how someone interacts with your design, detailing the commands or APIs that you want to build and explaining in natural language what their behavior is.

Describe your Design

DESIGNERS lead

I recommend opening a Miro Links to an external site. board, sharing your screen, and sketching while you and your teammate's brainstorm.

Your job is to write a brief design specification that details the interaction design for your solution (as you've likely done in INFO 360). A design specification details what the software will do in terms of functionality, but not how. Your specification is good if someone could read it and understand the user experience of your application and rationale for your design choices. Everything else about how it might be implemented is work for later.

Your specification should have the following sections:

• Problem. This is a revised version of the problem statement from Homework 1. A good problem description is a logical, substantiated argument that proves the existence of a problem. Your problem description should cite evidence from your user research, as well as any scholarly literature you can find about the problem. This doesn't need to be long; a few paragraphs is usually enough to clearly define the problem you are solving.
• Solution. This section must detail every design decision necessary for engineering your solution, including every screen, every error, every algorithmic functionality, and every detail about the textual and visual content of your design (aside from content created by users). If your solution is software, a software engineer should be able to read your specification and build your solution without asking you any questions. Embed mockups of screens throughout the text of this section to visually specify your design. Because of the short timeline, it's okay if these are hand-sketched.

Note that you only have one week to do this. That means that your design really can't be that complicated from an interactive perspective. Keep your solution simple. Our focus in this class will be on something that is architected well, defect-free, and shipping, not something that is multifaceted and powerful.

To write a clear design specification, you need to iteratively evaluate how well the specification specifies its interactive details. Use the Clarifying a design specification strategy Links to an external site. on HowToo to improve your draft, and then write a comment on your experience using the strategy for credit. Remember that the comment must not be anonymous.

PMs: Store your specification in a GitHub Markdown document in your GitHub repository. You're welcome to collaborate on drafts of it in a different medium, such as Google Docs, as long as it eventually appears in GitHub, and is submitted as a public link.

Example Specification

Below is a very simple example specification that conveys the structure that I'm looking for, but not the level detail. (I expect your solutions to be more complex and include more detail about every possible state the user might enter). Sketched mockups are acceptable.

Problem

Many children in the world still memorize multiplication tables for numbers 0-10. This memorization helps them thrive in a world where small multiples are abundant in everyday tasks. However, paper-based forms of memorization are slow to grade, slow to practice, and thus often quite boring. This takes valuable class time away from elementary school students, while also creating the impression that arithmetic is slow and boring.

Solution

We envision a multiplication table game in which players receive a series of 1-digit multiplication problems, including digits 0 through 10 (0 x 0 through 10 x 10). Each successive problem is based on past correct and incorrect answers. When a player correctly answers all possible pairings of digits three times in a row, the player wins. Otherwise, the game continues to present problems that they have yet to answer three times correctly successively.

The interface is simple. There is one main screen for solving multiplication problems:

Players tap the digits to enter a number up to three digits long. They can tap the backspace key to delete a number, all the way back to an empty answer. They can tap the checkmark to enter the number. When backspace is pressed on an empty number, nothing happens. When three digits have been entered, the keypad buttons become disabled by turning gray.

When a player submits a number by tapping the checkmark, the game shows a correct or incorrect screen for 2 seconds before displaying the next problem:

:

After the answer screen , the game selects a new problem by finding a random pairing of digits 0-10 that the player has not yet successively answered 3 times correctly. The order of the digits does matter (7 x 3 is different from 3 x 7).

Once the player has won the game, they see the game over screen, which also provides the option of resetting the play history to start the game over:

The game contains no sound, no keyboard support. The game's interface layout is responsive to screen size, but uses the same interface layout for all platforms.

Grading Criteria

For homework credit, submit a link to your Markdown design specification from your GitHub repository.

• Problem (1 point). Full credit for something that is logically sound and clearly defined.
• Details (3 point). Lose 0.25 points for every interactive detail that is critical to solving the problem that is not specified. It's okay if visual details are not specified, since those can be changed easily. I want to see the core functionality of your application fully specified.
• Strategy Feedback (1 point). Write a comment on HowToo evaluating the utility of the specification refinement strategy.  Remember that the comment must not be anonymous.