Colmar Academy - first project - would appreciate criticism

I’ve completed (well, the desktop half of it anyway) the Colmar Academy project. My formatting isn’t to the specified sizes, which in hindsight was a bad idea - made it very unresponsive and hard to format for mobile. Fixing it would require me to rewrite pretty much the whole CSS part of it, and… well, i quite honestly don’t want to look at it anymore. If anyone would like to check out the mess of a code I’ve made and give me a few tips, constructive criticism or anything else would be greatly appreciated.

Repository: https://github.com/AnyaGrimm/ColmarAcademy

and punlished:https://anyagrimm.github.io/ColmarAcademy/

Hi, Yanita,

I just completed the same project, and feel similarly to you about not wanting to look at it anymore! I definitely learned some things along the way though, and I’m lucky enough to have an in-person mentor who showed me some tips and tricks. Some of the things I noticed in your code:

  1. Standard Structure
<html>
  <body>
    <header></header>
    <main></main>
    <footer></footer>
  </body>
</html>

Your code is missing a main element, and the footer is outside of the body. Think of the <body> being “everything you can see on the page”.

  1. Logo uses <strong> element, instead of using CSS to style the span, which you can assign a class to. This is a semantic debate about whether the emphasis is meaningful in the logo text or not, but I would interpret the logo as part of the aesthetics of the site, therefore more suitable to style via CSS, instead of an important structural component of the content of the site.

  2. Several places use <br> to style line breaks, which is technically correct, but your code often uses them in places where it would be better to have a <p> element, so that the text is more responsive at different sizes. Using the <br> means that it will always break there, leaving chaotic formatting at any size of screen other than the one that you used. In general, <br> should never be used to style text, unless you need very specific line breaks, as in address formats or poetry.

  3. <Nav> element can have <a> elements inside it, instead of <span>. And in general, when you put an <a>element, you can also put a placeholder for the link, something like <a href="#"> where the “#” is a placeholder that you can easily navigate to later and paste in a link once it’s known.

  4. A button doesn’t need to be an <input> element if it’s a link to another page. It can just be an <a> styled with CSS to look like a button. If the button is a link to another webpage, it’s semantically more appropriate to use an <a>. If the button is submitting a form with information somewhere, it is more appropriate to use an <input>.

I appreciated the subtle hover transform you added to the linked sections, it made it clear that there was a link there. And good job noticing that the text in two sections was in quotation marks – that was something I missed in my project, and just treated them as regular paragraphs.

As far as difficulty structuring for mobile version, I agree. I struggled to figure this out, and my mentor suggested that I start to learn a “mobile first” design, where you start building your HTML with the mobile version in mind first, and then add media queries and more HTML elements as you build up. He also recommended using something called “utility classes” in CSS, where you assign some page-wide CSS rules to a certain class, such as “display:none” with a class called “.display-none”. Then you can add that class to your HTML element right in front of you, and organize your mobile, tablet, and desktop versions that way. I found this very clear and helpful, and my next project I intend to start it that way, as it was a little confusing working backwards and re-structuring my exisiting code, but it was a good exercise in carefully reading code, for sure.

To be very specific, here is the CSS code for utility classes, which cuts down on how many times you have to write out display specifications for mobile/desktop versions. I even kept it in a separate CSS file called “utility-classes.css” and linked it in the head, just above the “style.css” file, so then both CSS styling files are applied:

/* Responsive utility classes for element display */

/* Classes for mobile screens (and default all breakpoints) */

.display-none {
    display: none;
}

.display-block {
    display: block; /* won't ever really be used, since it 
										is the default display */
}

.display-flex {
    display: flex;
}

/* Classes for tablet and larger screens */

@media only screen and (min-width: 640px) {
    .tablet-display-none {
        display: none;
    }
    
    .tablet-display-block {
        display: block;
    }
    
    .tablet-display-flex {
        display: flex;
    }
}

/* Classes for desktop and larger screens */

@media only screen and (min-width: 1024px) {
    .desktop-display-none {
        display: none;
    }
    
    .desktop-display-block {
        display: block;
    }
    
    .desktop-display-flex {
        display: flex;
    }
}

With the above utility classes, you assign the .class-name directly to the HTML element, then it’s a lot easier to keep track of which element is displaying in which version, because you don’t have to switch back-and-forth between two files.

Hope some of that is helpful!

Wow, this is really great feedback! I just amended my Colmar Project based on the feedback about not using <br for styling - so thank you.

I’d love to see how yours turned out, if you wouldn’t mind sharing the link?

Thanks N

Hi, Natalie,

Glad you like my feedback :slight_smile: You can check out my project site at Colmar Academy

I didn’t do much stylistically/design-wise. I like many of your design choices. I focused my time on learning the nitty-gritty of designing for three separate break-points size-wise.

1 Like

Nice work! Really like how you did the three separate break-points, especially the tablet version - stops the nav links getting too squished and is very pleasing layout-wise. :slightly_smiling_face: