CSE 370 - Applied HCI

Overview

The web is the dominant medium for development, and has a wide range of capabilities. For those among you who pursue careers in industry, some amount of web programming is almost certainly in your future, even if you also do engineering, mobile, or desktop development. This project will explore designing a social media platform for the web and mobile. It will also explore other facets of the software development lifecycle as they interact with design, including requirements, test methods, user testing, style guides, and presentation. There will be multiple iterations of development, demonstrating the cyclic nature of design and improvement based on feedback. This is a team based project, and you will be interacting with potential users of the product to help define and evaluate the results.

Resources and Lab Setup

Version Control

We have created a team github site for your project. This should serve as evidence of revisions based on feedback during the development cycle, and of compliance with your team contract. We have it set up so that the repository remains private to your group.

Deployment Environment

Accounts for each team have been set up on webdev.cse.buffalo.edu, the class web server.

Team	URL
Sedentary Sprinters	https://webdev.cse.buffalo.edu/hci/teams/sprinters
2 Piece	https://webdev.cse.buffalo.edu/hci/teams/twopiece
Craz3	https://webdev.cse.buffalo.edu/hci/teams/craz3
Jam	https://webdev.cse.buffalo.edu/hci/teams/jam
The Missing Fifth	https://webdev.cse.buffalo.edu/hci/teams/tmf
Zoomers	https://webdev.cse.buffalo.edu/hci/teams/zoomers
UI Maxxing	https://webdev.cse.buffalo.edu/hci/teams/uimax
Team8s	https://webdev.cse.buffalo.edu/hci/teams/team8s
200 OK	https://webdev.cse.buffalo.edu/hci/teams/ok
Ben 10	https://webdev.cse.buffalo.edu/hci/teams/ben10
Won One	https://webdev.cse.buffalo.edu/hci/teams/wonone
Dawgz	https://webdev.cse.buffalo.edu/hci/teams/dawgz

Technology Frameworks

The web application will be developed using the React JS framework. You may also use any other non-UI javascript libraries that are available via CDN, but note that you’re on your own for tech support if you choose to use third party tools. You also may not use any libraries that “do the work for you” like bootstrap, material design, etc. If you are unsure, please ask.

API

An API will be provided for you to use to pull and push dynamic content. No direct database interaction is necessary, this will be handled by the API. Input and output will be handled via JSON objects and URL parameters. While we have made every attempt to test out the APIs, there is the definite possibility that there are still some kinks left to be worked out, especially since we make revisions every year based on prior feedback. There is a swagger API test harness that you can use to exercise the endpoints outside of your code, available here:

https://webdev.cse.buffalo.edu/hci/api/swagger/

Pick your tenant id (this will be the same as the end of the URL above) in order to interact with your specific data.

Starter Code

We have created your repo with a clone of the master repo available at https://github.com/CSE370HCI/hci-social-frontend as a test harness for the API layer, with example calls to the various API endpoints.

Browsers

Cross browser testing will be a requirement, so finding an environment (or environments) to test with Chrome, Firefox, Safari, and IE/Edge is necessary.

Requirements and Deliverables

Platform Functionality

While the way in which it accomplishes each feature is up to you, your social media platform must (at a minimum) support the following user stories. There is considerable flexibility in the way that you implement these features in order to have it match your platform’s goals and objectives. For example, followers on instagram, friends on facebook, and connections on linkedin are all examples of relationships that could be implemented for relationship management that have different attributes and impacts.

Account Creation and Management

As a social media participant, I want to be able to register for a new account using a unique email address and username so that I can use the application
As a social media participant, I want to be able to reset my password if I have forgotten it via an emailed link so that I can regain access to my account at any time
As a social media participant, I want to be able to edit my profile to update any and all of my personal information so that I can keep it current
As a social media participant, I want to be able to maintain a profile picture or avatar to represent me in the platform so my connections can recognize my posts
As a social media participant, I want to be able to remove my account and have it delete all of my posts to ensure my data privacy if I choose to discontinue using the platform

Content Creation and Management

As a social media participant, I want to be able to create content to share it with my connections or with the world so that other users can see and interact with it
As a social media participant, I want to be able to comment on others content to express my opinions of it
As a social media participant, I want to be able to edit or retract my content to remove items that I no longer want to share
As a social media participant, I want to be able to decide who my content is shared with, to preserve my privacy

Content Consumption

As a social media participant, I want to be able to see content generated and shared with me so that I can stay connected with my contacts.
As a social media participant, I want to be able to block users or content that I find objectionable so that I’m not exposed to objectionable content
As a social media participant, I want content to be relevant to me, and appear to me in a way that optimizes for that relevance, so that I can see the things I consider most important
Relationship Management As a social media participant, I want to be able to connect with other users, so that I can create a network of connections

If you are using a friend model :

As a social media participant I want to be able to accept or reject connection requests from other users, so I can moderate my network of connections
As a social media participant I want to be able to block, suspend, or disconnect from other users who I am connected with, to keep my connection network current and relevant to me

If you are using a follower model :

As a social media participant I want to be able to stop following another user, so that I can keep my connection network current and relevant to me
As a social media participant, I want to be able to see all the other users that are following me so I can keep track of my social network

Team Specific Functionality

Your team must write a minimum of five additional user stories that are particular to your social media platform and demographic. These may be related to content moderation, chat, offline communication via email, data analytics, etc - but the stories must fit the context of the problem that you are trying to solve, and be non-trivial in nature (as determined by your project manager).

Wireframes

Sprint one will be primarily focused on producing a high fidelity prototype of your application using Figma.

The prototype should have both a mobile and a desktop layout
All application functionality should be represented (all required and custom stories)
All navigation in the prototype should be interactive
All actions (buttons, forms) should simulate interaction - placeholder text or images can be used
Simulated interaction should include examples of error handling / confirmation dialogs

Team Profiles

Your web application will include a page for each team member with their profile. Each profile needs to include at least a paragraph of text about the user, and a picture that represents them in some way. These will be part of the first programming deliverable, and individual checkins for the profile page files will be examined. They must be deployed to the class server to get credit.

Team Contract and Project Description

Create a plain text document that contains the following information, and check it in to your github repository, named ProjectDescription.txt - Team name - URL of your GitHub repo - URL of your ZenHub board - Describe your team's alternate dispute resolution approach. Your team will be required to use these when you just cannot agree on a decision. Your mechanism must be fast, simple, and as silly/fun as possible to limit the bad feelings that can result. Voting is NOT allowed for this. - Write 1 or 2 paragraphs describing the completed version of your project. (Developing estimates is very, very hard and takes years to do well. These descriptions are only to help your project manager understand your goals and prioritize the work to be done). - Write 1 or 2 paragraphs describing a typical user of your project and how they would use it.

Nontechnical Requirements and Deliverables

Requirements Management

We will be using Trello to create task boards, and manage tasks for the development sprints during the semester. You will be responsible for managing the status of these tasks and completing them as assigned by your project manager. Completion of your assigned tasks will form the individual portion of your grade for the project. Each task will include test criteria, and be demonstrated to the project manager before being counted complete.

Style Guide

The style guide is your instruction set to future developers on how to extend your application while maintaining the overall look and feel - the “branding”. Your style guide must be a web page (HTML or a react component) that is deployed with, and accessable from, your web app. The style guide must contain (minimally)

Fonts and Font Sizes, and where to use them
Layout and navigation templates
Color palette and use
Size/position/interaction guidelines for popups/modals
Treatment of feedback (both success and error conditions)
Methods for inline help

Examples of each of the elements above must be included, and relevant code snippets (CSS/HTML/JS) should also be included with the example.

Usability Scripts and Results

At the end of each sprint, you will need to execute a usability test with at least 3 people who are NOT in this class who will be potential users of the new site. You need to submit a writeup that contains

The Script you used
The results of the test (links to videos of the test execution for each user)
What problems were found
What changes you will make based on those findings

The usability tests will be due the week after the sprint ends, to allow you to test with the completed sprint deliverables.

A/B Test criteria

No team lands on the best approach for all of the elements of a project the first time through! As part of this project, you need to pick one feature that could be implemented two different ways (different interaction styles? Different graphics? Different tags or comment styles?) and implement that feature both ways. During usability testing for sprint 3, your script should have the user test both different ways, and collect feedback on which way is better. Your final project should incorporate the way that was selected during usability testing.

The guidelines that we will be using to assess the A/B Test criteria are as follows:

The functionality should have two distinct options that are both reasonable implementations (no option 1 = click a button and option 2 = type 432 characters in ancient greek).
The functionality should be one of the items from the requirements document
The two approaches should demonstrate that they achieve the same goal, and that goal should be specifically stated
The two approaches should have some way to measure which one is better. Ideally this is an objective metric, but if that is not possible the way you collect subjective metrics needs to be defined

Error Handling

Your application needs to provide context sensitive guidance / error handling. Error handling will be assessed on the following

All inputs should be validated
All help should be context sensitive, appearing as close to the area needing to be addressed as possible
Progress should never be lost; errors should not remove entered data
Error messages should be descriptive and tell the user what the issue was and how to correct it.
In the event that feedback is part of the game mechanic and therefore does not follow these rules, it should have an escalating path to resolution (i.e. hints)
Using the javascript alert function for error handling will receive 0 points

Adaptive/Responsive Design

All functionality should be retained if the site is viewed on a mobile device, without scrolling horizontally. Changing screen width and height should result in the screen changing layout as appropriate to avoid scrolling or breaking functionality. Navigation can change, but still needs to function at mobile layout resolution.

Universal Design

Where possible, your application should follow universal design principles. If there are game mechanics that do not allow for universal design, these should be noted in your presentation, with a justification for why the game mechanic requires the exception.

Page elements should have unique IDs
All images should have descriptive alt tags
All form elements should have corresponding label elements
All links should have descriptive text, or an image with descriptive text in the alt, describing where that link goes.
Hierarchy should be established using the <h1> through <h6> tags; no skipping levels.
All color cues should have alternate non-color specific cues to provide backup for colorblind users
HTML must have valid syntax
Pages should have a default language associated with them
Contrast between foreground and background should be sufficient for visibility

Presentation and Demo

Your presentation will be assessed on two sets of criteria - your presentation materials and the presentation itself.

For the materials, you should have a slide deck (powerpoint or google slides) that discuss the following

What the goal of your project was
What the main features of your application are and how they relate to that goal
What issues you faced in development and how you resolved them
What things weren’t completed, were placeholders, or are good candidates for future enhancements

The deck should not get too technical (no source code!) but rather should be a high level discussion of your experience.

For the presentation and demo, you should aim for about 10 minutes maximum. Each person on the team should have a chance to speak, and after the presentation you should demo the main aspects of your application live.

For the presentation you will be evaluated on

Speaking clearly, and loudly enough to be heard
Demonstrating familiarity with the application in the presentation
Each team member sharing the presentation time more or less equally
Demo not crashing!

Peer Evaluations

Teamwork will be critical to successfully completing this project on time. Each team member will have the opportunity to assess the performance of her/his teammates, and the average scores will be used to determine the value of the peer evaluation component. There will be a peer evaluation each sprint, so that feedback from these evaluations can help motivate the team in following sprints

Submission and Scoring

There are several deliverables for this project, and they will be due in sprints. Lab writeups for non technical deliverables will be submitted to UBLearns, along with links to any technical/online content.

Sprint 1 (Graded week 5)

Specific Deliverables	Rubric	Points
Team Contract and Project Description	Team Contract	3
Individual profile page deployed to the class server	Profile Page	3
Base code from github deployed to the class server	Deployment	3
Sprint Grading	Sprint 1 Rubric	24
Usability Test	Usability Testing	3
Team Meetings	Meetings	6
Total		42

Sprint 2 (Graded week 8)

Specific Deliverables	Rubric	Points
Style Guide	Style Guide	3
Sprint Grading	Sprint 2-4 Rubric	12
Usability Test	Usability Testing	3
Team Meetings	Meetings	9
Total		27

Sprint 3 (Graded week 11)

Specific Deliverables	Rubric	Points
AB Test	AB Test	3
Sprint Grading	Sprint 2-4 Rubric	12
Usability Test	Usability Testing	3
Team Meetings	Meetings	9
Total		27

Sprint 4 (Graded week 14)

Specific Deliverables	Rubric	Points
Sprint Grading	Sprint 2-4 Rubric	12
Usability Test	Usability Testing	3
Team Meetings	Meetings	9
Total		24

Final Review (Graded week 14)

Specific Deliverables	Rubric	Points
Style guide is followed throughout the application		3
Presentation materials (slide deck)		3
Presentation preparedness and delivery (all team members should participate)		3
Universal design guidelines followed		6
Web app uses responsive design		9
Context sensitive guidance messages are provided where appropriate		6
Subjective aesthetics		3
Content creation stories are all satisfied		3
Content consumption stories are all satisfied		3
Account creation stories are all satisfied		3
Relationship management stories are all satisfied		3
All relevant APIs have been used to satisfy the corresponding stories		9
Custom User Stories		15
Total		69

Extra Credit

Final scoring will take place during the project demos (see class schedule). Volunteering to be in the first round of project demos on will gain 10 points extra credit. If there are no volunteers, distribution of demos will be random, and no extra credit will be awarded. If there are more than required, selection from the groups volunteering will be random, but credit will be granted. Similarly, volunteering to go on the second day will gain 6 points extra credit, with the same backup plan as for day 1.

Any teams who wish to exceed requirements in an interesting and useful way are also free to propose their own extra credit possibilities are free to do so, and the number of extra credit points will be determined based on the complexity of the suggestion.