Assignment 6
Due
Submitting your homework
We are going to use Github Classroom for this assignment. You need to have an account on GitHub and be logged in. Authorize Github Classroom here and accept the assignment, then follow the instructions there. Please follow the structure and naming of the starter repo, though you can add any additional files if you need them.
To submit the assignment, please visit Canvas
and submit the URL to your final commit that you want us to grade.
A commit URL looks like https://github.com/designftw-YEAR/hw6-username/commit/b59f14ba05869b3067724aa6d2006667a54c8e7d.
You can submit as many times as you want.
This is important. Your homework is not submitted and is accruing slack hours until you do this!
To make sure your homework is graded correctly, please follow the following:
- Please make sure each of your exercise directories are self contained, i.e. that you don't reference any files outside of the directory (e.g. from your repo root or other exercises). While having a common assets directory for all your exercises might be a good idea in general, we extract each exercise directory separately (as it may be graded by different people), and that will result in your pages not working correctly.
- Do not use root-relative URLs (URLs that start with
/) or absolutelocalhostURLs, as these require the grader to run a local server at a specific directory within your repo. If for some reason you cannot avoid it, please document it in a README otherwise links may be broken for whomever is grading your homework.
If you submit after the deadline, it will count towards your slack hours.
AI Usage
(guidelines updated March 11, 11:30pm)
Allowed uses
- Looking up or understanding relevant DOM API calls (manipulation, traversal, query)
- Getting further guidance on how to perform needfinding or idea generation in general
Unallowed uses
- Do NOT ask AI to generate or refine ideas
- Do NOT ask AI to generate or refine needfinding questions specific to your intended use case
- Do NOT use AI to draft or refine your needfinding report or prototypes. Those should be your own analysis.
Exercise -N: HW4 Retrogrades (Optional)
Now that you've received feedback on some of your assignments, we are offering a (completely optional) opportunity to improve some of your past work and resubmit it for a retrograde. Your final grade on an exercise will then be the average of the original grade and the retrograde. For example, if you got 10 points on the original exercise and 20 points on the retrograde, the final grade we'd put down for the exercise would be 15 points. We will never give you a lower grade than you got originally.
Not all exercises are eligible for retrogrades, either because they are part of multi-week assignments already or because we don't think fixing up that exercise provides a good learning opportunity.
This week, you may request retrogrades for any or all of:
To submit a regrade, simply commit and push additional changes to the relevant exercise in that week's repo. Retrograde submissions are due with the assignment where they are offered.
Exercise 1: Build a web scraper (30%)
A major use of DOM traversal is to scrape web pages, extracting the data from them for repurposing. There are general-purpose packages for this, but for this exercise you build one the old fashioned way, by hand. The intent of this exercise to help you gain familiarity with the DOM APIs for selection, creation, and deletion.
We will scrape information from the MIT EECS faculty page. The general design of your scraper should be as follows:
- use document.querySelectorAll with some appropriate selector to gather all the "root elements" containing each faculty description
- for each such root element e, use multiple e.querySelectorAll calls to select out different pieces of information about the faculty member
Information you should extract for each faculty is
- faculty name
- title (e.g., "Class of 1992 Professor")
- list of research areas
Your scraper should perform these three high-level steps:
- Scrape the existing site by traversing the DOM and collecting the above information from each faculty card.
- Delete the existing grid of faculty cards from the DOM.
- Add your table to the page by generating an HTML table with a header row (one column for each type of information) and one row for each faculty member, so that users can easily select-all and copy/paste the table into a spreadsheet.
There is no UI design to be done for this exercise; you will get full credit so long as your scraper produces the data in a compact, copyable HTML table and the original cards/grid are removed. You should not write any CSS for this assignment.
You should implement your scraper in the body of the scrape function in the js file scraper.js that we provide in the starter repo.
To run the scraper, its script has to be included into the page you want to scrape. A common way to do this is with a bookmarklet.
Once your scraper is working you can make a bookmarklet for it if you wish.
But to simplify your development work, we've included a copy of the page we want to scrape in the starter repo, with an added script tag that includes scraper.js.
Do not edit this file. But once you've added your scraper code to scraper.js, you can test it by loading this file.
To test your submission, the graders will open the real page and use a bookmarklet to load your scraper code and run it in that page.
Exercise 2: Needfinding for chat/IM apps (40%)
This assignment begins a series of steps which will culminate in you implementing a chat/messaging app, following an iterative design process of progressively more high fidelity prototypes and eventually an implementation.
You might decide to design a messaging app for the general population, or something optimized for a particular use case (e.g., discussing a sporting event in real time) or user population (e.g., students enrolled in 2.70 at MIT). It's ok if you are part of the target user population (but you cannot interview yourself).
In HW5 you were asked to compare the usability of several existing chat apps. In this exercise, you will be doing needfinding to see what needs people have from the chat apps they use, and what their pain points are.
You may already have a feature in mind that you want to implement. How does this align with the idea that you are supposed to do needfinding before you design? Well, you've probably come up with that feature by imagining some need that the feature would address. In this case, your user population would be "people who have that need" and your needfinding process would aim at (i) confirming that there are indeed people who have that need and (ii) learning more about the details of that need---as it may turn out that your imagined feature isn't the best way to address it.
You will interview at least three people for this exercise. The interviews don't need to be very long, but try to reach out to people early!
How to Conduct a Needfinding Interview
The Mom Test is a great resource for scaffolding effective needfinding interviews. It can be purchased at $10 for a digital copy or $20 for print. (It's also pretty easy to find for free on Google or if you check the HTML source of this page!) Don't get too hung up on its focus on business and making money. You're making an app and it will be free, but the principles still apply! We recommend you read the first three chapters since they will help you prepare for and conduct your interviews.
Part 1: Interview questions (10%)
Per Chapter 3 of the The Mom Test, before each interview create a list of 3 big questions about your target users that you most want answers to. This list may evolve between each interview. That's ok!
From the book:
Don’t stress too much about choosing the "right" important questions. They will change. Just choose the 3 questions which seem murkiest or most important right now. Doing so will give you firmer footing and a better sense of direction for your next 3.
You should also refer to our advice on needfinding from class.
Deliverable:
- A brief description of your intended user population (who you are designing for and why)
- The list of questions you used for each interview
- A short explanation of how and why your questions evolved (or didn't) between each interview
Part 2: Interviewing (15%)
Interview at least three people, and record your interviews (you'll find you need to revisit them to fill gaps in your memory). You need not transcribe the interviews word for word, but take detailed notes on what they say. Each interview should be around 10-20 minutes long.
Refer to The Mom Test for how to conduct these interviews. You should also collect some basic demographic information, as outlined in the lecture slides.
Deliverable:
- A description of your target users (who you chose to interview and why they represent your intended user population)
- Your interview notes
- A 5-10 second clip of each interview, included in your writeup through
<audio>or<video>elements (please don't upload your entire interviews in the repo)
Part 3: Key Insights (15%)
Examine your notes to distill 5-10 most-important conclusions from the notes you took.
Deliverable: Your list of most-important conclusions
Exercise 3: Idea generation for chat/IM apps (30%)
Based on your needfinding, identify at least two needs you could address with your chat app. Then, for each need, go through this process, a variation on the "10 plus 10" sketching technique:
- Create at least five sketches of ideas for addressing that need. The ideas don't have to be good! We're going for quantity over quality. But they should be substantial and substantially different from each other. See what happens when you give your editing brain a break.
- Go through each sketch and describe the need, the proposed solution, and why you think it might work.
- Pick the one or two most promising designs for the need.
- Sketch a total of five details and/or variations of the design(s).
- Describe each one as before.
You can find an example of this process here.
Here are some ideas to seed your creative process.
- Add some organizational mechanism such as folders or tags to let users save some messages for later finding.
- To assist coordination, indicate that certain messages require replies from certain participants, and make sure users can find/interact with messages that require replies from them.
- An app for illiterate users that delivers voice messages
- Configure automatic replies to all or certain messages (e.g. "I'll be afk until 4pm and will respond then")
These are just for inspiration; do not use them same ideas for this exercise unless you develop them significantly more.
How to sketch: For this exercise, since you are still exploring preliminary designs, we'd like you to try fat marker sketching. See Basecamp's Shape Up book for more details and examples.
You can literally use a large sharpie marker to do this! A digital tablet with a large diameter pen works, too. This sketching style encourages you to not get bogged down in details too early.
A Note on Scope
The ideas you present should not be tiny ("use a better font for improved readability"). Also, since you will ultimately be aiming to implement these ideas, they should not be too large ("an online discussion and voting system for state government budgeting"). Instead, you should think on the scale of adding features to what is still at its core a traditional messaging application. These added features are may only partially address the need you've identified. You are encouraged to confer with LAs regarding the scope of your ideas before you flesh them out.
Deliverable: For each of at least two distinct needs:
- At least five sketches of ideas for addressing that need, each with a short description of the need, the proposed solution, and why you think it might work.
- Your chosen most promising design(s) for that need and why you chose it.
- Five sketches of details and/or variations of that design(s), each with a short description as above.
Present the sketches via photos or scans. Include all accompanying text in your writeup.
Exercise N: HW6 feedback
Since this is a new class, we need your constructive feedback about every aspect of it: lectures, homeworks, labs etc.
Please fill in your feedback about HW6 in this form. You can edit it as many times as you like until the survey closes (48 hours after the homework deadline). Since this is part of your participation grade, it does not affect your slack hours, but failing to submit the form on time, could result in a lower participation grade.