W3C home > Mailing lists > Public > public-web-mobile@w3.org > September 2013

Re: Mobile, Web and Multi-device

From: Jo Rabin <jo@linguafranca.org>
Date: Wed, 25 Sep 2013 18:06:00 +0100
Cc: tomomi.imura@nokia.com, dom@w3.org, sa-takagi@kddi.com, public-web-mobile@w3.org
Message-Id: <9C3567AF-C871-4CB0-B88E-4AB891400190@linguafranca.org>
To: Marcos Caceres <w3c@marcosc.com>

On 25 Sep 2013, at 11:48, Marcos Caceres <w3c@marcosc.com> wrote:

> On Friday, 20 September 2013 at 22:22, tomomi.imura@nokia.com (mailto:tomomi.imura@nokia.com) wrote:
>> I am not trying to bring back the topic, but yes, classification of
>> "mobile" is getting too complicated these days.
> This is why it is best to avoid it: to ask, "what is mobile? What is a web app? what is a web page?" risk sending us down a rat hole that's rapidly morphing (it's really not that relevant and everyone will give you different definitions that will be neither fully wrong nor fully right - but 100% unhelpful). Those things are whatever those that build them want to call them - and not intervening or trying to define it is a good thing - that's what urban dictionary and wikipedia are for.  

I do think it's useful for us to say what we mean by the the word "Mobile" in name of our group, and use of the word in our charter. As mentioned on the call today, it's a scoping exercise, mainly, to my mind. 

To be clear, I am not interested in classifying devices, I'm interested in classifying the context of use, only part of which relates to the device in use. I'll publish a draft paper shortly. Hopefully it will gain immediate and massive consensus then we can just move on. :-)

> "Mobile web" is a red herring (just marketing speak), like "HTML5". Perhaps it used to mean something - specially in the days when content was not being created for portable computers; but now that we all "get it" (even if we all truly suck at defining it - i.e., "we know it when we see it"), it's becoming increasingly rare for a webs site to not be tailored to a range of screen sizes and input method AND for a device to not be able to adapt the content of sites to small screens and input methods. 

It would be useful to know if you have specific stats on "increasingly rare". And in any case the representation of the content on the screen is only part of the story.

> In other words, this is not new and the distinction is not relevant or even interesting  - it's a mostly solved problem (and has been for a long time through media queries and declarative solutions).

Media Queries helps a bit for sure, but that doesn't make the problem "mostly solved". For example (and we had this discussion in Coremob, which we should bring forward) one would like to be clear which assets referred to in a media query should be pre-emptively loaded (e.g. landscape vs portrait flips) vs those that should not. This is of some importance in a "mobile" environment meaning in this case that the connection has limited bandwidth and/or is paid for by usage.

>> It is not just the hand-held devices that connect to Internet on cellular
>> network anymore. How about wearables? Internet of Things?
>> Google Glass is probably considered mobile, and it has a web browser that
>> can access "mobile web" too.
> We need to be careful not to think of the Web this way. 
> As hopefully all agree, there is no such thing as the "mobile web" and no distinction to be made between "that's mobile", "that's *not* mobile", and "but is that mobile?"

If you mean "The Mobile Web" qua a distinct district, or neighbourhood of the Web, I agree, the time for that has passed. However there is indeed such a thing as "The Mobile Web" if one means the Web used in a wide variety of contexts whose properties vary distinctly from suppositions about The Desktop Context. 

To take Tomomi's example, Google Glass is mobile, not because people move around with it on, particularly, but because you interact with it in different ways ...

> I'm sorry to have to disagree with you, but users and developers *can* and *do* feel the difference between native and using HTML5 technologies (even in packaged apps). Where they are sometimes not feeling it is when they make use of vendor (read Webkit) specific extensions, as is done with Sencha-built apps. 
Well, as I understand it there's often a difference between the vendor provided browser and the vendor provided Web control. Different features and different implementations of the underlying technology, e.g. JS engine. So when making comparisons one needs to be clear about the execution environment, of course.


Received on Wednesday, 25 September 2013 17:06:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:58:59 UTC