Project One: Due Thursday, March 24, 2022

Shipping and Payment Form

Project Description

You will create a compelling, multi-page process that walks a user through payment, billing, and shipping options to complete the order of a pre-selected set of items in the user’s shopping cart. The goal of this project is to experiment with patterns of interaction that make it as effortless as possible for users to complete a purchase, which is not an easy task.

Design for straightforward, engaging entry of personal information. Include friendly, frictionless client-side tests and alerts for malformed, missing, or incomplete information. And bring a full suite of validators, linters, and visual regression tests to ensure code quality from your earliest commits.

Deliverables and Deadlines

  1. Due by Thursday, February 3: Post your set of interface sketches to the Project One Sketches board on Basecamp. Provide a link to your _sketches/ directory in your repository. Include in your post two or three specific questions you’d like feedback on.
  2. Due by Thursday, February 10: Respond with substantive comments on at least three other sets of student sketches.
  3. Due by Thursday, February 24: Post your Project One draft to the Project One Drafts board on Basecamp. Provide links to your project repository and live site on GitHub Pages. Include in your post two or three specific questions you’d like feedback on.
  4. Due by Thursday, March 10: Respond with substantive comments on at least three other student projects.
  5. Due by Thursday, March 24: Email Project One deliverables to Stolley. Your email should include:
    • The https:// link to your project’s GitHub repository, which should include your sketches in a _sketches directory.
    • The link to your deployed site, such as on GitHub pages.
    • A 4-5 sentence self-critique memo of your project and your progress in class to this point

Project Requirements

  • File Requirements:

    1. Include multiple (at least three) linked valid, well-formed semantic HTML files
    2. Include only one single valid, linted, error-free CSS file called screen.css. Do not create more than one CSS file for your project; all styles should be in the same file. Use an id value on <html> or <body> and leverage that in a CSS descendant selector if you need a special style on a specific page
    3. Use only directory-based URLs containing the default-served index.html file, so that you can point to, for example, example.com/order-confirmation/
  • Source Requirements:

    1. Prepare all source-code files in UTF-8/Unicode character encoding with Unix-style line endings (LF), entabbed with spaces (two spaces per tab)
    2. Indent all HTML, CSS, and JavaScript files with spaces, not tabs. Use 2 spaces per level of indent. Indent HTML only to show nested tag relationships; indent all CSS style rules inside the declaring block, and further indent all rules and blocks inside of your media queries; and indent inside of all JavaScript function definitions and multiline object literals
    3. Present source code that is hand-written and original (no WYSIWYGs or code-generators, no Bootstrap or other off-the-shelf HTML or CSS frameworks); no presentational classes
  • WCAG Requirements:

    1. Satisfy all applicable Level A success criteria from WCAG 2.1
    2. Aim for satisfying all applicable Level AA success criteria
    3. Note in your Project Draft and final project memo any Level AAA conformance you’ve achieved
    4. Reference both the WCAG 2.1 specification and the How to Meet WCAG (Quick Reference) (hint: the Quick Reference has customizable filters to help you target the success criteria relevant to your Project)
  • Code Quality:

    1. Make use of both the validators and linters to ensure the quality of both your HTML and CSS
    2. Your project repository must contain the ITMD 362–style .htmllintrc, .stylelintrc, and .eslintrc.json linter configuration files
    3. Configure and present a suite of visual regression tests using BackstopJS, anchored to the viewports set in your CSS media queries
  • HTML Requirements:

    1. Use only valid, semantic well-formed HTML
    2. Use only structural, semantic HTML elements and attributes. Absolutely no table markup, break tags, <span> or <div> tags, or any use of HTML to achieve a particular page layout. All layout and design should be handled via CSS.
    3. Make use of ARIA attributes whenever possible and necessary
    4. Each input element on a form must have an accompanying <label> element, with a for attribute pointing to the id value on the input
  • CSS Requirements:

    1. Open your screen.css file with the ITMD 362 House-Style modified, minified Eric Meyer reset CSS styles (if loading externally hosted typefaces via an @import statement, that must be your first line of CSS, before the reset styles)
    2. Make use of modern CSS layout modules, including flexbox and CSS grid
    3. Use only relative units (em, rem, vw, %) in your CSS; no px, pt, or other absolute units are permitted in your CSS, including in media queries, which should be calculated as 16px ems, regardless of what your actual html em-value is
    4. Use only min-width media queries to enhance your mobile-first styles for larger screens
    5. Completely avoid max-width media queries, which are not allowed (they are not mobile-first)
  • JavaScript Requirements:

    1. The only indication that JavaScript is loaded in your project should be a single <script> element in your HTML
    2. Use JavaScript event-listeners exclusively to intercept user interactions on your project
    3. Engage in appropriate feature detection and error handling
    4. Make smart use of state classes that reference CSS, rather than embedding style values in your JavaScript itself
  • Git Requirements:

    1. Prepare a Git repository with frequent commits and meaningful commit messages that accurately reflect each set of changes that you make
    2. Your commit messages should be in sentence case and begin with a verb in the imperative mood (e.g., Add…, Update…, Remove…)
    3. Include a .gitignore file that ignores the test files from BackstopJS; you should commit only the reference images—not the images from each test run
    4. Your GitHub repository must contain only the files and commits from this project

Project Goals

  • Conduct task analysis & apply the information to user-centered design
  • Design and build a user-centered website applying good principles of design
  • Apply color and typography in web design to optimize the interface
  • Engage in agile, iterative web design and development, supported by version control
  • Write useful, descriptive messages attached to granular commits in a version control system
  • Apply linters to your HTML, CSS, and JavaScript to ensure code quality
  • Configure and run BackstopJS for visual regression testing
  • Configure, build tests, and run NightwatchJS for basic automated UI testing
Project Two: Due Thursday, April 21, 2022

Online Store Design

Project Description

You will work in teams of three and four to build a complete online store. You and your team will begin by selecting the completed Project One of one of your team members, which will be the starter code for this project.

You will then create a single-page online store, listing at least twelve (12) products or services that can be added to a cart. You will also write the structures, styles, and logic for a cart that can be modified: at the very least, you must enable users to remove items from the cart.

Your online store must then correctly calculate the total for all items in the cart, as well as add Illinois-state sales tax (6.25%) and any shipping fees. You will also work, as a group, to refine the checkout process from your team member’s Project One. That will include testing the entire store and checkout system on actual users (see Project Three, which will overlap with Project Two).

All of your work should be committed alongside accurate, appropriate tests. Tests are especially consequential for things like your cart’s functionality, not to mention ensuring that your checkout logic correctly calculates the amount of money your users will be charged.

Deliverables and Deadlines

  1. Due by Monday, March 28: Email instructor with your team members and communication hub and GitHub organization information. Organize into teams of 3–4 students for projects Two and Three. Use Basecamp and the Team-Organization thread to group up.
    • Teams must be at least three students and no more than four students
    • Choose one team member to contact the instructor with the names of your team members
    • In the email, share the URL for your team’s Git organization and your chosen communication platform (e.g., a team Basecamp, Slack, Discord, or whatever your team has opted to use)
  2. Due by Thursday, March 31: Post your signed team contract as a CONTRACT.md file to your team’s GitHub repository. See the contract writing guidance and instructions for creating and signing the CONTRACT.md file on Basecamp.
  3. Due by Thursday, April 7: Post your team’s Project Two draft to the Project Two Drafts board on Basecamp. Provide links to your team’s project repository and live site on GitHub Pages. Include in your post two or three specific questions you’d like feedback on.
  4. Due by Thursday, April 21: Email Project Two deliverables to Stolley. Your email should include:
    • The https:// link to your team’s GitHub repository.
    • The https:// link to your own fork of the team’s GitHub repository.
    • The link to your deployed site, such as on GitHub pages.
    • A 5–7 sentence description of how results from the first round of usability testing (Project Three) lead to specific improvements to your Project Two
    • A 4-5 sentence self-critique memo of your project and your progress in class to this point
    • A 2–3 sentence critique of each of your team members and their contributions to this project

Project Requirements

  • File Requirements:

    1. Include multiple (at least three) linked valid, well-formed semantic HTML files
    2. Include only one single valid, linted, error-free CSS file called screen.css. Do not create more than one CSS file for your project; all styles should be in the same file. Use an id value on <html> or <body> and leverage that in a CSS descendant selector if you need a special style on a specific page
    3. Use only directory-based URLs containing the default-served index.html file, so that you can point to, for example, example.com/order-confirmation/
  • Source Requirements:

    1. Prepare all source-code files in UTF-8/Unicode character encoding with Unix-style line endings (LF), entabbed with spaces (two spaces per tab)
    2. Indent all HTML, CSS, and JavaScript files with spaces, not tabs. Use 2 spaces per level of indent. Indent HTML only to show nested tag relationships; indent all CSS style rules inside the declaring block, and further indent all rules and blocks inside of your media queries; and indent inside of all JavaScript function definitions and multiline object literals
    3. Present source code that is hand-written and original (no WYSIWYGs or code-generators, no Bootstrap or other off-the-shelf HTML or CSS frameworks); no presentational classes
  • WCAG Requirements:

    1. Satisfy all applicable Level A success criteria from WCAG 2.1
    2. Aim for satisfying all applicable Level AA success criteria
    3. Note in your Project Draft and final project memo any Level AAA conformance you’ve achieved
    4. Reference both the WCAG 2.1 specification and the How to Meet WCAG (Quick Reference) (hint: the Quick Reference has customizable filters to help you target the success criteria relevant to your Project)
  • Code Quality:

    1. Make use of both the validators and linters to ensure the quality of both your HTML and CSS
    2. Your project repository must contain the ITMD 362–style .htmllintrc, .stylelintrc, and .eslintrc.json linter configuration files
    3. Configure and present a suite of visual regression tests using BackstopJS, anchored to the viewports set in your CSS media queries
    4. Write and present a suite of frontend tests using NightwatchJS
  • HTML Requirements:

    1. Use only valid, semantic well-formed HTML
    2. Use only structural, semantic HTML elements and attributes. Absolutely no table markup, break tags, <span> or <div> tags, or any use of HTML to achieve a particular page layout. All layout and design should be handled via CSS.
    3. Make use of ARIA attributes whenever possible and necessary
    4. Each input element on a form must have an accompanying <label> element, with a for attribute pointing to the id value on the input
  • CSS Requirements:

    1. Open your screen.css file with the ITMD 362 House-Style modified, minified Eric Meyer reset CSS styles (if loading externally hosted typefaces via an @import statement, that must be your first line of CSS, before the reset styles)
    2. Make use of modern CSS layout modules, including flexbox and CSS grid
    3. Use only relative units (em, rem, vw, %) in your CSS; no px, pt, or other absolute units are permitted in your CSS, including in media queries, which should be calculated as 16px ems, regardless of what your actual html em-value is
    4. Use only min-width media queries to enhance your mobile-first styles for larger screens
    5. Completely avoid max-width media queries, which are not allowed (they are not mobile-first)
  • JavaScript Requirements:

    1. The only indication that JavaScript is loaded in your project should be a single <script> element in your HTML
    2. Use JavaScript event-listeners exclusively to intercept user interactions on your project
    3. Engage in appropriate feature detection and error handling
    4. Make smart use of state classes that reference CSS, rather than embedding style values in your JavaScript itself
  • Git Requirements:

    1. Prepare an upstream team Git repository; use branch protection to ensure code only gets added to main via reviewed pull requests
    2. Fork the upstream Git repository to your own GitHub account, and clone it to your computer (see Production Problem 04); make your contributions to the project on feature branches with frequent commits and meaningful commit messages that accurately reflect each set of changes that you make. Don’t forget to provide or update the tests associated with your contributions
    3. Submit small, targeted features on properly named feature branches as GitHub pull requests to your upstream team Git repository
    4. Your commit messages should be in sentence case and begin with a verb in the imperative mood (e.g., Add…, Update…, Remove…)
    5. Include a .gitignore file that ignores the test files from BackstopJS; you should commit only the reference images—not the images from each test run
    6. Include a setup script (e.g., a scripts/setup executable) that symbolically links your git-hooks scripts
    7. Your GitHub repository must contain only the files and commits from this project

Project Goals

  • Conduct task analysis & apply the information to user-centered design
  • Design and build a user-centered website applying good principles of design
  • Apply color and typography in web design to optimize the interface
  • Engage in agile, iterative web design and development, supported by version control
  • Write useful, descriptive messages attached to granular commits in a version control system
  • Collaborate effectively in a team setting using Git as well as pull requests on GitHub
  • Communicate effectively in a team setting using a communication portal (Basecamp, Discord, Slack, etc.) of your team’s choosing
  • Apply linters to your HTML, CSS, and JavaScript to ensure code quality
  • Configure and run BackstopJS for visual regression testing
  • Configure, build tests, and run NightwatchJS for basic automated UI testing
  • Use git-hooks to ensure passing tests on each commit
  • Use pull requests to ensure test coverage on all team-member contributions
Project Three: Due Thursday, May 5, 2022

User-Tested Online Store

Project Description

The final project of the course asks you to subject your group’s online store from Project Two to two rounds of user testing, and to implement and report improvements to the project based on what you learn through your user tests.

You should structure your tests around the guidance in Chapter 9 of Krug’s book. You are welcome to use as a starting point the sample script and recording release form available at Krug’s website. However, your script must be modified to match your specific project and its tasks, obviously.

For each round of tests, you must document users’ interactions with your online store. That documentation is both for reference and for the benefit of your team members who may not be able to attend the test session live.

Note that this project overlaps with Project Two, which should incorporate improvements from your first round of user tests.

Deliverables and Deadlines

  1. Due by Thursday, April 14: Complete first round of usability testing. Remember to analyze the results and implement changes in your Project Two.
  2. Due by Thursday, April 28: Complete the second round of usability testing.
  3. Due by Thursday, May 5: Complete and email Stolley your usability report. Your email should include:
    • The https:// link to your team’s report repository on GitHub
    • The https:// link to your own fork of the team’s report repository on GitHub
    • The Google Drive link to your team’s test documentation (user videos and consent forms)
    • A 4-5 sentence self-critique memo of your project and your progress in class this semester
    • A 4–5 sentence critique of each of your team members and their contributions to both the usability tests and the final usability report

Project Requirements

  • Testing Requirements:

    1. For each round of testing, you must test with three users who are not currently enrolled in ITMD 362
    2. Each round of testing should test a different group of users: if someone was a test user for the first round, you cannot ask them to participate in the second round
    3. You must receive a consent form signed physically or digitally by each of your test users
    4. You must document each user in each round of testing. That should include at least an over-the-shoulder video recording, and might also include a screen recording
    5. Users should use their own devices for the test, if at all possible. Strive to test each user on a different device (e.g., one on a phone, one on a tablet/touchscreen, one on a laptop or desktop machine)
  • Test-Documentation Requirements:

    1. Preserve all videos of user tests in Google Drive, along with the user consent forms
    2. Plan to delete all user-test videos on May 18, 2022 or as soon as possible after that date
  • Implementation Requirements:

    1. The results from the first round of user testing should lead to specific changes on your team’s Project Two
    2. Keep notes on the changes your team implemented based on the first round of testing; you will write about those changes in your memo with Project Two
  • Usability-Report Requirements:

    1. The results from the second round of user testing will lead to a brief usability report, outlining the changes that should be made to further improve your online store
    2. The report should be jointly authored as a Markdown file in its own GitHub repository in your team’s GitHub organization where you have your Project Two repository
    3. You and your team members should all contribute to the report via pull requests
    4. Note that you do NOT need to implement the changes; you need only to report them as future improvements

Project Goals

  • Evaluate user interface designs with human subjects.
  • Demonstrate how user-centered concerns can be incorporated into system development life cycles.
  • Explain the need to evaluate system usability.
  • Conduct and document usability tests on mobile and traditional devices, either remotely or in person.

Course Information

Instructor

Teaching Assistant