akshantjain / cs422project Goto Github PK

Initialise the project repo with react and the required dependencies

GR0 - Problem Statement

The heart of this course is a semester-long project, in which you will design, implement, and evaluate a user interface. User interface design is an iterative process, so you will build your UI not just once, but three times, as successively higher-fidelity and more complete prototypes. In order to have time for these iterations, you need to get started on the project as early as possible.
Each project group should consist of 5 people. In the event the class is not divisible by 5, the instructor will approve which groups will have a 4 members.

Choosing a Problem

For your project, you will choose a problem faced by some user population, and then design and implement a user interface to address that problem. Note that the problem should come first; try to avoid having preconceived notions about the solution until you've at least understood the problem.

You have a lot of freedom in choosing your problem topic. However, you will learn the most from this project if you stretch yourselves into unfamiliar areas of the design space. So we require that you design for somebody else. Choose a problem faced by a user population that nobody in your group belongs to. If you design for somebody much different from you, you will have to learn more about your users and their problems, you will have to challenge your assumptions, and you will have to be more creative in your designs. Examples include people with different roles (diving coaches, singers, mothers), different capabilities (children, elderly, people with disabilities), and different contexts (windsurfers, rock climbers, buskers). Note that your chosen user population must be reasonably available to you -- you will have to interview and observe them for this assignment, and you will have to do user testing with them later in the semester.

Examples of some projects that looked at interesting user populations include:

ElderConnect (for older people),
CheckIn (for parents and kids),
VoiceComposer (for composers),
Musical Sketches (for music students).
SAGE2 Classroom Edition (for instructors)
"Bachao" - Your personal safety application (for campus safety)
Immigrant News (for undocumented immigrants)
SONIFY (for visually impaired users)
re:Linked (for mothers who want to return to the workforce )
User Observation and Analysis

In order to refine your understanding of the problem you have chosen, you will interview at least three users in your target population who face the problem you are tackling. Observe them dealing with the problem in their real environment, and take notes about what you observe. Ask the participants to perform their tasks as realistically as possible, while talking to you about it as appropriate. Afterwards, spend 10 minutes interviewing each participant about the activity that you observed.

Using your observations, and the results of your interviews, you should then refine your problem statement, and analyze your problem, by identifying user classes and goals. A user class is a subset of the user population that may be expected to use the system in a different way. Note that a single user may fall into two classes, if they play distinct roles at different times. Be aware that generic terms such as 'power users' and 'novices' are not usually helpful. The goals should be high-level tasks that are associated with the problem. You should identify at least three goals; if you cannot, your problem may be too small to serve as a good project, and you should rethink it.

Deliverables

Sign up as a team.

Your TA will create groups in Piazza accordingly.

Create a draft of your problem statement in a Google Doc (max. 1 page). Add the TA and instructor as collaborators.

You are expected to refine this over the course of the interviews and to include a more polished version in your report.

Google Doc Project Report. You will be keeping track of your team's work in a google doc, which you will update with each group assignment. By the end of the semester, your google doc will constitute the final report for your project. A link to your doc should be made accessible from group sign up page.(Be sure to use your UIC account)

Create a project page with the following sections:

1. Group members. A list of your group members. Students who are not registered for credit are not permitted to participate in the group project. All members of your group must be registered for the class by the time this assignment is due.
2. Problem statement. Briefly state the problem(s) that your project will seek to solve. Take the user's point of view. Consider what the user's goals are, and what obstacles lie in the way. Do not talk about any solutions here.
   Complete and submit the assignment by 23:59 CST Monday September 14th.

GR3 - Paper Prototyping

In this group assignment, you will do your first implementation of your term project, as a paper prototype.

You should do at least two rounds of testing, each round involving at least three users. After the first round, you will revise your paper prototype to address the critical usability problems that arose and explore possible design alternatives. You will have to find users outside class as well as ask classmates to complete this assignment.

Preparing for Testing

Before testing your prototype, you should:

• Build your prototype. Draw the static background, menus, dialog boxes, and other windows. Decide how to implement the dynamic parts of your interface. Hand-sketching is encouraged. You don't have to prepare every possible screen in advance; it may be much easier to write responses on the fly.
• Prepare a briefing for test users. This should be at most a page of information about the purpose of your application and any background information about the domain that may be needed by your test users. These are your notes for the briefing, so make them short, simple and clear, and not dense, wordy paragraphs. This is not a manual or a quick-reference card. It should not describe how to use the interface.
• Write your scenario tasks on separate index cards. Your scenario should have involved at least three tasks. You should write these tasks down to give to your users. Just write the concrete goal(s) of the task (e.g. "buy milk, tomatoes, and bread"). Don't write the specific steps to follow, since that's for your users to figure out. The tasks should be brief, roughly 5 minutes to run.
• Choose roles for your team members. One person must play the computer. The other team members will be observers. It's not necessary to have a facilitator for these pilot tests. It may be useful for you to swap roles after every user on during the testing sessions so that each of you gets a chance to try each role, but decide how you'll do it in advance.
• Practice running your paper prototype. Every team member should practice playing the computer, learning the steps involved in making the prototype functional, such as re-arranging pieces and writing responses. It isn't important to be fast, just competent and confident. A few trials are enough. Make sure your prototype can handle the tasks involved in your scenario.

Running the Tests

When you run your prototype on a user, you should do the following things:

• Brief the user. Use the briefing you wrote up to describe orally the purpose of the application and background information about the domain. Don't waste too much time on this: 1 minute should be enough.
• Present one task. Hand the index card to the user and let them read it. Make sure they understand the task.
• Watch the user do the task. Take notes from your observations, keeping an eye out for critical incidents.
• Repeat with the other tasks. Run as many tasks on the user as you have time for.
• Bring extra materials to your testing sessions. Having extra blank Post-it notes, correction tape, and index cards on hand will help you improvise if a user does something unexpected, or help you make small fixes to your prototype between users.

Serving as a User for Your Classmates

During testing sessions, when you are serving as a user, you should:

• Relax and enjoy yourself. You're not being tested -- the interface is. Part of the point of this experience is to feel what it's like to be users in a user test, so that you can empathize with them.
• Be cooperative. Don't be intentionally stubborn, e.g. looking for Exit everywhere but the File menu. Interact with the interface as you would if you were really using it.
• Think aloud. Help the observers understand what you're thinking by verbalizing your thought process. "Let's see, I want to enter this bottle of milk, so where's the scanner... oh, here it is. I'll scan the bottle like this, oops that didn't work, let me find the barcode..." You get the idea.

Deliverables

Google Doc Project Report. Under the section "GR3 Paper Prototyping" add the following sections:

• Images of your prototype. Digital photos/images of the pieces of your prototype. Show the prototype in interesting states; don't just show a blank window. Although you will iterate your paper prototype during this assignment, the photos only need to show one iteration. Ensure the quality of these photos is high enough so that you can actually see the features of your paper prototype! Smartphone images are often not high enough quality/blurry/too small. You can produce high quality images by scanning your prototype using the scanners in the library.
• Briefing. The briefing you gave to users.
• Scenario Tasks. The tasks you gave to users, as you wrote them on the cards.
• Observations. Usability problems you discovered from the testing. Describe critical incidents encountered by the users, but don't record users' names. Record these as a series of high-level takeaways, focusing on the usability problems you saw, rather than what each participant did. For instance, you might describe how you had some learnability issues with your prototype, as evidenced by users B and C clicking all of the menus to try to find option X.
• Prototype iteration. You did multiple rounds of paper prototyping. Please state the number of iterations you did, the outcome of each iteration, and the number of users tested in each iteration. Describe how your prototype changed between those two rounds.

Complete and submit the assignment by 23:59 CST Monday October 19th.

GR5 - UI Development

In this group assignment, you will build a working implementation of your term project.

What you'll do

By the deadline, your implementation should be complete in the sense that you are ready to test users on the tasks you used for your paper prototype. Your implementation should have a fully functional frontend, with live user interactions. However, your implementation cannot have a server-side component. You can use hard-coded responses, browser-level storage (e.g., cookies or HTML5 local storage), or data APIs (e.g., Firebase), but cannot have your own backend (e.g., Django backend, Rails backend, or MySQL).

A complete backend is beyond the scope of this class, and we strongly encourage everyone to gain a frontend UI implementation experience.

During the project discussion, each group will demonstrate their implementation to the teaching staff. You will have a 10-minute time slot. Within this time, you will have to:

• brief us about your application's purpose and user population
• take us on a guided tour of the interface
• let us try the interface for ourselves
• answer our questions about your design decisions and development process

You should bring your own laptop. Take notes during the discussion of your presentation and put the important ones in your report.

Deliverables

Google Doc Project Report. Your report should include a URL of your working project (website, GitHub, etc.), and an indication of the browser/OS combination expected. Each member of your group should briefly indicate what parts of the prototype they contributed. Also describe the feedback you got in your project discussion sessions, and how you incorporated it into your project.

Complete and submit the assignment by 23:59 CST Tuesday November 24th.

GR1 - Project Proposal and Analysis

The heart of this course is a semester-long project, in which you will design, implement, and evaluate a user interface. User interface design is an iterative process, so you will build your UI not just once, but three times, as successively higher-fidelity and more complete prototypes. In order to have time for these iterations, you need to get started on the project as early as possible.

Each project group should consist of 5 people.

Choosing a Problem

For your project, you will choose a problem faced by some user population, and then design and implement a user interface to address that problem. Note that the problem should come first; try to avoid having preconceived notions about the solution until you've at least understood the problem.

You have a lot of freedom in choosing your problem topic. However, you will learn the most from this project if you stretch yourselves into unfamiliar areas of the design space. So we require that you design for somebody else. Choose a problem faced by a user population that nobody in your group belongs to. If you design for somebody much different from you, you will have to learn more about your users and their problems, you will have to challenge your assumptions, and you will have to be more creative in your designs. Examples include people with different roles (diving coaches, singers, mothers), different capabilities (children, elderly, people with disabilities), and different contexts (windsurfers, rock climbers, buskers). Note that your chosen user population must be reasonably available to you -- you will have to interview and observe them for this assignment, and you will have to do user testing with them later in the semester.

Examples of some projects that looked at interesting user populations include:

ElderConnect (for older people),
CheckIn (for parents and kids),
VoiceComposer (for composers),
Musical Sketches (for music students).
SAGE2 Classroom Edition (for instructors)
"Bachao" - Your personal safety application (for campus safety)
Immigrant News (for undocumented immigrants)
SONIFY (for visually impaired users)
re:Linked (for mothers who want to return to the workforce )
User Observation and Analysis

In order to refine your understanding of the problem you have chosen, you will interview at least five users in your target population who face the problem you are tackling. Observe them dealing with the problem in their real environment, and take notes about what you observe. Ask the participants to perform their tasks as realistically as possible, while talking to you about it as appropriate. Afterwards, spend 10 minutes interviewing each participant about the activity that you observed.

Using your observations, and the results of your interviews, your group should then refine your problem statement, and analyze your problem, by identifying user classes and goals. A user class is a subset of the user population that may be expected to use the system in a different way. Note that a single user may fall into two classes, if they play distinct roles at different times. Be aware that generic terms such as 'power users' and 'novices' are not usually helpful. The goals should be high-level tasks that are associated with the problem. You should identify at least three goals; if you cannot, your problem may be too small to serve as a good project, and you should rethink it.

Deliverables

After completing GR0, complete the following under "GR1 Analysis" section :

Observations and Interviews. Give a narrative of the five people that you observed and interviewed. Don't use their names (you may use pseudonyms). Don't identify the users by name, but do describe who they were. Each narrative should include a particularly interesting moment -- a breakdown or workaround that exhibits a feature of the problem you're aiming to solve.
User Classes. Describe the user classes that you have identified and their major characteristics.
Goals. Describe the goals that you have identified, with reference to the observations you made.
Complete and submit the assignment by 23:59 CST Monday September 28th.

GR6 - User Testing

In this group assignment, you will evaluate your interface with a small user test and write a final reflection.

What you'll do

Find users. Find at least three representative users from your target population. None of your users should be enrolled in CS 422. All should be willing to participate voluntarily.

Prepare briefing and tasks. These may be the same ones that you used in paper prototyping, but you may need to improve them based on feedback from the paper prototyping. (You may, if you wish, also prepare a short demo of your interface that you can use to show your users the purpose of the system. The demo should be scripted, so that you do and say the same things for each user. It should use a concrete example task, but the example task should be sufficiently different from the test tasks to avoid bias. The demo option is offered because some interfaces are learned primarily by watching someone else use the interface. Think carefully about whether your interface is in this category before you decide to use a demo, because the demo will cost you information. Once you've demonstrated how to use a feature, you forfeit the chance to observe how the user would have learned to use it alone.)

Pilot test. Do a dry run of your briefing, demo, and tasks before you test your real users. You can use another member of the class for your pilot testing, if you wish.

Run the test. Conduct a formative evaluation with each user:

• Provide your briefing and (optionally) demo.
• Then provide the tasks one at a time, observe, and take notes.

One member of your group should be the facilitator of the test, and the rest should be observers. Watch and record critical incidents. We don't recommend that you videotape your users. However, if you want a record of the user test to supplement your notes, you may try using screen capture software, such as QuickTime Player, which is free, or Camtasia Studio.

Analyzing results. Collect the usability problems found by your user tests into a list. Assign each problem a severity rating (cosmetic, minor, major, catastrophic), and brainstorm possible solutions for the problems.

Deliverables

Google Doc Project Report. Under the section "GR6 User Testing" add the following sections:

• Design. Describe the final design of your interface. Illustrate with screenshots. Point out important design decisions and discuss the design alternatives that you considered. Particularly, discuss design decisions that were motivated by the three evaluations you did (paper prototyping, heuristic evaluation, and user testing).
• Implementation. Describe the internals of your implementation, but keep the discussion on a high level. Discuss important design decisions you made in the implementation. Also discuss how implementation problems may have affected the usability of your interface.
• Evaluation. Describe how you conducted your user test. Describe how you found your users and how representative they are of your target user population (but don't identify your users by name). Describe how the users were briefed and what tasks they performed; if you did a demo for them as part of your briefing, justify that decision. List the usability problems you found, and discuss how you might solve them.
• Reflection. Discuss what you learned over the course of the iterative design process. If you did it again, what would you do differently? Focus in this part not on the specific design decisions of your project (which you already discussed in the Design section), but instead on the meta-level decisions about your design process: your risk assessments, your decisions about what features to prototype and which prototype techniques to use, and how you evaluated the results of your observations.

As usual, be complete, deep, and concise in your report. Tidy up your entire report to make it a usable presentation of your term project. If your project changed direction or scope over the course of the semester, update earlier sections (such as the original Problem section you wrote for GR1) to reflect your final project.

Complete and submit the assignment by 23:59 CST Wednesday December 2th.

GR2 - Designs

In this group assignment, you will start designing your term project. Your project may have changed direction slightly from GR1. Make sure you update your GR1 write-up to be consistent with your GR2 submission.

Design

Scenario. Write a scenario that involves the tasks you identified in GR1. A scenario is a concrete, realistic story that sets up a situation involving a user with a goal to satisfy, and then follows the user through the tasks they do to satisfy that goal. While your task descriptions were abstract (e.g. "Buy a subway ticket"), your scenario should be concrete, complete with imaginary users and imaginary details (e.g. "Frodo is going to the Red Sox game with 3 of his friends. He needs to buy a ticket, but the T station is packed with commuters and other Red Sox fans...").

Design sketches. As an individual, each member of your group should generate three different preliminary designs for your user interface. Each design should be represented by one or more sketches, and accompanied by an explanation in a few sentences. These do not need to be fully fleshed out, but should reflect the insights gained from writing the scenario.

We want you to stretch your design thinking. So at least one of each individual's three designs should be extreme in one of the following ways or similar:

• ultra-efficient
• ultra-safe (preventing all errors)
• for illiterate users
• for blind users
• for a non-computer, non-phone interface
• for a tiny screen (smaller than a standard smartphone screen - e.g., a watch)
• for children
• for the elderly
• for use while driving
• for physically-disadvantaged users

Storyboard designs. As a group, synthesize your individual design ideas to generate three different proposed designs for your user interface. These designs should synthesize the best parts of the individual designs. Explain each design and include a storyboard showing how it works for your scenario. The storyboard should combine words with sketches showing how the interface appears over the course of the scenario, and should include (at the end) an analysis of the design's good and bad points for learnability, efficiency, and safety.

Deliverables

Google Doc Project Report. Under the section "GR2 Design" add the following sections:

• Scenario
• Individual design sketches
• Group designs, consisting of storyboards and analyses
• Complete and submit the assignment by 23:59 CST Wednesday October 7th.

Advice

Your designs will be judged on how well you've described them, how well you analyze them, and how diverse they are. Three group designs that differ only in small ways will not receive much credit. Individual designs that fail to show stretch will not receive much credit.

Take time to brainstorm on a variety of different interface designs, sketching them by hand on paper or a whiteboard. You should play with many more than the required designs, but we only require you to record a subset of them in your report.

When you draw your sketches, don't get bogged down in details like wording, graphical appearance, or layout. Keep things simple. Focus on the conceptual model you're trying to communicate to the user, and think about your task analysis: what the user needs to do and how they can do it. Putting too much time into designing low-level details is pointless if big things have to change on the next design iteration.

Hand-drawn sketches are preferred. There are a number of ways to get hand-drawn sketches into your report. You can draw on paper and take a photo or use a scanner to convert it to electronic form. Make sure your sketches are readable, and crop them and size them appropriately so that your report presentation has good usability. Sketches may be annotated on a computer.

GR4 - Computer Prototyping

In this group assignment, you will do the first computer-based implementation of your term project.

You may want to use a prototyping tool for this assignment, such as Adobe XD or an HTML editor. You don't necessarily have to throw this prototype away, so you can choose a tool that will produce code you can use in your final implementation. But you shouldn't get too attached to this prototype either, and be prepared to make radical changes or throw it away if evaluation reveals serious usability problems.

Building your prototype

Your computer prototype should be:

• High fidelity in look. Use this prototype to explore the graphic design of your final implementation. Lay out screens as you want them to appear in your final implementation. Make choices about colors, fonts, alignment, icons, and white space.
• High fidelity in feel. This prototype should run on the web or natively in an OS, for example, in a recent version of one of the following desktop browsers: Chrome, Safari, Firefox. Make sure you indicate what browser/OS/version combination you have used.
• Low fidelity in breadth. Your prototype should include every feature needed by your scenario from GR2, but doesn't need any features beyond that.
• Low fidelity in depth. You can leave out most of your backend. Where system responses are needed, make them canned (i.e., always the same) or random. Consider using static images (pixel-model output that you created in a drawing program) in places where the final implementation would have to draw on the fly (stroke-model or component-model). Use realistic data in your canned displays, however -- in particular, data of a realistic scale. If you were building (say) an music player and your prototype displays only three songs in the user's library, that's pretty unrealistic, and won't adequately test your UI design choices.

Here are some issues you should not worry about in this prototype:

• Window resizing. When a window is resized, its layout has to adjust to respond. Don't worry about this for now. Determine a good default size for your windows and design a good layout for that size (using either automatic layout or even absolute positioning). Your final implementation probably should support window resizing, depending on your application, but you should decide how to make your interface's default look as good as possible, before worrying about variation.
• Platform independence. Even though your final implementation will run on multiple platforms -- different browsers, different operating systems -- your prototype doesn't need to look good or work well everywhere. Focus on one platform for now.

After you hand in your prototype, ask at least four of your classmates to do heuristic evaluations of it for assignment PS3 and we will give their reports back to you.

Since your evaluators must be able to view and interact with your prototype, this puts some constraints on how you implement your prototype. Depending upon its viability, you may need to schedule an in-person session or send them an executable or URL. You may use the time during Studio 7. It is fine to require evaluators to use a particular web browser and OS to ensure the correct appearance and operation of your prototype (or even your own computer).

Deliverables

Google Doc Project Report. Under the section "GR4 Computer Prototype" add the following sections:

• Platform details. Specify the platform and software requirements for your prototype.
• Instructions. Give brief, step-by-step instructions for starting up your prototype. A URL might be sufficient.
• Shallow parts. Describe which parts of the prototype are shallow (incompletely implemented or canned), so that your evaluators know what should work and what shouldn't.

Note that your prototype must remain frozen (ie, with no changes) and accessible at the URL or from you that you provide for one week after the due date.

Complete and submit the assignment by 23:59 CST Monday November 9th.