Projects

Project One: Onboarding

Due March 3, 11:59pm CT

Project Description

You will create a compelling single-page site that features a sign-up process to get new users to join some type of project, such as an email list, a software beta test, or an open-source community. The goal of this project is to experiment with patterns of interaction that persuade someone to sign up for whatever it is you’re offering, which is not an easy task. Design for effortless, engaging entry of personal information. Include friendly, frictionless client-side tests and alerts for malformed, missing, or incomplete information.

Project Goals

  • Create a touch-friendly, mobile-first responsive web design
  • Experiment with design and interaction patterns for pleasing user experience
  • Design and execute a progressively enhanced page focused on system users and tasks
  • Apply design principles including typography, layout, color, and material design
  • Engage in agile, iterative web design and development, supported by version control

Deliverables & Milestones

  1. Sketches of your design. These can either be natively digital sketches, or paper sketches that you photograph. Whatever method you choose, save your sketches in a web friendly format (JPEG, PNG) and place them in a directory called _sketches in your repository.
  2. A video presentation of your work in progress. Host the video on YouTube, Vimeo, or another similar service and post the link to Basecamp. Your Basecamp post should also include the URL to your GitHub repository and representative sketches that you made in designing your interface. Include in the text of your post one or two specific things you would like feedback or help on from the instructor and other students in the class (due no later than February 10, 11:59pm).
  3. Substantive comments critiquing at least three other student projects (by Febraury 14, 11:59pm CT).
  4. An email to the instructor containing the project’s two final deliverables (by March 3, 11:59pm CT):
    1. A 4-5 sentence self-critique memo of your project and your progress in class to this point
    2. The https:// link to your project’s GitHub repository, which should include your sketches in a _sketches directory.

Requirements

  • Write only one valid well-formed HTML file, one valid CSS file, and one JavaScript file.
  • Encode source files in UTF-8/Unicode with Unix-style line endings (LF); entab with spaces, not tab characters
  • Indent HTML, CSS, and JavaScript files with 2 spaces per level of indent. Indent HTML when nesting tags. Indent all CSS style rules inside the declaring block, and further indent all rules and blocks inside your media queries. Indent inside of all blocks in JavaScript.
  • Present organized, readable source that is hand-written and original (no WYSIWYGs or code-generators, no Bootstrap or other off-the-shelf frameworks). A JavaScript framework for basic DOM manipulation is permissible, such as jQuery or a lightweight alternative such as Umbrella JS or Shoestring. Challenge yourself to use native DOM methods first.
  • Run all code through validators and linters to ensure the quality of your HTML, CSS, and JavaScript
  • HTML requirements:
    1. Use the default-served index.html file name in directory-based URLs, so that you can point to, for example, example.com/
    2. Write well-formed, valid semantic HTML. Projects whose HTML does not validate with the W3C HTML validator will receive a zero-point, failing grade. In the unlikely event that you discover a validation error or warning that is a genuine bug in the validator, you must acknowledge that bug in the memo that accompanies your project, and point to the relevant documentation, such as specifications or an existing reputable bug report, that your source is in fact correct. Get in the habit of validating and linting your HTML before you commit to Git.
    3. Use only structural, semantic HTML elements and attributes. Absolutely no table markup, break tags, or any other use of HTML to achieve a particular page layout. All layout and design should be handled via CSS.
    4. Write valid HTML form elements in conjunction with <label> tags and the for attribute
    5. Present semantically structured text-based content to accompany all media elements (image, audio, video). Make use of the <figure> and <figcaption> tags
  • CSS requirements:
    1. Write 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.
    2. Open screen.css with the minified Eric Meyer reset CSS styles
    3. Use only relative units (em, rem, vw, %) in your CSS; no px, pt, or other absolute units are permitted in your CSS
    4. Use only min-width media queries to enhance your mobile-first styles for larger screens
  • JavaScript requirements:
    1. Use JavaScript only for progressive enhancement. All site content and basic functionality (e.g., clicking links, viewing images and other media, scrolling, submitting forms) must still be accessible even in the absence of JavaScript.
    2. Never use on- or other deprecated event attributes in your HTML. Handle all events via event listeners in your JavaScript. The only element in your HTML that should contain any references to JavaScript should be a <script> element that loads your JavaScript file, and possibly also your DOM-manipulation framework. In other words, keep your JavaScript unobtrusive to progressively enhance your HTML.
    3. Avoid using JavaScript to manipulate your CSS whenever possible. Limit JavaScript to manipulating the DOM, including adding and removing state classes, and keep style information and transitions where they belong: in your CSS file.
    4. Use an immedately invoked function expression (IIFE), function closures, and other techniques to avoid polluting the global window namespace
  • Git requirements:
    1. Build a Git repository with frequent commits and meaningful commit messages that accurately reflect each set of changes that you make
    2. Include only the files and commits from this project in your repository
    3. Use only the command-line Git program on your computer; no commits made through the GitHub web interface

Project Two: Booking System Design

Due Sunday, April 21, 11:59pm CT

Project Description

For this project, you will work in self-selected teams of three or four students to design a booking system for purchasing tickets for travel, movies, concerts, or sporting events, or a similar system for ordering food online.

In all of those types of systems, users must be able to book a purchase for a certain number of people, for a certain event taking place at a particular time. There are then also the details like the destination for a flight, bus, or train; or the specific movie or concert. And finally there is the problem of reserving a specific seat or a block of options: seating charts to clarify which seats someone is purchasing, or a menu displaying food items available for order. You must also design a simple form for accepting payment by credit card.

Your design, which you will test with actual users for Project Three, must accomodate all of those kinds of choices and others that you identify. You should begin by conducting a competitive task-analysis of other, similar booking sites. Take extensive notes of the patterns that you see. Which work? Which could be improved upon? And what entirely new ideas do you and your team have for streamlining the user experience of these types of multifacted tasks?

Project Goals

  • Conduct task analysis and apply the information gained to a user-centered design
  • Build interface modules/elements from a basic design foundation of alignment, contrast, proximity, and repetition
  • Apply design principles including color/material, typography, accessible media, and grid-based design
  • Execute a progressively enhanced, touch-friendly, mobile-first responsive design focused on system users and tasks
  • Write informative text content; catch error conditions and guide users accordingly
  • Experiment with design and interaction patterns for pleasing user experience
  • Engage in agile, iterative web design and development within a team-based workflow on GitHub, via pull requests and code reviews, coordinated over a project-management app like Basecamp, Slack, or Trello

Deliverables & Milestones

  1. Whole team: A project proposal, based in part on your work for Production Problem 03, describing:
    • Who the members are on your team (organize yourselves on Basecamp starting 3/4)
    • What kind of booking system you will build
    • What the URL is to your shared team GitHub repository, and the URLs to each team member’s individual fork of the shared repository
    • Which project-management/communication app (e.g., Basecamp, Slack, Trello, or something else) that you will use to communicate with one another to coordinate your work and avoid disasters on GitHub and elsewhere.
    The proposal should be collaboratively written as a Markdown file in your shared GitHub repository (due no later than Thursday, March 14, 11:59pm CT). Designate one member of the group to post as a new message thread on Basecamp the URL to the group repo containing the proposal.
  2. Whole team: A screen-by-screen task analysis of existing sites that provide similar functionality to your chosen task (again, e.g., booking a flight, purchasing reserved-seating tickets to a concert, ordering food for delivery at a specific time). Post to Basecamp (due no later than Thursday, March 28 11:59pm CT).
  3. Whole team: A video presentation of your team’s work in progress, hosted on YouTube, Vimeo, or another similar service and posted to Basecamp. Your Basecamp post should include the URL to your team’s GitHub repository and a URL to the live site (GitHub Pages is fine). Include in the text of your post one or two specific things you would like feedback or help on from the instructor and other students in the class (due no later than Sunday, April 7, 11:59pm CT).
  4. Each team member: Substantive comments critiquing at least three other team projects (by Sunday, April 14, 11:59pm CT).
  5. Each team member: an email to the instructor containing the project’s three final deliverables (by Sunday, April 21, 11:59pm CT):
    1. A 4-5 sentence self-critique memo of your project and your progress in class to this point
    2. A 2-3 sentence critique of each group member’s work on the project
    3. The https:// links to your individual and group GitHub repositories

Requirements

  • All source files in UTF-8/Unicode character encoding with Unix-style line endings (LF)
  • Organized, readable source that is hand-written and original (no WYSIWYGs or code-generators, no Bootstrap or other off-the-shelf HTML or CSS frameworks)
  • HTML, CSS, and JavaScript files should all be indented with 2 spaces per level of indent; indent all CSS style rules inside the declaring block, and further indent all rules and blocks inside your media queries
  • HTML requirements:
    1. Only structural, semantic uses of HTML elements and attributes. Absolutely no table markup, break tags, or any other use of HTML to achieve a particular page layout.
    2. Valid HTML form elements, written in conjunction with <label> tags and the for attribute
    3. Semantically structured text-based HTML content to accompany any media elements (image, audio, video)
  • CSS requirements:
    1. CSS file should open with a set of reset styles (such as the minified Eric Meyer resets from class demos); consider also the Normalize.css styles for forms
    2. Only relative units (em, rem, vm, %) in your CSS; no px, pt, or other absolute units allowed (pixel units are allowed in media queries, although you may wish to convert those to 16px-based ems)
    3. Use at least two min-width media queries to enhance your mobile-first styles for larger screens
  • JavaScript requirements:
    1. JavaScript that throws no uncaught errors and is loaded unobtrusively (no JavaScript event attributes in your HTML, in other words; attach events to any elements requiring interaction)
    2. JavaScript that uses function closures and other techniques to avoid polluting the global window namespace
    3. JavaScript that uses only asynchronous methods and callbacks
    4. Use of JavaScript objects or JSON to prototype interaction with a server to retrieve data, such as indicating seat/show/menu availability
    5. Use of cookies or, better, LocalStorage to maintain information/state between pages (e.g., the number of tickets someone wishes to purchase)
  • Git requirements:
    1. Whole team: A shared team Git repository with frequent commits from each team member and meaningful commit messages that accurately reflect each set of changes. The team GitHub repository must include frequent commits from every team member for the duration of the project.
    2. Each team member: An individual Git repository with feature branches, frequent commits, and meaningful commit messages that accurately reflect each set of changes that you make, including experimental work that you ultimately might not push upstream to the shared group repository.
    3. All GitHub repositories (team and individual) must contain only the files and commits from this project
    4. Use of the command-line Git program on your computer; no commits made through the GitHub web interface, apart from merge commits created as part of code reviews/pull requests

Project Three: User-Tested, Revised Booking System

Due Thursday, May 9, 11:59pm CT

Project Description

The final project of the course asks you to subject your group’s booking system project to a series of low-stakes user tests, and to develop and implement 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 his 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.

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 usability tests on mobile and traditional devices.

Deliverables & Milestones

Unlike previous projects, your deliverables for this assignment should be turned in as a Google Drive share URL. Be sure all members of your group have full read/write access to the group folder on Drive.

Do not use the internal sharing function on Drive with the instructor. Generate a shareable URL that you paste yourself into a Basecamp post or an email to the instructor. The URL should point to a folder containing thoughtfully named files and folders containing each deliverable listed below.

  • A Basecamp post by 11:59pm CT on 4/25 with Google Drive links to the following things:
    1. Testing script (posted to Basecamp by 11:59pm CT on 4/25, before testing), which should include a welcome to your participant, an explanation of the process, and a numbered list of the exact tasks you will be asking participants to complete
    2. A/V release form for each participant to sign (posted to Basecamp before testing, by 11:59pm CT on 4/25)
    3. Site plan: location, equipment, setup/arrangement (posted to Basecamp before testing, by 11:59pm CT on 4/25)
  • A group-authored email to the instructor by 11:59pm CT on 5/9 containing Drive links to the following things:
    1. Video recording of each participant session (due by 11:59pm CT on 5/9)
    2. Testing notes + 3 major issues per observer, per participant (due by 11:59pm CT on 5/9)
    3. A group-authored recommendation report (due by 11:59pm CT on 5/9) on three most pressing issues identified through your testing, including:
      • an explanation as to why the issues you’ve selected are most pressing
      • possible approach to implementing fixes/improvements to address the issue
      • future usability tests you’d run to ensure the quality of the fix
  • An individually authored email containing a 4-5 sentence self-critique of your project and your progress in class this semester in addition to 4-5 sentence critiques for each of your group members, emailed to the instructor (due by 11:59pm CT on 5/9)

Requirements

  • Test your site with three different participants not in our class. At least one participant should use a mobile device (phone or tablet); at least one should use a traditional device (desktop or laptop)
  • When possible, have participants use their own devices (but have a backup device ready to use, just in case)
  • Figure out how to best involve your group’s online students who cannot be present on campus for testing; include those details in your site plan
  • Submit all final deliverables as an email to the instructor. The email must contain your individual reflection memo and a URL to a shared Dropbox or Google Drive folder to which all group members have read/write access