Prototyping an App in Static HTML

Max Böck

I recently worked on a larger new web app. The product was in its early stages, so one of the first big tasks was to come up with a prototype for the UI design.

I started doing some pen-and-paper mockups and some concepts in Sketch, but the project details weren’t clearly defined yet, and things would change very frequently. I had to redo a lot of components or modify them often to reflect changes I’ve made somewhere else. It didn’t feel efficient.

Essentially, I was just drawing pictures of an interface. A pixel canvas simply wasn’t the right medium for this.

So I decided to design in the browser and make a clickable dummy that I could use to rapidly prototype the UI. I wanted a way to try new directions and change stuff quickly, without having to do the same tasks over and over again.

I opted for simple static HTML.

Since the end product was going to be built in React, I though about how to best get into a workflow that matched a component-based architecture, and design elements accordingly right from the start. This approach also had some other benefits that I discovered while refining my setup:

Thinking in Components

Prototyping an application as sort of a LEGO set of individual chunks of HTML forces you to think about the building blocks early on. As every component has to be self-contained, you start to see patterns and abstractions in an interface clearer.
Design with real data

Using mockup data gives you the ability to see your work in “real life” conditions, rather than in a pixel-perfect dreamland. This helps to spot problematic elements that could break the design.
Version Control

Another real advantage of static files is the ability to check them into version control. Branching off to try something new or reverting back to an older design is as easy as finding the appropriate git command.
Test and Iterate

Testing responsive features on different devices works effortlessly through BrowserSync, and clients can try the look and feel of things on their own laptops and iPhones - they love that 😍.

Sound good so far? Cool.

So how can we best go about doing this?

Generating the Files

To build our static prototype, first we need a good templating language. My tool of choice here is Nunjucks, a powerful engine built by Mozilla. It integrates nicely with node-based build setups and is crazy extensible. But, you could just as easily do this with Liquid, Handlebars, or the like. The only important thing to remember is that your choice of templating language shouldn’t impose a particular structure on you and is flexible enough to handle anything you throw at it.

Most of these work in a very similar way: You define templates that contain “blocks”, which are dedicated areas in the markup that can then be extended by other templates, or populated with content.

The folder structure in my setup has three main parts:

📂 1) layout contains the basic templates. There is usually a base template that just holds the outermost html elements like <head> and <body> and loads the CSS and Javascript. You can then extend this base template to create other, more complex reusable layouts.

<!-- base.html (simplified) -->
<html>
  <head>
    <title>My Template</title>
  </head>
  <body>
    {% block content %}{% endblock %}
  </body>
</html>

See that {% block %} thing? That’s where you can inject other templates to get more refined:

<!-- layout-2col.html -->
{% extends "base.html" %}

{% block content %}
  <div class="container">
    <div class="row">

      <div class="col-md-9">
        {% block main %}{% endblock %}
      </div>

      <div class="col-md-3">
        {% block sidebar %}{% endblock %}
      </div>

    </div>
  </div>
{% endblock %}

📂 2) components is the folder for all the building blocks of your application. Basically anything that can be isolated and reused goes in here. This can be stuff like headers, menus, posts, user avatars … you get the idea. Files should be self-contained and named like the root class of the component.

<!-- post.html -->
<article class="post">
  <h2 class="post__title">{{ post.title }}</h2>
  <div class="post__excerpt">{{ post.content | truncate(50) }}</div>
</article>

The BEM naming scheme really comes in handy here, because you can properly namespace your components to avoid conflicts with other ones. It’s also good practice to have a separate SCSS partial for every component (_post.scss, _avatar.scss…).

Include your new component in other templates with {% include post.html %}.
You can of course also have things like loops and if statements, and pass data to your components:

<!-- variable {{post}} will be available inside post.html -->
{% for post in data %}
  {% include post.html %}
{% endfor %}

📂 3) views is where all the different sub-pages of your app are defined. This could be stuff like index, detail or settings.
The templating system will look at the files in this folder and generate a matching HTML document for each of them, looking up all its dependencies (components and layouts) recursively.

The view files should ideally only arrange different components, and have very little to no markup of their own, to keep everything nice and DRY.

Using realistic data for UI design

Designers (myself included), sometimes tend to make things “too pretty” to produce nice-looking mockups for the client.

Apple Watch Models — Look at all my cool model friends with four-letter names.

In the real world however, things don’t always work that way. People will have long names with non-english characters. People will upload low-resolution or no images. People will break your carefully balanced typography rules.

And that’s OK - a good design should anticipate such problems and be flexible enough to handle them. By using more realistic data right from the start, it’s easier to think about these things.

Here’s where static HTML prototypes shine. One of their big benefits is the ability to easily incorporate any kind of mockup data into the UI. This means you can design your application with “real life” content in mind.

Mockup data generators like Mockaroo give you a simple interface to quickly produce demo data in any structure you like. Say you needed some sample users for your app:

The Mockaroo UI, different field types define the structure of a data ressource

Mockaroo lets you define your data as a collecton of fields and it has a field type for almost anything you can think of. You can generate text, images, bitcoin addresses - you name it. It can also give you a predefined percentage of random blank fields.
When you’re done, save your schema (in case it changes later), and download the mock data as a JSON file.

Finally, plug that into your prototyping setup like so:

//tasks/nunjucks.js
var demoUsers = require('app/data/DEMO_USERS.json');
...
gulp.task('nunjucks', function(){
  gulp.src('app/views/**/*.html')
    //this makes the data available to the templating engine
    .pipe(data(function(){
      return {
        users: demoUsers
      }
    }))
    .pipe(nunjucks())
    .pipe(gulp.dest('dist'));
});

Whenever your data structure changes, just update the JSON. Your demo users are now available inside all components like this:

<!-- user.html -->
{% set user = users | random %}
<span class="user">
  <img class="user__avatar" src="{{ user.image }}" />
  <span class="user__name">{{ user.first_name }}</span>
</span>

Migrating to React

When the time comes to move things over to the final development environment, it’s fairly simple to convert your components from static HTML to React. You can see by the variables contained in a file which props a component needs to receive. In many cases, you can simply copy-paste the HTML into a render() function as JSX. (Be sure to replace instances of class with className though).

👉🏾 In most React Setups, it’s possible to colocate styles with their corresponding component, and have them in their own folder. I think it’s more convenient that way. By scoping styles strictly to their own partial, reusing the .scss files from your static prototype is also very straightforward.

Free Static Prototype Kit 3000™

I made a custom boilerplate based on Gulp using this approach (plus a few other goodies). It’s available on Github, feel free to use/extend it anyway you want.

blogs
tech

Three Goals for 2017

Max Böck

I've been a freelance web developer for about seven years now.

I started making websites when I was still in school - I used to do fun little sites for local bands, events and other things. At some point I decided to do it professionally, registered my business and had my first real clients.

I’ve learned a lot since then, and I still do now. At the beginning of 2017, I did some thinking about where I wanted things to go for me.

Why I love the web

I can still remember what it was like to build my first website. I had absolutely no clue how to do stuff, it was all trial and error. But going back and forth between blogs, tutorials and stack overflow, watching other people work, shamelessly copying bits and pieces - I improved.

The fact that I can just hit view source on any website and see how it’s made still amazes me.

Altough I have a degree in web development now, I can honestly say that I learnt most of what I do by soaking up information available on the open web.

This is only made possible by lots of talented people who not only produce great work, but dedicate their time and energy to show others how to do it, too. I don’t know any other profession with such an open exchange of knowledge.

People from around the world actually work together on open-source projects, just to build something that others can use. Top developers in the field will share their latest findings publicly in carefully crafted tutorials and code examples on Github.

Think about how amazing that is - an entire industry where you can learn every last secret of the trade for free - all you need is dedication and an internet connection.

Twitter is great because the creator of JavaScript will help you with JavaScript within 7 minutes pic.twitter.com/3XrQZtTF7E
— Wes Bos (@wesbos) January 9, 2017

Coincidentally, this is also the only way people can keep up with all the new developments being made in this fast-paced industry. If we didn’t share, we’d stop moving.

I want to keep moving.

Goal #1: Get more involved in the Developer Community

Oddly enough, I’ve always felt that writing or speaking about the web was more difficult for me than to actually code or design things. It just doesn’t flow that well for me. However, I want to make en effort to change that.

👉 In 2017, I want to…

write more and better blog posts
speak at meetups or small conferences
engage in more conversations on twitter

A web comic about self doubt — me, browsing github

Sometimes it can be difficult to think of something worth sharing. There’s always a level of self-doubt involved.

"Somebody else has probably already written a better version of this anyway. Besides, you don't even really know what you're doing."
— your stupid brain

It’s easy to find reasons not to do it in the first place. But no matter what your skillset is, sharing your progress is always helpful. Even if you’re just starting out, a lot of beginners might look exactly for that first-steps perspective, where you can see questions that more experienced authors might not even consider.

But its not just giving back to the community. A much more selfish motivation (at least for me) is that by teaching others, you become a better developer yourself.

"If you can't explain something simply, you don't understand it well enough."
— Albert Einstein

I think teaching / talking / writing about stuff forces you to organize your thoughts.
You need to research the whys behind any given topic to be able to explain it to somebody else - and that, in turn, improves your own understanding as well.

Goal #2: Do more interesting Projects

I’ve come to find that I learn best when I can apply new techniques to an actual real-life project. That’s why I try to include something new in everything I work on, to get myself out of the comfort zone.

Finding good, interesting work isn’t always easy though. This is still my job and I’ve got bills to pay, so there’s a business side to it. But at the same time, doing the same “standard” projects over and over again won’t push me forward, and is ultimately not why I’m in this career.

👉 In 2017, I want to…

find work that lets me explore new directions
find clients who do interesting things
find good ideas to build as side projects

Goal #3: Work on the Basics

I’ve seen a lot of “technology fatigue” posts in the last year. And I get it - things are moving so damn fast that developers are tired of having to learn a shiny new framework every two months. People are annoyed that simple tasks can require 14 different tools now. They are also worried about being left behind.

webcomic about a coder who just come back from a conference, hyped on new technology

The thing is though - underneath it all, the ingredients never change. It’s always HTML, CSS and Javascript. The fundamental building blocks are the same, they’re just expressed differently.

Part of the beauty of web standards is that they never truly break. I could look at that first website I made back then in a modern browser today, and it would still work. I could still access all the content (although it would be laid out in <TABLE>s and cluttered with janky GIFs).

A good knowledge of the fundamentals also makes it a lot easier to learn the new hot stuff, because that’s whats actually under the hood.

So if there’s any safe horse to bet on in terms of learning web technology, it’s the basics.

👉 That’s why in 2017, I want to…

get better at vanilla JS and ES6.
learn some of the newer CSS concepts like grid
really focus on accessibility and performance

Getting There

As with any type of resolution, accomplishing these goals will take some effort. I hope that by putting them up here, I’ll feel a little more motivation to actually follow through.

I have some changes coming up this year, and I’m excited to see where it will take me!

tech
blogs

The Relaunch Post

Max Böck

Two weeks into 2017, I used some spare time to relaunch my website.

I do this almost every year - not (only) because of my neverending quest to optimize the shit out of it, but because it’s a great way for me to try new things I want to learn on a “real life” project.

Altough it’s a fairly simple site - basically just a small portfolio section, a blog and a contact form, it’s still a good exercise to see how different modern workflows can come into play.

So here is the way I did it in 2017. This might get a bit lenghy and technical, but hang in there.

TL; DR:

Jekyll Static Files
BEM-flavoured CSS (w/ Critical Path Inlining)
Vanilla JS (ES6 / Babel)
System Fonts & FontFaceObserver
Offline Support w/ Service Worker
Focus on Speed and Accessibility

All source files are available on Github, if you’re interested.

Going Static

While previous versions of this site were all built on WordPress, this year I finally decided to switch to a static file generator, Jekyll.

Jekyll blogs are typically run by developers or other tech-savvy people, as they require a bit of knowledge about tooling and setup, and posts are usually written in Markdown. It’s definitely harder to get started than with a 1-minute WordPress install, but it’s worth it:

Static files are faster, safer and more resilient than a database-driven site.
Plus using any sort of CMS always restricts you to doing things a certain way - and I wanted full control over the barebones HTML.

The out-of-the box Jekyll setup includes a development server and support for SCSS preprocessing.
However, I wanted a little more - so my first step was to build a custom boilerplate with Jekyll and Gulp to do the heavy lifting.

Design

Design-wise, I’ve always been a fan of minimalism - so it’s no surprise that this year’s iteration turned out to look very clean and reduced again.

Content precedes design. Design in the absence of content is not design, it's decoration.
— Jeffrey Zeldman (@zeldman) March 5, 2008

Keeping true to this premise, I focused more on the content, on good typography and readability; and I think it turned out nice. While I dont think that every site should look as “boring” as this one - cause I really enjoy the crazy creative things others come up with - for me, it was a good fit.

Accessibility

I read a lot about accessibility last year, most recently the highly recommended “Inclusive Design Patterns” by Heydon Pickering. It gave me some very valuable practical advice on the subject.

The biggest takeaway for me was to not treat accessibility as an add-on to further improve an exisiting website, but to design websites “inclusive” right from the start. Trying to think of all the use cases outside of your own bubble first, to make a site everyone can use.

I believe that a good website should be able to handle almost any scenario you can throw at it, and still manage to provide content in a usable form. So for the relaunch, I wanted to incorporate this knowledge and push for a really flexible, accommodating design.

A few of those features include:

semantic, structured HTML & microformats
landmark roles and WAI-ARIA attributes for screen readers
UI doesn’t rely on color perception
content can be navigated by keyboard in a logical way
entire site scales in relation to default font size (rem-based)
top level pages are cached by Service Worker for offline use

Javascript

I have to admit that I had become a bit lazy with jQuery. Relying too much on the framework to do basic tasks made me dependent on it, and using jQuery for everything adds unnecessary bloat.
So as part of my ongoing effort to really get better at Javascript, I wrote everything in plain vanilla ES6 this time.

I found a few select microservices to handle things like lazy loading or basic ajax requests, making sure to include just the absolute minimum. All of them were available via npm install and can be consumed as modules, first thing in the main file:

import FontFaceObserver from 'fontfaceobserver'; //font loading
import Blazy from 'blazy'; // lazy images
import NanoAjax from 'nanoajax'; //ajax
import Util from './lib/util'; //custom helpers

For some of the stuff that is usually provided by jQuery, I created a separate Utils.js file to import. Things like serializing form data or getting the parent DOM node of an element can easily be recreated as simple functions, and then called like Util.serialize().

I also made an effort not to use a third-party plugin for the contact form, but to build as much as possible from scratch.

The final minified and gzipped JS file weighs in at just 8.4KB, quite small compared to the hefty 68KB I had before. Feels good 😎.

Defer all the things!

Since the site basically works fine without Javascript too, there’s really no reason to have it block the rendering. The webpack-generated main JS file bundle.js can therefore be defered quite easily.

For a few ressources that are not related to the function of the site itself, I’ve taken it a step further still. I used my favourite defering snippet to make sure stuff like analytics, polyfills or the twitter API are loaded last, when the site is already done and rendered.

Fonts

Taking a page out of Github’s playbook, I used system fonts for the body copy (and emoji) 🍺.
They look great, support all languages and fit in nicely with the rest of the device UI. And best of all, they’re available without a single network request.
Here’s the full body font stack:

$body-font: -apple-system, BlinkMacSystemFont, "Segoe UI", "Roboto", 
"Oxygen", "Ubuntu", "Cantarell", "Fira Sans", "Droid Sans", 
"Helvetica Neue", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol";

Titles are set in Playfair Display, a font availabe on Google Fonts. I chose to self-host it, and provide fonts only in woff and woff2 formats. That’s not totally bulletproof, but more future-friendly.

And besides, no font-face syntax will ever be bulletproof, nor should it be.

For @font-face loading, I used Bram Stein’s FontFaceObserver to make sure users wouldn’t see a FOIT on page load. Titles fall back to the similiar looking Times New Roman until the font is ready.

A couple of additional tweaks here:

Preload the font as early as possible

  <link rel="preload" href="playfair-display-regular.woff2" as="font" type="font/woff2">

Optimize for repeat visits

Once the font is cached, we can use it straight away. There’s no reliable way to detect this though - I settled on a cookie-like solution (I say “like”, because it actually uses session storage). The length of a browser session is a reasonable timespan to assume for a valid cache, so I set a flag when the font is first loaded.

The whole fontface observer code looks like this:

function loadFonts(){
  if(sessionStorage.getItem('fontsLoaded')){
    return;
  }
  
  const playfairObserver = new FontFaceObserver('Playfair Display', {});
  playfairObserver.load().then(() => {
    document.documentElement.classList.add('fonts-loaded');
    sessionStorage.setItem('fontsLoaded', true);
  }, () => {
    document.documentElement.classList.remove('fonts-loaded');
  });
}

Performance

Speed was a major factor in the relaunch process. It’s not that my blog is particulary heavy or gets that much traffic, but I’m super interested in performance optimization and wanted to see how far I could take things.

I tested using Webpagetest, Google PageSpeed and Lighthouse, looking especially at three metrics:

time to first meaningful paint
speed index
total # of requests

Let’s get critical

A good method to improve page performance is to try and render the initial view within the first network request (the first 14KB or so). To achieve this, a subset of the full CSS is inlined in the page head.

Determining exactly which styles are necessary to render the page at a given viewport is a little tricky and would be quite cumbersome, if one were to do it manually. Thankfully, the smart people of the internet (namely Google’s Addy Osmani) have developed a tool for that:

Critical is a gulp plugin that takes in a set of pages and a viewport width/height, then looks at these pages, extracts all applied styles and injects them into the <head>.

Configuration is very simple:

const config = {
  inline:   true, 
  base:     '_site',
  minify:   true,
  width:    1280,
  height:   800,
  ignore:   ['@font-face']
};

gulp.task('critical', () => {
  return gulp.src('index.html')
    .pipe(critical.stream(config))
    .pipe(gulp.dest('_site'));
});

The task inserts the extracted styles in a <style> tag and includes a tiny script to load the main CSS after the page is done:

Offline is the new black

To establish offline support, there’s no way around Service Worker.
A Service Worker is essentially a piece of Javascript that sits between the client and the network,
to intercept requests and deliver assets, even without an internet connection. It’s a powerful thing.

A few requirements for this to work though:

The Browser has to support service workers
Only secure connections over HTTPS are allowed

There are different methods of letting SW handle network requests, you can find a great outline in The Offline Cookbook, written by Jake Archibald.

On my site, I opted for a pretty simple approach. Since it’s all static files, I can pre-cache the most important assets and top-level pages in a Service Worker to drastically reduce the amount of data and network requests necessary. When a client first hits the site, the SW installs itself and caches a list of ressources with it, after the page has loaded:

network requests made by Service Worker — See the small Cog Icon? That's the ServiceWorker doing its thing.

Now, once it is active, the SW can intercept all requests to files in its cache, providing them instantly on the next call.
Here’s what happens when the client navigates to another page:

cached assets delivered by the service worker

Everything important is instantly available. Even when offline, these assets can be accessed.

Managing the Service Worker of course also means keeping track of what has changed, to replace deprecated assets with new versions.
To make this easy, I used a tool provided by the Chrome team called sw-precache.
It can be integrated in the build process to check for changes everytime the site is deployed.

When it finds something has changed, it generates a new sw.js Service Worker file, which will replace the old one as soon as no one’s looking. You can simply pass it a set of files to watch, and never have to worry about cache invalidation again.

The Results 🎉

Here’s how it turned out. I’m pretty happy with it!

WebpageTest

Google PageSpeed

pagespeed results — analytics is not properly cached - oh the irony 😒

Google Lighthouse

Alright, that’s it! Let’s see how much of this still holds up in 2018. See you then!

blogs
tech

Frontend Developer Interview Answers

Max Böck

I recently came across the H5BP’s Frontend Developer Interview Questions. It’s a collection of questions related to building websites, meant for employers to vet potential candidates for a job.

Although I’m currently not looking for a (regular) job, I thought it would be interesting to try and answer as many as possible and see where I stand.

I think when you first start learning about web development, you cover all these basic principles, but once you get better and move on to more advanced problems, you don’t really think about them anymore. So it can’t hurt to revise that stuff every once in a while, right?

There’s questions on HTML, CSS, JavaScript and general programming knowledge.
It was an interesting exercise because it got me thinking a lot about these fundamentals. If you’re interested, I published my answers on github.

Of course, some of these questions depend strongly on the context, and some are deliberately phrased to provoke a discussion. It’s a lot of questions, and I didn’t want to write a novel there (since, again, this was just for my own curiosity).

So my answers are far from perfect and in some cases barely scratch the surface of a topic. But hey, I’m not on trial here, so calm down 😉

blogs
tech

The Lost Art of the Gigposter

Max Böck

I’m a big fan of good looking band art. Sadly though, unlike other countries, Austria doesn’t really have a culture of well designed concert posters - they’re usually just bold type on bright neon paper stapled to a signpost. So for a long time, collecting and designing covers and gig posters for local bands has been one of my favourite hobbies. I just love when music and design come together like this.

There are some very talented people out there dedicated to poster art. Some of my personal heroes, for example, include DKNG Studios, Olly Moss and Kevin Tong. Go check em out if you have time, they’re all brilliant.

Here are a few of my own works that I made over the years: