This is the multi-page printable view of this section. Click here to print.
Projects
1 - Project 1 - Semester Project
Overview
Working in instructor-assigned teams, you will design, develop, and deploy a client-side web application prototype. The deliverables include three milestones linked below.
While in this course you will learn to build (static) web sites, this project is 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 allows users to order food from that restaurant.
Requirements Summary
The requirements for each milestone will be enumerated on its own page, but in summary your app will:
- be a client-side web application.
- have a focused theme and audience of your choosing.
- serve someone besides yourself.
- Thinking empathetically is an important skill to develop for web design, as you need to understand your clients’ vision to bring it to life.
- Facilitate a visitor in Creating, Reading, Updating, and Deleting (i.e. performing “CRUD” actions) application-relevant data, which will be persisted in the browser’s local storage.
- be deployed to a publicly accessible URL.
- demonstrate your ability to synchronize asynchronous events generally and
- specifically, (for some path through its features) require multiple (>=2) network requests be made dynamically via js to a third-party API (e.g. to a REST API) and at least 1 of the requests after the first must rely on information made available in the response from an earlier request
- this requirement is sometimes difficult to understand. here’s an example of this part: Rhyphy
- when you search for a word
- it will search a rhyming database
- it will display the results
- it will search giphy for a gif for each of these rhymes
- will meet or exceed accessibility and validation standards.
- not be written using a frontend framework (e.g. react, solid, svelte, vue, angular, etc.)
- optionally use third party code such as design frameworks (e.g. bootstrap) and Javascript libraries
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.
- A micro-blogging platform a la X that lets users write short posts.
- An online store and wishlist that allows users to keep track of things they would like to purchase.
- 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 graphs (eg bar charts) illustrating categories of spending habits.
- A note-taking application with a wiki-style interface that lets you update information.
Cross-Milestone Requirements
General Requirements
The following echo the summary above, but go further and this section will be linked from each individual milestone’s specifications to remind you that these apply to every part of the project.
- with a focused theme and audience of your choosing.
- must serve someone besides yourself.
- Thinking empathetically is an important skill to develop for web design, as you need to understand your clients’ vision to bring it to life.
- will meet or exceed accessibility and validation standards
- demonstrate your ability to synchronize asynchronous events generally and
- specifically, (for some path through its features) require multiple (>=2) network requests be made dynamically via js to a third-party API (e.g. to a REST API) and at least 1 of the requests after the first must rely on information made available in the response from an earlier request
- must not be written using a frontend framework (eg react, solid, svelte, vue, angular)
- may use third party code such as design frameworks (e.g. bootstrap), js libraries
Professional Practices and Design Quality
- Your source code must be formatted using a consistent standard. I recommend using the built-in support in vscode for formatting HTML and CSS (other options like prettier may not default to producing valid HTML)
- Your site’s non-HTML resources must be organized:
- Images must be placed in a directory named
images
. - CSS files must be placed in a directory named
styles
. - first-party js files must be placed in a directory named
scripts
. - The PDF files of your design sketch must be placed in a directory named
design
.
- Images must be placed in a directory named
- Your forms and user interactions must incorporate validation to prevent users from entering bad information (such as a start date that is after an end date).
- 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.
- 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.
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.
The content should have adequate and consistent spacing. Text should never* bleed against the edge of its containing box.
- never say never, but seems unlikely to be a good choice
- 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.
- 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.
- The names of your files must be entirely lowercase and contain only alphanumeric characters.
- You should use meaningful comments.
Third-Party APIs
Here are some possible third-party APIs that you could explore for ideas or to support your application:
- GitHub API
- Spotify
- Spotify allows for client-side access using PKCE. Here is a tutorial and demo you can follow.
- see also a demo with a bit more explanation
- Canvas Learning Management System
- OpenStreetMap
- Mastodon’s not X/Twitter
- List of “public” APIs from: this random github repo
- List of “free”* APIs from: RapidAPI
- gifs and more from: GIPHY
Milestones
1.1 - Milestone 1 - Design Sketch
Instructions
Use whatever tools you like such as a slideshow tool or other visual design tool to create a design sketch or “mockup” that depicts your planned web application.
Requirements
🚨 Don't Forget!
In addition to the following enumeration, the Cross-Milestone Requirements apply to this milestone too!- 1.1
- Sketch depicts at least one page in mobile view
- 1.2
- Sketch depicts at least one page in a larger (e.g. "desktop") view
- 1.3
- Has annotations to show the font faces, colors, and sizes
- 1.4
- Has annotations to show the layout and spacing
- 1.5
- Depicts the user interface elements necessary to perform the CRUD actions.
- 1.6
- Has annotations with a matching numerical label to point out where each of the numbered requirements of Milestones 2 and 3 are met by the proposed design.
Example
1.2 - Milestone 2 - Static Site
Instructions
Work with your team to create the beginning of your dynamic web application prototype as a static site. Follow the design you proposed in Milestone 1, incorporating the feedback you’ve received and lessons you’ve learned since then.
Requirements
🚨 Don't Forget!
In addition to the following enumeration, the Cross-Milestone Requirements apply to this milestone too!- 2.1.
- You must use the git repository your professor created for this project.
- 2.2.
- You must publish the site
- 2.3.
- Your site must include a page called report.html that is accessible from URL root of your site, and this report.html must include at least an ordered list where you briefly explain how your site meets all of these requirements (or if you aren't going to meet a requirement, you explicitly write that you did not meet that requirement). i.e. first item in your list should say like
1. this is the url to our github repo which is shared with each other and the prof: http://github.com/... 2. this is the url to our deployed application where anyone could try our app: http://example.github.io/... ... 13. Right now we are thinking that the 2 APIs we will use are https://developers.giphy.com/docs/api#quick-start-guide and https://developer.spotify.com/documentation/web-api/reference
- 2.4
- Your site must support distinct layouts for large and small screens using media queries. Use comments to note where you completed this activity. You may do this in a variety of ways. Consider using this to control images or switching blocks between rows (for large screens) and columns (for small).
- 2.5
- Your site must contain at least five separate pages, each having a meaningful purpose. One of the files should be named index.html. Your pages must link to each other in a logical and meaningful flow.
- 2.6
- Your site must include some sort of header.
- 2.7
- Your site must include some sort of navigation links.
- 2.8
- 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 webcrawlers.
- 2.9
- Each page and stylesheet of your site must validate without any warnings or errors using the Nu Validator and WAVE Web Accessibility Evaluator.
- 2.10
- Your site must use at least two different font faces. Headings are often rendered in a sans-serif font, and paragraph copy in a serif font.
- 2.11
- Your site must include at least one form. The form need not do anything at this point in your learning, but it must be present and it must use built-in content verification. Like all content, it must be neatly aligned.
- 2.12
- Your site must include links to external sites.
- 2.13
- You have some ideas (minimum 2) about network requests you might make to support the next milestone's interactivity.
1.3 - Milestone 3 - Dynamic Application Prototype
Instructions
Iterate on the work you did for Milestones 1 and 2 to finally complete the web application. In the earlier milestones, the focus was on the structure and presentation of the site. Now, the priority is the behavior of the site, but as the final deliverable, you should also make sure that the structure and presentation are complete.
Requirements
🚨 Don't Forget!
In addition to the following enumeration, the Cross-Milestone Requirements apply to this milestone too!- 3.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 is handling)
- 3.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.3
- Your site must use localStorage to store and retrieve updated data values between sessions. I.e. what is displayed as content should reflect these changes. Often these actions are called "CRUD" Create, Read, Update, and Delete
- 3.4
- However you implement the CRUD actions, your implementation should contain forms that
- 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.
- form submissions should include appropriate event handlers to refresh the displayed data
- 3.5
- One possible implementation of CRUD actions in the frontend could be to use a widget such as Bootstrap's modal, but it is not required that you do so. Rather it's required that you use a flow that reflects best practices from around the web. If you choose to use a modal you might:
- have one modal that allows users to add new data values.
- have one modal that allows users to edit existing data values.
- have one modal that allows users to delete existing data values.
- have forms within the The add and edit modals
- form submissions within a modal should include appropriate event handlers to refresh the displayed data likely should also dismiss the modal.
- 3.6
- Your site must provide a Blob to export the current data values as a new JSON file.
- 3.7
- Your site should provide the user a means to clear their data (to start from a fresh beginning)
- 3.8
- Each page and stylesheet of your site must validate without any warnings or errors using the Nu Validator and WAVE Web Accessibility Evaluator.
- 3.9
- Your app must make at least 2 network requests to 3rd party APIs via javascript (e.g. via `fetch`). You must demonstrate your understanding of javascript features to sequence these requests, such that only after you have the response from the first, you make the 2nd request (typically this is because the 2nd request needs to include some information that was directly in or computed form the response to the first request).