Assignment 7
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/hw7-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 -N: HW5 Retrogrades (Optional)
Now that you've received feedback on some of your assignments, we are offering a (completely optional) opportunity to improve some of your past work and resubmit it for a retrograde. Your final grade on an exercise will then be the average of the original grade and the retrograde. For example, if you got 10 points on the original exercise and 20 points on the retrograde, the final grade we'd put down for the exercise would be 15 points. We will never give you a lower grade than you got originally.
Not all exercises are eligible for retrogrades, either because they are part of multi-week assignments already or because we don't think fixing up that exercise provides a good learning opportunity.
This week, you may request retrogrades for any or all of:
To submit a regrade, simply commit and push additional changes to the relevant exercise in that week's repo. Retrograde submissions are due with the assignment where they are offered.
Exercise 0: Hall of Fame Shame (Participation)
Over the rest of the semester we would like you to submit four entries to the UI Hall of Fame/Shame. Submitting an entry should be pretty simple, just write a couple short paragraphs about the UI in question and what makes it usable or unusable. Make sure to use precise terminology from class and the Design of Everyday Things.
We suggest you submit to the Hall of Fame/Shame whenever you encounter a particularly good or bad UI. The UI can be either virtual or physical.
Exercise 1: Paper prototype concepts for chat/IM apps (40%)
In this homework, we continue along the iterative design process path for your chat/IM app, a process we started in HW5.
In HW6, you did needfinding and idea generation. In this homework we will focus on paper prototyping and user testing.
For paper prototyping to be effective, it is important to create several designs and iterate on them. Therefore, we want you to create at least two substantially different paper prototypes of your chat app. These should be two different prototypes about the same problem.
You do not need to prototype everything in the chat app, but you should prototype the features that differentiate your app from other chat apps, and enough other elements to let users carry out tasks that leverage your novel features.
Your prototypes should be "interactive": not just sketches of entire screens, but multiple screens and paper pieces that allow you to modify the screens based on user input. in HW8 you will test your prototypes with actual users.
To see how to create and use these "interactive" paper prototypes, watch at least minutes 10-23 of this video of a paper prototyping user test from the Nielsen Norman group. We encourage you to watch the rest as well to learn more.
Deliverable: 2 prototypes, each with:
- Photos of key prototype "screens" showing your novel features and a simple HTML page that explains them and justifies the improvements (1-2 sentences max per improvement).
- A video of you interacting with your "screens" (as in the Nielsen Norman group video) to carry out the tasks you expect users to perform with your interface. The prototype should be clearly visible in the video, as well as your hands interacting with it.
Exercise 2: Drag & Drop to reorder your to-do list (40%)
In this exercise, you will implement drag & drop to reorder the "Vanilla" JS to-do list we worked on in Studio 7 (link will become available after 1:30pm on Friday).
You will use the HTML5 drag & drop API.
You are not allowed to use a library for this, you need to implement it yourself.
Alternative implementation: Raw pointer events
We recommend using the HTML5 drag & drop API, but if you want to use raw
pointerdown,
pointermove, and
pointerup events instead,
you can do so.
Do note that this is lower level, so you need to implement certain things yourself that the drag and drop API handles for you. Some of these things are:
- You want to listen to
pointerdownon the dragged element, but you want to listen topointermoveandpointerupon the entire document. Otherwise moving the mouse too fast would cause bugs where your implementation doesn't realize the mouse button has been lifted, so you move your button around and the element is still moving. - You want your code to not confuse a click and a drag.
Your to-do list app in todo/.
If the functionality is not finished during studio,
you would need to implement that too, following the studio instructions.
Exercise 3: Create a bookmarklet that unmasks password fields (20%)
Bookmarklets are bookmarks with javascript: URLs that execute Javascript code on the current page when invoked.
We have seen how to create one in lecture
(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 (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 (10%)
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 (10%)
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.
Bookmarklets have to be encoded in a specific way, and a bookmarklet generator such as this one can do the job for you.
To facilitate iterating on bookmarklet code without having to package it up as a bookmarklet every time,
you can include your bookmarklet code in a separate file (e.g. bookmarklet.js),
then create a bookmarklet that loads that file from localhost (e.g. http://localhost:8000/bookmarklet.js).
Then you are just editing a JS file and reloading the page to test your bookmarklet and iterate on it.
Please note that this is for your convenience: the code you submit cannot depend on a particular localhost setup,
and thus should include the bookmarklet code directly in the bookmarklet link.
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: HW7 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 HW7 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.