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.

Next Up: a 3-minute piece by Dev Mukherjee Dev Mukherjee

Announcing Jekyll-Faker and Jekyll-Reload

Read more