If it was up to me, everyone would view my beautiful, pixel-perfect design on the same sized monitor as me and see what I see. The phrase “well, it looks good on my screen” would ring true for everyone! Unfortunately, this is never going to happen and with so many unknown variables in the digital word these days, it’s important to consider our audience and relinquish the control. This becomes a little easier to do when you realise that, although it’s nice to have a good-looking website, the most important thing to consider is accessibility and the user experience. With the huge variety of screen sizes available to people, it is important to find a solution that provides the best user experience across all browsers, screens and devices. A Fluid or “liquid” layout allows for this flexibility by adapting to the largest screen size right down to the smallest mobile device. This is because a fluid layout uses percentage-based widths instead of pixels, which allows the container to stretch up and down when you resize your browser window. Although there are a lot of benefits to fluid designs, they do take more time to plan as you have to foresee problems that occur at every possible width. I have listed below some examples of the challenges I have faced when designing with a fluid layout and what I did to work around them:
With a fluid design, there are a lot of different variables and you’re going to have to account for these by mocking up your design at a number of different widths. What may look good on a small desktop might look completely different on a 27-inch iMac. It is also important to make the client aware of how their design will respond on large desktops right down to the smallest mobile device and to take the time to mock this up for them. I have had clients in the past that love the PSD designs, but when they see the fluid design in action, they didn’t like how it looked. In these instances, we had to compromise by putting a max width on the content container to limit how large the content area became. This leads me to the next challenge…
Having a fluid design means that the text can scale up and down with your browser, which is great for responsiveness but as the browser gets larger, you run into legibility issues with extremely long lines of text. To get around this issue, I like to incorporate a maximum width on all content areas so that the copy is aesthetically pleasing and legible across all devices and screen widths. Again this needs to ideally be addressed in the design stage when you are mocking it up in different widths, which can be quite time-consuming and needs to be accounted for at the beginning of a project.
Ideally, it’s good practise to use retina images in your fluid designs to maintain image quality and clarity. However, this can slow down your site and affect its overall performance. But with more and more people viewing sites on larger screens and with the launch of the new iMac 5k Retina Display, we have to start catering to these devices and find ways to incorporate retina images without sacrificing site performance. One way to do this is by using HTML’s srcset. There is a more in-depth article here that explains how srcset works and how to incorporate it. However, I’ll just sum it up in a language that I understand… srcset allows different sized images to display depending on the size of your screen. This means that only screens that support 196DPI or higher will display the retina images, so your site performance does not have to be compromised.
Regardless of whether or not a design is fluid or fixed, no design scales seamlessly beyond the context it was originally intended for. Therefore, it is important to have a flexible foundation with dynamic elements that change depending on the view port. For example; on a recent fluid web design, I had the navigation centred on a small desktop and as the browser increased the meta navigation, the search icon and basket stayed pinned to the right while the page links stayed centralised. This was to ensure balance and maintain easy access for the user to the main pages of the site. In this instance, it was extremely important to communicate with the developer how I visualised this working, mocking up examples to help demonstrate how the elements on the page reacted to each other as the browser window changed. Without a clear open line of communication with the developer, it leaves room for interpretation, which you may not be happy with until it’s already been created. And having to go back and redo things after they have been created in not going to be time efficient for anyone. I find the best way to prevent any misunderstandings is to not only provide a visual mock-up but also provide a written explanation of how the dynamic elements should work. I would include this in a design handover document for the developer so that they are fully aware of how the site will respond, meaning there are no surprises at the end when it’s finished.
With fixed layouts slowly becoming a thing of the past, it is important to be aware of the challenges faced when designing a website with a fluid layout and the ways to work around them. It is important to plan ahead and take into consideration all of the various screen widths and how you want your design to react and adapt. It’s also essential to incorporate a maximum and minimum width to certain areas of your design, especially text, to ensure legibility across all devices. If you are planning on using retina images, be sure to take the proper steps to ensure that your site performance is not sacrificed. Last but definitely not least, make sure to have a clear line of communication with the developer to ensure that they are aware and understand how the dynamic elements of your design should react with the various screen widths. Although it does take more time and thought, when done right, a fluid layout provides a positive and consistent user experience by adapting across all devices.
Powered by WPeMatico