Final Project

This project is intended for you to build a significant dynamic web app on a topic of your choosing that also provides a JSON web service. As Harvard's CS50 Final Project puts it:

All that we ask is that you build something of interest to you, that you solve an actual problem, that you impact campus, or that you change the world. Strive to create something that outlives this course.

Here are some motivating examples:

• Ushahidi crowd sources user's notes based on location and time (it is really that simple!)
  Originally developed as a small application to help report election violence in Kenya, it has been generalized to achieve a variety of results.
• Massachusetts Covid Vaccine Appointments crowd sources Covid vaccine availability reports to provide searchable access
  The developer's story (and how she wrangled volunteer help) is told in this Podcast and how it is still better than what the state's government provides
• Purple America: uses US Election Atlas and US Census TIGER data to display election results in a novel way
  The visualization was last updated in 2004 because it not designed to be automatically updated but the idea led to a national movement.
• Seeding in the NCAA Men’s Basketball Tournament: When is a Higher Seed Better?
  A research paper by Professor Sheldon H. Jacobson, that went viral and has since been turned into a bracket odds website.

You can earn extra credit if you really do change the world (although it might need to be given retroactively :)

Submission

This project will be added to your portfolio_NETID repository as directed below. To submit this project:

• create one separate folder for the entire assignment that contains:
  • index.html: a welcome page that includes
    • a high level description of your project idea
    • a high level description of how it works (its structure, algorithms, data processing, etc.)
    • attributions for your data sources, assets, libraries, etc.
    • links to the main app page (dist/index.html), your final demo video, and the JSON data returned by the server
  • reports subfolder: HTML pages describing your project plan and progress reports for each deliverable, as well as any other supporting materials for these pages
  • src subfolder: any JavaScript file(s) source files to implement the app
  • src/assets subfolder: any assets (e.g., images, audio files, etc.) or local resources used to support your app
    This folder can be put in the front- and back-end subfolders instead if its content is not shared.
  • src/secrets subfolder: any API keys, tokens, or throw away passwords needed by your app
  • dist subfolder: the generated JavaScript and asset files generated by Vue and actually used by the browser (including the main index.html page representing your app)
  • data subfolder: a "local" version of your data source(s), either to serve as an example or as a backup in case the primary site/database goes down depending on its size
  • user_feedback subfolder: the feedback from at least three users in whatever format you captured it
  • a README file (in plain text or Markdown format) describing your work on the assignment as well as
    • special instructions needed to set up, run, access, or use your app (like user passwords you have set up, command line utilities, or external programs that need to be run)
    • references for your data that establishes its authenticity
    • description of your database data structure
    • description of the different goals/access for different user types
    • description of the bad input/data and other error conditions you actively check for
    • discuss both the pros and the cons of different framework possibilities you considered and why you made the decision you did (including choosing not to use any framework)
• then add a very obvious link on your Portfolio web site to each page you have made for each deliverable

Your page(s) must

• display the way you expect in the latest version of Google's Chrome browser on the course Gitlab server
• be written following standard Coding Conventions that is validated using ESLint (JavaScript) or online (Accessibility)
• not produce any warnings (within your control) or errors in the DevTools Console

Specification

Your task is to create a web app that supports your idea; it can be an original idea, or a scaled down version of a popular web site that is improved in some way or directed towards a different problem. The exact user experience, navigation, and look of your website is up to you but all "pages" should have a similar look and feel. Since this is the final project, it should show off all that you have learned in terms of producing an appealing, interactive, web site that is not limited by containing hardcoded values that could be part of a data structure and is modularized well enough so it is easy to change the styling and the location of the data sources without changing the app's "business" logic.

In general, your web site should allow users to

• interactively load and update data from multiple sources that is then organized and persisted within a database
• interact with the cumulative data in a useful way
• view the cumulative or individual data in multiple ways
• keep track of individual preferences regarding users of your web site

Your app should be written using JavaScript, with the Vue framework, and follow good program design principles, including the MVC architecture encouraged by the web development community, small components rather than one monolithic app, and standard coding conventions that have been validated.

Roles

Your app should support authenticating users in three different roles as follows:

• Guest, who can only browse the site, but not edit any data and not store any preferences
• User, who can edit online data, as well as store and update preferences
• Administrator, who can see logs of the app's users and how often they access the site

This implies that certain links or buttons should either require authorization or only appear when appropriate (note the difference between authentication and authorization).

Service

Your app should include a web service of your own design, and deployed on a server, that provides data to your web page as a single source (either directly to your app or to your database). Ideally, the data should be able to be updated dynamically (i.e., users can enter additional data to correct or augment the original data sources). You may scrape data from HTML pages or use program-generated "fake" datasets if real ones are too difficult to obtain but those results should be stored in separate data files (like JSON) so it is easier to switch to a live data source if it becomes available.

Additionally, make the data from your app available to others in JSON format so they do not need to scrape your web site.

This service must be accessible on Gitlab Pages at all times so it must be deployed to Heroku (or somewhere other than your personal machine).

Robustness

Your app should be robust against bad input or bad data and should not crash for any reason (i.e., internal error) so you must validate any user input (both on the client and server side) and any JSON data you load before trying to access it. Essentially, if you expect your data to have a specific format, range of values, or be non-null, you must verify it rather than simply expecting it is.

Submit a log of all the bad input/data and other error conditions you actively check for in your app.

Code Libraries

The primary code of your app should be clearly your own work. Beyond that you can combine open source Vue Components, style themes, etc. to improve the experience of your site or to process your data in interesting ways. In this sense, there is as much intellectual effort in creating a quality app that is a mash up of available resources than building it all from scratch.

Submit your research into available code libraries by reporting on why you chose the tool you did or why you decided not to use any.

Usability

While it is the case that your app will not be judged based on its appeal or usability, it is important that you get some feedback on your site regarding those aspects. Thus you must get feedback from at least three people that you think are similar to potential actual users of your app who have used it. It can be an "official" User Test with specific tasks to complete and survey questions or something more informal where they make general comments after using your app or a recording of them talking out loud about their reactions while they are using it. Whatever you choose, the feedback must be in the user's own words not your interpretation of what they said or what you remember them saying, so a Google form, email, or recording are good records.

Submit the person's name, when the interaction took place, and the feedback in a separate folder within your project folder in your portfolio repository.

Responsive

Responsive Web Design was coined by Ethan Marcotte based on the notion of responsive architectural design, whereby a room or space automatically adjusts to the number and flow of people within it. A website is said to be responsive if it works effectively on both desktop browsers and the variety of available mobile devices that are now used more often to visit web sites and people who browse while on-the-go have very different needs than those sitting at a desk. Responsive web sites reorganize themselves automatically according to the device viewing them.

While BootstrapVue will handle most of the basic responsive layout effects (via its grid structure), your styling must follow these guidelines:

• Images should display at 100% size within the containing tag in which they are placed instead of fixed size
• Specific numeric values over 30 pixels must be given as percentages
• Use CSS media queries to change at least one thing for at least three typical screen widths (even if it is just the background color)

You can use this site or the Chrome's Device Toolbar to check your website on different devices (including landscape orientations). Since the specific look and feel requirements are largely up to you, you must describe what you were trying to accomplish in your README file so we can tell if what we see is intended or a bug.

Testing

Automated testing is a very important topic, and some would also say it was a moral imperative, that we did not have time to address adequately during the course. However, for this project you must demonstrate that you can at least set up and run some automated tests for both the front- and back-end parts of the project. Your tests do not have to be comprehensive (although they certainly can be :) but they must include at least the following:

• at least one example JSON or database data with known initial values that will result in known computed values
• at least four back-end tests to verify the JSON data returned the expected values (including at least two that produce expected error results)
• at least one front-end test to verify your code displays the backend's JSON data correctly by checking the appropriate HTML elements are displayed
• at least four front-end tests to verify your code works as intended by simulating common user "actions" and testing that the GUI responds appropriately

You may use any of the many testing frameworks available, but we recommend WebDriverIO.

Security

Any API keys or passwords you use must be checked into your Gitlab repository (so do not use personal accounts for this project). This is generally not a good practice (unless required by the library you are using like Firebase or Google Maps) but, in this case, necessary so we can access it properly when grading your project. In general, this is okay because your project repository is private. However, if you ever make your project public, take care to hide those values so they cannot be scraped and used against you.

Deliverables

The written reports below must be located in your project's reports folder (including any supporting files), with each linked to from your Portfolio web site, and presented in plain HTML/CSS (i.e., not raw text, Markdown, PDF, Word, or PowerPoint). Note you can generate clean HTML from Markdown (but not from Microsoft files or Google Docs :(.

1. Plan. Convince us your project is interesting, appropriately sized, uses authentic data, and that you have a plan for building your idea (no code required)
   • Screenshot
     • Include a screenshot of a mock up of each of the views of your app to show how you intend it to work (this is not intended to be a working version, instead you are encouraged to use a modern drag and drop layout tool for web or desktop apps (such as Wix.com, Figma, or Adobe XD) to create a rapid prototype that can be shared, commented on, and updated easily)
   • Written Report
     • Idea. Describe the app you want to build — what makes it useful, interesting, or different from an existing site
     • Scope. Describe the app's features — what what it will display, how it will be interactive, what will be done on the user's computer and what will be done on the server (if necessary), what will be your core features, what will be optional features, and what technologies (libraries, components, etc.) you want to use
     • Data Sources. Provide a list of possible data sources the app would use, including an example of actual data from each source and how you plan to import it if it is not already provided as JSON (i.e., CSV or via web scraping)
     • Data Structure. Describe the data structure that will support the app and thus be stored in a database so it persists and is sharable
     • Schedule. Provide a rough timeline of the order in which you will you tackle the app's features — list specific features/goals you intend to work on (and then demo) during each week and how you will "test" it along the way to ensure you are confident it works as it scales from small example data to live data
     
     
2. Progress Check 1. Show progress based on meeting your Plan's schedule (code required)
• Demo
  • Record a 3-5 minute video showing the current state of your web app that is publicly deployed (i.e., not running just on localhost). If just the backend is working, show the JSON returned when accessing different URL endpoints; if just the frontend is working, show it reacting to user input with hardcoded/dummy data; or shown both working together. For each feature, describe the expected results before they are actually shown and how close to "complete" you feel it is. You can use Zoom or there are many free screen capture tools available or free trials of some pretty powerful tools as well.
• Written Report
  • Data. Describe the structure and important fields in the data that will drive your web app (i.e., what you need from the API/scraped data or why you need all the data entered by the user). Also, provide a link to actual JSON data you plan to use in your project, e.g., the results of an actual API call, the results of scraping a web site, or example user entered data.
  • Progress. Describe your progress on the features/implementation you planned to have been completed so far and, for any that are not yet finished, what is needed to complete them.
  • Concerns. Describe anything you have discovered, through research or by implementing specific features, that may block your progress or complicate your plan.
  • Learning. Describe something specific you have learned working on this project (i.e., outside of class lecture/readings); it can be technical or about managing (web) projects in general.
  • Plan. Describe your goals and priorities for the next project deadline as well as any changes to the overall web app you intend to make based on the TA's feedback or anything else you have learned from working on the project so far.
  • Summary. How are you feeling about your progress and the project's overall feasibility at this point?
  
  
3. Progress Check 2. Show progress based on meeting your updated Plan's schedule (code required)
   • Demo
     • Record a 3-5 minute video showing the current state of your web app that is publicly deployed (i.e., not running just on localhost). If just the backend is working, show the JSON returned when accessing different URL endpoints; if just the frontend is working, show it reacting to user input with hardcoded/dummy data; or shown both working together. For each feature, describe the expected results before they are actually shown and how close to "complete" you feel it is. You can use Zoom or there are many free screen capture tools available or free trials of some pretty powerful tools as well.
   • Written Report
     • Data. Describe the structure and important fields in the data that will drive your web app (i.e., what you need from the API/scraped data or why you need all the data entered by the user). Also, provide a link to actual JSON data you plan to use in your project, e.g., the results of an actual API call, the results of scraping a web site, or example user entered data.
     • Progress. Describe your progress on the features/implementation you planned to have been completed so far and, for any that are not yet finished, what is needed to complete them.
     • Concerns. Describe anything you have discovered, through research or by implementing specific features, that may block your progress or complicate your plan.
     • Learning. Describe something specific you have learned working on this project (i.e., outside of class lecture/readings); it can be technical or about managing (web) projects in general.
     • Plan. Describe your goals and priorities for the next project deadline as well as any changes to the overall web app you intend to make based on the TA's feedback or anything else you have learned from working on the project so far.
     • Summary. How are you feeling about your progress and the project's overall feasibility at this point?
     
     
4. Final Demo. Show final results of your web app
   • Demo
     • Record a 4-8 minute video, with voice over describing what is happening in the code, and where it is happening (browser, server, or database)), to show the following:
       • all the features of your publicly deployed web app, i.e., running through Gitlab and Heroku (in case we cannot access some feature due to a bad API token or down API)
         To avoid wasting time, please have Heroku ready to go before starting the video so there is no delay accessing it
         
       • all your tests run and pass locally (i.e., running on localhost, through a proxy if you use that feature), describing what each is testing
         To avoid wasting time, please have both local servers already started before starting the video so there is no delay running your tests
       • one URL access in your browser to your deployed server that returns JSON data, e.g.: https://PROJECT-NAME-ID.herokuapp.com/api/getdata
         Basically, just show us interacting with two different tabs in your browser (Gitlab frontend and Heroku backend) and running your tests live in your Terminal
         
   • Code, README, and User Test Feedback
     • All other supporting deliverables required for the project in their appropriate folders in your portfolio_NETID repository