For building web sites and systems Engaging has a mantra of “mobile first second” as a twist on the no-longer-quite-so-new paradigm of “mobile first”. Does Engaging proceed this way simply because its mobile designs derive from extant desktop sites? Not always. Then because your dear developer/designer has mental grooves for desktop now two decades high and has not yet adapted to a web increasingly dominated by mobile? Perhaps. Perhaps not.

In designing for mobile the web site of friend and painter Juan Carlos Bronstein, we pared down the existing site then fed this new streamlining back to the big-screen version. Until doing so we’d thought the desktop design was just fine yet if we’d done mobile first we might have had a better desktop site with less work.

For instance, in each painting’s description we removed tool lines that separated the various texts; it turns out that their varying typographic styles is enough to divide them. And on the Works page, which displays dozens of paintings, we removed the box around each painting. We also removed white borders from around the site’s menu items.

Doesn’t all this suggest we’d have been better off doing mobile first? Well, these are relatively trivial changes; the fact remains that the big screen somehow allows for more exciting concepts that can more plausibly be adapted for smaller screens than a small-screen design can generate big-screen concepts. That is to say: graceful degradation beats progressive enhancement, at least at the ideational phase (for actual CSS implementation the opposite may be true). Mobile screens certainly do have their own excitement, being less displays to look at than objects to manipulate; we hold them close. And I’ve often preferred the mobile versions of Engaging-made sites with their intimacy and immediacy. But that is due I believe to their being a concentration of ideas produced for the larger version.

At any rate, it’s the fertility of design ideas and their adaptivity that are the proper criteria for deciding how to proceed, not the commonly-cited method of estimating the number of visitors who’ll use which screen size and designing for them. This is because you will be designing for all screens regardless.

Which means that for responsive design you’re not actually doing mobile nor desktop first anyway: like 3-dimensional chess (whatever that is), you’ve internalized that every component on the site needs to work at every size; you want your site to remain essentially itself no matter its dimensions. So it’s really a matter of “components first”, isn’t it? Indeed the advent of React as the new paradigm for web development makes concrete this approach — it’s components all the way down.

For a similar discussion, see “Mobile First Design: Why It’s Great and Why It Sucks” by Code My Views. The views there seem in alignment with mine here: go from big to small for ideas, then small to big for implementation, keeping both in mind throughout.

Since we’re talking about a painter’s site anyway: how would a painter do it? How to paint ostensibly the same painting on a big and on a small canvas? The most clunky would be just to scale down. Slightly more sophisticated would be selecting one more or more highlights. Or else show something completely different that nonetheless has the same spirit? Maybe the analogy is worthless because each painting is unique, so it’s a different painting if it’s a different size, and the method for one painting has no bearing on another. Perhaps this in itself is instructive: there’s no one way to do it.

Flex to the rescue

But let’s get down into some reeds. On the Works page, when eliminating the boxes around painting entries, it became clear that on a big screen their white backgrounds could merge to form a continuous row, akin to a gallery wall. All entries were set to float: left but when the row’s last entry cleared to the next row, the wall-to-wall background did not reach the entirety of the screen width, even though the entries’ container div did. How to eliminate this gap at the right side of the wall?

The solution marked the first time I’d used CSS3’s new flexbox in the wild. Removing the floats and setting the flex container to justify content: space-between did exactly what was needed. It did require eliminating the fixed width for each painting entry and instead setting a max-width, thereby letting their widths vary, which means that paintings are not precisely lined up vertically down the screen, but for Juan Carlos’s Works page at least this is arguably a good thing — it’s a less rigid grid.

Flexbox also helped with the site’s menu. Previously its position was fixed at top left, but on the small screen this meant that the masthead to its right got messily hidden underneath it, so the menu now had to be part of the layout flow, floated left as the masthead floated right. The problem was that as the screen narrowed the masthead’s inner text wouldn’t wrap, forcing the masthead to clear prematurely. Nothing helped with this — except again replacing floats with flex.

The menu then got fixed onscreen not in CSS but in JavaScript with the excellent Sticky Kit plugin for jQuery.

Penetrable CSS

I don’t know about you but as I build a web site my CSS gets into a terrible mess, often ending with a shouting match of “!important”s. Once a site is completed it’s vital to take some time to prune, sanify and beautify all that. For less struggle and fewer statements, a nice clean slate is especially important before adding media queries (Did somebody say “mobile first second”?). After all, CSS is code too and deserves comments wherever helpful and logic that’s easy to understand.

Cool kids turn away now: there’s no CSS pre-processing here. For one thing, the CSS these tools generate is impenetrable (sure, today the browsers have great developer tools for insights, much more powerful than View Source, but still). On this site the CSS file is actually a template in the ExpressionEngine content management system anyway, so that the entirety of the PHP language is available within the CSS if needed — though nothing was for this site, even if a couple of variables could have helped here and there.

All that said, I do appreciate the nesting that SCSS affords (though this too can be problematic as it seems in tension with cascading) so I now use indentation in my CSS to follow along with the DOM structure. Also, each element’s properties are alphabetized. One other formatting choice is to not skip a line for variations on an element.

PJAX for performance

To help speed things up, the site makes use of the CMS’s built-in caching functionality. The next performance gain is achieved by applying PJAX.

So now you can get a nice fast taste of painter Juan Carlos Bronstein on a device near — even very near — you.