Assignment 3
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/hw3-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.
Exercise 1: Fix the Web with CSS! (30%)
Many usability improvements we’ve discussed in lecture can be achieved entirely with CSS—no HTML or JavaScript changes required.
Exercise Outline
- Pick one or more real websites you visit.
- Use DevTools to modify the CSS to improve the:
- Usability (learnability / efficiency / safety), and/or
- Graphic design
- Document each improvement with
- A (clickable) link to the website you are modifying
- Your CSS change (marked up as code, not a screenshot)
- A sentence or two justifying how your change improves the usability/design (using course vocabulary)
- Screenshots/recordings of the site before and after
Each usability improvement you make is worth 10 points, and each graphic design improvement you make is worth 2.5 points.
Therefore, to get full points in this exercise, you need to find & implement 3 usability improvements, or 12 graphic design improvements, or a mix (e.g. 2 usability improvements and 4 graphic design improvements). No extra credit, sorry!
Choosing a website
Note that not all websites you visit will have nice HTML that lends itself easily to CSS selectors. This is especially true of massive websites like Amazon, Facebook, etc. If you are struggling to find a good website to work with you can try:
- Internal MIT and MIT-related sites (registration, WebSIS, MIT Firehose, MIT Recreation, research groups, clubs, etc.)
- Course websites (including ours!)
- Websites we've critiqued in studio
- Small business websites (cafes, restaurants, daycares, etc.)
Try not to spend more than a couple minutes finding a site - most sites have room for improvement and you don't need to use the same site for all your improvements.
However, please avoid login-gated pages unless they are for very large websites (Facebook, Twitter/X, Instagram, etc.) or MIT websites, as these can be difficult to test and grade.
How we will test your CSS
To grade your exercise, the grader will open the website link you provide, then run:
document.body.insertAdjacentHTML("beforeend", `<style>/* CSS here */</style>`)
This inserts your CSS in a <style> element at the very end of the HTML markup, after any other stylesheet.
To make CSS work as a global stylesheet, make sure you are using appropriate CSS Selectors based on element types, classes, attributes, and/or position in the DOM.
Constraints
- CSS-only: Do not change the HTML, javascript, or add inline styles.
- No
!important:!importantis a hack that you can always avoid with proper selectors. - No double-counting: One improvement may help multiple dimensions, but we will only count it once.
- No repeats of the same “type” of fix: Example: “hide distractions/ads” is one type of improvement—you can’t submit three variations of “hide different page elements.”
Deliverable
Submit an HTML page in a fix-with-css directory including your changes each with a site link link, CSS code, justification, and before/after
Exercise 2: Couple Expenses App Implementation (60%)
It is now time to implement an app for the expenses problem we explored in HW1. This time, you have also learned a little bit of CSS, and you can also use that in your prototype.
You don't need to use any of the HTML you wireframed in HW1. You can (and likely should) change your design decisions.
For this exercise we want you to think hard about the problem space and create an innovative, efficient interface that is tailored to the problem, rather than adopting a design that is similar to other expenses apps out there that have different goals.
We want you to focus on the expense-entering and -editing UI and really think creatively about optimizing that, not on analytics, so don't worry about charts and other summary information (though of course you're welcome to work on that as well, after you're done, as extra credit).
About JavaScript
You do not need to write JavaScript to complete this exercise. The starter code and Vue handle most of the functionality you need. If your design idea would require custom JS to implement, consider whether there is a different design that achieves the same goal using only HTML and CSS. There is almost always a way.
That said, sometimes a little JS is the most natural way to express what you want. If you do want to do something that requires JS, feel free to ask the course staff on Piazza or during OH (try to reduce your question to just the part about JS, to avoid giving away part of your solution!). You may also use AI to write basic JS expressions, but remember to adhere to the Course AI policy.
We are not grading you on how you write JS, only on the interface you design. Learning JS properly comes later in the semester.
Common Use Cases (optimize for these)
Your interface should make common use cases efficient and uncommon use cases possible.
Neo and Trinity will use this app all the time. If it takes too long to enter something, they are more likely to forget to enter it at all. The most common cases are:
- Neo or Trinity paid for a joint expense
- The joint card paid for a personal expense of Neo's or Trinity's
- Entering expenses retroactively (i.e., days or even weeks after they happened)
- Expenses are entered in USD
Uncommon Use Cases (must still be possible)
While common cases are most important and the UI should be designed to optimize them, the following uncommon cases must still be possible to enter, with reasonable efficiency:
-
Foreign currency: Trinity and Neo went traveling. Some expenses are in a different currency, but the total amounts owed still need to be in USD. (The skeleton includes a rudimentary
currencyConvert(from, to, amount)function — since this is a prototype, it's OK to only support USD, EUR, and GBP.) -
Unequal splits: For some expenses, Trinity and Neo both paid unequal amounts. These expenses might be joint or might be for just one person.
-
No-impact expenses: Some expenses don't change the amount of money one person owes the other. For example, Trinity and Neo might have split a joint expense equally, or Trinity might have paid for an expense for herself. They may still want to record these for bookkeeping purposes.
The design challenge is how to accommodate these uncommon cases while keeping the common cases as efficient as possible. If you think of additional interesting uncommon cases, you may earn bonus points, but you won't lose points for supporting only these three.
Efficiency, Learnability, and Safety
Efficiency is the primary focus of this exercise. For the common use cases, use KLM (discussed at the end of the Efficiency lecture) to reduce the number of keystrokes needed and eliminate homing between keyboard and mouse as much as possible. It should be possible to add a common type of expense without using the mouse at all, and without more than five keystrokes (if that) to select payer and payee. You don't need to include your KLM analysis anywhere — this is to help you make better design decisions.
Learnability and safety still matter. It is acceptable to make some tradeoffs between learnability and efficiency (since this is an app for specific users, built for their needs), but the interface cannot be entirely obscure. For example, a UI where payer and payee are selected by pressing A–J for each of the 9 combinations may reduce the selection to a single keystroke, but it is not an acceptable tradeoff — it sacrifices too much learnability and is not memorable, as it relies entirely on knowledge in the head.
Technical Notes
The app should be a fully functional Vue.js app.
The skeleton repo includes basic storage functionality like last time,
but feel free to change the UI for logging in and saving data if it would help usability.
The graffiti-personal-data component also accepts an autosave attribute (i.e. <graffiti-personal-data autosave ...>) that you may
(or may not) want to use in your app. (Consider the safety implications of autosave.)
If your design requires changes to index.js, don't hesitate to reach out about what JS would implement what you need.
Deliverable: Your app in the expenses/ directory of the starter repo.
Exercise 3: Poor Safety Example for Studio (10%)
Submit an example of a website with poor safety design for consideration in studio. You should do this exercise after Monday's lecture on safety, as it will give you inspiration about what to look for.
Create four slides on Google Slides:
- The first one should contain a screenshot and URL of your example
- The second slide should be titled "I Like…" with short bullet points about what you liked (which need not focus on safety)
- The third slide should be titled "I Wish…" with short bullet points about what you wish was different, targeting safety
- The fourth slide should be titled "What If…" with ideas about fixing the issues identified in slide 3.
Your slides should also be concise, and thus, efficient. If you spend more than 20 minutes or so making them, you probably misunderstood the exercise.
We may select some particularly educational examples to be discussed in studio.
Deliverable: A README.md file in studio/ with its only contents being a URL to your Google Slides.
Please do not include any other contents, as this will be read by script.
Don’t forget to make your slides publicly viewable!
While you need to submit the URL by the deadline of this homework,
you can continue editing your slides for an extra day (until Thursday midnight).
Exercise N: HW3 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 HW3 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.