Re: Dynamic probes prototype

[Dave Olsen <dm...@gmail.com>]

I stumbled onto this group after seeing a referral today from
Bertrand's note. First off, thanks for highlighting my work with
Detector. It's much appreciated. Second, if there's any insight I can
provide regarding the issues I've run into with Detector please let me
know. It's great to see others pursuing similar lines of development.
I'm really curious to see where it can be taken and if I can help.

As for the "hard part" of the project...

My feature detection code is just Modernizr. Any custom tests someone
would want to develop can just use the Modernizr.addTest() Plugin API
[1] so... maybe not so hard to implement ;) Though maybe those tests
[2] are not enough info for your project. For example, I noticed
you're using the JS to get platform info via navigator whereas I'm
going the more traditional route and using ua-parser [3] which was
created with data from browserscope.org. Bryan, in developing Profile,
was definitely trying to do something similar to your project. I'm not
sure where he's at on that kind of thing. I don't foresee pulling away
from Modernizr myself.

The plumbing definitely isn't hard. I'm more curious to see how the
group determines what forms a base profile of tests that is useful to
everyone. I'd be happy to see if I could standardize Detector on that
set of tests too so data could be easily shared between projects...
assuming this becomes a Java library (sorry, not sure what the
deliverables for the project are).

For those who might not be familiar with Detector, I wrote up a blog
post regarding what my goals for the project were [4]. The GitHub
project [5] also lists the current features. A lot of my work has been
focused on how the info can be used as part of a templating engine
[6]. We will be using it in production this summer.

I'm probably being a little overbearing & longwinded... I wasn't quite
sure how to introduce myself ;) So, hi :)

[1] - http://modernizr.com/docs/#addtest
[2] - http://detector.dmolsen.com/demo/modernizr-listing/
[3] - https://github.com/tobie/ua-parser
[4] - http://www.dmolsen.com/mobile-in-higher-ed/2012/01/18/introducing-detector-combining-browser-feature-detection-for-your-web-app/
[5] - https://github.com/dmolsen/Detector
[6] - http://ress.dmolsen.com

-- 

http://dmolsen.com

Re: Dynamic probes prototype

[Dave Olsen <dm...@gmail.com>]

On Tue, Jun 5, 2012 at 12:14 PM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> My first goal would be to get a browser map, and leave the door open
> for linking that to devices when/if that happens. I think we're on the
> same wavelength here (though this project's name might not be fully
> representative then ;-)

Ok, I think a decent next step for me would be to develop a Google Doc
which lists browser features that could be tracked via tests. At this
point I feel comfortable with the plumbing of Detector that I think it
can be used as an example for other similar libraries. Now I can take
a a critical look at what it tracks. This could form the basis of a
standard.

I'll use the default Modernizr tests as the base but work in r0 of
Ringmark [1] and some of the Can I Use tests [2]. I'm sure there's a
lot of overlap. I'd love to explicitly track ARIA support too. I think
the trick is to a) find a small set of tests that won't bog down a
browser and b) identify those tests that make sense to save to a
profile on disk. Something like pixel density would be awesome to test
& keep on disk but it doesn't track to a UA well. With Ringmark now
contributed to the W3C Core Mobile group that might prove to be an
interesting way to standardize both features tracked and code used.

I should have something to share in two weeks or so. Then interested
parties can throw darts at it.

By the way, I'm probably making an assumption that tests should be
organized into core & per-session like I have w/ Detector [3].

[1] - http://www.rng.io/
[2] - http://tests.caniuse.com/
[3] - https://github.com/dmolsen/Detector/wiki/Detector-Test-Tutorial

-- 

http://dmolsen.com

Re: Dynamic probes prototype

[Bertrand Delacretaz <bd...@apache.org>]

Hi Dave,

On Tue, Jun 5, 2012 at 3:04 AM, Dave Olsen <dm...@gmail.com> wrote:
> Bertrand wrote on May 31:
>> I've just committed a prototype using a "dynamic probes" technique...

> My one big question related to this technique is how do you plan to
> definitively link UA (e.g. a *browser*) to a particular device?...

Good question - I think you are right that we are indeed detecting
*browser* capabilities as opposed to *device* capabilities.

Which is fine for my use cases. I'd be happy with having many browsers
identified based on the result of probing them in javascript, and
having some of them mapped to device definitions that could include
more details.

> ...solutions. I envisioned a solution where all of the UA profiles
> sourced with Detector [1] could be put into a GitHub repo and people
> could put in pull requests and pull data whenever they wanted...

That's very useful, and IMO doesn't prevent people to further linking
that info to devices where that makes sense.

> ...Maybe I
> just didn't know enough but I quickly gave up with device-detection
> or, rather, trying to organize by device and moved to calling what I
> was doing simply browser- and feature-detection and organizing by
> unique UA. Lots of overlap but less thinking on my part ;)...

Sounds good to me!

>
> As an example of where I think their may be a disconnect between
> device- and browser-detection is a complaint someone sent to me about
> their Detector profile. One of the features I test for is touch event
> support. The commenter noted that their N9 was a touch device but I
> was reporting it as false. I had to point out that there's a
> difference between touch as input on a device and touch as the browser
> sees it and can act on it. As a developer I'm more worried about the
> latter than the former....

Yes, agree with that.

>
> Is there a relatively easy way to link UA to device? Or does this
> technique point towards a more generic, browser map as opposed to a
> device map?...

My first goal would be to get a browser map, and leave the door open
for linking that to devices when/if that happens. I think we're on the
same wavelength here (though this project's name might not be fully
representative then ;-)

-Bertrand

Re: Dynamic probes prototype

[Dave Olsen <dm...@gmail.com>]

Bertrand wrote on May 31:
> I've just committed a prototype using a "dynamic probes" technique
> which detects device features using client-side javascript, and makes
> that available both on the client and server sides.

My one big question related to this technique is how do you plan to
definitively link UA (e.g. a *browser*) to a particular device? I
originally came at this problem as a device-detection solution. I saw
Detector as a good way of sourcing data without relying on... existing
solutions. I envisioned a solution where all of the UA profiles
sourced with Detector [1] could be put into a GitHub repo and people
could put in pull requests and pull data whenever they wanted. Maybe I
just didn't know enough but I quickly gave up with device-detection
or, rather, trying to organize by device and moved to calling what I
was doing simply browser- and feature-detection and organizing by
unique UA. Lots of overlap but less thinking on my part ;)

As an example of where I think their may be a disconnect between
device- and browser-detection is a complaint someone sent to me about
their Detector profile. One of the features I test for is touch event
support. The commenter noted that their N9 was a touch device but I
was reporting it as false. I had to point out that there's a
difference between touch as input on a device and touch as the browser
sees it and can act on it. As a developer I'm more worried about the
latter than the former.

Is there a relatively easy way to link UA to device? Or does this
technique point towards a more generic, browser map as opposed to a
device map?

[1] 1000+ Detector profiles for a low traffic website -
http://detector.dmolsen.com/archive.php

-- 

http://dmolsen.com

Re: Dynamic probes prototype

[Bertrand Delacretaz <bd...@apache.org>]

Hi Dave,

On Fri, Jun 1, 2012 at 3:40 AM, Dave Olsen <dm...@gmail.com> wrote:
> ...First off, thanks for highlighting my work with
> Detector. It's much appreciated...

You're welcome, and thanks very much for writing here - it looks like
we should be able to find ways to collaborate between the different
projects working in this space, even if we're targeting different
languages.

> ...Second, if there's any insight I can
> provide regarding the issues I've run into with Detector please let me
> know. It's great to see others pursuing similar lines of development.
> I'm really curious to see where it can be taken and if I can help...

As you probably noticed if you read our mailing list archives, this
project is just getting started, so I guess we're open to anything
that brings us forward - it can range from just discussing things and
sharing experiences to moving your code here (and becoming a committer
in the process of course) if that makes sense. Or maybe just sharing
the javascript detection code and related test suites so that they can
be applied to various server-side components. My current examples are
in Java because that's what I use in my work, but I think we should
abstract the client-side detection code as much as possible so that it
can be reused and shared between different languages.

> ...My feature detection code is just Modernizr. Any custom tests someone
> would want to develop can just use the Modernizr.addTest() Plugin API
> [1] so... maybe not so hard to implement ;) Though maybe those tests
> [2] are not enough info for your project...

I agree that the Modernizr stuff provides most of the information that
people need.

What might be interesting is defining a simple plugin system where
javascript snippets that detect more features (and/or cope with newer
devices) can be exchanged - but if possible it's probably better to
contribute such things to Modernizr instead of reinventing that wheel.

> ...For example, I noticed
> you're using the JS to get platform info via navigator whereas I'm
> going the more traditional route and using ua-parser [3] which was
> created with data from browserscope.org. Bryan, in developing Profile,
> was definitely trying to do something similar to your project. I'm not
> sure where he's at on that kind of thing. I don't foresee pulling away
> from Modernizr myself....

I think such choices should be left to the user - with devicemap the
aim is to provide reusable components and data that people can mix and
match according to their own needs and to which method they trust
best. A simple plugin system (like you have IIRC in Detector.js) is
probably good enough to allow people to do this mixing and matching.

>
> The plumbing definitely isn't hard. I'm more curious to see how the
> group determines what forms a base profile of tests that is useful to
> everyone. I'd be happy to see if I could standardize Detector on that
> set of tests too so data could be easily shared between projects...
> assuming this becomes a Java library (sorry, not sure what the
> deliverables for the project are)....

Yes, sharing those test sets would be great - maybe we just need to
base all tests on a simple plugin system that can be used from either
php, java or other languages? A textual javascript snippet definition
format that specifies dependencies ("Modernizr 1.3") and provides the
detection code might be sufficient.

> ...I'm probably being a little overbearing & longwinded... I wasn't quite
> sure how to introduce myself ;) So, hi :)...

Hi, and thanks very much for getting in touch!

-Bertrand

>
> [1] - http://modernizr.com/docs/#addtest
> [2] - http://detector.dmolsen.com/demo/modernizr-listing/
> [3] - https://github.com/tobie/ua-parser
> [4] - http://www.dmolsen.com/mobile-in-higher-ed/2012/01/18/introducing-detector-combining-browser-feature-detection-for-your-web-app/
> [5] - https://github.com/dmolsen/Detector
> [6] - http://ress.dmolsen.com
>
> --
>
> http://dmolsen.com