< Back to Blog

How to Stop Worrying and Start Coding: Self-Help Tips for Developing a Web Front-End

Self-Help Tips for Developing a Web Front-End

Like Frankie said
I did it my way
—Bon Jovi

During the four years I’ve worked as a front-end developer, I’ve gained a great deal of experience coding HTML pages. Today, I’m going to share some of that with you.

Let’s imagine that you have just received a designer’s layout of a landing page — for a business card website, for example, or an administrative panel dashboard. Where do you start and how do you put everything in its proper place? Let’s find out!

Load up on Guns

Precisely the place for Nirvana to start, perhaps, but an HTML front-end requires a lengthier checklist:

  • Read the requirements
    If you are fortunate enough to have a set of technical specifications, read them thoroughly. This is really important! Before you do anything else, ask all the questions that occur to you while reading the specs — and add any responses you collect to the specs document.
  • Identify which browser versions you’ll need to support
    If the requirements don’t specify which browsers (and versions of browsers) need to be supported, now is the time to pin down this information. The list of supported browsers will determine your coding approach. If you’re only focusing on the latest versions of the most popular browsers, for example, you may be able to use ‘flex’ instead of ‘float’ on your pages.
  • Know which devices the website is expecting
    When you know which target devices to expect (such as desktop computers, mobile phones, tablets, projectors, etc.) you can not only select the most appropriate style rules (mobile first or desktop first), but you can also request layouts for each one in advance. This will help you avoid the need to fix missing design elements right before the website release date.
  • Choose a streaming build system
    I myself prefer Gulp for static website coding. It’s fast, supports a variety of plug-ins, and can be used to automate a broad range of development tasks. If you have code you reuse regularly, you can save it as a template for rapid reuse. Examples of my own code templates can be found here.
  • Select an icon format
    These days, vector icons in SVG format are optimal for web use. They’re small, versatile, and display well on a variety of screens. If you need to use icons in a raster format (e.g., PNG), you should use two sets of icons: one for standard display resolutions and another for Retina displays. You also need to think about arranging icons as CSS image sprites.
  • Check your font needs
    What fonts will your page require? If the font is in the public domain, there’s no big deal: you can use Google Fonts or download and install the desired font. However, if you need commercial fonts, you’d better inform your project manager. Sometimes designers just forget to inform them about the need to buy fonts.
  • Pre-check that you’re ready for the deployment process
    Make sure that you have all required credentials and permissions to deploy the website. If required, you can create and set up continuous integration tools, such as Jenkins, Travis, or others.
  • Discuss teamwork rules of conduct in advance
    This is the kind of thing that you want to sort out in advance, not when the deadline is looming. What will the testing process look like? What are the priorities for bug and issue resolution? What criteria will you use to evaluate issues and task execution? Most disagreements between case testers and developers arise from a lack of simple agreements about how to proceed. Establish the ground rules at the beginning, and try to hold personal and group discussions as often as possible to solve issues that may arise.
  • Choose your CSS-writing methodology
    There are four main CSS-writing methodologies:

    • Object Oriented CSS (OOCSS)
    • Block, Element, Modifier (BEM)
    • Atomic CSS (ACSS)
    • Scalable and Modular Architecture for CSS (SMACSS)

    Personally, I prefer BEM. The methodology was developed by Yandex and it has almost became the front-end standard (as a result of long and persistent PR campaigns) but it solves all the problems related to the selector class naming and continuous project support — so there’s more than just PR behind it. One can find more information about BEM here, here and here.

Decompose the Layout

Regardless of the CSS methodology you’re planning to use, it can be useful to understand the page layout in terms of its main elements before you do any coding. By understanding the layout in this manner, you can allocate your efforts more effectively and set more realistic expectations for delivery.

  • Identify the blocks that will be used in your work. Usually these are comprised of buttons, text fields, icons, carousels, etc.
  • Create clear and distinct names for the blocks. You want them to be easy to remember.
    • Examples of good names: jumbotron, main-menu, page-footer, input, label, form, link-set, btn, checkbox, radio.
    • Examples of bad names: red-btn, left-top-menu, big-red-middle-radio, shipping-form, user-address, long-text, dscr-msg, bck-tp, b-txt-bold, fp-section, contact-page.
  • Try to include the semantic of each element in its name — but without linking the name to a specific location. For example: block__list, block__title, block__item, block__text.
  • Think about CSS modifier names. If you are lucky enough to get a style guide from your designer, you can use it to find information about the types of buttons, input fields, checkboxes and other elements that you’ll want to use on the website. Such a guide usually contains information about the different states of all active elements, including their colors, fonts, sizes, and so on. This information can be used as a base upon which to create such modifiers as btn-error, btn-border, input-big, main-menu__item_active, and main color variables.

You’ll find several examples of proper block designs here.

Code the Page (at Last!)

After decomposing the layout into blocks you can—at last—reproduce each element and each block in HTML. If you want your website to be static then it’s a good idea to use a template engine at this stage. It will avoid the need to copy and paste code associated with similar or repeating elements (such as headers, footers, and so on).

You should create a separate style file for each of the blocks, too, but don’t waste time trying to create pure CSS. Instead, use your favorite preprocessor. This will save a lot of time and make code support much easier.

Avoid using constructions that are overly complex, too. It’s best to limit yourself with simple nesting, mixins, and variables. Don’t forget that your colleagues will read the code. You don’t want to pain them.

One More Thing: Pixel-Perfect Testing

So, your code is written and tested. Is your front-end done? Not quite. There’s one final step: pixel-perfect testing.

Pixel-perfect testing is all about ensuring compliance between the website as laid out and the website idea as the designer envisioned it. After all, design is not just about the relative location of blocks on the screen. A designer selects an optimal font, its size, padding, margins, and many other parameters. A well-written front-end won’t just approximate the designer’s idea.

How can you ensure the highest level of design compliance? The PerfectPixel plug-in for Google Chrome provides precisely the functionality you need to accomplish this. The plug-in places a semi-transparent image overlay on top of the page you’ve developed in HTML. This enables you to compare the design to the execution right on the screen.

I treat pixel-perfect testing as a distinct stage. The task is routine, yes, but it’s very important and really has to be done in pipeline mode.

Once you’ve validated page compliance, then you’re good to go!

Afterword

This article contains information about methods that I use, as well as methods that my colleagues at Distillery use – but many of these methods were created by other people and subsequently shared with us. Join the community and share your experience! The front-end simply can’t exist without a proper approach to coding.

Carry on my wayward son,
For there’ll be peace when you are done
Lay your weary head to rest
Don’t you cry no more
–Kansas

 

About the Author

Andrew Fatuk is Distillery’s lead front-end professional. A talented engineer, a rock music fan, and a polyglot (with four human languages in his arsenal), he enjoys researching new technologies and teaching front-end development to HTML Academy students in his free time.