6.4500 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-YEAR/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: Setup Github Pages (10%)

As you work towards completing your chat app, it will be useful to have a live version of the app that you can visit on other devices or share with your friends to test. We will be using Github pages to host your app, which is free and your app will update whenever you push new code to Github.

Follow the Github Pages instructions here and choose "start from scratch" for appropriate instructions. You will need to create a new public repository for your chat app (separate from the homework repository), push your chat app code to that repository, and then enable Github pages for that repository. Once done, you should be able to visit your app at https://<your-github-username>.github.io/<your-repo-name>/.

Note that after the class if you want to continue using your chat app, you could choose to buy a custom domain which you can use instead of Github's domain.

Exercise 2: Add a component to your chat app (35%)

Choose one aspect of your chat application to turn into a reusable component. This can be a feature you already implemented or a new feature you want to add. This component must be reused in at least two different places in your app. Make a short writeup describing where the component is used and how it works.

While, we recommend that you break your application out into components representing entire pages, as you did in studio, that is not what we are looking for in this exercise. Instead, we are looking for you to use components to represent repeated or recursive features of your app. Some examples of features that are good candidates for componentization include:

• Recursively threaded comments
• A "name" component to display the user's chosen name (see the profile exercise below)
• A "like" or "reaction" component to add to different messages.
• A "pin" button to pin a message to the top of a chat
• A button to "friend" a user that can be used on their profile or within a chat

Exercise 3: Adding a profile to your chat app (55%)

The next milestone we would like you to complete in your chat app is some sort of profile creation. Profiles are common to most chat apps and so we suspect that you will want to include them in your own applications, however if your app does not involve profiles, feel free to reach out to us and we can work out a different milestone for you.

Your profile can include whatever information you want that makes sense for your application: a name, pronouns, a profile picture, a bio, a status, interests, etc.

In terms of implementation, a profile object would look something like this:

{
	name: "Theia",
	pronouns: "she/her",
	describes: "https://theia.example.com",
	published: 1745448976510
}

You are free as always to add new object properties to the as you see fit, or break out the profile into multiple different objects. In most cases it would make sense for the profile object to be included in the channel named by the actor's URI, $graffitiSession.actor which is "https://theia.example.com" in the example above. Alternatively, a user might be able to set a different name for different chats, in which case it would make more sense for the profile object to be put in the chat channel.

Note that depending on your design, users may not be the creators of their own profiles, hence the importance of the describes property. For example, traditional contact list designs allow users to create profiles for each other, in which case the describes property would point to the actor the contact is being made for rather than the actor the contact is being made by. Some applications fuse elements of profiles and contact lists, where the users create a profile for themselves, but can set custom "nicknames" for each other.

Additionally, you may (or may not) want your app to preserve a history of profiles over time. For example, on Facebook, you can view a person's profile picture history. The published property can help disambiguate which profile object is the most recent.

Some aspects of the users profile may be settings that are either uninteresting to other users or not appropriate to share at all. For example, if your application helps users buy and sell local goods, like Craigslist or Facebook Marketplace, you may want users to specify their address in their profile so the app knows where to display listings, but you may not want that address public, for privacy reasons. To achieve this, remember that you can create private objects, by setting an allowed field on your objects. Setting an allowed field to [] will only let the actor who created the object see it, which is useful for storing private settings:

{
	value: {
		location: "Cambridge, MA",
		describes: "https://theia.example.com",
	},
	channels: ["https://theia.example.com"],
	allowed: [],
}

Finally, consider whether you want there to be a special "wizard" for creating a profile when a user first creates an account, to help them fill out their profile.

While not required, you are welcome to create a small writeup describing your design decisions for for your profile editor.

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.