6.S063 Design for the Web: Languages and User Interfaces

↑ All assignments

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/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:

If you submit after the deadline, it will count towards your slack hours.

Exercise 1: Fix the Web with CSS! (30%)

Many of the usability improvements we have discussed in lecture can be performed entirely by modifying a website's CSS.

For this exercise, you need to find and make such improvements on websites you visit. Use the Dev Tools to experiment with modifying the CSS of an existing website (and see what selectors to use). You could even use Stylus to share your modifications with the world, if you want to (we just ask that if you choose to do so, you wait at least 2 days after the deadline!).

Note that not all websites you visit will have nice HTML that lends itself easily to elegant CSS selectors. In some cases you may need to write selectors that are selecting based on the type of the element and its position in the DOM, or its attributes. Make sure that the selectors you write do not depend on HTML that changes across users/pageviews.

Each usability improvement you make (learnability, efficiency, safety) is worth 10 points for the exercise, 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 even a mix (e.g. 2 usability improvements and 4 graphic design improvements).

Note that usability dimensions often correlate, and improving one frequently also improves others. However, you cannot have the same improvement count for multiple categories. If it addresses multiple usability dimensions, you should still point that out, but grade-wise it will only count towards the category that gives you the most points.

Usability improvements need to be justified using the vocabulary we are learning in class or that you read in DOET. Graphic Design improvements need to be justified using the principles we learned in the Graphic Design lecture. For example, improving typography (e.g. by using CSS to change the font family, size, or spacing between lines) and then writing "the website is now easier to read" will neither get full points as a usability improvement, nor as a graphic design improvement because it is neither refrencing usability principles, nor graphic design principles. Often improving graphic design improves usability as well, but each improvement you make can only count towards one of the two (the one that gives you most points).

If you list improvements whose points exceed 30 points they will be capped to 30 points, you will not get extra credit. You can make multiple improvements on the same website, but you need to make sure they are sufficiently independent and separate.

Do not use the same type of improvement more than once. For example, hiding distractions (e.g. ads) is a way to improve usability (which dimension?), but you cannot just submit three improvements where you just hide different page elements.

Do not pick improvements which require login, unless they are about very big websites (Facebook, Twitter, Instagram etc) or MIT websites.

Having trouble finding websites? Here are some broad categories of websites that usually have a lot of room for improvement:

  • Internal MIT and MIT-related websites (e.g. registration, WebSIS, Stellar, Canvas, MIT Firehose, MIT Recreation, various research groups, clubs, sororities, fraternities etc)
  • Course websites (including ours!)
  • Small business websites (e.g. local cafes, restuarants, daycares, etc)
  • Conference websites
  • Startups and smaller scale websites (e.g. Piazza, forums)
  • Airline websites

Avoid trying to improve Facebook or Google, their markup is so mangled you are going to have a very hard time writing CSS for it.

You are not allowed to use !important in your CSS unless it is absolutely necessary. Part of the exercise is to get you to practice writing selectors when you cannot adjust the HTML to make it easier for yourself, and to get you to understand the cascade. !important is a bad practice in general, and rarely necessary. If you are absolutely 100% certain that there is no other way, you can use it, but if you are wrong, you will lose all the points of that improvement.

There are two main cases where !important is necessary:

  • When you are overriding CSS that is in style attributes
  • When you are overriding CSS that also has !important

In almost every other case, it is not necessary.

Your improvements need to only consist of CSS that can be included in a user stylesheet.

This means:

  • No JS
  • No changes to the HTML
  • No changes to inline styles (overrides via CSS rules are fine)

To grade your exercise, the grader will visit the website via the link you specify, then open the JS console and run this code:

document.body.insertAdjacentHTML("beforeend", `<style>/* CSS here */</style>`)

This inserts your code in a <style> element at the very end of the HTML markup, after any other stylesheet. This means you don't have to worry about your CSS coming before other stylesheets (though of course specificity is still a concern) You might want to run the same code to make sure everything works as you expect.

Deliverable: An HTML page with your improvements, in a fix-with-css directory. For each improvement, please list:

  • A clickable link to the website that it improves. Please do not download and include the actual page in your homework. A link is fine.
  • The CSS code for the improvement. Make sure to mark it up with appropriate HTML for code snippets. Screenshots of code will not be accepted.
  • Which usability dimension(s) and/or design principles are improved.
  • A sentence or two about how your code improves this usability dimension
  • Screenshots (or video!) before & after. Please save screenshots as PNG, not JPG or GIF. Do not take photos of your screen, look up how to take actual screenshots for your OS.

Please include a table of contents in your HTML with internal links to the improvements listed.

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 have 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.

Your interface should make common use cases efficient, and uncommon use cases possible.

Your app should focus on being efficient for the most common cases. Neo and Trinity will use this all the time, and if it takes too long to enter something, they are more likely to forget to enter it at all.

The most common cases are:

For these 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.

While efficiency is the focus of this exercise, 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 is selected through pressing A-J for each of the 9 combinations may reduce selecting this info to a single keystroke, but it is not an acceptable tradeoff, as it sacrifices too much learnability, and is not memorable as it relies entirely on knowledge in the head.

While common cases are most important and the UI should be designed to optimize them, uncommon cases should still be possible to enter, with reasonable efficiency. Uncommon cases you must support include the following:

The design challenge you need to solve 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 some bonus points, but you won't lose for supporting only these.

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)

The app should be fully functional, including storage.

You will be implementing this as a VueJS app, using the MaVue helpers if you want. The skeleton repo includes an app that reads and saves to GitHub, as well as the data from the spreadsheet in JSON format, though you need to modify the URL to that of your own repo so you can save.

We wrote the MaVue helpers so you can use VueJS without learning (much) JS, since learning JS properly comes later in the semester. You are not graded on how you write JS until we cover it properly; therefore if you need any help writing JS expressions for Vue, feel free to ask the course staff on Piazza or OH (try to reduce your question to just the part about JS, to avoid giving away part of your solution!).

Deliverable: Your app in the expenses/ directory of the starter repo. Since this is a design task, depending on your design, you may need to modify index.js. If you do, don’t hesitate to reach out to ask about what JS would implement what you need to do. We are not grading you on how you write JS, only on the interface you design.

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:

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.

← Assignment 2 Assignment 4 →