Robert Nealan

Using the WordPress REST API with React.js

Sat, 03 Nov 2018 00:02:17 GMT

It’d been a few (happy) years since I last used Wordpress for a client project, but with its now (questionably-)stable REST API it came up last year as a potential candidate for backing a React-based magazine/news site. After doing some digging it became clear that it was not only a possible candidate, but a frontrunner amongst the options as it would provide ~80% of what we needed with minimal work, potentially providing huge time and cost savings to our client.

Unfortunately, its cryptic documentation left something to be desired and most articles around the web were either for v1.x, out of date with current v2.x changes, or just plain wrong. So as usual with Wordpress, it was up to us to sort out that other 20% for ourselves.

Adding Endpoints for Custom Post Types
Adding Custom Metadata to API Responses
Adding the Featured Thumbnail to Single Post Responses

Adding Endpoints for Custom Post Types

In our project’s case we are using the default Wordpress “Post” post-type for the bulk of the site’s news and blog articles (sorted into categories), but needed to add Custom Post Types for our other content types like Events & Videos.

If you’re familiar with adding Custom Post Types (CPTs) the snippet below for our “Events” CPT should look familiar (if not I recommend reading up on them first in the Wordpress Codex or on Elegant Themes’ excellent guide to Custom Post Types). There’s a lot going on this, but lines 35-37 are the specific part relevant to making the CPT accessible through the REST API.

Line 35 tells Wordpress to expose this CPT in the rest API (pretty self explanatory).

Line 36 gives the CPT a URL base within the API. Rather than query /wp-json/wp/v2/posts/ for a normal Post, this tells Wordpress you want to be able to query this CPT at /wp-json/wp/v2/events/. You can change this to be anything you want as long as it doesn’t collide with another CPT or built-in post types (Post, Page, etc), though it generally makes sense to keep it the same as the CPT’s name.

Line 37 tells Wordpress to extend the default WP_REST_Posts_Controller for functionality related to handling API calls. It’s technically possible to heavily extend or customize this, but that’s outside the scope of this article.

For our purposes we’re using these CPT endpoints as read-only GET requests, but they can also be used for your standard POST/PATCH/DELETE requests if you setup an auth layer to verify those requests.

Adding Custom Metadata to API Responses

Now that we have a CPT setup we can query the API for a list of events, a single event, and more (all documented reasonably well here on the REST API Handbook). Unfortunately, if you’re creating a CPT there’s a good chance the default schema won’t store everything you need and you’ll need to customize the response to add additional fields. There’s two ways of doing this that we explored and found as viable routes:

The Native Wordpress Way

To add additional fields without using a plugin you’ll have to use the register_meta hook in your functions.php. This is documented here, but is formatted as register_meta(post_type, meta_field_name, array($args));. In our case wanted to add the city our event was taking place in (amongst other things):

register_meta('event', 'city', array(
     'type'         => 'string',
     'description'  => 'An string containing the city in which the event is taking place.',
     'single'       => true,
     'show_in_rest' => true
 ));

event is our custom post type from earlier, and city is the name of the metadata field we’re adding.
type can be either a string, object, or integer.
description should be a plain English explanation for what the field is used.
single tells Wordpress that this meta field should be used on an individual (or “single”) post.
show_in_rest is what actually exposes the field on the API response.

Using Advanced Custom Fields (ACF) for Custom Metadata

The above way of registering custom metadata works well, but unfortunately left us with the issue of needing to either build custom metaboxes or having our client edit the content using the clunky default metaboxes, which wouldn’t work for fields where there might be zero, one, or several repeating items depending on the “Event” — enter using ACF Pro.

ACF has been a staple of most Wordpress projects I’ve built in the past several years, and is one of maybe two or three plugins I can actively recommend using on a site¹. It’s extremely easy to setup and customize, and by default has a much improved editing experience for editors than the default Wordpress metaboxes. Unfortunately integrating it with the Wordpress REST API isn’t officially supported just yet, and there wasn’t a clear answer on the best way to add data input through ACF forms to each API response.

Adding the Featured Thumbnail to Single Post Responses

Oddly the Wordpress API only exposes the media ID for post‘s featured image rather than embedding it directly. While it would be pretty easy to get the image URL by querying the media endpoint after receiving the first response it seemed wasteful to make multiple API calls if it could be avoided, and this wouldn’t scale well once we start showing lists of posts where they all have featured images. Enter the _embed query param.

This is briefly documented on the Linking & Embedding page of the API Handbook, but simply requires adding a ?_embed query param to the end of your request, so a GET request to /wp-json/wp/v2/events/ becomes /wp-json/wp/v2/events?_embed. It’s not entirely clear why the Wordpress team has taken this approach, but it updates the response to include an attribute called wp:embedded on the response object, which includes all details about attached featured images.

Just be wary if you’re fetching a large number of posts as this can balloon the JSON response size substantially.

I otherwise avoid plugins at all costs as they tend to trade flexibility for stability, and are rarely written correctly. ↩

An Adventure in Blurring a Cross-Origin Image Client Side Using the HTML5 Canvas

Fri, 21 Oct 2016 02:45:00 GMT

While working as a frontend developer means I get to experiment with new javascript frameworks on at least a yearly basis, it’s far less frequent that I get to interact with new, native browser technologies, let alone ones that have wide enough support to be used in production. Thankfully Proton Radio, one of my [amazing] long-running clients has provided the exciting opportunity to experiment with the Web Audio API (more on that later) as well as the HTML5 Canvas in order to implement a variety of features that wouldn’t otherwise have been possible.

The Project and the Problem

Proton Radio is an online radio station that continuously streams ~1-2 hour electronic DJ mixes 24 hours a day, and features a custom banner image for most of those mixes (for those that don’t have their own banner image we have a variety of fallback images so they still look spiffy). As part of our new Beta redesign we really wanted to minimize the noise by putting these unique banners front and center, and started looking at ways we could make the landing page feel unique to the current DJ mix by applying a matching unique full-page background.

The Proton Beta prior to our canvas adventure.We knew we wanted to take that image in the middle and apply it to the gray background in an elegant way, but we weren’t quite sure of the best way to make it happen.

Unfortunately, to make things more complicated all the original image assets were created at 578x291 pixel resolution (some dating from the early-2000’s), and stretching them out even on small screens causes them to quickly become extremely pixelated. While we hope to create new banners at higher resolutions in the future, redoing the entire back catalog of thousands of images just wouldn’t be practical.

Considering the Options

We initially discussed extracting the color profile from the image to a CSS gradient to the background, but this seemed like a halfway solution as it wouldn’t have nearly as much depth as the images itself. Instead, we decided to explore the possibility of scaling up and applying a gaussian blur to the image itself as it would both mask any evidence of pixelation and would give the page a great sense of depth between the foreground and background.

Process Images Server-Side

The most obvious solution was to process all the banner images server-side to have a new 1920x1080, pre-blurred copy that we could then apply as a fullscreen CSS background-image with background-size: cover; to keep it in proportion. From a technical standpoint this would actually be easy to implement as open source image processing libraries are plentiful and simple to use, but on the downside our users would suddenly need to download an additional 150-200kb+ image that exists only to add some blurred, superficial ambiance — something we wanted to avoid if at all possible in our mission to keep page load time down.

CSS3 Filters

The second suggested solution was to use the CSS3 Blur filter, but as I suspected support is still pretty spotty, and the performance is abysmal enough to make the fans in my 2015 Macbook Pro sound like a jet engine about to take off. There’s also the annoying issue that the blur filter leaves a lighter ring around the image edge due to it assuming the off-canvas area is white/transparent, so you have to do temperamental negative margin hacks inside of a container element with overflow: hidden; set to get it looking right.

I look forward to the day CSS3 filters are production ready, but I’m guessing we’ve still got at least a few years to go.

Image Processing With Javascript

This left us with our third option of processing the images client-side with javascript — an option I honestly wasn’t all too familiar with despite working in javascript on a daily basis, and assumed wouldn’t be reasonable from a performance standpoint on older devices.

Looking into it I quickly figured out that we’d likely need to use a <canvas> element, which based on a few different blog posts should allow me to apply almost any image filter imaginable. Unfortunately, up until this point I never completely grasped the purpose of the <canvas> element, so I decided to do some research and try to add some clarity, starting with the Mozilla Developer Network (MDN) Canvas tutorial.

<canvas> is an HTML element which can be used to draw graphics using scripting (usually JavaScript). This can, for instance, be used to draw graphs, make photo composition or simple (and not so simple) animations…

This quick description along with the rest of the article helped, but I still had only a vague understanding and too many unanswered questions. Why do we need an element to draw to when we have the DOM? Why can’t we just use SVG? What’s better about the <canvas> compared to anything else? It wasn’t until I actually started playing around with the canvas in javascript and used some basic drawing methods that it really clicked.

Looking back, I think the <canvas> can be better introduced as “a rectangular DOM element that contains a 2-dimensional grid of pixels, onto which you can draw arbitrary lines, shapes, or graphics using x,y or vector coordinates relative to the <canvas> element itself, without the performance overhead normally involved with manipulating DOM elements.”

Or more simply, it’s kinda like MSPaint for the browser, except you draw with code instead of a paintbrush tool. And it’s fast…real fast.

Getting Knee Deep in Canvas Land

With all that in mind I quickly came across a few image blurring libraries, the most popular of which is an old-school standalone script called Stackblur.js. At first glance I was a bit wary as its author’s website hasn’t been updated in years and it lacks an official Github page, but it thankfully turns out there’s several popular forks of it on Github, including a NPM module called stackblur-canvas that adds a few extra features. As a plus, this fork also has just short of 500 stars and the occasional Github issue filed, so I can be a little more confident there’s some community support to push patches should it needed to be updated in the future.

While setting it up and blurring an image based on the README was surprisingly quick, there were a few gotchas we figured out along the way.

Canvas Elements Are Dumb by Design

Canvas elements are by design unaware of anything you draw in them other than the color value of each pixel. This can be frustrating if you need to get intelligent information out of a canvas element, but its what helps make them so performant compared to manipulating full DOM elements. Rather than keeping track of the position of a bunch of vector elements, its just a X/Y grid with a native API to help you draw to it. The downside of this is it also means that the canvas element is unaware of your original image’s aspect ratio, so you have to do those calculations prior to drawing into it and recalculate anytime there’s a window resize event.

// resizeCanvas() // // Resizes the background canvas element to maintain img proportions // while centering and stretching canvas to fill fullscreen.

let resizeCanvas = function(img_ratio) {
let window_w = window.innerWidth;
let window_h = window.innerHeight;

let window_ratio = window_w / window_h;

if (img_ratio > window_ratio) {
$(‘#dataCanvas’).css(‘height’, window_h).css(‘width’, ‘auto’);
let canvas_w = $(‘#dataCanvas’).width();
$(‘#dataCanvas’).css(‘left’, ((canvas_w - window_w)/2) * -1)
.css(‘top’, ‘auto’);
} else if (img_ratio < window_ratio) {
$(‘#dataCanvas’).css(‘height’, ‘auto’)
.css(‘width’, window_w);
let canvas_h = $(‘#dataCanvas’).height();
$(‘#dataCanvas’).css(‘left’, ‘auto’)
.css(‘top’, ((canvas_h - window_h)/2) * -1);
}
};

Canvas Elements Require CORS Headers

Canvas elements require proper CORS headers on images to be set prior to drawing, otherwise the canvas becomes “tainted” and you can no longer read information out of it due to the potential security implications. While we aren’t reading out any information for our application in an obvious way, behind the scenes it turns out Stackblur actually applies the image to the canvas, reads out all the pixel data, calculates the new blurred values, and then applies that over the original image.

The good news is that setting CORS headers for a specific directory is actually really simple in most HTTP servers, and for us amounted to adding the three lines of code below to our Apache httpd.conf file (in many cases this will/should actually be a separate .conf file in the /etc/apache2/sites-available/ folder specific to the VirtualHost in question). You’ll also likely need to set the img.crossorigin attribute to '' or 'anonymous' in order to prevent it from having issues in certain browsers (you can read more about CORS enabled images on MDN’s article), though browser support for this attribute seems to be inconsistently implemented at best.

<Directory "/path/to/folder/containing/images">
  # If you have specific sub-domains you can list them instead
  # of using the '*' wildcard.
  Header always set Access-Control-Allow-Origin "*"
</Directory>

Android 4.4 and Below Don’t Support Image CORS Rules

Android 4.4 and below aren’t a huge part of our user base, but at ~2.5% its still enough traffic to be concerned when there’s a application-breaking bug present. In our case we kept getting a cryptic “Uncaught Error: unable to access image data: Error: unable to access local image data: Error: SECURITY_ERR: DOM Exception 18” reported in Bugsnag¹ for old Android devices that didn’t seem to be accurately working with sourcemaps and had no clear answer we could find on StackOverflow. As luck would have it though, I temporarily disabled the background blur for the better part of an afternoon and the error suddenly disappeared. With an Android emulator I was able to reproduce the error, which revealed a less-cryptic alert message I was then able to trace back to the uncompiled Stackblur.js library. I thought it might have to do with the outdated netscape.security.PrivilegeManager rules (the stackblur-canvas package has since removed these), but manually omitting them didn’t seem to make a difference.

While I couldn’t find any answers via Google, I finally looked deeper into CORS rules and support to see if I was missing something — turns out that Android 4.3 and below specifically don’t support CORS for images in a canvas — exactly what we were trying to do! You’d think this would be a common point of discussion, but with Android <4.3 being on its way out I ended up discovering it in the footnotes of the CanIUse CORS page (only shows up “Show All” is enabled).

Screenshot of caniuse.com’s CORS InformationAlways make sure to click “Show All” and double check the footnotes for potentially vital ~~life~~ time-saving information.

If you’re serving images from the same domain as your client application this of course won’t matter, but in our case changing the infrastructure to serve our flyers off the same domain as our Beta, Staging, and local environments wasn’t worth the extra complexity it’d introduce to our already-complex infrastructure setup.

After some deliberation we agreed that not having a blurred background image for older Android users was an acceptable level of “graceful degradation”, so I added a simple method to detect Android browser versions and skip over the backgroundBlur method for those with problems¹. Despite caniuse.com showing that Android 4.4 should support CORS rules on images, we noticed that about half our Android 4.4 users were experiencing problems so we opted to exclude them also.

// whichAndroid() // // Checks the userAgent to see if it’s an Android device and returns the version // number if true. Returns false on all other browsers/devices.

let whichAndroid = function() {
var userAgent = navigator.userAgent.toLowerCase();
var check = userAgent.match(/android\\s([0-9.]*)/);
return check ? check[1] : false;
};

Chaining it All Together

After a lot of research, some trial and error, and a bit of luck, we pushed our last update to the background blur several weeks back and haven’t seen any related bugs since. One last minute change was to hide the <canvas> element with the CSS opacity property until after it finishes blurring, then animate it in using the CSS transition property — this really tied it together and made the whole experience feel more elegant than if it flickered in and out until it was properly blurred.

The screenshot below is what it looks like right now, but you can check it out live at Proton Beta.

The Proton Beta with background blur applied.It took a lot of work, but in the end we couldn’t be happier with how great the page looks with the blur effect.

For readability’s sake here’s a Gist with all the relevant code from my Marionette/Backbone view (excludes the Apache CORS rules). Depending on your choice of framework/tools it’ll likely need to be adapted, but it should be a good starting point for most views written in javascript.

blurBackground Method

Show.RadioView = Marionette.LayoutView.extend({ blurBackground: function() { if(whichAndroid() > 4.4 || whichAndroid() === false) { const img = new Image(); const canvas = document.getElementById(‘dataCanvas’); const radius = 50;

  // Make it work with CORS
  img.crossOrigin = '';
  img.src = this.imageURL;

  // Wait till image loads
  img.onload = (e) => {
    // Setup image vars
    let img_w = img.naturalWidth;
    let img_h = img.naturalHeight;
    let img_ratio = img_w / img_h;

    let window_w = window.innerWidth;
    let window_h = window.innerHeight;

    let canvas_h = window_h;
    let canvas_w = (window_h/img_h * img_w);

    canvas.height = img_h;
    canvas.width = img_w;

    // I have a global Backbone “resize” event that I listen 
    // for in Marionette, but you can also listen manually here.
    // $(window).on('resize', () => resizeCanvas(img_ratio));

    StackBlur.image(img, canvas, radius, false);
    resizeCanvas(img_ratio)

    // Make the canvas visible once processing is done. I use a
    // CSS3 transition to have it fade in after the class is added.
    $(canvas).addClass('is-visible');
  }
}

}
});

// resizeCanvas()
//
// Resizes the background canvas element to maintain img proportions
// while centering and stretching canvas to fill fullscreen.

let resizeCanvas = function(img_ratio) {
let window_w = window.innerWidth;
let window_h = window.innerHeight;

let window_ratio = window_w / window_h;

let whichAndroid = function() {
var userAgent = navigator.userAgent.toLowerCase();
var check = userAgent.match(/android\\s([0-9.]*)/);
return check ? check[1] : false;
};

Notice something amiss or want to chat? Feel free to get in touch with me at rob@atomidesign.com!

I normally wouldn’t condone using User Agent sniffing in production, but in this case there’s no accurate way to detect support for this feature in a “progressive enhancement” manner, and the browser in question is old enough that its highly unlikely that the UserAgent will ever change. ↩ ↩²

Day 1 of Writing a Webapp: Getting My Hands Dirty with NodeJS, Express, and MongoDB

Tue, 18 Oct 2016 03:47:00 GMT

On any given day I probably have at least a dozen new ideas of what to build floating around in my head, but for one reason or another most come and go without much further thought. About a year ago now one of those ideas floated into my head, and ever since it hasn’t left.

Rather than letting this idea continue to nag at the back of my mind I’ve finally decided to do something about it, and will periodically blog about it along the way to help keep myself accountable and self-reflect along the way.

The Problem, The Solution

Without a doubt the biggest pain year-after-year as a self-employed individual is keeping my finances in order and paying my taxes upfront/on time. Almost every how-to or blog article about getting started on your own business repeatedly screams at you to stay on top of your finances, yet it seems to repeatedly be one of the most common problems for almost every recently self-employed individual I meet. There’s tons of financial software out there, but it’s almost always targeted at accountants or larger businesses (overkill for a contractor), or is meant for people who are employed full time by the same company. Instead, contractors/freelancers are left hodge-podging all their finance information together using various different software that provide subpar solutions¹. Ironically the best piece of software I’ve used for tracking my expenses has been Freshbooks, an amazing SAAS product whose primary purpose is instead for invoicing.

Enter Transact — my plan for a simple web and mobile app that helps me keep track of not only my income and expenses, but also details about each expense to create a clear paper trail. Right now I’m just trying to hit my head against a wall build a [mostly] functional webapp that consumes its own API, that can then be reused to connect to from a React Native powered iOS/Android application.

This might be naive, but I figure if I can build an app that I personally find useful and streamlined enough to use on a day-to-day basis, then there’s probably other self-employed people out there who will find value in it.

Stepping Off the Deep End

I’m a designer and frontend developer by practice, so delving into backend code is always a little awkward. On the other hand, writing a backend application from scratch feels completely insane.

Prior to leaving San Francisco I briefly started working on the same idea with my friend and backend developer extraordinaire Dev, who started hobbling together a proof-of-concept Rails API for our purposes.

Unfortunately, I don’t know Rails.

On more than one occasion I’ve tried to teach myself, but without the ability to dedicate a long period of time to learning the syntax, lingo, and other “gotchas” of the Rails ecosystem it would be an excruciatingly slow, painful march of progress, and at this point I just want to get something rolling.

The good news is I do know javascript, and have spent my fair share of time working within the confines of NodeJS/Express applications in the past (albeit mostly on the frontend). I’m sure there’s a hundred reasons why “Framework A is more suited to this than NodeJS” or how “NodeJS really sucks and is going to cause problems in a year”, but for now I just need to optimize for progress based on what I already know and am at least vaguely familiar with.

Screenshot of the code-in-progress…So far its been a constant “be confused for 2+ hours, solve one tiny problem” sort of day.

Progress So Far

I’m writing this as a brief break from coding, but as of this afternoon I’ve managed to scrape together a basic ExpressJS + MongoDB application with user authentication using the Node Passport package that has its own API that it self-consumes so adding other clients (iOS/Android) in the future will be a much smoother process. Currently I’m using Babel to enable using ES2015 (ES6) syntax and ESLint to help keep my code quality in check.

I’m admittedly a little wary of using MongoDB as heard some of the scaling horror stories, but for now it’s the fastest and easiest way to get things up and moving (famous last words?). So far its running without a hitch, though I’m still a little fuzzy on some of the core concepts, especially around how Mongoose abstracts interacting with Mongo and how you properly reference models from one another using Mongoose’s helpers.

For getting bank transaction data I’m testing out the Plaid API, which as far as I can tell is the only option out there short of writing your own custom bank integrations (no thanks). Thankfully, their documentation and API are in the best of their class and they include libraries for most major backend languages/frameworks.

Think you’ve got good docs?Here’s a snippet of Plaid’s Connect docs, which is the basic endpoint allowing you to pull in both general bank account information as well as detailed transaction data. They’re without a doubt some of the clearest, best docs I’ve ever seen.

Overall I have to say I’m really impressed with how the Node ecosystem has grown since I last looked at it, and how quickly I’ve been able to get a basic server application running. On the downside, it seems to be weirdly difficult to find good, complex Node/Express applications to use as a point of reference compared to other large communities (aka Rails, Backbone, React, etc). Over the next few days I hope to better learn how Mongoose (the Mongo ODM) works, be able to pull real bank data from my own Wells Fargo business accounts, and start calculating a rough estimated amount for how much tax I owe based a simple calculation of income minus expenses.

I tested out Intuit’s “Quickbooks Self Employed” but received an error when trying to connect my Wells Fargo Business Account. That aside, after connecting my person account it still seemed to be riddled with bugs and didn’t serve the purpose I’m looking to fill. That said, the fact that a company as large as Intuit is working a product targeting self-employed workers only helps prove how large of a market freelancers are becoming, especially with the proliferation of contractor-based companies like Uber. ↩

Why Designers Should Code

Mon, 22 Aug 2016 08:00:00 GMT

Over the past several years the topic of the designer who codes has generated quite the lot of controversy within the tech community. Some camps believe designers shouldn’t distract themselves with code and instead maintain their roots in graphic design as pixel-pushers, while others think that designers should be getting their hands dirty with code down in the trenches alongside their developer cohorts.

As I’ve written on the topic on more than one occasion¹ and non-coincidentally run a meetup group called Designers Who Code, it should come as no secret that I fall into the latter camp.

At the Outset

When I first started teaching myself web design back in university I didn’t have any mentors to consult or tell me what to do. While I had plenty of friends in the computer science program, I was surprised to discover that they were all learning old-school Java/C++, and knew almost nothing in the realm of modern web languages nor web application development ¹. I’d had some exposure to the world of table-based HTML layouts and <font> tags back in high school, so in my need to make extra money to pay for beer my rent, I figured I’d just learn by Googling the hell out of anything and everything.

This way of learning has its faults, but as I had nobody telling me what or what not to do, it just seemed like common sense that I’d code up my own designs too. At the time they were mostly simple static HTML/CSS layouts, so anything I didn’t already know I could quickly figure out (aka frantically Google and hit my head against the keyboard until 4am). It wasn’t until I moved to San Francisco in 2012 that I found out that designers coding wasn’t the norm, and what seemed like common sense to me was a foreign concept to most people I met.

This quote from Jeremy Bell from the blog of [the regretfully defunct] Teehan + Lax sums up what I encountered and how I felt pretty accurately¹:

…If I was to be a designer, I couldn’t be a developer. There was never an option to do both. Instead, I’d spend hours designing static pages in Photoshop that would simply be handed to the developers for reproduction in HTML. There was rarely an opportunity to collaborate throughout the process. Hell, we barely spoke. Sometimes we weren’t even in the same timezone, let alone the same room.

That was 16 years ago, and not much has changed.

As I’ve previously written about, at my first full-time web design job I encountered the same problem — I was hired as the UI/UX Designer in party because I could code and communicate with developers in a way they’d understand, but within the first few hours of my first day the CTO quickly asserted that, “Designers don’t touch code” (a huge sticking point that resulted in a relatively short-lived employment)¹. While the concept of designers being anything more than pixel-pushers still remains a foreign concept to many companies, it thankfully seem to have been gaining more and more traction over the past few years as job listings for UI/UX Designers now regularly include “HTML/CSS” as requirements or nice-to-haves, or are listed under the guise of a “UI Developer” position instead.

You might ask, “So what, why should designers code?”

The full answer is a long one, but in short a [good] designer isn’t someone who just makes things “pretty” or “functional”, but someone who strives to understand the problems at hand and develop the optimal solution to that problem, whatever set of skills that might require. This isn’t to say a designers should do everything, but a good designer should know where they or their colleagues can deliver more value more efficiently and coordinate their role appropriately. In this case, there’s numerous clear benefits to the designer building the frontend templates themselves.

Tightening the Feedback Loop

Nearly every web designer, myself included, has numerous stories of handing off mockups to a developer only to have the built version look nothing like the mockups that were provided. At the time it’s always easy to rant and criticize the developer, but what else would you expect when you’re handing off the responsibility of implementing the design to someone whose job is only tangentially related to design, and often doesn’t care about the design nearly as much as you do?

This is by no means meant to criticize developers, but instead quite the opposite as I suspect a very similar problem would arise if the situation were reversed and developers gave designers specs to implement a new a feature. It might “work” in the designer’s eyes, but any experienced developer would likely cringe during the code review. Instead, a developer’s job should be to build complex features and applications, not to fret over a few pixels here, a font weight there, and the crazy nuances of cross-browser CSS — that’s the designer’s job, and it makes infinitely more sense for the designer to be able to tweak those nuances directly rather than hunting down, bothering, and distracting a developer from their own responsibilities.

In reading a great Medium article by David Cole¹ I came across a rather strong quote from Jennifer Tidwell¹:

So there’s lots of good stuff to learn before you can create production-quality software systems. But here’s what I worry about: it takes years to learn it well, and this is what a lot of good software engineers do for 50+ hours per week, building knowledge and picking up new skills. Practice, practice, practice.

Hey, designer. Can you afford to invest those years?

Cole goes on to dispute Tidwell by arguing that tools built for designers will help alleviate that learning curve, which while true to a certain degree, I think it misses the larger point at hand.

Designers don’t need to practice 50 hours/week on development because the skills they need to cover design responsibilities aren’t nearly as broad as your typical developer. Designers don’t need to build a full javascript single page app (SPA) or an efficient Rails API to implement their designs effectively¹; instead, they need to be able to work with primarily HTML and CSS (or SASS/LESS/etc), to build code-based static templates of their designs that can then (if needed) be taken by a developer and integrated into a larger application.

A developer who isn’t trained in design nor practices it on a daily basis isn’t going to notice the minute pixel differences a designer does, and being able to directly and immediately make those changes yourself helps tighten the designer/developer feedback loop in a way that pawning off frontend development responsibilities will never be able to match. Instead of a 12+ step process of delayed designer-developer communication, it instead becomes something more akin to:

Wireframes + Mockups
Build HTML rapid prototypes to test design elements.
Build templates from mockups, making edits and adjustments as needed along the way.
Iterate.
Hand off templates to developer.

This not only makes for a much faster iteration cycle, but results in both a better end-product and frees up developers time so they can focus on building features rather than making small design tweaks. Additionally, any time you’re discussing changes to an existing site with your product manager or management, rather than going through the full gambit of producing an updated mockup and iterating with your developer, you can instead often fire up Chrome Developer Tools or Firebug and test out the edits in real time, discuss, and make a fast decision right then and there.

Briefly on the topic of CSS & Javascript

CSS itself as a “programming language” is incredibly easy to criticize given it’s problematic cross-browser history¹ and inconsistent syntax, but if someone has to deal with its insane idiosyncrasies across half a dozen browsers across dozens of devices with versions dating back at least several years, who better than the one person who really cares enough to fight their way through it all? And realistically, once you’ve used CSS long enough on a regular basis you start to quickly learn the quirks and ins and outs of the language, and how to use it in a way that’s effective and cross-browser friendly.

To add to the mockup-to-code problem, anyone who has worked both sides of design and front-end development knows that what works in Photoshop/Sketch/[InsertToolHere] almost never perfectly translates 1:1 to what various browsers do, and you always need to make adjustments along the way. The design’s not done until it’s shipped, and trying to freeze it after you deliver some mockups to your development team is only doing the job halfway, and any time you try to lock-in a project that requires creative thinking you’re going to achieve subpar results.

Regarding javascript, I personally love to learn new things and ended up diving head-first into its dark and magical ecosystem of libraries, frameworks, and package managers that install other package managers. I don’t think this level of javascript knowledge is necessary for the majority of designers, but a minimal level of javascript knowledge goes a long way in communicating some of the finer points of your design. Want to simulate a panel or modal animating into view in a way that requires toggling or modifying style properties? Rather than mocking it up in After Effects or Keynote, you can actually build that animation exactly how you want it the first time around, and not nitpick with a developer about how it’s off by 50ms or how it doesn’t feel “quite right”.

Final Thoughts

There’s much, much more to be written about on this topic, and I intend to do so over the coming weeks (and probably months). I’ve only begun to scratch the tip of the iceberg in my research efforts, and already I have well over a dozen articles from other designers and developers on the topic. As I continue to write more I might circle back and make adjustments/additions, so if you have something to say on the topic feel free reach out by Googlechat at robertnealan@gmail.com or email me at rob@atomidesign.com — I’d love to chat.

This is the first in a planned series of articles on the topic of being a designer who codes. As I publish additional articles in the series they will appear here accordingly. Cover photo is a screenshot of the Proton Radio Beta, a just publicly launched client work-in-progress.

I’m looking at you Internet Explorer 6 through 10… ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸

Working Remotely as a Digital Nomad While Traveling

Sun, 14 Aug 2016 09:40:00 GMT

On June 3rd, 2016 my girlfriend and I left San Francisco for New York City, kicking off the start of a 6 1/2 month journey that would take us around the world until we return to California just before the Christmas holiday.

While its all been extremely exciting, traveling for the better half of a year presented an interesting predicament as traveling tends to be expensive, and I’m regretfully not rich (yet). The good news is I already almost always work remotely and most places we’ve been traveling are significantly cheaper than living in San Francisco, so making the jump to being a digital nomad is relatively seamless. In fact, I did the math on our former San Francisco one bedroom apartment’s monthly rent, and it came out to an inane $77.71/day — more than we’ve generally spent on housing, food, and all living costs combined, especially now that we’re in Thailand.

That said, there’s still some considerations to be had and a lot of preparation to be made in advance with this kind of trip. This is definitely written from the point of view of a web contractor, but will hopefully be applicable to anyone looking to transition to being a digital nomad for.

Talk to clients as early as possible!

I wanted to believe work would be a 100% seamless transition where clients wouldn’t even know I’m on an island in the Gulf of Thailand, but in reality there’s going to be a few hiccups along the way. Unless you plan on staying in one place long-term, assume you’ll have at least a few days where you don’t have a working cell phone and/or internet fast enough to upload your work (or no internet at all). Chances are this will happen more frequently if you’re traveling in second and third-world countries, but even in highly developed places like Europe you’ll likely find yourself with a few days that are a wash.

While I do my best to avoid these situations whenever possible, you need clients who will be understanding when you do fall off the grid for 24-48 hours (power/internet here sometimes drops randomly for hours at a time!), and if anything be excited for the journey you’re about to take. In the event that an existing client (or employer) isn’t comfortable with that kind of possibility, you need to work with them to wind things down leading up to your departure, and if possible help them get your replacement up to speed sooner than later.

Be realistic about how much you can work and communicate when you can’t.

Working constantly while traveling is not like working at home — it’s way more chaotic, exhausting, and ultimately takes time away from enjoying all the exciting things happening around you. 30 hour work weeks may sound like living the dream compared to the 40+ hour work weeks most people experience at home, but when you’re hopping around the world on planes and trains there’s a good chance those 30 hours will feel a lot more like 60. Plan your work ahead as much as possible, and talk to your client about working extra hours leading up to and following periods where you know you won’t be able to put in your normal amount of work. Research where you’re going ahead of time, and if you know internet might be spotty be sure to let your client know ahead of time.

Be honest and don’t be afraid to turn down clients.

This is arguably good advice for even non-nomads, but it’s especially important when your traveling and time is limited. Be upfront and honest with both yourselves and your client(s)/potential client(s) about you can and can’t do, and strongly consider not just the number of hours you’ll be working, but also the responsibility you’ll owe to your client to do a quality job within the timeline you’re agreeing to. It’s always tough to say no when you’ve got dollar signs in your eyes, but unless you’re incredibly strapped for cash you should aim for a balance between work and enjoying the new culture around you.

Don’t compromise just because you’re traveling.

I have no idea what was in the water in July, but I personally had an onslaught of potential projects (at least 8!) thrown my way over a period of two weeks, and am forever thankful that I turned down all but one. Of the other ~7 that I turned down, at least 2 asked if I could relocate to their location earlier than the planned end of our trip, and one even asked what my discounted rate was as I was out of the country where cost of living is cheaper. (Spoiler Alert: I only offer “discounted” rates for long-term retainer-based contracts of 2+ months at 40+ hours/month or more as there’s an inherent benefit in not needing to constantly follow up on new project leads while managing a dozen different projects.).

There’s something to be said about full time salaries being adjusted based on cost of living, but as a contractor you’re selling your expertise, skill, and most importantly your time. If a client wants to hire a cheaper overseas contractor they are more than welcome to do so, but you shouldn’t make yourself that contractor.

The Internet is your friend (seriously).

There’s a huge wealth of resources out there to help you plan around your work needs — use them. My personal favorites have been a few travel staples like lonelyplanet.com and wikitravel.org, and a few lesser known ones like nomadlist.com and nomadforum.io. Also, if you’re going to Southeast Asia be sure to check out Facebook Groups — while we mostly use Facebook for connecting with friends in the United States, there seems to be a group in each city for literally everything, from meeting other expats to dating to renting an apartment.

Get used to working offline.

I might work as a web designer and developer, but not having internet can’t be an excuse for not getting any work done. In the weeks leading up to traveling try intentionally turning off your wifi for a half day at a time and figure out what you can and can’t do while offline. Work on gradually making sure anything you normally would need the internet for can be done offline, and if it can’t then give yourself a list of alternative tasks you can do in the meantime. Prior to leaving I gradually made sure all my web projects can run locally without an internet connection and training myself to use Dash for OSX to read docs rather than searching online. For one project it admittedly required a good few modifications to the backend server, but more than paid for itself when I was able to do a solid 8 hours of work while on the slow ferry from Athens to Milos in the Greek Isles.

If there’s any large uploads/downloads you’ll need to make be sure to do them either before you leave or while you’re in major cities where connections are fast and latency to US services are low — it’s easy to forget when living in the US or Europe, but uploading/downloading to a server on the other side of the world can take 100x as long even when you have a fast local connection.

Work Asynchronously

Taking 1AM calls is part of the deal you make when you choose to work remotely and travel the world, but it definitely shouldn’t be the norm. Make sure that whatever client’s you’re keeping or accepting are used to working in an asynchronous manner via either email, chat applications like Slack, or project management applications like Github, Asana, or Trello. My primary two clients have employees around the world across at least a dozen timezones, and using Slack for almost all our communication has made it barely any different than when I was living in San Francisco. The main thing you (and your client) need to keep in mind is that every sentence counts when you get to be on a 12+ hour time difference. If you forget to say something or you’re not clear in what you need, that could mean another 24 hour delay from your original message.

If you haven’t already, check out Remote by Jason Fried (founder of 37Signals/Basecamp). It’s admittedly at times a bit general, but overall it lays down a lot of common sense principals for both individuals and clients/employers that can help make working remotely successful.

Get a VPN (Virtual Private Network)

While using a VPN for security might be overkill in your situation, you’d be surprised how many websites don’t work properly when they detect you’re in another country. Paypal alone has already refused to let me access my account in both Greece and Thailand, and without a VPN to route my traffic through the US I wouldn’t have a way to get payments from one of my clients to my actual checking account. If you’re doing development work there’s also a good chance you’ll encounter public wifi that (for reasons unbeknownst to me) block port 22, making SSH worthless without a VPN.

If you need to sign up for one I can’t recommend Private Internet Access highly enough. Their setup isn’t the prettiest or fanciest, but their servers have so far been extremely reliable, as fast as one can expect when routing traffic halfway around the world and back, and they take their user’s privacy to an extreme by forcing you to use anonymous usernames, not maintaining logs of any user traffic, and allowing you to pay via (more) anonymous methods like Bitcoin. In at least one case over the past 6 months they’ve sent a newsletter letting all users know that they were retiring their Russian VPN locations due to concerns over new legislation that would potentially compromise their customer’s privacy.

If you’re starting a new business, give yourself at least 3 months to be revenue-positive.

Lastly, traveling can be the perfect time to start a digital or online business, but remember that it takes time (and often money) to build something profitable from scratch (it took me almost 6 months of contracting back in 2012 before my income stream was stable). If you can, do as much of the upfront legwork before you leave, and make sure you have enough savings to pay for everything for at least 3 months. In the highly possible event you aren’t making enough money by the time your savings starts to run dry, be sure to have a backup plan in place that either lets you jump ship for back home or pickup a local job that covers the bills.

Be Prepared for a “Worst Case [Technology] Scenario”

Within a few weeks of starting our trip, my girlfriend encountered my worst fear: with no prior signs of issues her barely one year old Macbook Pro wouldn’t power on. I tried every combination of system reset keys in the book, but as it wouldn’t even begin to power on it looked like it was a hardware issue. Unfortunately, we were at the time in Dublin, Ireland where there’s oddly no official Apple Store and any secondary repair shops had a 3-5 day turnaround time…not promising when we had a flight to London in two days. We looked at getting it fixed in London, but all their Apple Store appointments were booked a full two weeks out, and the next Apple Store we’d encounter with open appointments wasn’t for two weeks in Milano, Italy.

In the end we thankfully we got it fixed (damn faulty Mac logic boards), but as it was just barely outside it’s warranty window and under a US warranty (many companies, Apple included, don’t always honor warranties from different countries) it ended up being a few hundred dollar repair. There’s not a lot you can do to prepare for this one, but just remember that as reliable as your laptop is now, getting it repaired overseas might not be as simple as hopping down to the nearest Apple Store. If having a running laptop is crucial to your work, it’s worth having that emergency fund for that unexpected repair or replacement.

Final Thoughts

Working remotely as a digital nomad can be an extremely rewarding experience, just make sure you have everything in order before you hit the road and most of all: communicate, communicate, COMMUNICATE! Almost all problems that come from working remotely can be avoided if both parties are communicating clearly (and honestly) as early as possible.

Have you or are you working as a digital nomad and have something you think would be worth adding? Email me at rob at atomidesign.com and let’s chat!

When things don’t go according to plan.An important client meeting in progress from Piraeus Port in Athens via mobile Google Hangouts. Our ferry from Santorini to Athens ran 3 hours late due to rough seas and I had to start the call while deboarding with a thousand other people.

Setting Up SSL for Ghost on DigitalOcean with Lets Encrypt

Thu, 19 May 2016 21:51:59 GMT

After reading entirely too many articles and a lot of trial & error, I’ve written this guide on how to get HTTPS working on a DigitalOcean-powered, Nginx-backed Ghost blog using LetsEncrypt’s free SSL certificates. For years people have argued whether it’s worth setting up SSL on websites that have no inherent need for strong security (credit card processing, user logins, etc), but now that SSL certificates are free for anyone and Google is prioritizing HTTPS sites over non-HTTP sites there’s no excuse not to.

While DigitalOcean’s pre-made Ghost Droplet gets us pretty far, there’s still a few steps to get HTTPS and your custom domain running.

The Guide

All steps are written from the viewpoint of a Ghost blog that was setup on DigitalOcean using it’s one-click installer, but they’re likely applicable to most Nginx/Ghost setups in general. Regardless you should probably be familiar with using a terminal and SSH — if you aren’t I highly recommend brushing up via those links before you get started.

If you already have a Ghost blog setup then skip to step 2. If not, go ahead and create a new droplet on DigitalOcean using the Ghost “One-Click App” install (Ghost 1.2.11 on Ubuntu 16.04 as of this writing — we’ll update it to the latest Ghost version in a few steps!) with 512mb of memory¹ (the $5/month option). Feel free to choose whichever datacenter is closest to yourself (or your users), and add an SSH key so you can access your Droplet via your local terminal.
Once the droplet is finished building, access your droplet over SSH via the terminal of your choosing with ssh root@0.0.0.0, where 0.0.0.0 is the IP address of your droplet as listed in your account. If it prompts you to trust the RSA key type yes and press ENTER.
Once you’re inside your server (synonymous with “droplet”), run apt-get update && apt-get upgrade -y to bring all Linux dependencies up to date. If it prompts you to setup mail config or provides a warning about the /root/grub/menu.lst I recommend choosing the default “No Configuration” and “Keep local…” unless you have reason to do otherwise.
Switch to the “ghost-mgr” user DigitalOcean already setup by running su - ghost-mgr (su = switch user).
Install Node Version Manager (NVM) so we can easily update to a more recent version of Node by running curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.11/install.sh | bash. Activate the nvm bash alias by running source ~/.bashrc or exit’ing and switching back to the ghost-mgr user.
Install Node v8.9.3 and set it as the default by running nvm install 8.9.3 && nvm alias default node. You can check that the setup worked by running node -v, which should return v8.9.3.
Install the Ghost CLI with sudo npm i -g ghost-cli so we can easily upgrade to the latest version of Ghost (v1.23.0 as of current) now and upgrade easily in the future.
Run cd /var/www/ghost/ to switch into your project’s folder, and then ghost update to update to the latest version.
Next let’s install LetsEncrypt’s CertBot to get our SSL certificate — type exit to go back to the root user (or start a new SSH session as root) and install the CertBot package with…
sudo apt-get install software-properties-common
sudo add-apt-repository ppa:certbot/certbot
sudo apt-get update
sudo apt-get install python-certbot-nginx
Run sudo certbot --nginx and follow the prompts along. Make sure to add a real email as they’ll send you SSL renewal reminders, and select 2: Redirect when prompted so all visitors are forced to the HTTPS version of your site.
Run vim /var/www/ghost/config.production.json to edit the url attribute to reflect your site’s domain name (in my case url: "https://robertnealan.com",, exit, and then run ghost restart (make sure you’re in your project directory!).
Remove the default IP-based Nginx config by running cd /etc/nginx/sites-available && ls, and then removing the IP address file with rm 0.0.0.0. Next open the default config in vim and edit it to match the configuration file below, replacing all instances of robertnealan.com with your own respective domain name².
Run service nginx restart — if you get any errors run nginx -t and it should point you to any syntax errors you might have made in the /etc/nginx/sites-available/default conf file.
Test https://yourdomain.com to make sure that SSL is working properly…if it is then celebrate! 🎉
Lastly, you’ll want to set up a cronjob to automatically renew the certificate every 60 days or so, otherwise they’ll expire after 90 days. First run /usr/bin/certbot renew --dry-run to make sure it’ll work as expected. Next go ahead and run crontab -e in your server terminal, and you should see something similar to the image below. On the last line add 0 0 1 */2 * /usr/bin/certbot renew --nginx --quiet, which tells cron to rerun the certificate renewal for you on the first day of every other month. With this cron in place you can safely ignore the renewal emails from LetsEncrypt.

And that’s it! If you have any issues or find an error feel free to comment on the gist, tweet at me, or message me via the contact page.

Nginx Config

server { listen 80; listen [::]:80;

server_name robertnealan.com;
root /var/www/ghost/system/nginx-root;

location / {
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Host $http_host;
    proxy_pass http://127.0.0.1:2368;

}

location ~ /.well-known {
    allow all;
}

client_max_body_size 50m;

listen [::]:443 ssl ipv6only=on; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/robertnealan.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/robertnealan.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}

server {
if ($host = robertnealan.com) {
return 301 https://$host$request_uri;
} # managed by Certbot

listen 80 ;
listen [::]:80 ;
server_name robertnealan.com;
return 404; # managed by Certbot

}

Other Basic Ghost Setup Tasks

Redirecting From non-www to www Instead

I’ve personally always favored non-www addresses, if you prefer to have the www version then make sure to use www.yourdomain.com during the CertBot registration, and subsequently make sure the server_name directives in the Nginx default conf file have www.yourname.com rather than yourdomain.com.

Reference Links

CertBot Documentation: https://certbot.eff.org/lets-encrypt/ubuntuxenial-nginx
Ghost Production Setup: https://docs.ghost.org/docs/install#section-create-a-new-user
Ghost Mail Configuration: https://docs.ghost.org/docs/mail-config
Node Version Manager (NVM): https://github.com/creationix/nvm

Updates

August 11, 2016: Updated guide to add steps breaking apart enabling HTTP, verifying LetsEncrypt, and enabling HTTPS.
October 19, 2016: Updated the Nginx config to have the default root directory as /var/www/ghost instead of just /var/www.
January 24, 2017: Updated the Nginx config to fix a bug where www to non-www redirects wouldn’t occur properly on HTTPS URLs, and added instructions on how to redirect from non-www to www instead.
July 3, 2017: Removed lines 59-61 in the Nginx config Gist and code snippet, which previously manually routed the robots.txt and sitemap.xml, as Ghost now handles these automatically for the past several major versions. Huge thanks to both Tom Blackshire & Grant Whinney for both giving me the heads up!
May 23, 2018: Fully overhauled the post to use DigitalOcean’s newer Ghost Droplet, Ubuntu 16.04, the new Ghost CLI, and the latest version of LetsEncrypt’s CertBot.

If you’re worried about only having 512mb of memory feel free to upgrade, though this blog has handled upwards of 650 concurrent visitors without skipping a beat. ↩
If you’re interested in learning more about Nginx configuration you can read up on it on their official wiki, https://www.nginx.com/resources/wiki/start/. ↩

Turning Down the Noise

Tue, 23 Feb 2016 21:08:31 GMT

I still remember getting my first cell phone.

The year was 1999 and my mom passed down her beater of a silver Sprint flip phone. For the time it was high tech, featuring an exterior notification screen, polyphonic ringtones, and a few games that would later look “totally lame” next to Snake on my friend’s Nokia brick-phones. Despite the terror that is being a cell phone owned by an 11 year old kid, it lasted several years until I convinced my parents to upgrade me to a a new LG phone with a “totally cool” color screen (and countless software bugs).

Fast forward to 2008 where I found myself in need of a new phone having had my latest victim Razer flip phone split in half. In an effort to show mercy to my parents, I made the mature decision to get my own phone plan and a sexy, contract-subsidized iPhone 3G for only $200.

For the first few years having an iPhone was similar to having a dumbphone, just with a better screen, a browser that worked, and countless other bells and whistles that were more of a novelty than necessity. Unfortunately, somewhere along the way those novelties gave way to alerts, push notifications, and constant buzzing, beeping, and blooping that turned the my “smart” into a constant point of annoyance and stress as it begged for my attention.

It’s for this reason that I’ve been diving into the extremely extensive notification settings and turning off as many active notifications as possible (active being anything that makes my phone buzz, beep, or otherwise distract my attention when it’s not in front of my face). The only three apps for which I’ve left active notifications fully intact are “Phone”, “Messages”, and “Facetime”, or what I still consider to be the core functions a phone should provide (and even those are 100% silent at the flip the switch on the side of my iPhone).

Additionally, to help minimized distractions when I am on my phone I’ve also disabled the majority of passive notifications (badges, banner alerts, etc - anything that unobtrusively appears once you’re already on the phone), and only left them intact for the few work-critical apps like Mailbox, Slack, and Google Hangouts.

A few weeks in I now check my email once or twice a day, Facebook a few times per week, and otherwise only pull out my phone when I have true downtime rather than out of habit. Surprisingly, I’ve yet to miss anything work-related that couldn’t wait until later, and what started out as an experiment in being able to focus better on work has turned into a much better balance between myself and what should be a tool rather than a constant distraction. If you find yourself distracted or pestered by your phone I’d recommend giving it a try.

As someone who works as a designer and developer I get it — the more we use our phone the better for your company, but as a human being with limited time and attention I have to wonder if there’s a better way? All things aside, that old Sprint phone had one feature that makes it appealing compared to phones of today — the damn thing was silent 99% of the time.

2015 - Year in Review

Wed, 17 Feb 2016 21:01:00 GMT

It seemed like 2015 went by fast, but I’ve blinked twice and it’s already almost the end of January halfway through February (okay I’ve really been procrastinating on this post). For years I’ve read “years in review” by others in the tech community, but never did one of my own because it never seemed like my experience was worth sharing. While I’m still skeptical how much value others might get out of this, especially considering how informal it is, it’s at minimum helpful in collecting my own thoughts.

So to start, in general it was a great year — not necessarily just for business, but all around it felt great. That’s not necessarily a quantifiable metric, but that’s what it was.

Client Work

In 2013 and 2014 my consulting business had always afforded me the freedom to work my own schedule and forgo an employed job, but never quite amounted to what I could have made working a market rate job. In the early days there were even a few of those “oh god I have no work lined up and can’t pay rent ” occasions that I’ll never forgot, but somehow it always worked out.

Twenty Fifteen, on the other hand, seems to be the year that things have not only gotten extremely stable with an upward trend in income, but also in quality of clients, ongoing relationships with clients, and ease of finding work when needed (and turning it down when not).

By the Numbers

In 2015 I worked on a total of 17 different projects with 12 different clients — an insane amount compared to previous years and something I aim to curb moving forward (more on that below). Net income saw a 94.1% increase over the previous year, and gross income increased by 82.2%. While the prior is indicative of overall business health, the latter is effectively my take home pay as I don’t have a salaried job and all income after business expenses is personal income in the all-seeing eyes of the Internal Revenue Service.

For the visual learnings out there here’s a chart showing year-by-year income and revenue, as expressed in emoji (I was a full time student until 2012, so any income was minimal and likely to be spent on cheap beer).

Looking back, this was a much better year than 2014, which saw a net income increase of 52.8% and gross income increase of 11.2% over 2013. If you factor in the fact that I was employed full time from January through April of 2013, I likely actually saw a negligible increase in income compared to the previous year.

I unofficially had made a net income goal for 2015, which I exceeded by roughly 15%. My goal for 2016 is actually to maintain that same income level, but while working on client projects roughly 30% less. It’s always been my goal to design and build my own products (analog & digital), so I hope this extra time will be enough to start focusing more time on doing so compared to previous years.

What Went Wrong

That said, it wasn’t all good.

First, as mentioned before I worked on seventeen projects, which was way too many for one person to handle. For the most part everything worked out, but at times I was stressed to the point I wanted to punch a wall (I didn’t), which is exactly the opposite of why I got into contracting.

Second, I took on a client that gave me “a bad feeling”. That client also happened to coincide/cause that peak of stress partway through the year. As the project went on it became more and more demanding to the detriment of my other work, and worse yet it was a product I neither believed in nor thought should exist. In the end I talked to my friend on the project and we decided to let the client know we would be ending our contract after delivering the current project milestone in a few weeks.

It’s always hard to say no to someone trying to hand you a check, but being able to pays dividends in your personal well-being and being able to deliver the quality you already promised to your existing clients.

Designers Who Code

Designers Who Code has exceeded my wildest expectations. What started as a hunch that their might be other “designer-developers” out there has turned into a group of 2000 2200 members. We hosted 6 events from January through April with companies like Heroku, Zurb, and Carbon Five, and had a total of 784 RSVP’s between those 6 events.

All things considered I think we had some great events and were able to engage a considerable number of people despite being dormant the latter half of the year.

In good news I recently launched a new website for the group that was designed/built intermittently over the course of a few months on top of Jekyll. It’s pretty minimal and still has gaps, but will serve as a good foundation for a myriad of other features I hope to include as I aim to allow the group to exist independent of Meetup.com’s platform.

Additionally, I’m in talks with friends about becoming co-organizers (so things don’t necessarily go dark when I do), and it’s looking like we’ll be having our first events outside San Francisco this year.

Backpacking Trips

As someone who loves the outdoors and is generally active, it surprised me when I realized that I’d never been on a proper backpacking trip. Fast forward to April and I’m trekking down an Arizona desert canyon riverbed with my girlfriend, her brother, and his girlfriend for 40 miles over 3 days. I could write an entire post to the trip alone, but put simply it was nothing short of amazing. While I’m not sure I’d ever want to live in the desert permanently, it’s an environment I appreciate and respect far and above any other.

_About 15 miles into Paria Canyon in the “narrows”._

After the trip I couldn’t shake the feeling that I needed to go on a longer trip, so I naturally opted for the 212 mile John Muir Trail (40 miles to 212 miles…totally reasonable). I’ve written a post on my gear and preparing for the trip in general, but have yet to write anything detailed otherwise. I tried, but at the time any words I could put down seemed to pale in comparison to the awe and wonder two weeks in the Sierras instilled in myself.

_Looking back down from the top of Forrester Pass at 13,500’_

Looking to the Future

I’m currently working with a colleague of mine on an app aimed at helping make freelancers lives easier. It’s still pretty early to say much, but I’m sure I’ll have a followup post down the line.

And the big news for the year…my girlfriend and I will be traveling the world the second half of 2016! What started as an idea to be expats in Thailand has turned into a trip that includes the eastern US, a myriad of European countries, and an unplanned number of countries in Southeast Asia. As part of the trip I’m looking at writing a “digital nomad” series for those thinking about working and traveling at the same time.

Words of Wisdom for 2016:

“You have Cost, Quality, and Speed — Pick Two.”

Is Self Hosted Blogging Dead?

Thu, 21 Jan 2016 21:23:00 GMT

Or, the case against hosted blogging options.

More and more I find myself reading articles on blog networks, and by networks I mean Medium. There was a promising short lived moment where smaller, topic-oriented blog networks like Svbtle (amongst others) started appearing, but even those seem to have gone by the wayside and are increasingly being replaced by Medium.

It’s not that I have anything inherently against these sites; they are incredibly well designed and seem to be doing a fantastic job at fostering a community and discussion around the writing of people spanning the whole spectrum of society. What I do have a problem with is trusting all my writing to a third-party company, which may or may not decide to monetize my content, shutdown, or update their application in a way that makes it a moot platform for future writing.

Don’t get me wrong, from those the few people I’ve met who work at Medium and Svbtle they seem like honest, top-notch people, but when I read through their Terms of Service it’s hard not to be a little concerned.

Like this snippet from Svbtle:

“As a paid customer, you give Svbtle a perpetual world-wide license to use your company’s assets and logos, unless Svbtle agrees in writing otherwise. These assets and logos will be used purely for marketing and sales efforts, such as being displayed on the home page.”

So by posting to Svbtle once, they suddenly have a perpetual license to use my company’s logo in way’s I’m forever unable to control unless they agree not to in writing, presumably before I ever use their service? It’s not that I think they’re necessarily going to do anything I disagree with right now or in the near future, but times do change — companies transition or are sold to a new owner, and you hear horror stories about formerly reputable companies like Sourceforge, the formerly ubiquitous choice for version control hosting, hijacking GIMP’s unused Windows distribution account for their own profit.

Or what about this one:

“Svbtle reserves the right, at its sole discretion, to modify or replace any part of this Agreement. It is your responsibility to check this Agreement periodically for changes. Your continued use of or access to the Services following the posting of any changes to this Agreement constitutes acceptance of those changes.”

Not only can they update the Terms of Service at any point in time without notifying their users, but it’s the user’s responsibility to check it for changes? I’m not a lawyer, but it seems extremely questionable that they can’t commit to providing some sort of outreach before those changes take effect. This is the same type of shady practice that previously earned Facebook heaps of backlash from its users, and led to them adding a clause to their Terms of Service that they’ll transparently communicating future changes in advance of them going into effect.¹ I don’t know about you, but I highly doubt many people are checking the Terms of Service for changes every time they go to make a blog post.

Medium.com’s Terms of Service are thankfully written in as much honest, plain-speaking words as possible with upfront statements like, “Even if your eyes normally glaze over the word “Terms,” it’s a good idea to read this agreement carefully before you use Medium.” and “You own the rights to the content you post on Medium. We don’t claim ownership over any of it.”

Still though, you look further down and come across this piece:

“…we may change, terminate, or restrict access to any aspect of the service, at any time, without notice.”

As a web designer and developer, I get it — times inevitably change and you don’t want to find themselves in a lawsuit because someone’s favorite feature got removed, but still that risk doesn’t seem worth it. It’s hard enough to muster the time to put my thoughts into words, and the last thing I want is for all that effort to hinge on the decisions of a benign dictator.

Lastly, as great as the Medium community is currently, it’s still a walled garden. You write on Medium, read on Medium, discuss on Medium, and inevitably live or die based on the choices of the company behind Medium.

Long Live Self Hosted Blogs

For my own blog I personally self-host Ghost’s open-source platform. As it’s still pre-1.0¹ it requires a little bit of technical know-how to get setup, but with options like DigitalOcean’s pre-configured Ghost Droplet it’s getting easier and easier to manage. On the downside the only writing format it currently accepts is Markdown, which depending on your preferences will be a polarizing feature (I love it).

So maybe Ghost isn’t your jam, and that’s okay. That’s the beauty of self-hosting your own blog, there’s so many options out there! Things like Wordpress, Jekyll, Middleman, Octopress, AnchorCMS, PicoCMS, Dropplets, takes breath …and at least hundred others are free and available for you to use, customize, update (or not), etc at your own choosing. That’s the beauty of having control over your own writing — the Ghost community might opt to add or remove a feature I disagree with, at which point I have full control to not update to the newest version and plan a transition to a different platform that fits my needs.

Version v0.7.5 at the time of this writing. ↩ ↩²

12 Resolutions for 2016

Fri, 15 Jan 2016 23:09:20 GMT

I’ve always thought that if something in life is important enough you shouldn’t need a yearly resolution to make that change. Unfortunately life isn’t that simple, so after more than a decade of abstaining from resolutions I’ve decided to give it a go with an appropriate first item:

Regularly re-evaluate pre-conceived ideas and opinions.

Read daily.
Start each morning by meditating. (No idea how this will go, but I figure it can’t hurt.)
Write daily with the goal of writing a book this year.
Build at least one product/application for myself.
Build at least one product/application to sell to others.
Go jogging at least 3 times per week, bouldering at least once per week, and biking at least once per week.
Put a minimum of 20% of my 2016 pre-tax income towards savings/stocks/retirement/etc.
Purchase food locally as frequently as possible (farmers markets, coop boxes, etc).
Publish at least one article per month — can be on this blog or elsewhere.
Cook something new at least once per week.
Organize at least one meetup for Designers Who Code every other month (socials/happy hours don’t count).

Maybe I’ll fail, maybe I won’t. What I do know is that 3 1/2 years out of college it’s far too easy to become content and fall into the same rhythmic pattern day-after-day, only to look back and realize not much has happened in the past few years. This thankfully hasn’t been the case, but I’m adamant to make sure that it doesn’t happen.

Gearing Up for the John Muir Trail

Mon, 14 Sep 2015 18:36:56 GMT

To those who know me personally it’s no secret that I love a good adventure. Whether it’s traveling in a foreign country or biking across my own, testing your limits by pushing yourself outside your normal comfort zone positively expands your character in a way that no other type of experience can quite compare.

Having gone backpacking for the first time earlier this summer in Paria Canyon (despite having lived out of a tent for several months of the past decade), it only made sense to immediately plan the longest backpacking trip I could manage between projects before the onset of winter’s freezing temperatures, [hopefully] snow in the Sierra Nevadas, and the El Niño-pocalypse that meteorologists are predicting for this year. So with a few months summer to spare, I immediately booked a late-season permit for two on the John Muir Trail and tricked a good friend into take two weeks off work to join me in the adventure — it still amazes me how much of a draw “backpacking the John Muir Trail” has over “backpacking in the mountains for two weeks”.

With the help of numerous other blogs, the JMT facebook group, and a bit of my own intuition I’ve come up with what should stand to be a setup that combines the best of comfort and weight savings as well as some gear that should serve future trips for years to come. Additionally, I’ve included a link to both my original Google Spreadsheet both as filled out by myself and blank for anyone else to use (WIP).

The Gear

Spreadsheet Last Updated: Sep 14th, 2015 at 4:00PM PST
https://docs.google.com/spreadsheets/d/1MQQqY0z0noiJg7CUWhkjYgsABQoRF7-l2W3Ub9ROlEE/edit?usp=sharing

Packing

Osprey Exos 58 Backpack — I’ve been nothing but impressed by the weight and comfort of this pack. At 2lbs it’s lighter than almost any other pack in its class but still provides the comforts of an internal frame pack.
Sea to Summit Medium Dry Cover
BearVault BV500 Bear Can — Light as you could hope for, transparent, and doubles as a pretty sweet campfire chair.
1 Osprey Dry Sack
2 Odor Bags A few gallon sized Ziploc Bags

Shelter & Sleeping

Big Agnes Copper Spur UL1 Tent & Footprint — It was a tossup between this and the Fly Creek, but the CS won out despite the extra ounces primarily due to being freestanding and affording more space for my pack beneath the fly. As a huge bonus, having a side-door is way better than the Fly Creek’s front door in the rain, and gives you the option to sit inside your tent and hang out with your campmates when cold.
REI Flash Sleeping Bag — It’s half the cost of any other sleeping bag in its weight/warmth class and packs down small. Only has a 30-degree rating, but I sleep pretty warm and am willing to layer up above 10,000’.
Thermarest Z-Lite Foam Sleeping Pad — Not nearly has comfortable as inflatable sleeping pads, but much lighter and more reliable. Also double’s great as a seating pad outside the tent.

Survival & Tools

Black Diamond Ergo Cork Trekking Poles — Usually keep me from toppling over when I’m tired.
GSI Cathole Trowel — For when nature, gardening, or sand castle building calls.
Petzyl Tikka XP Headlamp — Runs on AAA batteries for far longer than I would’ve guessed and is blindingly bright on its highest setting.
Zippo Lighter & Small Box Matches

Clothing & Accessories

Arc’teryx Cerium LT Hoodie Down Jacket — Keeps me sweating even in freezing weather.
Arc’teryx Beta AR Hardshell Jacket — The California drought has kept me from putting this to the test, but as with all Arc’teryx gear I doubt I’ll need to worry.
REI Waterproof Hiking Pants
Prana Mojo Shorts (Worn) — These are my go-to climbing shorts but double as a pair of extremely comfortable hiking shorts.
REI Sahara Shirt (Worn)
Patagonia Capilene Middle Weight Long Sleeve Baselayer
Vasque Hiking Boots — I’ve had these for at least 6 years and they’re still rock solid. Never have gotten a single blister nor had a single complaint.
Patagonia Capilene Heavyweight Baselayer Underwear
2 pairs Patagonia boxer briefs (1 Pair Worn) — Should stay much cleaner, much longer than cotton underwear.
1 Pair Misc über thick alpaca wool socks
1 Pair REI quarter hiking socks (Worn)
Rayban Wayfarer Liteforce (Worn) — Just my polarized sunglasses of choice.

Cooking & Hydration

Jetboil Flash — I’ve had this for going on 4 years and bring it anytime I’m camping (even if we have a full stove).
Snow Peak Titanium Spork — Because.
Camelbak 2L Water Bladder
Nalgene Water Bottle — If you don’t need/want something as sturdy as a Nalgene Smart Water bottles work great and weigh next to nothing.
Katydyn Hiker Pro Water Filter — Quick and has a carbon filter that helps improve the taste when filtering impure water.
Sawyer Squeeze w/Smart Water Bottles — The Katydyn unfortunately broke while on the trail, and after seeing/using several Sawyer Squeeze’s will be switching as soon as I make it to REI.

Food

Big Sur Bars — A college meal staple from the Central Coast of California. Buy them, you won’t regret it (original & white zest recommended).
Pro Meal Bars
Justin’s Single Serve Peanut/Hazelnut/Almond Butter — Ordered in bulk on Amazon.
Peanut M&M’s
Beef Jerky
Mountain House Meals — Ordered in bulk online and repacked into ziplock bags to save space.

Hygiene

Toilet Paper
Toothbrush
Toothpaste
REI Lite Mini Multi Towel — Amusingly tiny but nonetheless handy in cleaning dishes and/or washing off.
Dr Bronners Peppermint Soap (4oz) — Realized I had no real use until I got off the trail and left it in the car.

Miscellaneous

Banana Boat SPF50 Sunscreen (4oz) — Because Irish/Italian/English people were not meant to get tan.
Tom Harris JMT Maps — Great maps for great adventures.
Wallet (Rubber Band, ID, Credit Card, Debit Card)
Ben’s 30% Insect Repellent — Likely unnecessary in September, but critical for Sierra hiking earlier in May/June/July.
Duct Tape — Rewrap some off the roll onto your trekking poles below the handles to save space in your pack.
iPhone 6 — Will be off 99% of the time, but useful when we get out of the mountains.
Misc medical kit (bandages, medicine, etc)

Death by Inertial Scrolling

Mon, 16 Feb 2015 22:21:20 GMT

Every year there’s a few design trends on the web that make their rounds. Some are recognized as good design patterns and persist while others gradually fade out. Thankfully most of these trends are tacky and cringeworthy at worst (web 2.0 rounded glossy buttons anybody?), but every so often there’s one that’s just so downright awful, so downright evil, that when I cross paths with it I can inevitably be witnessed at public cafes twitching and muttering swear words under my breath.

Currently that cardinal sin of a trend I continue to encounter is the introduction of javascript controlled accelerated scrolling on non-touch devices.

If you’re not sure what I’m talking about then hop over to writefullapp.com and try scrolling with either your laptop’s touchpad or a mouse scroll wheel. You should notice that it’s going a bit faster than normal and has a bit of a slingshot effect. This is what I’m referring to with accelerated scrolling. Rather than letting the browser treat scrolling like it does on 99.99% of other websites, a javascript library hijacks the scrolling action to create a supposedly more natural scroll that has inertial momentum.

So why is this bad?

Because good design should make a user’s experience as fluid and effortless as possible. We’re trained to expect certain differences in website’s designs, but at the core of our browsing experience we assume that the way we interact with them will be done in the same manner. When a new feature alters a basic interaction in an unexpected and inconsistent way, it requires heavy concentration from the end user that almost inevitably causes confusion and frustration.

This isn’t to say that inertial scrolling is a bad idea in and of itself — Windows could take a cue from OSX on that point — but it’s only good when it’s done in a way that both feels natural and is implemented system (or potentially application) wide.

I’m all for new features that enhance our experience on the web, even when it’s ahead of the curve regarding browser support, but this new trend is definitely not one of them.

Tools for Designing in the Browser

Thu, 12 Jun 2014 22:10:04 GMT

This post is intended to be a regularly updated list of tools, articles, and other goodies that help make designing in the browser both easier and more efficient. If you’re currently a designer-developer hopefully you might learn something new of use, while if you’re new to the game hopefully this will get you started off in the right direction. Tools that I currently use are marked with an (*), while others I have used in the past.

Have something you use that think should be here? Email me with a link at rob at atomidesign.com, and I’ll be sure to check it out.

Last updated: June 12, 2014

Articles

5 Good Reasons Why Designers Should Code by Team Treehouse
Designing With Code by Jeremy Bell @ Teehan + Lax
Designers Will Code by David Cole @ Quora
The Great Value of the Designer Who Codes by Garry Tan

Browser Inspectors

CSS Preprocessors

Version Control

Git *
Subversion

Full Frontend Frameworks

Grid Systems

Templating Languages

Handlebars *
Mustache
HAML - Haml is mostly used in Ruby on Rails projects, but serves as a good example for an indentation-based language.

Development Tools

Static Site Generators

Organized Development Approaches

Craft Your First Impression

Mon, 09 Jun 2014 18:31:57 GMT

A few weeks ago I received a cold email from a local San Francisco startup called Mighty Spring asking me to demo their product. If you work in tech and have an internet presence you get used to receiving these things all the time (and generally saving them to the metaphorical circular filing cabinet¹, but the simplicity and attention to details in this particular case left such a great first impression that I felt it’s worth sharing.

Right off the bat they address me by name. This might seem like an obvious detail (especially given how easy it is to use mailing list merge tags), but you’d be surprised how emails I receive that even bother to do this much. Even better, he immediately tells me how he happened upon my contact info:

“I just found your profile on Github…”

He’s no longer a stranger who found my email through some shady email list purchase but instead a compadre who at the very least knows the existence of Github – a major nexus of the developer community and something that I maintain a profile for the purpose of people finding my work¹. The second half, “…and am hoping to get your feedback on my startup, Mighty Spring,” doesn’t yet try to sell me on why this startup is going to change my life, but instead appeals to my emotion and asks for my help.

*slow clap*

With only 21 words they’ve already addressed me by my name, told me how they found me, and asked for my help; and, in the next 33 words they manage to tell me what the startup is, how it’s going to benefit my life, and oh yeah, by the way – it’s free. If this is a product that has any appeal to a potential customer (most people who work full time positions), at this point I have to imagine their only question would be, “Why wouldn’t I sign up?”

A Little Magic

Lastly, this isn’t just a normal invite, this is a beta invite. That in itself unfortunately isn’t that meaningful since the early days of Gmail save in special circumstances¹, but again when I clicked the link I didn’t just land up on a signup page, but instead landed on a page that already knew who I am.

At first I was confused, but then I realized they used the same trick I used to rickroll all my friends back in the day. While the link appears to be https://www.mightspring.com/lumen/, in reality that’s the text of the anchor tag and the real URL is: https://www.mightyspring.com/lumen/?email=robertnealan@gmail.com. This is the oldest trick in the book, but really can add a hint of magic to the experience for those who either don’t code for a living or just aren’t paying that close of attention. It’s the little details that make a big first impression.

All in all, the email took me about 7 seconds to read at a leisurely pace, and I’m already sold on trying it out. While I personally don’t have much use for a passive recruiting given that I’m happily self-employedd at Atomi Design, I’ll still be giving it a go to see how well they follow through on their promises and whether it’s worth recommending to friends.

Remember – you only have one chance to make a first impression, and with this style of email outreach you have the advantage of being able control the situation. Take your time to craft your message and test it out before going public. Think it’s good? Wait a day and read it again. Good now? Pitch it to the next person who gets on the elevator and see how they respond. Lastly, be concise. Time is money, and most of us have a severe shortage of time these days. If you send a lengthy essay about your startup chances are most people aren’t going to read it.

Thanks owed to Clement Poisson for proofreading.

I’m looking at you Dribbble… ↩ ↩² ↩³

Life is (Finding) Meaning

Sun, 04 May 2014 16:27:05 GMT

I’ve only now just finished listening to Derek Siver’s latest conference talk “The Meaning of Life”, and can only encourage everyone else to watch (or listen to) it as soon as possible.

As someone whose life work exists on a series of computer hard drives it hits pretty close to home. I regularly question what I’d do if a massive solar flare hit Earth and wiped out every electronic known to man. I mean sure, my skills as a designer/developer are pretty damn valuable right now, but when everything’s reset back to the 1850’s would that skillset really matter? Should I be developing practical skills like hunting and fire building instead? It’s enough to give anyone an mid-life crisis.

Either way, my main point in writing is that while I loved hearing Sivers so casually questioning the meaning of life with his children’s storybook reading voice (seriously), I unfortunately was disappointed by his ending. After working through the questions of “Life is Time”, “Life is Memory”, and “Life is Learning”, he concludes that we all inevitably assign our own meaning to these different questions; and therefore apparently life is (just) life.

While I don’t necessarily disagree with this statement, I think there’s a better answer than the one he gave - one hidden right in plain site throughout his entire presentation:

Life is (Finding) Meaning

To some this might seem like a disappointing cop-out to a question for which we all want a singular clear answer, but I see it as a beautiful symbol of the unique quality of being human. While other species seem to exist purely to reproduce, we instead explore, invent, and question why we exist, and in doing so (hopefully) eventually find our own reason to persist. Whether that’s a religion, your spouse, or rock climbing in a remote mountain range hours from any sort of civilization, the meaning of life for yourself is whatever you find it to be.

Web Designers Code

Tue, 11 Mar 2014 00:14:14 GMT

When I moved to San Francisco in 2012 I knew I wanted to get a job as a designer at a startup, but had never before dealt with the issue of needing to categorize myself into a certain role. In architecture there might be different types of designers (architect, landscape, etc), but they all overlap into a mesh of interdisciplinary collaboration that requires each person to be knowledgeable in the other person’s fields, regardless of their day-to-day responsibilities.

Despite the oddity of having these arbitrary categories (especially at small startups), I applied to a few jobs as UI/UX designer and surprisingly got interviews within a week at all but one company (who interviewed me ~9 months later), got a lot of questions about whether or not I could do X or Y type of design, and landed a full time position at couple year old startup. At the time I didn’t know why I was having such a great response rate, but looking back I realized it was due to one thing:

I was a designer who could accurately code my designs.

As a self taught designer/developer who never had anybody telling me what to learn or not to learn, this only seemed like common sense. If I’m passionate about my designs then why would I hand them off to someone who’s passion is in programming, not the tedious time-sink of HTML/CSS?

Unfortunately the CTO at the time didn’t share this passion and I watched as designs were hackily assembled by a group of “full stack” developers, most of which who neither enjoyed nor cared about frontend presentation development, all with a hodge-podge of Bootstrap CSS and an over-abundance of bloated legacy CSS. While I pushed for media queries to be used to create a unified UI/UX across all devices, they were instead used to create an entirely different “mobile experience” and as an excuse to to throw “mobile app” and “responsive” onto the long list of marketing buzzwords.

Let’s be honest, HTML/CSS is rarely fun and coding out your own designs probably isn’t that exciting to you, but as a designer you’re likely the one who most cares your designs being built accurately in their final medium, and as such you need to be able to take control of their execution. In some cases this means translating designs from PSD to HTML yourself or as is the case more and more often at Atomi Design - designing directly in the browser¹.

Regardless of how you setup your own workflow, the important thing is being able to take control of your designs from conceptualization through implementation. Even if aren’t coding frontend designs yourself, you need to have that knowledge as it helps inform the way you work and enables to start that discussion with the person who is coding it.

TL;DR: If you call yourself web designer and you aren’t coding your designs, you better start.

Shameless Plug:
I’ve started a Meetup community called Designers Who Code that focuses on the intersection of design and development. We’re having a Designer Drinkup on Wednesday, March 12th at Bloodhound in SoMa, and will be announcing upcoming workshops at our office in SoMa soon. If you’re in the San Francisco area and enjoy good beer and good company be sure to come check it out!

This is likely a topic for a larger discussion, but after having just finished our first project sans-Photoshop we’d like to think it still has a place in our workflow as a place for “digital sketches”. Full page PSD mockups are out, but working in different analog and digital mediums always helps shake up the old design thinking. ↩

The Most Important Part

Mon, 16 Dec 2013 18:25:44 GMT

While doing some research on OOCSS vs OOSCSS I stumbled across one by Chris Hansen at Pivotal Labs titled Why we don’t use OOCSS (but we should). I have my own hesitations and thoughts regarding pure OOCSS, but was dumbstruck by one of his reasons for not using it:

HTML and CSS are just not as important as the server code or javascript for a web developer.

The Part Your Customers See Isn’t As Important?

Let’s be honest, building out HTML/CSS templates can be pretty mundane at times, so to all the developers who grumble when they have to tediously build out a pixel perfect frontend - I understand. It’s actually one of the many reasons I believe all designers should learn to code their designs themselves.

Unfortunately, it seems like this attitude extends beyond minor discontent and instead is an industry-wide attitude that the frontend is less important the innerworkings of your application, when I’d argue the exact opposite.

Yes, the backend is still extremely important, but most of your customers likely neither understand nor care how it actually works, so long as it does what it says it does. Unless your product is something targeted at the development community or some holy-grail with no competitor (Hint: It probably isn’t), chances are your customers are both consciously and subconsciously forming opinions about your product based on how it looks. When one of your customers inevitably runs into a bug (I promise they will), if it looks polished there’s a much better chance they’ll be forgiving and report the issue to you instead of switching to a competitor’s product. Better yet, if you respond promptly and work to help them through the issue and/or patch the bug there’s a good chance you can turn a negative situation into a positive memory of great service for your customer.

On the other hand, when one of your customers runs into a bug and your application looks like a POS, they’re going to assume that’s because it is a POS.

Feel free to voice your thoughts over on HackerNews

MVP, not MVPOS

Mon, 18 Nov 2013 16:48:41 GMT

If you live and work in the tech world, then “lean” or “agile” just might have been your first words.

Every meetup, conference, and startup in a 50 mile radius is talking about what it means to be a lean startup, and I have to say it’s been a great improvement over old-fashioned waterfall workflows. Unfortunately, another phrase that goes hand-in-hand with the lean/agile movement is the ever-present concept of the “MVP”, otherwise known as the Minimum Viable Product.

In theory it’s a great idea - inputting the minimum amount of time necessary to validate a product/feature - but like many great ideas it seems to be frequently bastardized in practice and reinterpreted as what I like to call MVPOS, or Minimum Viable Piece of Shit.

Yes, I understand you want to move quickly; and yes, I do think you should be doing the minimum amount necessary to validate your idea. However, that is no excuse for it to look and function terribly (or not function at all). Save time on things that don’t scale [1] long-term but can be manually processed for the purposes of testing, but don’t cut corners on the things that directly affect the end-users’ perceivable quality of your product.

Short of some weekend hackathon you did with your buddies or an internal tool your company uses that took off unexpectedly, every feature of any product you intend to sell or monetize should strive to be as polished as reasonably possible and function just as your end-user expects it should. Don’t be one of those startups that delivers broken features with the excuse, “It’s just the MVP., we’ll fix it later.”

Man up, admit it isn’t good enough, and fix it now.

Otherwise, you’re missing the entire point of the MVP in the first place - to iterate quickly on small features based on customer feedback and measurable data. If it doesn’t work right in the first place, the only feedback you’ll get is likely what you already know.

Share your thoughts on Hacker News

1. If you havn’t read Paul Graham’s Do Things That Don’t Scale, do yourself a favor and check it out.

Be Honest

Fri, 15 Nov 2013 20:28:13 GMT

My friend Nathan will tell you I just hate people (jokingly, I think), but when it comes to business you can’t beat around the bush. Is someone’s work not up to par? Tell them they need to step things up. Is the client not holding up their end of the work? Sit them down and (politely) talk about what they and you can do to communicate or work together better.

Sometimes it’s going to be awkward and sometimes it’s going to take some time to fix. And yes, one day you’ll probably inadvertently burn a bridge or two, but more often than not it saves a lot of pain and headache that’ll come from avoiding the reality of the situation until it’s too late.

Pipe in on Hacker News

Stop Freelancing

Wed, 13 Nov 2013 18:42:32 GMT

I’ve been “freelancing” part time for the better part of the past 4 years and full time for the past 8 months, and if there’s one thing I’ve learned it’s that telling people you freelance will garner responses that manage to combine a jealousy of your freedom and a subtle tone that silently says,

“A freelancer? That’s cute.”

So what did I do? I stopped freelancing and started my own company. I came up with a business name[1], filed for a business license, and as of recent finally even got myself a desk with a fancy “Suite” address in a coworking building.

While the transition to me seamlessly occured over the course of several months, to the clients I pitched and worked with it was a sudden and jarring difference. Potential leads increased in quantity (and quality), a higher ratio of those leads converted to clients, and the level of control I had over the actual working relationship with clients improved exponentially. Behind the scenes barely anything has truly changed, but by presenting myself as a company it gave a much more professional image than that of some kid “webmaster” working from his parent’s basement[2].

Remember, you’re not a no-strings-attached temporary employee, you’re an expert in your field whom clients come to because they want the best product possible and can trust to guide them in the best direction possible.

I’m not saying there aren’t plenty of talented, extremely professional freelancers out there (there are tons), but my experience has been that being a “freelancer” sets the unfortunate tone that you need your client, whereas in reality they are the one who needs you to help tell them how to make their business successful.

Talk about it over on Hacker News

1. Some people might want to continue to use their personal name, which is fine. Just be sure to position it as a company, not you. The difference between “Designer John Smith” and “John Smith Design Studio” can’t be underestimated when viewed by a prospective client.
2. No, I don’t work from my parent’s basement.

WordPress is Great, WordPress is Terrible

Fri, 01 Nov 2013 21:54:17 GMT

The blogging community has been flourishing for years with Wordpress at the lead, but to anyone involved it’s obvious that there’s room for improvement.

The Community

First off, let’s just get out front that it now powers an estimated sixty million, or eighteen percent of websites, on the internet.

Holy shit.

Now while I won’t argue that something is great because it’s popular (I’m looking at you preppy high school kids), it still doesn’t mean that its widespread use is any less impressive. A quick look at the source of the top 30 articles on HackerNews at the time of writing this shows that at least 9 are powered by Wordpress. First impressions suggest that Wordpress is probably more pervasive in our cat-meme browsing lives than any other platform out there.

As every platform with more than ten users has started holding a conference if only for publicity’s sake (really Box/Dropbox/Trello/etc?), Wordpress has impressively held over 200 of their own Wordcamp’s worldwide since 2006. What’s impressive isn’t that Wordpress itself organized 200+ events (I’d label that as insanity), but that almost all of these events were organized by the community itself.

So what’s the problem?

John O’Nolan, one of the designers of the Wordpress UI stated,

What started out as a humble blogging platform targeted at enabling digital publishing for the masses, has evolved into a fully-fledged website CMS.

The problem is that Wordpress has long since deviated from being the pure blogging platform it started as, and in doing so has introduced a lot of confusion into it’s product direction. After years of its users hacking it to be more CMS-like it finally embraced this ideal, but years after its acceptance it still remains only CMS-like. Rather than growing into the open source CMS power house it should have been, it’s instead stuck in an awkward adolescent stage where anything is possible but never quite feels right. I can’t recall the last time I had to tell a client, “Wordpress can’t do that,” but sadly I find myself walking away unproud of the code I’ve left behind.

Like a public school multi-purpose room, it can do anything, but is great for nothing in particular.

Content is King

There’s too much stuff everywhere, too much clutter, too many (so many) options getting in the way of what I really want to do: publish content.

This is one of the opening lines that leads O’Nolan to introduce his new “pure blog” platform, Ghost. While I so far love Ghost (I’m placing my bet on it with this blog), I think he missed the point that “publish[ing] content” should be the focus of every site, not just simple blogs.

While the dashboard has visually stood the test of time with some grace, it doesn’t help the fact that it continues to have a steep learning curve for the casual user. Looking at the dashboard for a recent client site, I can quickly count at least 23 sidebar/header links without even getting into dropdown menus or the dashboard homepage content.

Why is my theme name, number of widgets, Wordpress version, and spam comments given a first-class location as soon as I log into the dashboard?

For my client’s sake I’ve thankfully created a custom user role that gives them access to only the things necessary for most employees, but again it’s another fix to an issue that shouldn’t exist. Why are Appearance, Plugins, Users, Tools, and Settings all separate top-level items? At the end of the day these are all “Settings” that aren’t relevant to the normal content management process and should be organized as such.

Security

With great power comes great responsibility, and Wordpress is no exception. With 60 million websites and an aging codebase susceptible to common attacks, it’s not uncommong ot hear about hacked Wordpress sites. I myself have had several occasions where old clients call asking why their description on Google is a bunch of gibberish about credit cards, only to find that a hidden block of text had been injected into their page from some foreign base64 encoded line within their theme or the core files.

The introduction of poorly written plugins brings even more risk of common attacks like an SQL injection. If anything, Wordpress should probably take the route of auto-escaping any inputs unless explicitly disabled on a case-by-case basis.

“The Loop…oh god, the loop”

A decade ago PHP was one of the most promising languages out there, but now it’s largely the subject of regular ridicule. While its been making great strides at modernizing itself since v5.3 (now on v5.5), it still has a long way to go compared to its younger, more nimble (and less stable) competitors. Given that PHP is making such big steps to modernize you’d think Wordpress would be right there with it, but instead we get a cop out on their inconsistent “Requirements” page:

We’re very aware that the latest versions of PHP and MySQL aren’t right for everyone, and that sometimes hosts can be slow or hesitant to upgrade their customers since upgrades to PHP and MySQL historically have broken applications.

Being conscious of not breaking your user’s websites is admirable, but when you’re supporting a version of an actively developed language that’s now 6 years old, it starts to raise some concerns.

A large portion of the PHP community (and development world as a whole) accepted the benefits of separating logic from the view with languages like Twig/Handlebars/etc, yet we still have a muddled method of writing templates using Wordpress’ own PHP-based template tags. While I’m not much interested in arguing whether or not PHP is a templating language in its own right, with inconsistent Wordpress functions all mixed inside the god-forsaken the_loop() it becomes one big hack of if/while/else statements and “Wordpress PHP” that becomes near-impossible to consistently maintain long-term.

A Proposal for the Future

Modularize the core. Don’t need a feature? Then don’t include it. Take some cues from the likes of node.js’ require and Rails 4’s separation of core features into modular gems. No need for a blog? Then stop including post-style functionality and instead just include pages with base templates that can be manipulated based on flexible sets of rules. Don’t need commenting? No problem.

Integrate the community. No, really integrate them. Wordpress has one of the most active communities out there and they’re actively building the great plugin ecosystem that makes Wordpress so successful. Take a serious look at the “indispensable plugins” - the ones that are used on almost every website - and integrate them into the Wordpress core as optional modules. There’s no reason we should be installing the same breakable third-party plugins on every Wordpress site we build…I’m looking at you Gravity Forms and Advanced Custom Fields.

Don’t get me wrong, Wordpress is still a great platform to build for small client sites for many reasons not listed here, but if it wants to continue to remain as relevant as it has been it needs to start looking toward the future.

Share your thoughts on HackerNews

Doing It Live

Thu, 31 Oct 2013 17:14:59 GMT

After months of my phone asking, “Are you going to write 1000 words tonight?”, I sadly only have half a dozen partial posts. I kept myself convinced that building a backlog of potential posts was the right choice so I’d still have something to post when I get busy, but ultimately that’s just an excuse to be lazy. Instead, I’m going to stop talking about it with myself and do it live. It’s tough to stay motivated, and it’s terrifying to put yourself out there, but as they say, “no risk, no gain” (that is a saying, right?).

I don’t want to make a grand statement about how this is a “relaunch” of my blog, because it isn’t - it’s just a continuation minus the old content because it’s no longer relevant to what I hope to express. Some of the old stuff will inevitably find itself regurgitated in one way or another, but sometimes starting with a clean slate is the only way to start again at all.

I’ve written blogs before - it shouldn’t be that difficult, right?

…right?

Robert Nealan

Using the WordPress REST API with React.js

Adding Endpoints for Custom Post Types

Adding Custom Metadata to API Responses

The Native Wordpress Way

Using Advanced Custom Fields (ACF) for Custom Metadata

Adding the Featured Thumbnail to Single Post Responses

Footnotes

An Adventure in Blurring a Cross-Origin Image Client Side Using the HTML5 Canvas

The Project and the Problem

Considering the Options

Process Images Server-Side

CSS3 Filters

Image Processing With Javascript

Getting Knee Deep in Canvas Land

Canvas Elements Are Dumb by Design

Canvas Elements Require CORS Headers

Android 4.4 and Below Don’t Support Image CORS Rules

Chaining it All Together

blurBackground Method

Footnotes

Day 1 of Writing a Webapp: Getting My Hands Dirty with NodeJS, Express, and MongoDB

The Problem, The Solution

Stepping Off the Deep End

Progress So Far

Footnotes

Why Designers Should Code

At the Outset

Tightening the Feedback Loop

Briefly on the topic of CSS & Javascript

Final Thoughts

Footnotes

Working Remotely as a Digital Nomad While Traveling

Talk to clients as early as possible!

Be realistic about how much you can work and communicate when you can’t.

Be honest and don’t be afraid to turn down clients.

Don’t compromise just because you’re traveling.

The Internet is your friend (seriously).

Get used to working offline.

Work Asynchronously

Get a VPN (Virtual Private Network)

If you’re starting a new business, give yourself at least 3 months to be revenue-positive.

Be Prepared for a “Worst Case [Technology] Scenario”

Final Thoughts

Setting Up SSL for Ghost on DigitalOcean with Lets Encrypt

The Guide

Nginx Config

Other Basic Ghost Setup Tasks

Redirecting From non-www to www Instead

Reference Links

Updates

Footnotes

Turning Down the Noise

2015 - Year in Review

Client Work

By the Numbers

What Went Wrong

Designers Who Code

Backpacking Trips

Looking to the Future

Is Self Hosted Blogging Dead?

Or, the case against hosted blogging options.

Long Live Self Hosted Blogs

Footnotes

12 Resolutions for 2016

Gearing Up for the John Muir Trail

The Gear

Packing

Shelter & Sleeping

Survival & Tools

Clothing & Accessories

Cooking & Hydration

Food

Hygiene

Miscellaneous

Death by Inertial Scrolling

Tools for Designing in the Browser

Articles

Browser Inspectors

CSS Preprocessors