Assignment 13
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/hw13-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.
DUE DATE
Due to institue policy this homework is due at the end of class on monday. If you need an extension, please reach out to the course staff.
Exercise 1: Chat app final submission (80%)
Complete your chat application!
Please include a small writeup detailing your design decisions using language from the class, including what problem it is intended to address and how it does so. Make reference the various prototypes and user studies that you completed throughout the semester, and how they informed your design decisions.
To help you out, we have included some tips to address common issues below
Deliverable: Your chat app and source code linked in chat-app/index.html and your writeup in writeup/index.html
Exercise 2: Final User Test (20%)
Now that you have completed your chat app, you will do one final round of testing your completed implementation, just as you user tested your paper prototypes and your figma mockup.
Requirements:
- Choose three tasks to give your users.
- Run a user study with two participants. Each user should complete all three tasks.
- Make sure that your testing covers the novel features you designed for your implementation.
- Follow the same user testing procedure as in HW8
During monday's lecture you will have time to do this user testing in class with your peers. We will allocate 1/2 hour to mutual testing and 1/2 hour to completing your writeup of the results. There will also be snacks! We highly recommend coming to class for this.
Deliverable: An HTML page in user-testing with a short clips of your users performing tasks, and a write up with your three tasks, insights from the user testing, suggestions for future changes based on the user test, and raw user testing notes in an appendix at the end.
Chat App Tips
We have identified common issues we often find with chat apps and assemled a list of points you could benefit from considering. None of these are requirements for some minimum standard of goodness; they’re just directions you can consider for making your work better.
- Consider long input lines (messages, chat titles, usernames, etc.)
- Consider large numbers of chats
- Consider large numbers of messages in a chat
- See this blogpost if you are having trouble working out how to make the chat automatically scroll new messages into view
- Responsive design: unless you have a good reason that your app will only be used at one screen size, make at least some attempt to be responsive. Don't waste vast amounts of space when the screen is large, and make sure the app is functional when the screen is small.
- Recognizing links in messages and making them clickable would be nice
- Channel IDs and actor IDs are random strings that are incomprehensible to users; think about whether and where they need to be displayed. If a user needs to copy one, would some kind of button or link be clearer than selecting and copying a visible channel/actor id? Also the terms "Channel" and "Actor" are system jargon, if you n (Room ID, Invite code, etc.)
- Where can actor IDs be replaced with graffiti handles (use graffiti.actorToHandle)? Where can Graffiti handles be replaced with an editable profile name?
- Can the names and memberships and other characteristics of chat groups be changed after creation? Why or why not?
- What things are so frequently accessed that they should be visible at all times, and what things are relatively rarely accessed so that showing them all the time is using up valuable screen real estate that could be reallocated?
- If i'm looking at an overview of many chats, are there useful things to show about each---number of messages, number of members, unread status, etc.?
- it's common to have enter as a keyboard accelerator for sending a chat (with ctrl-enter to put a newline in a message)
- Users hate to lose data because of an incorrect/accidental click—can that happen during profile editing, message composition, other types of input?
- Consider supporting multiple ways of achieving the same task which may be more efficient or intuitive in different contexts. For example, if your app has profiles, consider making those profiles visitable both from a profile tab and clicking on a person’s name within a chat. If messages have a menu with functions like delete/like/etc., consider making that menu appear both on hover (for desktop) and long press (for mobile).
- Instead of delaying a UI update until data has been synchronized, consider whether you can optimistically update a user's local state immediately while synchronizing in the background (sending a message, saving a profile change, creating a new chat, etc.)
- Consider whether a feature should be available as a modal, a new screen, or something else. On mobile, creating a new chat is often a popup triggered by a "+" icon. On desktop, it often adds a new chat container to the existing list and waits for your input. Profiles are often edited in a separate screen from the main UI. Look at chat apps you use frequently for inspiration.
- It can be helpful to think of UIs as dynamic physical objects that take up space. Where does your profile screen live? Is it placed on top of the current screen? Does it replace the current screen? Do you have a header or footer that floats above your main content while the rest of it changes underneath?
- Use concepts consistently. Distinct objects in your system, like pinned messages, profiles, and folders, should typically be visually distinct. On the other hand, sometimes it's useful to group similar actions together, such as creating a new chat, contact, or group (see WhatsApp, for example).
Exercise N: HW13 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 HW13 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.