Garrett Winder - Erskine Design

Questioning the quality of our work

Wed, 20 Nov 2013 00:00:00 -0600

We took a break from client work last week to hold our second Erskine Breakfast event in our Nottingham office. It was a packed house and the topic of discussion was the creative process. This is a summary of my talk on improving the quality of our work throughout the project lifecycle.

Our design and development team is constantly improving the way we work together across different “departments” as well as with our clients. Questioning the quality of our work, the communication with our clients and how we can make that better.

Over the years we’ve naturally transitioned our approach to creating web projects from a siloed waterfall approach to working more collaboratively. Most of the changes we’ve made spawned from the following areas.

Design implementation

Design implementation breakdowns are a classic example of working separately on a project rather than together. The designer makes their masterpiece, emails it to the developer and the final implementation isn’t quite as it should be. LOL.

This is an easy one, and we can avoid it by putting more thought into our design deliverables and, as a designer, thinking more like a front-ender in terms of deliverables.

“Thou shall not leave guesswork to the front-end developer.”
—Albert Einstein

Here are a few examples of design deliverables we’ve introduced over the last few years. Hint: lives have been changed.

Living, master color guide

Detailed typographic styleguide and how the elements of the page fit together

Fully exported, optimized and organized imagery

Breakdowns in communication

This can be both an internal issue with our teams and an external issue with our clients.

Clients first. At the start of a web project we shouldn’t assume the client knows what we’re talking about. Don’t roll into a kickoff meeting beatboxing buzz words. Guide and teach your clients in plain, simple language all the way through. They’ll love you for that new found small talk they can bust out at next year’s holiday bash.

Internally we need to talk more cross department. It should be fair game, and encouraged, for designers to have development feedback and vice versa. Also, daily stand-up meetings. Knowing what everyone on your team worked on yesterday, is working on today and is having trouble with is a life saver for productivity and openness.

Maintainability

The key to maintainability is realizing early on that a web project is never over and that shortcut you took last week will haunt you next year. It doesn’t matter what your project conventions are as long as your project has conventions and your team is sticking to them. Build for maintainability and build for the future.

EECI EU 2012 - Illegally good front-end

Fri, 08 Jun 2012 00:00:00 -0500

The EECI EU 2012 conference is Europe’s largest gathering of ExpressionEngine aficionados, drawing delegates from a wide range of countries and with a great line up of top level speakers.

Best practices for breaking websites down into scalable, reusable components.

Last week I got the chance to go back to Leiden for EECI and spoke about “Illegally good front-end”. The presentation covered topics such as the anatomy of a website, our front-end workflow and how it can be constantly improved. Below is a link to the presentation as well as a few other relevant links.

Resources

Illegally good front-end presentation on Speaker Deck
The Ultimate Package (Erskine’s baseline front-end framework)
The Ultimate Package wiki (Erskine’s front-end documentation)
Typographic styling with SCSS
Planning and documenting front-end components

You can find other articles on this topic around my site as well as on Erskine Labs. As usual, if you’d like the original keynote presentation just shoot me an email.

Calculating EMs with SCSS

Tue, 08 May 2012 00:00:00 -0500

Earlier this year Erskine made the switch to SCSS and I’ve really loved what its done to our front-end workflow. One thing I’m particularly fond of is how SCSS has improved how we’re calculating EMs.

A screenshot of a website with markup showing CSS font sizes and line-height

The olden days

Before SCSS we’d simply make our EM calculation and leave a comment explaining where that number came from off to the side. This worked fine, but could be time consuming and was a nightmare when adjusting things like, say, our base-font.

Here’s an example:

h1 {
font-size:1.875em; /* 30 / 14 */
}

Using SCSS for calculations

To calculate EMs with SCSS we have a few options; using the basic number operations or definining our own function, to name a few.

Basic number operations

Using basic number operations we can drop the commenting that is needed with standard CSS and used the code as documentation. This is the technique we originally used when we switched to SCSS. This works, but we can do much better:

h1 {
font-size:(30 / 14) * 1em;
}

Defining our own EM calculation function

SCSS has tons of built in functions for common calculations, and we can even make our own. Here’s a function we’re using to calculate EMs, which is a modification of one we found in The SASS Way.

@function em($target, $context: 14) {
@return ($target / $context) * 1em;
}

This function takes 2 variables, $target and $context. $context is optional, as it defaults to 14, our base-font. Now lets rewite our example using our new function:

h1 {
font-size:em(30);
}

This is the same as saying (30 / 14) * 1em but now we don’t have to repeat ourselves all over the stylesheet.

But wait, this can be taken a step further.

Adding variables to our EM calculation. Vuala!

We can modularise this process more by defining default variables for our base-font size, heading sizes, etc. With these in place, tasks like “adjusting the base-font” can be done in a matter of seconds.

$basefont:14;
$baseh1:30;

@function em($target, $context: $basefont) {
@return ($target / $context) * 1em;
}

h1 {
font-size:em($baseh1);
}

Beautiful. Checkout the SCSS config file in Erskine’s Ultimate Package for more examples of how you can take advantage of default variables in SCSS.

Typographic styling with SCSS

Sat, 03 Mar 2012 00:00:00 -0600

Friday, right after Erskine’s end-of-week pub rituals, Phil and I went back to the office with hopes of building a website. At the beginning of last week we got fairly obsessed with typographic styling, so this would be a good time to experiment with that process a bit more.

We fired up Sublime, fetched the Ultimate Package and jumped in. We started with a simple page including kitchen sink-ish html for headings, paragraphs, links and all the other elements that get me going.

We chose a base font-size, Phil created a baseline.png file and I ate two American style hotdogs. We got keyboard shortcuts for toggling the baseline plugged in and cranked up Lynyrd Skynyrd. It was time to make Instapaper for cats.

Typography + SCSS = love

What I love about SCSS, besides variables, is its most dangerous feature: nesting. When used smartly, nesting can make your stylesheets much more modulular, reusable and maintanable. Lets take a look at the standard workflow of styling typography and how it can be applied with SCSS.

Standard workflow

Setup default font-size, line-height and margin to be inherited by generic elements and ensure they’re inline with the baseline.
Put an h1 at the top of the page, give it some line-height and margin so everything is still inline with the baseline.
Do the same with h2 through h6, but also ensure p + h(n) has proper margin and doesn’t break the baseline.
Ensure h2 + h3, etc., has proper margin and doesn’t break the baseline.
Lastly, do the same for blockquote, table and ALL THE OTHER THINGS.

That list isn’t too daunting, but it takes about 2 hours of pair brogramming to get right, 4-6 if you’re me and Phil. With SCSS, we can modularise this process by creating a little typographic skeleton. This doesn’t exactly speed up the process, but it’s a good example of how we can use SCSS to clean up our development.

Typographic skeleton with SCSS

First, we setup the defaults to be inherited by all of our generic elements. I know this is standard practise but for the sake of the case study I’ll include it:

body {
font:$normal percentage($basefont / 16) sans-serif;
line-height:(24 / $basefont);
}

Now that that’s done, we need to ensure p + h(n) has proper styling and doesn’t break the baseline. Not only p, but the other generic elements as well. This can be done beautifully with SCSS.

p, ul, dl, ol, address, figure, hr, pre, table {
margin-bottom:;

& + h2 {
padding-top:;
}
& + h3 {
padding-top:;
}
& + h4 {
padding-top:;
}
& + h5 {
padding-top:;
}
& + h6 {
padding-top:;
}
}

We need to ensure that h1 + h2, etc. have proper styling too.

h1 {
font-size:($baseh1 / $basefont) * 1em;
line-height:;
margin:;

& + h2 {
padding-top:;
}
}

h2 {
font-size:($baseh2 / $basefont) * 1em;
line-height:;
margin:;

& + h3 {
padding-top:;
}
}

You get the point, same for h3 through h6. Tada!

Summary

This exersise helped me learn a lot about the importance of extreme readability. It’s something I don’t think I’ve paid enough attention to in the past so effective immediately I’m adding it to my list of Things to take over-the-top on every single project.

Going mobile with ExpressionEngine

Fri, 06 Jan 2012 00:00:00 -0600

This article was originally posted on net magazine.

Knowledge needed: Experience in building websites with HTML and CSS.
Requires: A licensed copy of ExpressionEngine 2
Project time: 30 minutes - 1 hour
Source files: Download source files
Demo: View demo

Follow along as Garrett Winder of Erskine Design talks us through the process of going mobile with ExpressionEngine using a dedicated approach.

In the last few years mobile has absolutely exploded. It’s the way people shop, browse the web and check email and the numbers are increasing exponentially. Because of this, we need to shift our focus on building websites explicitly for the desktop and really start thinking about the context that our work is being seen in and interacted with. We need to rethink the way we’re building websites.

In this tutorial we’re going to run through some ways to integrate mobile into our ExpressionEngine workflow.

Getting started

To follow along you’ll need a licensed copy of ExpressionEngine 2. You can download it as well as find step by step installation instructions from the ExpressionEngine website.

You’ll also need to download the core files for our example site, Know your viral enemies, a fictitious educational website about common viruses and why we need to wash our hands!

Dedicated vs responsive, in a nutshell

When it comes to a mobile web experience we’ve got two options: dedicated and responsive.

A dedicated mobile website is a mobile optimized version of our website that usually resides on its own domain or subdomain. With a dedicated approach we can easily give our users the option to view desktop or mobile. We’ve also got more control over resource optimization and load time.

A responsive website is created with a mix of fluid layouts, flexible images and media queries. It gives us a tailored experience based on the width of the browser window using the same HTML and CSS. This approach also forces us to think about website structure and create cleaner, more focused design and front-end code. Since this is all done in the CSS, we won’t go through that in this tutorial (though I have included a responsive version of the example site for your rummaging).

So, without further ado, let’s get started.

The dedicated approach

With a dedicated approach, we can have two versions of a website using the same installation of ExpressionEngine.

Create a global variable in `index.php`

First off, we need to create a global variable that we can use to tell our templates to load the full or mobile version of our website. Open up your index.php file and find the following line:

$assign_to_config['global_vars'] = array(); // This array must be associative

Right below that line, we need to add the following:


/* Setup our global variable array */
$global_vars = array();

/* gv_site_version: set to 'full' or 'mobile'; */
$global_vars['gv_site_version'] = 'full';

/* Assign to global vars in EE 2 */
$assign_to_config['global_vars'] = $global_vars;

What we’ve done here is created a new global variable, just like site_url or site_name, that we can use anywhere in our ExpressionEngine templates.

{gv_site_version}

Set up a subdomain

The next step is to create a subdomain to house the mobile version of your website. This step is highly based on where you host your site, so I’ll let you and your host’s support team take care of this one.

Once you’ve got your shiny new subdomain setup, you need to copy index.php (the one we just edited) into the subdomain’s root directory. Open up your new index.php file and change the gv_site_version variable value from ‘full’ to ‘mobile’. You’ll also need to edit the $system_path to point to your main website’s system folder.


$system_path = '../domain.com/system';

/* gv_site_version: set to 'full' or 'mobile' */
$global_vars['gv_site_version'] = 'mobile';

Set up your templates

Finally, we can set up our ExpressionEngine templates. Log in to your ExpressionEngine control panel and click the Design button at the top and then choose Template Manager under Templates.

Before we create any templates we’re going to need a template group to house them. From the Template Manager screen click New group to create a new template group. For the >Template Group Name, type _home. Leave Duplicate an Existing Template Group as is, and tick the box next to Make the index template in this group your site’s home page. Click Submit. You should now be taken back to the Template Manager screen, with your new _home group selected.

Now we need to make two new templates to live inside of our new template group, one for our full site and one for our mobile site.

Be sure that your _home template group is still selected, and then click the New Template button at the top right. For the Template Name type _index_full. Leave the rest of the options as is and click Create. You should now be taken back to the Template Manager screen. Repeat the last step to create our last and final template, and name it _index_mobile.

Bringing our new templates to life

Now it’s time for us to integrate the Know your viral enemies files into our ExpressionEngine website.

The first thing you need to do is open up the index template in your _home template group, and copy the following snippet of code into it:

{embed="home/_index_{gv_site_version}"}

This is where the magic happens. When a user hits our homepage (the index template), it’s going to load either our _index_full or _index_mobile template, depending on where they’re coming from. Remember: gv_site_version will either be equal to ‘full’ or ‘mobile’.

Now we need to copy the static folder into the root of our main ExpressionEngine website so that it lives along side admin.php, images, index.php, etc. The static folder is where all the CSS and images are.

Lastly, copy the contents of desktop.html into _index_full and copy mobile.html into _index_mobile.

Now you should have a working desktop and mobile version of our website using the same ExpressionEngine installation. Yeehaw!

Giving the user the option

The dedicated approach doesn’t have to stop here, we can easily add in some functionality to give the user the option to view desktop or mobile with MX Mobile Device Detect. Download and install the add-on, then uncomment div.notification in _index_full. In order to make this work, all we have to do is change this:


<div class="notification">
    <p><a href="">Hey, there’s also a mobile site!</a></p>
</div>

to this:


{exp:mobile_detect}
    {if mobile}
        <div class="notification">
            <p><a href="">Hey, there’s also a mobile site!</a></p>
        </div>
    {/if}
{/exp:mobile_detect}

This notification will only be exposed to the frontend if the user is on a mobile device. With this in place, the user will get notified that we have a mobile version of our website if they’re browsing from a mobile device. Don’t forget to add the link to your subdomain in the anchor.

There it is. That’s all it takes to integrate a mobile experience into our ExpressionEngine workflow.

Planning and documenting front-end components

Fri, 09 Sep 2011 00:00:00 -0500

At Erskine it’s more than just accepted, but it’s encouraged to question the way things are done. If something isn’t working, figure out another way and test it out with the team. We’re always experimenting and our processes are constantly questioned. The way we’re working now is ten times better than it was six months ago, and the same thing will happen in another six months. It’s inevitable.

We recently finished a project where the deliverables were a bunch of flexible components that together built up 20+ very distinct front-end templates. We had to make this in a way that we weren’t repeating ourselves, that was easy to manage and could easily be implemented by an external team. It was a daunting task.

When we got about halfway into the project it became clear that we needed a better way to document the components, naming conventions, and front-end implementation that made up the website. Another problem that comes up with projects like this is when you get further into the project, you’ve got to refine previously made components more and more to work in harmony together. Houston, we have a problem.

After putting way too much thought into all of this, I broke the issues down into a few simple rules:

We need to build more reusable website components.
We need centralized front-end documentation from the start.
We need up-to-date access to a high level overview of the system as a whole.

Introducing the components table

The components table is a new way of developing websites that I’m currently experimenting with. You name, define and markup your components within the [fluid] table instead of inside the constraints of a website. Thus, answering all the rules above in one fell swoop.

We need to build more reusable website components

A website is a skeleton made up of an assortment of individual components that can work individually, side-by-side, and sometimes integrated together. Components should be plug-and-play, and they should be location and dimension independent. They don’t need to rely on an external source to be usable. Also, quality control should be built in at the component level. By breaking our websites down, and focusing on small elements at a time we can really dig into the details.

We need centralized front-end documentation from the start

When someone new jumps into a project, they need to be able to get up and running as quickly and efficiently as possible. They need an easy way to see how the pieces of the puzzle fit together. By it’s very nature, the components table is centralized documentation.

Sometimes we hand over front-end templates to an external web team for integration with their own systems. Developing with the components table means little to no extra documentation on project hand over.

We need up-to-date access to a high level overview of the system as a whole

We need a way to easily spot components that can be refined and integrated with each other. Flaws in the system need to be spotted sooner rather than later. Nothing is worse, or more !important, than an out of hand stylesheet. Also, when starting on a new phase of a project do we build feature X on top of existing code, or do we start fresh? What’s the naming convention for the shopping basket? This can all be found in the components table.

Though it’s just an experiment, the components table fixes a lot of the problems I’ve had with front-end development. Anyone else out there trying to solve these problems? I’d love to see what you’ve come up with.

EEUK 2011 - Going mobile

Sat, 27 Aug 2011 00:00:00 -0500

Tips, techniques and tactics for going mobile with ExpressionEngine.

Photo by Joel Bradbury

Current status of mobile
Native v.s. web
Dedicated or responsive?
And how ExpressionEngine can help ease the pain

EEUK11 presentation – Going mobile (pdf)

I’ve condensed them down quite a bit so if you’d like the originals, shoot me an email.

Personal task management with Things.app

Thu, 04 Aug 2011 00:00:00 -0500

Here at Erskine we use all the usual suspects to keep the day in order: The 37signals Suite (mostly Basecamp and Campfire), Beanstalk, Harvest, Redmine, the list goes on. All of these are great for a team or client overviews, but in my opinion are not enough to personally stay truly organized.

I’ve always had a pretty obsessive approach to organization and go quite overboard with it, actually. Constantly testing, tuning and refining my personal processes until I feel like I’ve got the perfect way of doing something.

My work falls into a few different categories, and depending on the month, and phase of the moon, I’m always doing more or less of one or the other. Right now my work ranges from front-end development to internal project cheerleading and client handling. My day can get very confusing, especially when we’re busy.

Bring on the Things

For the past few years I’ve been using Things.app for task management. I’ve traded out for different applications here and there, but in the end I always come back to Things. This article is about why I use it, and how it fits into my work.

Out of the box

This is a screenshot of Things the first time you open it. The software is extremely simple: To-dos organized by projects, people, time and tags. Exactly how I think.

Tailored to your thought process

This is a screenshot of how I actually use Things. I use the 'Inbox’ randomly throughout the day to dump everything that comes into my mind so I can get back to work. I usually sift through my inbox once every morning – organizing, tagging and giving due dates to items.

For Projects, I usually use the naming convention Client name – Project name. All to-do items for that particular project are filed away in there. I use 'Areas’ for an extra layer of organization and for those to-do items that don’t exactly belong to a project, but they do belong to a client. Every client gets a 'General’ area, plus areas for major pieces of their business that Erskine work with on a regular basis.

If a task is out of my hands, but needs to be done in order for me to keep on keeping’ on, I use the 'People’ feature as you can see in the screenshot above. Lastly, tagging. For tagging I use a little of my own conventions plus most of the goodies found in this article from the Omni Focus blog.

So, that’s how I use Things. Hopefully you can take some of this and apply it to the way you work. This is something that I’m really interested in and would love to see your thoughts, conventions, etc below.

Taking our work to the extreme

Sun, 13 Feb 2011 00:00:00 -0600

95% of my everyday involves implementing and working w/ front-end languages like HTML/CSS and integrating them w/ the ExpressionEngine content management system. Not many people (outside of my twitter followers) have a clue what this means, nor will they ever see my work directly, but I still try and execute every little detail to the extreme. What?

How many of you view source on that new cool website everyone is talking about on Twitter? What about look at the CSS? No? I don’t either. But when that 1 person does look, I want it to be perfect. I want them to get knocked out of their seat like they’ve seen a ghost. Lights shine down, music starts playing. The whole 9 yards. #BOOM

For the CSS that means: Perfect tabbing, alphabetical ordered properties, thought into details like where the comments go and styling them beautifully, how specific my declarations are and making sure that every little piece of the cascade comes together flawlessly.

For the HTML that means: Tabbing, spacing, comments, simplicity, using the right elements in every single situation and not shortcutting anything with a generic span or div. I want my grandma to be able to view source on my HTML and go “Oh yeah, that’s what I’m talking about.”

As far as bringing it all together into a content management system like ExpressionEngine: How is the code outputted? Is it still perfectly tabbed and spaced? If not, make it that way (without hurting the readability of the actual template files). Does the control panel make sense to the end user editing the site and are there things you can do to fix that? Field instructions, Channel names, everything. What about the possibility of a new guy coming along and taking over your project? Does the back-end stuff look perfect for him/her as well? Make it that way.

There’s a lot more to this obviously, but you get the point. I’m not just talking about making a site look good. I’m talking about making every little aspect of the whole ordeal executed to the extreme.