Twitter Strategy Tip: Images vs. Twitter Cards

Last week when I was hopped up on sinus medicine I mostly stayed away from blogging and social media, in part because all I did outside of client work was try to keep up with my children and sleep, and in part because I was a little worried my normal filter wouldn’t be working at full capacity.

I think I probably proved that second reason true with the comments I left on this Shopify blog post about Twitter Cards pointing out that the examples in the post actually mostly don’t show Twitter Cards and instead are just photos attached to tweets.

While I still feel kind of bad for pointing out something seemingly so trivial, I’m ok with how I did it and upon non-medicated reflection it still does bother me a little bit that the examples are wrong, mainly because (a) accuracy and (b) there are strategic reasons when using a photo makes sense and strategic reasons for using Twitter Cards and they’re for different purposes, at least in my book.

So in an effort to make usefulness out of grumpiness, I thought I’d explain why I use both techniques, and why I consider them two different sides of a similar strategic coin.

Twitter Tip: Photos vs. Twitter Cards

Why Use Twitter Images?

According to this Mashable article (and I believe it, from my own Twitter usage), including an image in a tweet dramatically increases share rates. Not only do images tell the viewer more about the content of the tweet, but they are very eye-grabbing given that they’re partially expanded in the timeline in the desktop app and some other Twitter clients.

Twitter Cards, which usually include both an image and some kind of text, are created on the site side via meta tags in the markup, so you don’t have any control over whether a link you share from someone else’s site supports them. From my unscientific research looking through my Twitter feed, most sites (even many you’d expect to be on top of this type of thing) do not support Twitter Cards. A quick way to check is to view that site’s own Twitter feed, as you’ll probably find links to their own content in their tweets.

Images, however, are completely within your control, since you can just upload them directly to the tweet using Twitter’s built-in tools. As such, when sharing third-party links, unless you’re certain there is Twitter Card support, it’s a good idea to include an image manually.

I do this a lot with various resources I share, using quick screenshots I’ve grabbed from the linked site, e.g.:

Why Use Twitter Cards?

As mentioned, Twitter Cards are content summaries, often with images, that you can set up for your own site by adding some simple markup. There are a few different types of Twitter Cards, including a “large image” card that looks similar in many ways to a tweet with a photo uploaded, and “gallery” cards, which show multiple images.

Here’s an example, although currently you don’t get the full effect of the large image via embedded tweets so you may want to click through to see the tweet on Twitter:

The benefits to using Twitter Cards over tweets with photos are:

  1. If you set up Twitter Cards for your site, every link to your site will automatically have them, even if the person tweeting the link doesn’t bother with images (which is most people tweeting your links)
  2. The Twitter Card is generated from the regular link URL, so you don’t need to have both a link URL and a photo URL hogging characters in order to show a photo and direct people to your site
  3. Twitter Cards provide even more information about the content, usually including both title and a short excerpt along with the image.
  4. There are multiple kinds of Twitter Cards for different purposes, including the aforementioned multi-image gallery cards and even video cards.

So, in my opinion it makes sense to implement Twitter Cards for your own site and then you’ll default to using them when you share your own content. As a wonderful bonus, everybody else who shares your content will have their tweet’s share-ability boosted via the extra content in the cards.

When you don’t have control over the link’s content, then it makes sense to use an uploaded image instead.

Further Thoughts

Of course I can’t leave at just the baseline explanation, so here are a few more related thoughts on Twitter images and Twitter Cards:

Images for Every Tweet?

Just to clarify, I don’t think you have to use an image or Twitter Card for every single tweet. One of the things I like about Twitter (compared to Facebook, for example), is that it’s very text-focused and requires more thought put into words than I see in much of the rest of the internet.

For some types of content sharing, images are really a useful way to both help readers understand what it is you’re linking to, and to encourage further sharing – that’s when these techniques come into play.

What happens if you use both?

I couldn’t find documentation outlining what happens if you post a Twitter Card-enabled URL along with an uploaded, but never fear, I tested it out. It turns out that the uploaded image has priority over the Twitter Card display. In retrospect, this seems obvious, so nicely done Twitter.

A Twitter Cards Tutorial

If you’ve made it this far and are like, “SOLD, now how do I do it?” then you will be pleased to know that I’ve got a tutorial on setting up Twitter Cards ready and waiting for you. Go forth an increase share-ability!

Q&A: Four Methods for Client Education & Training

Q&A: Client Education & Training

I’ve been asked a few different times how I handle teaching clients to manage and update their content once their site is finished. While I enjoy hearing from my clients after we’ve wrapped a project and often work with people ongoing to add templates or on new projects, it’s important to me that clients are able to manage all of their content without relying on me and my team.

In order to make that happen, I use four different methods for sharing information with clients and training them to use the content management system to manage their content and their site as a whole.

1. Documentation

For early decision points and also for general information on website concepts, I provide a lot of documentation in written format in one of two places.

Blog Posts on Common Topics

A lot of my documentation for clients is right here on my blog. Many of my posts are just elaborations on answers I’ve first sent to clients via email, which is great because once they’re published I can just send the link instead of re-answering the question.

My posts on backing up & updating WordPress, prepping images for the web and aspect ratios are all examples of blog posts that started out as client education emails.

Non-Post Documentation

This is for things that come up again and again in email conversation with clients but aren’t necessarily right for blog posts, I’ve started compiling additional documentation via HelpScout using their Docs feature.

Documentation via HelpScout

There is some overlap between this content and my FAQ page. The difference is that the HelpScout documentation, while not protected or completely hidden, is intended for clients, whereas the FAQ is more public-facing. The integration with HelpScout email (which I use for my general email inbox, shared with my business assistant) is partly what makes this a great system for us, as we can really easily insert links to the articles into emails.

2. Admin Structures

When we’re actually building a site, my team and I make sure to prioritize the content management experience of the end user, making it easy for the client to update their content even when it means a little more work for us.

While this is not explicitly part of client education, it is an approach that makes our client education needs down the line more manageable.

Example Admin Structures

In practice, this means we use tools like Advanced Custom Fields to create really clean, nice-looking, intuitive admin screens specific to each page template.

Scouted Recommendations Model

Click to zoom, from the Scouted NYC case study

You can see more examples of how we’ve done this for various sites by looking through my case studies.

3. General Tutorials

Since I use existing content management systems that already have great structures for many things a client will need to do, I also make make use of existing documentation where possible. This saves time but also ensures that clients get really really great information – better than I’d be able to provide.

WordPress Video Tutorials

For WordPress, I provide clients with access to WP101’s premium video tutorials, which I’ve licensed and share via a private area on my site:

WP101 page on

These videos cover all the WordPress “basics” including working with blog posts, categories, comments, menus, widgets, and plugins. The videos are a higher quality than I’d be able to provide and are updated with changes to WordPress core.

Shopify Written Documentation

For Shopify, I link out to specific pieces of documentation in the Shopify manual and I’ve also been impressed with the third-party Shopify & You e-book (affiliate link), which is $39 and very very thorough.

4. Custom Tutorials

While those general resources have proven to be quite helpful, since we customize the admin to handle the various page templates we’re creating for clients I typically also create a informal video tutorial covering our customizations. I’ve found that video is great because the client can watch and re-watch it at their convenience, rather than feeling like they have to absorb all the information in real-time via a screen share or real-time training session.

Example Site-Specific Video Tutorial

Here’s an excerpt from a recent tutorial I created for Clara Persis:

That’s about half the video, and the rest of it walks through the remainder of the pages.

Underneath the Videos

You can see from watching that example that these videos are not rehearsed – it is just me talking through the pages and features one by one the same way I’d do it if I were sitting at the computer next to Clara. The informal, unscripted nature ensures that I can record these videos quickly, which keeps it feasible.

Technology-wise, I use Quicktime (the regular version that comes with Macs) to record along with the microphone built into my UrbanEars headphones. I then upload the video my Vimeo Pro account via the built-in Quicktime “Share” feature and email the review page link to the client, with permission set such that only people with the link can access the video, no sharing is allowed, and the client can download the file to their computer if they so choose.

So that’s it – the four methods I use to education clients and help them learn to use their site! Of course, I also try to be flexible to meet clients’ individual needs, so there have been times when I’ve supplemented these methods with phone and/or screen-share training, or even with in-person training for an entire team. Usually, though, the videos and written documentation are a great, lasting solution for both me and my clients.

Q&A: What the heck is an aspect ratio?

Aspect ratio is one of those concepts that is confusing until you try and explain it to someone else and then it is downright impossible.

It comes up most often when thumbnails are being generated from a large original image, and is especially a concern for Shopify sites since, unlike WordPress, their system cannot be set to crop thumbnails to a specified dimension (more on this later).

So now that I’ve used the term “aspect ratio” a bunch of times, maybe you’re wondering what it actually means and where it comes up in practice?

Aspect Ratio Explained

Aspect ratio is the ratio between the width and height of an image. That means that images that are different sizes can have the same aspect ratio. It’s not about absolute sizes, it’s about relative sizes.

A lot of the time in web work, we talk in actual pixel dimensions or in general terms (“square” vs “portrait” vs “landscape”), but if you are writing out an aspect ratio, you write it as width:height, e.g.1:1 or 3:4. Typically the values are reduced as much as possible, so an image that is 400px by 300px (400:300) would have the aspect ratio 4:3.


If an image’s width and height are the same, that image would have a 1:1 aspect ratio (it would be square).

If it is one and a half times as wide as tall, the image would have a 1.5:1 aspect ratio (it would be landscape oriented).

If it is 4 times taller than it is wide, the image would have a 1:4 aspect ratio (it would be portrait oriented).

In Practice, This Means…

I recommend that Shopify store owners upload their product images at the largest size it’ll ever be displayed (including via zoom features). The current maximum size Shopify will serve is 2048 x 2048, so the images should have 2048 pixels as their largest dimension.

If the images are squares, they can be 2048 x 2048.

If they are landscape oriented (wider than they are tall), the width should be 2048px and the height will be less.

If they are portrait oriented (taller than they are wide), the height should be 2048px and the width will be less.

Generating Smaller Sizes

Shopify stores the originals and also makes a variety of smaller-sized versions. We unfortunately don’t get to specify those smaller sizes, they’re predetermined by Shopify (you can see the size list at the bottom of this page).

This gets tricky with thumbnails, especially when a nice grid has been designed for category pages or for additional product images, and the uploaded images have varying aspect ratios.

One of the image sizes Shopify creates is “medium,” which is listed as 240 x 240. That’s a little misleading, though, because Shopify doesn’t crop the images to exactly that size. Instead, it shrinks them down, maintaining the aspect ratio, so that they fit within that sized box.

In fact, that’s the way I imagine it in my head – as a 240 x 240 pixel box, and then a larger image that is shrinking down to fit in that box but is otherwise unchanged. If it is landscape-oriented, it stays landscape oriented, and the width becomes 240px (the max for that size).

Shopify Takeaways

There are a few takeaways from all this that I’d leave you with:

For Shop Owners

If you want a consistent grid, it is a good idea to make all of your product featured images (the first image for each product, usually) have the same aspect ratio before you upload them. Sometimes this can be approximated for images that are similar, but it gets messy if your images are very different in aspect ratio (like the third row in the graphic). Better to do it before upload for maximum control.

For Designers

It’s a good idea to check with shop owners early in the project to find out if they have consistent images and/or if they’re willing to handle making their images mostly consistent (at least those used in grid views – usually the first image for each product).

Additionally, it is very helpful if you keep the Shopify image sizes in mind and design using them as much as possible. Otherwise, we have to resize in the code, which is a bit slower when the page loads.

WordPress Side Note

In WordPress we’re able to set the thumbnail size (via Settings > Media) to crop or to respect the original aspect ratio. The other built-in sizes do not crop. In addition, we’re able to set our own custom sizes in the theme files and choose for each whether they should crop or not. While this eliminates many of the problems caused by a non-cropping system, it still can cause issues if the focal point is not within the crop area.

Processors, Languages, & Task Runners: What I Use & Why

Front-end Development Processors, Languages, and Task Runners

Yesterday I wrote about the nine steps in my starter theme workflow to get things set up and running (the post is about my WordPress starter, but process is very similar for Shopify). I name dropped a bunch of code tools (processors, languages, task runners, and so on) and today am going to attempt to give a quick explanation of what those things are and why I use them.

Before I dive in, I wanted to mention that I was kind of resistant to adding this stuff to my workflow – regular old CSS and manual task running was working fine and I didn’t feel like I had the time to figure out these new things.

However, a lovely combination of a push from one of my associate devs (thanks, Kim) and the realization that all these things could actually work together finally had me trying it out. I’ve seen a noticeable efficiency boost even though I’m barely scratching the surface of these tools, so I won’t be looking back.

Version Control


git logoGit is a free, open source version control system. I mainly use Git because it makes sharing files and collaborating easier, although I am certain if I ever need to roll back to earlier code I’ll appreciate the history as well.


GitHub Mark A common point of confusion is whether Git and GitHub are the same thing. Git is the source control system, GitHub is an online storage and tracking system for projects using Git (kind of like a specialized Dropbox). It also includes features like issue/ bug tracking and wikis. I mainly use GitHub for open source projects (where I want to share the code publicly) or projects that will eventually be open source, since you have to pay for private repositories.


Bitbucket Bitbucket is very similar to GitHub – online storage and tracking for repositories – but they offer unlimited free private repositories. We use Bitbucket for client projects, but keep public projects on GitHub mainly for the community aspects (also the web interface is a little nicer on GitHub).

CSS & Browser Prefixes


Sass Sass is what is apparently called a “CSS extension language,” which I interpret as “a different way to write CSS that requires conversion to normal CSS before it hits the browser.”

After a long period of resistance to trying Sass (or LESS, an alternative), the turning point came when I started looking into task runners and realized that everything could be done all in the same easy package (no need for another GUI).

I currently only really use the variables, nesting features and a fairly limited set of mixins (all those terms are described in the Sass Basics guide). Even with only those features in play, it has made my working files much easier to read and update.

In addition to the documentation on the Sass site (which is well done), there’s a nice beginner’s guide to Sass on Web Designer Depot that’s worth checking out.

Side Note on Compass: I don’t have strong feelings on Compass, which works with Sass and has a bunch of mixins built in. I can see the utility but I’m more the type to roll my own. Right now one version of my starter uses it and another does not.


Autoprefixer I found out about Autoprefixer after reading about it on CSS-Tricks (as one does), and added it into my task runner workflow from the outset. It’s a tool that processes your CSS and adds all the necessary vendor prefixes based on the database.

Evidently Compass does similar things but I like this method because I don’t have to even consider prefixes or mixins. It’s all done for me and it’s kept up to date automatically.

Task Runners


Grunt I was inspired to try Grunt after reading Chris Coyier’s 24 Ways post called “Grunt for People Who Think Things Like Grunt are Weird and Hard”.

Essentially, Grunt is a tool that runs a bunch of processes on a set of files. That can include everything from Sass processing to Autoprefixing (those are what I use it for) to image compression, code testing, and much much more.


Gulp Gulp is basically the same thing as Grunt, but with a different method of structuring the processes. I like it mainly because it’s faster and I am impatient, otherwise I don’t have a very strong perspective (some people do – there are lots of Grunt vs. Gulp articles out there).

Gulp is a little bit newer so there are not quite as many options for things it can do, but all the stuff I need is covered so that doesn’t impact me. I used this tutorial by Travis Maynard, which starts at the absolute beginning (installing Node.js), to get going. Here is my current gulpfile in case it’s helpful to see one.

Update: A Note on Watch Tasks

Shortly after I published this post, a question on Twitter reminded me that I forgot to mention one of the key benefits of these task runners, which is watch tasks. You can set up a special task that watches a set of files and runs some tasks whenever a change is made.

For example, I have my watch task set to keep an eye on all my .scss files and every time I make a change in one of them it automatically processes the Sass and recompiles my minified CSS file, and then if I have LiveReload turned on the browser, it also reloads the styles so I can see them change in real time.

It’s basically magic.

Deployment via DeployHQ

DeployHQ While I’m leaving out the desktop applications mentioned in the original workflow post, I did want to mention DeployHQ, which is an online deployment tool that links up remote repositories (e.g. from GitHub and/or Bitbucket) to a live server on a hosting account.

I’ve written about deployment options in the past, if you’re interested.

Automatic Configuration via Yeoman

YeomanFinally, we’ve just started to play around with Yeoman, which will allow us to cut 4-5 steps out of that workflow I posted about by automating them via a configuration tool.

When that is finished, I’ll be able to run Yeoman from the main folder where the configuration tool and starter theme files live. There will be a series of questions (with sensible defaults set), and the new theme will be created based on the answers. It’ll handle the naming conventions, installing the task runner of my choice, and a few other things. It’s pretty amazing, really.

It took me a few (very interrupted, weekend) hours to get my first generator mostly working (it currently works if you opt for Gulp but fails if you choose the Grunt option), mainly using their getting started guide. The Treehouse blog also has a Yeoman tutorial.

Also, this is a great video of a presentation on automating your workflow that hits on both Grunt and Yeoman.

If you’re just starting to consider using these tools, keep in mind you don’t have to start with every feature or method that exists. My .scss files are still large part regular old CSS, just reorganized into a clear nesting structure and with variables peppered throughout. I don’t use task runners for much other than CSS yet. That’s all fine – now I have the systems in place doing me some favors and it’ll be easy to add to them as I find other places in my workflow where it makes sense.

Workflow for Setting Up a Custom WordPress Theme Project

I’ve been doing some work on the starter theme we use for all client projects (more on starter themes & custom work here) and thought it’d be interesting to share the current set of steps necessary to get it set up for a new project.

NOTE: I am just running through the steps in this post, not so much going into what each component or tool is or does. I would love to know which pieces don’t make sense or aren’t familiar to you so I can elaborate on them in the future.

Also, next week I’ll be launching a limited enrollment beta version of my new online course that teaches whole process in excruciating detail (along with how to actually work and customize with all of the files in the theme itself). Sign up for the WP and/or workshops lists here for first dibs.

Here’s what it currently takes to get the starter theme ready for development:


The theme is hosted as a private Github repository, for easy access across our team. So the first step, then, is to download the theme from Github. I could copy the local directory, but sometimes I mess that up so I just download the zip each time for now.


Next, I do a bunch of renaming, replacing the starter theme name with the project name. The folder itself gets a new name, and I use String Replacer to do a bulk find and replace operation to change function names and other instances throughout all the files.


At this point, I move the theme to the directory where it’ll live while I’m working on it (which is synced with Dropbox), and then I open it in Terminal via drag and drop. I also open the directory in Espresso, which is my text editor of choice, again by dragging the folder icon onto the application in the dock.

New theme ready for set up in Terminal and Espresso

Ready for more set up!


Next, I run npm install in Terminal, which installs all the Gulp dependencies (all the files needed for the tasks we run using Gulp).


One thing that isn’t captured by my bulk find-and-replace is the theme meta information in the stylesheet, so I update that next in Espresso by editing the /scss/style.scss file. Once that’s updated, I switch back to Terminal and run gulp to compile the CSS for the first time (getting my main directory style.css all set up with the new meta info).


Next, I run through a set of steps to set up version control using Git. I’ve historically used Tower, which is a Git GUI, to handle these steps because it’s been easier as I’ve gotten more comfortable with Git. Now that I feel more at ease in Terminal, I’ve done this a few times on the command line as well, just because I’ve been too lazy to open Tower. Either is fine, I try not to stress about the method too much. The general flow is: create local repository (git init), stage all the files (git add -A), run an initial commit (git commit -a -m 'initial project commit').


We use BitBucket for client repositories because they have unlimited free private repos (Github has a limit), so next I log into BitBucket, create a repo there for the project, and add relevant members of my team. Then, I grab the access link and jump back to Terminal to push my local repository up to the remote version (for backup and cross-team access) using git remote add and git push.


Next, depending on the project we often set up automatic deployment using DeployHQ so that every time we push future commits, the remote server also gets the updates. This is convenient in a development situation but I would not suggest automating it on a live site. The sub-steps for this include getting the theme directory set up on the server, connecting Bitbucket and DeployHQ (really easy – DeployHQ connects right to the Bitbucket account and lays out the steps to take on the BitBucket side), and entering server credentials in DeployHQ.


At this point, I’m ready to work on the theme itself, and all that setup ensures that much of my process from here out is nicely automated (Sass processing, version control, even deployment)!

Improving Efficiency

Clearly, this setup process is not the most efficient thing in the world, although it’s gotten quicker with practice. We’ve been working on automating some of these steps using Yeoman, which I’ll share more about once we get it fully up and running. I’ll also be making my starter open source in the near future, once we’ve done a bit more cleanup.

Update: About all those tools

I realized after writing this post that I name-dropped a ton of stuff without really explaining what it is (Grunt, Gulp, git, etc.) so I wrote a follow up post explaining what they are and why I use them.