Finished Personal Portfolio: Workflow I wish I knew before building it

Hello, everyone! :smile: :wave:

I’m so happy to announce that finally, after almost two weeks of working on my portfolio, I’ve finished it, and I got my certificate :tada:

Links:

This was my first time building something big. There were many important things I wish I knew before starting so my workflow was not a smooth experience at all. But it let me learn the hard way as I had to search countless times for things I’m not familiar with. The valuable lessons I learned were too much to retain them all in my head and they all seemed to be jumbled. So, I decided to write them down and share them with you all here.

(very long read)

STEP :one: : create a design
Why? Trust me, it’s bad to apply the styles on the spot then code them. The result will turn to a combination of chocolate and raisins or pineapples on pizza! I’ve been there and have done that. Having a design to follow will make the coding part easier (or less hassle).

  • Seize the chance to steal like an artist! This is what artists usually advise people when practicing to draw better. It means to look into other people’s works and copy them. But not totally! Take a part of it that you find good, then try to combine it with your style. I think this can also be applied in web design. Without looking at other people’s cool portfolios, I can’t make a decent-looking one. How can someone create output without ideas as input? Because ideas had to originate from something.

  • To officially start, thinking that it’s an actual personal portfolio is helpful. It made me realize that the webpage’s overall look would likely be based on my brand identity and I’ve noticed this in amazing portfolios I’ve taken as an inspiration. So, I created a logo that would represent myself. Creating a meaningful one can help us avoid providing superficial answers like “I don’t know why I added that, it just looks good.” The following is my logo explanation:

  • JK is my first name initials. The arrows in the background mean “moving forward” because my motto is “I can move on greater things one step at a time.” It’s not seen clearly, but I customized the arrows’ colors starting from the right to slowly decrease or fade along to the left side. I styled this because I think it relates to my thought that every day is a new day to live; yesterdays are not to be dwelled in & should be taken as lessons. Also, I think it shows as “progress”. The thin line between the first and second rows of arrows (which is unclear too), means “with moderation” or “balance” because I’m constantly trying hard to strike a balance between my work and life (like relationships and health). Finally, I chose the color yellow because according to the book “Designing Interfaces” by Hype, it psychologically means enthusiastic and optimistic. These are adjectives that can describe me or how I am. Enthusiastic to learn more. Optimistic about my future.

I’m not yet a professional designer or even a good one. I only used Canva (way simple than photoshop) as my design tool. But I think a practice of building logos, products, or whatever they may be with profound meaning is a start to creating substantial and amazing ones.

One thing I wished for was learning Figma before I started building my project. The following sub-steps could have been done easier through a design tool dedicated to designing web pages. In my case, I was short on time, and I had to show something as soon as possible to my parent. So, I just used Canva which was easy and simple for me to use.

  • After having a logo, I easily knew which colors I can use on different designs I can apply to my webpage. Next was typography. I chose Montserrat because I read an article saying it’s popular and easily readable. I didn’t go for less-known fonts because they might not be always supported. Based on another article, 16px is the minimum font size, but 18px is better as body text. Try to have a look at Medium’s Website as an example.

  • Then I created a “content flow” or how I’ll introduce myself from beginning to the end of my portfolio. I made a draft talking about my projects, skills, and education. For the illustrations representing my texts, I created most of them by combining free shapes and icons in Canva. I converted them into SVG format because actual courses are talking about how they can help increase a website’s performance. I used the yellow waves background for the headings. I thought they make good dividers. I discovered it through Brett’s WebGuide, a collection of his web tools or resources. Naming files should be done either in a camel-case (FileName) or with an underscore (file_name) to avoid confusion. There are other naming conventions too but these are the popular ones. Funny, because I mistakenly used both. After having all these as preparations, I went on making the page’s layout for different screen sizes.

  • Now, this is one of my huge mistakes. I didn’t search and read more about breakpoints for media queries. I treated my 13-inch laptop as the biggest screen size. I forgot about the huge desktops because we don’t have those and I’m used to seeing people with laptops. The largest one is 1920 x 1080 but my webpage was still a one-column layout. So, I had to redo, delete, modify, or add some code in my CSS to turn into a two-column layout on a larger screen like 1360px and up. Indeed, breakpoints for media queries were my breakdowns! :smiling_face_with_tear:

  • Aimed for a fluid design. Meaning a design that transforms from one screen along with different screen sizes. For example, the placement of the navigation menu. After reading an article, I learned that for mobile and tablet screen sizes, an off-canvas menu is a good feature to add, especially if the page’s content is long. While fixed top navigation bar on laptops and a left-hand navigation bar on large desktops are nice to have so that visitors can easily look for anything. I applied them all except for the left-hand navigation bar through pure CSS only. Another example is sizing the images which was difficult to do for me because I want them to have fixed sizes on different screens to satisfy my design preferences. Therefore, determining the breakpoints for the media queries is hugely dependent on your design.

STEP :two: : start to code
At this point, there should be a final web design to follow. The next thing to do is to code it.

  • Doing the new responsive web design beta course was an awesome experience! Helped me a lot to reinforce my learnings from different materials and finish my projects easier.

  • Code in a text editor like VS Code. Lots of useful features like changing all the same words at once and the code can be viewed better than on CodePen.

  • Learn how to use Github even just the basics. If you’re serious about learning web development like me, then this is a must to learn. I don’t know it in-depth yet, but I started using it after like 5 days of working on my project. I was able to share easily my portfolio with other people so it was also easy to get feedback from them. Another reason is it shows how frequent our activities are, like how often do we do our projects? I think it’s nice to show off to potential employers that we’re always grinding!

  • Maximize the use of comments. Learned this practice from Shay Howe. I liked how more organized the code was when comments were introducing every group of styles for the main sections. Aside from that, I used it to create a table of contents on the very top for easier CSS navigation. Creating it made me understand the flow of my code better. Lastly, I added credits on the last part or bottom of my CSS to list all the cool resources I used for my project.

  • Know how to name classes. This is one of the things I really wished I knew before. Maybe I knew but just forgot it. Anyway, this is important! I now try avoiding adding classes to elements with a style name, like class=“red-round-button”. Because you never know, you might change the actual color or shape in the future. There are many articles talking about this topic. I found a good one in FCC news/articles, “CSS Naming Conventions that Will Save You Hours of Debugging” by Emmanuel Ohans.

  • Heavily use the inspect method because it allows us to change stylings on an element temporarily. If we want it, we can just copy and paste it into our editor. It’s tiring to jump between the browser and editor all the time. Another reason is the easier fixing of styles. I lost my mind when I tried a bunch of ways to find out why the styles aren’t applying. This has happened to me a lot. But when I discovered that there’s a line identifier in inspect element mode, my life was saved from going crazy again. Yes, beginner things. Some possible reasons are a new style has lower specificity than the other old ones, or the new style was added way before the old style so the old one will take effect (cascades from top to bottom).

  • Grid or Flexbox? In my case, I used both of them in one design most of the time. Like I used Grid and flexbox with everything from the navbar and buttons down to the layout like rearranging sections in a manner suitable to different screen sizes. There are a bunch of articles or readings though that explain when to use the two.

  • Use markers and a whiteboard when creating a layout. Yes, they’re old-fashioned but still golden. Paper, pen, and pencils will do too. My mind was spinning when I was applying grid and flexbox. When my brain has reached its limit like can’t illustrate clearly where sections are supposed to be, I try to draw the layout on the board with markers. This let me see and understand the layout more, like which line of column or row this element should go.

  • Sometimes check HTML and CSS code at W3C’s validator. It is quite helpful and scary to use. Helpful because it let us know exactly where we possibly went wrong in our code so it’s easy to fix. Scary because of the chance of knowing there are possible errors and we have to redo, modify or delete our code again. I only knew my HTML warnings when I’m so done with my project. I find it difficult to modify my code again because I think everything’s intact. So, to avoid having the same situation, check the code from time to time! Especially, if there are major updates.

STEP :three: : reflect on the learnings
I know this is not necessary. But for me, writing the things I’ve learned makes me learn better. The knowledge is more engrained in my head and it forms a system that lets me pick up or reference back to any information with more ease. On the other hand, when I don’t write them and I proceed to learn other major things, I forget the lessons sooner as they’re all messy in my head.

One main question I ask myself when I do a reflection is “What are the things I’ve learned?” I try to form my explanations of the lessons to have them more impact on me. As they say, you’ve never truly learned if you can’t even explain it on your own.

STEP :four: : be proud and humble
Let’s take pride in our achievement and share it with the world! The course was no easy task to accomplish if one has taken it seriously. If you’re also the person who always targets quality when working, then the process will become hard. But that’s what makes it fun. It makes us work with deep meaning. Not just for simply passing the course like how usually it is in the real world. We study and work because we’d love to learn and have our dream careers. But sometimes, studying and working because we simply need money is okay too. For me, finding the job that suits you or you like takes privilege and luck :blush:

However, let’s try to stay humble too. Too much pride in oneself can hinder growth. Helpful criticisms are blocked as they’re hard to handle or take in. Let’s not forget what Aristotle said, “The more you know, the more that you don’t know.” This is why I didn’t add percentage bars of the skills like HTML and CSS because learning is forever. We could master a part of it, but I think we can’t retain it forever, and we’ll eventually forget some of it. And of course, knowledge always progresses, we can’t always be at the top and catch up on all of them.

So that’s all for my reflection paper :laughing: If you’ve come to this point, thank you so much for taking the time to read. If you found something valuable or to relate with, leave a message. I’d be so happy to know that I’m actually helping and there’s another person going through the same hurdles :smiley:

1 Like

Yeah, that’s how it is. To some extent, these things need to be learned the hard way. With time, you get better at managing these things.

There were many important things I wish I knew before starting so my workflow was not a smooth experience at all.

Most of us aren’t. Most coders are notoriously bad designers. In any non-trivially sized company, there will be someone just for that.

I only used Canva…

I don’t know if it is necessary to go full software at this stage (especially for a single page app), but I do agree that putting some thought into the design is good. On a project this small, that may just be sketching it out on paper.

And there are different work flows. Often I will just sketch the layout, and then add in the “styling” - colors, padding, shadows, etc. Different people work in different ways. But if you’ve found something that works for you, then that’s great.

Code in a text editor like VS Code. Lots of useful features like changing all the same words at once and the code can be viewed better than on CodePen.

That is definitely the long term goal. But some people get overwhelmed with the problems of file management and hosting, so I think it is OK to do the RWD projects on an online IDE like CodePen. After that though, they should start thinking about moving to locally developing.

Maximize the use of comments…

I have to disagree with this. I (and a lot of other developers) roll my eyes when I see code loaded down with a lot of comments. I know they tell you when you’re learning, “comment everything”, but in my opinion, comments are often the sign or poorly written code. There is the concept of “self-documenting” code, code that tells you what it is doing. It is broken into logical chunks, put in well named files, formatted correctly, and given meaningful names. Well written code tells a story.

Granted, you may be limited at the moment in how much you can break up your HTML and CSS in different chunks in different files. These concepts will become more important when you get to JS. But I just don’t want to perpetuate the idea that we need to comment everything. But if you find it helpful, then go for it, 100%. This is tough stuff - do what you need to do. And in all fairness, if I had to write a big HTML or CSS file, I probably would use more comments than I normally do. (One big exception would be annotation markup comments.)

Know how to name classes.

Yeah, naming things is hugely important. Always assume that your code will be read by someone who has no idea what is going on. And I assure you, after a few months not looking at that code, that my be you.

Grid or Flexbox? In my case, I used both of them …

Yes, they serve two different functions and work well together.


But there is a lot of good advice in here for beginners. Thank you for taking the time to write up your thoughts.

2 Likes

I hope so! :smiley:

Currently, I’m aiming for a front-end developer job in a company, and go freelancing after. So, I thought I have to be a decent designer to land one. I’ve encountered many books and courses for developers to learn design. Based on a book I’ve read, the collaboration between designers and developers is often not in sync??? Because the design is usually not followed by the developers. Then to be more competent or different than the rest of the applicants, I have to create products that put UX/UI in importance. This is why I treat design as my number 1 preparation before coding. I guess the design priority level differs from one person to another as people have different goals. My bad, I didn’t indicate this in my post.

I agree there are different kinds of ways to do or solve something. Sketching is good if a person does not know using any software. But I promise Canva is friendly to beginners, and it’s completely free.

I truly respect your thoughts Sir, but I think it’s better to start coding in an editor asap. Because why delay the problem of not knowing how to work with it? It offers a lot of benefits like increased work efficiency. Based on my experience while coding on CodePen, it’s hard to do inspect. Meanwhile, a local file viewed on the browser has been easier for me. Another reason why I avoid CodePen is that every time I update my code, the screen kind of glitches. But that’s the only IDE I know, I don’t know about others. And maybe it only happens to me. But, I believe the time and effort to learn how to use an editor before starting any projects as a beginner are super worth it. Get over with the “overwhelming” soon by slowly starting to get a hang of it.

Oh, I didn’t know about the “self-documenting” code. I will look into that. I used comments too much because I find it overwhelming when my HTML and CSS started to get long.

I’m always happy to help others :slight_smile: and thank you so much, Sir Kevin, for reading and replying to my very long post! I’ve learned something new today because of you.

Hello there,
the freeCodeCamp forum is not a great platform for articles like this. Our community members come to the forum to ask questions, and to engage in conversation. I encourage you to share it on a platform that is better designed for sharing informational content. freeCodeCamp News has several guides on writing and publishing technical articles. Here are just a few:

If you are an experienced writer, and would like to be one of the developer authors for freeCodeCamp News, you can find everything you need to know in the Publication Style Guide.

2 Likes

Thank you so much, Ma’am Ilenia for sharing some resources or guides. I might try out writing on freeCodeCamp News :smiley: I hope I can pass as a writer tho :laughing:

Thank you for taking the time for writing this post. As a beginner I find it usefull, as I can relate to many of the struggles you had.

Also thanks to kevinSmith for clarifying some points, from a seasoned developer perspective, particularly about the “self-commenting” code (something I once knew but forogot). Quake 2’s engine (coded in C, by Adrian Carmack) is said to be such an example.

1 Like