Foundations: Guide users to distinguish the HTML and CSS versions of their Recipes: Project

[Falciron]

Checks

• This is not a duplicate of an existing issue (please have a look through our open issues list to make sure)
• I have thoroughly read and understand The Odin Project Contributing Guide
• Would you like to work on this issue?

Describe your suggestion

Within the 'Block and inline' module in the CSS Foundation section of the curriculum, step 5 of the assignment has students returning to the Recipes app to apply styling to it. This is a great exercise, in my opinion. It's also the source of confusion and misguided comparison for newer students.

Earlier in the curriculum, students are submitting their HTML-only Recipe app via the 'Submit your solution' button in Project: Recipes and via the creations-showcase Discord channel. When they return shortly after to apply styling to their app, they're updating that code and making beautiful pages.

Right now there's plenty of caution on the Project: Recipes page about not looking at submissions ahead of time and comparing yourself against them. However, by instructing students to update their repository with CSS styling, the curriculum is explicitly exacerbating the problem.

A few students have shared their experiences and discussed different approaches:

• Leave the curriculum alone (No Lift)
• Amend the cautions on the Project: Recipes page (Light Lift)
• Instruct students to fork their project on the Block and Inline module (Light Lift)
• Teach students about Forking GitHub Projects more explicitly (Medium Lift)
• Update Project Odin to snapshot the GitHub repository and Pages website (Heavy Lift)

I'd be interested to hear contributors' thoughts on this issue. If the preferred solution is lightweight, I can also offer my hand to make the adjustment.

Path

Foundations

Lesson Url

Project: Recipes, Intro to CSS, or Block and Inline have the most relevant content right now.

(Optional) Discord Name

falciron

[mao-sz]

I'm personally of the mind to not do anything. We already make this clear in the very first section of the page

And the community submissions page at the top even makes it clear that the project requirements come from the instructions, not the community submissions.

Adding more notes won't really help IMHO. We already point towards this idea multiple times in the page and people still come to the server to ask about exactly what the page clarifies. In other lessons, we sometimes even have great big note boxes saying very specific things and people still miss them or come to ask if it actually means what it says.

I do not think it's sensible to bring branching forward to this point. By Block and Inline, people will have barely had any basic Git practice, so branch stuff doesn't make sense to introduce. I feel it's very sensible where it is, which is near the end of Foundations.

Ultimately, this seems like a necessary evil to me and honestly, I don't think it's much of an evil at all. This is my opinion though and I'll leave this issue open in case other maintainers want to share thoughts.

[rlmoser99]

Thank you for this thoughtful issue and for analyzing the different solutions!

After reviewing the lesson and seeing how many places we address this concern, I have a slightly crazy idea:

What if we remove live preview from Recipe project submissions? Students could still share and view repository code, but wouldn't see the visual comparison when others add CSS styling later. This addresses your core concern without changing the lesson instructions or introducing Git concepts too early.

That said, I also support @mao-sz 's suggestion to leave things as is. We already have multiple warnings in place, and this can be a valuable learning moment about not comparing yourself to others.

I'm curious what you and other maintainers think of this idea.

[Falciron]

I think your crazy idea has merit! Students who look at the codebases might still see classes and IDs throughout the HTML files, but without the visual comparison, the (non-existent) bar for project quality feels lower.

[mao-sz]

While it should be possible to disable the live preview, there are the following considerations:

1. The "go back and add a little CSS to play around with the things you've learnt" bit isn't a project, so there is no project submissions box in the relevant lesson. It's just a little mini task as part of that lesson's assignment. So removing the preview in the Project won't solve anything because they're not previewable in the Block and Inline lesson (nor would it make sense to make them; that lesson is not meant to be a project). This isn't the only instance where we do something like this in lesson assignments; while those do come after the content on branches, I know for a fact many will have forgotten about branches by that point and so the original submissions will still have "later content" viewable in the original project pages - I personally have not seen many (if any) issues in the community relating to these later projects/lessons (e.g. JS Library project -> refactor with Class syntax).
2. On top of that, I imagine people will be very confused why they're instructed to deploy the site on GH Pages only to not be able to share that link if they submit.

I think it'll actually make things more confusing if we removed live previews from it.

All in all, we already state what the purpose of the project is as well as that we will be revisiting it later to add some CSS (after we learn about CSS). We also have mountains of stuff specifically pointing towards "community submissions are not the requirements/expectations". There will always be cases where, despite all that, people still miss or misunderstand these, and end up using community submissions as an expectations list, and that's something we'll never be able to fully eliminate. For example, I've responded to people in the server who have legit asked "I haven't learnt about CSS yet and I know the project says we'll come back later to add CSS, but still does it expect me to add CSS?".

Hence I personally am chalking this up to some self-doubt that's always going to happen, and can easily being resolved if someone asks in the community by pointing to what the project already says, or confirming it does indeed mean what it says. Which is why I'm inclined towards "no action".

[rlmoser99]

@mao-sz Great points! Thanks for taking the time to lay this out so thoroughly. Glad I prefaced that the idea was crazy!

After reviewing the lesson again, I think we could improve the final note by making it specific to this project, then building on it to apply to future community solutions. Here's my suggestion, though I am open for suggestions:

###  Community submissions

<div class="lesson-note" markdown="1">
#### Many community submissions will have styling

In future lessons, you will learn CSS and add styling to this project. When viewing community submissions, you'll notice many have already added this styling.
</div>

When viewing community solutions (after you've completed your project), keep a few things in mind:

- Learners often revisit older projects to improve them for their portfolios
- Some people start the curriculum with previous programming experience
- Project requirements sometimes change over time

**Focus on meeting the project requirements rather than comparing yourself to others.** Community submissions are helpful for seeing different approaches, but they don't represent what your project "should" look like at this stage.

This applies for future projects too. For more information read ["Learning Code" from "Becoming a TOP Success Story"](https://dev.to/theodinproject/learning-code-f56).

Edit: because that raw markdownwas not very readable... Here is a screenshot with the previewer:

[mao-sz]

That seems sensible, looks good to me.

Edit: Referencing a PR below which will address a lint error that'd come up with the above regarding heading levels after the assignment section.

[Luigi-Vetere]

If no one take this one, I would like to help

[rlmoser99]

@Luigi-Vetere All yours! If needed, feel free to ask questions here.