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/hw11-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: Adding animation on your chat app (20%)

Especially in a chat application, animation can be used in a variety of ways to improve usability and delight users. Make at least 5 improvements and point them out in a short writeup (~1 sentence for each improvement). Please include (short!) videos of these animations in your writeup. Given that most effective UI animations are shorter than 500ms, these videos should not be longer than a few seconds.

If you have already included animation on your website that meets the criteria we've discussed in class for animations that communicate state changes without getting in the user’s way, you can just write about these in the short writeup, you don't need to come up with new ones.

Exercise 2: Beginning to add Prototype Functionality using JS for Chat/Messaging App (80%)

In HW 10 Exercise 2 you worked on improving the usability of the basic chat template that we provided to you. This week we want you to add three new features your to chat app.

1. Add read indicators to messages. (25%)
2. Add the ability to reply to a message. (25%)
3. Let users choose a profile picture and display the profile pictures of other users (30%).

These features are generic enough that they will probably work with your novel chat-app design even if you didn't include them in it originally. If for some reason you don't think these features would fit, let the staff know and we can find something to work within your design that would meet the same teaching goals.

As a reminder you can find a detailed description of the chat app template in the README included with the starter code. You should also check out the documentation on Graffiti's vanilla JS library and the Graffiti Vue plugin. Finally, the Vue documentation will also be useful to look over.

Read Indicators (25%)

In studio this week, you created a Like button for messages. Adding read indicators is actually not that different. Imagine that when you looked at a message, your app automatically "liked" it. Then it would be pretty easy for your app (and other people in the chat) to tell which messages you've read.

Rather than posting Like activities, you will post Read activities, which simply have a different type:

{
  type: 'Read',
  object: <The id of the message you're reading>,
  context: [ <The id of the message you're reading> ]
}

In some applications, like Facebook messenger, read indicators are shared with other people; these are often called read receipts. In other applications, like email, read indicators can only be seen by the recipient. And some applications, like iMessage or Signal, allow you to toggle whether your read receipts are visible to others or not. You can choose which way you would like your read indicators to work: public, private, or (the most work) toggleable.

By default, Graffiti objects are public. You can make an object only visible to the creator by making it "bto" an empty list of recipients. For example:

{
  type: 'Read',
  ...,
  bto: [] // Only the creator can see this object
}

That's basically how you can implement read indicators. But in addition you'll also need to design a way to display this information to the user. That specific design is up to you. Just make sure there is some way that appropriate users can tell which messages have been read.

Replies (25%)

A reply is basically a Like with text added to it. Just as with read indicators, start with the like data model but modify the UI to be appropriate for text replies. For example, you could put replies in their own collapsible thread, or you could keep the conversation single-threaded and display a snippet of the replied-to message with each reply. Feel free to be creative!

A reply object is similar to the "Note" object used for messages but with an extra field, inReplyTo.

{
  type: 'Note',
  content: <The reply string>
  inReplyTo: <The id of the message you're replying to>
  context: [ <The id of the message you're replying to> ]
}

Check out the message sending form and the sendMessage function in the template code to see how regular message-sending happens.

Media (30%)

In studio, you added the ability for users to send pictures to each other. You're now going to let users add a profile picture to their account and display the profile pictures of other users.

Read through the Name component in the template code. This component is what handles setting and displaying names. You're going to make a similar component for setting and displaying profile pictures. The resulting Profile object will look like:

{
  type: 'Profile',
  icon: {
    type: 'Image',
    magnet: [magnet link of uploaded image]
  }
}

Recall that Graffiti provides two methods to interface with media: store and fetch which you can read more about at the end of the vanilla Graffiti docs. These functions are asynchronous just like the username resolver functions you dealt with in Studio 10.

The workflow for setting your profile picture will go something like this:

• User uploads a file using a File selector
• Call $gf.media.store on the uploaded file and await the result, which is a special type of link called a Magnet link.
• Post a JSON object containing the magnet link using $gf.post. Use an appropriate ActivityPub property like image to associate the link with the profile.

The workflow for displaying a profile picture will go something like this:

• The user retrieves a Graffiti user profile object that references an image magnet link.
• Call $gf.media.fetch on the magnet link and await the result, which is a Blob.
• Create a local URL for that blob with createObjectURL
• Display the file by assigning the src property of an appropriate tag (e.g. <img>) to the local URL you generated.

Note that Graffiti stores media using WebTorrents. This is a peer-to-peer file-sharing protocol which means when you "upload" media, it is being served directly from your computer rather than a remote server. Anyone who downloads the media also acts as a server of the content - the more people that view a particular media file, the more people there are to download that media file from.

This has the benefit that there is no restrictions on how much you upload since you and your peers are the ones responsible for hosting it. However there are some restrictions:

• When you close the app, you stop serving/"seeding" files. If no one is seeding a file it can't be downloaded.
• Media transmission can sometimes be slow, especially when you first load a page.

While these restrictions are not the best for usability, we will not judge you for them since they are inherent to the infrastructure we are providing you. However, the usability of your app can vary a lot based on how and whether you communicate current state to the user, and that is in scope for this assignment.

Exercise N: HW11 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 HW11 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.