Solid Tips On How Get Better At Responsive Web Design | Hacker Noon

Author profile picture

Better Responsive Web Design, A Structured Approach

Every front-end web developer will tell you that responsive web design is crucial in building a modern website or web app. However, unless you’re a leet coder who is too cool to admit that CSS is frustrating, you would also know that it can actually be pretty difficult to build a responsive design properly. This is why I wanted to provide a framework for responsive web design principles. Something that will help you build out better responsive designs, without making the same rookie mistakes I did.

It is critical to mention that there is no ‘right way’ to build a responsive website. My hope is that you take this as a foundation to build your knowledge moving forward. Instead of getting lost in the noise of various unrelated responsive design principles. I can’t lie, when I first began my journey as a self-taught developer, I made a lot of mistakes when building out my website frontends. Most of which caused a lot of ‘bugs’ that were not intuitive to go back and fix without breaking at different viewports and browsers. So yeah…

The thing is, these mistakes would have been easily avoided given some prior planning and knowledge of proper responsive CSS practices. Practices that can help any developer enhance their front-end skills! So, to all my backend friends and beginner frontend developers, I made this with you in mind. You’re welcome.

Responsive Web Design Tips And Techniques

Before we begin, I wanted to state that this post will focus on building frontends from scratch. Frameworks like Bootstraps can be a great asset in writing responsive designs easier and faster but building out frontends without using frameworks as a crutch will give you a lot more freedom in what you build. So for that reason, we will not be covering the use of bootstrap. Although these tips will certainly still help if you do. Also, if you are a complete beginner and don’t know HTML yet. I suggest you start here because this post may be a bit too advanced for you.

What Does Responsive Web Design Mean?

Responsive web design is an approach to designing websites that focuses on providing an optimal composition and scale of elements for each screen size it can be viewed on. In 2020, this is the most common approach to designing websites and is considered best practice. It truly is the only way you should be designing your websites and applications. Gone are the days where a static desktop site can acceptably be viewed on mobile devices. In today’s world, responsive web design is synonymous with modern web design.

Part A: Designing Before You Code

The first step to creating a well-structured frontend is to realize that designing and coding are two separate actions. It is much more difficult to write lean, DRY code when you don’t have a strong mental concept of what you are building. Understanding all the visual aspects of your web app on small, medium and large devices will allow you to plan how you are going to code later on. However, if you take the “code as you go” approach, you are inevitably going to introduce unnecessary and overwritten CSS styling rules into your application and have to constantly re-work your design. Which takes considerably more time with code than with some sort of mock-up tool.

If you are new to building wireframes/mockups for your web projects, don’t worry, there are many options available online. If you are comfortable with the Adobe Suite, Adobe XD is a great free website mockup software that allows you to build out designs quickly. Below you can see a screenshot of one of my wireframes for a site I was building. As you can see, it displays each webpage with a mobile, tablet and desktop version in mind.

Looking for a quicker way to build out wireframes without learning a new piece of software? Hand drawing out your designs before you code can be an easier, more manageable way to plan out your designs before you code. If you are building a small website for fun or don’t care too much about the design aspect, this is a great alternative. Just remember that the more effort you put in, the better your end product will be!

Part B: Planning The Macro Code Structure (The Mobile-First Design Strategy)

Once you have taken the time to draw out the visual design of your application, it’s time to start planning the macro design structure of your codebase. This structure is aimed to look at the codebase as a whole. The design strategy I am going to explain here honestly changed my life as a front-end developer and made the process of both building and also maintaining my CSS code so much easier. Especially in contrast to taking an unstructured approach. The concept behind the mobile-first design is simply to build your application for the smallest device size first and make changes to larger screen-sizes as required. It may sound simple but it holds a lot of benefits if done correctly. Here is the structure:

As you can see from the structure above, we keep our base styling outside of media queries and only use min-width queries as we move up. This is key to mobile-first strategy. It inherently builds upon itself in a way that allows for easy and predictable modifications. If the code base is always moving upstream, we know that the base styles will apply to everything but the styles applied at each breakpoint will only affect the following larger device breakpoints. Making troubleshooting and code changes much more predictable and manageable. This approach also allows for every screen port to be accounted for, simply by following the structure.

Why The Mobile-First Strategy Is Great

As a novice developer, I would always attempt to build my websites with desktop in mind, then make it responsive by building down to mobile and up to larger devices. This is a very bad way to approach responsive design. Your base stylings are now likely trapped in the middle range of your device sizes and you have no idea how a change made on one device size will affect another. Leading to more testing and more bugs. By taking the mobile-first design approach, you will see both a reduction in the amount of unnecessary code written while also understanding how new CSS rules will affect the rest of your application.

Part C: Planning The Micro Code Structure

Now that we have touched upon creating our mock-up and the macrostructure of our code, we need to address the final branch of great responsive web design, building the micro-components. Building good micro-components is the most challenging piece of responsive web design. Primarily because there are many micro-components that make up good responsive design and, in many cases, the best alternatives will be subjective. Learning how to build great micro-components really just comes down to trial and error and what you are trying to build.

That being said, there are some critical things to keep in mind when building the microstructure of your code. By keeping these aspects of your CSS in mind, you will be able to make better-informed decisions on what direction to take your CSS.

Building Fluid Components

If there is one thing that web designer and developers have agreed upon, it is that the introduction of Flexboxes and Grids have made designing for the web so much easier. Seriously. Even simple things were difficult before CSS3.

Using CSS properties like flexbox helps to build websites that are structured well and can be built with responsiveness in mind. I like to refer to this as building ‘fluid’ components. Since elements within a flex or grid container work together to build a layout instead of against each other. This is in contrast to ‘non-fluid’ properties like floats. To the inexperienced CSS user, floats seem like a magic declaration that plays by its own rule, and it kind of does. Since it’s used to purposely break free of the current design and position itself where it needs to. Now I’m not saying floats are bad. They are a very powerful tool. However, it’s a new age and we now have better tools… Use them.

Absolute vs. Relative Measurements

Absolute Measurements

The second micro-component you should pay attention to is what measurements you use to build your elements. Which fall loosely into two categories. Absolute measurements and relative measurements. Absolute measurements are used when the size of an element should not be changed. These include units such as in, cm, mm, pt, pc and px. Unless building something for print, px (pixels) will likely be the only absolute units used on a website. Absolute measurements are great if you want something to look consistent across devices or if you want greater manual control over your elements.

Relative Measurements

The alternative to absolute is relative measurements. Which are sized relative to its surroundings. These include units such as em, rem, viewport units and percentages. If you don’t know what em and rem units are, this is a great article from CSS tricks that explains them. So why would we want to use relative measurements? Simply because they scale better between viewports. Writing your code in relative units can save you a lot of time and lines of code! For instance, there will likely be certain div elements you will want to use percentage widths for. While other times you would prefer to have a fixed width. Using the view height (vh) and view width (vw) measurements are also a great way to size a background to fit the entire screen size. It is also widely supported in 2020. So it’s pretty safe to use without a fall back (if you feel so inclined to do).

The important thing to note here is that you could use any unit of measurement for your design. You will also get a lot of conflicting opinions on what is the best way to do something. Do you want me to let you in on something though? There is no best way to do something. Browser compatibility, user needs and external factors change so often that there is never a perfect solution. There may be a better way to do something, but it will always be entirely dependent on your design. That’s why responsive design can be so challenging.

Luckily, this is where our mockup comes in handy! Since we can visualize how our design looks on all platforms, we can make informed decisions on what units to use. Do what you think will be best and learn from whatever mistakes you make. That’s just a part of the job!

Once again, there is no one-size-fits-all approach to font-sizes and it’s something developers can’t agree on. Check out this Stack Overflow post where two highly upvoted answers recommend px over rem and vice versa. So honestly, the best advice I can give is to do some research, pick a structure and stick with it. Font-sizes can get messy really quickly. Especially if you don’t plan ahead or decide to use a mix of different units for your font sizes. Decide what works best for you and do what everyone else does. Tell us that your answer is the only answer.

That’s about it! Obviously, there will always be more to account for but these are what make up most of the micro components of a layout. By taking how components work together, the units of measurement, and font sizes into account early, you are already well on your way to building a great responsive web design.

Conclusion

Hopefully, this article has helped you conceptualize responsive design principles better. While also giving you actionable tips and techniques to start building better-designed websites and apps. This article is far from complete, it would be impossible to put everything you need to know in a single article. However, it is a great start. You may not be a master frontend developer after reading this post, but I promise if you take all of this information into account, you will be very soon!

One last tidbit of advice I can give is to try and stay up to date with everything CSS. I find that a great way to do that is by following newsletters. CSS-tricks are a great resource for this or you could subscribe to us at The Code Bytes. If you’re looking to become a full-stack developer, here’s everything you need to know. We are always here to help. Happy coding!

Previously published at https://thecodebytes.com/archives/486

Tags

Join Hacker Noon

Create your free account to unlock your custom reading experience.

read original article here