This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Project

Final Project general information and milestones.

Overview

Working in teams, you will design, develop, and deploy a client-side web application prototype. The deliverables include the milestones linked below.

While in this course you will also learn to build (static) web sites, the final project is a prototype of a web application. The difference is that a web site is a collection of static pages, while a web application is a dynamic program that responds to user input. For example, a web site might be a collection of pages that describe a restaurant, while a web application might be a program that facilitates online ordering of food from that restaurant.

More information on the (primarily out-of-class) group project and its milestones is coming soon!

1 - Final Project - Milestone 01: Design Sketch and Narrative

Milestone 01 of the Final Project

Over the next 10+ weeks, you will design and implement an interactive application. Your project should have a focused theme and audience of your choosing. We encourage you to be creative and have fun with the project!

For this first project milestone, you will come up with an idea and direction. You will also create an annotated design sketch of your application’s layout. In the end, you will submit two pdfs with your proposed project ideas.

Overall Requirements

Your project will…

  1. be a client-side web application.
    • “Client-side” means you will not implement a backend that runs on a server. Your project must be completely self-contained, like the labs we have done so far.
      • Your project should not have social media elements (Ex: likes, status updates). Sharing data with friends requires server-side processing that you cannot access. Any data posted should be for the individual user only.
      • Your project should not depend on authentication/passwords. We will not have your login credentials when grading, and we will not use our own personal credentials (if we even have accounts).
    • “Web application” means a program that runs in the browser and responds to user input.
      • Applications are not static/hard-coded presentations of images and text. They load and work with data to generate the presentation dynamically. That is, applications do something.
      • Most of the code/focus should be JavaScript, with a fair amount of HTML and CSS.
  2. serve someone besides yourself.
    • Thinking empathetically is an important skill for application development. In the future, you need to understand your client’s vision to bring new ideas to life.
  3. perform “CRUD” operations (Create, Read, Update, and Delete).
    • Application-relevant data will persist in the browser’s local storage. Additional data will be fetched at run-time from third-party APIs (examples below).
  4. be deployed to a publicly accessible URL.
    • That means you can’t “hard code” paths that work only on your computer. You also can’t install any “server-side” frameworks (like Node.js) or other tools.
  5. meet accessibility and validation standards while demonstrating a pleasant visual design.
    • Use a palette that combines multiple colors for accessible and pleasant aesthetics. See Color-hex, Venngage, or K Design Co. for example palettes.
    • Use CSS layout, borders, spacing, etc., to present information clearly and effectively.
  6. use a CSS framework (Bootstrap or Tailwind).
    • Bootstrap has the advantage of providing many pre-built interactive components that you can control with classes and your own JavaScript. However Tailwind generally has better and more flexible aesthetics, including colors and filters.
  7. use client-side JavaScript libraries (Ex: Chart.js).
  8. include asynchronous programming (in the end).

Possible Examples

Below are some ideas, and you are encouraged to come up with your own. Your content must be original and not lifted from other websites. Third-party images/media are acceptable provided you adhere to their license; you must also cite their use. You may consider some of the following scenarios and use cases:

  • A calendar for keeping track of due dates, events, birthdays, etc., combining user data with information from standard lists of holidays.
  • A shopping or wish list that allows users to keep track of things they would like to purchase, including tags for sorting based on priority or a comparison shopping cart with pricing data pulled from online stores.
  • A tablet-based ordering system for a local business, with separate screens for selecting and customizing orders, displaying sales information, etc.
  • A personal journal that lets someone track exercise, health, or other personal information, while making progress toward established goals.
  • A personal finance tracker that creates charts illustrating categories of spending habits or an investment portfolio.
  • A note-taking application with a wiki-style interface that lets you update and annotate information.
  • A custom media player interface for building playlists, playing locally stored media, and/or adding annotations (Ex: adding a “bookmark” to a favorite scene or musical passage).

Getting Started

First, exchange contact info with your assigned team members. Set up a group text or other means of communicating outside of class. Then have one student do the following:

  • Go to draw.io and click the blue Start Now button.
  • Click the Google Drive button and authorize the app on Google Drive (if needed).
    • Alternatively, you may use OneDrive. But Google Drive supports more features.
  • Click the Create New Diagram button and select Blank Diagram as the template.
  • Give the file a meaningful name like CS343_Project1.drawio (or similar name).
  • Click the orange Share button (top right) and add the other team members.

Once the diagram is shared, all team members should be able to edit simultaneously.

What to Turn In

Upload the following two pdf files to Canvas. Each pdf should be 2–3 pages. Only one team member needs to submit the files.

  1. Annotated design sketch (exported from draw.io)
  2. Project narrative (from Google Drive or OneDrive)

Your design sketch must…

  • depict at least one page in a larger view (Ex: “desktop”).
  • depict at least one page in a smaller view (Ex: “mobile”).
  • have annotations to show the font faces, colors, and sizes.
  • have annotations to show the layout and spacing (where not default).
  • depict user interface elements necessary to perform CRUD operations.
  • depict a navigation menu that will be present on all pages.

Your project narrative must include the following sections (about 200 words each):

  • Purpose
    • Clearly state the main idea and intended purpose of your application.
    • Explain a problem your application aims to solve and why it is important.
  • Users
    • Identify the primary users of your application, including their background or needs.
    • Justify how your application will benefit these users and improve their experience.
  • Features
    • Outline the core functionalities of your application and explain how they will work.
    • Provide a concrete example demonstrating how the application fulfills its purpose.
  • Data
    • Describe the types of data that users will create, read, update, and delete (CRUD).
    • Include an example of this data using either real or representative sample values.

At the top of the narrative, include the project title, your team name, and the student names.

References are optional, but you may include “Works Cited” if that simplifies the explanation.

2 - Final Project - Milestone 02: Static Site (NO JS!)

Milestone 02 of the Final Project

This page is mostly complete, but some details might change

For this second milestone, you will work with your team to create the beginning of your “app” as a static website. Follow the design you proposed, incorporating the feedback you’ve received and lessons you’ve learned since then.

Overall Requirements

  1. You must use the git repository your professor created for the project.
    • Each team member must make incremental commits to the project over time.
  2. You must publish the site to the w3.cs.jmu.edu server.
  3. Your site must support distinct layouts for large and small screens using media queries. Use comments to note where you completed this requirement.
    • You may do this in a variety of ways. For example, you can move images or switch blocks between rows (for large screens) and columns (for small).
    • For example, you could use a CSS media query to change the layout when the screen width is less than 600px. Include a comment in your CSS file to indicate where you did this.
  4. Your site must contain at least five separate pages, each having a meaningful purpose. The main page must be named index.html. Your pages must link to each other in a logical and meaningful way.
  5. Your site must include some sort of header.
  6. Your site must include some sort of navigation links.
  7. Your site must include images, and their alt attributes must adequately describe the image content to users of screen readers, users with images disabled, and web crawlers.
  8. Each page and stylesheet of your site must validate without any warnings or errors using the Nu HTML Checker and WAVE Accessibility evaluator.
  9. Your site must use at least two different font faces. For example, headings are often rendered in a sans-serif font, and paragraphs in a serif font.
  10. Your app (eventually, in milestone 3, because as you recall this milestone has no JS yet) must support user interaction, for example
    • it could include at least one form. The form need not do anything at this point, but it must be present. Like all content, it must be neatly aligned.
    • your plan could be that clicking or typing or other actions will be noticed (in milestone 3)
  11. Your site must include links to external sites.

Project 2 Report Page

Your site must include a page named report.html accessible from root of your site. (This does not count as one of the five pages.) Your report.html must include an ordered list where you briefly explain how your site meets the above requirements. If you aren’t going to meet a requirement, you need to explicitly write that you did not meet that requirement.

    1. This is the url to our github repo: `https://github.com/...`
    2. This is the url to our deployed site: `https://w3.cs.jmu.edu/...`

    ...

    12. We used the [GIPHY API](https://developers.giphy.com/docs/api)
        and the [Spotify API](https://developer.spotify.com/documentation/web-api/).
        *Explanation of how/why...*

Feel free to write additional comments below the ordered list that describe other progress you have made on the project.

Professional Practices

Your project will be graded on both the functionality and quality of the code. Use this list of practices as a guide:

  1. Your source code must be formatted using a consistent standard. We recommend using the built-in support in VS Code for formatting HTML and CSS (other options like Prettier may not default to producing valid HTML).
  2. Your site’s non-HTML resources must be organized:
    1. Images should be placed in a directory named images.
    2. CSS files should be placed in a directory named styles.
    3. JS files should be placed in a directory named scripts.
    4. Design sketch files should in a directory named design.
  3. Your interface must demonstrate good aesthetics, including good choices for color schemes, layout (using grids and/or flexboxes, along with non-static positions), and dynamic effects.
  4. Your site must maintain a coherent style across its pages. Repeated style rules must be placed in a shared external stylesheet. Style rules not shared between pages must be placed in separate external stylesheets.
  5. The content should be neatly aligned. The axes of alignment should be clearly visible. Favor left- and right-alignment over centering—as centering does not produce a strong axis of alignment.
  6. The content should have adequate and consistent spacing. Text should not overflow the surrounding box.
  7. Your source code must be readable, using conventional and consistent formatting and meaningful names for classes and IDs. Use kebab-case (preferred) or camelCase identifiers.
  8. Your source code should use semantic and structural elements to support accessible usage. You should also use ARIA features as appropriate. In particular, you must adhere to the Level A recommendations in the WCAG Checklist.
  9. The names of your files must be entirely lowercase and contain only alphanumeric characters.
  10. You should write meaningful comments.

3 - Final Project - Milestone 03: Dynamic Application Prototype

Milestone 03 of the Final Project

This page is mostly complete, but some details might change

Now comes the fun part—finish your final project! In the previous milestones, the focus was on the structure and presentation of your “site.” The priority of this last milestone is the behavior of the application. However, you should also make sure that the structure and presentation are complete, incorporating the feedback you have received.

The Big Picture

Most requirements from the previous project milestones still apply. In particular, please review the following sections:

We are revising the “5 html pages” requirement. You don’t need “at least five separate pages” per se, but rather enough complexity. Your application must demonstrate at least five distinct features or use cases, each with a meaningful purpose. These may be implemented as separate HTML pages or as interactive sections within a single-page application. Your site should include clear navigation that allows users to access all major features in a logical and meaningful way.

Requirements

  1. Your app must use at least one media query to implement its responsive design.
    • This media query might not appear in your own source code if it’s something your chosen design framework (e.g. Bootstrap) is handling.
  2. You may (and are strongly encouraged) to augment the default style with your own CSS to create more pleasing aesthetics. (Bootstrap’s color schemes are not exactly the most beautiful…)
  3. Your site must use localStorage to store and retrieve updated data values between sessions. That is, what is displayed as content should reflect these changes. Often these actions are called “CRUD” (Create, Read, Update, and Delete).
  4. However you implement the CRUD actions, your implementation should contain forms that:
    1. make appropriate use of labels, buttons, and input groups. The forms should use a combination of input, select, checks, radios, and possibly other input types based on the data being entered.
    2. include appropriate event handlers to refresh the displayed data when forms are submitted.
  5. One possible implementation of CRUD actions could be to use a widget such as Bootstrap’s modal. Use a flow that reflects best practices from around the web. For example, if you choose to use a modal you might:
    1. have one modal that allows users to add new data values.
    2. have one modal that allows users to edit existing data values.
    3. have one modal that allows users to delete existing data values.
    4. include appropriate event handlers to refresh the displayed data and dismiss the modal.
  6. Your site must provide a way to export and import the current data values to/from a JSON file.
  7. Your site should provide the user a means to clear their data (to start from a fresh beginning).
  8. Each page and stylesheet of your site must validate without any warnings or errors using the Nu Validator and WAVE Web Accessibility Evaluator.
  9. Your app must make at least two network requests to third-party APIs via fetch(). You must demonstrate your understanding of JavaScript features to synchronize the responses.
    • For example, you may sequence the requests such that you make the 2nd request only after you have the response from the 1st. Typically this is because the 2nd request needs to include some information that was computed during the 1st request.
    • Alternatively, your application may issue multiple requests that are combined when all promises are resolved. Or you may do something else that is at least as complex as this and the previous bullet point.

Submission

Your final deliverable is your GitHub repository. Please verify that all files are committed, pushed, and ready for grading. Your final code will be deployed to https://w3stu.cs.jmu.edu/cs343s25/teamX/.

Presentation

Each group will have 12 minutes to present their final project to the class. Divide the time into 3–4 minute segments: one for each student. Do not prepare slides. For each 3–4 minute segment, do the following:

  • Demonstrate how the application works in the browser.
  • Consider walking the class through how to use the app.
  • Walk through the source code (HTML, CSS, JavaScript).
  • Answer questions and/or invite comments throughout.

You don’t have to show your entire code; focus on the most interesting parts. Explain any problems you encountered and how you solved them. Give the audience a sense of what you learned during this project.

Be sure to demo both the “desktop” (large screen) and “mobile” (small screen) layouts of your app. You may use the DevTools to simulate a mobile device, or just resize the browser window, or something else.

The presentation must involve all group members—don’t allow one person to do most of the talking. Practice transitions beforehand so you know how to support each other and tell a cohesive story about your work.