CompSci 290.2
Spring 2018
Web Application Development

Final Project

This project is intended for you to build a significant dynamic web application 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.

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

Your task is to create a web application 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 modularized well enough so it is easy to change the styling and data sources without changing the application's "business" logic.

In general, your web site should allow users to

Your application should follow good program design principles, including the MVC architecture encouraged by the web development community.

Code Libraries

The primary code of your application should be clearly your own work. Beyond that you can combine open source, style themes, or JavaScript frameworks to improve the experience of your site or to process your data in interesting ways. For example, it makes more sense for you to use JavaScript's D3 to generate interactive visualizations of your data than try to build it yourself. In this sense, there is as much intellectual effort in creating a quality application that is a mash up of open source resources than building it all from scratch.

In your final documentation, show that you did research into available code libraries by reporting on why you chose the tool you did or why you decided not to use any.


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

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


To work with a reasonable amount of data, your application should make use of a web service to provide data that can be updated dynamically rather than relying solely on users to input the data directly. 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.

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


Your application should be robust against bad input or bad data and should not crash for any reason (i.e., internal or routing error). This means that you should validate any user input (both on the client and server side) and any JSON data you load before trying to access it. In short, 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.


While it is the case that your application 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 written feedback from at least three people that you think are similar to potential actual users of your application who have used your application. It can be an "official" User Test with specific tasks to complete and survey questions or something more informal where they write general comments after using your application or a recording of them using your application and 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. Include the person's name, when the interaction took place, and the feedback in a separate folder within your GitHub repository.

In addition to the usual validation required for your application, HTML, CSS, and JavaScript, your application should:


Regarding security, any API keys or passwords you use must be checked into your GitHub repository. 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 on GitHub. However, if you ever make your project public, you should take care to hide those values so they cannot be scraped and used against you.


Your application must be accessible from GitHub Pages at all times. That means if it requires a backend component to run, that it must be deployed to a host somewhere other than your personal machine. Duke's VMs or Heroku are good free options to host your application.


The code you submit should be your own. You may look at general tutorials or examples, but even searching specifically for examples or tutorials related to your application will be considered cheating. You must attribute the source of any of the code you copied rather than writing yourself, but you may not copy more than 5 lines of code from any specific tutorial or example (other than those given in class). Any copied code must be commented in your own words as to how it works and it must be tuned to the specifications of your application. We will be checking that your code is consistent in its style, organized, and cleanly written, rather than a mess of combined tutorials. As a reminder, the goal of this project is to demonstrate that you have mastered the material from this course.

Working in Pairs

This project may be done by individually or with a partner (of course, more will be expected of pairs since you have twice the number of people working on it). If you choose to work together, your group will submit one web site with both portfolio sites linking to this one site.

Working in a pair also comes with a special set of responsibilities to maintain academic integrity. The most basic is this: the project must be the joint work of both members. One person doing the great majority of the work does not count, nor does one person coding and the other person designing the site's style. Getting this right is easy: only work on the assignment when both people are there! If both members of the pair are working together (perhaps in front of the same computer), you are in the clear. Plus, doing it this way keeps you from having to deal with merge conflicts within GIT, which is a huge source of pain and suffering. If you have questions about working in pairs, please let us know.

Use this form to either let the course staff know about a partnership you have arranged or to request that we help you find a partner. We will do our best to find partners for any students that want one. If you prefer to work alone you do not need to tell us.


Here are some example ideas:

Of course, there are a lot of data services and sources available on the web, but here are a few interesting examples:

  1. Duke University API Catalog
  2. The Programmable Web
  3. API Marketplace (including Natural Language Processing)
  4. Google Fusion Table
  5. IBM Watson AI
  6. Spotify
  7. GitHub
  8. US Government Open Data
  9. World Bank Open Data


  1. Topic. In no more than 1 page, describe the application you would like to build, what makes it interesting, and a list of possible data sources it may use.
    Your goal is to convince us your project is interesting and appropriately sized.
  2. Plan. In 3-4 pages, describe your plan for building the application, including exact features you will build and what technologies you plan to build them with, as well as an example of actual data you intend to use in your project. A mock up of your site would be very helpful.
    Your goal is to convince us you know how to build your project and that it is appropriate technologically and uses authentic data.
  3. Application. Complete version of your application code.
    You may still add data to it or develop results from it, but all of the coded functionality is complete.
  4. Demo. Show results of actually running your application in front of the class.


To submit this assignment

Your files must display the way you expect in the latest version of Chrome. You are expected to follow the standard coding conventions for HTML, CSS, and JavaScript (within reason).

Only what is in your assignments-portfolio-GIT_SCREEN_NAME repository on GitHub at the deadline will be considered for your submission.