Early this year, the fifth version of the popular open source framework, Ruby on Rails, was released and along with it, a new identity featuring a rearranged logo. The thing that caught my eye about this effort was that it included a thing I’ve never seen before in an open source project – a creative brief.

Rails shouldn’t feel slick. It should be warm, approachable, and welcoming. Rails is in a different place than it was in 2004. It isn't courting cutting-edge early adopters so we can lay off the gradients. Rails is now for everyone and its site should reflect that.

I’m not sure what exactly is cutting-edge about gradients but all-in-all, I’m impressed with the thought that was put into the brief. However, the caps-lock, tentacle-attack logo that resulted from the process, while remaining consistent with the project's history, doesn’t fulfill the ideals of the brief.

When feedback was solicited, I offered my help and was told how I could participate. After trying to clean up the current logo, I came to the conclusion that there were no minor tweaks that would bring the current design to a place where it would meet the stated goals, so the next best thing would be a redesign that paid homage to the original. I made this:

Even though I had no expectation that this work would be accepted, I sent along a pull request with a brief pitch explaining how this design balanced the goals listed in the brief with the logo’s history. While the Rails team was very appreciative and cordial, the work was quickly rejected which, even without any expectations, was a bummer.

This was just one experience but I’m sure there are many more like it. The open source process for design is often a complete disaster that creates a toxic environment for designers. An overabundance of personal opinion means that every design decision is turned into an undirected bake-off (which, frankly, is just as bad as those reviled crowd-sourcing design sites). It’s an uphill battle for a designer and, oftentimes, it’s just not worth the time and effort. This is a huge missed opportunity for the open source community – well-considered identity systems can inspire interest, create engagement, and set the tone of how the project is run.

As someone with a foot in both worlds, I don’t believe it has to be that way.

A New Idea

What if — just like projects have a technical lead or small team in charge of their development direction  — there was an accompanying “creative” lead, for lack of a better term, appointed to direct the design process, set expectations, and handle contributions from non-developers (like content-strategists, writers, and designers) in the community?

Perhaps it's too idealistic but maybe this could be a new model for how open source projects are run. If this sounds interesting to you, get in touch. I’d love to work with some thoughtful developers on putting this new idea into action.

If you're interested in the basics of web security —and you should be — check out this fantastic interview with Anselm Hannemann on CSS Tricks. You'll learn about how HTTPS can instantly prevent bad situations like this:

If you log in over HTTP to your backend, your credentials are sent in plaintext to the server. So, anyone who intercepts your WiFi or internet connection now has access to your CMS...

Getting started with HTTPS has never been easier. Let's Encrypt, while a bit complicated, will give you a free SSL/TLS certificate for your website. If you're working with PHP, Laravel Forge has made it ridiculously easy to secure your server with Let's Encrypt or other paid security certificates.

In any content managed website, the need always seems to arise for a structured content section that can handle multiple levels of navigation. On a recent project I wanted to apply an "active" class to every page in the current path to give visitors a better sense of where they are in the site. Before I reveal the solution, it's worth understanding the basics of how the {% nav %} tag works and exploring some of the models that Craft supplies.

The Craft {% nav %} Tag

Craft makes rendering structured navigation trivially easy with the {% nav %} tag, as we can see with this example from the documentation:

{% set entries = craft.entries.section('pages') %}

<ul id="nav">
    {% nav entry in entries %}
        <li>
            <a href="{{ entry.url }}">{{ entry.title }}</a>
            {% ifchildren %}
                <ul>
                    {% children %}
                </ul>
            {% endifchildren %}
        </li>
    {% endnav %}
</ul>

But looking at the {% children %} tag, you may have the urge to try to wrap markup around it or try to cajole it in another way but you won't have any luck. What is that thing doing?! From the docs again:

When Craft gets to this tag, it will loop through the element’s children, applying the same template defined between your {% nav %} and {% endnav %} tags to those children.

In other words: the {% children %} tag copies the markup inside the {% nav %} tag, including logic. So in the above example, the {% children %} tag would output something like this for each entry:

<li>
    <a href="https://foredesign.co/projects/logos">Logos</a>
</li>

So if we gave that li a class of active, every list item would have that class regardless of whether it was actually active or not. That won't do.

The next step is to write some logic — in this case, an if statement to figure out when we want to apply that class. What tools do we have at our disposal to figure out whether an entry is active or not? Our URL path is a good place to start: we have access to the entry slugs from the craft.entries model, it mirrors the structure of our navigation, and it changes to reflect what page our visitors navigate to. Our logic should sound something like this: "if an entry's slug is in the URL path, then give it a class of active."

The next question is, how do we turn the URL path into something we can use? Craft comes to the rescue again with the craft.request model. Specifically, we're after the segments property, which returns an array of path segments in the URL. That means we can take a URL that looks like this:

https://foredesign.co/projects/logos

and start working with it in our Craft template like this:

{# Get the segments and store then in a variable #}
{% set slugs = craft.request.segments %}

{# Dump the variable to see what we have #}
{{ dump(slugs) }}

{# Returns:
 # array (size=2)
 #   0 => string 'projects' (length=8)
 #   1 => string 'logos' (length=5)
 #}

So we have the slugs, now we just have to check if the entry slug for each navigation item is in our slugs array as we iterate in our {% nav %} tag. Maybe something like this:

{% set entries = craft.entries.section('pages') %}
{% set slugs = craft.request.segments %}

<ul id="nav">
    {% nav entry in entries %}
        <li{% if entry.slug in slugs %} class="active"{% endif %}>
        <a href="{{ entry.url }}">{{ entry.title }}</a>
        {% ifchildren %}
            <ul>
                {% children %}
            </ul>
        {% endifchildren %}
        </li>
    {% endnav %}
</ul>

We're taking advantage of the Twig in operator to check if the current entry.slug is in the slugs array and if it is, we apply class="active" to the li tag. This totally works! Now, since we're probably going to want to use this bit of code more than once, we should turn it into a macro:

{# ================================
 # In your Macros file
 # _macros.twig
 # ================================ #}
{% macro isActive(slug) %}
    {% if slug in craft.request.segments %} class="active"{% endif %}
{% endmacro %}


{# ================================
 # In your template file
 # ================================ #}
{% import "_macros" as macros %}

<ul id="nav">
    {% nav entry in entries %}
        <li{{ macros.isActive(entry.slug) }}>
            <a href="{{ entry.url }}">{{ entry.title }}</a>
            {% ifchildren %}
                <ul>
                    {% children %}
                </ul>
            {% endifchildren %}
        </li>
    {% endnav %}
</ul>

You can see that we've created a macro that will accept a slug to test and will work through the logic while keeping our code tidy and reusable. Hopefully this small example opens up a world of possibilities for your next project.

A Little Sabbatical

Amy and I spent the first half of this year taking a break from client work to rediscover our love of art and design, read, learn, cook, bake, and work on some personal projects. We also rebranded Fore Design, completely revamped our design process, found our voice, and built a business and lifestyle that is true to ourselves.

The benefits of our "little sabbatical" can't be understated. Our attitude has returned to a happy, positive place, the energy has flooded back into our work — and it shows. We won our first design award, helped one of our clients more than double their fundraising efforts, and completed a handful of projects that not only meet our own high standards but were true to the people and companies we worked with.

Work/life Integration

I've always had an issue with what people call "work/life balance" because of its implication that the two are (or should be) entirely separate. Instead, Amy and I have attached ourselves to the idea of "work/life integration." The pace of this way of living is far more sensitive to the natural ebb and flow of creative work, making every aspect of work and life more enjoyable. And with the help of a dedicated home office space, we've been able to weave work and life together in way that supports reflection and creativity.

Healthy improvements

We typically start every day with a long walk on the trail by our condo with our dog, and have turned cooking from a necessity into another creative space where we can experiment and create away from the computer. We've made gradual improvements to our diet by removing preservatives and being more thoughtful about the process of how food finds our plate. Now I bake all our bread and Amy makes granola bars for breakfast (which she's elevated into breakfast art).

Daily Learning

I've personally spent a lot of time focusing on development and have made learning a part of my daily routine. I've become fluent in JavaScript, learned how to manage my own servers, and strengthened my technical skill set — but it's all been in the service of design.

For me, the story of 2015 ends on a high note. My big takeaway from 2015 can be summed up in one thought: Design is in everything and everything can be designed.

The release of OS El Capitan brought us Safari 9, which gave web developers a slew of new features to play with. One of my favorite new features is the ability to define an icon for pinned tabs. Implementing these icons is a snap. All you need is an SVG icon (16px square works best) and a link tag in the head of your document to include it:

<link rel="mask-icon" href="icon.svg" color="#322f31">

While working on our company website I ran into a situation where the pinned tab got stuck on the default letter in a rounded square. No amount of cache clearing had any effect. However, one terminal command saved the day:

rm ~/Library/Safari/Template\ Icons/*

Ferdinand Ulrich writes the first part of a history of rounded type for FontShop, chock full of beautiful type specimens.