Building a scalable frontend #3

To finish off talking about frontend scalability, we’ll continue with the idea that our product is being used by a much more diverse set of users from around the world, using different devices, but also with unique sets of requirements as well.

Responsive design

Since web development began, there have been many different approaches to designing for websites, from fixed width when everyone was using a screen 640 pixels wide to liquid design when monitors started to be sold in more different dimensions. Today, the web is browsable on many different devices, from phones to laptops to TVs.

To handle all device types, we now follow an approach called responsive design, which means that given a viewport of any height or width, our application is still displayed in a usable and visually appealing manner.

The most common way to support different screen sizes is to use media queries. These allow us to apply CSS rules to specific media properties like device height and width. So, rather than implementing a fixed-size application, we can create a layout that responds to many different device types: mobile, web, TV, etc. This is now quite a common practice in modern web development, and a lot of popular CSS frameworks and tools come with out-of-the-box abstractions to help developers. TailwindCSS and MaterialUI, while handling layout and styling quite differently, both have pre-defined media queries called ‘breakpoints’ built-in and responsive design functions and components.

Both of these tools take the mobile-first approach to applying styles, which is widely accepted as the most sane approach to supporting a wide range of device types. This is the idea of by default styling and defining a layout for mobile, i.e., the smallest device width, and applying styles in an additive approach as the screen size grows. It’s much easier for developers to start simple and add just the styles they need than to go the other way. Starting at the largest size and trying to strip redundant styles as the screen width gets smaller is incredibly difficult and hard to maintain.

Internationalisation

Internationalisation is the practice of designing web products to be able to support a variety of target audiences around the world, where things like language, time, date formats, and units of measurement might vary.

Some of these might not have much of an impact on how you approach the design and implementation of your application, especially at the beginning, but others are worth noting, for example, if you want to support different languages in the future. English is read from left-to-right (LTR), whereas Arabic and Hebrew are read from right-to-left (RTL). This is where we can run into some pesky layout issues.

The majority of the design and layout work we do in Europe is for LTR languages, especially when using directional CSS properties like align: left. left will always mean the left of a content box, whether or not the current language is LTR or RTL. A simple change to using a logical property like align: end means that regardless of the writing mode, the property will be applied correctly. Common layout techniques like flexbox and grid use these logical property values by default, so it’s worth noting when writing extra styles by hand.

Another interesting consideration is the length of the words in the language. The German language is always a great one to test with; not only does it have longer words than English on average, but it also has some incredibly long words. Not testing for this sufficiently before moving to the German market, for example, can lead to some embarrassing layout issues. Things like temperature, distance, and height/weight units are also important to consider when moving into markets around the world.

Accessibility

The accessibility of a product refers to how anyone, whether they have a disability or not, can still interact with it and derive equivalent amounts of value. The way we design and implement our products shouldn’t mean a portion of our user base finds it difficult, or even impossible, to engage with them.

To understand how accessible our product is, we can refer to different guidelines, a common one being the Web Content Accessibility Guidelines (WCAG). WCAG outlines four main principles of accessibility: perceivable, operable, understandable, and robust (POUR).

We can meet these criteria by making sure we include alternative text for images, interactions with sufficient and intuitive keyboard shortcuts, and semantic HTML, among many others. This in itself is another huge topic, so I won’t go into much more detail here.

In addition to having a clear and predictable document structure, which aids assistive tools like screen readers, using ARIA HTML attributes can help convey more meaning and help users navigate more quickly and intuitively. Again, the correct way to implement ARIA labels is not so straight-forward, so I will leave more detail for a future article.

Wrapping up

These considerations might not be the first that pop into your head when scaling your startup, but they certainly are worth bearing in mind, especially when doing that post-PMF redesign and rewrite. These are super helpful things to make note of if you want that design or implementation to last a lot longer than your MVP or version 1. Next, we’ll start getting to the fun stuff and dive into scaling the backend of your product.