Occasionally in conversation here the argument has fallen to pieces under the weight of a shapeless FUD surrounding how, where and when users are making use of their mobile browsers, and how that in turn should inform user interface design.

User interface genius Luke Wroblewski has just published a brief analysis of data sourced from tracking agency Compete's latest quarterly report [1] on this notion of differing context, which might help at least clarify some of the intangible ideas floating around here of late:

http://www.lukew.com/ff/entry.asp?1263

[1] http://blog.compete.com/2010/03/12/smartphone-owners-a-ready-and-willing-audience/ � how they established this information isn't all too clear.

Regards,
Barney Carroll

barney.carroll@...
07594 506 381

1. Privacy (as in I control it not the content provider)
2. Performance (as in how does the content feel to the customer)

 

Great stuff! We at Mobiletech.no have also done some efforts to quantify and document the (mobile) context. We believe that the context is made up of 5 "dimensions".
Location, as already mentioned, is one of them (both the lon/lat type and the "relative to home" location. Related to this we have named another dimension "User Profile" which can be whatever information is available about the end user (social networks, crm systems etc). And since we are talking mobile here, we have defined the Device (hardware, os, capabilities, the Run-time (browser, WRT, app etc) and Connection (how the end user is connected; wi-fi, 3g,2g, carrier etc.) Together, this data gives a pretty complete picture of how, when, where, who is consuming the content. Makes sense to report on too.
-@jonarnes

--- In mobile-web@yahoogroups.com, James Pearce <jamesgpearce@...> wrote:
>
> I've always loved this sort of thing. It paints empirical pictures about
> what you see people doing every day with their phones. For example, the huge
> SMS peak in the UK at 11pm when the pubs & bars used to close, and
> anomalously poor mobile web performance spikes during big sporting events or
> reality TV shows.
>
> It's almost a puzzle to try to figure out the reasons. What were people
> doing to cause these observations?
>
> Along those lines, can I humbly suggest Luke stops short of the next step in
> the logic? Having established that mobile handsets are used in lots of
> different contexts - no surprise, I hope, we should start to deduce what
> different types of service might be being used there. (The Compete report
> seems to think about this, but only from the point of view of contextual
> ads)
>
> "At home", "miscellaneous downtime", "waiting in line", "shopping", "at
> work", "watching TV", "commuting" - there are no doubt many types of site or
> service that are used across all these situations (Twitter? Email?), but
> surely traffic is not homogeneous across the board. There must be a skewing
> of the traffic of many types of service according to context.
>
> Presumably, traffic to shopping (or price comparison) sites is higher when
> shopping. Traffic & industry news sites when commuting. Celebrity news and
> tie-ins when watching TV. Mobile intranet sites (!) when at work.
>
> With that in mind, an individual site owner or designer should attempt the
> reverse mapping. Where are most of my users likely to be accessing my site
> from - or rather, what are they likely to be doing?
>
> I once pondered a private school's brochureware mobile web site - on the
> move wouldn't users be more likely parents on the school-run wanting daily
> news? Pupils wanting their timetable? Visitors wanting travel directions?
> (The important and expensive school selection process seems more likely to
> take place in a considered, airy, home context)
>
> Speaking personally, almost all my mobile web usage within cinemas is to
> movie database and review sites - checking information on movies for which
> I've just seen a trailer or poster.
>
> Do the creators of movie-related mobile web sites place a high priority on
> me, the 'in-cinema' persona?
>
> I hope so. They certainly should.
>
> James
> http://tripleodeon.com &c
>
> PS - shouldn't we try and get Luke on this mailing list? ;-)
>
> On 1 February 2011 08:03, Barney Carroll <barney.carroll@...> wrote:
>
> >
> >
> > Occasionally in conversation here the argument has fallen to pieces under
> > the weight of a shapeless FUD surrounding how, where and when users are
> > making use of their mobile browsers, and how that in turn should inform user
> > interface design.
> >
> > User interface genius Luke Wroblewski has just published a brief analysis
> > of data sourced from tracking agency Compete's latest quarterly report [1]
> > on this notion of differing context, which might help at least clarify some
> > of the intangible ideas floating around here of late:
> >
> > http://www.lukew.com/ff/entry.asp?1263
> >
> > [1]
> > http://blog.compete.com/2010/03/12/smartphone-owners-a-ready-and-willing-audience/ �
> > how they established this information isn't all too clear.
> >
> > Regards,
> > Barney Carroll
> >
> > barney.carroll@...
> > 07594 506 381
> >
> >
> >
>
>
>
> --
>
> James Pearce
> Sr Director, Developer Relations
> Sencha
>

 

Peter,

You've repeatedly shown a keen interest in the notion of 'movement' being the oft-ignored defining factor in mobile web usage, and bemoaned the lack of standardised APIs for accessing other low-level inferred features directly from the front-end.

Personally, I can only imagine extremely specific, very specialised services making use of such information. Maybe that's because of a lack of vision or imagination, but I am honestly stuck � for a maps application, I can see the point of this. But for 99.9% of mobile web services I struggle to see how I'd change the service to make it more or less relevant to the user's location/orientation/speed.

What kind of services are you envisioning?

Regards,
Barney Carroll

barney.carroll@...
07594 506 381

On 2 February 2011 14:17, Peter Cranstone <peter.cranstone@...> wrote:

IMO Context is made up of three dimensions - WWW as in Who, What & Where

1. Who you are - personal information you�re willing to share
2. What your device is capable of doing (and I mean everything)
3. Location - where you are, includes Lat, Long, Alt, Speed, Heading

And whatever solution you build that grabs a customers context you�ll need two more dimensions

1. Privacy (as in I control it not the content provider)
2. Performance (as in how does the content feel to the customer)

Privacy is the really big issue. It�s interesting to watch the folks over at Mozilla try and solve it with a �do not track header� coming from the browser. One tiny problem - no way of verifying if the content provider is honoring it. FAIL.

Peter
__________________________________
Peter J. Cranstone

M: 720.663.1752

5o9, Inc.
CEO

<5o9_logo_web_S.png>
Web Tools for Mobile

On Feb 2, 2011, at 6:15 AM, jonfravolda wrote:

 

Great stuff! We at Mobiletech.no have also done some efforts to quantify and document the (mobile) context. We believe that the context is made up of 5 "dimensions".
Location, as already mentioned, is one of them (both the lon/lat type and the "relative to home" location. Related to this we have named another dimension "User Profile" which can be whatever information is available about the end user (social networks, crm systems etc). And since we are talking mobile here, we have defined the Device (hardware, os, capabilities, the Run-time (browser, WRT, app etc) and Connection (how the end user is connected; wi-fi, 3g,2g, carrier etc.) Together, this data gives a pretty complete picture of how, when, where, who is consuming the content. Makes sense to report on too.
-@jonarnes

--- In mobile-web@yahoogroups.com, James Pearce <jamesgpearce@...> wrote:
>
> I've always loved this sort of thing. It paints empirical pictures about
> what you see people doing every day with their phones. For example, the huge
> SMS peak in the UK at 11pm when the pubs & bars used to close, and
> anomalously poor mobile web performance spikes during big sporting events or
> reality TV shows.
>
> It's almost a puzzle to try to figure out the reasons. What were people
> doing to cause these observations?
>
> Along those lines, can I humbly suggest Luke stops short of the next step in
> the logic? Having established that mobile handsets are used in lots of
> different contexts - no surprise, I hope, we should start to deduce what
> different types of service might be being used there. (The Compete report
> seems to think about this, but only from the point of view of contextual
> ads)
>
> "At home", "miscellaneous downtime", "waiting in line", "shopping", "at
> work", "watching TV", "commuting" - there are no doubt many types of site or
> service that are used across all these situations (Twitter? Email?), but
> surely traffic is not homogeneous across the board. There must be a skewing
> of the traffic of many types of service according to context.
>
> Presumably, traffic to shopping (or price comparison) sites is higher when
> shopping. Traffic & industry news sites when commuting. Celebrity news and
> tie-ins when watching TV. Mobile intranet sites (!) when at work.
>
> With that in mind, an individual site owner or designer should attempt the
> reverse mapping. Where are most of my users likely to be accessing my site
> from - or rather, what are they likely to be doing?
>
> I once pondered a private school's brochureware mobile web site - on the
> move wouldn't users be more likely parents on the school-run wanting daily
> news? Pupils wanting their timetable? Visitors wanting travel directions?
> (The important and expensive school selection process seems more likely to
> take place in a considered, airy, home context)
>
> Speaking personally, almost all my mobile web usage within cinemas is to
> movie database and review sites - checking information on movies for which
> I've just seen a trailer or poster.
>
> Do the creators of movie-related mobile web sites place a high priority on
> me, the 'in-cinema' persona?
>
> I hope so. They certainly should.
>
> James
> http://tripleodeon.com &c
>
> PS - shouldn't we try and get Luke on this mailing list? ;-)
>
> On 1 February 2011 08:03, Barney Carroll <barney.carroll@...> wrote:
>
> >
> >
> > Occasionally in conversation here the argument has fallen to pieces under
> > the weight of a shapeless FUD surrounding how, where and when users are
> > making use of their mobile browsers, and how that in turn should inform user
> > interface design.
> >
> > User interface genius Luke Wroblewski has just published a brief analysis
> > of data sourced from tracking agency Compete's latest quarterly report [1]
> > on this notion of differing context, which might help at least clarify some
> > of the intangible ideas floating around here of late:
> >
> > http://www.lukew.com/ff/entry.asp?1263
> >
> > [1]
> > http://blog.compete.com/2010/03/12/smartphone-owners-a-ready-and-willing-audience/ �
> > how they established this information isn't all too clear.
> >
> > Regards,
> > Barney Carroll
> >
> > barney.carroll@...
> > 07594 506 381
> >
> >
> >
>
>
>
> --
>
> James Pearce
> Sr Director, Developer Relations
> Sencha
>

 

Right, I think I see where you're heading (no pun intended). Would you say there needs to be a new W3-governed specifications for mobile web applications?

Regards,
Barney Carroll

barney.carroll@...
07594 506 381

On 2 February 2011 14:40, Peter Cranstone <peter.cranstone@...> wrote:

Barney,

Here�s a real live use case for you. 5 students at a local college in Boulder (CO) built this in about 3 hours. Problem statement - real time GPS enabled �local� search with turn by turn directions to your favorite �restaurant� with times given �based� on �your� current speed - they did three examples, driving, biking & walking. Do all of this in the browser. For bonus points - deliver personalized coupons based on me arriving at my destination in the next 15 minutes.

My issues around context are simple - grab as much as you can. lat/long is maybe ok for some, but others want speed, heading and altitude because that�s �all the context� around location (time is a give as it�s time stamped when you make the GPS call).

The W3C limited the call to protect the user. Yet every GPS device out there requires speed to compute time to destination. Without that you�re stumped.

Peter
__________________________________
Peter J. Cranstone

M: 720.663.1752

5o9, Inc.
CEO

<5o9_logo_web_S.png>
Web Tools for Mobile

On Feb 2, 2011, at 7:24 AM, Barney Carroll wrote:

 

Peter,

You've repeatedly shown a keen interest in the notion of 'movement' being the oft-ignored defining factor in mobile web usage, and bemoaned the lack of standardised APIs for accessing other low-level inferred features directly from the front-end.

Personally, I can only imagine extremely specific, very specialised services making use of such information. Maybe that's because of a lack of vision or imagination, but I am honestly stuck � for a maps application, I can see the point of this. But for 99.9% of mobile web services I struggle to see how I'd change the service to make it more or less relevant to the user's location/orientation/speed.

What kind of services are you envisioning?

Regards,
Barney Carroll

barney.carroll@...
07594 506 381

On 2 February 2011 14:17, Peter Cranstone <peter.cranstone@...> wrote:

IMO Context is made up of three dimensions - WWW as in Who, What & Where

1. Who you are - personal information you�re willing to share
2. What your device is capable of doing (and I mean everything)
3. Location - where you are, includes Lat, Long, Alt, Speed, Heading

And whatever solution you build that grabs a customers context you�ll need two more dimensions

1. Privacy (as in I control it not the content provider)
2. Performance (as in how does the content feel to the customer)

Privacy is the really big issue. It�s interesting to watch the folks over at Mozilla try and solve it with a �do not track header� coming from the browser. One tiny problem - no way of verifying if the content provider is honoring it. FAIL.

Peter
__________________________________
Peter J. Cranstone

M: 720.663.1752

5o9, Inc.
CEO

<5o9_logo_web_S.png>
Web Tools for Mobile

On Feb 2, 2011, at 6:15 AM, jonfravolda wrote:

 

Great stuff! We at Mobiletech.no have also done some efforts to quantify and document the (mobile) context. We believe that the context is made up of 5 "dimensions".
Location, as already mentioned, is one of them (both the lon/lat type and the "relative to home" location. Related to this we have named another dimension "User Profile" which can be whatever information is available about the end user (social networks, crm systems etc). And since we are talking mobile here, we have defined the Device (hardware, os, capabilities, the Run-time (browser, WRT, app etc) and Connection (how the end user is connected; wi-fi, 3g,2g, carrier etc.) Together, this data gives a pretty complete picture of how, when, where, who is consuming the content. Makes sense to report on too.
-@jonarnes

--- In mobile-web@yahoogroups.com, James Pearce <jamesgpearce@...> wrote:
>
> I've always loved this sort of thing. It paints empirical pictures about
> what you see people doing every day with their phones. For example, the huge
> SMS peak in the UK at 11pm when the pubs & bars used to close, and
> anomalously poor mobile web performance spikes during big sporting events or
> reality TV shows.
>
> It's almost a puzzle to try to figure out the reasons. What were people
> doing to cause these observations?
>
> Along those lines, can I humbly suggest Luke stops short of the next step in
> the logic? Having established that mobile handsets are used in lots of
> different contexts - no surprise, I hope, we should start to deduce what
> different types of service might be being used there. (The Compete report
> seems to think about this, but only from the point of view of contextual
> ads)
>
> "At home", "miscellaneous downtime", "waiting in line", "shopping", "at
> work", "watching TV", "commuting" - there are no doubt many types of site or
> service that are used across all these situations (Twitter? Email?), but
> surely traffic is not homogeneous across the board. There must be a skewing
> of the traffic of many types of service according to context.
>
> Presumably, traffic to shopping (or price comparison) sites is higher when
> shopping. Traffic & industry news sites when commuting. Celebrity news and
> tie-ins when watching TV. Mobile intranet sites (!) when at work.
>
> With that in mind, an individual site owner or designer should attempt the
> reverse mapping. Where are most of my users likely to be accessing my site
> from - or rather, what are they likely to be doing?
>
> I once pondered a private school's brochureware mobile web site - on the
> move wouldn't users be more likely parents on the school-run wanting daily
> news? Pupils wanting their timetable? Visitors wanting travel directions?
> (The important and expensive school selection process seems more likely to
> take place in a considered, airy, home context)
>
> Speaking personally, almost all my mobile web usage within cinemas is to
> movie database and review sites - checking information on movies for which
> I've just seen a trailer or poster.
>
> Do the creators of movie-related mobile web sites place a high priority on
> me, the 'in-cinema' persona?
>
> I hope so. They certainly should.
>
> James
> http://tripleodeon.com &c
>
> PS - shouldn't we try and get Luke on this mailing list? ;-)
>
> On 1 February 2011 08:03, Barney Carroll <barney.carroll@...> wrote:
>
> >
> >
> > Occasionally in conversation here the argument has fallen to pieces under
> > the weight of a shapeless FUD surrounding how, where and when users are
> > making use of their mobile browsers, and how that in turn should inform user
> > interface design.
> >
> > User interface genius Luke Wroblewski has just published a brief analysis
> > of data sourced from tracking agency Compete's latest quarterly report [1]
> > on this notion of differing context, which might help at least clarify some
> > of the intangible ideas floating around here of late:
> >
> > http://www.lukew.com/ff/entry.asp?1263
> >
> > [1]
> > http://blog.compete.com/2010/03/12/smartphone-owners-a-ready-and-willing-audience/ �
> > how they established this information isn't all too clear.
> >
> > Regards,
> > Barney Carroll
> >
> > barney.carroll@...
> > 07594 506 381
> >
> >
> >
>
>
>
> --
>
> James Pearce
> Sr Director, Developer Relations
> Sencha
>

 

You could argue that one of the reasons that the Web is effective today is that since its beginning the content has been suitable for consumption by all kinds of agents, not just user agents controlled by users - in particular I'm thinking of search engines, of course. 

In this vision of the future, how will sites expose their content so they can be found, or will they rely on the search engines instantiating and exercising their user-centric interfaces?

Jo

 

On 31 Jan 2011, at 23:43, James Pearce wrote:

 

More interestingly, this raises the other evolution that the web is undergoing.

Rather than sending vast documents of HTML every time a user does anything, our increasingly app-centric web is one where the server merely provides data (and security services) that a powerful client, which can bootstrap its own UI, can consume efficiently.

In the 'document web', the server/CMS did almost everything, and sent vast, architecturally-daft payloads. The browser just needed to turn tags into pixels. In the 'app web', even mobile web clients are now able to rival server-side logic (with MVC, local storage, offline use etc). The two sides of the wire are becoming more like sync-peers than the thick master and thin slave they once were.

This alters a lot of performance considerations. Yes, one might need to send more resources to the client to bootstrap the app in the first place, but once it's conjured up its own user-interface, most of the subsequent HTTP activity need be little more than lightweight JSON. (Of course this is essentially 'AJAX on steroids')

One of my missions for 2011 is to figure out how to get common content management systems to work in a way that acknowledges this new peer-like role, and the diminishment of the importance of the document. We don't need to throw CMS platforms out, just encourage them to play well with richer internet applications - mobile in particular of course.

James

http://tripleodeon.com &c

On 31 January 2011 15:21, Peter <peter.cranstone@...> wrote:

 

Agreed. The next problem is how do you measure that on Mobile? How do I know what I didn't need to send?

Peter

--- In mobile-web@yahoogroups.com, Kai Hendry <kai.hendry@...> wrote:

>
> On 29 January 2011 20:18, Peter <peter.cranstone@...> wrote:
> > Your web site has to be designed with performance in mind.
>
> Any site or application should be coded with performance in mind imo.
>
> It's unfortunate that so many people introduce CMS and libraries and
> heavyweight stack dependencies without seeing the trade off.
>

--

James Pearce

Sr Director, Developer Relations

Sencha

1. User Experience
2. Location
3. Device
4. Network

 

I think there's a confusion as to desirable (even possible) content traversal models being forced upon applications to which they are inherently not suited, not to mention a conflation of development and design best practice for end users with vague overarching political philosophies regarding the nature of the Internet.

When we (on the list) talk about mobile websites as opposed to apps, there's a largely implicit ideology of escaping the received wisdom of kingdoms of native applications, with our eyes set on a bright future of Internet-based constructs built on w3c technology.

This is where we need to clarify the term 'web app'. For the masses, a web app is a pretty vague term. For fad-enthused web design amateurs, it means something awesome on the Internet, probably relying on cloud storage/processing and HTTP communication with the end-user. For me, it's a website which is defined by its specialised interaction models as opposed to its content.

That's not to say there isn't an overlap: a lot of native apps would be pure websites in the old sense of the word if it weren't for paid-for content, which arguably requires obfuscation layers, an imperviousness to obvious hacks, closed content and authentication systems � which all add up to define pretty strict requirements for interaction models; hence apps. A friend of mine once opined that Spotify wouldn't get off the ground unless they delivered what the users were ultimately after, which is a totally transparent content API allowing us to interact with the goods in the ways we saw fit: I retorted that that would drive Spotify into the ground, effectively ruining them and the music industry by their current financial models. [1]

Other bona fide apps � that is to say, business interests aside � present granular content in highly specific ways that revolve around how the user can interact with or respond to it. There are all sorts of reasons � of varying levels of virtue and legitimacy, ranging from quality control to miserly content retention � for obfuscating these apps' content to external machine-processable standards so that the medium of the app proper enforces itself; but for plenty of things it's largely irrelevant and impossible to categorise micro content without the navigation & interaction paradigms defined by the interface:

Twitter & Facebook have APIs to allow varying degrees of content transparency, but just getting the content itself misses the point: you need to see it presented with the right interface, the right application, the right tools, for it to be relevant to the user.

At the end of the day, if we're talking in non-specific abstract terms, the argument boils down to solid data formats, sensible information architecture, good API design and business models. Let's separate these out from esoteric mobile design & development concerns: Then, if we can still see them, we can start pin-pointing the problems we're trying to resolve.

[1] This is a big issue. W3C front-end technology, almost by its very nature, is easily hackable to pieces because of its openness. As an example. HTML5 audio and video content will have a tough time replacing Flash because Flash can flexibly embed advertising or restrict content without the user just bypassing those measures. Relinquishing ultimate control over content is a significant reason investment in W3C front-end content presentation isn't what many optimistically thought it'd be by now. 

Regards,
Barney Carroll

barney.carroll@...
07594 506 381

On 8 February 2011 11:27, Jo Rabin <jo@...> wrote:

 

It's not just that they are difficult, maybe impossible to crawl, it's also that the servers and their tightly coupled apps a likely to form a closed rather than open ecosystem.

Eat your heart out generative Internet (OK, I've read The Future of the Internet and How to Stop It).

Jo

On 7 Feb 2011, at 19:20, James Pearce wrote:

 

Absolutely. Here's a web of of rich, uncrawlable applications.

Is it a co-incidence that suddenly curated directories of such things - euphemistically known as 'app stores' - are all the rage? Even for desktop web apps?

One way to read Google's Chrome Web App Store is as an admission of defeat.

Of course these directories suffer the same limitations that human-edited Yahoo and Tucows (circa 1995) suffered. But then again, they also offer an important educational role: showing regular users what's available when they previously had no idea. However, my suspicion is that users - and the industry as a whole - will soon outgrow them.

Sometime soon, someone will figure out to today's, increasingly mobile, 'web of apps' what Page Rank was to the 1990's 'web of documents': a seminal step forward in the uncurated discoverability within an open, effectively unbounded, environment. (This will also need to co-incide with users understanding that *anything's* out there somewhere, as the original keyword search proposition did).

The questions are: who is going to step up and implement this disruption, when will they do it, and how can I buy their stock?

James

http://tripleodeon.com &c

On 7 February 2011 10:37, Jo Rabin <jo@...> wrote:

 

You could argue that one of the reasons that the Web is effective today is that since its beginning the content has been suitable for consumption by all kinds of agents, not just user agents controlled by users - in particular I'm thinking of search engines, of course. 

In this vision of the future, how will sites expose their content so they can be found, or will they rely on the search engines instantiating and exercising their user-centric interfaces?

Jo

 

On 31 Jan 2011, at 23:43, James Pearce wrote:

 

More interestingly, this raises the other evolution that the web is undergoing.

Rather than sending vast documents of HTML every time a user does anything, our increasingly app-centric web is one where the server merely provides data (and security services) that a powerful client, which can bootstrap its own UI, can consume efficiently.

In the 'document web', the server/CMS did almost everything, and sent vast, architecturally-daft payloads. The browser just needed to turn tags into pixels. In the 'app web', even mobile web clients are now able to rival server-side logic (with MVC, local storage, offline use etc). The two sides of the wire are becoming more like sync-peers than the thick master and thin slave they once were.

This alters a lot of performance considerations. Yes, one might need to send more resources to the client to bootstrap the app in the first place, but once it's conjured up its own user-interface, most of the subsequent HTTP activity need be little more than lightweight JSON. (Of course this is essentially 'AJAX on steroids')

One of my missions for 2011 is to figure out how to get common content management systems to work in a way that acknowledges this new peer-like role, and the diminishment of the importance of the document. We don't need to throw CMS platforms out, just encourage them to play well with richer internet applications - mobile in particular of course.

James

http://tripleodeon.com &c

On 31 January 2011 15:21, Peter <peter.cranstone@...> wrote:

 

Agreed. The next problem is how do you measure that on Mobile? How do I know what I didn't need to send?

Peter

--- In mobile-web@yahoogroups.com, Kai Hendry <kai.hendry@...> wrote:

>
> On 29 January 2011 20:18, Peter <peter.cranstone@...> wrote:
> > Your web site has to be designed with performance in mind.
>
> Any site or application should be coded with performance in mind imo.
>
> It's unfortunate that so many people introduce CMS and libraries and
> heavyweight stack dependencies without seeing the trade off.
>

--

James Pearce

Sr Director, Developer Relations

Sencha

--

James Pearce

Sr Director, Developer Relations

Sencha

 

We are way off mobile topic :-)

So I expect most contemporary web apps to provide a meta-page which describes the API to me, a developer.

Of course a generic crawler probably can't do anything with this. I am sure it would be nice to have machine-readable descriptors to make sense of these, and perhaps that's what you're getting at. It's a great idea (as long as we learn from WSDL et al).

But then you said:

> servers and their tightly coupled apps a likely to form a closed rather than open ecosystem

And I don't know why. How is sending JSON-over-HTTP to a JavaScript app (in a browser) any less open than HTML-over-HTTP to a document rendering engine (in a browser)? Is {} less open than <>?

Architecturally, I prefer the former, since the semantics:syntax ratio is higher and I don't have to send the entire UI as a document (!) every time the user does something. What's the downside? It's only through phenomenal algorithmic gymnastics that search engines can make sense of the latter anyway.

But you imply an interesting point. Could crawlers benefit from instantiating apps for reasons *beyond* simply "indexing data"? - somehow "indexing functionality", "indexing user experience", or even "indexing purpose"?

That sounds exciting for everyone - and not just those mobile.

James

On 8 February 2011 13:01, Jo Rabin <jo@...> wrote:

 

Think I'm missing your point you're making. I like the fact that both GMail and my bank account are secure. But the concepts of openness and security are orthogonal, as you put it. You seem to be promoting the merits of secret and obscure protocol access as a form of security. The fact that it is not crawlable is good only because there's good security, not because the interface is proprietary.

There is a Google-provided human-centric Web interface to GMail (several, I think, for different devices) cleverly constructed using the most modern Web techniques. Also there are both proprietary and open APIs to GMail that use "proper" security.  So it is indeed crawlable (hundreds of different POP and IMAP programs and the Google Apps API show that to be the case). This means that you can use GMail without using those user interfaces or for the purposes that their creators assumed you would want to use GMail for. And that's great.

By contrast my bank assumes that I want to use it interactively and although it lets me download Excel spreadsheets insists that I interact with it , using their interface, to do so. From that perspective I am not pleased that it's not mashable - or in other words can only be used for the purposes that they thought I might want to use it for using /only/ their take on what might pass for good user interface design (if indeed they gave that a thought).

GMail and access to my bank account are examples of providing a service. Lots of applications are not like that and are about open discovery of information that the publisher wants to be freely available and the consumer wants to consume. Proprietary apis over commoditized bearers would not be the way to achieve either of their objectives.

Jo

On 8 Feb 2011, at 18:07, James Pearce wrote:

 

I've been laboring under the impression that 'apps vs documents', 'crawlable vs closed', 'W3C standard vs not' are three orthogonal vectors.

In the case of the GMail server and its 'tightly coupled app', for example, it's pleasing that it uses slivers of HTML and HTTP, but I am rather glad it isn't crawlable or mashable.

In fact, we should welcome a world in which rich client apps, built with web technologies, use data APIs over commoditized bearers. Machine-reading those is a lot easier than teasing the semantics out of vast slabs of HTML, which seem to remain unavoidably as much form as they are function.

The 'mobile vs desktop' is another vector altogether, so I suspect I've rather deviated from the topic.

James

On 8 February 2011 03:27, Jo Rabin <jo@...> wrote:

 

It's not just that they are difficult, maybe impossible to crawl, it's also that the servers and their tightly coupled apps a likely to form a closed rather than open ecosystem.

Eat your heart out generative Internet (OK, I've read The Future of the Internet and How to Stop It).

Jo

On 7 Feb 2011, at 19:20, James Pearce wrote:

 

Absolutely. Here's a web of of rich, uncrawlable applications.

Is it a co-incidence that suddenly curated directories of such things - euphemistically known as 'app stores' - are all the rage? Even for desktop web apps?

One way to read Google's Chrome Web App Store is as an admission of defeat.

Of course these directories suffer the same limitations that human-edited Yahoo and Tucows (circa 1995) suffered. But then again, they also offer an important educational role: showing regular users what's available when they previously had no idea. However, my suspicion is that users - and the industry as a whole - will soon outgrow them.

Sometime soon, someone will figure out to today's, increasingly mobile, 'web of apps' what Page Rank was to the 1990's 'web of documents': a seminal step forward in the uncurated discoverability within an open, effectively unbounded, environment. (This will also need to co-incide with users understanding that *anything's* out there somewhere, as the original keyword search proposition did).

The questions are: who is going to step up and implement this disruption, when will they do it, and how can I buy their stock?

James

http://tripleodeon.com &c

On 7 February 2011 10:37, Jo Rabin <jo@...> wrote:

 

You could argue that one of the reasons that the Web is effective today is that since its beginning the content has been suitable for consumption by all kinds of agents, not just user agents controlled by users - in particular I'm thinking of search engines, of course. 

In this vision of the future, how will sites expose their content so they can be found, or will they rely on the search engines instantiating and exercising their user-centric interfaces?

Jo

 

On 31 Jan 2011, at 23:43, James Pearce wrote:

 

More interestingly, this raises the other evolution that the web is undergoing.

Rather than sending vast documents of HTML every time a user does anything, our increasingly app-centric web is one where the server merely provides data (and security services) that a powerful client, which can bootstrap its own UI, can consume efficiently.

In the 'document web', the server/CMS did almost everything, and sent vast, architecturally-daft payloads. The browser just needed to turn tags into pixels. In the 'app web', even mobile web clients are now able to rival server-side logic (with MVC, local storage, offline use etc). The two sides of the wire are becoming more like sync-peers than the thick master and thin slave they once were.

This alters a lot of performance considerations. Yes, one might need to send more resources to the client to bootstrap the app in the first place, but once it's conjured up its own user-interface, most of the subsequent HTTP activity need be little more than lightweight JSON. (Of course this is essentially 'AJAX on steroids')

One of my missions for 2011 is to figure out how to get common content management systems to work in a way that acknowledges this new peer-like role, and the diminishment of the importance of the document. We don't need to throw CMS platforms out, just encourage them to play well with richer internet applications - mobile in particular of course.

James

http://tripleodeon.com &c

On 31 January 2011 15:21, Peter <peter.cranstone@...> wrote:

 

Agreed. The next problem is how do you measure that on Mobile? How do I know what I didn't need to send?

Peter

--- In mobile-web@yahoogroups.com, Kai Hendry <kai.hendry@...> wrote:

>
> On 29 January 2011 20:18, Peter <peter.cranstone@...> wrote:
> > Your web site has to be designed with performance in mind.
>
> Any site or application should be coded with performance in mind imo.
>
> It's unfortunate that so many people introduce CMS and libraries and
> heavyweight stack dependencies without seeing the trade off.
>

--

James Pearce

Sr Director, Developer Relations

Sencha

--

James Pearce

Sr Director, Developer Relations

Sencha

--

James Pearce

Sr Director, Developer Relations

Sencha

--

James Pearce

Sr Director, Developer Relations

Sencha

Strongly disagree.

Google's suite of web applications (Mail, Calendar, Docs, Maps) are incredibly powerful alternatives to apps that have traditionally resided on the dektop � and I can use them from nearly anywhere (a friend's feature phone, my office, whatever smartphone I may have, in an Internet caf� in Egypt�).

On the other end of the spectrum, we have applications whose entire use-case depends upon ubiquitous connectivity and remote data interaction, and are conceived of as web apps first, with various native apps often arising later on down the road (and falling by the wayside later): Facebook, Twitter, YouTube, etc (that whole 'web2.0' thing � interactive remote content paradigm).

The advantage of these applications sitting upon websites accessed via web browsers is colossal:

1. OS independence
2. Universal discovery & access via established, standardised protocols (HTTP)
3. Universal, open programming languages (W3C front-end & the XAMP stack)
4. Security (via the browser engine layer � ie sandboxed from other apps and the core OS and machine file structure)
5. Load on demand
6. Seamless application updates
7. External data connection ubiquity

The failings you mention, as far as I am concerned, stem from three crucial factors:

1. Connectivity dependence
2. Intermediary technology dependence (Java/ActiveX/Flash)
3. Interface design, and more specifically in the cases you mention (reading between the lines here), interaction design

Connectivity is a moot point. I'm sick to death of sites loading 1 MB of Javascript (especially after I've already started interacting with page elements that depend upon it), but they're becoming few and far between.

Mitigating the second requires our vigilance in painstakingly investigating ostensible indicators, testing and forking code. That's a huge ongoing task that will never be complete � no matter how many times I joke about it, I still regularly find myself spending atrocious amounts of time fixing IE6 incompatibilities, for instance: and I've had to hack 'stable' jQuery releases to compensate for this � but on the other hand our apps aren't crippled by the buggy first release which kills the franchise: something breaks, we fix it, every user gets the new version.

The third factor is something we have the unprecedented ability to change at any moment's time � users may be stuck without the ability or the will to upgrade their native applications (once again, IE6 steps up as a great example), but we can make sure that our sites/apps stay relevant forever: As long as the user has a browser and an Internet connection, the world is their oyster � it's just that the boundaries of developers' powers and responsibilities have moved.