Assignment 8
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/hw8-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: Additional paper prototype (20%)
For the problem you addressed with your chat app prototype in your HW7 Exercise 1, come up with another design that is substantially different. The requirements and deliverable are the same as in HW7 Exercise 1 (except we are asking for one prototype, not two).
Some students interpreted HW7 Exercise 1 as asking for two paper prototypes of two different problems. While this was not our intention, we will not penalize such submissions. In that case, you can select one of the two problems you prototyped in HW7 Exercise 1 and come up with a new design for it. Then you will use these two prototypes for user testing in the next exercise.
Exercise 2: User testing of your Chat/Messaging App paper prototypes (40%)
For this exercise you will be user testing your three Chat/Messaging App paper prototypes from HW7 Exercise 1 and Exercise 1. You should choose a "between-subjects" design for your user testing, meaning that each participant will only use one prototype for each task. However, the same participant can (and should) use different prototypes for different tasks.
You should test with at least 3 participants, but you can test with more if you want. Participants should be part of your target audience. Due to the nature of paper prototyping, sessions cannot be conducted remotely. You will also be video-recording these sessions.
First, create a list of three non-trivial tasks. For each task, include a (1) short title, (2) a succinct goal (i.e., in words that can be given to the user), (3) a rationale for inclusion (e.g., what you expect to discover or understand about your design by testing it with a user, compared to analyzing it through a cognitive walkthrough that you conduct yourself).
Make sure the order of the tasks makes sense, and the transition from a task to the next is also non-trivial.
Then, find participants and obtain their consent for participating in your test and the recording session. Prep them by explaining their role (and how you’ll use the test results) and the general purpose of your app. Reassure them that you are testing your interface ideas, not them, so if they fail it's not their personal failing, but a problem with the interface (thus, an opportunity for you to fix it!).
During the study you will ask your participant to perform the tasks. Your paper prototype is static but you can simulate interactivity for your test subjects by explaining what would happen if it were interactive. Your explanation can be verbal, but it can also include physically modifying your paper prototype using post it notes, index cards, or pencil markings. During the tasks, you cannot give any hints or help to the user (you must resist the temptation!). While the user is performing tasks, jot down notes about their behavior and questions. These will be helpful for recalling insights in your writeup. We strongly recommend you do not rely on rewatching the recordings to jot down notes, but jotting them down as they happen.
The participant in your testing session does not have to be a student. It can be anyone you know including a friend or family member. You can even approach a random person and ask if they want to participate in your study (though they must be a part of your target audience).
If you only have two prototypes (see note in Exercise 1), then instead of three participants, you will need four.
Deliverable:
An HTML page in user-testing with a short clips from each of your users performing tasks with your paper prototypes,
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.
The videos should not contain the entire study session, we only need a short clip (~1 minute per user).
You should not show the user's face on the videos, only their hands using the paper prototypes.
Exercise 3: Create a bookmarklet that allows you to hide undesirable content (40%)
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 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() 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()useful. See also document.elementsFromPoint(). - Minimize side effects when the user is clicking on elements to remove them.
Whenever possible, try to prevent the
clickevent from propagating further or triggering default actions. You cannot fully prevent undesirable side effects, because there is no way to read whatclickevent 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 libraries), 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. The HTML page should also display your bookmarklet code, with syntax highlighting (you can use Prism for that).
In your HTML page, also include a list of URLs you have tried your bookmarklet on and verified it works. You should test on at least 5 websites.
Exercise N: HW8 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 HW8 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.