Due date. This assignment is due at 11:59pm on Friday, September 29.

Overview. In your last assignment, you brainstormed feature ideas for your app, and you posited some concepts to implement those features. In this assignment, taking your previous ideas as a starting point, you’ll construct a complete design of your app, comprising three parts: an overview of your app describing its audience and purpose; a conceptual design consisting of key concepts and their relationships; and a user interface design in the form of wireframes of the main pages. No design is perfect; there are always tradeoffs between different options. As part of this assignment, you’ll think carefully about what tradeoffs you made in your own design.

Purposes. The purposes of this assignment are to give you practice in: (a) moving from divergent to convergent design, and focusing and scoping your design ideas; (b) expressing the functionality of your design in terms of concepts (defined as state machines with states and actions), and doing the hard work of modularizing the design by separating the functionality into concepts that are truly independent of one another; (c) constructing wireframes for prototyping user interface layouts and interactions; (d) making design tradeoffs and explaining them succinctly.

Commitment. You may be wondering at what point your are committed to implementing the design you have in hand. Recognizing that design is always iterative, and that you will discover design flaws and opportunities during implementation, we anticipate that you will make changes in the next two (implementation) assignments to the design you develop here. But we expect the design resulting from this assignment to be very close to the design as implemented. In contrast, this design need not be close to the design you outlined in the previous assignment (although if you go too far, you might lose the benefit of the insights you gained from your interviews).

Tasks

Please read this whole section and all the advice before you start!

Pitch. Write a succinct (100 to 300 word) product pitch for your app, that gives it a name, describes its intended audience, the value that it brings, and some of its key functionality. Feel free to build on what you wrote in the previous assignment, and to draw on the insights you gleaned from your interviews and introspection. Describe the functionality in terms of the central concepts. You may well want to just adjust this pitch when you have completed your conceptual design.

Functional design. Design a collection of concepts that will embody the functionality of your app; you’ll probably want 5-7 concepts for an app that is sufficiently rich to be interesting but not so complex that it can’t be implemented in the time you have (4 weeks). Of course you can use the concepts you identified in the previous assignment, but you can also adjust or even replace those concepts. Each concept should have the standard parts (name, purpose, principle, state and actions). You can write the principle informally, so long as it’s clear which actions are being referred to. The state should be defined using sets and relations. The actions can be written informally, or using the set/relation syntax illustrated in class. Define the app-level actions as synchronizations of concept actions, and instantiate generic concepts with appropriate types. Draw a dependency diagram showing the possible subsets.

Remember that the goal of this personal project is not just to learn the basics of building a full-stack web app but also to practice innovative design. So your design should have some novel elements to it, such as new concepts (which are not familiar from existing apps), new enhancements of existing concepts (adding actions or state that makes the concept more powerful or flexible or perhaps easier to use), new uses of existing concepts, or new synchronizations between existing concepts.

Wireframes. Construct a set of wireframes that shows the user interface elements and their layout, and includes some of the main flows. You can omit error handling and completely standard interactions (such as user registration), but your wireframes should otherwise be enough to cover all your concepts.

Design iteration. As you work on your functional design and wireframes, you should simulate the execution in your mind, considering each step the user might take and how the app would react. You should also have in mind the social/ethical concerns that you considered in the last assignment, and how they might be impacted by the decisions you’re making. As you do this, you will encounter problems that you have to resolve and choices to make. Note down the issues as they arise, and the options you considered; you won’t hand these notes in, but they’ll be useful in the next step.

Design tradeoffs. Using the notes that you took during your design, pick at least 3 design decisions that you made in which you had to choose between multiple options. For each one, provide (a) a pithy title naming the issue; (b) an outline of what the various options were; (c) a rationale for why you chose one option over the others. Try to keep your analysis below 300 words in total (for all the tradeoffs).

Submission Process

Post your design document to your portfolio by the assignment deadline. Feel free to structure your document as you please; you can have multiple sections of a single page, or you could split the document into separate pages. Just don’t put your document in a PDF! And remember to check that your document displays properly when viewed through a public URL.

Submit this Google form to finalize your assignment submission, also by the deadline.

You must do both steps for us to consider your assignment submitted.

Rubric

The teaching staff will grade your assignment using the following rubric. Grading will occur qualitatively, and the teaching staff will conduct multiple rounds of collaborative grading, calibration, and cross-checking to ensure consistency. This assignment is worth 10 points. Submissions that meet the expectations (i.e., the Satisfactory column) will roughly map to a B (8/10). Submissions that exceed expectations will roughly map to an A (9/10), while submissions that require substantial improvement will be awarded a C (7/10). Note that individual rubric cells may not map to specific point values, and excessively long answers will be penalized.

Part Excellent Satisfactory Poor
Pitch Concise overview of app that convincingly explains what it offers and what problems it solves, making it sound new and exciting, and connects to the lessons from the interviews. Gives good idea of what the app offers, but is not persuasive or novel sounding. Hard to understand, rambling or doesn’t hold together.
Design novelty Design addresses problem in a creative way with novel concepts or by using familiar concepts in new ways. The app as a whole fulfills a novel function, but its design is conventional and uses existing concepts only in standard ways. The app is not novel in its overall functionality or its conceptual structure.
Concept independence Concepts are independent and made generic (polymorphic) when possible, suggesting opportunities for reuse. Concepts do not reference each other or assume each other’s presence, but some concepts refer to specific types when they could in fact be generic. Generic concepts are correctly instantiated in the application definition. Concepts reference each other, eg as if they were classes in an object-oriented program.
Concept familiarity Includes an example of a non-trivial factoring that allows a familiar concept to be used. When concepts embody common functionality, they take a familiar form. Familiar functionality is obscured in unfamiliar concepts.
Concept basics Purpose reflects non-obvious insights about the value the concept brings; overall design of concept allows unusually clear OP. Informative name, compelling purpose, readily understandable OP. Poor name, unclear purpose or confusing OP
Concept state and actions States always defined with sets and relations; actions are always clear. All the essential actions, sufficient state to support them, but action definitions not consistently clear. Missing actions, insufficient state, unclear description
Concept syncs Syncs include some examples of synergy. All interactions between concepts are defined by syncs between concepts. Syncs are unclear, or concepts interact by other means.
Dependency diagram Diagram includes all concepts and shows correct relationships. Diagram includes all concepts and shows correct relationships, but maybe has an incorrect edge or two. Diagram misses some concepts or has several incorrect edges.
Wireframes Concept actions and visible state are presented clearly; executing operational principles is straightforward and intuitive; interface teaches the underlying concepts effectively Concept actions and visible state are available in the interface; executing operational principles is possible but not completely intuitive; concepts not inferable from interface without additional help Some actions or state that should be visible unavailable in interface; operational principle hard to execute; misleading image of concept projected
Tradeoffs Identify and thoughtfully address subtle issues that lack easy solution Clear explanation of non-trivial decisions Uninteresting issues, poorly explained decisions, or straw-man options

Advice

Start early. If you make an early start on thinking about your design, you’ll have it in mind over the next few days, and you’ll mull it over in the back of your mind and find both interesting flaws and interesting fixes without trying too hard. But if you leave the whole assignment until the last day, it will be hard to think creatively, and you’ll have much less fun.

Don’t postpone the details. We can’t stress enough how important it is to avoid wishful thinking and postponing critical details until coding. We know it’s hard to estimate how much coding work it will be, especially since you’ve never built a web app before. But you should assume that anything that you’re unable to specify precisely in your concept design is potentially a tarpit, so if you can get all your concepts clear in your mind, you can be much more confident that coding will go smoothly (and that you won’t have to make radical changes to your design).

Scoping your app. Don’t be too ambitious, and try to include only the concepts that are absolutely necessary to make a proof-of-concept app. That means some features that would be very nice to have in practice can be missing. On the other hand, make sure you have enough concepts to make a coherent app that gives the full experience of your design idea, and that your design is novel enough that you’ll feel a sense of satisfaction in building something different from everything else out there.

Wireframing resources. For wireframing, Figma’s tutorials provide helpful background beyond the recitation notes.

Concept design resources. For concept design, see the tutorials. The most relevant ones are those on concept modularity; concept criteria; concept purposes; operational principles; concepts as state machines; concept state; concept composition and sync; and dependence diagrams and subsets. For inspiration, see the tutorials on great design and simplicity. For more general background on software concepts read this tutorial or this more expansive blog post. The recommended text has chapters about all these topics with many examples, and is available as a paperback book and as a free PDF from the MIT Library.

Being succinct. Try to be as succinct as possible in your written answers. We’re not asking you to write essays here, so keep it as brief as possible, and use bullet points and bolded subtitles to give structure even to short paragraphs. Bear in mind that we will penalize excessive length (that is, going over the word limit when the content doesn’t justify it).

Judging novelty. When we ask students to be creative and innovative, they sometimes ask how much novelty is enough. In previous versions of the class, we’ve sometimes even specified that you need some number of novel concepts, etc. But our sense is that such constraints don’t encourage creative work, and may actually limit it. So instead, we ask you to be creative and introduce innovative ideas, and we’ll judge the novelty of your design qualitatively, giving credit generously for genuine novelty.

Concept independence. The requirement that concepts be independent of each other is very challenging, and you should expect to spend time figuring out how to achieve it. This requirement is hard because it forces you to do introduce modularity early on. Often, developers are sloppy about this and then they have to introduce modularity in the code, when everything is more complicated and that can require a lot of reworking. Put another way, it’s a difficult task whenever you do it, but it’s easier to do at the design phase, and will make coding much easier. We’ve written a tutorial that explains this in more detail.

What independence means. Note that being independent does not require a concept to not reference the objects of another concept at runtime. For example, a Comment concept might contain comments with ids of target objects, which at runtime may be posts, images, etc, but the Comment concept itself can be designed and implemented without any mention of which other concepts actually generated these ids.