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

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:

• 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 absolute localhost URLs, 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 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.

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

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:

• 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) is pretty common
• Expenses are entered in USD

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:

• Trinity and Neo went traveling. Some of their expenses are now in a different currency, however the total amounts owed still need to be in USD (the skeleton includes a rudimentary currencyConvert(from, to, amount) function for you — since this is a prototype it's ok to only support USD, EUR and GBP currencies).
• For some expenses, Trinity and Neo both paid unequal amounts. These expenses might be joint expenses, or they might be expenses for just one person.
• 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. However, they still might want to record this expense in the app for bookkeeping purposes so they know how much money they spent.

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.

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.

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.