tactile

– thoughts on CSS, UIs and UX.

A checklist for common front-end needs

Posted: December 11th, 2012 Author:

After building the front-end on a number of web apps, I’ve noticed there are a number of common functions or helpers each web app needs for Front-end development purposes.

Some tasks are trivial to solve, by virtue of being included in some web app frameworks, others are repeat offenders that you find yourself building for each and every web app.

App-wide needs

The web app should set a default language code

<html lang="en">

This acts as the basis for an i18n setup. It’s also good to set defaults.

The <title> element should include a basic information hierarchy

<title>Page name or title [| Section name] | site name</title>

This is more meaningful and allows for better history backtracking. It’s also better for SEO.

The core CSS file should be included on every page

<link rel="stylesheet" href="core.css">

Emphasis on file. You should be bundling all your reusable CSS files into one file at build-time. This CSS file should be included in the <head> element on every page.

The core JavaScript file should be included at the bottom of every page

<script src="core.js"></script>

Emphasis on file. You should be bundling all your reusable script files into one file at build-time. This script file should be included at the bottom of every page, before the closing </body> element.

Section or context-specific needs

The web app should specify what business objects are used in the page context, or indicate the section of the site

<html class="obj_1_name obj_2_name section_name">

This is useful for section-specific style overrides, where the styles in one section are distinct from those in another.

A user or layout-context CSS file should be included on every page that uses that context or layout

<link rel="stylesheet" href="guest.css">

Most of our CSS should be wrapped up in the core CSS file, but sometimes you’ll want to include an extra block of styles because the layout or styling is unique. A good example of this is the split between being a guest user vs. an authenticated user. Guest users will see marketing related content. Authenticated users would see app-specific styles.

A page or section of the web app should be able to add its own specific script file

<% Footer script block %>
<script src="home.js"></script>
<% end Footer script block %>

The core scripts should not be overloaded with page or section-specific scripts. Since the core script will be cached, the impact of this additional script should be negligible.

A page or section of the web app should be able to add its own specific CSS file

<% Head link block %>
<link rel="stylesheet" href="page_home.css">
<% end Head link block %>

Likewise with page-specific scripts, the front-end developer should be able to add CSS for sections or pages within the app. This will keep the core CSS file down in terms of size.

A page or section should be able to set its related page or section nav item to ‘active’

<nav>
  <ul>
    <li class="active"><a href="/">Home</a></li>
    ...
  </ul>
</nav>

This is one of two ways to set active nav-items. The other is to use the page_slug ID and match it to an ID for each nav-item. There will be some circumstances where it would be better to set a class on the active nav-item, so your web app should provide this.

Page specific needs

The page name should be added as an ID value to the root node

<html id="page_slug">

This gives a CSS author the ability to set page-specific style rules or exceptions to the style rules

Set page-specific keywords

<meta name="keywords" content="[keywords]">

This will allow for better search indexing

Each page should have a page title in the header of the page content

<article>
  <header>
    <h1>Page title</h1>
  </header>
  ...
</article>

This gives the document a good structural outline, some extra elements to use for styling and helps with SEO.

Content-specific needs

If you’re building an ecommerce app, you should mark-up all prices consistently

<div itemprop="offers" itemscope itemtype="http://schema.org/Offer">
  ...
  <b itemprop="price">
    <span itemprop="priceCurrency">ZAR</span>
    <abbr title="Rands">R</abbr>&nbsp;4<span class="separator">,</span>999<span class="decimal_point">.</span><span class="cents">99</span>
  </b>
  ...
</div>

Not only does this help with styling flexibility, but also better semantic use. The snippet above uses schema.org microdata.

Conclusion

I’ll add more as I think of them, but hopefully this should cover most of the Front-end Developer’s needs.

I think we’re in for some exciting times when we throw CSS precompilers such as Sass and LESS into the mix. This setup is all about modularising the UI based on information and technical architectures, something that the precompilers are built for.
Still, this is uncharted territory. What’s your experience? What do you have to rebuild each and every time?

Comments are closed.