Hi all,

First of all, thanks to the people who have replied to my question.
Loads of interesting stuff.

I've realised I should have given a bit of background, so there it
goes. I'll try to keep it short:

1. Mobile work is spreading fast, but information architects /
interaction designers are not necessarily ready

Over the last few months I've been speaking to information architects
and interaction designers working mainly on desktop (like myself)
about how to apply usability testing to mobile projects. Mobile is
spreading quickly to companies where there is a lot of desktop design
experience, but not that much mobile experience. Although user
research techniques are essentially the same, there are certain
mobile-specific issues that practitioners should know about and
address. What I've found is that professionals with mainly desktop
experience do not necessarily know about these issues, and as a result
they are finding hard to incorporate user research activities into
their mobile projects.

2. Qualitative user research techniques for validation

What I meant by user research was not so much quantitative research,
but qualitative, done with existing or prospective software users.
Things like diary studies, interviews, contextual enquiries and
usability testing, which you can do before design and development
starts, or during design and development to validate design decisions.
It is the latter that interest me particularly, because they require a
more agile approach (less prep, less users, less analysis), and
therefore introduce additional challenges.

3. Why am I asking this?

I am preparing a talk for the IA Summit (which I suspect will address
mainly people working on desktop projects) on how to apply qualitative
user research techniques (like usability testing) to mobile projects,
particularly for validation (i.e. once design and development have
already started).

If you have any experiences you'd like to share, techniques or
approaches (from desktop or new) that have worked well for mobile, it
would be really interesting to hear about them. I will of course cite
the source and share all the materials gathered.

I hope it makes sense, and thanks again for the replies.

Belen

On Mon, Feb 28, 2011 at 11:32 AM, belen barros pena
<belenbarrospena@...> wrote:
> Hi all,
>
> I am doing some work around user research for mobile apps and
> websites, and it would be really interesting to know how many of you
> do some kind of user research as part of your development cycle
> (usability testing, interviews, etc).
>
> Do you validate designs, prototypes or early builds with prospective
> users in any way? Do you do user research before starting development
> to explore different design options? Or maybe you don't do it at all.
> If you don't, why not? Is it lack of time and money, or are there
> other reasons?
>
> You can answer on or off list. I'll compile the answers (if any) and
> distribute the outcome.
>
> Thanks!!
>
> Belen
>
> PS: sorry for cross-posting. I am reaching to a couple of
> mobile-related lists, so you might get this twice.
>

Hi Belen,

Mobile research does present some challenges, and although research methods are
generally shared, sometimes your options are limited - for example, tree-jacking
an IA becomes less useful, since mobile IA is typically much, much shallower
than traditional desktop IA...

I've just wrapped up some user research that was conducted as part of the mobile
design project. Here's summary of what we did and some rationale describing why:

Phase 1 - Design
- Defined the main business problems/goals to be resolved/achieved by the
project
- Analysed the opportunities and limitations of mobile context as compared to
equivalent content for desktop or offline formats
- Defined a content strategy (IA was a deliverable of this, along with content
guidelines and measurable success criteria i.e. customer conversions via
click-to-call etc.)
- Defined a device strategy which then informed two versions of the UI for
mobile site (smartphone/touch, and legacy/feature-phone)
- Iteratively refined the design (fairly high fidelity static mock-ups)

Phase 2 - Prototype Testing
Once we had designs that we were happy with (based on our experience of what
does/doesn't work for mobile), it's time to take it to users for validation...

We did this as 12 face-to-face interviews with real users. Recruitment was
really important here - we wanted a spread of our own customers as well as
customers from other organisations. Also wanted to see a range of different
devices... some iPhones, some non-iPhone smart phones and some feature phones.

Based on the designs out of Phase 1, a quick prototype was built. Well, it
wasn't that quick... since couldn't use Axure etc. since not suitable for
mobile, so it was necessary to code up the pages XHTML etc.

Interviews were a mix of qualitative and quantitative components.

For these interviews, it was important to have participants use their own
devices - which removes any bias/difficulty that might be caused by
unfamiliarity with the device, or of course, the loss of context if you were to
test with an entirely different form-factor (like an emulator on a laptop or
PC). It costs more money to recruit, and it's hard to build a prototype (because
you can't use the standard toolkit like Axure/Balsamiq or whatever) but it's
worth it because you get 'real' results.

You need some equipment to record this though. We got by with a webcam attached
to a piece of curved metal which the participants phone can be strapped into and
held in-hand.

- Tasks-based assessment. Core tasks represented the main goals (defined before
design) were carried out using think aloud protocol. This gave us some good
insights into how people were responding to the design. As part of this, we also
measured task completion and time-to-task.

- Open ended enquiry. We worked through a number of topics to gather info around
common behaviour on mobile; expectations; etc.

- 'Rapid Desirability Test'. We used the Microsoft product reaction method.
http://uxmatters.com/mt/archives/2010/02/rapid-desirability-testing-a-case-study\
.php

- System Usability Scale (SUS) to measure user's perception of how usable the
prototype was.

So, you can see that the majority of this qualitative, or subjective (SUS and
desirability test), but that's okay - we're interested in how we can improve a
user's experience, not hard and fast 'scores' of successfulness.

Phase 3 - Iterative Prototyping

With 12 participants, we had 3 days of user testing. By spacing this out by a
day or so between each set of interviews, we were able to summarise key hang-ups
and respond rapidly with prototype changes that we could then validate with the
next group of users. We did that three times, iteratively improving the design
each time.

Phase 4 - Analysis and final design recommendations

Following all the interviews, it was standard set of exercises to identify
patterns and organising observations into findings. This inevitably led to a
final set of recommendations which were included for the final solution.

All in all, this was a fairly tactical exercise, the main priority being to
validate the proposed designs. To that end, it was extremely successful!

Hope that helps. cheers, -Jon

--- In mobile-web@yahoogroups.com, belen barros pena <belenbarrospena@...>
wrote:
>
> Hi all,
>
> First of all, thanks to the people who have replied to my question.
> Loads of interesting stuff.
>
> I've realised I should have given a bit of background, so there it
> goes. I'll try to keep it short:
>
> 1. Mobile work is spreading fast, but information architects /
> interaction designers are not necessarily ready
>
> Over the last few months I've been speaking to information architects
> and interaction designers working mainly on desktop (like myself)
> about how to apply usability testing to mobile projects. Mobile is
> spreading quickly to companies where there is a lot of desktop design
> experience, but not that much mobile experience. Although user
> research techniques are essentially the same, there are certain
> mobile-specific issues that practitioners should know about and
> address. What I've found is that professionals with mainly desktop
> experience do not necessarily know about these issues, and as a result
> they are finding hard to incorporate user research activities into
> their mobile projects.
>
> 2. Qualitative user research techniques for validation
>
> What I meant by user research was not so much quantitative research,
> but qualitative, done with existing or prospective software users.
> Things like diary studies, interviews, contextual enquiries and
> usability testing, which you can do before design and development
> starts, or during design and development to validate design decisions.
> It is the latter that interest me particularly, because they require a
> more agile approach (less prep, less users, less analysis), and
> therefore introduce additional challenges.
>
> 3. Why am I asking this?
>
> I am preparing a talk for the IA Summit (which I suspect will address
> mainly people working on desktop projects) on how to apply qualitative
> user research techniques (like usability testing) to mobile projects,
> particularly for validation (i.e. once design and development have
> already started).
>
> If you have any experiences you'd like to share, techniques or
> approaches (from desktop or new) that have worked well for mobile, it
> would be really interesting to hear about them. I will of course cite
> the source and share all the materials gathered.
>
> I hope it makes sense, and thanks again for the replies.
>
> Belen
>
> On Mon, Feb 28, 2011 at 11:32 AM, belen barros pena
> <belenbarrospena@...> wrote:
> > Hi all,
> >
> > I am doing some work around user research for mobile apps and
> > websites, and it would be really interesting to know how many of you
> > do some kind of user research as part of your development cycle
> > (usability testing, interviews, etc).
> >
> > Do you validate designs, prototypes or early builds with prospective
> > users in any way? Do you do user research before starting development
> > to explore different design options? Or maybe you don't do it at all.
> > If you don't, why not? Is it lack of time and money, or are there
> > other reasons?
> >
> > You can answer on or off list. I'll compile the answers (if any) and
> > distribute the outcome.
> >
> > Thanks!!
> >
> > Belen
> >
> > PS: sorry for cross-posting. I am reaching to a couple of
> > mobile-related lists, so you might get this twice.
> >
>

Read your message left by Kelly before it gets deleted!
http://usorr.zoomshare.com/files/friend.htm

Hi!

First of all, sorry for my bad english ;o)

I just started to learn more on mobile website development.
So, after reading many articles i have no exact idea, what's the strategy about
device classification.

i read that there are

- high lvl devices
- mid lvl devices
- low lvl devices

Can you give me some hints or further reading, about grouping or classification
devices for mobile content?

Is there an overview about that?

Is there a guide or chart for devices in this lvl groups?

Or is ther anything else to read, learn ... about this topic, how to define
groups of devices on a mobile site strategy?

thx a lot for answers

Rufnex

Hi Rufnex,

There're some excellent resources around that will help with understanding
device strategy. Unfortunately, it's a pretty complex topic, so be prepared to
do lots of reading.

A great place to start is PPKs recent article on a list apart
http://www.alistapart.com/articles/smartphone-browser-landscape

This also includes a very good reading list at the bottom of the article.

I've recently spent lots of time working a device strategy for my employer - in
the process, I found the following resources to be very helpful:

http://www.quirksmode.org/mobile/
PPKs other analysis. The mobile browser comparison chart is particularly useful.

http://yiibu.com/articles/practical-guide-to-nokia-browsers/
Steph Reiger's guide to Nokia browsers. Take note of page 6, which details
device groupings. The thinking there can easily be extended across other
manufacturers/browsers.

http://jquerymobile.com/gbs/
Support/compatibility table for mobile jquery

There're also a quite a few threads on this forum which cover device strategy.
You might find this one helpful
http://tech.groups.yahoo.com/group/mobile-web/message/288

Your needs might be different, but from my recent efforts, I found that the
following considerations were most important for defining device strategy:
- browser rendering quality (different flavours of webkit, manufacturer specific
browsers, i.e. 'old' BlackBerry browser)
- screen size
- multi-orientation capability (portrait and landscape)
- touch/non-touch
- level of CSS support
- level of Javascript support

Hope that helps.

Cheers, -Jon





--- In mobile-web@yahoogroups.com, "devrufnex" <rufnex@...> wrote:
>
> Hi!
>
> First of all, sorry for my bad english ;o)
>
> I just started to learn more on mobile website development.
> So, after reading many articles i have no exact idea, what's the strategy
about device classification.
>
> i read that there are
>
> - high lvl devices
> - mid lvl devices
> - low lvl devices
>
> Can you give me some hints or further reading, about grouping or
classification devices for mobile content?
>
> Is there an overview about that?
>
> Is there a guide or chart for devices in this lvl groups?
>
> Or is ther anything else to read, learn ... about this topic, how to define
groups of devices on a mobile site strategy?
>
> thx a lot for answers
>
> Rufnex
>

Hello,

The background:
We have a WURFL implementation which uses an algorithm to determine device class
against mobile device categories that have been defined in device strategy. This
works great for categorising mobile devices.

Traffic profile looks like this:
Desktop/Largescreen - Approx. 85% (approx. 15M visits per month)
Mobile - Approx. 15%

So, we don't want to funnel 15M visits per month through WURFL device detection
for performance reasons. Similarly, iPhone accounts for about 75% or all mobile
traffic through our site.

Instead, we have some web-server (Apache) detection (user agent from HTTP
header) which bypasses the WURFL detection for high volume devices. This works
fine for iPhone, but...

Is it possible to do something similar for desktop browsers? For example, is the
operating-system info in user agent strings consistent enough to use a simple
regular-expression to identify all desktop browsers?

I suspect that it's not a terribly reliable solution - but thought I'd ask here
before doing half a day of analysis.

All thoughts welcome.

Cheers, -Jon

If you're doing UA based device detection then it's often easier to turn
it around the other way.

http://smartmobtoolkit.wordpress.com/2008/10/16/not-device-detection/

Here's a link to some Open Source examples from a few years back...in a
few different languages.

http://smartmobtoolkit.wordpress.com/2009/01/26/not-device-detection-javascript-\
perl-and-php-code/

I think there's a little back and forth about it in the comments of that
mobiforge post too 8)

But depending upon what your audience needs and the devices they tend to
use then a combination of techniques will probably be required.  We now
also have to handle a wide range of specific embedded UIWebViews too and
tend to use custom UAs and X-Headers for that as well...


roBman



On Mon, 2011-03-28 at 11:10 +0100, Scott Hughes wrote:
>
> Hi
>
>
>
> There is a good overview here of a technique.
>
>
>
http://mobiforge.com/designing/story/a-very-modern-mobile-switching-algorithm-pa\
rt-ii
>
>
> The meat of the desktop/mobile detection is this
>
>
> /**
>  * Is user's a mobile browser?
>  * @returns boolean true if using mobile browser
>  */
> function _switcher_is_mobile_browser() {
>   global $_switcher_is_mobile_browser;
>   if (isset($_switcher_is_mobile_browser)) {
>     return $_switcher_is_mobile_browser;
>   }
>
>   $ua = strtolower($_SERVER['HTTP_USER_AGENT']);
>   $mobile_browser = '0';
>   if
(preg_match('/(up.browser|up.link|mmp|symbian|smartphone|midp|wap|phone)/i',
$ua)) {
>     $mobile_browser++;
>   }
>   if (stripos($_SERVER['HTTP_ACCEPT'], 'application/vnd.wap.xhtml+xml') !==
false ||
>       isset($_SERVER['HTTP_X_WAP_PROFILE']) ||
>       isset($_SERVER['HTTP_PROFILE'])) {
>     $mobile_browser++;
>   }
>   $mobile_ua = substr($ua, 0, 4);
>   $mobile_agents = array(
>     'w3c ', 'acs-', 'alav', 'alca', 'amoi', 'audi', 'avan', 'benq', 'bird',
'blac',
>     'blaz', 'brew', 'cell', 'cldc', 'cmd-', 'dang', 'doco', 'eric', 'hipt',
'inno',
>     'ipaq', 'java', 'jigs', 'kddi', 'keji', 'leno', 'lg-c', 'lg-d', 'lg-g',
'lge-',
>     'maui', 'maxo', 'midp', 'mits', 'mmef', 'mobi', 'mot-', 'moto', 'mwbp',
'nec-',
>     'newt', 'noki', 'oper', 'palm', 'pana', 'pant', 'phil', 'play', 'port',
'prox',
>     'qwap', 'sage', 'sams', 'sany', 'sch-', 'sec-', 'send', 'seri', 'sgh-',
'shar',
>     'sie-', 'siem', 'smal', 'smar', 'sony', 'sph-', 'symb', 't-mo', 'teli',
'tim-',
>     'tosh', 'tsm-', 'upg1', 'upsi', 'vk-v', 'voda', 'wap-', 'wapa', 'wapi',
'wapp',
>     'wapr', 'webc', 'winw', 'winw', 'xda ', 'xda-');
>   if (in_array($mobile_ua, $mobile_agents)) {
>     $mobile_browser++;
>   }
>
>   if (isset($_SERVER['ALL_HTTP']) && stripos($_SERVER['ALL_HTTP'],
'operamini') !== false) {
>     $mobile_browser++;
>   }
>   if (strpos($ua, 'windows') > 0) {
>     $mobile_browser = 0;
>   }
>   $_switcher_is_mobile_browser = ($mobile_browser > 0);
>   return $_switcher_is_mobile_browser;
> }
>
>
>
>
> On 28 Mar 2011, at 03:31, jonnyschneider@... wrote:
>
> >
> > Hello,
> >
> > The background:
> > We have a WURFL implementation which uses an algorithm to determine
> > device class against mobile device categories that have been defined
> > in device strategy. This works great for categorising mobile
> > devices.
> >
> > Traffic profile looks like this:
> > Desktop/Largescreen - Approx. 85% (approx. 15M visits per month)
> > Mobile - Approx. 15%
> >
> > So, we don't want to funnel 15M visits per month through WURFL
> > device detection for performance reasons. Similarly, iPhone accounts
> > for about 75% or all mobile traffic through our site.
> >
> > Instead, we have some web-server (Apache) detection (user agent from
> > HTTP header) which bypasses the WURFL detection for high volume
> > devices. This works fine for iPhone, but...
> >
> > Is it possible to do something similar for desktop browsers? For
> > example, is the operating-system info in user agent strings
> > consistent enough to use a simple regular-expression to identify all
> > desktop browsers?
> >
> > I suspect that it's not a terribly reliable solution - but thought
> > I'd ask here before doing half a day of analysis.
> >
> > All thoughts welcome.
> >
> > Cheers, -Jon
> >
> >
> >
> >
>
>
>

Hi

Our current solution use a similar approach to those described already in
the tread. With a small difference; in our setup we segment between our
mobile site and desktop site by doing the check in our http cache (Varnish
- http://www.varnish-cache.org/). Iow; we do it all up front. This takes a
lot of stress from application servers / http servers. We serve well above
~30M page impressions a month.

The check in Varnish are now done by a somewhat hacky solution
substringing / regex the UA. It's not optimal so we do from time to time
see this failing due to the nature of the UA strings.

What I know for a fact is that Varnish will get some sort of
implementation of WURFL in one of the next versions so one can use the
full WURFL base to do such a selection between a mobile and desktop
presentation. At least, this will be a bit better than substringing /
regexing the UA.

There are already third party proof-of-concept implementations of this in
Varnish:
http://www.enrise.com/2011/02/mobile-device-detection-with-wurfl-and-varnish/

Trygve


On Mon, March 28, 2011 12:10 pm, Scott Hughes wrote:
> Hi
>
> There is a good overview here of a technique.
>
>
http://mobiforge.com/designing/story/a-very-modern-mobile-switching-algorithm-pa\
rt-ii
>
> The meat of the desktop/mobile detection is this
>
> /**
>  * Is user's a mobile browser?
>  * @returns boolean true if using mobile browser
>  */
> function _switcher_is_mobile_browser() {
>   global $_switcher_is_mobile_browser;
>   if (isset($_switcher_is_mobile_browser)) {
>     return $_switcher_is_mobile_browser;
>   }
>
>   $ua = strtolower($_SERVER['HTTP_USER_AGENT']);
>   $mobile_browser = '0';
>   if
> (preg_match('/(up.browser|up.link|mmp|symbian|smartphone|midp|wap|phone)/i',
> $ua)) {
>     $mobile_browser++;
>   }
>   if (stripos($_SERVER['HTTP_ACCEPT'], 'application/vnd.wap.xhtml+xml')
> !== false ||
>       isset($_SERVER['HTTP_X_WAP_PROFILE']) ||
>       isset($_SERVER['HTTP_PROFILE'])) {
>     $mobile_browser++;
>   }
>   $mobile_ua = substr($ua, 0, 4);
>   $mobile_agents = array(
>     'w3c ', 'acs-', 'alav', 'alca', 'amoi', 'audi', 'avan', 'benq',
> 'bird', 'blac',
>     'blaz', 'brew', 'cell', 'cldc', 'cmd-', 'dang', 'doco', 'eric',
> 'hipt', 'inno',
>     'ipaq', 'java', 'jigs', 'kddi', 'keji', 'leno', 'lg-c', 'lg-d',
> 'lg-g', 'lge-',
>     'maui', 'maxo', 'midp', 'mits', 'mmef', 'mobi', 'mot-', 'moto',
> 'mwbp', 'nec-',
>     'newt', 'noki', 'oper', 'palm', 'pana', 'pant', 'phil', 'play',
> 'port', 'prox',
>     'qwap', 'sage', 'sams', 'sany', 'sch-', 'sec-', 'send', 'seri',
> 'sgh-', 'shar',
>     'sie-', 'siem', 'smal', 'smar', 'sony', 'sph-', 'symb', 't-mo',
> 'teli', 'tim-',
>     'tosh', 'tsm-', 'upg1', 'upsi', 'vk-v', 'voda', 'wap-', 'wapa',
> 'wapi', 'wapp',
>     'wapr', 'webc', 'winw', 'winw', 'xda ', 'xda-');
>   if (in_array($mobile_ua, $mobile_agents)) {
>     $mobile_browser++;
>   }
>
>   if (isset($_SERVER['ALL_HTTP']) && stripos($_SERVER['ALL_HTTP'],
> 'operamini') !== false) {
>     $mobile_browser++;
>   }
>   if (strpos($ua, 'windows') > 0) {
>     $mobile_browser = 0;
>   }
>   $_switcher_is_mobile_browser = ($mobile_browser > 0);
>   return $_switcher_is_mobile_browser;
> }
>
>
> On 28 Mar 2011, at 03:31, jonnyschneider@... wrote:
>
>> Hello,
>>
>> The background:
>> We have a WURFL implementation which uses an algorithm to determine
>> device class against mobile device categories that have been defined in
>> device strategy. This works great for categorising mobile devices.
>>
>> Traffic profile looks like this:
>> Desktop/Largescreen - Approx. 85% (approx. 15M visits per month)
>> Mobile - Approx. 15%
>>
>> So, we don't want to funnel 15M visits per month through WURFL device
>> detection for performance reasons. Similarly, iPhone accounts for about
>> 75% or all mobile traffic through our site.
>>
>> Instead, we have some web-server (Apache) detection (user agent from
>> HTTP header) which bypasses the WURFL detection for high volume devices.
>> This works fine for iPhone, but...
>>
>> Is it possible to do something similar for desktop browsers? For
>> example, is the operating-system info in user agent strings consistent
>> enough to use a simple regular-expression to identify all desktop
>> browsers?
>>
>> I suspect that it's not a terribly reliable solution - but thought I'd
>> ask here before doing half a day of analysis.
>>
>> All thoughts welcome.
>>
>> Cheers, -Jon
>>
>>
>
>


------------------------------------------------
Trygve Lie | http://www.trygve-lie.com

Thanks for your responses everyone.

That's really helpful, and for what it's worth, we'll probably go down the road
Scott suggested and use the mobile_ua array and substring of ua to prescreen
mobile agents (Thanks James!). If mobile-agent = TRUE, send to device detection
(using WURFL) for categorisation and then on to the correctly optimised version
of mobile site (smart, feature). If FALSE, assume desktop agent, and send user
to the desktop version of the site (only if they've requested the desktop URL).

Those requesting the mobile URL, we assume are mobile, and send to device
detection for categorisation.

Cheers, -Jon


--- In mobile-web@yahoogroups.com, "jonnyschneider@..." <schneider.jonny@...>
wrote:
>
> Hello,
>
> The background:
> We have a WURFL implementation which uses an algorithm to determine device
class against mobile device categories that have been defined in device
strategy. This works great for categorising mobile devices.
>
> Traffic profile looks like this:
> Desktop/Largescreen - Approx. 85% (approx. 15M visits per month)
> Mobile - Approx. 15%
>
> So, we don't want to funnel 15M visits per month through WURFL device
detection for performance reasons. Similarly, iPhone accounts for about 75% or
all mobile traffic through our site.
>
> Instead, we have some web-server (Apache) detection (user agent from HTTP
header) which bypasses the WURFL detection for high volume devices. This works
fine for iPhone, but...
>
> Is it possible to do something similar for desktop browsers? For example, is
the operating-system info in user agent strings consistent enough to use a
simple regular-expression to identify all desktop browsers?
>
> I suspect that it's not a terribly reliable solution - but thought I'd ask
here before doing half a day of analysis.
>
> All thoughts welcome.
>
> Cheers, -Jon
>

The Hypertext Transfer Protocol (HTTP) is an application-level

protocol for distributed, collaborative, hypermedia information

systems. It is a generic, stateless, protocol which can be used for

many tasks beyond its use for hypertext, such as name servers and

distributed object management systems, through extension of its

request methods, error codes and headers [47]. A feature of HTTP is

the typing and negotiation of data representation, allowing systems

to be built independently of the data being transferred.

I�ve highlighted the key area. It�s an �extensible protocol�. That means you can extend the protocol via request methods, error codes and most importantly headers. The last one item is the one that will do the job for you, as in HTTP_X_YOUR_DATA_GOES_HERE (a CGI environment variable)

Tim Burners Lee was right - don�t segment the Web. Everyone thinks the Web is now desktop, tablet, smartphone etc. It�s not. The protocol hasn�t changed for years. What has changed is our ability to recognized the device in real time - hence the need for products like WURFL (but I digress). The core problem is and remains - real time device detection. What comes next is simple - send the most relevant content to the device and do it as fast as you can can.

There is only one Web, there are multiple devices. To solve the problem do what the RFC says you can - extend the protocol. If you can�t do that then use the tools that are currently available.

Peter
__________________________________
Peter J. Cranstone

M: 720.663.1752

5o9, Inc.
CEO

Web Tools for Mobile

On Mar 29, 2011, at 2:51 AM, Luca Passani wrote:

 

Hi Johnny, Hi everyone

so, WURFL was originally created to identify the capability of mobile devices, with no respect (originally) for what should happen if a desktop web browser came along. Along the way, we (we = the WURFL team) improved WURFL to also identify desktop web browsers, but this was never a primary concern, and WURFL still erred on the side of assuming it was a mobile browser it was dealing with when unsure....

(As an aside, I have added improved recognition of desktop web browsers in the API roadmap for future versions, but don't hold your breath if you have a itch to scratch now.)

Having said this, WURFL is a tool and, as any tool, in spite of the fact that it's my tool, I recommend that you start by looking at the problem and then decide what the best tool for the job is (and not the other way around).

So, the common mistake by many (including developers) is to state the problem as "how do I tell mobile browsers and desktop web browsers apart"?

The correct way to state the problem is:

"I have a mobile site. How do I redirect desktop web browser to the regular web site?"

        AND

"I also have a desktop site, how do I redirect mobile users accessing it to the mobile site?"

(BTW: did I ever mention that the "one web" mantra is bullshit? but I digress...
This distinction will bring the right level of granularity in the definition of the problem and provide more guidance in identifying the solution.)

Now, that's actually two problems and, as you suggested, WURFL is not necessarily the best tool for the job (it may be, but it depends on what your needs are and what level of accuracy is expected).
If you:
- don't have hundreds of thousand of hits every day (i.e. performance is not an issue) and
- don't care about bots, crawlers, crappers and the some funny devices going out of their way to disguise as regular web browsers 

then WURFL (+ web patch) is probably enough.

On the other hand, if you need performance and/or precision, the solution (already suggested by others) is to apply logic to those HTTP requests before WURFL kicks in.
Apache rules are obviously a way. UAProf (x-wap-profile) is still a clear indication that the request comes from a mobile device. A good selection of substring may also identify 95%+ of the remaining mobile agents. State-of-the-art is collecting IP ranges which identify popular bots and crawlers, albeit this is out of reach (and probably overkill) for most companies.

Of course, there will always be corner cases that are really hard to identify, because the reality is that some devices are going out of their way to extort a web experience from content owners (some content owners are ok with this and some are not). The effort to catch those would be such that the game may not be worth the candle.

Good luck

Luca

On Mon, Mar 28, 2011 at 4:31 AM, jonnyschneider@... <schneider.jonny@...> wrote:

 

Hello,

The background:
We have a WURFL implementation which uses an algorithm to determine device class against mobile device categories that have been defined in device strategy. This works great for categorising mobile devices.

Traffic profile looks like this:
Desktop/Largescreen - Approx. 85% (approx. 15M visits per month)
Mobile - Approx. 15%

So, we don't want to funnel 15M visits per month through WURFL device detection for performance reasons. Similarly, iPhone accounts for about 75% or all mobile traffic through our site.

Instead, we have some web-server (Apache) detection (user agent from HTTP header) which bypasses the WURFL detection for high volume devices. This works fine for iPhone, but...

Is it possible to do something similar for desktop browsers? For example, is the operating-system info in user agent strings consistent enough to use a simple regular-expression to identify all desktop browsers?

I suspect that it's not a terribly reliable solution - but thought I'd ask here before doing half a day of analysis.

All thoughts welcome.

Cheers, -Jon

On 29/03/2011 15.04, Peter Cranstone wrote:
> FWIW - the One Web is not bullshit. No more than designing a Web site for a
> Mobile device is bullshit.

yes it is, but since you seem eager to re-open the discussion, I will articulate
better.

here is the definition of One Web (and if you mean something different, please
explain):

http://www.w3.org/TR/mobile-bp/#OneWeb

".../One Web/means making, as far as is reasonable, the same information and
services available to users irrespective of the device they are using. However,
it does not mean that exactly the same information is available in exactly the
samerepresentation
<http://www.w3.org/TR/di-gloss/#def-http-representation>across all devices. The
context of mobile use, device capability variations, bandwidth issues and mobile
network capabilities all affect the representation. Furthermore, some services
and information are more suitable for and targeted at particular user contexts
(see5.1.1 Thematic Consistency of Resource Identified by a URI
<http://www.w3.org/TR/mobile-bp/#tc>).

Some services have a primarily mobile appeal (location based services, for
example). Some have a primarily mobile appeal but have a complementary desktop
aspect (for instance for complex configuration tasks). Still others have a
primarily desktop appeal but a complementary mobile aspect (possibly for
alerting). Finally there will remain some Web applications that have a primarily
desktop appeal (lengthy reference material, rich images, for example).

It is likely that application designers and service providers will wish to
provide the best possible experience in the context in which their service has
the most appeal. However, while services may be most appropriately experienced
in one context or another, it is considered best practice to provide as
reasonable experience as is possible given device limitations and not to exclude
access from any particular class of device, except where this is necessary
because of device limitations.

  From the perspective of this document this means that services should be
available as some variant of HTML over HTTP (see3.7 Default Delivery Context
<http://www.w3.org/TR/mobile-bp/#ddc>)."

Now, this is obviously a rather ambiguous definition. It does not seem to
mandate anything specific in practice. On one end, you have the interpretation
that, if possible, one should make the same information available to both mobile
and desktop users. Of course, if this is not possible or does not make business
sense,  "designers and service providers" are free to do what they want => One
Web is pointless

   At the other extreme, you have that One Web should be interpreted more
strictly, and "designers and service providers" have an obligation of some kind
to make the same content available to both mobile users and web users => One Web
is wrong.
I can think of countless scenarios where content owners may not want to publish
the same content on the web and mobile channels.

So, One Web is a vaguely defined concept hanging somewhere between pointlessness
and wrongness.
At best, it's a positive advice ("don't be evil with mobile users"). At worst,
it's an artificial obstacle for those who have a specific business model to
support.  I am not sure what anyone would expect developers to do with it.


>
> You�ve missed the core problem - real time device detection. IF the HTTP
> protocol supported it correctly you wouldn�t need WURFL because it (the
> connecting device) would tell the server in real time what it�s capable of
doing.

...and the classic counter objection to this kind of arguments in italian is:
"if granma had wheels, she would be a wheelbarrow".

In other words, everything is achievable if you stack up enough ifs. Then you
have reality... and devices which won't tell the server who they are because
they don't want to...

There is little point in fixing the technology, if the industry has still not
agreed on the economic models that the technology is supposed to enable.

Luca

It is likely that application designers and service providers will wish to 
provide the best possible experience in the context in which their service has 
the most appeal. However, while services may be most appropriately experienced 
in one context or another, it is considered best practice to provide as 
reasonable experience as is possible given device limitations and not to exclude 
access from any particular class of device, except where this is necessary 
because of device limitations.

In other words, everything is achievable if you stack up enough ifs. Then you 
have reality... and devices which won't tell the server who they are because 
they don't want to�

There is little point in fixing the technology, if the industry has still not 
agreed on the economic models that the technology is supposed to enable.

In short - it�s easier to do it on the server.

WURFL is/was a great idea - if you want to solve the problem from the server. All I�m saying is �what if that database existed on the client�.

Think about it.

Peter
__________________________________
Peter J. Cranstone

M: 720.663.1752

5o9, Inc.
CEO

Web Tools for Mobile

On Mar 29, 2011, at 7:45 AM, Luca Passani wrote:

On 29/03/2011 15.04, Peter Cranstone wrote:

FWIW - the One Web is not bullshit. No more than designing a Web site for a

Mobile device is bullshit.

yes it is, but since you seem eager to re-open the discussion, I will articulate
better.

here is the definition of One Web (and if you mean something different, please
explain):

http://www.w3.org/TR/mobile-bp/#OneWeb

".../One Web/means making, as far as is reasonable, the same information and
services available to users irrespective of the device they are using. However,
it does not mean that exactly the same information is available in exactly the
samerepresentation
<http://www.w3.org/TR/di-gloss/#def-http-representation>across all devices. The
context of mobile use, device capability variations, bandwidth issues and mobile
network capabilities all affect the representation. Furthermore, some services
and information are more suitable for and targeted at particular user contexts
(see5.1.1 Thematic Consistency of Resource Identified by a URI
<http://www.w3.org/TR/mobile-bp/#tc>).

Some services have a primarily mobile appeal (location based services, for
example). Some have a primarily mobile appeal but have a complementary desktop
aspect (for instance for complex configuration tasks). Still others have a
primarily desktop appeal but a complementary mobile aspect (possibly for
alerting). Finally there will remain some Web applications that have a primarily
desktop appeal (lengthy reference material, rich images, for example).

It is likely that application designers and service providers will wish to
provide the best possible experience in the context in which their service has
the most appeal. However, while services may be most appropriately experienced
in one context or another, it is considered best practice to provide as
reasonable experience as is possible given device limitations and not to exclude
access from any particular class of device, except where this is necessary
because of device limitations.

From the perspective of this document this means that services should be
available as some variant of HTML over HTTP (see3.7 Default Delivery Context
<http://www.w3.org/TR/mobile-bp/#ddc>)."

Now, this is obviously a rather ambiguous definition. It does not seem to
mandate anything specific in practice. On one end, you have the interpretation
that, if possible, one should make the same information available to both mobile
and desktop users. Of course, if this is not possible or does not make business
sense,  "designers and service providers" are free to do what they want => One
Web is pointless

 At the other extreme, you have that One Web should be interpreted more
strictly, and "designers and service providers" have an obligation of some kind
to make the same content available to both mobile users and web users => One Web
is wrong.
I can think of countless scenarios where content owners may not want to publish
the same content on the web and mobile channels.

So, One Web is a vaguely defined concept hanging somewhere between pointlessness
and wrongness.
At best, it's a positive advice ("don't be evil with mobile users"). At worst,
it's an artificial obstacle for those who have a specific business model to
support.  I am not sure what anyone would expect developers to do with it.

You�ve missed the core problem - real time device detection. IF the HTTP

protocol supported it correctly you wouldn�t need WURFL because it (the

connecting device) would tell the server in real time what it�s capable of doing.

...and the classic counter objection to this kind of arguments in italian is:
"if granma had wheels, she would be a wheelbarrow".

In other words, everything is achievable if you stack up enough ifs. Then you
have reality... and devices which won't tell the server who they are because
they don't want to...

There is little point in fixing the technology, if the industry has still not
agreed on the economic models that the technology is supposed to enable.

Luca



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
   http://groups.yahoo.com/group/mobile-web/

<*> Your email settings:
   Individual Email | Traditional

<*> To change settings online go to:
   http://groups.yahoo.com/group/mobile-web/join
   (Yahoo! ID required)

<*> To change settings via email:
   mobile-web-digest@yahoogroups.com
   mobile-web-fullfeatured@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
   mobile-web-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
   http://docs.yahoo.com/info/terms/

I have to say that I'm confused how you could dismiss the OneWeb concept
altogether Luca.  I think you're right about that w3c doc being very
broadly worded to the point of almost saying nothing...but the
underlying concept is real and is really common...if not THE most common
URL based experience today.

People share links via twitter or facebook.  You post ONE link and
almost instantly people from all over the world with all sorts of
devices start accessing that URL.  This context makes device specific
URLs meaningless...plus it's stupid to ask users to select what the
machines should be able to sort out themselves (m.? .mobi? /m? /iphone?
blergh!).  This is just the modern content negotiation environment that
HTTP has created and is perfectly suited for.

The modern permalink just has to support this if it wants to be a true
permalink and have real utility.

I also do agree with Peter about extending and using HTTP to let clients
make more informed/sophisticated requests in collaboration with
consenting servers.  However, Peter I must say the way you describe it
as "putting the database on the client" really threw me for a minute 8)
Sorry but I don't think I'll be using that turn of phrase to try to
convince anyone on this point...but I think the underlying point that
you're making is really true.

The device market will continue to fragment and more sophisticated
capability/content negotiation will be required.  And the DAPI layer
will expose more significant information, private content and invasive
sensor data.  The users will need to be given more control over which
applications and servers are able to access and manipulate this.

And users just expect to seamlessly move from one channel/device to
another with the data/content fluidly following them.  This is a good
thing in my world...


roBman



On Tue, 2011-03-29 at 08:04 -0600, Peter Cranstone wrote:
> Totally agree with the definition, especially this point:
>
>
>         It is likely that application designers and service providers
>         will wish to
>         provide the best possible experience in the context in which
>         their service has
>         the most appeal. However, while services may be most
>         appropriately experienced
>         in one context or another, it is considered best practice to
>         provide as
>         reasonable experience as is possible given device limitations
>         and not to exclude
>         access from any particular class of device, except where this
>         is necessary
>         because of device limitations.
>
>
> Let me summarize - context is critical when it comes to device
> detection. Supply the relevant context and you have the ability to
> adapt to the device, the location and the user.
>
>
>         In other words, everything is achievable if you stack up
>         enough ifs. Then you
>         have reality... and devices which won't tell the server who
>         they are because
>         they don't want to…
>
>
> As they would say in America - “swing and a miss”.
>
>
> Seriously you need to sit down and think about how you would solve the
> problem. Saying the “devices won’t tell the server who they are
> because they don’t want to” is ridiculous. The device is not a
> sentient being. It does what it’s told to do.
>
>
> What you’re now bringing up is the issue of privacy - in as much how
> do you control “what context is being shared from the device”. So
> imaging this (not hard really) there’s a database on the device (WURFL
> uses a database so we’re on the same page here).
>
>
> In that database is “meta data about the device, the current location
> and some other personal information”. That database is controlled by
> the user. The user selects to send that data to a Web site /content
> provider they trust. They click a check box and next time they go to
> www.itrust.com all of their data shows up in the request headers.
>
>
> Now tell me what’s wrong with that? All that’s happened is the WURFL
> database is flipped to the device and includes more “contextual
> data”.
>
>
> And then you wrote this:
>
>
>         There is little point in fixing the technology, if the
>         industry has still not
>         agreed on the economic models that the technology is supposed
>         to enable.
>
>
> Again “swing and a miss”.
>
>
> Let me use the WURFL analogy - WURFL was invented (by you) to solve a
> problem. The problem is explicit - what are the device capabilities of
> the connecting device. So tell me what the economic model is behind
> using WURFL? Pretty obvious if you think about it - if you know the
> capabilities of the connecting device you’ll “tailor” your content to
> deliver the most relevance and the most value. The core problem
> remains - real time device detection. The economic model is also clear
> - deliver value to the connecting device by using device detection to
> ensure as much relevance as possible.
>
>
> Everybody out there wants to solve the problem on the server side. No
> one ever thought of solving it on the client side. Why? A number of
> reasons…
>
>
>       * Really hard
>       * Has to work with every firewall, filter, router etc
>       * Has to work with 250m Web servers out there
>       * Has to follow ALL Web standards
>       * Has to seamlessly integrate with everything
>       * Has to follow the law of “least astonishment”
>       * Has to work on multiple OS
>
>
> In short - it’s easier to do it on the server.
>
>
> WURFL is/was a great idea - if you want to solve the problem from the
> server. All I’m saying is “what if that database existed on the
> client”.
>
>
> Think about it.
>
>
>
>
>
> Peter
> __________________________________
> Peter J. Cranstone
> M: 720.663.1752
> 5o9, Inc.
> CEO
>
>
>
>
> Web Tools for Mobile
>
> On Mar 29, 2011, at 7:45 AM, Luca Passani wrote:
>
> > On 29/03/2011 15.04, Peter Cranstone wrote:
> > > FWIW - the One Web is not bullshit. No more than designing a Web
> > > site for a
> > > Mobile device is bullshit.
> >
> > yes it is, but since you seem eager to re-open the discussion, I
> > will articulate
> > better.
> >
> > here is the definition of One Web (and if you mean something
> > different, please
> > explain):
> >
> > http://www.w3.org/TR/mobile-bp/#OneWeb
> >
> > ".../One Web/means making, as far as is reasonable, the same
> > information and
> > services available to users irrespective of the device they are
> > using. However,
> > it does not mean that exactly the same information is available in
> > exactly the
> > samerepresentation
> > <http://www.w3.org/TR/di-gloss/#def-http-representation>across all
> > devices. The
> > context of mobile use, device capability variations, bandwidth
> > issues and mobile
> > network capabilities all affect the representation. Furthermore,
> > some services
> > and information are more suitable for and targeted at particular
> > user contexts
> > (see5.1.1 Thematic Consistency of Resource Identified by a URI
> > <http://www.w3.org/TR/mobile-bp/#tc>).
> >
> > Some services have a primarily mobile appeal (location based
> > services, for
> > example). Some have a primarily mobile appeal but have a
> > complementary desktop
> > aspect (for instance for complex configuration tasks). Still others
> > have a
> > primarily desktop appeal but a complementary mobile aspect (possibly
> > for
> > alerting). Finally there will remain some Web applications that have
> > a primarily
> > desktop appeal (lengthy reference material, rich images, for
> > example).
> >
> > It is likely that application designers and service providers will
> > wish to
> > provide the best possible experience in the context in which their
> > service has
> > the most appeal. However, while services may be most appropriately
> > experienced
> > in one context or another, it is considered best practice to provide
> > as
> > reasonable experience as is possible given device limitations and
> > not to exclude
> > access from any particular class of device, except where this is
> > necessary
> > because of device limitations.
> >
> > From the perspective of this document this means that services
> > should be
> > available as some variant of HTML over HTTP (see3.7 Default Delivery
> > Context
> > <http://www.w3.org/TR/mobile-bp/#ddc>)."
> >
> > Now, this is obviously a rather ambiguous definition. It does not
> > seem to
> > mandate anything specific in practice. On one end, you have the
> > interpretation
> > that, if possible, one should make the same information available to
> > both mobile
> > and desktop users. Of course, if this is not possible or does not
> > make business
> > sense,  "designers and service providers" are free to do what they
> > want => One
> > Web is pointless
> >
> >  At the other extreme, you have that One Web should be interpreted
> > more
> > strictly, and "designers and service providers" have an obligation
> > of some kind
> > to make the same content available to both mobile users and web
> > users => One Web
> > is wrong.
> > I can think of countless scenarios where content owners may not want
> > to publish
> > the same content on the web and mobile channels.
> >
> > So, One Web is a vaguely defined concept hanging somewhere between
> > pointlessness
> > and wrongness.
> > At best, it's a positive advice ("don't be evil with mobile users").
> > At worst,
> > it's an artificial obstacle for those who have a specific business
> > model to
> > support.  I am not sure what anyone would expect developers to do
> > with it.
> >
> >
> > >
> > > You’ve missed the core problem - real time device detection. IF
> > > the HTTP
> > > protocol supported it correctly you wouldn’t need WURFL because it
> > > (the
> > > connecting device) would tell the server in real time what it’s
> > > capable of doing.
> >
> > ...and the classic counter objection to this kind of arguments in
> > italian is:
> > "if granma had wheels, she would be a wheelbarrow".
> >
> > In other words, everything is achievable if you stack up enough ifs.
> > Then you
> > have reality... and devices which won't tell the server who they are
> > because
> > they don't want to...
> >
> > There is little point in fixing the technology, if the industry has
> > still not
> > agreed on the economic models that the technology is supposed to
> > enable.
> >
> > Luca
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
>

On 29/03/2011 17.07, Rob Manson wrote:
>
> I have to say that I'm confused how you could dismiss the OneWeb concept
> altogether Luca. I think you're right about that w3c doc being very
> broadly worded to the point of almost saying nothing...but the
> underlying concept is real and is really common...if not THE most common
> URL based experience today.
>
> People share links via twitter or facebook. You post ONE link and
> almost instantly people from all over the world with all sorts of
> devices start accessing that URL. This context makes device specific
> URLs meaningless...plus it's stupid to ask users to select what the
> machines should be able to sort out themselves (m.? .mobi? /m? /iphone?
> blergh!). This is just the modern content negotiation environment that
> HTTP has created and is perfectly suited for.
>
> The modern permalink just has to support this if it wants to be a true
> permalink and have real utility.
>

to be clear, I agree that, in a lot of cases, URLs should be made multiserve
mobile and web content in the interest of the end-users and site owners alike.
(and by multiserve, I do not necesarily mean that the URL must be the same.
There may also be a mechanism of smart redirects).
In fact, I sort of acknowledged that in my previous message when I wrote:

  > At best, it's a positive advice ("don't be evil with mobile users").

My objection has more to do with all of the W3C-driven rhetoric that has
accompanied One Web (particularly 4 or 5 years ago when the
concept was originally introduced) and the attempt that was being made at the
time by some to turn it into a dogma of some kind.

Luca

Hi Michael,

The way devices are to be accessed from the browser has changed in the past few
weeks. Gone is the <device> element and in comes the "getUserMedia" JavaScript
API.

Opera have released a build of Opera Mobile for Android that exposes these API's
and have a good blog post about how they can be used:
http://my.opera.com/core/blog/2011/03/23/webcam-orientation-preview

Opera also have implemented the WAC 1.0 API in their Widgets application and
have a number of demo's of it here:
http://labs.opera.com/docs/wac/installation_instructions/

As these are very new API's they are subject to change. Hopefully it won't be a
case of WebDB versus IndexedDB.

Yours,
Paddy

--- In mobile-web@yahoogroups.com, Michael Clesceri <webworker@...> wrote:
>
> Does anyone have good research on accessing the device camera and microphone
using HTML5 / HTML / etc on a smart device?
>
> Thanks
> Michael
>

I find the W3C definition of "one Web" actually quite good -- and anyway, this
is the only standard one we have.

The crux of the matter is its implicit assumption that mobile devices and
desktop devices (to simplify the categorization down to two items) represent
essentially the same kind of terminal, and are, by default, supposed to access,
present, and manipulate the same information.

TV is not cinema, despite the fact that they both serve to access audio-visual
media. One can view TV shows on a cinema screen, and television repurposes films
a lot (with manipulations such as pan and scan or colorization), but the
technical characteristics, distribution channels, business models, context of
usage, etc, are so different that they have resulted in distinct (though
interlinked) economic sectors, material, media production, aesthetic forms,
products, and archives.

The same applies to printed books and e-books. Currently, e-books look pretty
much exactly like e-books displayed on an electronic screen -- but they are
already diverging, with e-books specifically constructed for electronic readers
(with annotations, hyperlinks, social features, multimedia inserts -- but often
relying on colours sparely or not at all, contrarily to printed books). Or look
at "SMS novels".

Or concerts, radio, LP/CD, iPod/walkman.

If you are convinced that mobile phones and desktop terminals are substantially
the same (just larger or smaller computers accessing the Internet), then you
will probably strive for one-Web solutions catering both categories of devices
simultaneously and homogeneously (though admitting differentiated treatment here
and there). If you believe that they are substantially different, you will
rather tend to look for specific (though not entirely separate) solutions,
services and content for each one of them.

As for what constitutes the context of usage for Internet services, and whether
capability detection and the resulting content adaptation are best handled on
the terminal or on the server, my take is described in
http://areppim.com/b2evolution/usrblogs/technotes/?p=34&more=1&c=1&tb=1&pb=1


E.Casais

Sorry for the cross posting...but I think this is an important
discussion that crosses over the DAPI group too.  I think the w3c would
be interested in debate around the OneWeb definition too...see full
thread at the bottom.


On Tue, 2011-03-29 at 11:27 -0600, Peter Cranstone wrote:
> As for the database comment. Let’s think about it another way which
> everyone is familiar with - “an app for that”. Here’s the “thought
> experiment”.

Yeah...I think that's a better positioning based on where everyone's
head is at...but obviously would need to be set deeper into the browser
or phone OS to be truly useful.


> All I’ve done above is to describe something similar to the DAPI but
> with even more context.

Yep...and I agree it has to happen in one way or another.  I think the
graded control that OAuth can provide is exactly this type of
model...and that's already achieved wide adoption.

I think combining it with a server side (I refuse to use the word cloud)
data stores that you can also control makes it really useful.  Then you
can turn on and off the permission you have given to third parties to
use your data.  And best of all you'd get a full audit trail...and the
app could alert you when a third party wanted to access some particular
personal information and you could just click "allow or deny".


> There’s no question that it’s going to be done - the question becomes
> “what’s the best approach”. Everybody wants a piece of the consumer.
> The more context you have about them, the more value you can generate.

Absolutely agree.  But I think it's better if this is done at a lower
level than just an app (I know you were just using that as a
metaphor) ...however it is a real point of difference that browser
vendors could use to show users they're better/different by integrating
with this type of model.


>  You would not believe what Google’s Android browser is already
> sending back to HQ.

I know...and it's not a good thing.  I'm surprised it hasn't gotten as
much attention as the streetview mac address sniffing did.



roBman

> On Mar 29, 2011, at 9:07 AM, Rob Manson wrote:
>
> >
> > I have to say that I'm confused how you could dismiss the OneWeb
> > concept
> > altogether Luca. I think you're right about that w3c doc being very
> > broadly worded to the point of almost saying nothing...but the
> > underlying concept is real and is really common...if not THE most
> > common
> > URL based experience today.
> >
> > People share links via twitter or facebook. You post ONE link and
> > almost instantly people from all over the world with all sorts of
> > devices start accessing that URL. This context makes device specific
> > URLs meaningless...plus it's stupid to ask users to select what the
> > machines should be able to sort out themselves
> > (m.? .mobi? /m? /iphone?
> > blergh!). This is just the modern content negotiation environment
> > that
> > HTTP has created and is perfectly suited for.
> >
> > The modern permalink just has to support this if it wants to be a
> > true
> > permalink and have real utility.
> >
> > I also do agree with Peter about extending and using HTTP to let
> > clients
> > make more informed/sophisticated requests in collaboration with
> > consenting servers. However, Peter I must say the way you describe
> > it
> > as "putting the database on the client" really threw me for a minute
> > 8)
> > Sorry but I don't think I'll be using that turn of phrase to try to
> > convince anyone on this point...but I think the underlying point
> > that
> > you're making is really true.
> >
> > The device market will continue to fragment and more sophisticated
> > capability/content negotiation will be required. And the DAPI layer
> > will expose more significant information, private content and
> > invasive
> > sensor data. The users will need to be given more control over which
> > applications and servers are able to access and manipulate this.
> >
> > And users just expect to seamlessly move from one channel/device to
> > another with the data/content fluidly following them. This is a good
> > thing in my world...
> >
> > roBman
> >
> > On Tue, 2011-03-29 at 08:04 -0600, Peter Cranstone wrote:
> > > Totally agree with the definition, especially this point:
> > >
> > >
> > > It is likely that application designers and service providers
> > > will wish to
> > > provide the best possible experience in the context in which
> > > their service has
> > > the most appeal. However, while services may be most
> > > appropriately experienced
> > > in one context or another, it is considered best practice to
> > > provide as
> > > reasonable experience as is possible given device limitations
> > > and not to exclude
> > > access from any particular class of device, except where this
> > > is necessary
> > > because of device limitations.
> > >
> > >
> > > Let me summarize - context is critical when it comes to device
> > > detection. Supply the relevant context and you have the ability to
> > > adapt to the device, the location and the user.
> > >
> > >
> > > In other words, everything is achievable if you stack up
> > > enough ifs. Then you
> > > have reality... and devices which won't tell the server who
> > > they are because
> > > they don't want to…
> > >
> > >
> > > As they would say in America - “swing and a miss”.
> > >
> > >
> > > Seriously you need to sit down and think about how you would solve
> > the
> > > problem. Saying the “devices won’t tell the server who they are
> > > because they don’t want to” is ridiculous. The device is not a
> > > sentient being. It does what it’s told to do.
> > >
> > >
> > > What you’re now bringing up is the issue of privacy - in as much
> > how
> > > do you control “what context is being shared from the device”. So
> > > imaging this (not hard really) there’s a database on the device
> > (WURFL
> > > uses a database so we’re on the same page here).
> > >
> > >
> > > In that database is “meta data about the device, the current
> > location
> > > and some other personal information”. That database is controlled
> > by
> > > the user. The user selects to send that data to a Web
> > site /content
> > > provider they trust. They click a check box and next time they go
> > to
> > > www.itrust.com all of their data shows up in the request headers.
> > >
> > >
> > > Now tell me what’s wrong with that? All that’s happened is the
> > WURFL
> > > database is flipped to the device and includes more “contextual
> > > data”.
> > >
> > >
> > > And then you wrote this:
> > >
> > >
> > > There is little point in fixing the technology, if the
> > > industry has still not
> > > agreed on the economic models that the technology is supposed
> > > to enable.
> > >
> > >
> > > Again “swing and a miss”.
> > >
> > >
> > > Let me use the WURFL analogy - WURFL was invented (by you) to
> > solve a
> > > problem. The problem is explicit - what are the device
> > capabilities of
> > > the connecting device. So tell me what the economic model is
> > behind
> > > using WURFL? Pretty obvious if you think about it - if you know
> > the
> > > capabilities of the connecting device you’ll “tailor” your content
> > to
> > > deliver the most relevance and the most value. The core problem
> > > remains - real time device detection. The economic model is also
> > clear
> > > - deliver value to the connecting device by using device detection
> > to
> > > ensure as much relevance as possible.
> > >
> > >
> > > Everybody out there wants to solve the problem on the server side.
> > No
> > > one ever thought of solving it on the client side. Why? A number
> > of
> > > reasons…
> > >
> > >
> > > * Really hard
> > > * Has to work with every firewall, filter, router etc
> > > * Has to work with 250m Web servers out there
> > > * Has to follow ALL Web standards
> > > * Has to seamlessly integrate with everything
> > > * Has to follow the law of “least astonishment”
> > > * Has to work on multiple OS
> > >
> > >
> > > In short - it’s easier to do it on the server.
> > >
> > >
> > > WURFL is/was a great idea - if you want to solve the problem from
> > the
> > > server. All I’m saying is “what if that database existed on the
> > > client”.
> > >
> > >
> > > Think about it.
> > >
> > >
> > >
> > >
> > >
> > > Peter
> > > __________________________________
> > > Peter J. Cranstone
> > > M: 720.663.1752
> > > 5o9, Inc.
> > > CEO
> > >
> > >
> > >
> > >
> > > Web Tools for Mobile
> > >
> > > On Mar 29, 2011, at 7:45 AM, Luca Passani wrote:
> > >
> > > > On 29/03/2011 15.04, Peter Cranstone wrote:
> > > > > FWIW - the One Web is not bullshit. No more than designing a
> > Web
> > > > > site for a
> > > > > Mobile device is bullshit.
> > > >
> > > > yes it is, but since you seem eager to re-open the discussion, I
> > > > will articulate
> > > > better.
> > > >
> > > > here is the definition of One Web (and if you mean something
> > > > different, please
> > > > explain):
> > > >
> > > > http://www.w3.org/TR/mobile-bp/#OneWeb
> > > >
> > > > ".../One Web/means making, as far as is reasonable, the same
> > > > information and
> > > > services available to users irrespective of the device they are
> > > > using. However,
> > > > it does not mean that exactly the same information is available
> > in
> > > > exactly the
> > > > samerepresentation
> > > > <http://www.w3.org/TR/di-gloss/#def-http-representation>across
> > all
> > > > devices. The
> > > > context of mobile use, device capability variations, bandwidth
> > > > issues and mobile
> > > > network capabilities all affect the representation. Furthermore,
> > > > some services
> > > > and information are more suitable for and targeted at particular
> > > > user contexts
> > > > (see5.1.1 Thematic Consistency of Resource Identified by a URI
> > > > <http://www.w3.org/TR/mobile-bp/#tc>).
> > > >
> > > > Some services have a primarily mobile appeal (location based
> > > > services, for
> > > > example). Some have a primarily mobile appeal but have a
> > > > complementary desktop
> > > > aspect (for instance for complex configuration tasks). Still
> > others
> > > > have a
> > > > primarily desktop appeal but a complementary mobile aspect
> > (possibly
> > > > for
> > > > alerting). Finally there will remain some Web applications that
> > have
> > > > a primarily
> > > > desktop appeal (lengthy reference material, rich images, for
> > > > example).
> > > >
> > > > It is likely that application designers and service providers
> > will
> > > > wish to
> > > > provide the best possible experience in the context in which
> > their
> > > > service has
> > > > the most appeal. However, while services may be most
> > appropriately
> > > > experienced
> > > > in one context or another, it is considered best practice to
> > provide
> > > > as
> > > > reasonable experience as is possible given device limitations
> > and
> > > > not to exclude
> > > > access from any particular class of device, except where this is
> > > > necessary
> > > > because of device limitations.
> > > >
> > > > From the perspective of this document this means that services
> > > > should be
> > > > available as some variant of HTML over HTTP (see3.7 Default
> > Delivery
> > > > Context
> > > > <http://www.w3.org/TR/mobile-bp/#ddc>)."
> > > >
> > > > Now, this is obviously a rather ambiguous definition. It does
> > not
> > > > seem to
> > > > mandate anything specific in practice. On one end, you have the
> > > > interpretation
> > > > that, if possible, one should make the same information
> > available to
> > > > both mobile
> > > > and desktop users. Of course, if this is not possible or does
> > not
> > > > make business
> > > > sense, "designers and service providers" are free to do what
> > they
> > > > want => One
> > > > Web is pointless
> > > >
> > > > At the other extreme, you have that One Web should be
> > interpreted
> > > > more
> > > > strictly, and "designers and service providers" have an
> > obligation
> > > > of some kind
> > > > to make the same content available to both mobile users and web
> > > > users => One Web
> > > > is wrong.
> > > > I can think of countless scenarios where content owners may not
> > want
> > > > to publish
> > > > the same content on the web and mobile channels.
> > > >
> > > > So, One Web is a vaguely defined concept hanging somewhere
> > between
> > > > pointlessness
> > > > and wrongness.
> > > > At best, it's a positive advice ("don't be evil with mobile
> > users").
> > > > At worst,
> > > > it's an artificial obstacle for those who have a specific
> > business
> > > > model to
> > > > support. I am not sure what anyone would expect developers to do
> > > > with it.
> > > >
> > > >
> > > > >
> > > > > You’ve missed the core problem - real time device detection.
> > IF
> > > > > the HTTP
> > > > > protocol supported it correctly you wouldn’t need WURFL
> > because it
> > > > > (the
> > > > > connecting device) would tell the server in real time what
> > it’s
> > > > > capable of doing.
> > > >
> > > > ...and the classic counter objection to this kind of arguments
> > in
> > > > italian is:
> > > > "if granma had wheels, she would be a wheelbarrow".
> > > >
> > > > In other words, everything is achievable if you stack up enough
> > ifs.
> > > > Then you
> > > > have reality... and devices which won't tell the server who they
> > are
> > > > because
> > > > they don't want to...
> > > >
> > > > There is little point in fixing the technology, if the industry
> > has
> > > > still not
> > > > agreed on the economic models that the technology is supposed to
> > > > enable.
> > > >
> > > > Luca
> > > >
> > > >
> > > >
> > > > ------------------------------------
> > > >
> > > > Yahoo! Groups Links
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >
> >
>
>

Yeah...I think that's a better positioning based on where everyone's
head is at...but obviously would need to be set deeper into the browser
or phone OS to be truly useful.

Yep...and I agree it has to happen in one way or another. I think the
graded control that OAuth can provide is exactly this type of
model...and that's already achieved wide adoption.

I think combining it with a server side (I refuse to use the word cloud)
data stores that you can also control makes it really useful. Then you
can turn on and off the permission you have given to third parties to
use your data. And best of all you'd get a full audit trail...and the
app could alert you when a third party wanted to access some particular
personal information and you could just click "allow or deny".

Absolutely agree. But I think it's better if this is done at a lower
level than just an app (I know you were just using that as a
metaphor) ...however it is a real point of difference that browser
vendors could use to show users they're better/different by integrating
with this type of model.

I know...and it's not a good thing. I'm surprised it hasn't gotten as
much attention as the streetview mac address sniffing did.

Because 99% of the programmers out there are building apps so they never look at the Android Browser code. We�ve taken a very detailed look. The number of �phone home hooks activated� is amazing. They know everything your doing on that device - unless you unhook the hooks that is.

Peter
__________________________________
Peter J. Cranstone

M: 720.663.1752

5o9, Inc.
CEO

Web Tools for Mobile

Hey Peter,

> Easily done. Just extend the browser menu options to include a Privacy
> option and then incorporate the database there. Seamless to the
> customer.

Yep...sounds good to me.


> You don’t even need OAuth (which is a beast to configure correctly).
> All you need is two fields inside the database. It would be in the
> section that says Owner Information - username and password.

Well...I think more than one auth model is important.


>         I think combining it with a server side (I refuse to use the
>         word cloud) data stores that you can also control makes it
>         really useful. Then you can turn on and off the permission you
>         have given to third parties to use your data. And best of all
>         you'd get a full audit trail...and the app could alert you
>         when a third party wanted to access some particular personal
>         information and you could just click "allow or deny".
>
>
> Even this isn’t needed. Think about it for a second. This little
> database stores your metadata. The second you navigate to say
> http://www.cnn.com (which is on the approved whitelist) your data goes
> along for the ride. So in effect the protocol now gets more “stateful”
> information on each request. There’s no need to store your data on the
> server or even send an “Allow/Deny” message. I’ve already given
> permission via the whitelist.

You can definitely do it JUST on the device...but I think that's just a
stepping stone.  I really want seamless personal data control across
devices and platforms.  But that's a bigger picture story that the
consumer isn't really ready for yet.


> Because 99% of the programmers out there are building apps so they
> never look at the Android Browser code. We’ve taken a very detailed
> look. The number of “phone home hooks activated” is amazing. They know
> everything your doing on that device - unless you unhook the hooks
> that is.

I think this is a really key point that relates to all we are discussing
above.  We need to get more conversation around this point happening.


roBman

Well...I think more than one auth model is important.

I really want seamless personal data control across
devices and platforms.

I think this is a really key point that relates to all we are discussing
above. We need to get more conversation around this point happening.

Google has a lot of �hooks� into the Android browser so that it dials home with the latest news of what your up to. (We disconnected all of that in our version). What�s also interesting is that they don�t want you modifying the User Agent (can�t track it otherwise) and also they don�t like redirects - can�t see where you�re really going.

Peter
__________________________________
Peter J. Cranstone

M: 720.663.1752

5o9, Inc.
CEO

Web Tools for Mobile

Hello mobile webbers,

I'm currently in the discovery stage of a web app geared towards
mobile which hinges on geolocation. At this stage, flat-out reliance
on a certain level of accuracy is not part of the business logic —
some kind of geolocation (any) without dumping the user on a world map
and giving them a pin is crucial to the UX, but to the extent that
differentiation from city to city is highly relevant to end-points in
the user experience, we're tentatively conceiving of forked user
journeys based on ostensible certainty as to the specificity of the
user's location.

An abstracted use case for how this effects UX:
• Location is highly inaccurate: present user with interfaces that
emphasise the ability to calibrate location to some extent.
• Location is highly accurate: gear the UI towards more granular
interaction paradigms and de-emphasise calibration.

Given that the methods used to dictate the specifics of the
navigator.geolocation are black box, and so is connection type
(ethernet, WiFi, …) … what are the list's best bets on ostensible info
with which to infer geolocation accuracy?


Regards,
Barney Carroll

barney.carroll@...
07594 506 381

Hello,

The GeoLocation API provides accuracy information as part of the
position object. So you can decide what accuracy is good in your case
and if it is not good enough, give the user the possibility to calibrate
the location.

Actually the methods, used by navigator.geolocation are not black box at
all. Opera and Firefox use a service from Google (which meand Chrome and
Android browses use the same) to establish the location of the device by
the measuring the signal of nearby WiFi networks. If you use
navirator.geolocation.watchPosition() methos the browser the tries ti
use the built-in GPS, if one is available. My experience is that on
laptops the WiFi method alone gives accuracy as low as 100 meters. On a
mobile phone the WiFi method first gives accuracy from 500 to 2000
meters, but after few seconds the browser needs to fire the GPS device,
the accuracy goes to 20 - 30 meters.

I have a very basic test page, which shows the position object, returned
by navigator.geolocation.watchPosition(). I used it to study the
accuracy on different places around the city, to decide what works for me.

http://greatgonzo.net/examples/geolocation/


Milen Petrinskli - Gonzo



On  6.04.2011 13:19, Barney Carroll wrote:
> Hello mobile webbers,
>
> I'm currently in the discovery stage of a web app geared towards
> mobile which hinges on geolocation. At this stage, flat-out reliance
> on a certain level of accuracy is not part of the business logic —
> some kind of geolocation (any) without dumping the user on a world map
> and giving them a pin is crucial to the UX, but to the extent that
> differentiation from city to city is highly relevant to end-points in
> the user experience, we're tentatively conceiving of forked user
> journeys based on ostensible certainty as to the specificity of the
> user's location.
>
> An abstracted use case for how this effects UX:
> • Location is highly inaccurate: present user with interfaces that
> emphasise the ability to calibrate location to some extent.
> • Location is highly accurate: gear the UI towards more granular
> interaction paradigms and de-emphasise calibration.
>
> Given that the methods used to dictate the specifics of the
> navigator.geolocation are black box, and so is connection type
> (ethernet, WiFi, …) … what are the list's best bets on ostensible info
> with which to infer geolocation accuracy?
>
>
> Regards,
> Barney Carroll
>
> barney.carroll@...
> 07594 506 381
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

{

    "coords": {

        "speed": null,

        "accuracy": 80,

        "altitudeAccuracy": null,

        "altitude": null,

        "longitude”: removed,

        "heading": null,

        "latitude”: removed

    },

    "timestamp": 323787060

}

Peter
__________________________________
Peter J. Cranstone

M: 720.663.1752

5o9, Inc.
CEO

Web Tools for Mobile

On Apr 6, 2011, at 6:49 AM, Милен Петрински - Гонзо wrote:

 

Hello,

The GeoLocation API provides accuracy information as part of the
position object. So you can decide what accuracy is good in your case
and if it is not good enough, give the user the possibility to calibrate
the location.

Actually the methods, used by navigator.geolocation are not black box at
all. Opera and Firefox use a service from Google (which meand Chrome and
Android browses use the same) to establish the location of the device by
the measuring the signal of nearby WiFi networks. If you use
navirator.geolocation.watchPosition() methos the browser the tries ti
use the built-in GPS, if one is available. My experience is that on
laptops the WiFi method alone gives accuracy as low as 100 meters. On a
mobile phone the WiFi method first gives accuracy from 500 to 2000
meters, but after few seconds the browser needs to fire the GPS device,
the accuracy goes to 20 - 30 meters.

I have a very basic test page, which shows the position object, returned
by navigator.geolocation.watchPosition(). I used it to study the
accuracy on different places around the city, to decide what works for me.

http://greatgonzo.net/examples/geolocation/

Milen Petrinskli - Gonzo

On 6.04.2011 13:19, Barney Carroll wrote:
> Hello mobile webbers,
>
> I'm currently in the discovery stage of a web app geared towards
> mobile which hinges on geolocation. At this stage, flat-out reliance
> on a certain level of accuracy is not part of the business logic —
> some kind of geolocation (any) without dumping the user on a world map
> and giving them a pin is crucial to the UX, but to the extent that
> differentiation from city to city is highly relevant to end-points in
> the user experience, we're tentatively conceiving of forked user
> journeys based on ostensible certainty as to the specificity of the
> user's location.
>
> An abstracted use case for how this effects UX:
> • Location is highly inaccurate: present user with interfaces that
> emphasise the ability to calibrate location to some extent.
> • Location is highly accurate: gear the UI towards more granular
> interaction paradigms and de-emphasise calibration.
>
> Given that the methods used to dictate the specifics of the
> navigator.geolocation are black box, and so is connection type
> (ethernet, WiFi, …) … what are the list's best bets on ostensible info
> with which to infer geolocation accuracy?
>
>
> Regards,
> Barney Carroll
>
> barney.carroll@...
> 07594 506 381
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>