You will work on a team of two (or perhaps three) on a project of your choosing. It should be a functioning website of the nature and complexity of the class example, designed for a practical domain of application. Generally, you should plan to use the tech stack covered in class, but talk to us if you like to consider alternatives.

Project Ideas

We are open regarding project ideas, so consider any domain in which a single-page Web application could be of use. Feel free to talk with us about suitable projects as you draft your project proposal for project #1.

Potential projects include the following real projects suggested by various individuals and organizations.

• Museum Holdings — Professor VanAntwerp’s father works with the Pine River Area Historical Society and with their museum in Tustin, Michigan. They would like a catalog of holdings. Visitors to the museum could point to a QR code and get a short explanation of the object, its significance, links to other similar objects in the museum, and (perhaps) external links/documentation.

  For example, the museum has a collection of antique washing machines. At a basic level, visitors should be able to see how old each is, where they came from, manufacturer, and some other basic information. But the next level would be to point out how technology has changed the way we live (so doing some compare and contrast between the different machines) and point to other examples in the museum, such as the vacuum cleaners, toys, and clothing lines. I’m envisioning an immersive web of physical objects, text/audio/video micro-explanations about particular pieces, longer articles (text, audio, or video) about context, and external links to supporting documentation (be it Wikipedia, or other sources).

  From a software engineering project side, there would have to be one or several platforms to support creation of content, the web of links, and curation of exhibits. There are LOTS of little (and big) museums out there that could benefit from a format like this; the PRHAS isn’t unique in that respect.

  From Professor Jeremy VanAntwerp, Engineering

• Software Engineering Project — You could re-engineer one of the software engineering projects as an SPA (rather than as an Android native application).

Expectations

The project will be an application of what you’ve learned in the course so far, with the following basic expectations.

• Platform — Use the basic platform covered in the course.

• Elements — Format the application using a consistent, pleasing style.

• Complexity — Design and build a single-page application whose complexity is roughly that of the course example.

All code should be well-designed and well-documented. Roughly speaking, basic re-treads of the course example will score in the C range, nicer-looking upgrades of the course example with a one or two extra features (e.g., a separate admin page, new widgets, additional database or UI complexity) will score in the B range. The A range is reserved for more unique applications that serve a compelling need using interesting features.

We expect larger teams to accomplish more based on team size. Suitable extensions include authentication, authorization, separate administration servers.

Deliverables and Grading

The following project deliverables are required:

1. Project Proposal (5%) — This is a half-page vision statement for your project, which can refer to one of the suggested projects above. Submit this as a simple Markdown file (README.md) in the root of a new project directory in your CS 336 repo.

   This is a team project, so you can either collaborate with another one or two students from the class and include all team members' names on your (individual) proposals or suggest potential team members. If you choose the latter, submit a separate (private) text file in Moodle that lists people with whom you’d like (or not like) to work and clearly indicate in your vision statement that you've done this.

2. Project Design (5%) — This is an updated vision statement and a preliminary design for your team project.

   • The updated vision should be an updated version of your original proposal and should include a list the names of all team members. Store this in the README.md.
   • The design should specify:
     • the component structure for your ReactJS frontend.
     • the document structure of your MongoDB backend.
     Store this either as a textual outline (in DESIGN.md) or as an image (in DESIGN.png).

   You can either store your code under a repo in one of the team members’ CS 336 repos or create a new repo. We suggest the latter because it makes sharing and the Heroku deployment easier. You can delete the (now-obsolete) project directories for all other team members. Either way, please register your repo and (eventually) your deployment URL in this spreadsheet

3. Project Walkthrough (5%) — This is a walk-through of your project prototype with us, held sometime before the end of reading recess day. Push a functioning but perhaps incomplete version of your application to GitHub before the meeting and be prepared to run it and explain how it works.

4. Project Showcase (5%) — This is an open session in which everyone exhibits their final project, held during the final exam period in the classroom. Push your (nearly-)complete application to Heroku before the session. Be prepared with an informal, 3–4-minute presentation of your system that acquaints the class with the key application features.

5. Project Submission (80%) — This is your final submission of all your project code and resources, due by the end of the day of the class final. Your project should be properly designed (code: 20%; UI: 10%), implemented (30%), documented (10%) and it should address a compelling/interesting need (10%). Make sure that you include the Heroku URL (or URLs) in the readme file.

Commit all your work for this project in your cs336 GitHub repo under a new project directory. Only one team member will have this directory in their class repo.