Project

Overview

Form a team of three to four with others in your discussion section. As we will discuss in lecture, teams are hard, because interdependence is hard! So, make sure to have conversations up front with your team about what kind of norms you want, how invested you want to be in this project, how you will interact with each other, and why. If you cannot form a team of three to four, talk to a TA. However, our expectations are scaled around teams of three to four: we expect nearly as much work from teams of two as we do from teams of 3–4, and we expect much more work from teams of five than we do from teams of 3–4.

Work with your team to brainstorm a number of ideas. What are you proposing to create? You may pick the goal: fun, collaboration, collective action, creativity, or anything in between. What set of people will be seeding your social system? You will be creating this system from scratch. You are also tasked with considering the negative outcomes that might arise in your system, and how to address them effectively. You will launch that system. Finally, you will be writing up a paper analyzing your design and the behavior based on the theories and concepts from the class.

To give a sense of the scope and ambition we aim for we have placed some example projects from previous years in the "Files" area of Canvas. Please note that these examples were from earlier iterations of the class, and the requirements have evolved a bit since then.

Select A Project Zone

To support the range of different backgrounds and skills in this class, your team may elect for how technically focused, vs. how socially focused, the project is. You may choose one of three zones, which impact the expectations in terms of how many users we expect you to recruit and how much you analyze their behavior on the platform:

Your zone determines what is due at each deliverable.

All Zones are committed to designing for nontrivial social interactions: creating a Google Form and calling it a day is not a complex enough social interaction for the purposes of this project. Zones 2 and 3 are also making a commitment to recruit users onto the system. You might wonder, "But what if nobody uses my system?" Don't worry—learning to navigate this is part of our learning goals. First, you will propose a concrete usage goal in the proposal assignment, based on the guidelines above for your Zone. Via this proposal, you will come to an agreement on your usage goal with your TA. Make sure to launch far in advance of the deadline, so that you will have time to adjust course if you are not attracting usage like you expected. If, in the course of your project, you want to adjust your goal based on the realities of your project (e.g., it's a ghost town), reach out to your TA. Based on the situation, your TA may suggest that you iterate your design based on the feedback rather than adjust your usage goal, or may work with you to adjust the goal. If, after a few iterations, your project is still a ghost town, you and your TA may agree to change your final paper deliverable so that you report all of your iterations and compare them --- that your final paper can instead be a comparative analysis across your attempts to understand what is going on.

We don't receive any funding for this class, so you'll want to pick your platforms with budget in mind. Many platforms (e.g., Wix, Firebase, Render) have free trials, or you can budget ahead if you want to use a paid hosting platform.

Proposal + Piggyback Prototype

Decide on a Zone and a project topic. Based on your zone and the information above, decide what a reasonable goal is for how many active users your system will have to earn full credit on the Viral part of the project grading rubric. For the purposes of this class, we define an active user as someone who did more than just lurk on your system --- they must have contributed in some way. The table above provides some general guidelines in terms of numbers if you are looking to target Stanford students, but your project may target other or smaller communities (e.g., affinity groups you are a part of, interests you hold), and so adjust your target goal appropriately. The TAs will review your proposal and give you the OK for your target, based on your project and target community. In discussion with your TA, you may switch zones later in the quarter if needed.

Next, prototype your proposed design using a piggyback prototype. This probably involves getting at least five people outside your group involved in your prototype. As discussed in lecture, piggyback prototyping explicitly avoids building complex software: fashion something out of existing social platforms. Don't forget that piggyback prototypes should test authentic social behavior, not usability or feasibility.

Submit on Gradescope a PDF of 1,500 words or less on behalf of the group that reports:

1. The group members - names and SUNet IDs.
2. A high-level description of the design and motivation for your sociotechnical system.
   Tie the design and motivation to course concepts. Specifically: using concepts from lecture (e.g., the contribution pyramid, sociotechnical systems, intrinsic/extrinsic motivation, social influence, descriptive/injunctive norms), explain what the problem is, and how your design will address it.
3. Your project zone, user goal, and technical plan. Which zone is your project in? Based on the zone, what is your proposed number of active users your system will have in order to earn full credit on the Viral part of the project grading rubric?
• If you are in Zone 1: what code platform will you be using to build your system? Why that platform? Confirm that your team has roughly equal technical ability to contribute (so that one poor member isn't doing all the technical work). Lay out a high level technical plan for the engineering.
• If you are in Zone 2: what no-code platform will you be using to build your system, and what code platform will you be building your extension in? Why those platforms? What concrete extension will you be making to the non-code tool? Remember that Zone 2 requires a substantial code extension of the non-code tool, and must be well integrated into the system rather than an afterthought.
• If you are in Zone 3: which no-code platform will you be using to build your system? Why that platform?
4. Your method of prototyping the system.
   How did you test your envisioned social dynamics without spending weeks building the system?
5. Your results from prototyping the system.
   What happened when you tried out your prototype? What confirmed your design hypotheses, and what surprised you? How will you be adapting your design going forward? Again, tie the explanation to course concepts (e.g., those in the list of course concepts above) to explain the outcomes you observed.
6. Possible negative behaviors in the system, central ethical risks, and privacy concerns, and how you intend to address these. As a group, pick three of the most relevant Tarot Cards of Tech for your project, and apply them to your project idea. How will you address those risks? These considerations boil down to a reminder that real people will be using the system that you create. With great power - and the liberty to make design decisions - comes great responsibility.

On all project submissions, images and figures are not counted toward the word limit. If needed, project submissions may also include an appendix, which the staff will review if possible.

Only one team member needs to submit for the group on Gradescope. Remember to tag each team member in the submission.

While waiting for the staff to give feedback on your proposal, start thinking ahead about who you can reach out to as a seed community for your system.

Grading rubric

Milestone

The milestone deliverable is a checkpoint for the staff to provide feedback and help scaffold progress toward a successful final deliverable.

The deliverable varies by Zone:

• Zone 1: Either the front-end or back-end of your system is functional. For example, you might have a working React app populated with fake data, where the user can click around and interact on the platform but there is no server or database yet.
• Zone 2: The no-code components of your system should be complete. For example, the user interface should be finalized and ready to launch. However, the code components of your system may still be in progress.
• Zone 3: Launch! Your system, which is no-code, should be ready to launch. Following the milestone, launch it and start gathering usage. Zone 3 should launch the earliest, since its virality and analysis expectations are the highest.

If you want to switch Zones, make sure to clear it with your TA before submitting the milestone.

In your writeup, include:

• Screenshots or videos of your system, to demonstrate its current level of functionality
• A timeline for completing the project. Provide a list of TODOs — e.g., exam studying, wrapping up dev work, recruiting users, analyzing usage, writeup — and assign dates to each one.

As you launch, bear in mind the Social Computing Fundamental Standard and your responsibilities toward hosting a meaningful and enjoyable experience. Do not be a huckster. You also don't necessarily need to go viral across campus or the internet—you want to get meaningful amounts of behavior from your target group. Keep in mind that it takes time for people to find and participate. Don't wait until the night before this deadline. You are welcome to continue adapting your system as people use it and you gather feedback, and you are welcome to continue growing it through the final paper submission.

Submit on Gradescope a PDF of 500 words or less describing your milestone deliverable, as well as screenshots or videos. If you need to revise your target active user goal from the initial proposal, include that as well so that you and your grading TA can arrive at a revised agreement. Only one team member needs to submit for the group on Gradescope. Remember to tag each team member in the submission.

Final Paper

Submit a final report of up to 4,500 words. Only one team member needs to submit for the group on Gradescope. Remember to tag each team member in the submission. In addition, each team member will need to submit a final teammate evaluation form. This evaluation will factor into your overall final participation grade.

As usual, screenshots and images do not count toward the word limit. Your paper should include: