When I launched this design in 2018 I remember thinking this would be my last site. I wasn’t under any illusion that I wouldn’t update this site again in the future. Only that I had a solid foundation that I could build on for a long time. Even if the changes where major, they’d still be iterations of existing content and aesthetics.

I have two main motivations for this year’s realign. First, I want to present my work from the last few years in a more complete way. The 2018 verison of this site listed projects, but didn’t go into much detail. There’s a lot there I want to surface. I’m looking for my next role so I need to present my work in a way that show’s what I'm capable of.

Second, I just want it to look cooler and weirder. Heavy emphasis on weird. With every iteration of this site since I launched it in 2006 I’ve made concerted efforts to make it look much different than the standard web designer portfolio/blog website. I don’t have anything against other folks’ sites, I just want mine to look different and strange.

Writing about it

Plenty of other designers are iterating on their personal sites and writing about their process. I enjoy reading those. So, I’m going to follow their lead and write about my process.

I’ve already started the process in a rough way. For the last few weeks I’ve let myself noodle on different areas of the design. I spent a lot of hours pushing points around in Illustrator for an updated logo and some fun typography squigglevision. I spent, I don’t know how long just fiddling with CSS in browser. I wanted time to play a while before I set out to really get updated content and design together.

With the initial play I have a rough idea of what I’ll write about. I’ll update this post as I go to keep a reference. Some of the topics will change and I’ll add more as I go, but below is a rough outline.

Realign 2020 Posts

• Realign 2020: Logo
• Realign 2020: Type
• Realign 2020: Color
• Realign 2020: Content
• Realign 2020: Netlify
• Realign 2020: Tooling Updates

After the the illustration work and in browser playing, I jumped back into Sketch to try to get at a more concrete plan and to play more. I won’t continue in Sketch to get a “complete” design. I prefer to do a lot in CSS. But here's a zoomed out screenshot of my current mess to get an idea of what I’m up to.

You can see shell pages started for projects. I have six main buckets of work that I want to present in detail. There’s a lot more, but those are the ones that I’ll have the time and energy to pull off right now.

Here we go again.

Thanks for reading

First, the problem. I didn’t do anything fancy with the NetlifyCMS installation. I used the standard approach described in their docs. One requirement we had was to not use Netlify. We wanted to keep things on our AWS infrastructure, because that’s where all our stuff is. We didn’t want another thing to manage.

Before diving in, here are links to examples described in this post. These might be all you need to get going if you’re building a similar thing:

• Live client example
• Client example repo
• Server example on Glitch
• Server example repo

For NetlifyCMS authenticaton I went with GitHub backend. I got lost there. The docs say:

To enable basic GitHub authentication:

1. Follow the authentication provider setup steps in the Netlify docs.
2. Add the following lines to your Netlify CMS config.yml file:

NetlifyCMS docs, "Authentication & Backends - GitHub Backend”

I didn’t want to use Netlify. But I also went ahead and followed the docs they referenced in step one. Even with that, I couldn’t quite figure out what needed to happen. Step two above was fine. But, I could tell something was missing.

The Problem

When I tried to log in to the NetlifyCMS on our deployed site, I would hit a 404. So I knew I was missing some piece, but was unclear what that was. I’d spent a while banging my head against it so I asked a question in the NetlifyCMS Gitter room, but didn’t find help there.

The Solution

To use a GitHub backend with NetlifyCMS, you have to have your own server to handle OAuth. This is a requirement of GitHub’s authentication flow. The good news about that, is that it’s a standard OAuth flow. The bad news about that, is that it’s a standard OAuth flow.

Prior Art

vencax/netlify-cms-github-oauth-provider is an example of what’s needed. It’s mostly an example of a standard OAuth flow with a couple—very—helpful NetlifyCMS-specific bits. That got me almost there, but I still couldn’t get everything working. I was still having trouble understanding how all the pieces fit together.

What I needed to do was build my own server to handle the OAuth flow. This is a thing I’ve done and written about before. OAuth is like that for me. I set it up. Deploy it. Forget it. Then have to give myself a refresher to do again. That’s what the server example in this post is.

The Server

I went with Glitch for this example. For me it’s quickest way to get a server spun up. And the easiest way for me to share it with you.

I put steps in the README to explain what you need to do to get this up and running for your own use.

The user-facing part of the server example exists, but it’s not meant for direct use. If you try to use it directly it’ll look like it’s not doing anything. The idea is for you to copy the example—either on Glitch or your own server—and point your NetlifyCMS client at it using the base_url key described below and in the client example.

The code is 99% standard OAuth handshake handling. A GET followed by a POST to GitHub’s OAuth resources to retrieve the OAuth access token. I left comments in the code to point out what’s happening and what’s NetlifyCMS-specific. The biggest chunk of code that NetlifyCMS needs is this;

const postMsgContent = {
  token: body.access_token,
  provider: "github"
};

const script = `
  <script>
    (function() {
      function recieveMessage(e) {
        console.log("recieveMessage %o", e);

        // send message to main window with the app
        window.opener.postMessage(
          'authorization:github:success:${JSON.stringify(postMsgContent)}',
          e.origin
        );
      }

      window.addEventListener("message", recieveMessage, false);
      window.opener.postMessage("authorizing:github", "*");
  })()
</script>`;

A couple bits of formatting aside, I took this from vencax/netlify-cms-github-oauth-provider. This chunk of code is a little tough to follow. The gist of it is that your NetlifyCMS client JavaScript is gonna get your GitHub access token via postMessage. I tried to find the postMessage handling code in the NetlifyCMS code, but haven’t been able to track it down yet. If anyone knows where that is, I’d love to know.

We put this script in a string because we have the server respond with it. You could also put this in HTML and return the access token a different way, but this a way to make short work of it.

The Client

There’s a single customization needed to make this work with the standard GitHub backend NetlifyCMS configuration. The base_url key.

backend:
  name: github
  branch: master
  repo: tylergaw/netlify-cms-github-oauth-provider-client-example # change this to your repo
  base_url: https://netlify-cms-github-oauth-provider-example.glitch.me # change this to your OAuth server

The other items in config.yml are standard NetlifyCMS config items. base_url needs to be a public URL to the server that handles OAuth for your GitHub application. Like the example in this post.

You can see in the client code that this is a no frills NetlifyCMS setup.

That’s All

We’re a similar setup at StreetCred on our soon-to-launch new site and so far, so good. NetlifyCMS is an excellent project. One that I’ve been wanting for years. It checks all the boxes that other CMSs don’t and I look forward to using it more.

If this post and/or the examples helped you, or if you try to use it and get stuck, send me an email at me@tylergaw.com and let me know.

Thanks for reading

Here’s a non-exhaustive, unordered list of things about my work—maybe yours too—that are good.

• HTML is good
• The WHATWG is good
• CSS is good
• The CSSWG is good
• Sass is good
• PostCSS is good
• CSS-in-JS is good
• CSS Modules is good
• Sketch app is good
• Photoshop is good
• Illustrator is good
• Affinity Designer is good
• Paying for fonts is good
• JavaScript is good
• jQuery is good
• React is good
• React Native is good
• Redux is good
• Redux Thunk is good
• Redux Saga is good
• node is good
• Babel is good
• webpack is good
• rollup.js is good
• gulp is good
• Metalsmith is good
• Handlebars is good
• Prettier is good
• npm is good
• yarn is good
• Python is good
• Django is good
• Flask is good
• PyPI is good
• PHP is good
• Ruby is good
• Rails is good
• Atom is good
• TextWrangler is good
• Vim is good
• RSS is good
• Server-side rendering is good
• Client-side rendering is good
• Progressive enhancement is good
• Being positive is good
• Being earnest is good
• Being kind is good

There are infinite more things that are good about being a designer and engineer. If you read my list and thought; “Thing X is also good, why isn’t it on your list?”. It’s not that I don’t think thing X is good. It’s either that I; didn’t think of it, or don’t have enough knowledge about it to know it’s good. For those, I encourage you to make your own list of Good Things.

Thanks for reading

1. I’m reading more books
2. Always having a book I want to read (that I’m actually interested in, if I don’t like it, I put it down and walk away)

For step number two, I either buy two books at once or as soon as I finish a book, I go get another one. Lately, at the excellent McNally Jackson on Prince St. near my apartment.

The third thing I’m doing is documenting the book I’m reading and the books I’ve read in Library. Nothing fancy, just a list book titles, authors, and the month and year I read the book. I’m not making an attempt to list books before 2019 right now. Just starting with what’s fresh in my mind.

I decided I wanted this after reading Austin’s, “How to read more”. In it, he mentions Art Garfunkel’s list of read books. That list is amazing. I hope to maintain my list for even a portion as long as he as.

For this site, the numbers serve no purpose. They’re a vanity metric I either never look at or anxiously check when I have a burst of traffic for whatever reason. That anxious checking. It’s one more set of numbers to obsess over. The Unread emails, Slack notifications, Tweets, favorites, texts, and on and on and on. Ditching one set of numbers that want everything and give nothing feels good.

Also, I don’t want this site to track people in any way. You have enough of that. I know my use of analytics isn’t responsible for you getting ads about a jacket you looked at once on every other website you visit forever. But, hey this is now one less site that’s collecting information about where you’ve been on the Web. We could all use that.

Thanks for reading

First things first. If this idea sounds familiar, it’s because it’s been a thing before. In 2012, when I was on the Readability team, we designed and built Readlists. Readlists shut down in 2016. It happens. But I miss it and I know other people do to. I don’t think it’s a huge number of people, and that’s OK. My goal for Anthologies is to build a small tool that does one thing well. If only a few people use it, that’s A-OK with me. And much cheaper. (I plan to write about my approach to building this in a cost-efficient way as soon as I figure out how to do that. I’m following the serverless path right now.)

MVP

At its core, an Anthology is a title, description, and list of urls or “entries” as I’m referring to them. For the MVP, I’m also going to expand that to include details about each entry as they’re available. Each entry can have a title, excerpt, author, publication, and image. If each entry has those or not will depend on the contents of the page at the url. I know from experience that parsing pages for those details is unpredictable. So my design needs to be flexible.

Systems Check

Like a lot of designers, I sit down and get right to work on a new design by staring at fonts for an hour or two. For Anthologies, I wanted what I usually want from a typeface. I wanted sturdiness at small sizes and a good range of weights. I wanted a super heavy weight for stand-out titles. I also had a specific type hang-up this time around; I wanted a typeface with a two-story lowercase “g”. In early logo and UI sketches I kept drawing two-story g’s so I had it stuck in my brain and didn’t see a reason to fight it. I settled on Aaux Next. It has a beautiful two-story g. So far I’ve used the regular, medium, black, and ultra weights.

Another way I like to put off designing is to fiddle with grid configurations. Sketch makes this way too easy. After the proper amount fiddling, I landed on a grid that seems to work well. The grid is seven–191 pixels wide–columns with ten pixel gutters. I set row gutters at twenty pixels, and every now and then actually set text on them the right way.

If you’re looking at the grid image you might notice it’s off-center to the right. That’s on purpose. You’ll see later that each mock-up includes a banner with branding on the left. I didn’t want that to use the grid. I only place the primary content on the grid.

The Concepts

With ample procrastination out of the way, I started designing. For content, I used The Longform Guide to Sad Retired Athletes. Their collections are a perfect match for the type of content I expect will make up most Anthologies.

1. Two-up

The first go at it. A lot went into this that you don’t see in the mock-up. Much shuffling of text and images happened to get to this point. I don’t know that this is “good”, but it felt like a complete thought. It felt resolved enough. It displays the Anthology content and provides links to the articles. It accomplishes the goals.

The most valuable artifact of this iteration are the discovered interface patterns. These are building blocks for every later iteration. There’s a “cover”–made up of the title, description, and byline. The entries–made up of individual entry elements. And within those are smaller components. I think about these in Atomic design terms. The cover is a organism. It includes an “intro” molecule. The intro contains title, description, and byline atoms. And so on. These might not be the exact elements I end up with, but they’re a way for me to break down the interface into distinct parts. Finding interface building blocks is a goal of my early design process.

An Organized Tangent

Keeping my artboards, groups, and layers organized in Sketch helps me focus. Naming those items also helps me get a jump on naming elements in HTML and CSS. The names I use in Sketch, I’ll use for future class names, file names, etc. When I look at the Sketch layers palette, I see the DOM.

The name of each design concept is the name I gave the artboard in Sketch. Those names might not stick and aren’t always descriptive, but they help me organize my thoughts.

The first iteration is always the hardest. With it out of the way I started having a lot of fun with the designs. The rest of the concepts are me asking; “what if…?” and then designing answers. These aren’t meant to be separate themes to choose from. They’re exploration of possibilities. It’s me searching for interesting ways to display the same content. In that searching I find design solutions, but also more questions that lead to more design. This was also just good, fast design fun. I could do fifty of these and keep going. I won’t though, because I want to ship this thing sooner than later.

2. Grid Dark

This was a tiny step from the first concept. A little more modern, techy aesthetic. Instead of cropping the cover image, I let it fill the layout, and let the entries float above the background. A joke name I had for it was “Textflix”, because it reminded me of Netflix’s aesthetic. I’m light on words for this one because I think it’s just…fine. I could ship this and it’d work, but it doesn’t really move the needle for me. It invokes a healthy shrug.

These first two iterations were dark and felt heavy. For the next concept I lightened things up in color and design elements.

3. Text Light

Along with a lighter aesthetic, in this concept I changed grid usage. In the first two concepts, I gave the cover three columns and the entries four. In this concept, I gave the cover image more prominence. When I saw that, it felt like it needed room to breathe. With that, I gave it another half column and reduced the entries to three-and-a-half columns.

Content-wise, I introduced entry excerpts. The layout of the first two concepts worked better without excerpts. It feels a bit off to exclude them for entries though. It seems like the reader needs a bit more of a hook to decide where they want to start.

In the future, excerpts could be curator-configurable per Anthology.

4. Text Light Imgs

This was the first concept I tried using an image for each entry. When I saw them in place, it felt like the cover image could go away. The title and description could shoulder the work of being the cover.

For this concept I also tried an off-white background color. I pulled this from Readability, Instapaper, Pocket, et al. In those, a similar color tended to be used for a sepia theme. I’m luke-warm on it.

I explored options for the branding banner here too. I wanted to see if a stark contrast between banner and content could help the banner detach and fade away. Sometimes when an element is so much different than the rest of the design, it can make it easier to consider it, then ignore. I’m still not sure if it’s working or not, but it’s interesting.

5. Text Light Two

In this concept, I let myself toss around more design elements. Scattered orange blocks here, a few tech lines there, an angle on the cover image, and so on. With the orange blocks, I was thinking about something like a 1970s jazz album cover. Or at least how I pictured them looking. I also switched the title and entry headings to the Ultra weight of Aaux Next. They felt like they needed some extra heft.

With the introduction of more design elements, it felt like the eye needed a little break. To give it that rest, I removed the image thumbnails for each entry.

6. Spartan

After Text Light Two with all its fiddly bits, I wanted to try one the other way. For this concept I let the content speak for itself. Text and images as content with–almost–no other design elements. I kept one element in place, the subtle border between the cover and entries. You might also notice I increased all the font sizes. The title and each entry title felt like they needed more oomph to take center stage. I was looking at–and taking cues from–the New York Times on this one.

At this point, this concept feels the strongest in terms of practicality and broad use. When I start building, I’ll most likely use this as a guide.

7. Party

Oooooh shit, here we go! I needed to see one like this. I took about a day break between Spartan and this concept to clear my head. Then I threw everything at the wall. I’ve been reading posts on The Outline and enjoying the design they’re doing. I lifted ideas wholesale from them on this concept. That’s a fun thing about doing early concepts like this, it’s OK steal. It’s more about serious play than producing a finished piece.

I don’t know if a concept like this will make it to browsers, but it could. I don’t think it’s “bad.” Depending on the tone of the Anthology, something like this could work well. I plan to explore this type of aesthetic more as I go.

HTML/CSS Here We Come

Designs like this are never “done”, but this one is ready for the next step: browsers. Using Spartan as a base, I’ll build an Anthology page using static-content. As soon as you get in a browser you learn a ton. The design will shift and shimmy from the static mocks here to meet the needs of its ultimate home.

As I mentioned before, I have more posts I want to write about my process. When I dive into these projects I let myself get pulled into the weeds in myriad areas of design and development. It’s tons of fun and it’s important to share. Keep an eye out for more.

To date, Dribbble API changes have been additive. API features have given users more access to more of data via the API. As Dribbble explained in their post, version two goes the other way, it removes a lot of functionality.

The reduced functionality seems fine though. In my time working on Jribbble, most conversations I’ve had with designers are about using it to get their own shots. That’s still available, and the focus of API version two. My guess is most users of Jribbble won’t lose out. They will need to make code changes to continue using Jribbble though.

I’ve had a few conversations with folks on GitHub and email about updating to Jribbble 3.0. The biggest change is that Jribbble is no longer a jQuery plugin. It’s now a standalone library. I write more about the decision to remove jQuery later in this post.

The other big change is the shape of Jribbble’s public API methods. Here’s a 2.x vs 3.x example of a user getting their own shots with Jribbble:

// Jribbble 2.x
$.jribbble.setToken("<access_token>");
$.jribbble.users("tylergaw").shots().then(function(shots) { /* Work with shots JSON */ });

// Jribbble 3.x
jribbble.setToken("<access_token>");
jribbble.shots(function(shots) { /* Work with shots JSON */ });

The Jribbble API is no longer chainable or promise-based. Again, I detail more of the code decisions later in this post. We can still do the same thing, but now in a more concise way.

A New Barrier to Entry

With Dribbble API version one, we could make requests using read-only client access tokens. When creating an application via the Dribbble UI, they would generate the client access token. We could then use that token to make requests to the API.

In version two, those easy-to-use, auto-generated client access tokens are gone. Now, all requests must use a bearer token. To get a bearer token, you have to go through the OAuth2 flow.

Depending on your experience with OAuth, you might read that and think; “Sure, no problem. OAuth is easy” or “uhhhh, what’s an OAuth?” or somewhere in between. At any experience level, if you only want to make a single API request to display your Dribbble shots on your personal site, it’s a rigmarole.

When I first read about the new auth I thought, “welp, Jribbble is dead. As is all client-side JS access to the Dribbble API.” I thought this beause in most cases, you shouldn’t put OAuth-generated bearer access tokens in public code. Doing so makes them available for anyone to find and act on behalf of token owners in any–malicious–way they want.

I asked the Dribbble folks about this and they let me know that in this case, putting access tokens in public code would be OK because they’re read-only. A bad actor could still snag your access token and use it to abuse the API on your behalf. I’d guess by making a ton of nonsense requests. The Dribbble API has rate-limiting in place to help mitigate this. At the worst, Dribbble could revoke your access token or disable your app. You’d then need to go back though the process to get a new token and/or create a new app.

This change still didn’t sit well with me though. What are less code-savvy folks supposed to do? The main users of Dribbble and Jribbble are Designers. There’s a good chance many of them don’t have experience creating and deploying OAuth flows. That’s exactly who I’ve had conversations with over the years. And that’s who has reached out to me since the API version two announcment. Folks that know enough code to copy, paste, and tweak a snippet of JS, but not enough code to build and deploy a custom OAuth setup.

With that, I set out to come up with a way to help them. Because that’s what we do here.

Options

My first idea was to create a site where people would authenticate with a Dribbble application that I owned. They’d show up, tap “connect”, confirm with Dribbble, then get directed back to my site where they’d get an access token.

That would get the job done, but felt wrong. Having people authenticate through my app would mean their access tokens would be in my hands. If I deleted the app—or my Dribbble account—their tokens would stop working. If a bad actor generated a token then used it to abuse the API, my app could get suspended. Again, taking every user’s access token with it.

I needed a way for every Jribbble user to be able to generate access tokens using an application they owned.

Glitch

If you haven’t used it yet, Glitch is an excellent tool for sharing and learning code. What sets Glitch apart from similar code-sharing tools is that it gives you the ability to create and share web servers.

That’s exactly what I needed for this OAuth problem. I could write the server necessary for the OAuth flow, then make it available for anyone to–in the parlance of Glitch–“remix” the code to get full access to it. And they can do so without even creating a Glitch account.

So that’s what I did. jribbble.glitch.me is template that anyone can remix to get their own OAuth flow for generating bearer tokens to use with Dribbble API version two.

I won’t say that writing a server for this is “easy” because it’s only easy if you already know how to do it. But, I hope that this will help folks see that it’s attainable. To demonstrate, I’m going to plop the entire server here. The code is under 100 lines. The rest is comments to help people understand what’s happening at each step along the way:

const express = require("express");
const tiny = require("tiny-json-http");
const nunjucks = require("nunjucks");
const cookieParser = require("cookie-parser");

// We store the relavant Dribbble URLs here for convenience.
// authUrl is passed along to our template in the `/` handler below.
const authUrl = "https://dribbble.com/oauth/authorize";
const tokenUrl = "https://dribbble.com/oauth/token";

// The path of the Callback URL we set when creating our application on Dribbble.
// We reference this URL below in an app.get
const callbackUrl = "/oauth_callback";

// This isn't oauth or dribbble specific, but storing the value of the original
// Glitch project to check if we're seeing the original or a remix.
const ogGlitchUrl = "https://jribbble.glitch.me";

// These environment variables need to be set in the `.env` file. Look to your left 👈
// client id is safe as public value, if those are seen, it's OK.
// client_secret is not safe for public. You need to keep that private at all times.
const client_id = process.env.DRIBBBLE_APP_ID;
const client_secret = process.env.DRIBBBLE_APP_SECRET;

// When we receive an access_token from the api.dribbble.com server, we'll store it
// in this variable.
// Q: Why do we use `let` here instead of `const`?
// A: We use `let` so we can reassign `access_token` to a new value. Here, we set
//    an initial value of `null`. Below in the `/oauth_callback` handler we set
//    it to a new value of the access_token from the server.
let access_token = null;

// Standard express setup code.
const app = express();
app.use([express.static("public"), cookieParser()]);

// Set up our template library.
// I–Tyler–didn't look too deep into this, this block of code came from the nunjucks
// docs and got me up and running, so good enough for me at this time.
nunjucks.configure(["views", "public"], {
  autoescape: true,
  express: app
});

// This is our homepage and the page that does most of the work.
app.get("/", (req, res) => {
  const pageUrl = `https://${req.get("host")}`;

  // Here, we'll try to set the access_token from a cookie.
  // In the callback handler below, we set the access_token cookie on successful auth.
  // This isn't something you need to do in your Jribbble uses.
  access_token = req.cookies.access_token;

  // We use render so we can pass along variables to our template.
  // In index.html any time you see {{thing}} or {% %}, we're referencing
  // a variable we set here.
  res.render("index.html", {
    authUrl,
    accessToken: access_token,
    clientId: client_id,
    // Just in case we've hit an authentication error we'll use this to display a message in the template
    error: req.query.error,
    // We create new boolean value here so we don't send the actual secret to the template.
    // Note: I–Tyler–am not sure this is 100% necessary, but it felt best to be overly
    // cautious when our app secret. You don't want anyone to have that.
    hasClientSecret: client_secret.length,

    pageUrl,
    isRemix: pageUrl !== ogGlitchUrl,
    callbackUrl
  });
});

// This is where our Dribbble applications will come back to after a GET to authUrl
app.get(callbackUrl, async (req, res) => {
  const data = {
    code: req.query.code,
    client_id,
    client_secret
  };

  try {
    // We required `tiny` above in tiny-json-http
    // That's a small http library I preferred to use https://github.com/brianleroux/tiny-json-http
    // It's not the only way to make requests, there are many different was to accomplish
    // this http post request to Dribbble
    // Note we are using async/await here. If you're unfamiliar, that's OK. The number one thing
    // to know is `await` makes this code act like it's pausing here and waiting for the http
    // request to complete before moving on to the following lines of code.
    const { body } = await tiny.post({ url: tokenUrl, data });

    // As mentioned above, here we're assigning access_token a new value that is your
    // shiny oauth access token that gives you public read access to your Dribbble account
    access_token = body.access_token;

    // NOTE: Setting a cookie want be required in your uses of Jribbble, because you will
    // include the access_token in your JavaScript.
    res.cookie("access_token", access_token);

    // We don't want to stay on the /oauth_callback page, so redirect back home.
    res.redirect("/");
  } catch (err) {
    // If we hit an error we'll handle that here
    console.log(err);
    res.redirect("/?error=😡");
  }
});

app.get("/logout", (req, res) => {
  res.clearCookie("access_token");
  res.redirect("/");
});

app.listen(process.env.PORT);

Again, you can remix this at jribbble.glitch.me to get full access to the code.

Another cool thing. This example is intended for the Dribbble API, but with a few minor changes, it will work for any standard OAuth flow.

If you use that and run into trouble–or think it’s great–let me know on Twitter.

The Jribbble Rewrite

The main part of this project was writing Jribbble 3.0. Jribbble 2.x has six public methods to access resources from Dribbble API version one. Many of those methods have subresources like comments, likes, et al. It also has a chainable, promise-based interface. All these things add a non-trivial amount of plumbing code to make them possible.

Dribbble API version two reduces functionality to getting the current user’s profile, shots, and projects. For Dribbble-approved applications you can get a user’s likes and a list of popular shots.

The reduced functionality meant I could cut most of Jribbble’s code. The first thing I did was audit the usage of jQuery. The only jQuery methods in use were; $.ajax, $.Deferred, and $.extend. Because of the limited usage, I decided Jribbble 3.0 would not use jQuery.

It also didn’t feel necessary to use any type of transpiling process. So no Babel or TypeScript or the like. I would only write good-ole browser JavaScript. Also, I wanted 3.0 to work in as many browsers as possible, so I only used old-timey JS. No arrow functions, no let or const, etc. It wasn’t that bad. This is a small library so restraining myself to older JS wasn’t a problem. And writing it directly instead of relying on Babel keeps the file size smaller.

I could have used newer features and still probably ended up with wide-enough support, but it was a fun challenge. And it reminded me of writing JS in years past.

This was enough of a rewrite that I opened a new, blank file and started writing instead of reusing 2.0 code.

3.0 Details

Like 2.0, this version also has six public methods; setToken, shots, user, projects, likes, and popular. Each method is available on the window-scoped jribbble object.

setToken is the same as in 2.0. It’s how users give Jribbble their access tokens.

jribbble.setToken("12345");

For 3.0 I decided to also allow users to provide their token as an option when calling any of the other methods. For example:

jribbble.shots({token: "12345"}, callback);

That accomplishes the same thing as setToken in a more concise way.

From here, I’ll detail three internal functions that handle the lion’s share of what Jribbble can do.

Function one: get

I took it back in time for this one. For day-to-day work I use fetch or a wrapper like Axios to make network requests. For Jribbble I didn’t want to use a third-party library or polyfills for requests. So instead of fetch, I went back to XMLHttpRequest.

All Jribbble requests have the same requirements so I was able to abstract the functionality to a common function. I use the internal get function for all requests to the Dribbble API:

var get = function(path, callback) {
  var url = "https://api.dribbble.com/v2/" + path;
  var req = new XMLHttpRequest();
  req.addEventListener("load", function() {
    if (callback) {
      if (typeof callback === "function") {
        var ret = {};

        if (this.status < 400) {
          try {
            ret = JSON.parse(this.responseText);
          } catch (err) {
            ret = {
              error: "There was an error parsing the server response as JSON"
            };
          }
        } else {
          ret = {
            error:
              "There was an error making the request to api.dribble.com.",
            status: this.status
          };
        }

        callback(ret);
      }
    }
  });
  req.open("GET", url);
  req.setRequestHeader("Authorization", "Bearer " + accessToken);
  req.send();
};

Not bad. It’s a standard XMLHttpRequest GET request with an Authorization header. The bulk of the function is guard code to protect against type errors, JSON parsing problems, and network errors. It does what it can to fail with grace if there is a problem.

I use the Authorization header to send along the user’s Dribbble access token with every request.

The get function will work back to IE7. I figured It’d be safe to not include the old fork to check for ActiveXObject. It’s been years since I’ve typed that, it’s giving me a good chuckle to see it here.

Function two: createApiMethod

The user, projects, likes, and popular methods all do the same thing. They process N-number of arguments, make a request to the Dribbble API, and call a user-provided callback. The callback receives a single argument, the JSON response from the request.

Because they’re all similar, I didn’t want to have to repeat the same code when defining each method. Instead, I abstracted the functionality to createApiMethod.

var createApiMethod = function(path) {
  return function() {
    var args = processArguments.apply(null, arguments);
    get(path + args.query, args.callback);
  };
};

The path parameter is passed along to get to build the URL to the Dribbble API.

I then define each public method as a member of the api object. Each is a function with a unique path based on its needs.

var api = {
  ...
  user: createApiMethod("user"),
  projects: createApiMethod("user/projects"),
  likes: createApiMethod("user/likes"),
  popular: createApiMethod("popular_shots")
};

This doesn’t provide any extra functionality. It only makes it so I don’t have to repeat as much code when defining methods. createApiMethod returns a function. Let’s look at what’s happening in the body of that function.

var args = processArguments.apply(null, arguments);
get(path + args.query, args.callback);

The first line is the heavy lifting. It’s function number three that I’ll write about next. For now, it’s important to know that it returns an object with query, callback, and resourceId keys.

Those values, plus the path argument, let us build the arguments needed to make the request to Dribbble with get.

Function three: processArguments

For me, this is the most interesting bit of code in Jribbble. Every public Jribbble method except setToken uses processArguments. Its purpose is to inspect all arguments passed to Jribbble methods.

To show its usefulness, consider the following usage examples:

jribbble.shots(
  "456789",
  {token: "12345"},
  function(shotObject) { /* Work with JSON */ }
);

jribbble.shots(
  {token: "12345", page: 3, per_page: 5},
  function(shotsArray) { /* Work with JSON*/}
);

jribbble.projects(
  function(projectsArray) { /* Work with JSON */ },
  {token: "12345"}
);

jribbble.user(
  function(userObject) { /* Work with JSON */ }
);

Notice in each I’m providing a different number of arguments of different types. And in the case of projects I’m providing the arguments in a different order. This type of flexibility isn’t possible with a typical method signature. One where I define each parameter when I create the method.

For example, imagine a method signature for jribbble.shots like this:

var shots = function(shotId, options, callback) { /* Do the work */ };

That would work for the first usage example, but what about the second? What if I don’t need a single shot and I don’t need to provide an options argument?

This is where processArguments comes into play.

First, notice when I call the function in createApiMethod I use apply:

var args = processArguments.apply(null, arguments);

This took me a few minutes to get my head around. It’s also hard to write about, but here goes. I need the function that createApiMethod returns to take zero to three arguments. The Jribbble user, provides those. Using apply let me pass along the arguments object received from calls to public API methods. Then, within processArguments I have access to that original arguments object. Once I have it, I convert it to an array for manipulation:

var args = [].slice.call(arguments);

An important thing to note is processArguments doesn’t define parameters:

var processArguments = function() {...};

Again, that’s not something I can define ahead of time. This whole dance lets the public methods be flexible in number and order of parameters. It lets them say “yeah, whatever you got, I’ll take it.”

I mentioned earlier, processArguments returns an object with query, callback, and resourceId keys. The work of the function focuses on creating that object.

While I can’t define parameters, I do know a few things about potential arguments. I know any callback should be a function and any options should be an object. I also know resourceId is the identifier for a Dribbble shot. A shot id can be a string or a number.

I use that knowledge to inspect each item in the args array I created from the arguments object. Depending on the type I assign the item’s value to a local variable.

...
var resourceId = null;
var opts = {};
var callback = function() {};
...
for (var i = 0; i < args.length; i += 1) {
  switch (typeof args[i]) {
    case "string":
    case "number":
      resourceId = args[i];
      break;
    case "object":
      opts = args[i];
      break;
    case "function":
      callback = args[i];
  }
}

That snippet sets two out of three variables this function needs to return. resourceId and callback are ready to to go. I only use resourceId in jribbble.shots. The Dribbble API has different paths if you’re requesting a single shot or a list of shots. I use the value–or lack of a value–of resourceId to determine the path.

What about the third item, query? Also what is this opts object in favor of?

In earlier examples, I showed providing an object with token, page, and per_page keys to public methods. Token is the most important one. If a user doesn’t provide an access token, they can’t make requests. After the for loop I check for a token key on the opts object:

if (opts.token) {
  accessToken = opts.token;
}

I define accessToken at the root level of the main Jribbble function. This is how I provide the flexibility of setting token with the setToken method or via an options object.

At this point in processArguments, if there’s no value for accessToken there’s no reason to continue. I throw an error and let the user know they need to update their code.

if (!accessToken) {
  throw new Error(
    "jribbble needs a valid access token. You can either include this as an option: jribbble.shots({token: '1234'}) or with jribbble.setToken('1234')"
  );
}

If the user provided page or per_page, those keys will also be on the opts object. query needs to be a string that I can append to the URL of any request. So, I need to create that string if necessary. I know that “page” and “per_page” are the only query parameters allowed because they’re documented. I can use that knowledge to build the string based on the user-provided values.

var params = ["page", "per_page"]
  .map(function(p) {
    return opts[p] ? p + "=" + opts[p] : null;
  })
  .filter(function(i) {
    return i;
  })
  .join("&");

For each item in the array check to see if that key exists in opts. If it does, return a string beginning with the item plus an equals sign plus the value in opts. If the key isn’t in opts return null.

At this point, we could have an array that looks like:

["page=4", null]

That’s if the user set a page, but not a per_page value.

Next, I use filter to remove any null values. And finally join the items of the array with an ampersand between each. In the above example we’d end up with “page=4”.

processArguments is ready to return an object with the three keys needed. I also need to do one last thing for query. If the user doesn’t need a query, return an empty string. If they do, prefix the params string with a “?” so it’s ready to append to a URL.

return {
  resourceId: resourceId,
  callback: callback,
  query: params ? "?" + params : ""
};

And that’s processArguments. Syntax and even code-wise it’s not fancy, but it does a job and does it in what I think is a clear way.

One more iteration complete

This was another iteration on a little library I keep going. It has a small userbase, but I know it provides value for them when it’s needed. As the Dribbble API changes, I’ll keep Jribbble in sync as best I can.

Again, the OAuth flow project is at jribbble.glitch.me or just jribbble.com. The Jribbble source is available on GitHub. If you run into trouble, please open an issue or submit a pull request.

Thanks for reading

I’ll detail my process in this post. Here’s a live demo and an editable sandbox. The best way to see the effects is to use the Redux DevTools Chrome extension.

If you’re reading this I’m going to assume you have knowledge of Redux and are using it with React by way of react-redux. I'm also going to assume you’re looking for a solution to a similar problem.

What am I trying to do and why?

In standard Redux usage, you provide reducer functions at the time you create the store with createStore. I wanted a way to add reducer functions later, on demand.

A lot of folks need this because their reducers are not available at createStore time due to code-splitting. That’s a perfect use for dynamic reducers.

My project doesn’t use code-splitting. For this, dynamic reducers were a preference. I didn’t want to spread info about modules throughout the project structure. I wanted each feature to live in a directory, isolated as much as possible. That meant co-locating reducers, components, styles, and so on. I could do that and still import the reducers to the main reducer creation, but that would couple module reducers to the main reducer.

Existing solutions

In my Googling for an existing solution I landing on this Stack Overflow question and answer. The answer is from Dan Abramov so I knew it was a way to go. My solution uses most of the code from that answer.

In Dan’s answer, it all made sense to me until his example of how to inject reducers. I’m using React Router, but I don’t define routes the way he described. I didn’t want to have to change how I defined my routes for this. I also couldn’t find official documentation for methods he used in his example so I wanted to avoid copy / paste. I also wanted to fully understand the code I was adding to my project.

It’s worth mentioning two projects I came across in my search. redux-dynamic-reducer and paradux. I didn’t try either of them because I didn’t see the need in adding another dependency, but they might work for you.

What the demo shows

The demo shows a simple page with a link to /records. When page loads, the Redux state tree contains two keys. One for each reducer function introduced at store creation.

There’s a link to the /records page. When you navigate to that page, I add another reducer function for Records. In the rest of this post I’ll decribe how I do that.

The code

You can follow along in the CodeSandbox. I’ll start with creating the root reducer in /rootReducer.js.

import { combineReducers } from "redux";
import layout from "./reducers/layout";
import home from "./reducers/home";

/**
 * @param {Object} - key/value of reducer functions
 */
const createReducer = asyncReducers =>
  combineReducers({
    home,
    layout,
    ...asyncReducers
  });

export default createReducer;

I pulled this code from Dan’s SO answer. It has two reducer functions; layout and home. They’re global reducers, not module level, so they fit well in the root reducer.

The key detail here is the asyncReducers parameter. Adding the contents of it to the object given to combineReducers is how we add reducers later.

Next up is store creation in /initializeStore.js. Again, most of this code is from Dan’s example.

import { createStore } from "redux";
import createReducer from "./rootReducer";

const initializeStore = () => {
  const store = createStore(createReducer());

  store.asyncReducers = {};
  store.injectReducer = (key, reducer) => {
    store.asyncReducers[key] = reducer;
    store.replaceReducer(createReducer(store.asyncReducers));
    return store;
  };

  return store;
};

export default initializeStore;

The first line of initializeStore is where we create the Redux store with the initial reducers from createReducer. In standard Redux usage, this is all you’d need. The store is set up and ready with the home and layout reducers.

createStore returns a plain object, so we’ll take advantage of that by tacking helpful items onto it. We’ll use store.asyncReducers to house our dynamic reducers. With store.injectReducer I deviate from Dan’s example. The function does the same thing as his injectAsyncReducer, but I attach it to the store object for convenience that I’ll show later.

injectReducer has two responsibilities. First, store all dynamic reducers in asyncReducers. This ensures that each time we invoke injectReducer we don’t lose other dynamic reducers. Next up is the main work. replaceReducer isn’t custom, it’s part of Redux. It does does what it says on the tin. Invoking it replaces the reducer function with one you give it.

Where things got tricky for me

At this point everything seemed straightforward to me, but then I got lost fast. I have a store, I have a function to add new reducers. But where can I access that function to invoke it? In all my frantic Googling, I couldn’t find an example that worked for my setup. So, I sat down to figure out a solution.

It took me a while to figure out where I could access that store object. I had clues though. In my entry point file /index.js I use the Provider component. This is standard for React / Redux projects.

import React from "react";
import { render } from "react-dom";
import { Provider } from "react-redux";
import initializeStore from "./initializeStore";
import App from "./App";

const store = initializeStore();
render(
  <Provider store={store}>
    <App />
  </Provider>,
  document.getElementById("root")
);

Giving the store to Provider makes it available to all child components by way of the connect function. I read more about it and learned that store is also available in the context of each component. If you’ve read anything about React context, you’ve read that you probably shouldn’t use it. For my purposes here it seemed isolated enough to be OK. Time will tell if that’s correct or not. More details on my context usage to later.

Putting the pieces together

I want to use as little code as possible to add reducers. I do that with a higher-order component in /withReducer.js.

import React from "react";
import { object } from "prop-types";

const withReducer = (key, reducer) => WrappedComponent => {
  const Extended = (props, context) => {
    context.store.injectReducer(key, reducer);
    return <WrappedComponent {...props} />
  };

  Extended.contextTypes = {
    store: object
  };

  return Extended;
};

export { withReducer };

And example usage in routes/Records/Records.js:

import { withReducer } from "../../withReducer";
import reducer from "./ducks";

const Records = () => (...);
export default withReducer("records", reducer)(Records);

I’ll start with usage in Records.js. I import the records reducer from routes/Records/ducks/index.js. The reducer doesn’t do much. It sets hard-coded initial state, then returns it as-is. The component acts like a container component. I could connect it, but for the purposes of this demo, left it out.

The pertinent bit is the last line. There I invoke withReducer and provide it a key of “records” and the record reducer. Then I invoke the returned function, providing the Records component.

Records is a React component I import to use as the value of the component property of a React Router <Route />.

The withReducer component

withReducer is a Higher-Order Component. The key parameter becomes the key in the Redux state tree. The reducer parameter is the reducer to add. It returns a function that accepts a single parameter, WrappedComponent. That’s expected to be a valid React component. In the earlier usage example, that’s the Records component.

I’ll jump ahead to an important part of withReducer that was new to me and might be confusing.

...
Extended.contextTypes = {
  store: object
};
...

Extended is a stateless component, so it must define a contextTypes property to gain access to context. From the React docs:

Stateless functional components are also able to reference context if contextTypes is defined as a property of the function.

reactjs.org/docs/context.html#referencing-context-in-stateless-functional-components

In contextTypes I defined the property I want to access in the component, store. That uses the object type from the prop-types library.

When a component defines a contextTypes property, it receives a second parameter, context. That’s visible in the Extended signature:

...
const Extended = (props, context) => {...}
...

Extended now has access to the store object. That’s because <Provider store={store}> in /index.js makes it available to all child components via context.

This happens in the Provider.js source with getChildContext and childContextTypes. That code is good reading if you’re looking for examples of context usage.

In initializeStore.js I created a function on the store object, store.injectReducer. Now, I use that to add the new reducer:

...
const Extended = (props, context) => {
  context.store.injectReducer(key, reducer);
  return <WrappedComponent {...props} />;
};
...

The orginal component doesn’t change. Extended only returns it with any original properties.

How to see this working

At this point, the code works. But, this type of change can be difficult to visualize. As mentioned earlier, the Redux DevTools Chrome extension. works best for me. In the demo I included the devtools snippet when creating the store. If you install the extension and view the Redux panel, you can see new reducers change the state tree.

To further show the results in the demo, I connected the record route to display record data from the store.

...
const mapStateToProps = (state, props) => {
  const { match: { params: { id } } } = props;

  return {
    recordId: id,
    record: state.records[id] || {}
  };
};

export default connect(mapStateToProps)(Record);

The full code is in /routes/Records/routes/Record.js.

A solution

As I mentioned earlier, this is a common need in React/Redux projects for different reasons. I’ve used other, similar methods for dynamic routes in the past. Other folks have different approaches. With that, this is a solution, not necessiarly the solution.

If this is helpful and you use it as-is or change it to fit your needs, let me know. There’s always room for improvement.

Thanks for reading

Quick note. This isn’t a general “How to make a PWA” post. It may not even be a good intro. There are plenty of articles and tutorials to get the basics. This post is specific to the work involved in making ColorMe a PWA.

In a lot of what I’ve read about PWAs, there’ve been common steps for building them. A simple-on-the-surface looking process. Here’s one list from Jeremy:

1. switch over to HTTPS,
2. add a JSON manifest file with your metacrap, and
3. add a service worker.

Jeremy Keith, “Progressing the Web.”

OK, that seems easy enough. Except that last step. That seems like it could be a lot to unpack. He does offer a disclaimer:

That last step can be tricky if you’re new to service workers, but it’s not unsurmountable.

I’ll ignore the service worker part of the process for now and focus on the first two items.

Using HTTPS

ColorMe already has HTTPS in place. I host it on S3 and serve it through CloudFront. I used Amazon’s Certificate Manager to add an SSL certificate. HTTPS is in place and has been since launch.

Adding a Manifest

This is where things got more interesting. I built ColorMe with Create React App (CRA) so I made a manifest.json file in the public directory. The same directory as the favicon and index.html. Anything in the public directory gets copied to the build directory as is. That’s what we need for manifest.json.

Doesn’t CRA do PWA stuff out of the box?

Yes. CRA added built-in support for PWAs in version 1.0.0. ColorMe is still on version 0.8.4. That was the latest version when I created the project and haven’t had a reason to update.

I could have updated CRA to use the built-in PWA, but I didn’t want to miss the opportunity to learn step-by-step. Doing this myself, taking the long, “dumb” way, helped internalize the why and the how of each step. On future CRA-built projects, I’ll use the latest version with built-in PWA support. With that out of the way, here’s all my “metacrap.”

I knew there was “stuff” that went in the manifest, but I wasn’t sure about specifics. What keys can I use? What are example values for each key? And what key-values am I supposed to have? The best resource I found for questions number one and two is the MDN Web App Manifest documentation. It lists available keys and example values.

Lighthouse

For the third question, I turned to Lighthouse audits in Chrome dev tools. Before adding anything to the manifest, I ran a PWA audit. It reported items needed to meet the minimum requirements for a PWA (according to the audit).

With the audit report as a starting point, I hit each item on the list. Most important, I referenced the manifest in the head of index.html. This uses the CRA-specific %PUBLIC_URL%.

<link rel="manifest" href="%PUBLIC_URL%/manifest.json">

Most items in the manifest are straightforward enough so I won’t go line-by-line. But I will call out a couple items that took a bit more work. You can see the complete file on GitHub and below:

{
  "background_color": "#ffffff",
  "theme_color": "#B50003",
  "display": "standalone",
  "short_name": "ColorMe",
  "name": "ColorMe",
  "start_url": "/",
  "icons": [
    {
      "src": "launcher-icon-48x48.png",
      "type": "image/png",
      "sizes": "48x48"
    },
    {
      "src": "launcher-icon-96x96.png",
      "type": "image/png",
      "sizes": "96x96"
    },
    {
      "src": "launcher-icon-192x192.png",
      "type": "image/png",
      "sizes": "192x192"
    },
    {
      "src": "launcher-icon-256x256.png",
      "type": "image/png",
      "sizes": "256x256"
    },
    {
      "src": "launcher-icon-384x384.png",
      "type": "image/png",
      "sizes": "384x384"
    },
    {
      "src": "launcher-icon-512x512.png",
      "type": "image/png",
      "sizes": "512x512"
    }
  ]
}

Icon sizes

As you can see in the manifiest, I included six different icon sizes. The audit requires two sizes; 192x192 and 512x512. The former for the homescreen icon on Android, the latter as an icon for a splash screen on Android.

I’m not sure if the other four sizes are necessary, but I saw those in examples so I figured it wouldn’t hurt to include them.

Theme color

A requirement–per the audit–was to add a theme-color meta tag to index.html:

<meta name="theme-color" content="#B50003">

The theme-color meta tag ensures that the address bar is branded when a user visits your site as a normal webpage.

noscript

Another failing audit was “Contains Some Content When JavaScript Is Not Available.” For that, I added noscript content. It doesn’t do anything except apologize for not working without JavaScript. It would be better to have some type of useful experience without JS, but I’ll save that for another time. It’s interesting to think how to make a site like this provide value without JavaScript.

“According to the audit”

I’m using specific language like; “per the audit” and “according to the audit” on purpose here. Some of these aren’t universal. For example, the theme_color property and the theme-color meta tag have no effect on Mobile Safari or Mobile Chrome on iOS as far as I can tell. For the purposes of this exercise, I’m working towards 100% on the audit. I’m sure not every project needs every item. As usual, it depends.

The Chrome Dev Tools Manifest Tab

Every time I’d make a change to the manifest I’d re-run the PWA audit to check the results. This was slow. I didn’t realize there was a tab in Chrome dev tools for inspecting the manifest.json results. I found it early enough in the process that it helped speed things along. It also has an “Add to homescreen” button to test that mechanism. That’s much appreciated because I don’t have access to an Android device for proper testing. I wrote this in case someone else also doesn’t know about the manifest tab in Google Chrome Dev Tools.

At this point I still don’t have a PWA. The audit turns up one last failure:

Failures: Site does not register a Service Worker, Manifest start_url is not cached by a Service Worker.

With the basics of the manifest in place, I turned my attention to the service worker.

The Service Worker

Like I mentioned above, this was the biggest mystery for me. I understood the general concept of service workers, but I didn’t understand what the goals of a service worker for a PWA were. Sure, it’s JS, it runs in the background, but what’s that JS supposed to do? After spending time with tutorials, examples, and fiddling, I got a clearer picture.

The goals of ColorMe’s service worker:

• Store the site’s static files–HTML, CSS, JavaScript, and images–in the window.caches object
• Intercept all network requests. If the name of the requested file is in window.caches, respond with the cached file instead of making a request to the server
• Delete stale caches when the cache key changes

One thing that stuck out early was the caches member on the global window scope. When I first saw caches in use in example service workers, I thought it was a global only in the service worker context. That’s not the case. window.caches is available from any JS.

Here’s a quick example of caches. Go to colorme.io. Open the developer console and run this snippet:

caches.keys().then(names => {console.log(names)});

That should output ["colorme-v7"] (the version number might be different). Not much to look at, but you can see that window.caches is a thing in this context. That means you can access caches from any client side JavaScript, not only service workers. That’s pretty cool.

Goal 1: Cache Static Files

For ColorMe to work offline it needs to cache all critical static files. It’s a single page site so there are only a few; index.html, main.css, main.js, manifest.json, an svg image, and a Google Fonts stylesheet.

The CRA build process creates or renames the CSS, JS, and image files. That made things difficult and I’ll describe my process for fixing it later. For now, I’ll pretend the file names are what they are and walk through the code.

I created service-worker.js in the public directory. The full file is available on GitHub.

const STATIC_CACHE_NAME = "colorme-v1";
const STATIC_URLS = [
  "/",
  "/index.html",
  "/manifest.json",
  "/static/css/main.css",
  "/static/js/main.js",
  "/static/media/bgTransparent.svg",
  "https://fonts.googleapis.com/css?family=Cousine:400|Karla:400,700"
];
self.addEventListener("install", event => {
  event.waitUntil(
    caches.open(STATIC_CACHE_NAME).then(cache => {
      return cache.addAll(STATIC_URLS);
    }).then(() => self.skipWaiting())
  );
});

STATIC_CACHE_NAME is a unique key for this cache. STATIC_URLS is the list of files to cache. I’ll explain how I update this list later to account for dynamic file names.

In broad strokes, the next lines say:

1. when the service worker finishes the install process,
2. find or create a cache with our name,
3. and put the files we specified in that cache.

There are full descriptions of the install event and waitUntil available. MDN is a great one.

Skip Waiting?

I’ve read docs about skipWaiting, but I’m still a bit hazy on what it does or if I even need it in this context. Enough examples I saw recommended it, so I went with it for now. I’ll learn more about it as I work with it.

With those lines, ColorMe’s static assets are snug in a cache. There’s still work to be done though.

Goal 2: Serve Cached Files

Putting static files in caches isn’t enough on its own. For ColorMe to work offline, we need to tell the browser to look in the cache for those files.

self.addEventListener("fetch", event => {
  event.respondWith(
    caches.match(event.request)
      .then(response => response || fetch(event.request))
  );
});

This snippet listens for all HTTP requests from the user’s browser. event.respondWith prevents the browser’s default fetch handling. That allows us to check if the requested URL–event.request–is in the cache. If it is, respond with the cached file. If it’s not cached, continue with the request to the server using fetch().

ColorMe now works with or without an Internet connection.

Goal 3: Delete Stale Caches

If I stopped here ColorMe works offline, but I’d have no way to release updates to users. Cached items have to be deleted, they never expire. The service worker should remove stale caches.

self.addEventListener("activate", event => {
  event.waitUntil(
    caches.keys().then(cacheNames => {
      return Promise.all(
        cacheNames
          .filter(name => name.includes("colorme") && name !== STATIC_CACHE_NAME)
          .map(name => caches.delete(name))
      )
    }).then(() => self.clients.claim())
  );
});

This is the most involved-looking code in the service worker, but it doesn’t do much.

1. get an array of all cache keys with caches.keys(),
2. remove any keys that don’t contain our name and remove a cache with the exact STATIC_CACHE_NAME,
3. for each of the remaining keys, delete that cache.

When the service worker activates–every time the page loads–check to see if there are stale caches. If there are, delete them. I determine if a cache is stale with #2 above.

In the first code snippet I defined the cache key; const STATIC_CACHE_NAME = "colorme-v1". When I make changes to any of the cached files and deploy the site, I also change that version number. If a user visited the site when colorme-v1 was latest, then visits again when colorme-v7 is the latest, the service worker deletes v1 and caches v7.

Caching Dynamic Filenames

At this point, I’ve met all the goals for ColorMe’s service worker and have a functioning PWA. If you visit ColorMe then turn off your network connection, you should be able to refresh the page and use it as normal.

There is one issue I mentioned above. The filenames for the CSS, JS, and image are incorrect. In the earlier snippet, I cached files named;

• "/static/css/main.css"
• "/static/js/main.js"
• "/static/media/bgTransparent.svg"

The CRA build process fingerprints those filenames to something like;

• "/static/css/main.2ebebc14.css"
• "/static/js/main.7e7a1a8f.js"
• "/static/media/bgTransparent.e6317315.svg"

This is common for cachebusting and not only for CRAs. I’ve used and built tons of different asset pipelines over the years that use fingerprinting.

I got hung up on this big time. How am I going to tell the service worker to cache files when I have no control over their names? I didn’t find much info on the topic. This issue raises the question and the discussion helped me figure out an approach. I’d need to somehow generate the list of filenames during the build process. I had a few options, a couple of them not good ones;

1. Run the CRA eject script and change the default webpack build process to generate the service worker
2. Update to latest CRA and use their built-in PWA support
3. Walk away from computer, sleep on it, think about a better solution the next morning while walking my dog

I didn’t want to eject from CRA, because it didn’t seem worth it. I mentioned above, updating to the latest CRA would take away the opportunity to learn. Option #3 sounded best. After getting away from the computer, I realized I had more options than I realized and a solution that should work. It was’t going to be elegant or scalable, but it’d do the job.

Piggybacking on the CRA build script

The default CRA build script builds the project according to the baked in webpack config. I can’t change the config–without ejecting–but I can add to the build script in package.json. I’d already modified the script to include NODE_PATH=src. That makes it easier to import modules without referencing the full path. ColorMe’s starting build script looked like:

NODE_PATH=src react-scripts build

I knew a couple things. I knew the build process creates a file named asset-manifest.json. The contents of that file include the full fingerprinted names of all static assets used in the site. Example contents of the manifest file:

{
  "main.css": "static/css/main.2ebebc14.css",
  "main.css.map": "static/css/main.2ebebc14.css.map",
  "main.js": "static/js/main.7e7a1a8f.js",
  "main.js.map": "static/js/main.7e7a1a8f.js.map",
  "static/media/bgTransparent.svg": "static/media/bgTransparent.e6317315.svg"
}

Those are the full filenames I need to cache with my service worker. I need to get those filenames into the service worker file.

The first thing I did was add to the build script. Back in package.json I updated the script to look like:

NODE_PATH=src react-scripts build && npm run generate-sw

This says; “run the normal build process, when you’re done with that run this other npm script”. That script looks like:

"generate-sw": "node scripts/generate-sw.js"

To make sure that worked, I created /scripts/generate-sw.js and added a single line; console.log('hello'). Then I ran the build script npm run build to make sure the project built and I saw “hello” in my terminal output. So far so good.

The generate script

I need to get the filenames out of asset-manifest.json and into the array of filenames to cache in service-worker.js. My plan was to not get fancy with this. I only need to take strings from one file and write them into another file. The fact that the target file is JavaScript is immaterial to this process.

The full file is available on GitHub and I’ll go through the code in detail here.

const manifest = require("../build/asset-manifest.json");
const fs = require("fs");
const swPath = "build/service-worker.js";

First is setup. asset-manifest is JSON so I require it here for use as an object. I’ll use the fs package for reading and writing files. I store the path of the service worker for convenience.

const manifest = require("../build/asset-manifest.json");
const fs = require("fs");
const swPath = "build/service-worker.js";
const urlsCSV = Object.keys(manifest)
  .filter(k => !k.includes(".map"))
  .map(k => manifest[k]);

Getting more interesting, but still not fancy. The goal of this chunk of code is to build an array of filenames. First, use Object.keys to get the keys from the manifest JSON to loop over an array.

Next, use filter to remove keys that include the string “.map.” If you look at asset-manifest.json you’ll see source maps. We don’t want to cache those. I’m not sure if there’s a best practice for or against that, but I decided it didn’t seem right for this project.

Now that we only have keys for the files we want to cache, use map to create the array of filenames stored as urlsCSV;

[
  "static/css/main.2ebebc14.css",
  "static/js/main.7e7a1a8f.js",
  "static/media/bgTransparent.e6317315.svg"
]

A short tangent. Given the code above, you might be asking; “why didn’t you just use Object.values instead of Object.keys plus map?” That’s a great question with a quick answer. As of this writing, I’m running Node.js version 6.9.1. Object.values is not supported without the --harmony flag until version 7.0.0. I didn’t want to upgrade Node.js for this. I’ll do that another time. That’s all.

I need to get that array of filenames into the service worker file. Again, this isn’t meant to be fancy or scalable. It’s meant to do the work.

const manifest = require('../build/asset-manifest.json');
const fs = require('fs');
const swPath = 'build/service-worker.js';
const urlsCSV = Object.keys(manifest)
  .filter(k => !k.includes('.map'))
  .map(k => manifest[k]);

fs.readFile(swPath, "utf8", (err, data) => {
  if (err) { return console.log("Error trying to read SW file", err); }

  const result = data.replace("%MANIFESTURLS%", JSON.stringify(urlsCSV));

  fs.writeFile(swPath, result, "utf8", err => {
    if (err) { return console.log("Error trying to write SW file", err); }
  });
});

Let’s break this down. First, open the service worker file (swPath) for reading. The error condition isn’t important. I included it to be nice to myself in case something odd happens during a build.

The next line is the point of this script. It searches the contents of the service worker file (data) for the unique string “%MANIFESTURLS%”. When found, it’s replaced with a JSON stringified version of our filenames array, urlsCSV. Then, the updated contents are written back to the service worker file.

Updates to service-worker.js

As mentioned above the generate script needs to find “%MANIFESTURLS%” in service-worker.js. I went back and updated the script to account for that.

const STATIC_CACHE_NAME = "colorme-v1";
const BASE_STATIC_URLS = [
  "/",
  "/index.html",
  "/manifest.json",
  "https://fonts.googleapis.com/css?family=Cousine:400|Karla:400,700"
];
const STATIC_URLS = BASE_STATIC_URLS.concat(JSON.parse('%MANIFESTURLS%'));

// The install handler is the same as when we started.
self.addEventListener("install", event => {
  event.waitUntil(
    caches.open(STATIC_CACHE_NAME).then(cache => {
      return cache.addAll(STATIC_URLS);
    }).then(() => self.skipWaiting())
  );
});

Here’s what I've done. I moved the filenames I know about to BASE_STATIC_URLS. I don’t fingerprint those file names, so they’re safe to hard-code. The important change is next. STATIC_URLS still ends up being an array of filenames, but now it’s a combination of two arrays. The filenames we know about and the generated array of filenames written to this file.

STATIC_URLS ends up looking something like this;

[
  "/",
  "/index.html",
  "/manifest.json",
  "https://fonts.googleapis.com/css?family=Cousine:400|Karla:400,700",
  "static/css/main.2ebebc14.css",
  "static/js/main.7e7a1a8f.js",
  "static/media/bgTransparent.e6317315.svg"
]

When the project builds the fingerprinted filenames and asset-manifest changes. Then the service worker gets updated with the new filenames.

That all adds up to a build process that handles caching of fingerprinted files and one offline-capable PWA.

A New Normal

I’ve seen folks talking at length about how transformative PWAs are, but I couldn’t grasp it until I went through this process. This felt like building a responsive design for the first time. It’s the realization that this isn’t going to be a gimmick or extra or nice-to-have. It’ll take time for habit to kick in and browsers to catch up, but this will become my default when building sites.

We were lucky. The founder and team all wanted to keep doing the work we all felt so close to. There’s a story behind that work that I plan to share in the future. Over the course of two months, we were able to rustle enough contract work to pay salaries for the team members that stuck around. We were hired back in late February 2017.

In that couple month span I was able to stop and breathe for the first time in two and half years. I got to work on fun side projects. And I was able to ruminate on things I wanted out of my work, career, and life.

Inspired by the loss of a job and the uncertainty and clarity that brings, my thoughts about want I wanted led towards one thing. I wanted to work on a business that I owned that I could help build from the ground up. I wasn’t sure what that business should be or how I’d go about it. Then I got an unexpected opportunity from a friend.

On Wednesday, September 13^th, 2017 Chris and I launched our new business, Limbo.

Chris visited New York from California during my two month “vacation” and invited me for a drink to catch up. We hadn’t seen each other since I’d last visted the Dary’s Berkeley home about a year before. At one point in our conversation about family and work and life he asked; “Can I pitch you an idea?” Of course. He then laid out the idea and business model for Limbo and asked, “are you interested in working on it with me?”

Chris and I met in 2008 when he interviewed me for a position at Arc90 ^(RIP). I ended up getting the job and staying there for five years. In that time, I got to work alongside him on Readability and Readlists and occasional other projects. I saw him conceive of and build Kindling–which stayed in business for close to a decade. Over the years I saw him do excellent work, make smart decisions, and in general be a great person to be around. Any time I had the chance to work with Chris or even just have a conversation over coffee, I jumped at it.

So when Chris comes to me and asks; “I have an idea, do you want to work on it with me?” I say “yes” because I know it’s going to be a great project.

As expected, Chris didn’t dissapoint this time around. The next day he emailed me what he had so far. It was a lot. He already had the project set up. He had wireframes and rough mocks. He even sent a spreadsheet full of projections and different business model scenarios. Real adult stuff.

So we got to work. Or more accurate, I got to work, he’d already been hard at it.

I was still working full-time at The Groundwork and wanted to keep a hard separation between it and Limbo. To do that, I worked on Limbo mornings, nights, and weekends. My schedule would usually go something like; get up, work on Limbo for 30 minutes or so. Switch to The Groundwork for the day. Stop in the early evening. Take a break. Eat food. Then hop back to Limbo and work until I couldn’t keep my eyes open. Repeat.

Weekdays were always more productive than weekends even with splitting my time. An occasional rainy Saturday or Sunday I’d get things done, but it’s tough for me to do more computering on the weekend. Too many other things I’d rather do including doing nothing.

And so it went like that for months. My schedule made it take longer to get to launch, but we were making progress every day and now it’s a real, live thing.

Unknown unknowns

The feedback we’ve received since launch has been overwhelmingly positive. So there’s something there but, this is a business so we can’t say for certain how things will shake out. The goal is for Limbo to be our full time–paying–jobs. We’re doing everything we can to get there.

If you’ve worked with me you know I take ownership of what I’m working on. Not only design and code aspects of what I’m doing. I like to get in there. Co-workers have described me as “vocal.” When I see things in projects or teams or organizations that I think could be better, I offer my thoughts, ideas, and help. This is the opportunity we’re making for ourselves. We get to ask all the questions. We get to make decisions about every aspect of the business in a way that reflects our values. This is a chance to make something positive and put it into the world.

One example of the decisions we’re making is around money. In our first conversation we discussed seeking funding versus bootstrapping. We’ve been around long enough and seen enough to know that seeking early outside investment often does not end well. We decided bootstrapping was the way to go. It’s not that we think VC is wrong, it just doesn’t feel right for us on this venture, at this time. We want to see if the business model is sustainable from the day one. Not work on it for years, then get to the common start-up point of “I guess it’s time to figure out how to make money?” We either offer enough value to make enough money or we don’t.

A huge thank you to everyone who’s helped us with Limbo so far. We’re fortunate to have friends who will take time out of their day to try things out, give us feedback, point us in new directions, and offer encouragement.

This feels like the cusp of something. This has the potential to be where we put our energy for years to come. Chris and I have helped design and build world class products for other smart people. Now we’ll see if we can build, nurture, and sustain a business for ourselves.

Thanks for reading.

I’m thinking about the time between late 2004 to sometime in 2008. That's the start of my time working with the Web and computers in any real capacity. Flash was still Macromedia Flash. It was pervasive and incredible.

Building websites with HTML and CSS in 2004 to 2007-ish was interesting, but limited. We made 760 pixel fixed-width pages with tiled background images and bad image-based type. And that’s only if you’d made the switch from table-based layouts. Many folks had not. CSS transitions and animations weren’t even on the radar. jQuery wasn't a thing. JavaScript was still considered a toy language for “DHTML” gimmicks by most.

Flash filled a need and did it well. It provided a path to design and publish web sites with as far out graphics and layouts as we could conjure. Being able to work outside the capabilities of browsers was helpful for someone like me. I had a traditional art background and still felt stifled by computer-based design tools and the limits of browsers of the day. Flash was a looser way to learn and develop digital design skills. At the time, making Flash sites was flat out more fun and exciting.

Movement and sound

Flash helped many of us learn timing, pacing, and rhythm. It helped us learn how to design to music. Sometimes real music, sometimes the songs in our heads. These concepts aren’t limited to animation. Through the years, I’ve folded motion design concepts into tons of static design. It’s one way to arrive at richer, more interesting designs. I realize this sounds esoteric, it is. It’s squishy, designer-feel stuff, but it often results in design that stirs emotion.

Working in Flash opened doors to designing with other mediums like audio. How many of you also used Audacity to create sound effects for use in .swfs? Homemade foley was a constant in my early Flash projects. It was fun and silly and great.

Sites like 2advanced.com displayed a breadth and depth to designing with motion and sound on the Web. At the time, you could not find that with sites built with web standards alone. Seeing what was possible opened eyes and removed barriers. If 2Advanced and others could do work like that, so could we. And later, when technology caught up, we learned we could do it without Flash.

These concepts and approaches we learned weren’t lost when we stopped using Flash. We rolled them along to CSS and JavaScript and iOS and Android. The rich motion we now expect from digital products is no doubt inspired and learned by earlier work done with Flash.

Typography

We would not have the typographic capabilities on the Web we have today if not for Flash. sIFR let us explore what was possible with custom type in web pages. There were no other options at the time. @font-face would not exist for a couple years. It would be more years still until it had wide enough browser support you could use it.

In this instance, Flash was a polyfill. Using Flash to embed custom fonts helped us learn what we wanted from typography on the Web. That knowledge informed specifications and browser vendors were then able to make the specs reality. This feels, to me, like the most day-to-day, “bread and butter” impact Flash had on the Web.

Learning to code

Everything in this post is from my perspective, but this section is 100% about my experience. Everyone who writes code learned in a different way. I learned to program using ActionScript 2.0 within Flash so I hold it in high regard. ActionScript was my introduction to basic programming concepts; variables, conditionals, loops, and functions. I took to it well I think because it was the first time I’d seen code tied to a fun end result. Write code, see something fun happen in a .swf. It was immediate and tangible so it stuck.

Writing ActionScript also taught me how to think in code and convince a computer to do what I wanted. Often times the convincing wasn’t done in an elegant way. I remember my final for an Advanced ActionScript course in college. I got half credit on one programming task because I made it work, but did so in some roundabout way. That’s representative of how I write code today. I may not always have the most elegant solution, but I'll get it done no matter what.

It’s really the humans

In Mike’s tweet he used “nostalgic.” I wasn’t sure at the time if I felt nostalgia about Flash or not.

a sentimental longing or wistful affection for the past, typically for a period or place with happy personal associations.

After thinking and writing about this, yes I do. I’m not nostalgic about the technology itself though. Flash, like all other technology, is a means to an end. Thinking about Flash reminds me of that time in my life. It reminds me of the work I was doing, the rush of new ideas, and the thrill of making new things. It reminds me of the people I was working with, most of whom I haven't spoken to in the years since. So yeah, I think I’ll always look back on that time with “wistful affection”.

We’re doing what we always do, moving on. We learn, we evolve, we evolve our tools. This is a good thing and a constant in our field. At the same time it’s important to witness and remember the steps in our evolution.

Even though it has a couple more years of life, Flash’s time has come and gone. Flash's positives far outweigh its negatives and its impact will persist for years after it’s gone.

Thanks for reading

The first updates I made I snuck in the day after release. Those were improvements to the color adjuster sliders for touch devices. Or more accurate, devices without hover support. I knew the initial design had usability issues on mobile, but decided to ship it and iterate.

The main problem was the horizontal scrolling interfering with the range sliders. The thumb of the sliders was too hard to get a hold of with a finger. And it was tough to adjust the slider instead of scrolling horizontal. For this first update I didn't change the UI completely for touch devices. For now I only increased the size of the thumb on the range sliders in this pull request.

By default the CSS targets all devices. The range slider thumb is large. Almost comical in size and off center vertically when active. It looks strange in a screenshot, but the larger size and y-offset make it easier to control when using a finger.

.adjusterValRange::-webkit-slider-thumb {
  ...
  height: 1.6rem;
  margin-top: -0.8rem;
  width: 1.6rem;
}

.adjusterValRange::-webkit-slider-thumb:hover,
.adjusterValRange::-webkit-slider-thumb:active {
  margin-top: -1.8rem;
  height: 2.5rem;
  width: 2.5rem;
}

To decrease the thumb size on devices with hover support , I used the hover media query available in Media Queries Level 4.

@media (hover) {
  .adjusterValRange::-webkit-slider-thumb {
    ...
    height: 0.75rem;
    margin-top: -0.3rem;
    width: 0.75rem;
  }

  .adjusterValRange::-webkit-slider-thumb:hover,
  .adjusterValRange::-webkit-slider-thumb:active {
    margin-top: -0.5rem;
    height: 1.1rem;
    width: 1.1rem;
  }
}

I’m a huge fan of using the hover media query instead of relying on screen size. The issue isn’t caused because the screen is too narrow. It’s caused by not having the fine control a mouse and cursor provide. The new media query isn’t available in all browsers yet, but support is good enough for these purposes.

You can see the full CSS for the adjuster range sliders in Adjuster.css.

Usability of the adjusters on touch devices still has room for improvement. There’s an open issue about it in the repo. Along with the ideas there, I have an alternate UI I’d like to try out. That will likely be the next round of changes I make to the project.

Red, green, and blue adjusters

In the first release I also left out three of the available color adjusters. Red, green, and blue. Those are in place now. They do what they say on package. Each one adjusts that single channel. Could be helpful for finding that perfect reddish-greenish-blue. Or for finding a good complementary color.

New supported formats

One of the first bits of feedback I got was from my coworker, Justin. He said ColorMe should support rrggbbaa colors for the base color. I’d never used them before so I took some time to educate myself. If they’re new to you too, read this post. Then play with them in ColorMe to get a better feel how they work. I’ve been using the alpha adjuster to go through each value to see what the percentage is in hex. It’s still taking me some time to think about alpha values as hex, but I'm a fan. You should give it a try if you haven’t already.

I also added support for hsl(a) base colors. This was a no-brainer. It just didn't make the cut for first release.

Choosing output color format

OK, this is a fun one! Also the one that required the most effort. A request I got was the ability to see the output color in hex or hsl(a) format instead of only rgb(a). This was also something I’d been wanting. So I took the idea and ran with it.

You now have the option to choose the format for the output color. There are up to seven different formats depending on the color. The full list of formats is; hex, hex shorthand, rrggbbaa, rrggbbaa shorthand, rgb(a), hsl(a), and keyword. Depending on the base color some of them are available and some aren’t.

When you choose a format, ColorMe will do its best to hold on to your selection. Sometimes though there's no way to display a color in a certain format. For example; say you enter the color red. The output format is "keyword". Now, say you adjust the alpha value to 90%. There is no hex or keyword format for the new color. In that case ColorMe switches to the rgba format. It also disables the hex, hex shorthand, rrggbbaa shorthand and keyword formats because those aren't available. In the UI, this just happen for you. React makes short work out of maintaining view layer updates. Behind the scenes there’s a lot of logic to determining what formats work for each color.

If you’re interested in that logic, have a look at the getColorFormats function in utils/color.js. The code there isn’t clever. Most of it is if statements representing what I knew should be true about each format. Because this type of logic can be brittle when making changes, I also wrote a battery of tests to let me know when I break things.

A bug fix and open-source sleuthing

As I was tinkering with the UI, I hit one of those voodoo, ghost-looking bugs. After fiddling with the knobs a while longer, I saw the pattern and was able to reproduce the issue.

When using the alpha adjuster with the tint, shade, or contrast adjusters, the alpha value was wrong. For example, this code;

color(red a(10%) tint(50%))

produced:

rgba(255, 128, 128, 0.19999999999999996)

when I expected it to produce:

rgba(255, 128, 128, 0.1)

First I made sure my code wasn't up to anything fishy. Then started looking at my dependencies. The unexpected results were coming from the the css-color-function package. To complicate things more, the problematic code didn't end in css-color-function. It was its use of another color package.

css-color-function uses the mix function of that color package for tint, shade, and contrast adjusters. The Color.mix function was ported from Sass. In Sass, the mix function not only mixes color channels, it also mixes the alpha channel.

The opacity of the colors is also considered when weighting the components.

From the Sass docs on the mix function

As far as I can tell, this isn't the intended behavior of the color function adjusters. For ColorMe, I forked css-color-function and modified its blend method. The problematic adjusters use that method. What I did was take the alpha value out of play before mixing colors. Then put it back when finished. Here's my updated version of the blend method:

exports.blend = function (color, args) {
  var targetAlpha = color.alpha();

  // Reset the alpha value to one. This is required because color.mix mixes
  // the alpha value as well as rgb values. For blend() purposes, that's not
  // what we want.
  color.alpha(1);

  var other = new Color(args[0].value);
  var percentage = 1 - parseInt(args[1].value, 10) / 100;

  // Finally set the alpha value of the mixed color to the target value.
  color.mix(other, percentage).alpha(targetAlpha);
};

ColorMe is now using my fork of css-color-function. I opened a pull request to get the changes the original fork. I also added more detail about the cause and solution in the description of that PR.

Pull requests beget pull requests

When I started pulling at this thread I found two other projects affected by it. I'm sure there are others. I opened a pull request in postcss-color-function and reported the problem in postcss-cssnext.

More to come

I had a lot fun with these updates, hope folks find them useful. As said I have more ideas for future ColorMe updates. And as always if you see issues or have ideas, open an issue.

Thanks for reading

The Color Function is a CSS feature in editor's draft stage of specification. This means it will be a while before it lands in any browser. That doesn't mean you can't use the proposed syntax today though. You can use the color function PostCSS plugin. That plugin is also included in cssnext if you want access to more future-facing CSS. The plugin uses the css-color-function package for its parsing and converting.

I wrote about switching this site to PostCSS. That was my first encounter with the color function. After years of using color transform functions in Sass it's easy to see how powerful a native CSS color function will be.

There are more detailed articles about the color function. I'll give a brief overview of it here. On its own, color doesn't do anything with the given base color:

color(#ea3333) /* output is the same as input */

The power of the function is in adjusters. These are transformations applied to the base color. The current draft spec lists 15 available adjusters; alpha, rgb, red, green, blue, hue, saturation, lightness, whiteness, blackness, tint, shade, blend, blenda, and contrast.

The color function allows you to apply one or more adjusters to the given base color:

color(#ea3333 alpha(90%) saturation(75%) shade(20%)) /* rgba(182, 47, 47, 0.9) */

Many of the adjusters also have short names:

color(#ea3333 a(90%) s(75%) shade(20%)) /* rgba(182, 47, 47, 0.9) */

Like Sass, using the CSS Color Function in code can be difficult visualize. Colors are easier to work with when you can see them. That's why SassMe is so darn useful. And that's why I thought we needed the same for CSS.

Building It

ColorMe is a React app. I used the wonderful create-react-app to get started.

Before getting any UI in place I needed to see a first thing work. I needed to convert color function strings to rgb(a) strings. For that I used the css-color-function package. I started by importing the package and logging results of its use:

import colorFn from 'css-color-function';
console.log(colorFn.convert('color(red alpha(50%))')); // rgba(255, 0, 0, 0.5)

No major breakthrough, but that's how I get myself going. Just get one win no matter how small. From there it was a matter of building up functionality piece by piece.

The workhorse of the project is the color utils. All color calculations happen there. When you enter a base color, the app breaks it apart into individual color properties. Those properties are initial values for the adjusters. I used this color package to parse the base color string.

Because the color utils do so much I took the time to write decent test coverage. Writing tests isn't something I jump at doing (read as: I get distracted, just wanna draw pictures, or go outside, or anything else. Please don't make me write tests!). But it felt necessary for this and did save me a few headaches during refactoring.

Deploying It

When I'm ready to release updates to ColorMe I run npm run release. That command creates a new Git tag and pushes it to GitHub. Travis then runs the tests. When Travis sees the build is for a tag it executes deploy.sh. That script does a production-ready build with npm run build and then syncs the artifacts to AWS S3. This is a similar build process that I wrote about in more detail in “Rewriting Day Player for Sketch 40+”.

Try it out

It's still early days for the CSS Color Function. It's a promising feature with momentum behind it. My hope is that more folks will start using it and giving feedback. We'll see the spec continue to evolve and sooner or later get implemented by browsers.

Take ColorMe for a spin. If you find bugs or have ideas, feel free to add issues.

Thanks for reading

The first step I took was an inventory of my Sass usage. I needed to know what features I was using to make sure I found a replacement in the new setup. Here's a list of what I was using on this project:

• partial imports
• variables
• nesting
• mixins
• extend
• placeholder classes
• darken and rgba color functions
• compression

Preparing

Before getting to new syntax or other fun I needed to do some yak shaving. The project was using a file structure typical for Sass usage. I used the leading underscore naming convention for partials. And included the required scss extension. I used two directories to loosely organize Sass files. modules housed Sass that didn't produce CSS. Things like variables, placeholder classes, and mixins. partials housed all CSS-producing Sass.

This was the beginning file structure:

css/
  scss/
    modules/
      _module.scss
      ...
    partials/
      _partial.scss
      ...
    tylergaw.scss

Each Sass partial gets imported in tylergaw.scss.

@import "modules/setup";
@import "modules/reset";
@import "modules/fonts";

I reorganized and renamed the files. I first changed the extension from scss to css. Instead of doing it a file at a time, I used a Bash script:

for f in *.scss; do git mv -- "$f" "${f%.scss}.css"; done;

Because the leading underscore is from the Sass world I also removed that. I couldn't figure a way to do it with Bash so I removed it from each file by hand. (note to self; learn how to Bash better)

The last step was to move all the CSS files to the modules directory and remove the partials directory. I decided referring to all CSS as modules made more sense than trying to split them along the modules/partials line.

Build setup

I started with the PostCSS CLI. I added a temporary build script to package.json:

"scripts": {
  "postcss": "postcss -o public/css/tylergaw.css src/css/tylergaw.css"
}

Without changing any styles I compiled the CSS:

npm run postcss

It worked! Sorta. I didn't get errors in the console, but it left me with a naked page on the wrong day.

With the build process functional I could now work to get the styles back in order.

Looking at the console in Chrome I saw a stack of 404s. This revealed the first missing feature; @import inlining. tylergaw.css contains only @imports for each CSS module. The browser saw those and did what it knows to do. It attempted to load each module via an HTTP request. My build process only copies the single CSS file, not each module. Because of that, the browser couldn't find them.

I could change the build process to make default @imports work, but that would be inefficient. I needed a replacement for Sass style @import inlining.

The first plugin

To get Sass-style @imports I used the postcss-import plugin. After installing the module via npm I updated the build script to use it:

"scripts": {
  "postcss": "postcss -u postcss-import -o public/css/tylergaw.css src/css/tylergaw.css"
}

And ran the script again with npm run postcss. The single CSS file contains all the modules and the site now has partial styling.

Will this be in a future CSS?

The inlining of @imports was huge when it showed up in Sass. It's changed how we're able to organize styles for the better. I'm not sure this functionality will ever be native in though. It seems like we'll always need a build step for this type of functionality. Which doesn't seem all that bad.

I imagine the postcss-import plugin will be a staple for all my future PostCSS setups. My guess is this will be true for other folks too. This quote from the plugin author sounds right on:

This plugin should probably be used as the first plugin of your list. This way, other plugins will work on the AST as if there were only a single file to process, and will probably work as you can expect.

postcss-import

cssnext

cssnext is a PostCSS plugin for compiling future CSS syntax to syntax that works today. It's important to note that it's not a different language like Sass or Less. The features it offers are in-progress CSS specs. Some for features already showing up in browsers today. Others in beginning stages of the specification process.

I used cssnext to fill in the rest of the gaps left by missing Sass features.

Vendor prefixes

I built this site before I knew about Autoprefixer. I used custom Sass mixins to handle adding the needed prefixes. cssnext includes Autoprefixer, so I was able to remove that entire mixins module.

Variables

Next I changed the Sass variables to CSS custom properties. In _setup.scss I had:

$grey: #1e1e1d;
$yellow: #ffad15;
$offwhite: #f8f8f8;
$darkerwhite: darken($offwhite, 15);

This isn't all the Sass vars I was using, but it's the main ones. The rest are in individual modules.

Note: The “custom properties” vs. “variables” distinction. CSS custom properties are only valid for property values. They can't be used in selectors, property names, or media query values.

The updated setup.css:

:root {
  --white: #fff;
  --grey: #1e1e1d;
  --accent: #ffad15;
  --offwhite: #f8f8f8;
  ...
}

and an example of updated usage:

a {
  color: var(--accent);
}

Apart from syntax, CSS custom properties work the same as Sass variables. Because of limited browser support, properties are still compiled out. In the above example, the compiled value is color: #ffad15.

Color functions

In the previous example, I left out one variable; $darkerwhite: darken($offwhite, 15);. This is another Sass feature I needed a replacement for. There's a draft spec for a CSS color function. cssnext includes this function today and it's super cool. Here's setup.css with a darkerwhite custom property created with the color function and shade adjuster:

:root {
  ...
  --offwhite: #f8f8f8;
  --darkerwhite: color(var(--offwhite) shade(20%));
  ...
}

The color function provides a bunch of adjusters. You can use multiple adjusters in a single usage:

background-color: color(#d32c3f shade(40%) alpha(40%));

compiles to:

background-color: rgba(127, 26, 38, 0.4);

To reiterate. Right now cssnext compiles the result of color() to hex or rgba values. When the color function arrives in browsers, the compilation won't be necessary. The color manipulation can happen at runtime.

Nesting

Nesting is an indispensable feature introduced by CSS preprocessors. A must for any comfortable styling setup. Tab Atkins has a spec in-progress for CSS nesting and cssnext makes it available today.

This was mostly legwork. The CSS syntax for nesting includes a leading & before nested blocks. For example, the following is a Sass snippet from my Projects page:

.projects-list {
  ...

  li {
    & > div {...}
  }

  a {
    ...

    &:hover,
    &:focus {...}

    &::after {...}
  }

  @media (min-width: 640px) {...}
}

For CSS nesting, I changed that to:

.projects-list {
  ...

  & li {
    & > div {...}
  }

  & a {
    ...

    &:hover,
    &:focus {...}

    &::after {...}
  }

  @media (min-width: 640px) {...}
}

Basic nesting requires the leading &. Pseudo classes and selectors are the same in Sass and CSS. Media queries don't need a leading &.

Also worth noting is @nest. As mentioned in the docs, complex nesting requires @nest instead of &. I didn't have any use cases for it on this project, but may in the future.

Extend and Placeholder classes

I was using Sass @extend and placeholder classes for common styles. Here's an example usage responsible for styling Futura headings:

%futura {
  font-family: 'futura-pt', helvetica, sans-serif;
}

%futura-heading {
  @extend %futura;
  font-weight: 700;
  line-height: 1.1;
  text-transform: uppercase;
}

and an example usage:

.my-heading {
  @extend %futura-heading;
}

We looked at CSS custom properties usage earlier. There's a related in-progress spec for the @apply rule. @apply allows you to store a set of properties and reference them in selectors. I used @apply in place of Sass's extend.

Back in setup.css I added the updated Futura heading properties:

:root {
  ...

  --franklin: {
    font-family: 'futura-pt', helvetica, sans-serif;
  };

  --franklin-heading: {
    @apply --franklin;
    font-weight: 700;
    line-height: 1.1;
    text-transform: uppercase;
  };
}

and an example usage:

.my-heading {
  @apply --franklin-heading;
}

@apply is not extend. In the current form in cssnext, @apply copies the properties and values to each rule. This is a small project so that's OK. On larger projects the extra properties may cause too much bloat. At that time it would probably be best to use a common class name to get similar results.

At this point I had the site looking as it did before the changes. The Projects page was an exception. On it I used a different color for each project tile. Next I'll describe how styling that correctly without Sass required more work and more typing.

Mixins with arguments

To make writing the projects styles easier I used a Sass mixin. The mixin took a single argument, the color for the tile. Here's the project-block mixin:

@mixin project-block ($c) {
  background-color: $c;

  a {
    color: $c;

    &:hover {
      background-color: $c;
      color: $offwhite);
    }
  }
}

and example usage:

.p-jribbble {
  @include project-block(#ff0066);
}

At the time of this writing, I couldn't find a way to mimic this functionality in CSS. Custom property sets with @apply aren't functions, so you can't pass them arguments. In the future, it might be possible to use custom selectors for argument magic. The draft spec has a complex example that looks promising. Right now, I'll admit, I don't fully understand how it works.

That didn't mean I was out of luck. The CSS I write is longer than the Sass, but not by much. I also made use of another in-progress CSS feature; the matches selector.

Here's an example of the CSS replacement for the project-block mixin:

.p-jribbble,
.p-jribbble a:matches(:hover, :focus) {
  background-color: var(--color-jrb);

  & a {
    color: var(--color-jrb);
  }
}

The color variables are in a :root scope earlier in the file. cssnext compiles the above CSS to:

.p-jribbble,
.p-jribbble a:hover,
.p-jribbble a:focus {
  background-color: #ff0066
}

.p-jribbble a,
.p-jribbble a:hover a,
.p-jribbble a:focus a {
  color: #ff0066;
}

The last two selectors ...a a:hover and ...a a:focus won't match any elements. They're unecessary, but aside from a few more bytes they don't hurt anything. I preferred nesting the a selector for code readability.

More PostCSS

With the styles back in proper order, I decided to take advantage of more PostCSS plugins. I used css mqpacker to combine media queries that share the same query. I also used cssnano for code optimization.

This is where I'm looking forward to using a PostCSS setup. With Sass I felt locked in to the features in the current version. Because PostCSS works as a collection of plugins, it's extendible. If I have a specific need, I can write a plugin for it. The potential there is exciting.

I'm sold

After working with this setup for a few days, I'm all in. Making the switch from Sass syntax to new CSS syntax has been easy. And that's after five or six years of using Sass on every project I worked on.

I enjoy the shift in thinking this brings. cssnext has a similar approach to CSS as Babel has to JavaScript. They both allow you to write the language as it is and as it will be in the future.

Thanks for reading

Day Player has a limited scope. It requests images from placeholder image services and places them in Sketch documents. This 3.0.0 rewrite and release hasn't changed the scope. I did end up cutting two features and adding a new one.

What got removed?

The first feature cut was the placeholder service Lorempixel.com. I removed it because it doesn't support https. Day Player doesn't transport sensitive data. Still, I decided not to use services without https support.

The second feature cut was remembering user values for each service. I cut this for time. I didn't want to hold up the release for a non-essential feature. There's a good chance I'll circle back and add this in the future. Or, if you're feeling up to it, open a pull request.

What’s new?

The one new feature is the ability to add an image with the same dimensions and position as an existing layer.

I added this because of a user request. While it's not exactly what the user was asking for, it feels close enough to get the job done. And, as a user myself, it's a welcome addition.

What’s next?

As expected, within a day or two of release, I got the first “this doesn't work” issue. After a quick back and forth, it seems we've isolated the problem to macOS Sierra. I'm a slow new adopter, so I still haven't reproduced the issue. Sooner than later I'll update a machine and find and fix what's broken. If you have any tips for what may have changed, let me know here or on that issue.

How do you build and release this?

So glad you asked. This is a topic I want to write in more detail about in the future because it's fun, but I'll give a few highlights now.

Building

I'm not using Babel or any other code transmogrifying. I write in the JavaScript available in JavaScriptCore. In my day-to-day JS I use Babel and enjoy using ES2015+ features. With the current JSCore we have access to a limited set of new features. We can use const (but not let). Template literals are available to make short work of string munging. And that's about it. No arrow functions or other niceties yet. They'll get there. As I do more plugin development, I'll likely update my build tooling to use Babel.

Sketch plugins give you access to the Cocoa Framework. This allows you to write JS to create and interact with Cocoa elements. If you've ever written code to do this, you know that it doesn't have the smoothest API. A fun aspect of Day Player was writing components to act as facades for each Cocoa element needed. These components allow me to write more idiomatic code. They also allow for writing less code and provide a chainable interface.

For example, here's the code required to create a text label using regular Cocoa:

const textField = NSTextField.alloc().initWithFrame(NSMakeRect(0, 0, 350, 16));
textField.setDrawsBackground(false);
textField.setEditable(false);
textField.setBezeled(false);
textField.setSelectable(true);
textField.setStringValue('My Label:');

and the code required using the Label component:

new Label({
  value: 'My Label:'
});

Each image service has similar options. Because of this, I was able to abstract common setup code to a few functions. Those functions live in utils.js. Utils.js also includes comments describing my learning process with the excellent and in-progress Sketch JS API.

Releasing

Installing Day Player takes 3 steps; download, unzip, double-click. It was important to make that process as easy as possible. I want the user to use the plugin, not spend time figuring out how to get it.

As as plugin author, it's also important that the release process is as painless as possible. The release process works by chaining 5 primary tools together. Make, Node.js, Git, Travis CI, and AWS S3.

Here's how it works. When I'm ready to ship a new release I update the version in package.json. I then run make release. That in turn uses Node.js to execute the release.js script. I could run node scripts/release.js directly, but I prefer to put it in a Make target so all build commands are in one place.

Release.js first confirms I want to release. I put this in as check to keep myself from releasing an incorrect version. The script then creates a new Git tag and pushes it to the origin at GitHub. At this point, the process is on autopilot.

Travis CI now takes over. In travis.yml we have the following:

deploy:
- provider: script
  script: make publish
  on:
    tags: true

This tells Travis to watch for builds that create new Git tags. When it sees a tag it should run make publish after all other tasks are complete.

The publish Make target handles packaging the plugin and uploading it to S3. It first creates a zip file of the Sketch plugin bundle. Then using the AWS CLI, copies the zip file to the Day Player bucket; s3://day-player.

Interacting with AWS CLI in this way requires extra setup. First, we install the tool during the Travis install step.

install:
- pip install --user -U awscli

The next steps ensure Travis can make safe requests to AWS on my behalf. I set two environment variables in the travis conf. AWS_ACCESS_KEY_ID and an encrypted value for the secure key. The encrypted key:value is for the AWS_SECRET_ACCESS_KEY. The access key is not sensitive, so it's OK to be out in the open. The secret is for my eyes only. I used the Travis CLI tool to encrypt that value. You can read about that process in the Travis docs.

By default, the AWS CLI tool looks for the environment variables set above. Requests use them for authentication if found.

You may be wondering where the AWS access key and secret come from. This is an area where I use a best practice for handling AWS credentials. I've set up an AWS IAM Role that only has permission to upload objects to the Day Player S3 bucket. Setting up a restricted IAM Role is outside the scope of this post. A Google search for “IAM role for single bucket” returns up-to-date articles on the topic. That's how I figured it out for this process.

All this for placeholder images?

Yeah! This is a side project and my side projects are for learning, tinkering, and fun. If I also build things that are useful to other folks at the same time, that makes it even better.

Download Day Player 3.0.

Thanks for reading

Web folks–especially those of us working on the front-end of things–tend to be a bit consumed by tools and process. I sometimes get fatigued by the near constant chatter of new frameworks, build tools, package managers, plugins and on and on. I enjoy those tools and their benefits, but when I get worn down by them I need something to help pull me up and remind me why I love working on the Web. Our tools and processes are just means. I needed to work on something that would allow me to focus 100% on the end. Where the code creating it was unimportant. Where I could do things the long, hard, stupid way. And where I could bend and break best practices. That’s what I set out to do with what became Overawe.

What is this?

I’m no stranger to using HTML/CSS to build projects that exist a bit outside the norm. Until now I’ve considered these projects “experiments”. They seemed like a way to try out new–at the time–CSS features. I think I’m beyond that point. Things like CSS animations are here to stay. With Overawe–and other projects like it I’ll do–I’m not experimenting with CSS anymore. I’m choosing the web as my preferred medium for creating art. HTML, CSS, and JavaScript are my paintbrushes and web browsers are my canvases. And how cool is that? There's not a single, fixed size, always-the-same canvas. Each browser and each operating system and each computer that runs Overawe will run it a bit different. This is due to feature implementation, processor strength, etc. It’s also different based on each viewers' preferences. What size is their screen? Are they running their browser in full screen or presentation mode? Do they have a slow network connection? Do they have a bunch of other programs running that will cause Overawe to stutter?

For each one of the questions and many others, there is an effect on the project and how each viewer experiences it. I think that's incredible. Some people will hate it because it doesn't appear to do anything. For some it will run the same as it does for me on my local development server. I have no control over it and that makes it fun.

Where did this come from?

The idea for the format came from those cool MTV identities. You know, the short clips they play between segments. If you're not familiar, here’s an hour of them . I wanted to make something similar by pairing graphics with short audio clips. Each section is independent of the others. With some of them I have an idea about what it means and what I’m saying with it. Others, I made just because they give me chuckle.

Coming up with each section would be sporadic. Sometimes I would sit down and just start writing words and phrases that popped into my head. Other times I would be walking or taking shower or just doing other things and an idea for a section would come into my head. The process was loose. Once I had a phrase or an idea I'd hop into Photoshop and just play. I tried not to spend too much time on any one section. I would just throw together text and images and apply whichever styles and filters felt right at the time. I didn't worry about “mistakes”. Because this project was about creating a little world of it's own, there are no mistakes. Whatever ended up on the screen was supposed to be there in that form.

How did you do this?

While I don’t want this article or poject to be defined by the means of creation, I do want them to be available to anyone curious. As with most of my projects, you can access the source code on Github. All the animations are done using CSS. I did make use of the Web Audio API to fiddle with the audio clips. Each one is different, but I do things like speed up or slow down playback, add distortion, and apply high and low band filters. This is another area that gets interesting in different browsers. The Web Audio API is implemented different across browsers so the audio sounds different depending on which one you're using.

This was a lot of fun. Any time I get to sit down and create my own little world is good time. If no other person saw this but me, it’s still served it’s purpose. It allowed me to just make a thing without the normal internal debates about if I was doing every little thing the "right" way. I encourage everyone to do the same regardless of the medium.

http://lab.tylergaw.com/overawe
https://github.com/tylergaw/overawe

Thanks for reading

WWDC 2014 included a session on JavaScript for Automation. The session explained that you would be able to use JavaScript in place of AppleScript to automate applications. That alone is exciting news. Being able to automate repetitive tasks using AppleScript has been around a long time. AppleScript is not the most fun thing to write so using a familiar syntax in its place is welcome.

During the session the presenter explains the Objective-C bridge. This is where things get super cool. The bridge allows you to import any Objective-C framework into JS applications. For example, if you want to build a GUI using standard OS X controls you would import Cocoa:

ObjC.import("Cocoa");

The Foundation framework does what its name suggests. It provides the building blocks for OS X apps. The framework includes a large amount of classes and protocols. NSArray, NSURL, NSUserNotification, and so on. You may not be familiar with those classes, but their names hint at what they do. Because of its importance, you can use its classes without needing to import it in new apps. They are available by default.

As far as I can tell, you can use JavaScript to build anything that you can with Objective-C or Swift.

Building an example app

Note: You need Yosemite Developer Preview 7+ for the examples to work.

The best way to get going is to jump in and build something. I’m going to walk through building a small app that lets you display an image from your computer.

You can download the completed example from my example apps repo.

Making up the app is; a window, text label, text input, and button. Or by their class names; NSWindow, NSTextField, NSTextField, and NSButton.

Clicking the Choose an Image button will show an NSOpenPanel that allows you to select a file. We’ll configure the panel to restrict the file selection to .jpg, .png, or .gif.

After selecting an image, we'll display it in the window. The window will resize to match the width and height of the image plus the height of the controls. We’ll also set a minimum width and height for the window to make sure the controls don’t get cut off.

Setting up the project

Open the Apple Script Editor application located in Applications > Utilities. Script Editor ain’t the best editor I’ve ever used, but it’s necessary for now. It has a bunch of features that we need for building JS OS X apps. I’m not sure what goes on beyond the scenes, but it can compile and run your scripts as apps. It also creates extra stuff that we need like an Info.plist file. My guess is there are ways to make other editors do the same, but I haven’t looked into it yet.

Create a new document with File > New or cmd + n. The first thing we need to do is save the document as an application. Save with File > Save or cmd + s. Don’t confirm the save right away. There are two options that are necessary to make this run as an application.

Change the File Format to “Application”. Check the “Stay open after run handler” option. It’s important to set both of these options the first time you save the file because–as far as I can tell–there is no way to set them later. If you miss one of these you’ll have to create a new document and copy your code over.

If anyone knows a way to change the settings after creation, let me know.

If you don’t select “Stay open after run handler” your app will open, flash for a split second, and then close. There is not much in the way of documentation for this stuff online. I only learned this detail after hours of forehead/keyboard merging.

Let’s make something do something!

Add the following two lines to your script and then run it with Script > Run Application or opt + cmd + r.

ObjC.import("Cocoa");
$.NSLog("Hi everybody!");

Not much happened. The only visible changes are in the menu bar and dock. The app name along with File and Edit menus are in the menu bar. You can see the app is running because its icon is in your dock.

Where is the “Hi everybody!”? What is with the dollar sign, what is this, jQuery? Quit the app with File > Quit or cmd + q and we’ll find out where that NSLog went.

Open the Console app: Applications > Utilities > Console. Every application can log messages to the console. This console is not much different than Developer Tools in Chrome, Safari, or Firefox. The main difference is you use it for debugging applications instead of websites.

There’s a lot of messages in the console. You can filter it down by typing “applet” into the search field in the top right corner. Leave “applet” in the search field and go back to Script Editor. Run the application again with opt + cmd + r.

Did you see it!? The message “Hi everybody!” should have logged to the console. If you didn’t see it, quit your application and run it again. A lot of times I forget to quit and the code doesn’t run again.

What about the dollar sign?

The dollar sign is your access to the Objective-C bridge. Any time you need to access an Objective-c class or constant, you use $.foo or ObjC.foo. There are a couple of other ways to use $ that I’ll cover later.

Console App and NSLog are indispensable tools, you’ll use them non-stop for debugging. For examples of logging things other than strings, have a look at my NSLog example.

Creating the window

Let’s make something we can see and interact with. Update your script to look like the following code:

ObjC.import("Cocoa");

var styleMask = $.NSTitledWindowMask | $.NSClosableWindowMask | $.NSMiniaturizableWindowMask;
var windowHeight = 85;
var windowWidth = 600;
var ctrlsHeight = 80;
var minWidth = 400;
var minHeight = 340;
var window = $.NSWindow.alloc.initWithContentRectStyleMaskBackingDefer(
  $.NSMakeRect(0, 0, windowWidth, windowHeight),
  styleMask,
  $.NSBackingStoreBuffered,
  false
);

window.center;
window.title = "Choose and Display Image";
window.makeKeyAndOrderFront(window);

When that’s in place, run the app. opt + cmd + r. Now we’re talking! With a small amount of code we’ve built an app that launches a window with a title that we can move, minimize, and close.

If you’ve never built an app with Objective-C or Cocoa–like me–parts of this might look like a lot of gibberish. For me, that was due to the length of the method names. I enjoy descriptive names, but Cocoa takes it to the extreme.

Looking past that though, this is JavaScript. This code looks just like code you’d write when building a website.

What’s going on with that first new line where we set styleMask? You use style masks to configure windows. Each style option says what it adds; a title, a close button, a minimize button. These options are constants. Use a pipe “|” to separate options. That pipe is a C bitwise OR operator. I’m not gonna pretend to know what that means. I just know it’s needed to combine style options for a mask and that’s good enough for me.

There are more style options. You can read about them in the docs. NSResizableWindowMask is one you’ll use. Try adding it to the style mask to see what it does.

There are a couple interesting things about syntax that you’ll need to remember. $.NSWindow.alloc calls the alloc method of NSWindow. Notice there are no parenthesis “()” after alloc. In JavaScript that’s how we access properties, not how we call a methods. What’s with that? In JS for OS X parenthesis are only allowed when calling a method if you pass arguments to it. If you use parenthesis with no arguments, you will get a runtime error. Check Console for errors when things don’t do what you think they should.

The next thing is about that super long method name:

initWithContentRectStyleMaskBackingDefer

Take a look at the NSWindow docs for that method and you’ll notice it looks a bit different.

initWithContentRect:styleMask:backing:defer:

In Objective-C you would create the same window we did like this:

NSWindow* window [[NSWindow alloc]
  initWithContentRect: NSMakeRect(0, 0, windowWidth, windowHeight)
  styleMask: styleMask,
  backing: NSBackingStoreBuffered
  defer: NO];

The thing to note are the colons “:” in the original method signature. When you convert and Objective-C method to JS you remove the colons and capitalize the first letter following it. When you see two items in brackets “[]”, that is calling a method of a class or object. [NSWindow alloc] calls the alloc method of NSWindow. For JS, convert those to dot-notation and parenthesis if necessary; NSWindow.alloc.

I think the rest of the code to create and display the window is straightforward-enough. I’ll skip any more detailed description of it. It takes time and a lot of reading the docs to understand what’s happening for each step along the way, but you’ll get there. As long as the window is showing up you’re doing great. Let’s do more.

Adding the controls

We need a label, text field, and button in this window. We’ll use NSTextField and NSButton to make that happen. Update your script with the following code and then run the app.

ObjC.import("Cocoa");

var styleMask = $.NSTitledWindowMask | $.NSClosableWindowMask | $.NSMiniaturizableWindowMask;
var windowHeight = 85;
var windowWidth = 600;
var ctrlsHeight = 80;
var minWidth = 400;
var minHeight = 340;
var window = $.NSWindow.alloc.initWithContentRectStyleMaskBackingDefer(
  $.NSMakeRect(0, 0, windowWidth, windowHeight),
  styleMask,
  $.NSBackingStoreBuffered,
  false
);

var textFieldLabel = $.NSTextField.alloc.initWithFrame($.NSMakeRect(25, (windowHeight - 40), 200, 24));
textFieldLabel.stringValue = "Image: (jpg, png, or gif)";
textFieldLabel.drawsBackground = false;
textFieldLabel.editable = false;
textFieldLabel.bezeled = false;
textFieldLabel.selectable = true;

var textField = $.NSTextField.alloc.initWithFrame($.NSMakeRect(25, (windowHeight - 60), 205, 24));
textField.editable = false;

var btn = $.NSButton.alloc.initWithFrame($.NSMakeRect(230, (windowHeight - 62), 150, 25));
btn.title = "Choose an Image...";
btn.bezelStyle = $.NSRoundedBezelStyle;
btn.buttonType = $.NSMomentaryLightButton;

window.contentView.addSubview(textFieldLabel);
window.contentView.addSubview(textField);
window.contentView.addSubview(btn);

window.center;
window.title = "Choose and Display Image";
window.makeKeyAndOrderFront(window);

If things worked you’ll now have a window with controls. You can’t type in the text field and the button doesn’t do anything, but hey, we’re getting somewhere.

What did we do in that addition? textFieldLabel and textField are similar. They’re both instances of NSTextField. We make them in a similar way as we made the window. When you see initWithFrame and NSMakeRect, it’s a good sign that the script is creating a UI element. NSMakeRect does what it says. It makes a rectangle with the given position and dimensions; (x, y, width, height). That creates what’s called a struct in Objective-C. In JavaScript we’d refer to it as an object or hash or maybe dict. It’s a thing with keys and values.

After creating the text fields we set a handful of properties on each to get the results we’re looking for. Cocoa doesn’t have anything like the html label element. For that we make our own by disabling editing and background styling.

We’ll populate the text field programmatically, so we disable editing on it as well. If we didn’t need that, creating a standard text field is a one-liner.

For the button we use NSButton. Like the text fields, creating it requires drawing a rectangle. There are two properties that stand out; bezelStyle and buttonType. The values for both are constants. These properties control how the button will render and the style it will have. Check out the NSButton docs to see everything you can do with it. I also have an example app that shows the different button types and styles in action.

The last new thing we do is add the elements to the window with addSubview. When I first tried this I did window.addSubview(theView). That works for other standard views that you create with NSView, but not for instances of NSWindow. I’m not sure why that is, but for windows you need to add sub views to the contentView. The docs describe it as; “The highest accessible NSView object in the window’s view hierarchy”. Works for me.

Making the button do something

When clicking the Choose an Image button, we want a panel to open that shows files on our computer. Before we do that, let’s warm up by logging a message to the console when clicking the button.

In JavaScript you bind event listeners to elements to handle clicks. Objective-C doesn’t use quite that same concept. It has what’s called message passing. With it, you send a message containing a method name to an object. That object needs to have information about what to do when it receives a message containing the method name. That may not be a spot-on description, but it’s how I understand it.

The first thing we need to do is set the button target and action. The target is the object we want to send the action to. If this doesn’t make sense now, just keep going and it’ll get more clear when you see the code. Update the button setup part of the script with the following properties.

...
btn.target = appDelegate;
btn.action = "btnClickHandler";
...

appDelegate and btnClickHandler don’t exist yet. We need to make them. In the next addition to the script, order matters. I put comments in the following code to show where you should add the new stuff.

ObjC.import("Cocoa");

// New stuff
ObjC.registerSubclass({
  name: "AppDelegate",
  methods: {
    "btnClickHandler": {
      types: ["void", ["id"]],
      implementation: function (sender) {
        $.NSLog("Clicked!");
      }
    }
  }
});

var appDelegate = $.AppDelegate.alloc.init;
// end of new stuff

// Below here is in place already
var textFieldLabel = $.NSTextField.alloc.initWithFrame($.NSMakeRect(25, (windowHeight - 40), 200, 24));
textFieldLabel.stringValue = "Image: (jpg, png, or gif)";
...

Run the app, click the Choose Image button, and watch Console. Do you see “Clicked!” when you click the button? If so, that’s pretty darn cool right? If not, double check your script matches the code here and look for any errors in Console.

Subclassing

What’s this ObjC.registerSubclass all about? Subclassing is a way to create a new class that inherits from another Objective-C class. Side note; the likelihood I’m using incorrect terminology here is through the roof. Bear with me. registerSubclass takes a single argument; a JS object with the members of the new object. Members can be; name, superclass, protocols, properties, and methods. I’m not 100% sure that’s an exhaustive list, but that’s what’s in the release notes.

That’s all well and good, but what did we do there? Since we didn’t provide a superclass we inherited from NSObject. That’s the root class of most Objective-C classes. Setting a name let’s us reference the object later through the bridge with $ or ObjC.

$.AppDelegate.alloc.init; creates an instance of our AppDelegate class. Again, notice we don’t use parenthesis with the alloc or init methods since we’re not passing arguments.

Subclass methods

You create a method by giving it any string name. In this case “btnClickHandler”. Give it an object with types and implementation members. I haven’t found official docs for what the types array should contain. Through trial and error I found it goes like this:

["return type", ["arg 1 type", "arg 2 type",...]]

btnClickHandler won’t return anything so we set the return type to void. It takes one parameter, the sender object. In this case it will be the NSButton we named btn. We use the “id” type because represents any object.

The full list of types is in the release notes.

implementation is a normal function. Inside of it you write JavaScript. You have the same access to the $ bridge as you do outside of an object. You also have access to variables you create outside the function.

A quick note on using protocols

You can implement existing Cocoa protocols with sublcasses, but there’s a “gotcha”. I found out that if you use the protocols array your script will just stop with no errors. I wrote an example and explanation that you’ll want to have a look at if you’re doing that type of thing.

Choosing and displaying images

We’re ready to open the panel, choose an image, and display it. Update the btnClickHandler implementation function with following code:

...
implementation: function (sender) {
  var panel = $.NSOpenPanel.openPanel;
  panel.title = "Choose an Image";

  var allowedTypes = ["jpg", "png", "gif"];
  // NOTE: We bridge the JS array to an NSArray here.
  panel.allowedFileTypes = $(allowedTypes);

  if (panel.runModal == $.NSOKButton) {
    // NOTE: panel.URLs is an NSArray not a JS array
    var imagePath = panel.URLs.objectAtIndex(0).path;
    textField.stringValue = imagePath;

    var img = $.NSImage.alloc.initByReferencingFile(imagePath);
    var imgView = $.NSImageView.alloc.initWithFrame(
    $.NSMakeRect(0, windowHeight, img.size.width, img.size.height));

    window.setFrameDisplay(
      $.NSMakeRect(
        0, 0,
        (img.size.width > minWidth) ? img.size.width : minWidth,
        ((img.size.height > minHeight) ? img.size.height : minHeight) + ctrlsHeight
      ),
      true
    );

    imgView.setImage(img);
    window.contentView.addSubview(imgView);
    window.center;
  }
}

The first thing we do is create an instance of an NSOpenPanel. If you’ve ever selected a file to open, or a location to save a file you’ve seen panels in action.

We only want the app to open images. Setting allowedFileTypes lets us specify the allowed types for the panel. It expects an NSArray. We create a JS array with allowedTypes, but we need to convert that to an NSArray. We make that conversion with $(allowedTypes). This is another use of the bridge. You use it in this way to bridge a JS value to Objective-C. To bridge an Objective-C value to JavaScript you’d use $(ObjCThing).js.

We open the panel with panel.runModal. That pauses code execution. When you click Cancel or Open, the panel will return a value. If you clicked Open, the contstant value of $.NSOKButton is returned.

The other note about panel.URLs is important. In JS, we access the first value of an array with array[0]. Because URLs is an NSArray we can’t use bracket notation. Instead we use the objectAtIndex method. They both give the same results.

Once we have the URL of the image we can create a new NSImage. Since it’s common to create an image from a file URL, there’s a handy method doing it:

initByReferencingFile

We create an NSImageView using the same process we did for creating other UI elements. imgView handles displaying the image.

We want to change the width and height of our window to match the width and height of the image. We also want to make sure we don’t go below a minimum width or height. We use setFrameDisplay to change the size of the window.

We wrap things up by setting the image view image and adding it to the window. Since its width and height have updated we re-center the window.

And that’s our little app. Kick it around, open a bunch of images. And yes, animated gifs will display and play so be sure to try some.

Tidbits

So far, we’ve been running the app from Script Editor with opt + cmd + d. You run the actual app by double clicking its icon like any other application.

You can update the app icon by replacing /Contents/Resources/applet.icns. To access the app resources, right click on the app icon and choose “Show Package Contents”.

Why I’m excited

I’m excited about this because I think it has a lot of potential. Here’s how I’ve been thinking about it. When Yosemite is available, anyone that installs the OS will be able to sit down and write a native application. They will be able to do so using one of the most ubiquitous programming languages that exists. They won’t need to download or install anything extra. You don’t even have to install or open Xcode if you don’t want to. That removes a massive barrier to entry. It’s incredible.

I know there’s a whole lot more to building OS X apps than just being able whip up a quick script. I don’t have any illusions that JavaScript will become the defacto way to build for the Mac. I do think this will allow developers to build small apps that make development easier for themselves and for other people. Have a team member that’s not so comfortable using the command line? Build a quick GUI for them. Need a quick, visual way to create and update a large configuration file? Make a little app for it.

Other languages have these capabilities. Python and Ruby have access to the same native APIs and people make apps using those languages. Something just feels different about being able to use JavaScript. It feels subversive. It feels like some of the DIY of the Web knocking on the door of the Desktop. Apple left the door unlocked, I’m inviting myself in.

Thanks for reading

As with most projects, this one started with a problem that needed fixin’ The site this was for had a listing of audio tracks. Each list item included; the audio element, a title/link to the page for that track, and a short description. Some of list items had extra links to the track’s page in the description.

With this setup, the links to the track pages were causing the problem. Here’s what was happening; Users were pressing play on one of the tracks in the list. They would then click on one of the track’s links. That would take them away from the listing to that track’s page. The navigation would cause them to lose their place in the track they were listening to. The tracks were podcasts that ran from 45 to 90 minutes in length so losing your spot at 33 minutes and 45 seconds was annoying.

This is where controlling the time of the audio element came into play. Clicking on a link should take the user to the track’s page and the track should resume playing where they left off.

Writing The Thing

YouTube does this style of jumping around in videos via the URL. I think the query string style they use works well, so I took my cues from them. I decided I’d use URLs like:
http://site.com/tracks/track-name?t=1h22m35s.

Two quick things about the code examples and descriptions:

1. I wrote the original code for a specific project. The code I’ll be showing here is a modified version of that project’s code. The main difference is that there are no links to separate pages. I left that out because I felt like the interesting thing is not the navigation between pages.
2. The examples only show audio elements, but you can use the same code with video elements.

On page load, we run a function called seekIfNeeded. This function checks the window.location.search for the presence of the string “t=”. This determines if we need to bother trying to parse a time from the URL. This check is by no means fool-proof, but it gets the job done.

function seekIfNeeded () {
  var q = window.location.search;

  if (q.indexOf('t=') > -1) {
    // Do parsing stuff
  }
}

Once it’s determined there’s a time to parse the fun code starts. We declare a couple convenience variables for later use. We bind a canplay event to the audio. We convert the query string to seconds and then update currentTime property of the audio element.

function seekIfNeeded () {
  var q = window.location.search;

  if (q.indexOf('t=') > -1) {
    // Store the "1h34m27s" part of the query string
    var timeString = q.split('=')[1],

      // Store a reference to the audio element with an id of "media"
      media = document.getElementById('media'),

      // Have we updated the time of the media element from the URL before?
      seekedFromURL = false;

    // We can only interact with audio elements when they are ready.
    // Listen for the "canplay" event to know when that is.
    media.addEventListener('canplay', function () {

      // The "canplay" event is triggered every time the audio element
      // is able to play. We only want to change the currentTime of
      // the audio the first time this event fires.
      if (!seekedFromURL) {

        // The currentTime property seeks to a value of seconds in
        // the media element.
        media.currentTime = secondsFromTimeParts(partsFromTimeString(timeString));

        // We've done the seeking, don't do this again.
        seekedFromURL = true;
      }
    });

    media.play();
  }
}

Converting a String to Time

Things get interesting with the line that sets media.currentTime. It’s being set to the return value of the secondsFromTimeParts function. That function is given the return value of another function, partsFromTimeString.

I’ll break down that line of code from the inside out. timeString is a string like; “1h32m23s” or “15m10s” or “12s”. Any combination of hours, minutes, and seconds. Even though humans can figure out the string represents time, the audio element isn’t going to understand it. We pass the string to partsFromTimeString. That function converts the string into an object of key/value pairs. In the object, the keys represent a part of the time and the values the amount of time for each part.

function partsFromTimeString (str) {
  var parts = {h: 0, m: 0, s: 0};

  // Wrapping in a try to avoid an error in case someone gives the 't='
  // query string with no time. It'll just default to zero without it.
  try {

    // The regex match breaks the string into an array
    // like ["1h", "32m", "6s"]
    str.match(/[0-9]+[hms]+/g).forEach(function (val) {

      // Creates an array with two elements, the time and part
      // key like ["32", "m"]
      var part = val.match(/[hms]+|[0-9]+/g);
      parts[part[1]] = parseInt(part[0], 10);
    });
  }
  catch (e) {}

  return parts;
}

My first idea wasn’t to use a regular expression. I tend to avoid them because I only have a cursory knowledge of them. But the query string posed a problem I couldn’t solve without a regex. When trying to break up a string into specific parts, I look for patterns. A common letter or symbol or certain number or anything that repeats. A string like “1h32m23s” doesn’t have that, so I needed a more complex pattern.

The pattern that sticks out is; a number, followed by one of three letters. That letter could be “h”, “m”, or “s”. There’s no certainty that all the letters will be there. And they may not appear in the same order. Ambiguity lead me down the regular expression path. I suppose that’s what they’re for?

The string.match method returns an array of all matches found by a given regex. The regex /[0-9]+[hms]+/g reads the string from left to right and says, “I want an integer with a value of 0 through 9, followed by the letter ‘h’, ‘m’, or ‘s’.” If the regex finds that alphanumeric combination, it puts it in the array.

We’re getting closing to being able to separate the letters from the numbers. That’s what we’re after. Even though we want to separate them, we don’t want to disassociate them. Each letter gives us valuable information about the number. It tells us what part of the time it represents.

The next step is to iterate over the array of number/letter pairs one by one.

Again, we use the match method with a regex. The /[hms]+|[0-9]+/g regex says, “I want either the letter ‘h’, ‘m’, ‘s’ or a number, 0 through 9.” When either of those are found they’re placed in the array we named “part”.

The last bit of work is to add each of the time parts to the parts object we created at the start of the function. Since we get the time value from a string we need to use parseInt to convert it to a integer.

Now we have an object of time parts. The object looks like {h: 1, m: 22, s: 37}. The next step in seekIfNeeded is to get seconds from those parts. For that, we use the secondsFromTimeParts function.

function secondsFromTimeParts (parts) {
  var seconds = 0;

  seconds += parts.s;
  seconds += parts.m * 60;
  seconds += parts.h * 3600;

  return seconds;
}

secondsFromTimeParts adds up the values of the time parts object to get a total number of seconds. To get the number of seconds from minutes we multiply by 60. To get the number of seconds from hours we multiply by 3600. 3600 equals 60 minutes per hour times 60 seconds per minute.

At this point, we’ve converted a string that represents a time to an actual time value the media element can understand. We use that value–the number of seconds into the media we want to go–to set the currentTime property and then tell it to play.

Converting a Time to String

So now we can update the time of a media element with a query string, but what if we want to go the other way? What if we have the seconds and we want to convert that to our time string?

For that we’ll follow the previous process in reverse. We’ll get an object of time parts from the seconds and then a time string from the parts.

var timeStr = timeStringFromParts(timePartsFromSeconds(media.currentTime));
          

Again, from the inside out, let’s look at the timePartsFromSeconds function.

function timePartsFromSeconds (seconds) {
  var parts = {},
    secondsInt = Math.floor(seconds);

  parts.h = Math.floor((secondsInt / 3600) % 24);
  parts.m = Math.floor(secondsInt / 60);
  parts.s = secondsInt % 60;

  return parts;
}

We start by creating the empty parts object where we’ll store the key/value pairs. media.currentTime gives the number of seconds and milliseconds as a float. In this script I decided that I didn’t need milliseconds. Math.floor(seconds) removes the decimal point and everything after it.

The next few lines use the total number of seconds to determine the number of hours and minutes. Those values are set to the appropriate members of the parts object. These calculations are the reverse of what we used in secondsFromTimeParts. We know there are 3600 seconds in an hour so we divide the total seconds by it. We use the modulus–% 24–because anything over 24 hours would be a new time part: days. This script doesn’t handle days, but with a handful of additions it would be able to. We determine the number of minutes by dividing the total seconds by the number of seconds in a minute: 60.

That gives us an object of parts–{h: 1, m: 32, s: 27}–that we need to convert into a time string. We’ll do that with the timeStringFromParts function.

function timeStringFromParts (parts) {
  var str = '';

  for (key in parts) {
    if (parts[key] > 0) {
      str += parts[key] + key;
    }
  }

  return str;
}

This small function iterates over the keys in the parts object. For each key, if the value is greater than zero we add the value followed by the key to the str variable that we’ll return. The string returned will look something like “1h32m28s”.

secondsFromTimeParts and timeStringFromParts could have been combine into a single function like timeStringFromSeconds. I chose to separate them because I like to make functions that are as small and as specific as possible. Doing so provides clarity and allows for reuse. This approach is a tenet of functional programming.

And with that, we have our script soup to nuts. If you take a look at the source code you’ll see a function named displayTimeURL. That function converts a time to a time string for display. It also contains a couple other tidbits that may be useful if you need to build something like this yourself.

Bonus: Soundcloud

Soundcloud allows for embedding of most of their tracks. The embedded player also has a pretty cool API. I whipped up a version of this script to work with Soundcloud players. I’d say it’s about 98% the same. All the little functions I wrote aren’t concerned with the whole story. They just want numbers, strings, arrays, etc. Because of that I was able to use them with the Soundcloud version. Have a look at the demo. Like the HTML demo, you can add "?t=1m35s" to the URL to jump to that point in the track.

The only differences are how you interact with the media element and that Soundcloud takes milliseconds instead of seconds to set the current time. Soundcloud provides events and methods that you can use to control the player. They aren’t the same as their HTML counterparts, but the ideas are the same. The Soundcloud example code is in the same repo as the HTML version.

This was a fun problem to solve. Both from the UX view and from the code. I’m sure there are quite a few similar implementations, but I’m sure there are none just like this one.

Thanks for reading

I’m assuming some knowledge with this post. Folks who have middle ground knowledge of NGINX will get the most out of this. It’s not a how-to NGINX post, so beginners may not find it useful. It also may not be helpful if you have advanced NGINX knowledge as you likely have a better way to handle these things.

What I Do

I keep my config files in a private Github repo called “server-conf”. In it I have two directories; “local” and “prod”. Local for the NGINX install on my developement machine and prod for my VPS. I have different sites locally than I do production. Each site whether local or prod has its own config file.

Both locally and in production, I clone the server-conf repo to my home directory. To tell NGINX where the config files are, I use include in the http block of the main NGINX config file, nginx.conf. The location of this file is different for each install. Locally, mine is at /usr/local/etc/nginx. I can never remeber where it is on my VPS, I just have to peck around until I find it. Here are the relevant snippets from my local and prod nginx.conf.

# local
http {
  ...
  include /path/to/home/server-conf/local/*;
}

# production
http {
  ...
  include /path/to/home/server-conf/prod/*;
}

Why the Home Directory?

Mainly because I can never remember the default location of NGINX config files. This is especially true on my VPS since I access it infrequently. Having it in the home directory allows me to stumble on it since it’s the first directory I see when I SSH into the VPS.

How is this helpful?

This helps me in a number of ways. First, like I mentioned above, it makes locating the config files much easier.

Comfort

Doing this allows me to use a text editor I’m most comfortable with to make updates to production configs.

When I need to make an addition or change to production config I can make the changes on my machine. I then commit and push the changes to Github. Then SSH into my VPS, and navigate to the server-conf directory. There I git pull and after an nginx -s reload my changes are live.

Before this, to make production changes I would have to SSH into the VPS, navigate to the default NGINX config location and use Vim to make changes. This was a slow and error-prone process for me because I’m not comfortable with Vim and I get a bit lost sometimes navigating with the command line. Also, my server isn’t the fastest so editing there is much slower than it is on my laptop.

Git

The ability to quickly roll back breaking changes is huge. If I pull down changes that cause the prod server to stop working, I can use git to check out the previous version of the offending file(s) while I fix the problem. If I’m making larger changes I can create a different branch to make it even easier.

Config backup via Github. If I get a new computer or if mine is damaged, I won’t have to recreate my configs for local development. I can just clone the repo and make the quick update the nginx.conf to get back up and running.

Another cool thing is having a config revision history. Since everything is in git and on Github, I can see when and what changes I’ve made. This isn’t that helpful for me since I’m the only one making changes and they tend to be small, but it could be a huge plus if you have multiple people making updates.

NGINX is relativily easy to configure, but I used to dread making changes in production because I’m not as handy with the command-line and Vim as I am a graphical text editor. Having this setup in place makes it as easy as updating any other files associated with my sites.

Thanks for reading

I'm not trying throw out everything and start from zero. Because of that, my first step was look at what I have now. My current logo appears in three variations. The largest appears on my homepage. On medium size screens a smaller, stacked version with "web" on top and "designer" below my name is shown. On small screens, a side-by-side version with my name on the left and "web designer" on the right is shown.

I always start as rough as possible. I grabbed the "Tyler Gaw" portion of the existing logo and plopped it into a new PSD. I didn't have a plan for what I'd do with the logo so just started typing out different titles next to it in different typefaces to get things rolling. I tried side-by-side, top and bottom, serifs, sans-serifs, handwriting, pulling, prodding, stretching, scaling, etc. I let myself play and make as many ugly messes as I could.

After a good amount of messin' I landed on something that definitely wasn't ready, but felt like a good path. My name with "Design & Development" and "Brooklyn NY, USA" below it. I added a slight angle to both sides to make it a more interesting.

The image below shows that everything was out of whack, it's not even fully readable. That was OK. It was enough that I could see where I wanted to go with it.

In the existing logo I refer to myself as a "Web Designer". That feels like an accurate title because I design and write code, but I wanted to be more clear so I went with "Design & Development". Using "Web Designer" as a title I often have to answer; "no, not only design. I write code too".

Back to Sketching

The next step was to get off the computer and do some sketching. I gave myself some loose guides to follow for the width/height and for the shape the text would be in. I redrew the same thing five or six times until I got one that was close enough.

Moving Into Illustrator

I brought the close enough sketch into Illustrator and live traced it. The conversion to vector was as good as could be expected. With any hand-drawn text there are a lot of unneeded and rough points.

I did a pass where I cleaned up the spacing and removed many points to make the letters of "Design & Development" smoother. In the image below you can see some sharp edges in places on the "Tyler Gaw". Those were caused by me changing the height and rotation of different letters and portions of letters.

When I thought I had the basic size and shape where I wanted it I brought it over to Photoshop and placed it in a very early layout of the new site.

This felt wrong. It was too spindly. I didn't feel like it was standing up on its own. Felt like it could get lost easily at smaller sizes. I wanted it to feel more involved, more interesting, just more.

"What if I add some serifs?" I asked myself. I started with the "D" in "Design". I widened the stroke and added slight serifs to it. That's what it needed. With that small change I could tell immediately that this was where it needed to go. That also let me know that I was in for a whole lot of tedious work as I would have to take the same steps for each letter.

The Work

It took me about about fours days to update all the letters. I always started by removing as many points as possible. A general rule I figured out was mo' points, mo' problems. Fewer points allow for smoother curves and fewer pinches and nicks where they aren't wanted. After deleting the points it was a matter of moving them around until the stroke width and serifs matched the rest of the letters. I used some loose guides to keep the serif sizes similar, but since this is supposed to have a hand-drawn look I could take liberties with them.

The removing, adding, and moving of points feels a lot like working with clay. You start with these rough shapes and you slowly push and pull and smooth it into the shape that you're looking for. I've written about this process before for Slenderman. For some reason it felt more like chiseling rock that time.

As a way to check that things were shaping up correctly and as a break from tedium, I would often bring the logo into the rough layout in Photoshop. Looking at it as a raster image at the approximate size it would be displayed helped me make sure it was readable and looked how I wanted it. I worked on the letters in bursts. I would do a letter, maybe two. Then stop, get some air. Move it to Photoshop, check it, repeat.

I'm happy with how it's turned out. I'm also working on colors for the redesign so I added bits of color to the logo and put it up on Dribbble for feedback. From the beginning I've had my brain set on a red for some reason, but all of the feedback points to yellow. I've been playing with yellow as an accent color for the the rest of the site and it feels like it's working so far.

Here's a final (as-of-right-now) version of the logo embedded as SVG. I removed the yellow drop shadow from my name that is shown in the Dribbble shot. It was kind of cool, but didn't feel necessary. I think I can get more mileage out of the logo without it.

I'm looking forward to working with the logo more. Keeping it vector was important for me because I want to display it using SVG. I also think there will be some interesting things to do with it using CSS transitions and animations further down the road.

Thanks for reading

Nonsense

This part of the process has no structure. I just like to make things as messy as possible. I immerse myself in the types of ideas I want to convey and the type of designer I want to be. I open 100 browser tabs across 10 different windows. I keep multiple sketch books in front of me, a No. 2 pencil and busted, cheap sharpener. I drag out every micron pen I have, even though I'll probably not use any of them. I haven't yet, but I'll probably get out the paint and brushes to make a really big mess.

In my sketchbooks I don't really sketch interface wireframes, but I do write lots of words and phrases. Some of them are ideas I want to convey. Some of them are just nonsense that I think is funny. "Hollerin'" "Sweatin'" "Braggin'" "BLACK" "MAKE IT EXTRA LARGE" "NO STRAIGHT LINES" "ALL RIGHT ANGLES" "Don't limit" "Do limit" and plenty more non-sequiturs, contradictions, and fibs that will have me scatching my head when I look back at them at some point in the future. I also draw plenty of skulls on fire and anarchy signs and all other types of bad drawings that look awesome on the back of 8th grader's notebooks.

Folks

I listen to artists and designers talk about making cool art and design. I have seen all of these multiple times, they never get old. I love them and they get me excited to design:

• Portland/CreativeMornings - Draplin
• More Draplin - Tall Tales from a Large man
• Even more Draplin
• Draplin, shit! He's the best
• Design Matters: Lawrence Weiner
• Beauty is Embarrassing - Wayne White
• Beautiful Losers - Buncha great folks

With all of those it's not even really about the crud they make. I don't sit and stare at the work they produce. I get inspired and excited hearing them talk about how much they love what they do, what it means to them, and what they think it means to other people.

Letters and Such

This time around I wrote names of different fonts that I was interested in using or just like the name; "Franklin Gothic Condensed", "Futura", "Roboto Slab", "Neue Helvetica 55 Roman".

I hopped into ole sparky (PS) and threw together some of the type to see how it would look in the colors I have in mind. Again, no structure, just bashing on the keyboard and tweaking some settings here and there to see how things might work later.

Music

Music is always a huge part of my process. A new Interpol song was released yesterday. It's awesome. I've listened to it about 999 times so far. It's having an impact on my brain and designs.

Here's some other crud I have on repeat that will also have an impact on the design:

• Our Love to Admire - Interpol
• ANTEMASQUE - ANTEMASQUE
• Burials - AFI
• From Parts Unknown - Every Time I Die
• Ultraviolence - Lana Del Rey
• Cry Is For The Flies - Le Butcherettes
• Once More 'Round The Sun - Mastodon

That's pretty heavy list. This design is most likely going to be dark, loud, bold, and brooding. Simple and clean can take a long walk off a short pier.

6th Grade Art Class

Here's something I haven't done for designs in the past, but felt compelled to for this one. I pulled out a stack of old magazines and have been tearing through them cutting things out to make crap little collages. I'm not putting much thought into the pieces. These aren't "mood boards" or whatever. Just flipping the pages and if something catches my eye I hack it out and throw it on some paper. A piece of text that's bright. Some dumb phrase. Creepy dude eyes. Anything that's interesting.

These collages aren't going to be part of the design, they're just a way for me to get moving. Computers are too damn slow. I need to use my hands to move fast and toss shit around and scribble and just be a wreck in general. It helps me get my entire self into it.

These Silly Paragraphs

This post is part of it too. This isn't meant to be some how-to or "10 Clever Ways to Inspire Your Next Responsive E-Commerce Design" post. Like the rest of the process, it's messy. It's unedited and maybe unfinished. It's also a chance to stop and think about what I'm doing. Or to put it another way; procrastinate.

What about you, how do you start?

Thanks for reading

The opening titles to the show True Detective are incredible. CSS contains the building blocks necessary to create a similar style title sequence. I tried my hand it and came up with fun results. Here's the demo and the source code.

The first thing I have to do is issue the disclaimer. This is an experimental project. Things will most likely go wrong when you view it. I'm pushing on the browser pretty hard to get it to do things it maybe wasn't intended to. Also, due to limited suppport of CSS masking you'll only see the full effect in Chrome, Opera, and possibly Mobile Safari. The animations will work in other browsers, but things will look strange.

The Masking

There's a whole lot going on in each shot of the TD titles. You should read the write up about it on Art of the Title. The main effect that I wanted to recreate was the use of human silhouettes to mask shots. They use video clips for the masks and the content being masked, but I stuck with still images to keep things a little easier.

I'm accomplishing masking using the CSS mask property. As I mentioned, browser support for it is currently limited. I'm going to break down the first title card to explain how the masking is implemented.

Each title card is an li element. They contain base styles like width, height, position, etc. Within each li is markup specific to that card. Below is the markup for the elements that make up the opening card.

<div class="composition animated">
  <div class="town animated"></div>
  <div class="human"></div>
</div>
<h1 class="copy animated">
  <b class="role">This is a</b> CSS Experiment
</h1>

The containing div element with the class of "composition" houses all the images. I'm using a containing element here so I can move and scale the "human" and the "town" together, while still being able to move and scale each independently. I'm also applying the mask to the composition element. The "human" and "town" elements have background images applied to them.

All of the images are from the Flickr Commons. I cropped, clipped, and pushed their pixels around in Photoshop until they felt right. Some of them have kind of ratty clipping paths, but you can't really seen them with everything moving. I was able to bring the file size down some because of that.

I want to be able to move the "town" element from right to left and left to right. If I applied the mask to that element, the mask would move with the town causing it to not line up properly with the human image. The mask needs to be applied to an element above it, the composition element. Since CSS masks are only concerned with the opaque and transparent portions of an image, I can reuse the human image as the mask for the "composition" element using the CSS below. Areas appearing under opaque portions will be visible, those under transparent portions will be invisible.

.opener .composition {
  ...
  -webkit-mask: url("opener-human.png") top left/cover no-repeat;
  mask: url("opener-human.png") top left/cover no-repeat;
}

The shorthand mask has similar properties as background. URL, position, size, repeat. It was important that all of the images and mask had the same background-size setting. In this case they are all set to cover. That prevents the images from becoming too short or too narrow so that you see the edges of them. I could have set a fixed width and height on the cards to avoid this altogether, however it was more fun to embrace the unstable environment that is a Web browser by letting everything remain fluid.

The rest of the title cards follow a similar pattern with adjustments based on the the number of images that were needed and the animations that were put into place. You can see the source scss for each card here.

The Animations

There are a few different animations happening during the sequence. The main animation–or timeline–is responsible for cutting from one card to the next and looping back to the first after the last. Within each card there are one or more animations that control composition elements and individual elements.

The main timeline

Once I came up with all the cards I wanted, I tweaked the total length until the pacing felt about right at 36 seconds. The .54 seconds was added the to make the sequence length match the length of the audio track. The track ended up an odd length because I edited it with Audacity and I've never been able to tame that beast. Has anyone?

As the diagram shows, the length of each title card is a percentage of the total sequence length. That length is how long that card will be visible. Figuring out the length for each card took quite a bit of trial and error to get right. If each card was the same length, coming up with a percentage for each would be easy: 100% / number of cards = length. That was not the case with this sequence. There are four title cards and one "bump" card. The bump card contains no text, it's there as a break and extra visual information (AKA, it looks cool). Because of that, the bump needed to be shorter than the title cards. The photography card doesn't contain as much motion as the other cards and that was making it feel too long. I stole time from it to give to the last card. I wanted the last card with my Twitter info to be longer than the others.

Each card needs keyframes at multiple positions. I'm going to show the second title card–the director card–as an example, because they get a little strange.

@keyframes director {
  0%, 22.9%, 46%, 100% {
    opacity: 0;
    transform: translateX(-100%);
  }

  23%, 45.9% {
    opacity: 1;
    transform: translateX(0);
  }
}

I'm going to explain this backwards. Starting at 23% of the main timeline length I want the card to be visible and on the screen. It should stay visible until 45.9% of the main timeline length.

The first set of frames says that the card should be invisible and off screen from 0% until 22.9% and again from 46% to 100%.

I'm using the 0.1% intervals to make sure there is no visible interpolation of the opacity or transform. I want the transition from one card to the next to be a quick cut. The opacity is still interpolating from 0 to 1 and transform from -100% to 0, but it's too fast to be seen.

I'm using translateX to move the invisible cards out of the viewport so they don't obsure any elements of the current visible card. That was happening when I was only using opacity.

Again, getting the timing correct on each card was a lot of trial and error. Making changes a percentage at a time. You can see the full scss for the main timeline animation here.

A sub timeline example

The director card is the most complex card with five separate animations happening simultaneously. Here's the markup for the card.

<div class="composition animated">
  <div class="street animated"></div>
  <div class="trees animated"></div>
  <div class="human"></div>
</div>
<h2 class="copy animated">
  <b class="role">Directed by</b>
  <a href="https://tylergaw.com">Tyler Gaw</a>
</h2>

Anything with the class of "animated"–you guessed it–has an animation applied to it. The fifth animation is on a pseudo-element. Below is list of each animated element and description of what is animated.

• composition: Houses all the images. Over the span of 17 seconds it is slightly scaled, skewed along the X axis, and translated on the X axis.
• street: A masked image. Its X and Y positions are changed over 18 seconds using translate.
• trees: A masked image. Its X and Y positions are changed over 18 seconds using translate.
• copy: The card info is slightly scaled and translated on the X and Y axes over 17 seconds. The copy moves somewhat in tandem with the composition.
• pseudo-element: I'm using the ::before selector on the trees element to add an additional subtle detail I called a "blip". It is a image of fire that is displayed shortly to give a little more detail to animation.

A quick note on using translate. Always use it to animate elements on X and Y axes instead of using positioning properties like left, right, top, bottom. Also try to use it instead of animating the background-position property. Using translate gives much smoother animations and uses less CPU. Paul explains it better than I can.

All of the animations have their animation-direction set to alternate. I did this so there would be no visible jumps back to the starting position of the properties. If you watch the sequence multiple times, you're likely to see the animations running in different directions.

You can see the full source scss for the director card here.

Pausing the animations

In the markup there is a class of "animated" applied to any animated element. I'm using that as way to pause and unpause all of the animations using animation-play-state.

.paused .animated,
.paused .title-card .animated {
  -webkit-animation-play-state: paused;
  animation-play-state: paused;
}

There is some light JavaScript to allow the pause/play button to add and remove the class of "paused" from the body element, the CSS above takes care of the rest.

This was tough!

When I was working on this project, I realized there was a lot going on to make it happen, however I didn't realize how much I was on autopilot during the process. Sitting down and trying to explain—in words—what I did was difficult. If you read this far I hope there's a useful technique or trick that you picked up along the way. If not, I hope it was an interesting look into what goes on in my brain when building this type of thing.

Thanks for reading

Summer 2008. I was living in St. Louis, MO and working as a freelance designer/developer. For months I’d had a nagging feeling that I couldn’t articulate. The best I can describe it was a “pull” that was originating from my gut. The feeling was telling me there was something out there and I needed to go. The feeling didn’t bother to let on what was out there, or where “there” was. It wanted somewhere big though. Somewhere completely different from where I was then or where I had been before. Los Angeles? Nah, too glossy. New York City? Rough, the opposite of glossy. I’d only been to New York once before for a few days years earlier. At the time I described it as “a cool place to visit, but I couldn’t imagine living there.” The fact that I didn’t see New York as a place for me became a reason to go. This move wasn’t about comfort, it was about changing my life. Once I knew where “there” was I decided quickly, almost cavalierly. When my lease was up, I’d pack everything I owned into my Dodge Durango and move to a new city half way across the country.

The freedom that comes with freelancing and working from home was great, but I needed something new. I needed to be around other designers and developers. I wanted to share the work I was doing every day and learn from people that loved the Web like I did.

In my job search for “NYC Web designer”, “Front-end Web NYC”, “NYC Web PHP”, etc I came across this job post. PHP was my language of choice in ‘08 and wow, what a great post. No long list of buzz word requirements, no arbitrary years of experience necessary. Just three lighthearted, pointed paragraphs. Who was this company? Who was behind it?

Time has claimed some of the styles, but the Arc90 jobs page from Jul ‘08 is still available via the Wayback Machine. Here's a small portion:

“...if you appreciate (and violently defend) standards-based technologies like XHTML and CSS...”

It's easy to take for granted in 2014, but in 2008 an agency saying they wanted people that cared about Web Standards was not the norm. That description was speaking to me. It was saying all the things I wanted a company to say. That sealed the deal. Arc90 was where I needed to be. I hadn’t applied to anywhere else, and I wouldn’t. I wasn’t sure that my PHP skills were good enough to get hired for the developer position, but I was going for it anyway. I wanted to work for this company. I had to work for this company.

When I got to New York on August 27th 2008 I sprinted to the Arc90 office. I didn’t start work for a few more days, but I couldn’t wait to see the place and meet the people I’d only seen in photos up to that point. I was here. This place was real. I was a part of it.

Five years didn’t just happen. Working for a company is a relationship. Relationships are hard and require work to maintain. Over the years there’ve been ups and downs, too much work and too little, I saw good people leave and great people join. There were times I thought I was ready to throw in the towel, but didn’t. I knew how special my relationship with Arc90 and the humans there was so I stuck with it.

I wore a lot of hats. I designed a boatload of interfaces for insurance software. Designed and built sites and an app for a failed education startup. Designed and helped build an app to experience conference talks in a novel way. I also made a couple brief design visits to an app that I saw grow from weekend project to successful business.

The best work I’ve ever done I did for Readability. On Readability I was able to stretch my abilities in ways that I never imagined I would. My design and development skills were challenged and strengthened like never before. As the Product Lead I had the opportunity to shape the vision and direction of a product that I used and continue to use every day. I was able to try my hand at leading a team of incredible people to build incredible software. Working to make the lives of the people I worked with more enjoyable has been by far the most challenging thing I’ve done in my career.

I’m forever grateful for Arc90, the people there today, and all the people that have come and gone. The opportunities it’s given me have altered my life for the better. At Arc I was able to be a designer, developer, writer, customer support, marketer, advocate, lobbyist, conflict mediator, and–when needed–ad hoc therapist.

So why am I leaving now? It’s back. That feeling. That pull from my gut that I felt back in St. Louis in ‘08. It’s telling me it’s time to go again. Telling me something is out there. Telling me I need to go find it. Like before, it’s not doing me any favors of being specific about what “it” is. It’s not looking for a new “there” this time. It’s just looking for a “what”. It wants change. It didn’t let me down last time, so I’m not inclined to ignore it this time around.

I’m not sure what’s next, and that feels OK. I don’t have a new job lined up. I don’t have any interviews or prospects. I’m on the hunt. I’m going to spend my next handful of a days looking for it. Meeting and talking with passionate people about what they’re working on and what’s out there. I’m going to spend my next few days searching for how I’ll spend my next 2000.

The world is bigger than ever right now. I can't wait to see what I find.

Thanks for reading

Paper is an excellent product. Like all great products, it not only does a thing well, it also makes you want to do that thing more. Paper makes me want to draw more. After drawing with Paper for a few weeks, I wanted a quick way to share my drawings from Paper to the Web. I built Papersaver so I could get that done.

In Dependence

Made with Paper is a showcase of what people are drawing with Paper. I went to submit one of my silly sketches to it and saw that they ask for an attribution link. They suggest–and most submissions are hosted on–Tumblr. Twitter and Facebook are also mentioned as hosting choices. I don’t care for that. I want the canonical location of my brain dumps to be on a server that I control. This is my natural tendency, but I was also inspired by Jeremy and Frank’s articles on the topic of pushing ourselves to take more control over our digital artifacts by self-hosting.

At this point it was clear that I had a fun side project in front of me. With a few days off work for the holidays, I started letting my brain run wild with possibilities. The plan was to build some type of site where I could publish my drawings while digging into a technology or two that was new to me.

Planning

I generally start a new project with a few bullet points for what I want, what I don’t, technologies I’ll use, etc. These points don’t always make it into the final project and some are just questions to think about during the process. Here’s a few I jotted down for Papersaver:

Project goals

• Publish images from Paper to my personal Web site
• Do not rely on third-party platforms for storage
• “In Dependence”

What does it do?

• Static HTML site
• Displays a list of images (maybe thumbnails + click to enlarge)
• Git repo backed up to Github
• Different input methods: email, Twitter, direct to repo
• generate(): image creation, HTML generation, Git commit, publish
• How can others use this?
• Permalinks to each item

At this point I’ll also jot down some pseudo-code to start thinking about core functions of what I’ll be building. In this case I wanted to visualize what the main method of saving a Paper would look like:

newPaper() // takes img
// contents/papers/Date.getTime()
// " "/index.md
// date: D.getTime()
// template: paper.html
// image_path: tylergaw-paper-{date}.jpg
// save img: image_path.jpg

Getting rolling

After a few hours of writing down goals and researching similar projects I had a good idea of what I would build and the tools I would use to build it. I needed a way to get my drawings out of Paper. The App allows drawings to be shared to Tumblr, Facebook, Twitter, Camera Roll, and Email. The first three were out since they’re third-parties. I entertained the idea of using a combination of export to cameral roll and Dropbox to publish, but went away from it because it didn’t feel flexible enough. I’d be going the route of publishing via email.

How I use Papersaver

• Draw in Paper
• Email each drawing I want published to a dedicated email address
• A Node.js script listens for new email at the dedicated email address
• When a new email arrives, the script grabs the attached image and hands it off to Papersaver.js
• Papersaver.js creates the necessary directories and files for Node.js static site generator, Wintersmith
• Wintersmith regenerates the site with the new drawings
• The newly added and created files are commited to the Git repo and those commits are pushed to the remote repo at Github
• The drawings live at http://lab.tylergaw.com/papers

The pieces

Papersaver is a fairly simple hack, but there are a few interesting parts worth talking about in more detail.

Good enough email security

I'm using a node package to access Papersaver emails over IMAP. I don't want to leave the security of my primary email address in the hands of my programming skills so I use a dedicated email address–tylergaw.papersaver@gmail.com–for Papersaver.

I just gave you the email address. So what's to keep you from flooding my Papersaver with all the images you please? (aside from your trustworthy nature) I use a settings file with to and from whitelists to only allow emails to/from certain addresses. Nothing good would come from me adding my actual settings to the public Github repo, but I do include a sample settings file. The from address is really easy to fake, but the to address is a pretty decent way to lock things down.

I use a "+slug" on the email address that I don't publish anywhere. Fake example; tylergaw.papersaver+71ksk27817@gmail.com. I put that address in my toWhitelist settings. The mail listener script checks to make sure any emails received are to an address in the whitelist, if not, it bails. Fort Knox an email slug don't make, but for this little project it gets the job done.

Papersaver Command-line interface

While I was working on Papersaver, I didn't want to have to send an email each time I needed to test that the saving code was working. To make things faster I wrote a simple CLI that allows me to create new Papers from images on my machine. I used the super-cool node package Optimist to handle the arguments I wanted to provide. The Papersaver CLI isn't any type of technological achievement, but it was the first time I've written something like it, so it gets a mention here.

Static site generator

Since I decided to go the Node.js route for this project, I wanted all the pieces to be written in Node.js. Wintersmith is a static site generator written in Node.js. These types of static generators have been written about at length so I don't have anything more to add. I'll just say that Wintersmith gets the job done and if I need a generator written in Node.js, it will be my go-to.

Steal this project!

I didn't build this project just for me. My hope is that other folks that use Paper will find it interesting and start self-hosting the notes, drawings, and sketches they create. Papersaver isn't yet a turnkey project. I had that in mind from the start, but it will require more work to get it there. In the meantime, I'd love to see forks of it that remedy some of the issues that are currently making it not ready for quick re-use. I'm also 100% open to pull requests, so fork it!

Thanks for reading

Fonts have always felt like a black box to me. The thought of creating a new one seemed like a task reserved for a select few with decades of experience, a deep knowledge of typography, and cumbersome, expensive software. Not me, I thought. I proved myself wrong by making my first font, Slenderman.

Made to Scratch an Itch

I’m working on a small design project that felt like it needed hand drawn type. I could have gone the route of using images, but that just doesn’t feel right on the Web these days. I want my web type to be scalable and maintainable. Using images for type is neither of those. It was clear that I’d need to either find an existing font that fit the style I wanted, or create my own.

I didn’t look around for existing fonts that fit. I jumped straight to creating my own. The project is a personal one so there’s no time limit. When I have that choice I love to let projects expand to as many different areas as they need to. This same project also led me down the path of building another small tool for working with HTML video subtitles.

The Process

I knew how I wanted the capital letters to look from the outset. I started by just drawing them out on paper. My first thought for the lowercase letters was to make them not match the style of the caps, but to be a complement to them. I though a cursive handwriting style would be a nice contrast to the tall, skinny caps.

After drawing the letters, I scanned them and used Illustrator’s Live Trace to convert them to vectors. The cursive lowercase letters didn’t convert well. They lost a lot of detail, and just kind of turned into muck. It was clear they weren’t going to work out so I ditched them.

I went back to the pen and paper and drew a new set of lowercase letters as well as the numbers, punctuation, and assorted symbols. You can see in the drawing that the “@” and “&” are tough to decide on. I followed the same scan then Live Trace with these.

With all the characters drawn, scanned, and converted to vector the next step was to start refining them. All the charaters needed to have similar stroke weights, similar widths and heights, and a handful of other defining characteristics to make them feel like a family.

I started with the capital letters. They converted to vector really well. For them I mostly just needed to make sure each letter was the correct width and height. I also needed to remove extra, uneeded points that Live Trace had added during conversion.

While I was refining each capital letter, I was bringing each into Glyphs Mini, my font editor of choice. It allows vectors to be pasted in from Illustrator. Once the vector is in Glyphs I could set the position and spacing. Glyphs also allows characters to be typed out in the edit tab to get a real feel for how each one interacts with the others. This allows for creating kerning pairs of characters.

The refining process for the lowercase letters took a lot more work than the capitals. For each of the 26 letters, I needed to make the strokes narrower, and for a lot of them completely change the shape from what I had drawn. This involved manually moving the points that made up each letter. It felt a lot like the original vectors were chunks of rough granite that I needed to chisel down into their final forms. As you can imagine, it’s a long, slow process.

I followed the same process for the punctuation, numbers, and symbols. While I was refining the numbers, I did get a little overzealous. I ended up chipping away a bit too much off each one, leaving them very skinny. When they were next to other characters it looked like they were from a different family. This required me to go back and make each number a bit heavier. Lesson learned; compare each character to as many others as you can while you’re tweaking the vectors.

Glyphs Mini allows for exporting to the OpenType format. While I was adding characters I wanted to get a better feel for how they were working. I would export the font, install it and then open up a test Photoshop document. Seeing full sentences and different combinations of letters, numbers, and symbols is really key to determining if things are working. I could better see any issues with spacing and sizing and pick out pairs of characters that could use attention to kerning. Also, it’s a really great feeling to be able to use a font after spending so much time working with it.

Detail of a Gotcha

This is very specific to users of Glyphs Mini, but I spent a few hours banging my head against the desk before I figured it out so I’m going to write about it in the hopes that I’ll save some other poor soul’s forehead.

Glyphs has components. A component is a Glyph that is made up of a base glyph. Example components are right and left double quotes and the ellipsis; made up of right and left single quotes and the period, respectively. When you open a component to edit, the base glyph is grayed out, it seems like it is uneditable. It also only shows the base glyph. In the case of double quotes only a single right or left quote is shown. For the ellipsis only a single period. For some reason Glyphs stacks the base glyphs on top of each other. The base glyph needs to be clicked and dragged to reveal the other base glyph(s) under it. I found this answer on the Glyphs forum.

Part two of the gotcha took longer to figure out. After I’d separated the base glyphs of the compenents, I spaced them, tested them with other characters in the edit tab, and exported like normal. Then I tried to use right and left double quotes and the ellipsis. Nothing would show up. I could tell the glyph exported because I didn’t get the usual missing glyph character and neither Photoshop nor TextEdit tried to replace it with another font. This seemed like one of those what in the hell?!/computer voodoo moments.

Cmd + Shift + D was the magic key combo that ended my confusion. Components need to be Decomposed before they can be exported properly. The option is available under the Glyph menu > Decompose Components. Once a component is decomposed it is no longer tied to a base glyph so it can be edited like any other glyph and it exports normally.

Slenderman is Open Source

I’ve always felt like when I download a font that’s that. The font is done and nothing can be added or modified. This might not be the reality, but without a knowledge of how fonts are made, that’s how I’ve seen things. With Slenderman, I’m not aiming for it being “done”. I want to keep iterating and improving on it. All of the source files are available on GitHub. That means anybody can fork the repo and make any changes or additions needed. They can make new versions of it that fit their needs, or open Pull Requests to have their changes added into the main fork of Slenderman. I haven’t seen that before and I’m interested in seeing if anyone is interested in working on it.

What Did I Learn?

Slenderman does not make me a typographer by any means. It did open up the possibilty though. Working on it has given me a greater appreciation for the skill and patience required to create the beautiful type that we use and often take for granted.

Thanks for reading

A WebVTT Primer

The format is still fairly new and not yet widely supported, so I'll give a quick example of how it's used.

WEBVTT FILE

00:00:01.265 --> 00:00:06.210
This is text that will appear over the video at during the in/out points.

00:00:05.500 --> 00:00:10.250
You can use HTML within WebVTT, pretty cool.

That's an example of a very simple WebVTT file with two cues. We'll refer to it as captions.vtt

The next thing to do is to let your HTML video know about the WebVTT file. That's done using the track element.

<video controls>
    <source src="/path/to/video.mp4" type="video/mp4">
    <source src="/path/to/video.webm" type="video/webm">
    <track kind="captions" label="English captions"
        src="/path/to/captions.vtt" srclang="en" default></track>
</video>

That's all there is to it. If we played the fictional video above we would see the two captions appear at the times provided in captions.vtt. For a more in-depth look at the track element I suggest Getting Started With the Track Element on HTML5 Rocks. That's where I first learned about all this goodness.

Why Is Cuemarker Needed?

WebVTT is very specific about the time format for cues. Cue times must be represented exactly as shown in captions.vtt. It's easy to type out the times in that way, but how do you find precise times using HTML video? HTML video controls display the time of the video, but only down to the second. And not in the format needed for WebVTT. This is why I wrote Cuemarker.

Cuemarker provides a keyboard shortcut–the period key–for setting in/out points and outputting the cue time in the required format.

Cuemarker also provides shortcuts to interact with HTML video. You can play/pause using the space bar and seek forward/backward using the right/left arrow keys. Those controls allow you to arrive at more precise moments in video than you can using the default video scrubber provided by the browser.

How Do I Use It?

I'll go back to the HTML in the previous example, but I'm going to remove the track element. For marking cue times you only need an HTML video.

<video controls>
    <source src="/path/to/video.mp4" type="video/mp4">
    <source src="/path/to/video.webm" type="video/webm">
</video>

Once your HTML is in place, you'll need a bit of JavaScript. Cuemarker creates a variable–cuemarker–in the global scope. cuemarker is a function that takes one required parameter; the video element. It also takes a second, optional parameter to specify a seek interval and output function.

cuemarker(document.querySelector('video'));

That's a bare-bones example and may be all that you'll need. The cue times will be output using console.log.

Here's another example using both the available options.

cuemarker(document.querySelector('video'), {
  seekInterval: 0.5 //default is 0.03,
  output: function (cuetime) {
    var times = document.getElementById('cuetimes'),
        li = document.createElement('li');
      li.innerHTML = cuetime;
      times.appendChild(li);
    }
});

In that example, the seek interval is less precise than the default and the cue times will be injected into the page as li elements that are children of the ul with an id of "cuetimes".

Cuemarker doesn't try to get cute by attempting to transfer cue times to a WebVTT file. All it's interested in doing is outputting the in/out times. Once you've marked in/out times you can copy them over to your WebVTT files. That's how I've been using it and it's working really well for me.

A working demo of the latter example is located here.

That's It?

Yep, that's what I got for now. Again, the track element and WebVTT are not yet widely supported. As of this writing only the latest Chrome and Opera are cool enough to do so. The Web moves fast though and I know it won't be long before Firefox and Safari follow suit.

Limited support for the underlying technology means that this is a tool you may not need today, but you might tomorrow. Fork it!

Thanks for reading

Brass tacks: Come to my build-a-thon, make cool shit! .

If you haven't heard, Brooklyn is the place to be the second week of October 2012. That's the week that the Internet is getting together for a week of conferences, meet ups, drink-ups, shinanagans, and the friendliest little web build-a-thon that could. It just so happens that that build-a-thon is being organized and hosted by myself and Tom Sartain. We'd love for you to join us!

What's this “build-a-thon”?

Alright, here's the deal. If you're a designer or a developer I know you have at least one project in your mind right now that you want to work on. And there's a good chance you've been thinking about working on this project for a while and for one reason or another haven't been able to dive in and get it done.

Brooklyn Alpha is a perfect excuse to give yourself three days to put your idea into motion. Not only will you have three days, you'll have access to other motivated folks who may have complementary skills. Maybe you're a designer who needs a Python developer. Or you're Mr. Django himself and you need a designer to help make your project easy to use and easy on the eyes. Or maybe you're someone who has a head full of great ideas and you're looking for designers and developers to lend a hand in materializing all that greatness coming from your grey matter. Whatever your situation we'll have you covered.

“I don't have any ideas”

OK, OK. The brain well done gone dry. It happens to the best of us. Can you sling hot pixels or code? Of course you can. Then you should come to Brooklyn Alpha. Here's why. Last year when we opened up the floor to anyone to get up and pitch ideas, nearly every single one of our incredible attendees got up and did just that. And more than a few got up a second or third time. There will be no shortage of excellent ideas at Alpha and many of them will need your brain to get them moving.

OK, cool. What else?

I'll tell you what else. You get to be a part of something that's going to be huge. Brooklyn Alpha is sharing the week with the legendary Brooklyn Beta and we're an official part of Beyond Beta. If you haven't heard of those stop reading this now and go find out about them (then hurry back and pick up your ticket to Alpha).

Brooklyn Alpha will be taking place during the day each of its three days. That leaves the evenings free for maximum mingling with a whole host of excellent web folks that will for sure be inhabiting our incredible Borough of Brooklyn during the week.

Hope to see you there!

This is our second year hosting Brooklyn Alpha. It's a challenging, fun, and rewarding task to take on. We're doing this because we love the work we do, we love the city we live in, and we love the web community that makes events like this possible. We're honored to be able to surround ourselves with so many people that share our passions.

Thanks for reading

window.matchMedia provides a way for Javascript to react when a media query condition is met or unmet. While the functionality it allows is great, the necessary code duplication required to use it leaves a bit to be desired. I'm going to walk through a work-in-progress approach to getting around that duplication.

window.matchMedia

The method is simple enough to use and works the way you'd expect it. You give it a media query string it gives you back a MediaQueryList object.

var mql = window.matchMedia("(min-width: 480px)");

That sets the value of mql to a MediaQueryList object with two members, something like:

MediaQueryList: {
  matches: true,
  media: "(min-width: 480px)"
}

The boolean value of the matches member will be determined by the width of your browser window at the time.

You can add event listeners to MediaQueryList objects. An event will fire each time the condition is triggered. This allows you to be updated on the status of the media query without having to resort to polling or a window.resize event. Using mql from above we can set up a listener and handler like so:

mql.addListener(handleMediaChange);
handleMediaChange(mql);

var handleMediaChange = function (mediaQueryList) {
  if (mediaQueryList.matches) {
    // The browser window is at least 480px wide
  }
  else {
    // The browser window is less than 480px wide
  }
}

You can find similar code examples and further explanation of MatchMedia on the Mozilla Developer Network

MatchMedia works pretty well. As usual there are some caveats that I'll mention later. My issue is with needing to specify the media query when you create the MediaQueryList. If you wanted an event to fire for every media query you might have, you'd have manually copy each from your stylesheets to you JS. Every time you update a media query in CSS, you'd have to do the same in JS. What I want is a script to look at a page's stylesheets, pick out all the media queries and create a MediaQueryList for each one.

Getting Media Queries from CSS to JS

When I first started looking into this I thought I was in for some really hairy stuff. I imagined myself having to make ajax requests to fetch stylesheets, use weird regexes to find the @media rules, and employ other types of not-so-fun things. Luckily, this did not turn out to be the case.

I've written small script that accomplishes the tasks I'm after, mqEvents.js is on Github and a working example is at tylergaw.github.com/media-query-events.

(function () {
  var mqEvents = function (mediaChangeHandler) {
    var sheets = document.styleSheets,
        numSheets = sheets.length,
        mqls = {},
        mediaChange = function (mql) {
            console.log(mql);
        }

    if (mediaChangeHandler) {
      mediaChange = mediaChangeHandler;
    }

    for (var i = 0; i < numSheets; i += 1) {
      var rules = sheets[i].cssRules,
          numRules = rules.length;

      for (var j = 0; j < numRules; j += 1) {
        if (rules[j].constructor === CSSMediaRule) {
          mqls['mql' + j] = window.matchMedia(rules[j].media.mediaText);
          mqls['mql' + j].addListener(mediaChange);
          mediaChange(mqls['mql' + j]);
        }
      }
    }
  }

  window.mqEvents = mqEvents;
}());

I'm going to go through the code here and explain what's happening each step of the way.

var mqEvents = function (mediaChangeHandler)

The mqEvents function takes a single parameter, a function that will be called each time a media query is triggered.

var sheets = document.styleSheets,
    numSheets = sheets.length

The document contains an object of all loaded stylesheets. Our sheets variable is a list of StyleSheet objects. numSheets is stored for convenience for when we loop over the list of stylesheets.

mediaChange = function (mql) {
  console.log(mql);
}

if (mediaChangeHandler) {
  mediaChange = mediaChangeHandler;
}

If the mediaChangeHandler argument is not passed to mqEvents, a default function, mediaChange will handle each media query event. The default doesn't do much of anything. For the purpose of this script we just want to have something there.

for (var i = 0; i < numSheets; i += 1) {
  var rules = sheets[i].cssRules,
      numRules = rules.length;

Here we're looping over our sheets list to look at each loaded stylesheet. The rules variable is list of all the rules of the current stylesheet represented as CSSRule objects.
This is where things take a turn for the awesome.

At the start of this I was aware that all a document's stylesheets could be accessed and that all the rules of the stylesheets were represented by CSSRule objects, but what I didn't know was that CSSRule objects that contain a media query have a unique name. Take a look at this screen shot of the console when logging out each CSSRule object:

Regular CSS rules have the name "CSSStyleRule" while media queries have the name "CSSMediaRule". This is great because it gives us an easy way to pluck out only the media queries from our stylesheets without needing to resort to string parsing, which can get ugly quickly.

(It looks like other types of rules like font-face and keyframes have unique names too.)

for (var j = 0; j < numRules; j += 1) {
  if (rules[j].constructor === CSSMediaRule)

We can now loop over each rule in the stylesheet and check to see if it is a media query. The condition here, checking to see if the constructor matches the name "CSSMediaRule", was also new to me. I found that approach in a thorough Stack Overflow answer on the topic.

mqls['mql' + j] = window.matchMedia(rules[j].media.mediaText);
mqls['mql' + j].addListener(mediaChange);
mediaChange(mqls['mql' + j]);

Now that we know we're only dealing with media queries, we're free to use them with matchMedia to create MediaQueryList objects, bind events to those and handle them with a given handler function. This bit of code is nearly the same as the matchMedia example. The noticeable exception here is that each MediaQueryList object is being added to a hash, mqls, that we created earlier. We could accomplish the same thing without putting each object in the hash, this was more of a forward-thinking thing. I have a feeling that there could be a use for holding on to all of the objects to access them later.

Usage

So why would you use this and what happens when you do? In the demo I linked to, this is the implementation:

var msg = document.getElementById('condition'),
    handleMediaChange = function (mql) {

  // For some reason Firefox has trouble always running this code.
  // The console.log seems to help it.
  // TODO: Figure out what the hell that's all about
  console.log();

  if (mql.matches) {
    msg.setAttribute('class', 'met');
    msg.innerHTML = 'The condition "' + mql.media + '" was met.';
  }
  else {
    msg.setAttribute('class', 'unmet');
    msg.innerHTML = 'The condition "' + mql.media + '" was not met.';
  }
};

mqEvents(handleMediaChange);

Notice the big comment about Firefox there, I still don't know what that is. Like I said, work-in-progress here.

What this does is update a the DOM element, represented by msg, each time a media query is triggered. mqEvents doesn't try to react differently to specific media queries. It calls the same handler each time one is triggered. The handler function, however, does receive information about the media query. It knows what the media query is–which I'm placing in the DOM with mql.media–and if the condition was met by the window–which I'm checking with mql.matches.

What Else Can This Be Used For?

Maybe parts of the page layout are done with Javascript and need to be updated each time a media query is triggered. Maybe it could be used to do conditional loading of images, scripts, fonts, or the like. This type of conditional loading of assets could be used to help reduce the bandwidth usage on mobile devices.

Concerns and Caveats

If a page has a lot of media queries, mqEvents is going to add a lot of event listeners and it's going to be calling the handling function a lot of times. I haven't run into anything problematic with my small demo page, but I'd be curious to see the impacts on performance on a page with a substantial number of media queries.

With all these fancy new things browser support is a big question. matchMedia is not supported very well yet. According to caniuse.com we're looking at Chrome 17+, Firefox 9+, Safari 5.1+, iOS Safari 5.0+, IE 10+ (with an ms prefix), and no support yet for Opera. For unsupported browsers a polyfill could be employed. Here's a good one right here.

Other Cool Stuff

As I was working on this I found out about a related project named Harvey. I haven't used it yet, but it looks really good. It looks like it still has that duplication of media queries issue, but if you're looking for targeted reactions to specific media queries it might be the way to go.

Thanks for reading

If you haven't heard already, the current HTML Living Standard or HTML5 spec has in it some super cool form validation. This is client-side form validation that is meant to remove some of the burden of writing validation with Javascript. If you've ever written form validation with Javascript I think you'll agree that this is a very good thing.

Using this new feature of html can be as easy as creating a form and within it creating an input with a required attribute. When the form is submitted, browsers that support validation will take the reigns and make sure that the required input has a value. If it does not, the browser will display a validation error message.

In addition to validating required fields, the form validation will also check to make sure inputted values match given input types. New in the Living Standard are quite a few new input types such as; "email", "url", "number" and so on. Check out the full list located at http://developers.whatwg.org/the-input-element.html#the-input-element.

Validation error messages

As of this writing, there are three browsers that both support html form validation and display error messages when needed. Browser support includes; Chrome 10+, Firefox 3.6+, and Opera 11+. Safari doesn't care about validating your forms and I haven't checked any versions of IE, maybe 9 or 10 support this? Each browser handles the styling of validation messages differently.

Of the three, only Chrome currently offers a way to apply custom styles to the message. Through non-standard, Webkit-specific pseudo classes you are able to style the messages in any way that floats your boat. That's what I'm focusing on with this article.

What about the other browsers?

That's a good question. I haven't heard anything about Opera, but it seems that the style and even handling of the error messages is an open discussion with Firefox. I did quite a bit of digging around in Bugzilla and in the FF 6 source code, but couldn't find any solid information on what the plan is. My hope is that a standard will emerge for styling the messages, but that could be far off.

The pseudo classes and markup

When I first started looking into if/how the error messages could be styled I quickly came across a "Rosetta Stone" in an article by Peter Gasston, http://www.broken-links.com/2011/06/16/styling-html5-form-validation-errors. In the post Peter explains the pseudo classes that webkit makes available to target the error message elements. He's done the leg work of digging through the Webkit source code to find this stuff, thanks Peter! To reiterate some of what is in Peter's article, the following are the classes that are available to hook into:

::-webkit-validation-bubble {}
      ::-webkit-validation-bubble-message {}
      ::-webkit-validation-bubble-arrow {}
      ::-webkit-validation-bubble-arrow-clipper {}

Each of those target a <div> element that is inserted into the DOM when a validation error is triggered. The markup looks like this:

<div -webkit-validation-bubble>
      <div -webkit-validation-bubble-arrow></div>
      <div -webkit-validation-bubble-arrow-clipper></div>
      <div -webkit-validation-bubble-message>Error Message</div>
      </div>

There are four more pseudo classes that were added as I was writing this article. These are currently only in the nightly builds of Chrome/Webkit and seem to just allow further control of the styling.

::-webkit-validation-bubble-icon {}
      ::-webkit-validation-bubble-body {}
      ::-webkit-validation-bubble-text-block {}
      ::-webkit-validation-bubble-arrow-heading {}

As of this writing and Chrome 13.0.782.112 these classes do not seem to have corresponding html elements. Only the bubble-text-block and bubble-heading contain default CSS rules and they are minimal and any CSS rules applied to these do not seem to affect any changes to the current validation error messages. We'll have to wait and see how these elements get put to use.

Default styles

A huge help when styling the messages is knowing the default styles that Chrome applies. Luckily the default Webkit CSS is available to peruse so you can see the exact properties that need to be modified. The default styles live here; http://trac.webkit.org/browser/trunk/Source/WebCore/css/html.css

Demos

I set up three different demos using markup for a simple login form containing two fields. The first field is an email input that is required:

<input type="email" name="email" required>

The second field is a password input that is required:

<input type="password" name="password" required>

The rest of the markup for each demo is nearly identical, differences include; using <label> elements for the first demo and some different structural elements for each.

To really work with the message styles, I wanted each demo to have a distinct style from the others. Demo 1 has a kind of standard-looking style with error messages that are big, bright and bubbly. Demo 2 has a sleeker, higher-tech, control panel-y look with a slimmed down error icon with no text. Demo 3 has an artsy, Draplin-inspired, Futura-filled look that carries over into big-ole, text only error messages.

Fun with CSS animations

Something to keep in mind when styling the messages is that most any styles that are available in Chrome can be applied to the message bubbles, this includes animations. With demos 1 and 2 I created CSS animations to bring the messages into view. Since the message elements do not exist in the DOM until an error is triggered, the animations will not run until that time. So, in demo 1, to get that little shimmy and shake I'm using the following:

@-webkit-keyframes bounce {
      0% {
      opacity: 0.5;
      margin-left: 85px;
      }

      25% {
      margin-left: -35px;
      }

      50% {
      margin-left: 50px;
      }

      75% {
      margin-left: -22px;
      }

      100% {
      margin-left: -15px;
      opacity: 0.9;
      }
      }

The named animation is applied to the main message container;

::-webkit-validation-bubble {
      -webkit-animation-timing-function: ease;
      -webkit-animation: bounce 0.45s 1;
      ...
      }

Demo 2 uses a similar, but less complex animation to slide the serious looking icon in from the left. This demo also introduces something new; custom error message text. The message text, among many other things, can be customized through the Constraint Validation API.

Custom message text with the Constraint API

The Constraint API is a new one in the HTML Living Standard, it allows you to further customize form validation using Javascript. The API is large enough for a full article to explain its features and how to use it, here I'll just point out the code used to set a custom error message.

var inputs = document.getElementsByTagName('input'),
      len    = inputs.length,
      i      = 0,
      cur    = null,
      errMsg = '!';

      for (i; i < len; i += 1) {

      cur = inputs[i];

      if (cur.getAttribute('type') !== 'submit') {
      cur.setCustomValidity(errMsg);

      cur.oninput = function () {
      if (!this.value || this.validity.typeMismatch) {
      this.setCustomValidity(errMsg);
      } else {
      this.setCustomValidity('');
      }
      }
      }
      }

This is a fairly simple block of code, we start by looking at each input element on the page through a for loop, if the input is not a submit button we then use the Constraint API method setCustomValidity to apply the custom message of "!" that we stored in the errMsg variable. In my opinion that should be the end of the work needed, but there is more.

For some reason, when we set a custom error message with setCustomValidity that also removes the error checking from the input. If we were to stop here and submit the form, it would submit without triggering any errors. Starting at the line cur.oninput is the code needed to get around this oddity. The oninput event is fired each time a key is pressed that will change the contents of the input, each time the event fires we are checking to make sure the input has a value and that the value is valid according to the input type. The Constraint API makes available a validity property for input elements. This object contains a number of properties to determine the validity of the input, the one that we're using to make sure the value given is Ok is typeMismatch. If the input either has no value or the given value is not of the correct type, we need to set the custom message again. If a correct value has been entered we then set the custom validity to an empty string, which does a kind of reset on the validation. The input will then be validated normally again.

Going forward

This is definitely new, new stuff, and with all fun new things it will take some time before it can be used on a wide scale. I don't think that should be seen as a huge hinderance though. The Constraint API seems mature enough to be put into use right now, with the aide of a poly fill for browsers that don't yet support it. I haven't used it yet, but at least one exists already; http://afarkas.github.com/webshim/demos/demos/webforms.html. The error message bubbles are not really ready though. With only one browser supporting custom styles, and with no small amount of finagling needed to get them looking right, for now we'll need to keep creating our own error messages. I'll take it though, this is a huge step in the right direction and I can't wait for wider browser support and even more fun new things that will no doubt come with it.

Thanks for reading

Since reading Responsive Web Design by Ethan Marcotte I've been chomping at the bit to design a site using all of the fancy things written about in that little, yellow, different book. To really take those new ideas and techniques for a ride I needed a small project to work on where I could just go crazy and try every new thing I could pull out of the book and my brain. Luckily I have a never-ending stream of personal projects that can always use a little TLC. The project that I picked to revamp is a small one page site for a jQuery plugin that I wrote last year, Jribbble. The site is quick overview of the methods that the plugin makes available, documentation of those methods and some working demos.

The design process

Before starting a design I like to set some rules for myself. These aren't hard and fast rules, just some general thoughts that I keep in mind to guide the process and keep myself in check. The rules for this design were nothing outlandish, the design should:

• Use a flexible grid that remains comfortable from 320px to 1280px in width
• Be designed mostly in the browser with CSS, limited Photoshop work
• Not use any gradients
• Not use any Photoshop noise!
• Have some bits of CSS "sugar"

The last rule, "sugar", I think of as something extra, something possibly new, that you might not see that often. I'll talk about it more later.

The first graphic I envisioned for the design was the name, Jribbble. I saw the "J" and the "b"s in a large, swooping style. A style that I would not be able to accomplish with a computer. I would need to use my hands. The vision I had for it was too large for a pencil or pen or marker. I grabbed my box of acrylic paints, brushes, my 14" x 17" drawing pad and spread them out on my definitely-not-for-painting-on Ikea coffee table. With a medium sized brush and Primary Magenta I scrawled out a couple of "Jribbble"s as well as some random strokes. The toothbrush you see in the photo I used for making paint spatters and for getting paint all over the damned place.

After the painting I took the "Jribbble" I liked most into Photoshop and fiddled with it a bit. I isolated the color from the background, applied the Twirl filter a few times to give it more character and added some of the random strokes and splatters around it for a more haphazard look. In Photoshop I set up a 958px, 12 column grid to work off of. For the banner and assorted page headers I selected Botanika Mono Web from Typekit. I don't own that font so I have to use a very advanced and elegant method for playing around with initial type layout. I input the text I need into Typekit's Type Tester and take screenshots of the text from there. See, fancy ain't it?

The image above is the extent of the design accomplished with Photoshop. From that point on the rest of the design was created with good ole' CSS. Just like I have always done in Photoshop I went through quite a few style iterations; colors, type sizes, positioning, but instead of spending that time in Photoshop and only moving to the browser when it was "final" I used the medium that would be delivered to create the design. Designing in the browser, it feels good man.

The flexibility

To accomplish my flexible grid, I started with a overall width of 80% on the content area. That number was somewhat arbitrary, I started with 100% and decreased the number until I felt there was a comfortable amount of room between the edge of the browser and the beginning of the content. I am setting a max-width of 1280px on the content area. Any wider than that and things started to get a little unwieldy; line-lengths were too long and in general things just didn't look good. At browser widths of 768px or narrower I wanted to gain back some of the margin so I used a media query to increase the width to 95%.

#content {
      margin: 0 auto;
      max-width: 1280px;
      width: 80%;

      @media screen and (max-width: 768px) {
      width: 95%;
      }
      }

Quick note on the media query. I'm using Sass which allows for nested styles. You'll see more of this in later code examples.

In a number of areas of the design I use a two-column layout. To determine the widths of each column I used the oh-so-helpful formula that Ethan describes in RWD:

target ÷ context = result

For the columns I use the starting width of 958px as a context then determine a pixel value based off the width of each of my grid columns, 69px, to come up with widths like:

.method-description {
      h3 {
      float: left;
      width: 40.1878914%; /* 385 ÷ 958 = .401878914 */
      ...
      }

      p {
      float: right;
      ...
      width: 56.4718163%; /* 541 ÷ 958 = .564718163 */
      }
      }

More on media queries

Throughout the design I used media queries to add more fine tuning of styles that I couldn't accomplish with percentages alone. I decrease font sizes, switch to single column layouts and make other miscellaneous tweaks as the browser width decreases or increases to specified break points. For cross browser media query support I used the Respond.js poly fill. It works great, media queries in IE7, you can't beat that with a stick! I needed to make some specific enhancements based on features as well so I used Modernizer for feature detection. I included Respond.js in my Modernizer build.

The good stuff, the sweetness, the sugar

How does a die-cut, scaleable background image sound? I thought it sounded pretty rad. I'll explain. I had the idea that I wanted the "Jribbble" graphic to be different colors at different times. One way to accomplish that would have been to make a number of different images in the various colors that I wanted. That would work, but I thought I could do it a more efficient way. What I did was create an image that had a set background color of #ececec with the text itself transparent allowing for a background color to show through.

With die-cut taken care of, let's look at scaleable. At its base size of 1149px by 663px the logo graphic is pretty large. At medium to large browser widths, this works fine, as the browser width decreases or increases the graphic starts to lose its intended effect and also starts to cause readability issues for other page elements. background-size to the rescue!

#bigAssJribbble {
      background-image: url(../images/branding-die-cut.png);
      background-repeat: no-repeat;
      background-position: 15% 100%;
      -moz-background-size: 190% 140%;
      -webkit-background-size: 190% 140%;
      -o-background-size: 190% 140%;
      background-size: 190% 140%;
      padding-top: 45%;
      position: absolute;
      width: 100%;
      }

A couple things are going on here. It's important to note that the branding-die-cut.png image is much wider than it needs to be. The graphic is flush left and the right side extends ~1049px and is filled with our background color #ececec. I do this so I am able to position the background image off the left side of the browser and not leave a gap on the right side. If there was a gap that the image didn't cover, any background color would show through where I didn't want. The width of the element is set to 100% so it is always the size of the browser. The background-size property does exactly what it says, it scales the background image to the percentages that I used. There isn't a science to those numbers, I just tweaked them until they looked right.

Another cool thing in that block of CSS is the padding-top. Since an element has to be taller than 0px for a background image to show and I didn't want to set an explicit height due to the changing graphic size I used the percentage padding to give the element a height. Again, no science with that number, just changed it until it worked.

Something that's not accounted for in the above CSS is the background color, the color that should show through the die-cut image. This is where I started having a lot of fun. I set up 11 media queries at different pixel max-widths from 320px to 2360px, at each of those I set a different background color for the logo as well as a number of different elements on the page. As the browser width increases or decreases the background color changes. Another little extra I use is a CSS transition to smoothly change from one color to another on each of the chameleon-like elements. An example element with a media query colorway:

#bigAssJribbble {
      -moz-transition: background-color 0.2s;
      -webkit-transition: background-color 0.2s;
      -o-transition: background-color 0.2s;
      transition: background-color 0.2s;
      }

      @media screen and (max-width: 480px) {
      #bigAssJribbble {
      background-color: #4400ff;
      }
      }

I didn't get incredibly specific with what colors I chose. I started with a base of #ff0066 and then apply cooler colors as the width decreases and warmer as it increases.

That's CSS sugar in my view. It's not something that everyone will see, but it's just a little extra for those that are looking and into that sort of thing.

That's all

All in all a very fun process full of experimentation and learning for the sake of experimentation and learning. It probably took too long, so it goes. Side projects live in the off hours, the small windows of time before and after the "real" work and in the hours when you probably need to be sleeping.

Again, the completed site lives here http://lab.tylergaw.com/jribbble and if you're interested in more of the code, fork it from its Github repo https://github.com/tylergaw/jribbble.com.

Thanks for reading

On Tuesday, the 25th I presented an introduction of CSS3 features to a great group of folks at Refresh NYC. The new features included in CSS3 are something that I'm really interested in and very excited about so it was a good opportunity to really dig in and learn a whole lot about them in a short amount of time. For my slides I decided to not take the Keynote route and instead decided to create the presentation as HTML, CSS, and Javascript. It turned out great, not only did I get to explore the sweetness of CSS3 for the sake of presenting the information, I also used a lot of the features I was talking about to build the presentation.

This was the first time I had put together a presentation like this and got up in front of a crowd to present it, and I loved every minute of it. You really gain a deeper knowledge of a topic when you are trying to explain it to someone else. I'm definitely going to do this again in the near future and if you've had any interest in doing so I would highly recommend it.

Thanks for reading

Stuff You'll Most Likely Do Before Reading Any of This Post

View the demo Fork it
You'll need Safari or Chrome to view the demo

There have been a ton of new, really exciting things going on with CSS over the past couple years and I've had an itch for a while to work with them. I started out just wanting to do a small project to get familiar with some of the newer, more advanced CSS3 features, and it quickly grew into a two month immersion into CSS3 land.

Do they speak English in what?

A few years back Jarrat Moody, a super talented designer, created a kinetic type motion graphics piece based on a scene from the movie Pulp Fiction; that I am still floored by to this day. Since I saw that I have wanted to create a similar piece and even made a few attempts using After Effects, none of which ever really materialized.

Let's do this!

So I have my excitement over a new feature set, and inspiration from Mr. Moody, time to get to it. The Man From Hollywood is a kinetic type animation using only HTML, CSS and Javascript. All of the animation is done using Webkit CSS transition, transforms, as well as standard CSS properties. Javascript just acts as a helper to turn CSS classnames on and off at the appropriate times. All of the content you see on the demo is HTML and CSS, no images were used. The audio clip is scene from the movie Four Rooms

Is it practical?

No, not really, but it's not really supposed to be. My goals were to teach myself the ins and outs of a new feature set, make something fun to look at, and hopefully help and/or inspire others to work on their own CSS3 awesomeness.

If you enjoy it, you should Tweet it or share it on your blog or just whisper the URL into a co-worker's ear. That last one would definitely be the best.

Thanks for reading

1. It pushes you to write proper, lightweight HTML markup: IE6 has well-known issues with the box model, strange padding and margin issue, etc. One very good way to stop these potential CSS issues is to write good markup. Easy things like making sure you are writing semantic, valid markup and using <div> tags sparingly can knock out probably 95% of these issues that seem to be such a problem for so many. In my experience, most folks' CSS issues aren't CSS issues at all, they are HTML issues.

2. It gives you yet another chance to get creative: So what if IE6 doesn't support transparent pngs. Find a way to make that image a transparent gif or a jpg. Doesn't look as crisp as the png? So what, this is where progressive enhancement steps in, this is why we have conditional comments. Set up an IE6 stylesheet and dump all of the not so desirable CSS in there. Chances are most of your users are not on IE6 anyway, and if they are this can be a friendly little jab at them for using it. I took this route when building my site. I wanted to let anyone viewing my site with The 6 know that they are missing out so I created a completely stripped down version just for IE6, plus a nice reminder of why. It still works, you can access all the same content, it's just not pretty.

3. It forces you to clean up sloppy code that other browsers ignore: I've seen this a number of times when writing Javascript. Take a look at this bit of JS:

var someCrud = ['item01', 'item02', 'item03',];
alert(someCrud.length);

What's the length of the array? Firefox and Safari say 3. IE6 says 4. I'm siding with The 6 on this one, the comma at the end of the array is erroneous, it should not be there. IE6 sends the message that you should clean up your code by recognizing the extra item while the more advanced browsers ignore it and let you go on your sloppy way. This is just one example, I've come across a number of similar examples over the years, I'm sure others have too.

4. It keeps you on your toes: If you're building websites you need to be flexible. Not all environments are going to be picture perfect, and knowing how to find solutions to problems that arise when working with a browser like The 6 is key. It's easy to just say that a browser is the sole reason for not getting something to function well. Another look at it may reveal that the first approach taken was maybe not the best. You just have to put on that thinking cap a bit.

5. It's good to have a nemesis: What good is Batman without the Joker? You have to have someone or something that challenges you and makes your job harder, and sometimes downright frustrating. Web development is hard, that's why it's fun. How good a feeling is it to confront a problem in development and find some interesting way around it? I got a whole crappy article out of doing just that.

This viewpoint is 100% from that of a developer. As a user, I agree using IE6 would just be a nightmare. The security issues, the lack of features that modern browsers have, etc., etc. That is one merit that the Die IE6 campaigns have. But every time I see some Johnny Developer complaining about how hard it is to build websites for IE6 and how much they hate it, I can't help but think that that person is missing out on opportunities to use their noggin. And that they are a bit of a wimp. :)

After IE6 is gone some other browser will take it's place as the whipping boy. IE7? So, instead of just joining a campaign of wishing death on an inanimate object, I say learn to take away as much knowledge as you can from a less-than-ideal situation. Like Kuato said, "Open your miiinddddd."

Thanks for reading

I slapped a fresh coat on the old website. Well, new paint, siding, frame, foundation...who am I kidding? I just burned down the old one and built anew on its smoldering ashes.

This is the third incarnation of tylergaw.com and just like the past two versions, I've had a damn good time working on this one. I've been able to take the time to work with so much amazing code that I've never really dug into before. This is the first full site I've built using the Zend Framework which has just made me realize how completely rad it is working with a rock-solid framework. It also makes me kick myself a little for not picking it up a long time ago. I'm integrating with a number of different third party APIs, this is also the first time I've built a site doing that. How freaking cool is working with well-written, well-documented APIs?

With the visual design, I've really tried to push it in a direction that I think is, "me". This was one of those designs that I could really see in my head before I opened Photoshop or even put one thing down on paper. The biggest inspiration came from the cover art for Charles Bukowski's Women. The whole time I was reading the book, I was constantly looking back at the cover. I don't know exactly what it is but it is just so damned cool. For this round, I started the design process the old fashioned way; I grabbed a six-pack, some colored pencils, a big-ass sketch book and then went to work.

I'm a big fan of organic textures and knew that I wanted to incorporate some into the design. When I sat down in Photoshop to start turning my sketch into a working design, I realized quickly that I was going to need some real-world help getting the organic look and feel that I was going for. When it's time for real-world textures I just start grabbing anything, and I mean anything, and throw it on the scanner. You never know what you might use that scan of an old broken toothbrush for. Just to be sure, scan it!

Thanks for reading