Project Document Summary:
Coding Resources:
Use the audience that you identified from your original project.
If your original audience doesn’t represent a cohesive group with relatively uniform goals, revise your audience for Project 3. (Hint: If your audience is arbitrarily specific or overly broad, you probably need to revise your audience.)
Professional programmers make a plan before they code. You should too! Practice planning your code as preparation for your future career.
You are required to plan before you write any code.
Before you write any code in JavaScript, you are expected to plan first using pseudocode. Please do not “design” in code; if you’re doing all your coding first and then reverse engineering or “backfilling” your design journey, then you’re designing in code.
You are required to thoroughly document your design process.
We want to see the ideas that you considered, but didn’t make the final cut. We want to see the evolution of your design and planning and your reasons for changing it.
Revise your plan if necessary.
If you later decide to change your design or plan, you should document those changes in your design journey before you code them. Please don’t delete the old design/plan. Keep it there. The design journey is about documenting the iterations of your site’s design and planning. Be sure to explain why you made any changes. This context is important for understanding your design and planning evolution.
Minor changes do not require planning. How do you know if it’s minor? If you look at your design journey, you should be able to recognize the sketches and plan as the same site that shows up in the browser. Changing the name of a page is minor. Adding a sidebar is not.
Your final design and plan in the design journey should be mostly identical to the final version.
The sketches do not need to be identical, but they should be very close. Small changes like renaming “News” to “Latest Events” does not necessitate a new design. (Although, you should provide a rationale in the design journey for this change.) However, adding in a new two column layout does need a new design and should be documented.
If you need to make changes to your site: Stop. Design it, document it, then code it.
Use client-side interactivity to add a hamburger drop-down navigation menu and a modal to your existing project website to enhance your audience’s experience and help them accomplish their goals.
You must implement a hamburger navigation drop-down menu and at least one modal on the website.
Your hamburger menu should be implemented on every page of the website for narrow widths. The hamburger menu should not be present for wide widths. You will need to use JavaScript to implement this functionality; media queries are not sufficient to show/hide the navigation.
You need to implement at least one modal on the entire website. The modal should be used to enhance your audience’s experience and help them accomplish their goals. You may not implement a cookie banner.
The interactivity must be ambitious, significant, and reasonably complex.
This project should demonstrate your mastery of the course learning objectives. Your interactivity should be impressive. You need to go beyond the basic examples provided in lecture and labs. Implementing a hamburger menu and at least one modal meets this requirement. Copying the course provided examples and modifying them does not.
All interactivity must enhance your audience’s experience and help them accomplish their goals.
Interactivity should serve a purpose in relation to the audience’s goals. Avoid adding interactivity for the sake of adding interactivity.
Tip: Ask yourself “if I were a user of this site, would I find this interactivity frustrating/annoying or helpful?” If your answer is helpful, you’re probably on the right track!
Your interactivity should be familiar to your site’s audience by employing common interactivity design patterns.
Your hamburger drop-down navigation menu should be a small button that appears at the top of the screen for narrow widths. When clicked/tapped the full navigation menu should appear. When clicked again the navigation menu should be hidden away. (i.e. toggle) The hamburger menu should appear on every page of the website. A traditional navigation bar should be used for wide widths; no hamburger menu should be visible for wide widths.
Your modal should be a pop-up box that appears on top of the page when an element is clicked. (This is often used in a grid of thumbnails to show a larger version of an image when the user clicks/taps a thumbnail.) The modal should appear over the entire page. The user should be able to close the modal with a close button in the top right-hand corner. The website should be visible underneath the modal with some form of transparency effect. The modal should fill the entire screen for narrow and wide widths. No scrolling should be necessary to use the modal.
The interactivity must be well-designed. It must employ visual design principles and interactivity design principles.
Your design must make effective use of alignment, hierarchy, contrast, proximity, affordances, visibility, feedback, familiarity, etc.
The interactivity must be fully and completely integrated into your existing site.
The interactivity should look like it belongs on the site. We are asking you to add a feature to an existing site and fully integrate it into the design; the interactivity should not appear “tacked on” and simply added to the site because this project made you do it.
The hamburger drop-down navigation menu must be fully responsive.
If your navigation is not responsive, you will need to update your navigation to be responsive. This means if you use your website from project 1, you will need to design and implement a responsive navigation bar/menu and then make the navigation menu interactive.
You need not update the rest of your site to be responsive. We will only grade the drop-down hamburger navigation menu.
The modal interactivity must match the responsiveness of your existing site.
If your existing site supports narrow and wide devices, so should your modal interactivity. If your existing site only supports narrow devices, then your modal interactivity need only work for narrow devices.
You are not required to make your modal interactivity responsive. You are only required to make your modal interactivity work within your existing design, which may or may not be responsive.
This section may seem intimidating. It’s not meant to be. It’s simply meant to formalize the way you learned interactivity in class into requirements. If you’re implementing your client-side interactivity in the same manner as you learned in class, you’re probably doing this correctly!
You are required to implement the interactivity using the methods taught in this class.
You are required to use the instructor provided snippets (no citation necessary) to implement your interactivity.
No credit is provided for submitting work that uses other methods. If you’re unsure if a method is allowed, please ask.
Why? Because this assignment is about demonstrating that you understand how to communicate between the three browser layers. There are other methods for implementing interactivity that do not demonstrate this understanding.
All code must be your own work and written specifically for this assignment.
The objective of this assignment is to leverage all 3 browser layers (HTML, CSS, and JavaScript) to develop client-side interactivity. To demonstrate this, you need to plan, design, and code for all the layers yourself.
You may not copy the provided examples in class or labs and modify them for credit. Your implementation needs to be 100% original work.
You are encouraged to use the Mozilla reference documentation. However, you may not use tutorials or anything else you find on the internet (or elsewhere) for your interactivity. No credit will be awarded for code taken from online tutorials or code that is not written using the approach we have taught in this course.
Use HTML buttons (<button>) for all user actions.
<button> elements are important for the accessibility of your interactivity.
Note: Use CSS styling to remove the button styling if you don’t want it to look like a button. (e.g. an “x” to close a modal)
The interactivity must be functional for credit.
We are only able to grade your interactivity (design and code) if it is functional. If it doesn’t work, then we can’t grade it. If it doesn’t work, we are not able to provide partial credit either.
The interactivity must be implemented client-side in JavaScript and jQuery.
No external libraries, except jQuery, are permitted. Students are expected to utilize the snippet-based approach as taught in class.
Your interactivity must access HTML elements from JavaScript.
Use jQuery’s $() function.
To change the style (or visibility) of an element, you are required to use CSS classes in your JavaScript code.
You may use jQuery’s .addClass() or .removeClass() to change the styling of an element (this includes showing or hiding).
You may not change an elements style using only JavaScript or coding CSS from JavaScript. You may not use jQuery’s .css(), .show(), .hide(), .toggle() functions.
Your interactivity should dynamically change HTML and CSS using what already exists in each HTML and CSS file; you should not code HTML or CSS in your JavaScript code.
Do not code HTML elements in JavaScript; Do not create new HTML elements in JavaScript (html()). Do not change the text content of an element in JavaScript (text()). Do not code CSS in JavaScript (css()).
Your JavaScript code must be error free. (warnings are okay)
There is no validator for JavaScript like HTML and CSS. To check for errors in your JavaScript you must run your code and test it while checking the Console in the browser’s developer tools. If there are errors in the console, then you have errors in your JavaScript code, and you must fix them.
You should use external JavaScript. Inline or internal JavaScript is prohibited.
Your JavaScript files should exist in the “scripts” folder.
No JavaScript code may exist in your HTML code. This includes using the onclick= HTML attribute.
You may use the CSS :hover pseudoclass.
This does not count as interactivity. It is a CSS feature. Feel free to use it to provide feedback for user actions.
Your submission should follow the standards and best practices set forth in class, labs, and Projects 1 and 2.
As a professional web developer, your client will not give you a rubric telling you that your design needs to be aesthetically pleasing or that you need to name the main HTML file index.html. It is expected that you know the standards, conventions, and expectations of your field. We expect the same in this class.