Skip to content
  • Unlock Pro
  • Log in with GitHub
Solution
Submitted over 2 years ago

Frontendmentor Responsive Portfolio Website (Premium Challenge)

Manish Panda•30
@mkpgtr
A solution to the Single-page developer portfolio challenge
View live sitePreview (opens in new tab)View codeCode (opens in new tab)

Solution retrospective


The following are the problems which I faced while building out this website (also listed in the readme.md file):

  1. Disorganised CSS:The whole process of building this website was filled with lots and lots of problems. And the end-result might look somewhat okay but there are many problems which could have been overcome if I had a better plan to tackle them early on.

  2. Problems caused by focusing on section too much: When I first started out building this project, the grid that lays out the hero-section was behaving very weird. I was so caught up in solving these hero-section grid problems that I did not plan the css-variables well from the figma file. This might have led to problems in typography. And this might have caused the "Adam Keyes two appear in two lines instead of one(as given in the figma file)."

  3. Unpredictable layout problems:My layout had so many problems due to which I had to manually set margins and paddings for different media queries. This was so hard that it sucked my joy out of the process. I think I need different classes like section and container to align things properly. I definitely need help on that. This somewhat got okay when I applied justify-content:space-between in the skills section. But it was just out of trial and error. Layout felt very mysterious and very difficult.

  4. Too much repetitve code :I never used the DRY principle. I have repeated myself over and over again. It was all brute-force. It could have been much more elegant and smooth. I need help on that also. I need to learn how to write reusable classes. For example : the green underline should come from .underline styles defined in style.css only at one place.

  5. Changing styles manually caused lots of problems in other sections:By the time I felt like I might eventually mess the whole layout, I impatiently wrote the css for skills section and projects section. This led to more trouble cause there was lots of unorganised code in my style.css. Because I know Kevin Powell's youtube channel, and I have seen him organise things in a very clean manner I thought it's a good idea to do things the brute force way and submit it on Frontend Mentor and then get feedback on my mistakes. I am aware of some of the mistakes and I know there are many more that I am not aware of.

  6. Form validation: The Contact Form's Javascript is little bit taken from MDN and somewhat customized to meet the project requirements. But there must be a better way to handle errors. I still was not able to get the warning icon in the input box. Also, the email validation does not work as expected. Tweaking the MDN code in my app.js did not follow clean code standards. It could have been much elegant.

  7. The Contact Form's grid layout was messed up because I had disorganised padding and margin(I am just guessing).

  8. Over using !important: This happened all the time. It somehow worked while I was doing media queries. But I think so much !important is not necessary.

  9. In many places I felt like I am rushing to make a submit on Frontend Mentor. This might have caused lots of wrong decisions while writing CSS.

  10. overlay effect: The links that appear on hovering over the project image are very light. I guess I did not understand how opacity works. I took a little bit help from w3schools.com but that did not help me much.

  11. Problematic typography font-sizes: I did not touch the font-sizes much because everytime I changed a font at one place, my layout was breaking and getting messed up.

  12. Different classes for displaying different size hero-image: I had to write four different media queries for showing and hiding hero images. I could have used srcset just like Jessica Chan from Coder Coder did.

  13. Inconsistent border bottom in form validation: I had already spent 1 hour on form validation and setting border-bottom color on empty-field, valid and invalid inputs. Something was not working right so I had to revert back to this current version. Like I said, form validation could have been way more better. I really need a standard set of steps to implement form validation in a much more predictable way.

  14. Problems I might have missed: I am a beginner. I might have missed lots of problems. I would love to hear about them and how they can be fixed. After deploying on netlify, there might still be some layout issues.

  15. I will obviously implement the feedback in the next project. But for this project, should I refactor my present code? I am kind of burnt out doing this project for the last five days and I feel like I should start a new project I think like I am obsessing too much. Should I start a new project? Please guide me on how to keep moving and having fun along the way.

Code
Loading...

Please log in to post a comment

Log in with GitHub

Community feedback

No feedback yet. Be the first to give feedback on Manish Panda's solution.

Join our Discord community

Join thousands of Frontend Mentor community members taking the challenges, sharing resources, helping each other, and chatting about all things front-end!

Join our Discord
Frontend Mentor logo

Stay up to datewith new challenges, featured solutions, selected articles, and our latest news

Frontend Mentor

  • Unlock Pro
  • Contact us
  • FAQs
  • Become a partner

Explore

  • Learning paths
  • Challenges
  • Solutions
  • Articles

Community

  • Discord
  • Guidelines

For companies

  • Hire developers
  • Train developers
© Frontend Mentor 2019 - 2025
  • Terms
  • Cookie Policy
  • Privacy Policy
  • License

Oops! 😬

You need to be logged in before you can do that.

Log in with GitHub

Oops! 😬

You need to be logged in before you can do that.

Log in with GitHub

How does the accessibility report work?

When a solution is submitted, we use axe-core to run an automated audit of your code.

This picks out common accessibility issues like not using semantic HTML and not having proper heading hierarchies, among others.

This automated audit is fairly surface level, so we encourage to you review the project and code in more detail with accessibility best practices in mind.

How does the CSS report work?

When a solution is submitted, we use stylelint to run an automated check on the CSS code.

We've added some of our own linting rules based on recommended best practices. These rules are prefixed with frontend-mentor/ which you'll see at the top of each issue in the report.

The report will audit 1st-party linked stylesheets, and styles within <style> tags.

How does the HTML validation report work?

When a solution is submitted, we use html-validate to run an automated check on the HTML code.

The report picks out common HTML issues such as not using headings within section elements and incorrect nesting of elements, among others.

Note that the report can pick up “invalid” attributes, which some frameworks automatically add to the HTML. These attributes are crucial for how the frameworks function, although they’re technically not valid HTML. As such, some projects can show up with many HTML validation errors, which are benign and are a necessary part of the framework.