Assignment 7

Due Friday, April 1, 2022 at 1:00 PM

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. You can submit as many times as you want. Your homework is not submitted and is accruing slack hours until you do this!

Please make sure each of your exercise-N 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 that expect a local server to run at a specific directory within your repo, and if 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: Paper prototype a chat/IM app (20%)

The myriad of chat apps being out there and each having their own user base can tell us one thing: that there is perhaps no perfect chat app yet and that the existing apps each have their own grievances. In this assignment, we want you to think how you would design a chat app that fixes some of the usability problems you found in Exercise 4 of [HW5](../hw5), integrates the best characteristics of the apps you compared, and goes further to improve on them. You could also try more radical improvements, such as adding tags or arbitrary properties to messages, providing folders for storage, or prioritizing different users in the message list. These are only examples, please try to come up with your own ideas. Think outside the box! If you are providing usability improvements, justify them through heuristic evaluation features or other usability principles we have learned. If you are adding new functionality, ensure that the new functionality is usable. You can reference your HW5 to avoid repetition if you raised the issue there. Create at least two different paper prototypes of your chat app.

**Deliverable:** Photos or video of your prototypes and a simple HTML page that presents them and justifies the improvements (1-2 sentences max per improvement).

Exercise 2: User testing of calculator Balsamiq/Figma mockup (15%)

For this part of the assignment you will do a user testing session of your Balsamiq/Figma calculator mockup from exercise 3 of [HW5](../hw5). The participant in your testing session does not need to be a student. It can be anyone you know including a friend or family member. Prepare for the user testing by writing a list of three tasks for your user to perform with your medium fidelity mockup. During the study, you will ask your participant to perform three tasks. Using Balsamiq or Figma you can add some interactivity to your design which will help you discover issues your users might have that involve interactions with your design. While the user is performing tasks, try to jot down notes about their behavior and questions. These will be helpful for recalling insights in your writeup. Try to avoid students from this class for your user testing session. You will get an experience closer to real user testing if the subjects are not acquainted with usability theory.

**Deliverable:** An HTML page with a short video of your user performing tasks with your medium fidelity mockup, and a write up with your three tasks, insights from the user testing, plans for changes, and raw user testing notes in an appendix at the end.

Exercise 3: HTML/CSS mockup of calculator (25%)

Now that you have iterated on your calculator design, it is time to implement a high fidelity HTML & CSS prototype. This prototype must look like your intended interface, but does not need to provide any functionality. You are free to implement more functionality if you want to get a headstart on HW8. But keep in mind the feedback you got in your user testing sessions as you add functionality and make design changes.

**Deliverable:** Your prototype of the calculator. Include a short description of how you improved your design after user testing in Exercise 3 in comments, either at the top of the HTML file, or near relevant parts.

Exercise 4: Create a bookmarklet that unmasks password fields (7%)

[Bookmarklets](https://en.wikipedia.org/wiki/Bookmarklet) are bookmarks with `javascript:` URLs that execute Javascript code on the current page when invoked. We have seen how to create one [in lecture](https://designftw.mit.edu/lectures/events/#css-removal-bookmarklet) (note that this slide is interactive — you can use it to generate arbitrary bookmarklets). For this exercise, you will create your own bookmarklet. Often, when you visit websites where the browser has saved your password, it's hard to know what your password actually is, since it shows up as •••••. Also, the browser obscuring your password is rarely needed for security, since usually nobody is looking behind your back, and the practice [actively harms usability](https://www.nngroup.com/articles/stop-password-masking/) (which dimension(s) of usability does it harm?). Some websites offer functionality to toggle between masked and unmasked password fields, but not all. However, if you inspect the HTML with dev tools, you can change `type="password"` to `type="text"` (or remove it altogether, or set it to nonsense) and it just becomes a normal, readable, text field. #### Step 1 (5%) Write a bookmarklet that does this for all password fields on a page when invoked, so that one does not need to use dev tools for it. #### Step 2 (5%) Often, after unmasking a password field, you may want to mask it again. There are many reasons for this, for example, to get the browser to save your login (browsers typically match on `<input type=password>` for that) or because someone walked in the room you’re in and you don’t want them to see your password. Adapt your bookmarklet to return password fields to `type="password"` if invoked a second time. If invoked a third time, it would reveal the passwords again and so on.

Make sure that when you return text fields to `type="password"` you do not assume that everything with `type="text"` was previously a password field.

You do not need to try and persist the changes to `<input>` elements across page loads.

**Deliverable:** An HTML page with your bookmarklet as a link that can be dragged to the bookmarks toolbar. To facilitate both iterating on code for you, and grading by the graders, please include your JS in `exercise-4/bookmarklet.js`. Then, all your actual bookmarklet link needs to do is insert a link to `http://localhost:8000/bookmarklet.js` into the page. Note that for this to work, you need to have a server running on port 8000 in your `exercise-4` directory. In your HTML page, also include a list of websites you have tried your bookmarklet on and verified it works. You should test on at least 5 websites.

Exercise 5: Create a bookmarklet that allows you to hide undesirable content (30%)

Often websites have content that you don't want to see, such as ads, newsletter popups etc. If you have access to dev tools, you can always right click on an element, select *Inspect Element*, and then hit Backspace to remove it, or just type `$0.remove()` in the console. However, most Web users cannot use the dev tools and thus are stuck with the undesirable content (AdBlock removes some of it, but what it does is not customizable) Write a [bookmarklet](https://en.wikipedia.org/wiki/Bookmarklet) that, when invoked, allows you to click on elements to remove them from the page. It should also insert two buttons at the top of the page that are always visible until the removal process is terminated: - *Undo*, which re-inserts the last removed element (you don't need to keep a stack of more than 1, though that would be a welcome improvement) - *End*, which terminates the element removal process and removes the *Undo* and *End* buttons

You should actually remove the elements, not just hide them. You can use [`element.remove()`](https://developer.mozilla.org/en-US/docs/Web/API/Element/remove) for that.

- Pay attention to visibility of system status / Learnability. The user should be able to easily answer the question *If I click right here, which element will be removed?* - Pay attention to efficiency: The user should be able to quickly remove a large number of elements. - Pay attention to safety: The user should be able to undo the last removed element - To re-insert an element that has been removed, you need to save its position in the DOM. One way to do that is to keep track of its parent and previous or next sibling (if any). - You may find [`document.elementFromPoint()`](https://developer.mozilla.org/en-US/docs/Web/API/Document/elementFromPoint) useful. See also [document.elementsFromPoint()](https://developer.mozilla.org/en-US/docs/Web/API/Document/elementsFromPoint). - Minimize side effects when the user is clicking on elements to remove them. Whenever possible, try to prevent the `click` event from propagating further or triggering default actions. You cannot fully prevent undesirable side effects, because there is no way to read what `click` event listeners the host page has assigned to an element, and because not all default actions are cancellable, but try to minimize them. - When writing CSS to be combined with a host page's CSS, there will always be edge cases where things don’t look as intended. This is ok, as long as you try to minimize these cases, and test in enough websites. We're not aiming for perfection when writing code that will be executed on websites we don’t control (such as code for bookmarklets, browser extensions, or libaries), just for code that works in a sufficiently large number of websites that it's still useful.

You do not need to try and persist the removed elements across page loads.

**Deliverable:** An HTML page with your bookmarklet as a link that can be dragged to the bookmarks toolbar. To facilitate both iterating on code for you, and grading by the graders, please include your JS in `exercise-5/bookmarklet.js`. Then, all your actual bookmarklet link needs to do is insert a script element that points to `http://localhost:8000/bookmarklet.js` into the page. Note that for this to work, you need to have a server running on port 8000 in your `exercise-5` directory. In your HTML page, also include a list of websites you have tried your bookmarklet on and verified it works (mention what types of elements you removed). You should test on at least 5 websites.

Exercise 6: HW feedback (3%)

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 `exercise-6/index.html`.