February 24, 2016

How to Conduct an Interface Inventory With InVision

By definition: an inventory is a gathering of items tracked in a list. This term isn’t anything new, but the idea of using this concept towards interfaces is. Brad Frost, who coined the term “Atomic Design”, states that creating agnostic patterns helps to build far more versatile components that can be used widely across a system.

In this short tutorial we’ll use InVision to create an interface inventory. We’ll work towards a finished product with components and modules that are perfectly reusable and portable.

Getting Started

A “module” is a set of standardized parts or independent units that can be assembled to construct a more complex structure. Building this way makes predictable outcomes more likely.

In order to reach this pinnacle of development utopia we’ll use InVision’s Boards feature.

Aaron Stump on Dribbble

Boards are painless to create and each one can be titled with a name and description. Once your information is complete click the “create board” button.

file

Naturally, boards can be used for various purposes, whether that be for an inventory audit such as the one we’re creating, or for branding discoveries and so on.

file

We’ll be focusing on the interface inventory for the purpose of this tutorial, but keep in mind that boards can be used for other contextual needs as well.

Creating the Audit

Now that our board has been created it’s time to get down to business and begin the real work we’ve come to do; the interface inventory audit. Depending on your workflow this can be done in a few different ways, but usually it starts with screenshots of the interface’s “atoms” such as buttons, headlines, inputs, colors and even icons. Since Atomic Design also includes “molecules” and “organisms” you can move onto each type as the process guides you.

In most cases molecules and organisms are a much higher level of inspection that includes smaller atomical/molecular pieces combined in unique ways to create a larger whole.

Alisa Law project.

Organization is definitely the most important part as you begin your audits. As you can see above I broke down a particular section into patterns and variations so I could identify portions of the interface that repeated, but had a slight variation. This is great when it comes time to code because you can find reusable patterns in order to keep your CSS lean, ultimately constructing a more modular system.

Camp Shalom project.

Atoms will help identify variations and even guide you in your naming conventions quest; the most difficult part of the job. When discovering your atoms think to yourself what is a “display pattern” and what is a “content pattern” as both will differ greatly. If this question isn’t answered correctly your code runs the risk of deviating from becoming a portable and modular unit suitable for differing contexts.

file

Color swatches are a great use case with InVision boards too. This can be a huge timesaving guide when discussing if color consistency is used throughout an interface. Swatches can also help keep track of color values required when using variables to store color information for working with CSS pre-processors.

Murmuration Malts project

Take advantage of boards to document and discuss naming conventions, functionality, plugins/libraries and even identify patterns from a higher level.

Pattern identification used alongside commenting for the Murmuration Malts project
Gif extracted from the blog post Invision Boards Design Collaboration Reimagined

Comments and sketching are a powwerful feature that can be used with boards too! Use sketching to point out parts of the interface in question, or use comments to discuss patterns discovered in order to solidify requirements before development. There are a ton of other great commenting features that come with InVision I encourage you to read more on their site.

Conclusion

Boards are really handy to use for inital discoveries, whether development or visual in intention. If you’d like to learn more you can read all about Boards on the Invision blog. As always, happy coding and thanks for reading!

February 23, 2016

Why a High Bounce Rate Isn’t Necessarily a Bad Thing

In this introductory post to “Demystifying Google Analytics” we’re going to look at what a “bounce” actually is, then show why, in many situations, this may be a metric we should expect to be high!

First, Let’s Look at What a “Bounce” Is

A bounce is what we call a visit where someone:

  1. arrives at a page on your website, and
  2. leaves that page without looking at any other pages on your site.

In other words, a visit is called a bounce if the visitor only looks at one page on your site during that session.

The “bounce rate” is the percentage of visits that were bounces during a given timeframe. We can look at the bounce rate for any given page, or for the site as a whole.

Bounce rate over time
Bounce rate over time

I’ve noticed that a lot of people get really hung up on their bounce rate–not just with websites I’ve dealt with personally, but on the web as a whole. There are plenty of well-meaning blog posts that will advise you on the range in which your bounce rate “should” fall. In general, bloggers seem to see a high bounce rate as something to be avoided.

However, There’s More to It

But as with all metrics and statistics, it’s not that simple. Consider these examples:

  • Fred is a huge fan of Envato Tuts+ We Design. He’s read every post in the archive, and follows the site on Facebook and Twitter. Today, a new post was published: Fred saw it on Facebook, clicked the link, read the whole tutorial, and closed the tab. This counts as a bounce.
  • Monika has bookmarked a particularly handy post on Envato Tuts+ Design & Illustration that she finds herself referring back to every month. Whenever she loads it, it’s just to look something up, so she has no need to click the navigation links or check out the related posts. Every time she loads it, it counts as a bounce.
  • Juan is having a problem with his Mac; he Googles the issue, and finds a forum thread that points to a tutorial on Envato Tuts+ Computer Skills. He loads the tutorial and follows the instructions... and it fixes his problem! He can get back to work now, so he closes the tab. This counts as a bounce.
  • Mary visits a different tutorial website and clicks the first post on the front page. It’s not what she’s looking for, so she closes the tab without even scrolling past the fold. This does not count as a bounce for either the front page or the post itself.

Bounces have nothing to do with how long a user has spent on the site, how far they’ve scrolled down the page, or how many times they’ve visited before. A bounce is simply a visit that lasted one page.

How Does This Apply to Envato Tuts+?

Our posts generally aren’t trying to capture users and funnel them through to a checkout page (unless you count the Envato Tuts+ Courses banners–and even then, clicking one of those counts as leaving the site anyway!), so bounce rate is not as critical a statistic for us as it is for an e-commerce site. That’s not to say it’s worthless; we just have to consider it in context.

For instance, if the first part of a tutorial series has decent search traffic but a high bounce rate, that means that people are finding the post just fine, but not clicking through to the second part of the series once they get there. This could imply that they didn’t find the first part interesting enough to want to keep reading, or that the link to the second part isn’t obvious enough, or that the post’s title doesn’t reflect its content well enough (so the people clicking through to it from Google quickly discover that it’s not what they were expecting and leave the site).

Bottom Line:

The bounce rate of your website can be informative (particularly when looked at for a specific post), but don’t get hung up on whether or not it’s in the “ideal” range.

Next Time...

In my next post, I’ll talk about cases when the bounce rate is used to measure something other than the bounce rate.

February 22, 2016

Project: The Post Page of our Static Middleman Website

Continuing with our static website build, in this tutorial we’ll style the detail page for posts, embed the podcast widget and spend a little time getting our index list in shape. We’ll also take care of style duplications and relative links.

We’ll be covering the following:

  • Posts Detail Page
  • Style Duplications
  • Relative Links
  • Index List Player
  • Why SoundCloud? (Optional)

Posts Detail Page

I think we should shift our attention and give our details page a little bit of basic love before we adjust the app to display our podcast episodes. We are not entirely done with the index page, if we have some room left in this tutorial I’ll probably add a couple of media queries to deal with different screen resolutions. For now, I’d say, let’s move on. What’s the status quo?

file

Yikes, this doesn’t look too good! Our text is all over the place. Let’s fix that one first. It’s a good idea to activate the visual grid again.

In “source/stylesheets/base/_grid-settings.scss”:

$visual-grid: true; 

Layout

That done, we need to create a separate layout for the detail pages of our posts. The layout will be flexible so that we can use them for pure blog posts and for posting podcast episodes as well—a little conditional statement will help us out with that. More on that later though. Let’s open config.rb and add this line:

activate :blog do |blog|
  blog.layout = "layouts/blog-layout"
end

This will tell Middleman that we have a separate layout for detail pages and that it can be found in “layouts/blog-layout”. Next we need to create “layouts/blog-layout.erb”. Remember that the .erb is necessary without the .html extension to make this work properly.

In “layouts/blog-layout.erb”:

<% wrap_layout :layout do %>

  <article class='article-detail'>

    <h2 class='detail-post-title'><%= current_article.title %></h2>
    <h3 class='detail-post-date'><%= current_article.date.strftime('%b %e') %></h3>
  
    <% if current_page.data.soundcloud_id %>
      <section class='soundclould-player-big'>
        <iframe 
          width="100%" 
          height="450" 
          scrolling="no" 
          frameborder="no" 
          src="https://w.soundcloud.com/player/?url=https%3A//api.soundcloud.com/tracks/<%= current_page.data.soundcloud_id %>&amp;auto_play=false&amp;hide_related=false&amp;show_comments=true&amp;show_user=true&amp;show_reposts=false&amp;visual=true">
        </iframe>
      </section>
    <% end %>
  
    <%= current_article.body %>
  
  </article>

<% end %>

So let’s talk about what’s going on here. First of all, we need to wrap this blog-layout inside our general layout. Or, put differently, we wrap our application layout around the blog-layout.

<% wrap_layout :layout do %>

  ...

<% end %>

Why? Because we want to reuse a lot of the stuff from the original layout and not duplicate things like the footer partial or the asset links in head. Just give it a minute or two to sink in if this looks weird to you at first. The layout we used previously was more of a global thing. Now we need a bit more specificity to fit our needs.

Inside the article tag container, we manually build what we need to template our post. It has a title, a date, an optional SoundCloud embedded widget and, of course, the article body itself. Inside our layouts, we have access to each individual BlogArticle. We can use current_article to get the info for each article to build up our custom template. title, date and body are just methods to extract the attributes from the individual article. We also used strftime to format the date like we did previously on the index page.

<%= current_article.title %>
<%= current_article.date.strftime('%b %e') %>
<%= current_article.body %>

As already mentioned, a simple conditional is in charge of handling data that’s provided optionally for each individual post via its frontmatter—which is delimited by three dashes. Here we are looking out if the page has the id of a SoundCloud track, and to display the widget if so:

<% if current_page.data.soundcloud_id %>

  ...

<% end %>

In case you need a refresher, we get access to the data via the current_page object and ask its data for the value we stored in the frontmatter via its key. In our example, the key we need is soundcloud_id. If our template finds this key via the conditional, it displays the widget and interpolates the SoundCloud id for that track to find the right one. If it’s just a plain blog post, we don’t need to provide the soundcloud_id in the frontmatter and the SoundCloud widget won’t get embedded.

Here’s some example frontmatter for a podcast post with a SoundCloud widget:

---                                                                                                                                 
title: My super awesome eleventh long assed titled post that breaks into another line                                               
date: 2015-11-30 22:14 UTC                                                                                                          
soundcloud_id: 138095821                                                                                                            
tags:                                                                                                                               
---                                                                                                                                 
Your awesome podcast episode description …

<%= lorem.sentences 10 %> 

– Question #01

– Question #02

...

When you click on “share” on any of the SoundCloud tracks, you get the option to embed an iframe for that track and just need to copy paste it somewhere in your code. We use this iframe as a basis and use the id for the track we need to interpolate it into the url. There are two options, a big and a small widget—I chose the big one. The other has the advantage of being a bit more customizeable—you can adjust the color for the play button for example. It’s up to you:

<section class='soundcloud-player-big'>
  <iframe 
    width="100%" 
    height="450" 
    scrolling="no" 
    frameborder="no" 
    src="https://w.soundcloud.com/player/?url=https%3A//api.soundcloud.com/tracks/<%= current_page.data.soundcloud_id %>&amp;auto_play=false&amp;hide_related=false&amp;show_comments=true&amp;show_user=true&amp;show_reposts=false&amp;visual=true">
  </iframe>
</section>

The magic happens in this part:

...api.soundcloud.com/tracks/<%= current_page.data.soundcloud_id %>&amp;auto_play=...

After we asked if this data is available to us via the conditional, we use the fronmatter data to inject the id to display the track we want. Let’s have another look how things turned out so far:

file

Ugh. On the bright side, we have all the structure and data we need. And see, because we nested the blog-layout inside the layout layout, we get the benefit of having the footer already there at the bottom. No need to duplicate things—cool! With just a little bit of styling, we might turn things around and make this look a bit more decent.

In “source/stylesheets/all.sass”:

@import 'posts_detail'

And then in the partial “source/stylesheets/_posts_detail.sass”:

#main
  +outer-container

article.article-detail
  +shift(2)
  +span-columns(8)

.detail-post-title
  color: $matcha-green
  font-size: 1.7em
  margin-top: 40px

.detail-post-date
  font-size: 1.1em
  color: $text-color

.article-detail p
  font-size: 1.05em
  margin-bottom: 4em
  color: $text-color
  line-height: 1.35em

.soundclould-player-big
  margin-bottom: 50px

Let’s have another quick peak.

file

Well, it’s getting there. Let’s commit for now, and do some housekeeping after that:

git add --all
git commit -m '1st attempt at post detail page w/ podcast option
               Adds blog-layout
               Adjusts config for blog-layout
               Adds styles for detail page
               Adds Sass partial
               Imports Sass partial
               Updates blog post’s frontmatter'

Style Duplications

The avid reader might have already spotted what we should clean up next. There is a bit of duplication in “_posts_detail.sass” and “_index_posts.sass”. I’d like to extract the duplicated styles into a separate Sass file called “_blog_post_extractions.sass”. I’m experimenting with this technique lately—an idea that I got from Object Oriented Programming. Things like BEM or SMACSS can be great, especially for bigger projects with bigger teams if they have settled for following conventions, but for smaller projects I’m always looking for frictionless, dead simple solutions. I’ll give this a try until the next new shiny thing convinces me of a better approach.

In “source/stylesheets/all.sass”:

@import 'bourbon'
@import 'base/base'
@import 'neat'

@import 'blog_post_extractions'

@import 'footer'
@import 'index_posts'
@import 'posts_detail'

An in “source/stylesheets/_blog_post_extractions.sass”:

#main, .posts
  +outer-container

.posts p, .post-title, article.article-detail
  +shift(2)
  +span-columns(8)

.post-title a, .detail-post-title
  color: $matcha-green

.post-title, .detail-post-title
  font-size: 1.7em

.posts p, .article-detail p
  font-size: 1.05em
  line-height: 1.35em

.posts p, .article-detail p, .detail-post-date, .post-date
  color: $text-color

.posts p, .article-detail p
  margin-bottom: 4em

If you compare the above with the original files, you can see that we got rid of a nice chunk of duplication. It is also easy to understand and find because I import such extracted files right on top in “all.sass”. It’s easy to spot these extractions for people new to the code base. In this case, I use these files to collect extracted styles that apply to blog posts. A similar approach could work for duplications across different appearances of sidebars, devices or similar—there should be a common thread though.

In “source/stylesheets/_index_posts.sass”:

.post-title
  a
    +transition(color .4s ease-in-out)
    &:hover
      color: $text-color

.post-date
  font-size: 0.7em
  margin:
    left: em(-80px)
    right: em(20px)

In “source/stylesheets/_posts_detail.sass”:

.detail-post-title
  margin-top: 40px

.detail-post-date
  font-size: 1.1em

.soundclould-player-big
  margin-bottom: 50px

The previous files are now a lot smaller, nice and tidy—exactly how I like them. Files are cheap, so I don’t care if I have lots of them that all do their specific little job. A separation of concerns. It’s not a perfect solution, but it’s so dead simple for small stuff that I like experimenting more with that approach.

We should also comment out our visual grid in “source/stylesheets/base/_grid-settings.scss” and see how it looks:

file

It’s the same as before, but with much cleaner styles. Me likey! Time to commit and for deploying our changes:

git add --all
git commit -m 'Extracts styles into _blog_post_extractions
               Extracts duplications from
                 _index_posts.sass
                 _posts_detail.sass
               Imports styles' 

middleman deploy

Let’s go to our GitHub Pages page and check if everything works as expected. Oh dear. On the first glance it looks fine, but if we try to go to the detail page from index, we get a 404 error message. GitHub can’t find what we need.

file

Relative Links

If you have looked closely, you might have seen that we are missing some info in our url. Now it says something like “http://your_username.github.io/2015/11/30/my-super-awesome-post.html”. What it should say is something like “http://your_username.github.io/matcha-nerdz/2015/11/30/my-super-awesome-post.html”. The “matcha-nerdz” part was completely missing. Don’t worry, this is an easy fix. We need to activate relative links in our config file:

set :relative_links, true  

Having absolute links on GitHub Pages will point in the wrong direction. With this little change, your links are namespaced relative to your app’s root. As you can see from this little example, deploying early and often is ideal for catching things like that. Finding these things out of context, when you are already working on something completely different and you have to dig deep for bugs, can mess with your flow tremendously.

git commit --all
git commit -m 'Set relative_links in config.rb'

middleman deploy

Everything should work fine now. The typography is not perfect yet, but I’d like to move on and you can fine tune these things once the site is set up the way we need it. Let’s have a look:

file

Index List Player

As you can see, we are missing the audio widget; and the length of the displayed post is not ideal for an index list. Let’s fix that next. I want to use the smaller SoundCloud player to display the podcast episode in the index list. Therefore it does not make sense to extract a partial for the player for both the index and the detail page—each page needs their own widget. If you like to use only one of the players for both layouts you should definitely extract a partial for it. I’ll leave that step to you since you’ve already learned how this is done.

In “source/index.html.erb”:

...

<div class='posts'>
  <% page_articles.each_with_index do |article, i| %>
    <h2 class='post-title'><span class='post-date'><%= article.date.strftime('%b %e') %></span> <%= link_to article.title, article %></h2>

    <% if article.data.soundcloud_id %>
    <section class='soundclould-player-small'>  
      <iframe 
        width="100%"
        height="166" 
        scrolling="no" 
        frameborder="no" 
        src="https://w.soundcloud.com/player/?url=https%3A//api.soundcloud.com/tracks/<%= article.data.soundcloud_id %>&amp;color=ff5500&amp;auto_play=false&amp;hide_related=false&amp;show_comments=true&amp;show_user=true&amp;show_reposts=false"></iframe>
    <% end %>
    </section>

    <%= article.body %>
  <% end %>
</div>

...

The code example is focused on the section where we iterate over page_articles. I added a conditional that only displays the audio widget if the article has a sound_cloud_id in the frontmatter of the article—which we access via its data attribute. It’s very similar to the way we solved this previously. In this case we used the block parameter article to access the info we need.

file

Next I want to shorten the displayed text before we apply a few styles. In the index list, we only want to see something like a 300 character summary—not too much but definitely also not too little text. Experiment on your own and see what works best for your needs.

First we need to add the gem Nokogiri to our Gemfile:

gem 'nokogiri'

and bundle it:

bundle install

In index we need to change only one line. I left a comment for what needs to be replaced. We use the summary method and supply it with the number of characters we want to see per article in the index list.

So, in “source/index.html.erb”:

<%# article.body %>
<%= article.summary(300) %>

And then “source/stylesheets/_index_posts.sass”:

And we should add the styles for the small SC player on .soundcloud-player-small to our extracted file “source/stylesheets/_blog_post_extractions.sass”:

.posts p, .post-title, article.article-detail, .soundclould-player-small
  +shift(2)
  +span-columns(8)

Nudge the spacing a bit and we’re done:

.soundclould-player-small
  margin-bottom: 1em

file

Alright, we’re getting there. Now we have an index list that displays both text-only and podcast episode articles—uncomplicated, without any fuzz. If you have better dummy text, this should look quite decent by now. Let’s commit!

git add --all
git commit -m 'Adds Article Summary & Small Widget to Index
               Adds styles for index list SC widget
               Adds Nokogiri
               Adds optional SC widget to index
               Adds 300 character summary'

middleman deploy

Break

I think you’ve earned yourself a cool beverage at this point, so we can leave it at that for now. In the next and final tutorial we’ll tweak it a bit further and also add a little something for navigating the site.

Why SoundCloud? (Optional)

“Why host the podcast on SoundCloud?”, you might ask. Well, my reasoning was simple: First of all (and I’m not affiliated to SoundCloud in any way) it will quite certainly be around for a long time—something that you can’t necessarily expect from a lot of projects that offer to host your podcast audio files. I don’t want to get myself in the situation of dealing with migrating tons of already published audio tracks to another service just because someone got acquired or went bust.

file

Second, it’s dead cheap to host a ton of tracks, and they even have a free option for folks who publish tracks only occasionally.

The player and its options are alright too—I haven’t any reason to complain about speed or anything so far. The stats are useful as well and there are already people on the platform who are interested in podcasts—which is good for the discovery factor. Don’t get me wrong, there are plenty of reasons why I wanted to hug somebody gently around the neck when dealing with uploading and silly UX things, but compared to the downsides of bigger headaches with other hosting options, SoundCloud seemed like the most reasonable choice overall. Lastly, I don’t like the custom sites these podcast sites offer. They look super generic and I like to build my own stuff that fits my needs and lets me create my own visual identity.

February 22, 2016

Project: Continuing Our Website Build With Middleman

In this tutorial we’ll continue building our podcast site. We’ll begin styling our index of posts, create a nice little footer and throw a bit of color into the mix. All that using Sass and the Bourbon suite.

Our Posts Index

Right, where were we? At the moment our site doesn’t look too great:

file

Currently our posts aren’t aligned to anything other than the left side, so we’re in need of a grid to fix this mess. Our beloved Bourbon Neat to the rescue! First we’ll add a class posts as a wrapper for our posts and make it an outer-container that centers the content on the page.

In “source/index.html.erb”:

<div class='posts'>
  <% page_articles.each_with_index do |article, i| %>
    <h2><%= link_to article.title, article %> <span><%= article.date.strftime('%b %e') %></span></h2>
    <!-- use article.summary(250) if you have Nokogiri available to show just
         the first 250 characters -->
    <%= article.body %>
  <% end %>
</div>

Then we need to create a new Sass partial for our index styles and apply some magic, so in “source/stylesheets/all.sass”:

@import 'index_posts'

And in “source/stylesheets/_index_posts.sass”:

.posts
  +outer-container

I also feel it’s a good idea to add a background color to make our outer container easily visible—for now.

file

Then commit to Git:

git add -all
git commit -m 'Adds Sass partial for index posts
               Centers content'

Recent articles, tags, and calendar stuff is in “layout.erb” and doesn’t concern us at the moment. Let’s focus instead on making this index list of posts pop. Let’s give the h2 title a class post-title and let title and paragraphs of body copy span for eight (out of twelve) columns across the page. The posts need to shift two columns over as well because we want to avoid having our copy running across the whole page and thereby exceeding a healthy line width (measure) for reading of 45-75 characters.

So in “source/index.html.erb”:

<div class='posts'>
  <% page_articles.each_with_index do |article, i| %>
    <h2 class='post-title'><%= link_to article.title, article %> <span><%= article.date.strftime('%b %e') %></span></h2>
    <!-- use article.summary(250) if you have Nokogiri available to show just
         the first 250 characters -->
    <%= article.body %>
  <% end %>
</div>

And in “source/stylesheets/_index_posts.sass”:

.post-title, .posts p
  +shift(2)
  +span-columns(8)
file

Now we’re talking. Our content is aligned and nicely centered on the page. What we’re missing is any form of visual hierarchy; our h2 titles are not much bigger than the content of our posts. To provide a better reading experience, we should make sure titles and their corresponding text have better visual contrast than that.

First, we need better text to work with, so let’s make use of a Middleman helper for dummy text. Let’s add an erb extension to our blogposts and add the following to our test posts.

Note: we need the “.erb” extension only because we want to run some ruby code between this construct <%= %>.

In “source/posts/2012-01-01-example-article.html.markdown.erb”:

This is an example article. You probably want to delete it and write your own articles!
<%= lorem.sentences 5 %>

We’ll go over the details in a moment, but first a few more styles in “source/stylesheets/_index_posts.sass”:

.post-title
  font-size: 1.7em

.posts p
  font-size: 1.05em
  margin-bottom: 4em
file

That’s a bit easier on the eyes isn’t it? We have adjusted the headers and paragraphs to a reasonable degree. A little extra margin in between posts makes all the difference. In terms of hierachy, it’s a good start.

Commit to Git:

git add --all
git commit -m 'Adjusts size for title and body text
               Adds dummy text
               Adds .erb extension to dummy posts'

Footer

On with the footer. I think we should take care of the ghastly floating elements on the bottom first. Let’s pack “Recent Articles” and “Tags” in a footer and get rid of “By Year”. The relevant markup is part of the global layout in “source/layouts/layout.erb”. Find the code in the aside tag below yield and adapt it as follows. In “source/layouts/layout.erb”:

<footer>

  <div class='recent-posts'>
    <h3>Recent Posts</h3>
    <ol>
      <% blog.articles[0...10].each do |article| %>
        <li><%= link_to article.title, article %> <span><%= article.date.strftime('%b %e') %></span></li>
      <% end %>
    </ol>
  </div>

  <div class='footer-tags'>
    <h3>Tags</h3>
    <ol>
      <% blog.tags.each do |tag, articles| %>
        <li><%= link_to "#{tag} (#{articles.size})", tag_path(tag) %></li>
      <% end %>
    </ol>
  </div>

</footer>

The above default business of just looping through our posts and tags that comes with Middleman is fine. I want to have it a bit smarter, though, and introduce shuffling to both recent posts and tags. That way, the user doesn’t only see the last ten articles or a huge list of tags, but a randomized version of both that is always ten items long. They also don’t consume a whole lot of space and let me align both items consistently in the footer. I renamed the h3 for posts as well, in “source/layouts/layout.erb”:

<footer>

  <div class='recent-posts'>
    <h3>Random Posts</h3>
    <ol>
      <% blog.articles.shuffle[0...10].each do |article| %>
        <li><%= link_to article.title, article %> <span><%= article.date.strftime('%b %e') %></span></li>
      <% end %>
    </ol>
  </div>

  <div class='footer-tags'>
    <h3>Tags</h3>
    <ol>
      <% blog.tags.to_a.shuffle[0...10].each do |tag, articles| %>
        <li><%= link_to "#{tag} (#{articles.size})", tag_path(tag) %></li>
      <% end %>
    </ol>
  </div>

</footer>

### Alignment

I think we’ve improved the user experience quite a bit through that little enhancement. Ruby made our job super easy. Now this markup only needs a little push for better alignment. We create a new Sass partial for just the footer. In “source/stylesheets/all.sass”:

@import 'footer'

And then in the partial “source/stylesheets/_footer.sass”:

footer
  +outer-container
  border-top: 1px solid $base-border-color
  padding:
    top: 4em
    bottom: 4em

.recent-posts
  +shift(2)
  +span-columns(6)

.footer-tags
  +span-columns(2)

.recent-posts, .footer-tags
  h3
    font-size: 1.7em
  li
    font-size: 1.05em

In order to have some tangible test data, I added a couple more example posts via the middleman generator and gave it some dummy lorem text. Via the terminal:

middleman article 'Your fancy title'

I should probably mention that I also needed to add an “.erb” extension to these new posts for the dummy lorem text generator. The frontmatter contains a couple more tags to play with as well.

In “source/posts/2015-12-01-your-fancy-title.html.markdown.erb”:

---
title: Example Post
date: 2015-12-01
tags: example, bourbon, neat, middleman
---

This is an example article. You probably want to delete it and write your own articles!
<%= lorem.sentences 5 %>

The goal was to have at least ten posts and tags to see if everything aligns properly. Let’s see what we have here:

file

The background colors have fullfilled their duty for now. Let’s kill them and check if we’re happy with the actual result:

file

I think we can leave it like that for now. Time to commit our changes!

git add  ../layouts/layout.erb
gco -m 'Adapts layout and adds footer'

git add ../stylesheets/_footer.sass ../stylesheets/all.sass
git commit -m 'Adds styles for footer and imports Sass partial'

git add ../posts/*.markdown.erb
git commit -m 'Adds a bunch of dummy posts with:
              dummy lorem text
              dummy tags'

Deploy

Before we move on, we should deploy to GitHub Pages, check our progress and make sure we’re not running into any surprises.

middleman deploy

Open your browser, go to yourusername.github.io/your_project_name and see if you’re happy with your site so far.

Extraction

What should we do next? You’re right, the footer screams in big letters EXTRACTION! We’re going to take the <footer>, create a new folder for partials and put the markup in there. In turn, we need to render that partial from “source/layouts/layout.erb”:

<body>
  
  <div id="main" role="main">
    <%= yield %>
  </div>

  <%= partial "partials/footer" %>
  
</body>

Then in the partial “source/partials/_footer.erb”:

<footer>

  <div class='recent-posts'>
    <h3>Random Posts</h3>
    <ol>
      <% blog.articles.shuffle[0...10].each do |article| %>
        <li><%= link_to article.title, article %></li>
      <% end %>
    </ol>
  </div>


  <div class='footer-tags'>
    <h3>Tags</h3>
    <ol>
      <% blog.tags.to_a.shuffle[0...10].each do |tag, articles| %>
        <li><%= link_to "#{tag}", tag_path(tag) %></li>
      <% end %>
    </ol>
  </div>

</footer>

If you paid close attention you’ll have seen that I removed the date for the list of articles in the footer. I did this for two reasons. First of all, we’re going to save a bit more space so that we don’t easily run into the scenario that the alignment with the tags breaks when the title for the post is a bit longer. Secondly, I thought it is a bit distracting and doesn’t add too much.

This list of randomzied articles in the footer is a handy way to introduce new stuff to the audience. The date doesn’t play a big role in that. The same goes for the number of articles for the tag links. They waste space without adding too much value. Also, if you don’t have too many articles for a certain tag, it doesn’t look empty right away. I’d rather have more space for a stable layout. It also feels a bit more clean, but that is completely subjective.

file

Commit:

git add --all
git commit -m 'Extracts footer into partial 
               Removes date from post links in footer
               Removes number of articles for tags in footer
                 Didn’t provide enough value to sacrifice space'

More Dates

While we’re at it. Let’s take care of the date in our index titles. I think their size is way too prominent which does not improve our visual hierarchy and I don’t like having it at the end of the title. I’d rather stick it on the other side and use it as a visual anchor that doesn’t jump around with varying title lengths.

In “source/index.html.erb”:

<div class='posts'>
  <% page_articles.each_with_index do |article, i| %>
    <h2 class='post-title'><span class='post-date'><%= article.date.strftime('%b %e') %></span> <%= link_to article.title, article %></h2>
    <%= article.body %>
  <% end %>
</div>

And in “source/stylesheets/_index_posts.sass”:

.post-date
  font-size: 0.7em
  margin:
    left: em(-80px)
    right: em(20px)

The title of the post is reordered and starts with the span that contains the date. I left a little whitespace between the span with the date and the title itself, because if I align the date with the article body text for smaller screens then I have a natural one character space between the date and the title–and don’t need to use Sass unnecessarily.

The Sass code is straightforward. The negative margins help me to visually anchor the date to the left of the title and I used a Bourbon function to convert their pixel values into ems. Simple, but I like the hierarchy we’ve achieved. The eyes have something to jump to via the dates and the rest has enough whitespace so that we can stay away from using borders to divide our posts. Me, happy!

file

Commit to Git:

git add ../index.html.erb ../stylesheets/_index_posts.sass
git commit -m 'Changes order for date and post title on index page
               Styles date to create visual anchor'

And deploy:

middleman deploy

Color

Let’s bring this thing to life a bit—but not too much. Less is more! I went to COLOURlovers and played with a couple of color palettes. Watch out for solutions that can enhance your visual hierarchy, but stay away from colors that are screamishly loud. I realize that this is vague, since colors can be very subjective and culturally loaded, but that’s how I approach it at the moment anyway.

In our variables “source/stylesheets/base/_variables.scss”:

$matcha-green: #78B69D;
$text-color: darken($medium-gray, 20%);

Back to business; after playing with some ideas, I added two new global colors to my Sass variables file from Bitters. $matcha-green is now the color I wish to use for my identity and placed in this file I can reuse this variable wherever I please. Should I change my mind about what green I want, I will need to change it in once place. Also, I wasn’t too happy with the default color for text. Using a Sass function I darkened one of the preset colors from Bitters by 20 percent and stored that as $text-color. Post titles on hover, as well as dates and body copy received the new text color. The default was too dark in my opinion.

In “source/stylesheets/base_typography.scss”:

// transition: color $base-duration $base-timing;

And then in “source/stylesheets/_index_posts.sass”:

.post-title
  font-size: 1.7em
  a
    +transition(color .4s ease-in-out)
    color: $matcha-green
    &:hover
      color: $text-color

.post-date
  color: $text-color

.posts p
  color: $text-color

I also added a slight transition through a Bourbon mixin for hovering over .post-title. This changes from $matcha-green to $text-color over .4 seconds. Check my articles about Bourbon Mixins if you want to know more.

In case you’re wondering about the ease-in-out part, it’s one of 32 ways to time transitional behaviour. ($ease-in-out, as a $variable, like in the documentation, will throw an error) It’s a small enhancement but looks a lot better than browser defaults. To make this work I also had to uncomment the default transition behaviour from Bitters first in “base_typography.scss”.

In “source/stylesheets/_footer.sass”:

footer
  border-top: 1px solid rgba($text-color, .3)

.recent-posts, .footer-tags
  color: darken($medium-gray, 20%)
  a
    +transition(all .1s ease-in-out)
    color: $text-color
    &:hover
      color: $matcha-green
      border-bottom: 2px solid $matcha-green

Lastly, I adapted the colors for the footer as well. This gives us a coherent appearance and hopefully a bit of subtle understatement. The transitional behavior needed to be sped up for the links in the footer. Since they are grouped so tightly together I felt it wold be better if they were a bit snappier and underlined as well.

In terms of color, I did the oposite as with the titles in the index list. Since the footer list doesn’t need to be as present on the page—especially with so little distance between them—I gave them the default gray text color and only use the $matcha-green when hovering. In this example we only use whitespace and the sizing of type to achieve hierarchy.

Oh, and the border above the footer needed a bit of opacity via the Sass rgba function. I figured that 30 percent opacity is just enough to do its job without sticking out that much.

Not too shabby-looking, for such a small amount of code. Exactly how I like it—the less code you write, the fewer bugs there are to bite you!

file

Commit to Git:

git add --all

git commit -m 'First attempt at tuning colors
               Adds new brand color as $matcha-green
               Adds new $text-color:
                 Body copy
                 Post titles hover
                 Footer headers
               Takes care of hover transitions
                 Comments out Bitters default transition'

## Tweaks

One more little thing that irritates me is the line-height of the body copy. Let’s tweak that too. In “source/stylesheets/_index_posts.sass”:

.posts p
  line-height: 1.35em
file

Commit:

git add ../source/stylesheets/_index_posts.sass
git commit -m 'Adjusts line-height for body copy on index'

And, again, deploy:

middleman deploy

Break

Good job so far! It’s high time for another break. In the next tutorial we’re going to add a navbar and a “hero unit” on top. See you there! Get yourself a snack and chill for a bit!