Category Archives: CSS

Going all-in on Flexbox

On a recent project we finally got to use Flexbox extensively for page layout. In the interests of increasing general knowledge about flexbox (including mine), I’ll explain a number of layouts that use flexbox extensively, organised in 3 sections:

  1. Main page layout (for a single-page JavaScript application)
  2. Fluid product grid and accordion-like summary box
  3. Product “cards” and “slabs”

Continue reading

Why mobile last?

In his post Mobile Last? Jonathan Stark recounts his experiences at a recent hackathon, where teams were given 48 hours to build an innovative web application. While he ensured as usual that the site he built looked and worked great on any device, he was dismayed that “only one of the top ten winning entries was even a little bit mobile friendly.” He concludes that “the vast majority of web professionals have not truly embraced mobile.”

Jonathan points out, correctly, that mobile devices are already the default connected device for most people, and that poor mobile experiences are driving users towards native apps. After all, he says, working mobile-first is not that hard, and asks:

Are you working mobile-first? If not, why not? If you are working mobile-first, how do you like it? What were the biggest challenges you faced in making the transition from desktop? What platforms are you targeting on mobile? Web? Native iOS/Android? Something else?

I thought I’d write a quick response.

I’d guess the top reason why front-end web developers are not working mobile-first is that they are usually not the visual designers for the sites they’re building, and the designs they receive from the visual designers will usually be desktop designs. Visual designers:

  • are likely to be more set in their ways of designing for the desktop, and unaware of the “mobile first” philosophy
  • are working in tools that are not responsive (such as Photoshop), and creating mobile mockups as well means a doubling of effort

Clients are also slow to adapt. Unless they are conceiving of their project as primarily a mobile site/app, they’ll expect to be sold the design on the strength of a desktop mockup. This is what most visual designers are used to delivering.

Finally, the front-end developer and everyone else on the team will be working on desktop systems, where it’s far easier to view the work in progress in desktop browsers. It takes extra effort to view the site in a mobile device or emulation thereof.

I’m usually the front-end developer in this equation. I am given a clear visual spec for the desktop, and it’s left up to me to make it responsive. It’s usually not that difficult, but it means starting by implementing the visual spec I have, i.e. the desktop design, and adapting it via media queries afterwards, resulting in a “mobile last” process.

Mobile last is somewhat inefficient, as it means redefining many rules. (It’s “subtractive”, where mobile first is “additive”.) But in my experience it’s not that bad. In my 2 most recent projects the responsive.less include file (containing all the styles dependent on media queries) accounted for only 179 of 1492 lines of CSS (11%) and 641 of 5047 (12%), and adds at most 3 or 4 extra days. It’s also a conceptually simple way of working. The “layering” of a mobile first stylesheet can make the stylesheet a lot harder to interpret and maintain.

I’m currently implementing quite a complex visual design, provided to me, as usual, as desktop mockups. I have been attempting to follow a mobile first approach, but have found it extremely difficult, given that I don’t know at the outset what a polished look will be at mobile sizes (since I don’t have mockups for it). I’ve ended up following a mobile-first approach in some areas of the CSS, and mobile-last in others. Rather than a single responsive.less include right at the end, every one of the 20-odd Less files is riddled with media queries. The whole thing is, I have to admit, a lot more complex and confusing.

If I were starting a new project where I am also the visual designer, or a project where the visual design is relatively simple, then I’d probably work mobile-first. (Photoshop plays quite a small role in such cases, as my ideal process is to do much of the design in the browser.) But that, alas, wouldn’t be a typical project.

I hope this provides some insights into why so many developers are currently not yet working mobile first. What are your experiences? Let me know in the comments below or @fjordaan

On December 11 Jonathan will be redesigning his personal site in front of a live audience – you can sign up for the webcast here. I’m sure it will be a very interesting demonstration of mobile-first development.

My experiences are with websites and web apps, rather than native iOS or Android. I test on iPhone and Android smartphones, 7″ tablets and 10″ tablets (both iOS and Android). I also use the “Responsive Design View” on Firefox and Chrome’s mobile device emulation.

About usIsotoma is a bespoke software development company based in York and London specialising in web apps, mobile apps and product design. If you’d like to know more you can review our work or get in touch.

Return of the FOUC

So, generally Firefox 3 did not have much impact on our sites. Besides the Kupu problem Andy mentioned, there were just a few small CSS-related glitches, but overall we did not have to scramble to roll out patches. However, on a site we’re currently working on, Firefox 3 showed a serious glitch I hadn’t seen for a long time: the Flash of Unstyled Content or FOUC, first described back in 2001. The page content displays un-styled for a split second before the stylesheet kicks in.

The bluerobot article is now outdated, but the problem occasionally still rears its head on more modern browsers. Since I’ve been using Firefox 3, I’ve been seeing it quite often, where Firefox 2 doesn’t. (I’m not saying there’s anything wrong with FF3, it’s probably just being less lax than FF2.) This article has a good explanation. In a nutshell, you see a FOUC whenever a script tries to access properties like scrollHeight or offsetWidth before the stylesheet has loaded. The solution is simply to have the CSS links above the JavaScript links in the HTML.
Here’s an example (until they fix it, anyway): getcloser.com, an ambitious HMV-sponsored social connector based on entertainment interests, designed by the clever bods at LBi. You can see in the <head> there’s 78KB of JavaScript followed by 151KB of CSS. Switch it round, and it’ll go away.