Reading List: mobile development approaches

Just three links for this reading list, because they show a profound schism in the way people are thinking about building applications that have previously been desktop only and take them to mobile.

The schism is the same as we’ve long had on desktop. It’s simply: do you make your target audience as wide as possible, or do you only design for people who use the same technology as you do?

The nations’s favourite social-media based conference organiser thingy, Lanyrd, launched its mobile version two days ago. I don’t own an iThing, but I assume it’s great there, and it looks and works excellently on Opera Mini and Opera Mobile on Android.

Jake Archibald, JavaScript developer at Lanyrd, said

“Although we’re employing some ‘new and shiny’ browser features, we’ve taken the righteous path of progressive enhancement and been liberal with our testing and support. While most mobile offerings are targeted at particular devices or WebKit, our support includes quirky devices like the old Blackberry 9000 (yes, it still haunts people’s pockets), the Kindle, and even basic feature-phones if they can run Opera Mini. The site works as expected without JavaScript.

Compare this with the 37Signals’ blogpost yesterday, provocatively entitled Developing for old browsers is (almost) a thing of the past:

It used to be one of the biggest pains of web development. Juggling different browser versions and wasting endless hours coming up with workarounds and hacks. Thankfully, those troubles are now largely optional for many developers of the web.

What is this fabulous remedy that 37signals have found? Simply, ignoring users of browsers that you don’t want to support. “Supporting your browser is hard – let’s go shopping”, as Barbie says, or Regressive Ken-hancement in strict Computer Science terminology.

Compare this with Jake Archibald’s comment:

All it took was *not* doing everything wildly different to how you should develop a standard website.

Summarising this dichotomy is an excellent article Did we lose track of the big picture?:

It seems to me that we are slowly switching from publishing content for the Web, to making content accessible to Screen-Readers (SR) – from targeting users, to focusing on devices and modern browsers.

We write about new techniques without considering fall back mechanisms, we use ARIA “hacks” that look like anti-patterns and we use frameworks that have chosen to ignore oldIE.

If you read no other high-level articles this month, read that one.

4 Responses to “ Reading List: mobile development approaches ”

Comment by John Foliot

Because I’ve been known to beat dead horses in the past:

“it’s not “old tech” that you are supporting, it’s *YOUR USERS* that you are supporting – never lose sight of that!” – (me)

In this Bruce we are exactly in sync, and it seems to this humble observer that 37Signals are promoting themselves into a box-canyon. I am sure their competitors are wringing their hands in glee.

To be fair, their primary target audience is web-geeks (for the most part), although I wonder aloud how many of BaseCamp’s clients are working with their own client-base of less tech-savvy “owners”. Imagine contracting with a mechanic, only to later discover that he will only work with you if you have a late-model European car (<sniff> {looks down nose}). This is good business?

In the words of the late Xavier Cugat: “I would rather play Chiquita Banana and have my swimming pool than play Bach and starve.”

Comment by fvsch

A little over a year ago I wrote this article: Three Takes on Browser Compatibility. I highlighted three different strategies for browser support.

37signals picked the “aim for the top” strategy, which is especially interesting for modern web applications. Lanyrd used the “keep it low” strategy, which works for their mostly content-oriented website (there are some web app aspects to Lanyrd, but go to the home page or to a conference page and what you get is mostly information). Saying that 37signals could or even should do it like Lanyrd is as easy as it is misguided.

I welcome articles such as Thierry Koblentz’s, as there is a tendency for both untrained and trained-but-tired professionals to underestimate what you can achieve with progressive enhancement. We do need those kind of reminders. But progressive enhancement is no cure-all, and we should refrain from shaming people into using a particular strategy (suggesting they’re either stupid or lazy as you did with your Barbie comments, Bruce). It’s their project, their business model, their responsibility, not ours.

Finally, I strongly disagree with John who writes “it’s not ’old tech’ that you are supporting, it’s *YOUR USERS* that you are supporting”. Technically, “your users” are people actually using your product. If you build it to be compatible only with some specific tech, then all people who can’t or won’t use this tech are *not* your users. My best guess is that John refers to *potential customers or users that you SHOULD support*. Not sure if he means that in a moral or business sense, but both meanings would be highly debatable.

Comment by Chris Krycho

It boggles my mind that people got the idea that they could just stop supporting older browsers. I make a decision about IE6 in particular depending on whether the site is likely to generate enough traffic for IE6 usage to matter. (In my very small, personal sites over the last several years, the percentage of IE6 users has been so small as to be completely irrelevant, but for a larger-scale site, that’s just not true.) Responsive design, done right, should be the definition of progressive enhancement, and a “mobile-first” approach can actually provide really good fallback for older versions of IE if you do it right. Doing mobile-first as an excuse not to support those users is mind-bogglingly lazy.

Unfortunately, this situation certainly seems to validate everyone who said, “Browser-specific prefixes will be a bad idea; people will use them like they did IE-specific hacks back in the day!” I think a lot of the best designers said, “No, we won’t,” and they were right… about themselves. The reality, though, is that an enormous proportion of the designers and developers on the web are not reading A List Apart or actually paying attention to how Ethan Marcotte is saying to use responsive approaches. The best designers and developers are still using best practices. But there are lots of lazy designers out there who are not, and they are breaking the web. Again.

Maybe next time we’ll remember this lesson and take it to heart. Vendor prefixes were intended to be tools of progressive enhancement or graceful degradation; instead, they’ve become an excuse for bad practices. It shouldn’t have happened, but best practices are never implemented as broadly as they should be.

The user should always be the top priority. Not just the shiny new thing you can do.