Announcing Jekyll-Faker and Jekyll-Reload

, a 4-minute piece by Dev Mukherjee Dev Mukherjee

Jekyll and therefore Jekyll-Assets is part of the furniture at Anomaly. They power our web site and user interface prototypes. Late last month Jekyll-Assets released their third major rewrite of the asset pipeline processor. The release dropped the digest feature, which user interface build processes rely on, heavily. I started a conversation with it's maintainer Jordon Bedwell and Anomaly ended up sponsoring the development work to restore it back into Jekyll-Assets.

At Anomaly we use Jekyll to prototype Web user interfaces. I've been toying with the idea of building a couple of plugins that would super charge our prototyping rig. Chatting all thing Jekyll with Jordon, he mentioned that he was available to do more development work on Jekyll related projects. We decided to take him up on his offer and we are proud to share what we built together.

Realworld data in prototypes

In the past I've written about the importance of using production or randomised real world data in prototypes. It reveals all the oddities that your design mightn't cater for. Benjamin Curtis maintains Faker, which a port of Perl's Data::Faker. I kept thinking wouldn't it be nice if we could leverage Faker in our Liquid templates?

Jekyll-Faker does just that. It's the glue between Liquid and Faker, available as a Ruby Gem it makes available the "{% faker %} tag which can used as follows for any function that Faker exposes:

{% faker number between=1 between=10 %}
  <small>
    {{ faker.val }}
  </small>
{% endfaker %}

Browser autoreload

I have always wanted live reloading of our Jekyll based prototypes, it would save the endless clicks of the refresh button, specially when testing across browsers.

Meet Jekyll-Reload modern, simple, and to the point take on LiveReload for Jekyll. Simply install the Ruby Gem, add a tag the {% livereload %} tag in your template header and let your Jekyll project auto reload on change.

Enjoy

Jekyll-Reload and Jekyll-Faker are going to greatly enhance our prototyping rig. They're available to the world under an open source license. We thank Jordon for building these plugins for us and recommend you checkout and support his work.

Anomaly is committed to maintaining these projects into the future. If you have any feedback please use the the appropriate issue tracker on Github.

We hope you enjoy them.

Designing for reality

, a 7-minute piece by Dev Mukherjee Dev Mukherjee

Anomaly has always championed prototyping interface in the delivery medium. The aim discovering design problems early in the piece informed by real content, delivered to the actual target. It reveals what idealistic visual prototypes tend to mask. It's a topic that we will write about in great detail in the coming months in order to share our apporach.

We've been using a self assembled Jekyll rig to prototype Web browser based interfaces. At a minimum it provides a local web server, a templating engine and what I like about it most is that you can version the prototype.

Content informs design. In our attempt to bring designers closer to real content without necessarily exposing them to a database, we've tweaked our prototyping rig. As a teaser to a series of articles to come, here are tricks that can enhance your design pipeline.

Working with production and randomised data

Jekyll can load data files yaml, json, csv as part of it's build process. Place these files in a directory called _data and Jekyll exposes the parsed content as a dictionary accessible as site.data followed by the name of the file.

E.g a file called _data/racgp_fifth_edition_standards.yml would be accessible as site.data.racgp_fifth_edition_standards and as a result you can populate the content in your prototype via Liquid templates.

These serialization formats are widely supported and software engineers can automate populating the prototype from real world production data without the risk of exposing a live data source.

There's usually prejudice in the content used in a prototype. It's only human to pick things you like or know of, this poses the issue of not testing the design against content that the real world is going to throw at. Localisation should be at the centre of digital product design.

You want this content to be real but not determined by you, e.g a name, or an address from different parts of the world. I have been toying with the idea of using projects like Faker to produce the content. It's missing a glue to Jekyll which we intend to build and share.

Mange markup with HAML

Maintaining properly validated markup. When prototyping rather large detailed interfaces, it becomes daunting to maintain the quality of your markup. Enter HAML a markup language that’s used to cleanly and simply describe the HTML.

Sam Vincent's published this Ruby Gem that allows you to add HAML support to your Jekyll project. It integrates well with Liquid giving you the power to express rather complex production data in a Jekyll powered prototype.

An example from us templating the recently published Royal Australia College of General Practitioners 5th Edition Standards for Accreditation. We converted the standards into YAML which assisted us in loading them into the production system as well prototyping interfaces.

%main.facet.report
  %nav
    %header
      %h1= "Gundagai Medical Centre"
      %h2= "91 Sheridan Street, Gundagai NSW 2722"
    %ol
    {% for module in site.data.fifth_edition_standards.modules %}
      %li
        %h3
          %abbr= "{{ module.code }}"
          {{ module.title }}
        %ol
        {% for standard in module.standards %}
          %li
            %h3 
              %abbr= "{{ module.code }} {{ standard.number }}"
              {{ standard.heading }}
            %ol
            {% for criterion in standard.criteria %}
              %li
                %h3
                  %abbr= "{{ module.code }} {{ standard.number }}.{{ criterion.number }}"
                  {{ criterion.criterion }}
                %ol
                {% for indicator in criterion.indicators %}
                  %li
                    %h3
                      %abbr= "{{ module.code }} {{ standard.number }}.{{ criterion.number }} {{ indicator.code }}"
                      %small.complete
                        Complete
                    :markdown
                      {{ indicator.indicator }}
                {% endfor %}
            {% endfor %}
        {% endfor %}
    {% endfor %}
    %footer
      %h2= "RACGP 5th Edition"
  %section.scribe
    %header
      %h1= "C 1.1 A"
    %article
    %footer
  %section.reflection
    %header
    %article
    %footer

Ease scripting with uilang

Design should consider all states the interface and how the content behaves:

We tend to wire up portions of the interface as a point of reference for the developer. It's the truest form in which you can capture the intent of the design. On the Web this requires writing JavaScript. Since the prototype is only a point of reference we employ tools to ease this task.

Bejamin De Cock of Stripe maintains uilang. It presents an AppleScript interface to wiring up JavaScript events to simple intents like adding a class to an element.

What I like about it, the expression codes the behaviour and preserves the intent in human readable form:

<code>
clicking on ".try-it" toggles class "hidden" on ".info-box"
</code>

I recommend watching Benjamin's talk at CSSConf Australia from 2015 where he highlights that utilities like these make it less laborious to try more things out and let design become more expressive.

Epilgoue

A lot has happened at Anomaly this year, bringing me review our design and tooling process. We have learnt many valuable lessons in engineering, design, product and business. We intend to share them with everyone, so businesses can learn from our experiences and make better products.

Help me expand Tesla destination charging in Wagga

, a 2-minute piece by Dev Mukherjee Dev Mukherjee

I've been a Tesla Model S owner for nearly three years now and have enjoyed travelling all around the country thanks to destination chargers. Many months ago I expressed my views on how Tesla's destination charging programme was a paradigm shift for the tourism industry. The model is pretty simple a destination (e.g motel, hotel, restaurant) installs a Tesla connector and allows patrons to use it at no cost. Tesla in return push your business location to all car owners and advertise your location on their web site.

It's the modern day equivalent of watering the horse.

Wagga does have a couple of destination charging locations, Thirsty Crow Brewery and and the Valley parking service at the airport.

I happen to have a spare Tesla connector and since August have been trying to give it away so another destination in Wagga can join the list.

On offer a free Tesla connector to a hospitality business in #Wagga that has the foresight to becoming a @TeslaMotors charging destination.

— Dev Mukherjee (@mdevraj) August 2, 2017

I've had no success so far. I've tried to get the attention of local motels and no one, not even the tourist information centre is willing to install it and expand Wagga's destination charging options.

Destination charging literally is an excuse for us to head places, we often head to Albury for no good reason but the fact that it's an electric road trip and stay and charge at Atura (despite there being a supercharger in Wodonga).

As electric cars (not just Tesla vehicles) become prominent I urge the tourism industry in Wagga to adapt to the paradigm. Tesla offers these connectors to any business and mine is available free of charge to any business in Wagga that's willing to assist expand the electric car revolution.