Cloud Four Blog

Technical notes, War stories and anecdotes

Did you try to reach us?

I’m embarrassed to admit it. I screwed up and if you tried to contact us over the last few months, there is a chance your message didn’t get through.

Specifically, messages sent via the contact form on our site weren’t always reaching us.

In case this saves anyone else from making the same mistake, here’s what happened. We switched our mail to Google. Instead of having an email alias, we had to use a Google Group.

Everything seemed fine for a few months, but then at some point Google Groups decided contact form submissions were spam. And we didn’t have any moderators for the group.

I set up the Google Group so I must have screwed it up. Because things worked great for several months, we don’t know when the problem started and how many messages were missed.

The most painful part about screwing up something like this is that there is no way to know who you need to apologize to.

So if you tried to contact us and didn’t hear back, I’m very sorry. The contact form is fixed now. We’d love to hear from you.

How to handle software for small business employees in an app store world?

App stores have been great for consumers and developers. One-click purchasing is awesome. But as a small business owner, they cause us nothing but grief.

In the boxed software world, I knew that if we bought iWorks, that the company owned it. It became an asset of the company. And if we were really good, we could keep track of the serial numbers of the software we bought so that if anything happened to the physical media, we could still install the software.

The app store makes this much harder. All of us are on Macs here at Cloud Four. And while the computers we use are owned by the company, we all use our Macs to buy music, videos, and software that is for personal use.

In fact, it is much easier for everyone to simply use their personal iTunes account so that their purchases sync across multiple devices. It isn’t perfect, but it works well enough.

Until we need to buy some software for work. If the we buy the software using our personal account, it is encrypted and tied to our personal iTunes account. There is no way to transfer it to another person if we leave the company or if we simply no longer have use for the software and someone else does.

In truth, the software should be owned by the company. The company should be able to buy software and move it to whatever machine makes the most sense now or in the future.

But as far as I can tell, there is no way to do this. There is a business volume purchasing program, but that only applies for a minimum of 20 license purchases which doesn’t make sense for us. There is a similar business app store for iOS, but only certain apps participate and if they don’t, then you’re out of luck.

I’ve talked to another company that buys employees gift cards so they can buy apps. But whether it is gift cards or reimbursements, it doesn’t get around the basic problem that the software is cryptographically signed and associated with someone’s personal account instead of the company account.

Does anyone have a solution for this? Is there some obvious solution for small businesses that I’m missing? How do other companies handle this?

Mobile-First Responsive Design Virtual Seminar

When the kind folks at UIE asked if I was interested in conducting a virtual seminar with them, mobile first responsive design is the first topic that came to mind. It’s something everyone should be doing, but few are.

So let’s do something about that shall we?

If you’re already doing mobile first responsive design, awesome. Make sure you tell your colleagues why it matters and teach them so more responsive designs are built this way.

If you’re not doing it already, then I encourage you to join me for my Mobile First Responsive Design UIE virtual seminar next Thursday at 1:30 PM ET. The seminar lasts 90 minutes and costs $129.

I’ve put together a little slideshow with audio to give you a little preview of what the seminar will cover.

If the embedded slides don’t work for you (sometimes the audio takes a few seconds before the play button works) or you just want to see a larger version, try the original version hosted on SlideShare.

I hope you can join me next Thursday. Register today to save your place in the seminar!

The EMs have it: Proportional Media Queries FTW!

If we’re going to be proportional…

A core tenet of Responsive Web Design (RWD) is fluidity and proportion. Instead of using fixed-width layouts, we enlightened web devs and designers use percentages in our CSS. Font units aren’t pixels or points anymore, they’re percentages (typically for top-level baseline reset) or, more often, ems. And yet the vast majority of us still write width-based media queries in pixels, e.g.:

@media all and (min-width: 500px) {}
@media screen and (max-width: 800px) {}

It’s a natural thought process: for windows or screens of particular width ranges, we want to flow our content in a particular way. This naturally seems like a pixel dimension. But, once again, to bring out my big hammer, what about when we look at things from a content perspective?

Folks who design for traditional reading media—where the content really is king—don’t center design decisions around the absolute width of content-holding elements so much as around the optimal line lengths for the content they’re flowing. There are some tried-and-true numbers one can shoot for that make for the “right” number of letters (and thus words) per line for comfortable human reading.

Thus actual column width is a function of font size and ems-per-line.

Baseline expectations

You may have seen the rule of thumb (useful, admittedly!) that makes the following general equation in terms of baseline font sizes in CSS:

100% = 1 em ~= 16px ~= 14pt

This means that, at your baseline, that is, before you’ve adjust font sizes in any child elements, the default font size in the browser is usually approximately 16px and usually approximately 14pt but always 100% and 1em.

If we start from a baseline of 16px, you may well wonder what the difference (beyond academic) is between a media query like:

@media all and (min-width: 400px)

and one like this, that uses ems multiplied against the 16px baseline approximation:

@media all and (min-width: 25em)

The answer, my friend, is content

Here’s the 64-dollar question or whatever:

What happens when the baseline is not 14pt/16px?

On Ye Olde Desktop Web, this situation most often comes about (“most often” is unscientific here, but I’m willing to toss out the hypothesis, at least) from user-intiated zoom in browsers. Low-sight users might do it, I know I do it when I’m surfing the web on my Mac Mini from the couch across the room. I’m not that old but, man, it’s hard to see the contents of a Wikipedia article on a 23″ monitor from 10 feet away.

As I zoom in, that is, make the text larger in my browser, I’m no longer at a 14pt/16px baseline. 100%/1em in my world is now a different number, maybe 18pt, maybe 32px. Pixel-defined content holders no longer have comfortable amounts of words per line. Pixel-defined content holders that float might wrap awkwardly as the content in them swells.

Case study: Our nav

Our creative director and CSS wizard extraordinaire, Aileen, whipped us up a beaut of a responsive new site layout. For various screen widths, our site’s nav has a few different behaviors.

In pixels at normal zoom, the nav elements fit in a line roughly at a width of around 656px. There’s generous room to detatch and float next to the logo at around 960px.

For screens/windows narrow enough that the full set of top-level nav elements would not fit on one line, we use the menu button nav pattern:


For screens/windows narrow enough that the full set of top-level nav elements would not fit on one line, we use the menu button nav pattern.


For screens/windows in a particular range that are wide enough to fit the top-level nav elements on a single line, we do that.

For screens/windows in a particular range that are wide enough to fit the top-level nav elements on a single line, we do that.


For screens/windows wide enough to fit all of the top-level nav elements horizontally and have enough room left over for our logo, we detatch and float the nav to the top right.

For screens/windows wide enough to fit all of the top-level nav elements horizontally and have enough room left over for our logo, we detatch and float the nav to the top right.

But what happens if a user has his or her zoom set higher?

I’ll show you a little experiment. I’m using the Chrome browser, and I’m viewing our site with a window about 670 pixels wide. With a pixel-based media query, that puts me in the second category of nav experience: all of the top level items are shown horizontally, docked to the top of the content:



OK, now I’m going to use the Zoom In command twice to make my text larger.

With a pixel-based media query:




With an em-based media query:



Why did this happen?

The pixel-based media query @media all and (min-width:656px) still evaluates to true with the zoomed-in text and therefore creates awkwardly-wrapped nav elements.

However, the em-based media query of @media all and (min-width: 41em) scales to the larger text size. Zoomed in like this, the browser no longer satisfies that query: we have fewer than 41ems to work with. So we deliver the menu-button nav pattern and other layout and styling appropriate for the way the text fits. Content, again, is what ends up dictating what we’re doing in the end.

You could also make the text smaller and watch the same proportional adjustments occur, in the inverse.

BTW: It should be noted that, unlike window resizes, which cause media queries to be re-evaluated immediately, you’ll need to reload the current page if you zoom in or out for em-based media queries to re-apply. My hunch is that most users who zoom a lot keep their zoom set as they navigate around different pages and aren’t changing zoom settings on a site-by-site basis. I could be wrong about that, though.

The specifics of em-based media queries

The media queries on our site are all crafted based on the approximate baseline. We played with our browser window widths, adjusting them until it looked like they were at the appropriate width to create a breakpoint at normal text zoom. We noted that pixel measurement and divided it by the rough baseline of 16px to arrive at our em units. There may well be a better way to do this math, but this seems to do the trick so far.

A device-specific aside

One of the things that spurred me toward thinking about em-based media queries was my own Kindle Touch. Through no action of my own, the Kindle browser’s default text zoom is, roughly put, high. Like newer smartphones, the Kindle has a high pixel density, 167ppi. An absolute-sized font (say, 16px) on a high-density screen is correspondingly tiny. Most smartphone browsers get around this by reporting their resolution differently for purposes of the web. An iPhone 4, for example, which has a real resolution of 640×960 and 326ppi, masquerades as 320×480 in the browser as a way to get normally-designed websites to look normally-sized and not teeny tiny. For the iPhone, 1em is still approximately 16px or 14pt, and so pixel-based media queries generally behave equivalently to em-based ones (disclaimer: that’s a broad generalization).

The Kindle Touch, on the other hand, has taken a different approach. It reports its web pixel resolution as 600×800, but its default text size is considerably larger than 16px/14pt.

Our early, pixel-based media queries for our nav looked dreadful on the Kindle. Its resolution meant that it was using our tablet-range layout, but its text was enormous, causing widespread ugliness as the pixel-width elements didn’t scale to adjust. The site looks pretty decent, however, with media queries in ems:


Our site looks tolerable on a Kindle Touch. That's about as good as it's going to get on that browser.
Our site looks tolerable on a Kindle Touch. That’s about as good as it’s going to get on that browser. 


Sadly, I did find that, as reported by Stephanie and Bryan Rieger, the Kindle considers itself to be in color, so the media query @media all and (monochrome) doesn’t match it and @media all and (color) does. Too bad! Speaking of Kindle and Stephanie Rieger, the Kindle Fire tablet’s browser is also a great cautionary tale about mistaken complacence about “standard” device screen widths like 480, here is an enlightening tweet:



Food for thought, Stephanie, food for thought…

p.s. Thanks to the observant folks in the community who have noticed that our nav, at wider widths, has drop-down elements that are not ideal in terms of usability. We‘re cooking up ideas about how to make this better! have actually made improvements to the tablet-version nav on touch devices since I started working on this post! More to come in Nav-Land.

Taking “Content First” Very Seriously

The new site stretches content-first thinking to its academic extremes

Whereas my personal theme for the second half of 2011 was about letting content go, 2012 seems to be the year I obsess about content: what is content, what does it mean, and what does it look like? How do we go about untangling the CMS mess we’ve built over the last decade-and-a-half? How should content be marked up? Stored? Transformed? Delivered to devices and clients?

With the new site, we got a chance to Think Very Deeply about content and our mobile experience. We got to explore some of the nagging questions that keep us (well, me, at least) up at night. I’m not going to profess to have the answer, nor am I going to assert that the (long) thinking, designing and development process we endured was without convulsions or struggle1. But I think we’ve been lucky in the opportunity to dig in.

Content is content is content is content…

At its core, is content. Human-readable content written by regular people. Being bold and brave (maybe it’s hubris), we started with content before any design happened.

We’re not, by far, the first to shout, “Hey, Content First!” That notion’s been around the block a few times. But the practical challenge lies in unmooring oneself from 15 years of executing web development and design in particular ways and trying new habits and processes on for size. What sounds straightforward—have a point first and then make it pretty—actually goes against a staggering amount of what we’ve become used to doing with our web projects.

In our case, we opted for writing and storing our content in static text files. We selected markdown for this project, specifically, pandoc-extended markdown with Cloud Four-specific post processing extensions. Phew. More on that sometime other than now. Important piece being: human-readable text in a loose but meaningful format.

What a transformation!

Our happy, respected content sits there on the filesystem, grinning mysteriously, versioned, simple, ready to serve whatever purpose it needs to serve. In our case, obviously, we want a web site, so we can transform that core content into a set of web pages to make up a site that works in web browsers.

You’ll note that a lot of this sounds like, um, duh, yeah, we’re web devs, we make web sites. But in peeling back and thinking this hard about content, web pages as HTML isn’t necessarily a given for every context that we might use this content. But let’s talk about web pages for our purposes today.

Our content is transformed using a somewhat magical tool called pandoc2, which processes it, plunks it in an HTML template and does some other miscellaneous things—out come HTML pages! These HTML pages are then pushed to the live server environment where they enjoy a performance-tuned, simple existence, just waiting for folks to look at them and enjoy their content.

Though the content changes from time to time—it’s versioned in a github repository—it isn’t actually dynamic, so serving it out of a database (here I am getting a bit pedantic again) provides more of a performance-maintenance drain than a boon. Or at least, that’s what I tell myself to feel awesome.

But what about the blog? Ain’t broke, don’t fix

As giddy as the simplicity of static content and transformations and a pure ultra magical shared philosophical language of core content makes me as a dev, I have to kneel to practicality and things that make sense sometimes.

WordPress is a blogging framework. It’s been around a long while, we’ve used it a long while, and it has the tools for, well, you know, blogging. We’re sticking with WordPress for our blog, though you may notice that our blog now lives a robustly independent existence as Heck, maybe I’ll get the exciting opportunity to futz around with partially-static WordPress options with John!

There’s a lot more to talk about

The site is intensely responsive. It uses some edgy CSS selectors to get its job done semantically. The process of separating content from presentation can be deeply, deeply hard and we have stuff to say about that. We’ve spent a lot of time optimizing performance. We’ve battled specific bugs (many we knew about, some we didn’t) to get the site to look reasonably decent across a lot of devices. We are doing unprecedented things with :before pseudo elements. Our media queries are in ems.

We’ll continue to talk about the specific cool stuff we experimented with to get the new site working in upcoming posts. But I wanted to give a quick, high-level look at what we did before getting lost in the details.

Here is a nice picture

  1. Static content pages and image content, managed in a github repository.
  2. Pandoc and other transformation processing.
  3. Layout, design and behavior resources shared between static web and our blog.
  4. Blog content stored in WP database.

Thank you, Cloud Four Team

I owe a great amount of gratitude to the brilliant team at Cloud Four. Thinking the new site through and building it wasn’t always easy, fun or even sane. We had to (uncomfortably) learn new ways to do things that we were quite competent at before thankyouverymuch. There were confounding moments. It took John 327 hours or whatever to get Haskell compiled3 on our shared development server so we could run pandoc. And Aileen endured my weird experiments with SASS.

  1. Sometimes there was downright silliness as I pushed to explore the pedantic edges of what we could pull off with just content
  2. Not actually magic, but written in Haskell, which is kind of the same thing to my inadequate brain. More about pandoc here.
  3. Not actually true. But it did take John quite some time—it was hard! So, thank you, John.