Final Project

Goals

• Build a full stack web application
• Learn basic project management and collaborative software development skills

Overview

Working as a small team, you will develop a data driven website using node/express/mongoose.

The types of data used by your program can be based on something in the real world or completely factious. The main requirement is that there must be one type of "complex" data (see below) for each team member to work on.

Each group member is responsible for their own "silo" or work in the project: building functionality for one of the "complex" types of data. The functionality required is an interface for CRUD operations (Create a record, Retrieve and display record(s), Update existing records, and Delete records).

Conceptually, think of pages a site administrator would use, not an end user. In a project implementing a Library, the site should be designed as if a Librarian was going to use it and had full access to make changes to all the data. If you want to make pages that would be more appropriate for an end user of the system - say pages a Library Patron could use to update their contact info or check out books - the logic will likely be significantly more complex.

There are some places where your work will depend on basic portions of your teammates work, but only ~15% of the grade is a shared grade.

Your work for this project may not recycle work for earlier assignments or make direct use of any of the samples from the course (MDN's Library Sample, SuperHero sample). Obviously, you will use similar ideas and techniques, but all your work on this assignment should be new for the project.

What is "Complex" Data?

There must be one type of "complex" data for each team member to work on. A "complex" piece of data is one with at least 4 attributes and that needs to represent some kind of connection to at least one other type of data. (See below for examples.)

A "complex" piece of data is one with:

• 4+ attributes.
• At least one connection to another type of custom data (e.g. a reference to another record, or array of references to other records, etc...).

The second part is the key. Think in terms of something we would model with aggregation in C++.

Not complex:

• A Book that has a title, author, publisher that are strings and a publishDate that is a date is not complex. Although it has four attributes, it does not have any connections to other "complex" data types.
• A BookList that as a string name and an array of Books that are custom Book objects satisfies the connection requirement, but it only has two attributes. It would need at least two more attributes to be "complex".

Making them Complex:

Finding a relationship to generally just involves digging deeper on one or more of the attributes. Look for attributes that are strings that could be made into references to other records.

For example, if we take the version of Book that has four attributes, and change author in Book from a string ("William Shakespeare") to a reference to an Author object that is another custom data type, Book would now be "complex".

If the data type just has too few attributes, think about what else you might want to track. For the BookList data type above we could track the date the list was created and/or updated; or a description of the list; or maybe a reference to the user that created the list; etc...

Often times the relationship will work both ways, like Book and Author. A Book knows its Author and an Author object tracks its books. But it is possible to also only have a one way link. Maybe PatronAccount (in a library system) is going to track which Books are checked out, but a Book doesn't know which PatronAccount currently has it checked out.

It is OK to have extra data types that are not "fully complex" that exist to make another object complex. Maybe I am working on Pokemon cards, and trying to make my PokemonCard object complex. Currently, it has health/power/type/cost, where type is just "Fire" or "Water". To make PokemonCard complex, I could make Type be a new data type. Maybe Type has name ("Fire"), color ("red"), and icon ("fire.jpg"). Now, PokemonCard can have its type link to one of those Type objects and it is complex. Type is not complex (it has no links). So no one could use it as their "complex data type". Instead, whoever is making Pokemon would also make Type.

If you do make an extra data type, you do not have to provide web pages for interacting with it, you can just have some sample items that are loaded into your database and there will be no way to modify them.

Submission

See Canvas for instructions on submitting early and final deliverables.

In general, you will need to make sure your code is pushed to github and turn in a PDF with some documentation.

Your project must be runable from your repository without any changes or additions. I should be able to just do npm install and npm run start and then visit localhost:3000/.

This means that DB credentials, API keys, etc... must be stored in the repository. For a real project this would be a big no-no - credentials like that should either be stored in a config file that is not checked into source control or stored in environmental variables set on each machine.

Scoring Overview

Although you will be doing the project in a small group, most of the score is awarded individually.

Midterm deliverables - 20pts

There will be at least two mid-term deliverables where your team is responsible for demonstrating working versions of portions of your site. Completing these on time will be worth 20% of the overall grade.

Server functionality - 5pts

There should be a start script specified in your package.json that I can use to start up the server.

The server as a whole functions to serve your pages and handles basic errors (404/500).

One score is awarded to everyone on the team.

Page Cohesiveness - 5pts

The individual pages use a consistent navigation scheme and basic styling. The primary navigation looks similar across all the pages. There is a logical "home" page to the site.

It is fine if "something extra" features that someone adds to their pages make them stand out. But, they should still share some of the same basic page structure and navigation.

One score is awarded to everyone on the team.

Planning & Communication - 5pts

The team can provide evidence of task tracking and collaboration. The easiest ways to provide this are:

• Project boards on your github repo.
• A link to a google doc with meeting notes.

Full credit requires ongoing documentation of work in a more formal way than "we talked about it in our group chat". You should have some kind of record of decisions made in meetings, who is doing what, internal deadlines, etc...

One score is awarded to everyone on the team.

Data - 10pts

You were responsible for a type of data with multiple fields that includes references to some other data records. There is a schema defined for your data type and the database is pre-populated with a decent number of sample/starter records.

There should be a single loadData script specified in your package.json that I can use to reset the data in the database if something breaks. It should delete all existing records and add sufficient sample records to demonstrate the functionality of your site.

Information should be stored in the database as logical types. Do not store numbers or dates as strings.

Displays data records - 10pts

Clean, attractive pages to display existing records. Well-structured pages with clean, basic styling is the goal. These do not need to be masterpieces of visual design, but should have some basic CSS to make them presentable and use IDs and classes in the HTML to enable further styling. It is OK to use Bootstrap.

You should display some information about related objects and links to them.

Writeup Question 1: What data did you work on?

Supports Create/Update/Delete operations - 25pts

Provide ways to delete records, update existing records, and add new records.

For full credit, you should support editing at least one association for your object (the reference(s) to other data items).

Even if your data type does not store any of the associations, you should provide some way to modify what is considered related. For example, in the Hero/Team demo, the relationship is stored in Hero. But I provide a sample version where the form for editing a team includes a list to select Heroes.

You do NOT need to provide a way to edit every possible relation to other data types. If your type is the "hub" that connects everything else, just pick one or two relations that you want to provide a way to update on your form.

Delete operation should make sure nothing else in the database still refers to the removed object.

Pages for doing this should follow the same basic guidelines as for the "Display" pages.

Writeup Question 2: Provide a link to where I can find this. Google doc, project boards, etc...

Commit History - 5pts

Your commit history shows granular commits with meaningful messages that reflect the work done over a period of time.

You can find a sample of what a good commit history looks like in this github repo. Commits are very granular and new features are built up over multiple commits. One commit might add some new HTML structure, the next commit adds some CSS to style it, the next commit adds code to handle LaTeX output of the same feature, etc...

You should have more than one commit per deadline (many more than that for the final deliverable).

It is OK to have commits that "undo" previous work. Detailed commits that show meaningful chunks of work are better than a few commits that just show "final" versions of the code.

Something extra - 15pts

Doing a good job on the expected work is 85% of the assignment. The last 15% can be earned by doing something(s) not explicitly requested.

Writeup Question 3:

• What is your something extra?
• Provide CLEAR instructions on how to see it in action and/or what code I should look at to see what you did.
• What did you have to learn to get it done? What was most challenging about it?

Here are some suggestions:

• Implement "user-focused" pages for your data type. These should allow an end user to interact with the records in some "real world" fashion more complex than simple create/update logic. Example: in a library program, add a feature to allow a user to check out and return books. Books that are checked out are listed on the user's profile. A book that has been checked out is not available to other users.

• Build an AJAX based page that allows someone to dynamically sort/filter your data.

• Do something interesting with cookies/sessions to track "favorites", "recently viewed", or something similar.

• Make a json web request API for your data and document it. It should support most of the same basic CRUD options that your website interface does.

• Find a JS library that draws charts/graphs and incorporate it into one or more pages to visualize your data.

• Handle file uploads as part of your data. (e.g. You can upload an image that goes with a new record being added.)

• Do something really complex with the styling for your pages. This can't be a purely cosmetic change - it should involve learning some new techniques and doing something structurally different. Examples:

  • Investigate a different CSS framework (e.g. Tailwind)
  • Learn about SASS and use the npm based Dart SASS to preprocess your CSS. Use some of the features of SASS to make your CSS more modular and easier to maintain.

To earn the full 15%, you need to put significant effort in above the basic requirements. Effort can come through figuring out how to incorporate some complex idea, or via writing lots of code yourself. You can do multiple smaller "something extras" or one that is complex enough on its own to be significant. Although there is not a specific line count, if your "something extra" is just a few lines of code copied from a tutorial or example, it is unlikely to be worth the full 15% unless you can demonstrate that you had to learn a lot to apply that knowledge to your project.

Hopefully, you throw yourself into going deep into one or more things that sounds interesting to you. If you do that, you probably are going meet the "significant effort" requirement naturally. You are welcome to ask me for some feedback on whether something sounds like it is in the ballpark for qualifying for full credit. However, I will not do a formal evaluation of your work prior to grading. (In other words, you can't keep checking with me: 'is this enough?', 'how about now, is this enough?'... to min/max what you do.)

The "something extra" is per student. Group mates should do separate "something extras" - unless you get prior approval, multiple partners cannot receive credit for the same activity While it is fine to help each other, the goal is for each individual to push themselves to figure out something new.