Understanding the Front-End

During the course of this article we will take a big leap into front-end development and see how it fits into our broader picture. Here’s what we’re going to cover:

Development for Designers: Understanding the Front-End

  1. Understanding the front-end stack
  2. Limitations of the DOM
  3. Considerations
  4. Understanding events, states and responsiveness

Understanding the Front-End Stack

Rendering websites can be quite a task. With a host of devices, browsers, access points, bandwidths, programming languages and environments, building consistent web experiences can be difficult. Thanks to browsers and a standardising body (the W3C)we have some pillars in place to give control where possible; those pillars are HTML, CSS and JavaScript.

Combined, we refer to these pillarsas the front-end stack. Each language has its own purpose, and developers spend a lot of time making sure that they don’t blur the lines of each one as they can bleed into each other. So, let’s get basic here. Modern browsers, that are commercially available: the likes of Safari, Edge, Chrome and Firefox can only understand HTML, CSS and JavaScript. That’s it, threelanguages. With the exception of Javascript, HTML and CSS are declarative static languages. By this I mean that you don’t necessarily “program” in either of them as there is no real logic to write (with some small exceptions). JavaScript, which has been exploding into ever corner of the internet in recent yearsis, however, a programming language.

When I’ve tried to explain the Front-end Stack to students in the past, I’ve always found it useful to reference the human body. Considering that we’re talking within the context of Atomic Design, this coincidently carries my metaphor over!

Development for Designers: Understanding the Front-End

HTML: HyperText Markup Langauge

HTML is your skeleton. It determines your structure and your posture. A certain level of meaning can be derived from such a structure. Your head always comes first, neck, rib-cage, hips, legs, feet, all the way down to your phalanges.

Development for Designers: Understanding the Front-End

The order of elements I’ve just described is your typical human. It may be different for a whale or a tiger. Thus, HTML can be different for blogs, commerce stores or platforms. HTML is all about meaning, and describing to a web browser in a meaningful way what a page is about. It has become quite a science of late as Google’s algorithm essentially reads this structure and derives from itwhat the page is actually about.

Takeout: Keep in mind that HTML provides a structure for your web experience.

CSS: Cascading Style Sheet

CSS is how you look. Hair colour, eye colour, skin tone, hairy, long arms, muscular, toe nail length etc. It’s even the way you style your hair, or the makeup you put on to make you look like you.

Development for Designers: Understanding the Front-End

Its only purpose is to style what would otherwise be very plain and boring HTML. If we were all walking around in just our skeletons, attraction would be a problem. The same applies to web experiences.

JavaScript

JavaScript is your mannerisms and interactions. Anything from clicking your knuckles, to blinking, smiling, coughing, the way you walk, if you decide to skip or not, it’s all about interactivity. The important thing to remember about JavaScriptis that when you close your browser it’s all forgotten (generally speaking), so we can think of JavaScriptbeing the interactivity in a website that is going on while you are in a “session” or actively interacting with the website. Think of clicking on popups or navigation dropdowns.

Development for Designers: Understanding the Front-End

Some of you at this point may be asking where the brain or “logic” comes in, but we’ll get there. The most important thing to take out of this section is that HTML, CSS and JavaScriptlive in the browser, they all work together to create a “static” web experience which we can then take back to Atomic Design to refine.

Limitations of the DOM

DOM stands for Document Object Model. The DOM is the living, breathing result of HTML, CSS and JavaScript co-existing in a session activated by the user.

Because the DOM is a living, breathing representation of source code, it’s important to understand that it has limitations. The code you write in HTML, CSS and JavaScript files on your computer is known as source code. This sourcevery closely mimics what you see in the DOM but it is not the same thing. The DOM is the after-product of the manipulation and collation of these files filled with source code. When these files are requested from a browser the languages are “interpreted” and a website or webpage is born. If you change the source code, the representation of those source files needs to be refreshed in order to show the updated version in your browser.

Each language has its own limitations. CSS, for instance, doesn’t have a particularly strong layout engine. This means that it can be quite a process to generate complex layouts in the browser. HTML has no layout capabilities and is only capable of providing a structure and hierarchy for the website to be understood. JavaScript, being a programming language, has the ability to manipulate HTML and CSS. Due to the fact that we use a three layer stack for creating the front-end of any given website, they all need to play nicely with each other, as well as conform with some extra parameters. In our case, these parameters refer to different browsers, devices, operating systems, versions of browsers and more. The DOM is more or less the same across all browser types and distributors, but because of this there are a lot of rules to adhere by in order to create a consistent experience.

Considerations

CSS employs a concept called the Box Model. The Box Model comprises the following properties:

  • Content: the actual content area, filled with text perhaps.
  • Padding: extra padding that surrounds the content area and increases the background.
  • Border: a border, beyond the padding.
  • Margin: pushes the shape itself away from other elements.

Here’s a diagram that explains it a bit better.

Development for Designers: Understanding the Front-End

When designing a shape such as a square, the real estate it takes up comprises the above elements.

The odds are never in your favor

Yes, five column grids don’t bode well for developers. It’s generallyeasier to work with evens than odds. Developers tend to use front-end frameworks like Bootstrap or UIKIT that come with pre-calculated grids containing ten columns, twelve columns, or perhaps more. It’s a really good idea to ask a developer what framework they plan to use, if any, in order to align your design more appropriately with the HTML and CSS

Water, Not Ice

Gone are the old days of web. Due to the fact that the majority of website are moving towards responsiveness, the need for fluid layouts has become very apparent. Grids are now worked out with percentages (10%, 30%, 50%) of containers, whichthen collapse at certain breakpoints a developer can specify.

Fonts Are Not Your Friends

Fonts on websites work very differently to print. While you are building a website on your own computer, you can use any font you have installed on your system. This isgreat for you, but as soon as those files move to another computer, the source code can’t reference the font that you have installed on your own computer any more, as it has no connection to it.

There are many ways to get around this dilemma, but you’ll often hear a developer ask designers to use Google Fonts. Google Fonts are a set of fonts hosted on a CDN (Content Delivery Network) which can be accessed by any computer that has an active connection to the Internet, meaning that even if I don’t have the specific font installed on my own computer it can still render on my website. Be aware of this. Some fonts are also not designed for rendering on web engines. They mightlook drastically different when viewed in, say, Photoshop, compared to a web browser. Each program renders fonts with different rendering engines.

Events, States and Responsiveness

Now that we have covered some fundamentals, let’s take a look into some issues that designers tend not to consider in their designs but are really important for user experience.

Events

Events are actions that a user takes while interacting with your website. JavaScript has quite a few to take into account, but simple examples include “click”, “scroll”, “mouseon” or “mouseout”, and “keydown” or “keyup”. Ifyou want to read a little more about JavaScript events, visit Mozilla. Some of the events you see here aren’t necessarily trigged by user interaction.

From a designer’s perspective, it’s paramount to understand what happens to certain elements or sections on your website once a user has acted upon them. What happens when a button is clicked, for instance? Or is there an animation applied to a modal window when it closes on click? These are questions you need to provide answers for, especially if your project has a pre-defined scope. Depending on the budget and the timelines, “Interaction Design”, as it’s dubbed in the web communities, can take precious time out of a project.

State

After an event has occurred, elements are left in “states”. A common example being links. Links have a number of states: active, focus, hover. What do your links look like when they have been clicked on? While you’re pressing down? When the mouse hovers over them? Or when they are touched on mobile?

Atomic design can really come in handy here as your style guides can easily account for these states while building up an atom such as a button. State can have a dramatic impact on your user experience, so take it into account when dealing with more complex sites.

Responsiveness

The “responsiveness” buzz word has been buzzing for quite a while now. As developers we need to make sure that our web experiences are consistent across all devices. If you’re a freelancer, almost every client will ask for their site to be responsive. It’s become the “bread and butter” of the web. CSS provides developers with a useful technology such as Media Queries which allow developers to customize layouts at certain “breakpoints”.

Front-end frameworks like Bootstrap and Foundation are geared towards making responsiveness a lot easier to implement by devising responsive, percentage-based grids for developers to work with. The biggest take out here is not how responsive design grids work, but more what they are engineeredto do.

Conclusion

Thats it for this time! In the next article we will take a look at the backend and how we can use an Atomic Design mindset to improve our understanding of logic and programming skills.