Andy Taylor

• 1140px CSS Grid Retired

  09:57PM — Tuesday April 9, 2013

  It’s been about two and a half years since I released the 1140px CSS Grid. Initial response was exciting; lots of people used it. However, a lot has happened in that time. When it was released, the concept of Responsive Web Design was in its infancy (I’d never heard of it). Over time, I—and the rest of the web community—have learnt how to do Responsive Web Design properly.

  I’m not comfortable with people continuing to use the framework. It was never really a great solution; just an early experiment that a lot of people participated in. It was a one size fits all, desktop first, templated grid system. In short, not how you should make a responsive website.

  So it is now retired.

• Jekyll Reading Time

  11:32AM — Sunday April 7, 2013

  Some of my posts now include an estimated reading time. I did this by taking the Liquid Filter, number_of_words and—based on a reading rate of 180wpm—used other Liquid filters to convert it to an approximate reading time. Here’s the template code:

  {{ page.content | number_of_words | append: '.0' | divided_by:180 | append: 'min' }}

  For this post, it will output: 1.6944444444444444min

  Unfortunately the X.XXXmin figure is a bit verbose. I’d prefer a whole number, or at least X.Xmin. Without append: '.0' I was getting a whole number, but it wasn’t rounded. So 1.9min would be 1min. Liquid provides more filters which could limit the figure to X characters, but they haven’t been implemented by Jekyll.

  A reading time on very short posts seemed a bit silly. I found a clever bit of template logic on Stack Overflow that enabled me to only show it on posts that are greater than 250 words. It’s a bit hacky, but it essentially uses truncatewords (without actually truncating the words), then establishes if the post is longer than the truncated length to create an if statement.

  {% capture truncated_content %}
    {{ page.content | truncatewords: 250 }}
  {% endcapture %}
  {% if page.content != truncated_content %}
    {{ page.content | number_of_words | append: '.0' | divided_by:180 | append: 'min' }}
  {% endif %}

  Because I couldn’t get Liquid/Jekyll to round the number. I wrapped it in a span with the class .time. My friend Josh wrote a jQuery script for me that rounds it to the nearest whole number:

  <script type='text/javascript'>
    $(document).ready(function() {
      $(".time").text(function (index, value) {
        return Math.round(parseFloat(value));
      });
    });
  </script>
  

• Media Queries are a Hack ∞

  Apr 6, 2013 → ianstormtaylor.com/media-quer...

  Ian Storm Taylor puts forward the idea that Media Queries make writing modular CSS difficult:

  The big buzzwords in CSS these days are “modular” and “responsive”—and for good reasons. But we’re still trying to achieve those goals with the wrong tool: Media Queries. What we actually need is a tool that doesn’t exist yet: Element Queries.

  It’s a really interesting read. He proposes that to write modular CSS, the query should be based on the width (or other variable) of the element, not on the width of the screen. For example:

  .widget (min-width: 300px) {
    font-size: 0.8em;
  }
  

  It’s a great proposal. But it also left me wondering how it would work in practice. I imagine nested elements wouldn’t be an issue:

  .widget (min-width: 300px) ul {
    list-style: none;
  }
  

  But what if you needed to add a pseudo class selector?

  .widget (min-width: 300px):hover ul {
    color: #888;
  }
  

  Does that break the syntax? Wouldn’t the Element Query need to be chained to the element? If so, while we’re throwing around proposals, could we make the syntax a little less verbose:

  .widget(width>300px):hover ul {
    color: #888;
  }
  

  Multiple queries could be linked with an ampersand:

  .widget(pixel-density>=2 & height<100px) {
    line-height: 1em;
  }
  

  Using Sass would make this both modular and self-contained:

  .widget {
    font-size: 0.8em;
    &(pixel-density>=2) {
      &:after {
        content: 'Retina';
      }
    }
    &(width>300px) {
      font-size: 1em;
      &:after {
        content: 'Greater than 300px';
      }
      &(pixel-density>=2) {
        &:after {
          content: 'Greater than 300px and Retina';
        }
      }
    }
  }
  

  However they’re implemented, I’d love for Element Queries to become a reality.

• The Implied Elements of Pagination

  09:24PM — Tuesday April 2, 2013

  Pagination can take many different forms. However, it’s generally made up of labels, indicators, arrows, or some combination of the three. There’s no single perfect implementation. But we can get close by considering each of these elements, in context, before they are removed—or implied.

  First, you should look at the type of content being paginated, and—more importantly—how it’s sorted. This should define the language used for labels. In most cases, contacts are sorted alphabetically, blog posts are sorted reverse-chronologically, and search results are sorted by relevance.

  When paginating their results, Google use the labels Next to load more results and Previous to go back from pages other than the first. They also use a page indicator to show which page you are on (more on that in a minute).

  

  This is clear. You start on the first page and move left-to-right to the next page. You always know where you are, and what clicking Next or Previous will do. This labeling makes sense for paginating content sorted by relevance (or alphabet). It does not, however, for paginating chronologically sorted content.

  Blogs are almost always sorted in reverse-chronological order. This means the newest content is on the front page, with subsequent pages containing older content. If the label Next was used on the front page, the user could only assume this would take them to the next page of content; it’s the only option. The user may comprehend the label, but it isn’t the clearest option. Older or even Older Posts is more explicit.

  The pagination system should also be consistent throughout a site. On a post page, if the label Next was used, the user would have very little idea whether they would be taken to the next-newest or the next-oldest post. With chronologically ordered content, Newer and Older aid the users comprehension more than Previous and Next.

  Google give the user every element possible to aid comprehension. But they are not all necessary. Pagination is such a strong design pattern that, when you remove detail, the user’s brain fills it in. If Google’s pagination is cut in half (as below) both the top and bottom halves work on their own.

  

  Removing the bottom means there are no labels and no numerical indicator. However, the left and right chevrons imply Previous and Next, and the oooooooooo replaces a traditional numerical indicator. This still gives the user a fairly clear¹ idea of where they are and what clicking each arrow will do.

  

  Removing the top makes this far less graphical, yet equally—or more—clear. There are no arrows but direction is implied; Next is to the right of the page, and Previous is to the left. Bing do exactly this:

  

  Designers can make good use of these implied elements by considering, and then removing them. But if they aren’t considered, they can confuse the user.

  I would argue that in the case of reverse-chronologically ordered content—whether arrows are used or not—Newer should always be to the left of the page and Older to the right. In turn, when content is sorted by relevance or alphabet, Previous should always be to the left of the page and Next to the right.

  

  The reason for this is the page indicator; it may be implied, but it’s always there. English reads left-to-right, therefore, a list of numbers should be written left-to-right.

  

  In the above example I’ve reversed Bing’s pagination. If the page indicator was removed, this might appear to make sense. But with it present, it clearly doesn’t. If the indicator (or labeling, arrows etc.) is going to be implied, the other elements should still follow the left-to-right pattern.

  When elements of pagination are removed, they are still implied. Consider these implied elements next time you’re designing pagination.

  ---

  1. As red and yellow are similar hues, users with colour blindness may struggle to differentiate the red o.

     ↩

← Newer Page 1 of 11 Older →