Category Archives: HTML5

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.

HTML5 input type=number and decimals/floats in Chrome

As you may already know, HTML5 has introduced a number of new input types, one of which is the “number” type. As you might expect, this is a form field which accepts numeric input. So what happens in Chrome with the following HTML when we try to enter a decimal (floating point) number and submit the form?

<input type="number" />

Answer: Chrome pops up a validation error:

Decimal number failing validation

So what’s going on here? Is it a bug? It doesn’t fail in Firefox.

Well actually it’s not a bug; the form field is behaving as defined by the W3C. Numeric input fields can take additional attributes “min” and “step”, which constrain the range of values allowed in your input. The “min” attribute is fairly obvious: it’s the minimum value your number can be. The “step” attribute is less intuitive: by playing with different values, you would most likely work out that it controls the increase/decrease when clicking the up/down buttons on the field. If you input the number 1 and click the up arrow, it will increase to 2. This is because the default step is 1. So far, so obvious. However, the step attribute also determines which values are valid, so a step of 1 means you can enter 1, 2, 3 etc. and a step of 2 means you can enter 2, 4, 6 etc, and when you click the up/down buttons the number will increase/decrease by 2 each time, but entering 3 or 5 in the box will cause a validation error. You can also use a decimal value: for example, a step of 0.3 will allow values such as 0.3, 0.6, 0.9 etc, but not 1 or 2.

But what if you want all the numbers to be valid, integers and decimals alike? In this case, set step to “any”:

<input type="number" step="any" />

Now you don’t get a validation error. Yay! Also note that if you only want to accept positive numbers, you’ll want to add min=”0″.

So the lesson here is that the “step” attribute is linked to both the up/down buttons and the range of values allowed in the field. When step=”any”, the up/down buttons will increase/decrease the number by 1. As far as I can tell, there is no way to have step=”any” and an increase/decrease of more (or less) than 1 when clicking the up/down buttons. Feel free to enlighten me in the comments though!

About us: Isotoma 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.