🛜 Website – Quarter 2 Project

last updated Tuesday, January 9th, 2024

🔙 to the main Quarter 2 Project page

• Checkpoint due Sunday, February 25th
• Final submission due Thursday, March 14th
• Graded by methodology staff

Overview

You will create a static website that serves as a public-facing version of your report. To get a sense of the types of websites students created in the past, refer to last year’s project websites.

Anyone on the internet may stumble across your website, whether that’s a recruiter that messages you on LinkedIn, your friends and family from home, someone on the internet who Googles your research area, or even an expert who is interested in your results. As such, your website should be targeted towards a general audience. Not everyone needs to know the details of your work immediately; instead, the goal of your website should be to get the general public interested in your project and why it is impactful, and to encourage them to read further if interested. Realistically, nobody is going to read your report or look at the code in your GitHub repository – both of which should be linked from your website – unless they have a good reason to.

Your website will be the most prominent and public-facing of all the deliverables you create. As such, you should strive to create a high-quality website that you and your mentor are proud of. Prior instructors tell us that hiring managers for industry jobs are more likely to respond to candidates who include links to project websites on their resumes!

When creating your website, you may certainly borrow material from your report, but you should reduce the amount of material and make stylistic changes to make it appropriate for a general audience. With that said, your site will contain many of the same sections as your report – expect your site to contain an introduction, a methods section, a results section, and a conclusion section.

• The introduction section should motivate the problem being addressed and justify its relevance to the reader. It should also introduce the methods being used.
• The methods section should describe how you approached the problem. The level of detail provided depends on the target audience.
• The results and conclusion sections (perhaps even just one big section in the website) should talk about the impact of the work.

You can tailor your website for different audiences by hiding in-depth technical details behind links or dropdown menus, like the one below.

Note that your website should be simple and easy to navigate!

• Refrain from using complicated layouts and too many pages - readers like to scroll, not click. All you’re trying to do is motivate your project.
• Pictures and plots should tell your whole story, just like in your poster – just by skimming your figures, readers should be able to get the main idea of what you’ve done.
• It’s a good idea to review what you did in DSC 106.

You don’t need to write everything from scratch – feel free to re-use material from your report. However, your website should feel more informal and welcoming than your report, and so you may need to tailor your language and explanations accordingly.

Requirements

Unless you ask Suraj for explicit permission otherwise, your website should be hosted on GitHub Pages. Fortunately, you already learned how to create websites on GitHub pages – you had to create one in Methodology Assignment 5 last quarter!

In some special cases, your group may be working on developing a “product”, like a dashboard, an application, or some sort of service. If that’s the case, you will create and submit both:

1. Your actual product.
2. A separate, static website that explains your project, according to the guidelines above. This is the way most people will acquaint themselves with your project. You should include a prominent link to your interactive webpage from your static page.

Primary vs. Secondary Deliverables
If your project is a traditional methods or analysis project, your primary deliverable is your report and your secondary deliverable is your website.

If your project is building a product (e.g. an application or dashboard), your primary deliverable is your product itself and your secondary deliverable is your report, though as mentioned above, you must still produce a static webpage, and it is that webpage that you should submit a checkpoint for.

Checkpoint (due Sunday, February 25th)

All that’s required for the checkpoint is that you set up the skeleton/outline of your project webpage. It should contain titles and headers, but doesn’t need to contain content – all we need to see is that you put thought into how your webpage is organized.

To submit the checkpoint, you’ll submit a link to the repository containing the code to your website (not the link to your website itself). The README.md in that code repository should contain a link to the website itself, which we can use to visit your page. Your TA will review your website with you in your Week 8 Check-In.

Follow the instructions here to submit your work. You’ll need to start by creating an artifacts repository.