Re: Mobile first vs desktop first

(I'm not really up-to-speed with where things are at the moment, so forgive
me if I go over old ground and waste your time for a moment...)

FWIW, the "mobile first"/"desktop first" thing seems like an artefact of
current technology and development practices. If all "mobile" devices had
superior feature support, then the debate wouldn't have the same context.
We're already at a point where the words "mobile" and "desktop" have no
clear meaning anymore. There are tablets with higher screen res than the
laptop I'm writing on; people are using smartphones in their homes;
"desktop" computers are starting to have retina displays and touch
interfaces; sometimes my laptop is exposed to slower connection speeds than
a smartphone; and so on.

We might also rapidly move into very different worlds of development such
as using (server-side) components as building blocks and switching out
whole chunks of HTML (and scoped CSS) when different browsing conditions
are met.

To more loosely couple the wording with today's dev landscape, it might be
worthwhile to think about how things can be explained more broadly, and use
"mobile first" as an example, contemporary manifestation of progressive
enhancement.



On 10 December 2012 08:23, Konopacki, Daniel <Daniel.Konopacki@disney.com>wrote:

> Agree. Mat's definitions about each are very good. I'd like to offer my
> opinion as to why one would do one approach over the other.
>
> Mobile first isn't necessarily just about the design of the site, but also
> the capabilities/limitations that said device has. It is highly unlikely
> that a desktop, or desktop-like system (i.e. TV browser) will ever be
> connected to anything but an ethernet/wifi connection. A mobile device,
> however, could go from such connectivity to 3G/4G connection. Because of
> this, special considerations have to be made for a mobile device beyond the
> physical dimensions of an image, such as bandwidth constraints, latency on
> a OTA connection, etc. Mobile first, then, puts the design/developer in the
> mindset that the site needs to handle a story set that doesn't always offer
> the most optimal connectivity options.
>
> For reference to latency, and what it means to mobile, here is an article
> from Ilya Grigorik (Google) about the topic (near the bottom):
> http://www.igvita.com/2012/07/19/latency-the-new-web-performance-bottleneck/
>
> From: Kevin Suttle <kevin@kevinsuttle.com>
> Date: Mon, 10 Dec 2012 08:09:29 -0800
> To: Mathew Marquis <mat@matmarquis.com>
> Cc: Marcos Caceres <w3c@marcosc.com>, "public-respimg@w3.org" <
> public-respimg@w3.org>
> Subject: Re: Mobile first vs desktop first
>
> Well said, Mat. Very comprehensive.
>
> *KS*
>
> On Dec 10, 2012, at 11:04 AM, Mathew Marquis <mat@matmarquis.com> wrote:
>
>
> On Dec 10, 2012, at 9:39 AM, Marcos Caceres wrote:
>
> Hi,
> The Editor of the img@srcset specification has requested that the working
> group clarify the differences between mobile first and desktop first.
>
> In particular, "Why would you need to put either mobile or desktop first?"
>
>
> I may not know much, but this—this I know.
>
>
> People with more experience than me in this area, I would appreciate:
>
> 1. a detailed description of both approaches.
>
>
> *Mobile-First*
>
> Mobile-first development—the most common approach to a responsive design,
> in my observation—means starting with the “mobile” styles first and
> building on them in layers, by way of `min-width` media queries. Typically
> a mobile layout will lean towards being more linear: a lot of UA-default
> `display: block` and `width: 100%`. This is the approach we took with
> BostonGlobe.com <http://bostonglobe.com/>, which has several major
> benefits:
>
> * Where desktop browser support for media queries is fairly solid and
> mobile browser support is something of an unknown, it ensures that the most
> sensible styles are served up by default, outside of any media queries.
> * In the event that a desktop browser doesn’t support media queries (and
> no polyfill is in use), the user receives a less complex—but still entirely
> usable—layout.
> * From a developer convenience standpoint, we’re not first coding the
> “desktop layout” and then overriding all of our custom styles as we build
> down. That would mean a much larger (set of) stylesheet(s), and a number of
> additional “where’s this style coming from” headaches.
>
> In summary: “*mobile-first development means starting with the
> smallest-screen layout and adding layout complexity as screen real estate
> permits*.”
>
>
> *Desktop-First*
>
> A desktop-first development approach, predictably, means putting together
> the “desktop” layout outside of any media queries, and then reducing the
> complexity of the layout and tailoring it for mobile in layers via
> `max-width` MQ. The benefit here is that we would deliver a desktop-centric
> layout to desktop browsers that don’t natively support media queries—more
> often than not, it’s for the sake of IE 6/7/8. I generally find this
> approach to be way more trouble than it’s worth fro a dev standpoint, and
> it does mean running the risk of delivering a more complex “desktop” layout
> to an older mobile browser that doesn’t understand media queries, but there
> may be situations where a responsive layout is being applied in an
> environment where it’s limited in scope to “tablet-size and up.” In this
> case, a desktop-first approach may make the most sense, where the desktop
> layout will still function as-expected on a slightly smaller tablet, but
> less essential optimizations can be made within `max-width` media queries.
>
> This is a common approach when retrofitting an existing desktop-centric
> site for mobile contexts, without the overhead of rebuilding the entire
> site as mobile-first—`max-width` media queries would allow mobile/tablet
> focused styles to be bolted on to an existing site with minimal overhead.
>
> In summary: “*desktop-first development means starting with the most
> complex, large-screen layout, and removing complexity as screen real estate
> becomes constrained*.”
>
>
> Mobile-first is my preferred approach, but there’s no “one true way” in
> any of this. I’m hoping we get more feedback from you guys on the list,
> here. The more information we have at our disposal, the stronger our case
> for a flexible solution to responsive images becomes. No pun intended.
>
>
> -M
>
>
>