Project: Draft 1 (Static Mock-Up)

1. Your website will need to include multiple pages, each showing different content or different views of the data. Often you can think of each feature as having it's own "view" and URL, and thus being on distinct pages. If the features don't seem like different "pages" of the app, then they may not be different, though it is possible for a single "page" to include multiple features.

   Note that you don't have to make multiple different pages for repeated content. For example, if your "home page" has a list of cards that you click on to view more details, you don't need to make a different detail page for each card—just doing one example/template for the detail page and then having all of the cards link to that is fine.

   You must include hyperlinks to navigate between all of the pages/view (in both directions!)

   The "main page" should be defined in the index.html file. The "main page" is the primary page that the user spends the most time looking at and interacting with. For example, if you were making a social media app, then your "main page" would probably be the newsfeed or timeline, not the "sign in" page (which a user would only look at once!). If you want to have a sig in or "splash" page, that should go in different HTML file (e.g., splash.html or intro.html)

   

2. Any .html pages you have must share a unified "theme" and structure. They must all use a shared .css file (with the same CSS rules applied to content on both pages), so that they have the same styling/theme. This wil demonstrate that you can design effective CSS rules. For the draft, it's fine to copy-and-paste the HTML for shared elements such as navigation bars—you'll remove that code duplication for the final version when you shift to React.

3. Your page content can be structured however you wish, but must include a header Links to an external site. with appropriate content (including the name of your app) and a footer Links to an external site. with appropriate content (e.g., copyright and contact info).

4. Each HTML page must have appropriate metadata Links to an external site.: the index.html page should include the author (you), and a description.

   Additionally, your page must include a favicon Links to an external site. (an icon for the page); you can find lots of free icons at sites such as Icon Finder Links to an external site. or The Noun Project Links to an external site..

5. Overall, your web app needs to have sufficient content to make its layout and styling necessary. Just having a single data table won't be sufficient.

   One way to ensure you have sufficient content is to make sure your app displays multiple different views of your data. For example, you could display a list of cards as one view, and then allow the use to select (click) on a card to see further details on that record as a second view. You can also display your data in different formats (such as a table and a chart), as long as the different views are meaningful and there is a point to having them both! An interactive map (such as one created with Leaflet Links to an external site.) or chart (such as created with Plotly Links to an external site.) each counts as a single data view, and will not likely count as "interaction" (see below).

6. Your web site will need to include both text content and at least three (3) notable images or other media content (videos, etc). You are welcome to use stock images if appropriate. Unsplash Links to an external site., Morgue File Links to an external site., and Pixabay Links to an external site. are all good places to start looking for free images. Make sure you have the rights to any images you use, and include appropriate attribution Links to an external site..

   Note that the text and images on your page will need to be actual content, not just lorem ipsum placeholder text! You're developing a "real" app!

7. Your app will need to include a form (using the <form> element) allowing the user to submit some input to the app to interact with it. This can be a "search" or "filter" form. I suggest you aim to have at least two inputs (not just a single text query) in the form to help make your interaction sufficiently complex.

Below is a "checklist" that you can use to make sure you met all of the requirements for this section.

1.   Includes HTML content for all parts of the app
2.   Includes index.html file (named correctly, in the root folder)
3.   index.html file is the "main page"
4.   Includes multiple pages, with hyperlinks between them (in both directions!)
5.   All pages link in a single CSS file
6.   Includes meta elements in html head: author (index only), description (index only), favicon, title
7.   Includes header element (with app name) and footer (with copyright) elements
8.   Includes sufficient content (e.g., multiple views of the data)
9.   Includes 3+ images or media content
10.   Includes a form element

It is acceptable to use a CSS framework such as Bootstrap when styling your app, though if you do so you must use the most recent version (v5 for Bootstrap) as introduced in class. Moreover, even if you use a framework to help style your app, you will need to include some additional CSS rules of your own to demonstrate your mastery of this material.

As a simple heuristic, something at the design complexity of the iSchool home page or Twitter Links to an external site. would be worth full credit, while something that looks as nice as reddit Links to an external site. would be around 80% credit (satisfactory). And remember: just duplicating features and effects from the exercises will not be worth full credit—do something on your own!

1. You must use CSS to style the page. Define an external stylesheet (e.g., style.css) to contain your rules.

   We expect you to have a few dozen (20-30+) different CSS rules for this project; you will need that much complexity for the work to be satisfactory. These rules would be in addition to any framework provided styling.

   Your page design should include modifications to all of the following: typography (fonts), colors (text or background), spacing (margin/padding), and layout (see below). It's fine if many of these changes are provided by Bootstrap, but you will need to include custom rules yourself. Note that you can use a a tool such as the Material Design Color Tool Links to an external site. to help determine an accessible color palette (and avoid contrast issues). (Adobe Color CC Links to an external site. is another nice color palette tool).

   You are welcome and encouraged to go all-out on the artistry—just make sure that the page's content remains navigable, readable, and usable!

2. In order to demonstrate your development skills, your app must not entirely follow the default "flow" of content. You must also use a flexbox or grid to provide substantial "non-standard" layout structures. A multi-column layout is sufficient for full credit (and see Responsiveness below for related requirements). Note that simply using a flexbox to make elements horizontally "inline" will not be sufficient; you should use something like a multi-column layout.

   It's acceptable to use a Bootstrap grid to meet this requirement.

   Best practice is NEVER use the float or position properties! Use a flexbox instead!

3. Your design (read: CSS styling) needs to be deeply considered with a high level of polish and refinement. This means that you've thought about (and customized!) aspects of the appearance like the color, typography, positioning, etc. While this course does not focus on visual design, we want to make sure that you've actually considered how to use CSS to make a modern and pleasant looking webpage.

   You've all visited popular web sites; you should have a sense for what pages "look good" and what pages don't!

   For us, a polished app design is:

   • readable and navigable: we are able to see all the content, and move through the content without getting confused. Text is large/clear enough to read, buttons say what they do, links are obvious, etc.
   • consistent: colors, borders, fonts, spacing, etc. should be consistent throughout and across pages. Ideally, pages should have a shared visual language: for example, elements that are both "cards" should have similar purposes/meanings (see e.g. the explanation here Links to an external site.).
   • "clean": make sure that images or text content doesn't overshoot its container, that elements line up with each other, etc. There shouldn't be any visual "bugs".

Below is a "checklist" that you can use to make sure you met all of the requirements for this section.

1.   Loads an external CSS style sheet
2.   Stylesheet includes sufficient number of rules (20+)
3.   CSS changes:
   • colors
   • fonts/sizes
   • margins/padding
4.   Uses flexbox or grid for non-standard layout (via Bootstrap is fine)
5.   Has a polished appearance
   • readable & navigable
   • consistent
   • clean

1. For semantic html, this means appropriately using elements such as <main> and <section> (though you don't need the latter if there are no sections), headings are used for headings (not to change font size), that you don't use <i> when you mean <em>, etc. Also remember that <a> elements are for links (navigation), while <button> elements are for interactive elements. Choose the element that reflects what happens when you click on it (and then style it to look however you want).
2. For navigable html, make sure that your headings form a clear hierarchy. Don't skip heading levels. Think of them as producing a "table of contents" for your content!
3. There are particular elements (such as <label>) that you will need to use for forms. Be sure to include them! Links to an external site..
4. Don't forget your alt attributes! If you have an image or graphic that is included via a div or something, make sure to give it an aria-label.
5. If necessary, make sure to use ARIA attributes (particularly if you utilize components of a CSS framework). Remember: ARIA attributes are for when HTML isn't sufficient! Specify role Links to an external site. atributes for interactive elements (such as when you have a div that acts like a button). But don't over-use it; you don't need to specify ARIA attributes for elements that are already semantic!
6. Also make sure that your color choices have sufficient contrast to be accessible. You can use WebAIM's contrast checker Links to an external site. to check; TGPi also produces a good contrast-checking tool Links to an external site..

You can run your web page through an accessibility checker such as WAVE Links to an external site., AChecker Links to an external site., or Chrome Lighthouse Links to an external site. to confirm it is accessible. Or better yet, open up a screenreader such as Voice Over and try listening to your work!

Below is a "checklist" that you can use to make sure you met all of the requirements for this section.

1.   Uses elements semantically (no <i>; <a> for links; etc)
2.   Correctly uses sectioning elements (<main>, <section>, etc); not needed if no sections
3.   Uses Hierarchical headings; doesn't skip levels
4.   Includes alt attributes on all images
5.   Form includes <label> elements (with for attribute)
6.   Includes aria-label and role attributes when necessary (and only when necessary!)
7.   Colors have sufficient contrast

Note that just using a CSS framework such as Bootstrap is not sufficient for this requirement; your CSS must include some media queries to receive full credit.

1. Your site needs to be optimally styled for two categories of screen size: small mobile screens and large desktop screens. In particular, your site needs to be styled to look noticeably and meaningfully different on different screen sizes to accommodate their different affordances. For example, your site could switch to multiple columns as the screen gets large, change the size of cards, add additional images or content, etc. Your media queries need to do something meaningful!

   Styling differences can include layout, white-space, font-sizing, media presence, and more.

   Just having content "wrap" on smaller screens—even if that wrapping is performed with a flexbox—is not sufficient. We need to see that you've used responsive CSS to purposefully and intentionally customize the page for both small and large displays. This may feel a bit forced, but it's part of demonstrating your mastery of the material! Note that using responsive Bootstrap elements (like a responsive grid) can help meet this requirement.

   Remember that you need to do something beyond what is in the exercises to get credit!

2. You must follow mobile-first design principles Links to an external site. when implementing your page. In fact, I encourage you to take a "mobile-first" approach to both your design and to your implementation: make it work on mobile, and then expand to work on desktops.

   Remember to specify the viewport meta so that your page will actually be responsive!

   Using a CSS Reset file such as normalize.css Links to an external site. or Bootstrap Reboot Links to an external site. is a good idea for making sure your site looks the same across browsers.

Below is a "checklist" that you can use to make sure you met all of the requirements for this section.

1.   Specifies a viewport meta
2.   Includes media queries to handle 2+ sizes (at least small screens and large screens)
3.   Mobile-first CSS: media queries at the bottom (modify the small-size default)
4.   Styling changes on media and large screens
5.   Layout is noticeably and meaningfully different on different screen sizes
6.   Page content is polished on all screen sizes

1. All your code needs to be well-organized in your repo. Put CSS files in a css folder, images in an img folder, etc. Don't make us search to find code.

2. HTML code needs to be valid and well organized. For example: you'll need to include the DOCTYPE declaration, close all of your tags, only use block elements inside of block elements, etc. You can use the provided lint tests (and online HTML validators) to help check your work.

   Be sure to avoid any redundant elements! Don't include extra divs or spans if they aren't being used for styling or organization.

   Please also use clear and consistent indentation/spacing when writing your HTML so it's easy to read.

3. CSS code needs to be well designed and organized. Use descriptive class names (not just .thing1). Only use id selectors when accessing DOM elements from the JavaScript; otherwise use class selectors for styling (they are cleaner). Avoid duplicating CSS rules/properties; use a shared class or group selector instead. Be sure and use comments to help organize your CSS (e.g., "block out" which rules apply to which part of the page).

   Remember to use a "mobile-first" approach! That means that your media queries should be at the bottom, after you've defined the "normal" rules.

4. Run your code through HTML and CSS validators Links to an external site. to ensure that they are written properly!
5. When in doubt, consult the course text style guide Links to an external site. or ask us!

Coding style is important for readability (so we can understand your work!) and for maintainability (so you can iterate on this in the future). Thus it is vital that your code is well-written per the requirements of this class. Poorly written code may make a project unsatisfactory until the problems are fixed, regardless of the quality of the site produced.

Below is a "checklist" that you can use to make sure you met all of the requirements for this section.

1.   Organized files in repo
2. Valid HTML
   •   No invalid usage
   •   No redundant elements
   •   Clean and consistent indentation
3. Well-designed CSS
   •   Informative class names
   •   Effective selectors (e.g., no id selectors)
   •   No inappropriate duplication of rules
   •   Organized in file, with comments to "group" sets of rules
4.  Follows all the guidelines in the course text style guide Links to an external site..