Project: Draft 1 (Static Mock-Up)
- Due Feb 2 by 10pm
- Points 5
- Submitting a text entry box
For this deliverable, you will submit a draft of your Project. Your draft should be a "static mockup"—the completed page design, but no interactivity (so the content is there, but "static"). In short: all of the HTML/CSS work should be done, but it will not have any JavaScript/React (yet!).
- Yes, that means all of the "pages" and views for your app. Think through every possible screen that the user might see, and implement all of those!
In order to make sure that you have all of your "design" work done, you will likely temporarily create separate HTML pages for different views of the app or data. So you might have one page that shows what the initial data view looks like, and then a second HTML page that shows what it looks like after the user has interacted with it. This will give you something to work towards in the second half of the project—you'll write JavaScript that will take the first .html
page and transform it into the second when the user interacts with it!
- If your app will include interactive graphics (such as a chart or a map), you can instead include a static placeholder image that is a sample of what that chart/map may be showing at a particular moment in time. You can create such a placeholder using your favorite graphics editor. Note that if your app cannot be entirely based around an interactive graphic to meet requirements.
Getting Setup
For the project you will be working in the same repo you created for the Project Proposal. You will be adding additional code (HTML and CSS) to what was already present in that repo. Thus you don't need to create a new repo!
You will need to create a new index.html
file in the root of your repo to contain your web app. Note that this is separate and distinct from the proposal.html
page you made for the proposal. This file must be in the root of your repository!
You can optionally create a new feature branch to do your development, merging that back into main
as you finish aspects of the project. This can be helpful for organizing your development, but is not required.
Deliverable Requirements
The draft will be assessed use the same (HTML/CSS) requirements of the final version. Note though that the specification of the draft's requirements are structured slightly differently since the draft focuses on just the HTML & CSS content.
- Be sure and scroll to the bottom for details on submitting this deliverable!
Be sure to also look through the full project requirements so you have an idea of where you'll be going with work! You'll need to "plan ahead" about how you'll be adding interactivity in the future.
Content and HTML Structure
Your project will need to use well-structured and appropriate HTML to define its content.
Site Style and CSS Structure
Your project will need to use CSS to specify a custom design and layout for your app's content. This includes colors, typography (fonts), layout, spacing (margin/padding), etc. The design of the app is up to you: I encourage you to get creative with how information might be presented. You might study examples from related pages (e.g., for related apps, systems, or organizations), or look at design examples such as from CSS Zen Garden Links to an external site., the Bootstrap Expo Links to an external site., or the Materialize Showcase Links to an external site..
Reminder: it is not acceptable to build your page using an pre-defined template (e.g., in which you just fill in the content) or similar "pre-built" work. The site you submit should be entirely implemented by you. You are welcome to get design ideas from other sources or look up how to achieve specific effects, but the entire page needs to be coded by you, not by someone else. If you include more than 1 line of code from another source, you need to include an appropriate citation. You will not receive credit for code you did not write yourself.
Accessibility
As with everything, your web app should be accessible to all users, including those utilizing screen readers. You can ensure your content is accessible by semantically using HTML, applying appropriate headings and sections to make it navigable, and including text equivalents for the visual content (images) to make it perceivable.
Responsive Design
Your web app must be responsive and usable on both large desktop displays and small mobile devices. This means using adaptive layouts and multiple media sizes (e.g., different resolution images for different devices).
Clean Coding Style (HTML/CSS)
A requirement when writing any code is to make sure it is written well. Your code needs to be valid, clean, and readable. You should follow the best practices discussed in class, as well as the style guidelines described in the course text style guide Links to an external site..
Working as a Group
You will need to work as a group to complete this project. Each person will need to contribute to its development—that means contributing code.
All group members need to contribute to all aspects of the code to demonstrate that they understand the material. DO NOT divide up the work by language (e.g., have one person do the HTML and one do the CSS)—this will in fact make it harder to implement the project. A better approach is to divide up the work by "component". For example, maybe someone works on the header and someone works on a navbar. Or have each person work on one "page". Think about the work in terms of features or components, not in terms of implementation. (Do make sure to take time to integrate your work, so that e.g., the header bars match across all pages!)
As with the proposal, you are expected to use git
to share and collaborate on code. Each person will need to make some changes, commit their work, pull/merge the changes from other people, and then push the compiled code to GitHub. While there are other tools that can be used to share code or synchronously code together, we want to see that you're able to use git
version control to do this. Using other collaborative tools such as Zoom to talk to your group members—and even pair-program with them—is perfectly fine—just make sure that everyone writes and commits their code!
We will grade the final compiled work that exists on the main
branch, as well as checking the commit history to confirm that all group members have demonstrated mastery of all of the material. We will be looking to see that each person has contributed substantively to both the HTML and CSS work for this draft.
In addition, you will be required to fill out an initial peer evaluation Links to an external site. to help us evaluate group collaboration. Scores on this assignment will be adjusted to reflect unequal contributions (if any).
Submitting the Draft
In order to submit the draft, you will need to perform a couple of steps:
1. Confirm that the draft is complete
Make sure your project works and meets all requirements (so far). Check for bugs (look at the developer console), have someone else try to use the site, etc.
Also make sure the site works correctly when deployed! Make sure images load correctly, you don't have dead links, everything looks correct, etc.
(Although not required, it's a good idea to also update the
README.md
file to describe your project).
2. Tag Final Commit
For each deliverable, you will need to tag your commit so we know what version to grade. For this deliverable, you should tag it draft-1
Make sure you tag the last commit on the main
branch, and push
the tag to GitHub!
For example:
git tag draft-1
git push --tags
(If necessary, you can tag small fixes as draft-1.1
, draft-1.2
, etc.) -->
3. Deploy Web Page
In order for us to grade your project, you will need to "publish" your styled webpage to GitHub Pages. To do this, you will need to checkout
the gh-pages
branch, merge
changes from the main
branch, and then push the gh-pages
branch to GitHub. You should continue to be able to access your app at
https://info340-wi25a.github.io/project-yourusername/
(or replacing project-yourusername
with the name of your repo)
NEVER MAKE CODE CHANGES ON THE GH-PAGES BRANCH! Always make your changes on the main
branch and then merge
those changes into gh-pages
. gh-pages
should never have any commits that are not previously on the main
branch. This will let you easily publish new versions without needing to manage merge conflicts.
4. Submit Peer Evaluation
All group members need to contribute to all aspects of the code to demonstrate that they understand the material. As with the previous draft, you are expected to use git
to share and collaborate on code. Each person will need to make some changes, commit their work, pull/merge the changes from other people, and then push the compiled code to GitHub.
We will grade the final compiled work that exists on the main
branch, as well as checking the commit history to confirm that all group members have demonstrated mastery of all of the material. We will be looking to see that each person has contributed substantively to both HTML and CSS.
In addition, you will be required to fill out an initial peer evaluation Links to an external site. to help us evaluate group collaboration. Scores on this assignment will be adjusted to reflect unequal contributions (if any).
5. Submit to Canvas
Be sure to add
and commit
the final version of your work and push
your code to your GitHub repository (we will be grading the code on the main
branch). Also make sure you've pushed the final, "publishable" version of your work to the gh-pages
branch.
Then submit both (1) a link to your code repo and (2) a link to your published web site to Canvas using the button at the top of the page.
Since this is a group project, only one person needs to submit the link via Canvas. However EACH team member must fill out the peer evaluation Links to an external site.!
Grading Rubric
In assessing your project, our goal is to determine whether you've learned the course material at a sufficient level, as demonstrated by your project work. This project will be graded on a scale from 0 to 5 based on the below rubric:
Score | Description |
---|---|
5/5 | [Satisfactory] Project meets all requirements, and demonstrates a high level of mastery of the course material. The project is well designed and implemented, functioning without errors or problems and with a high level of polish and refinement. |
4/5 | [Satisfactory] Project meets most requirements, and demonstrates sufficient mastery of the course material. The project may display minor errors or problems with design, implementation, or functionality, or lack some polish or refinement. |
3/5 | [Unsatisfactory] Project meets many—but not all—requirements, and demonstrates partial mastery of the course material. The project may have major issues in design, implementation, or functionality ("works some of the time"). |
2/5 | [Unsatisfactory] Project meets only a few requirements, and demonstrates understanding (but not mastery) of course material. The project may be mostly non-functional, with significant issues in design and implementation. Project may be started but incomplete ("half done"). |
0/5 | [Unsatisfactory] Project is missing or meets no requirements. Project demonstrates no understanding of the course material. |
Note that the categories of requirements listed above should not be considered equal in weight! Additionally note that some requirements, if missing, will be enough for a project to be overall considered unsatisfactory. For example, you can't have a satisfactory project if it doesn't meet accessibility requirements (no matter how impressive the appearance!). Egregious programming errors can also cause a project to be unsatisfactory. Basically you need to make sure to handle things we've noted are really important to have a satisfactory project!
If a team member does not contribute to all aspects of the draft (including substantive HTML and CSS work), that individual will not earn a satisfactory grade on this deliverable.
Remember that the projects are developed iteratively, which is why there are multiple drafts. Part of iterating through a software project is making mistakes and then fixing them. As such, a deliverable that fixes the noted problems in the previous draft will will cause the score in that previous draft to be increased by up to 20%. For example, if you score an 75% on draft 1, fixing those problems for draft 2 can increase draft 1's score from 75% to 95%. This change only applies to the immediately preceding draft (so the final draft won't increase the score of draft 1).
Rubric
Criteria | Ratings | ||
---|---|---|---|
Content and HTML Structure (~20%)
|
|||
Site Style and CSS Structure (~30%)
|
|||
Accessibility (~15%)
|
|||
Responsive Design (~20%)
|
|||
Clean Coding Style (HTML/CSS) (~10%)
|
|||
Published Site (~5%)
|
|||
|