Re: Limitations of the current checker

Hi Jo,

Le lundi 26 mars 2012 à 14:31 +0100, Jo Rabin a écrit :

> Agree that this work is now more than a little out of date and the
> bits that are most out of date cast a shadow over the bits that are
> not.
> A couple of brief thoughts:

Thanks for the feedback! My replies in-line below.

> a. The checker implements mobileOK Basic Tests [1] - updating the
> checker presumably implies updating that document - or does it? The
> authority for the checker in part derives from the status of mobileOK
> Tests as a W3C Rec. So where would the authority for an updated
> checker come from if mobileOK Tests was deprecated? Indeed, never mind
> the authority, a fair amount of debate and consideration (ahem) went
> into wording and refining that doc, I'd imagine that at least the same
> if not more debate would be needed for a new one. The alternative of
> not producing an updated Rec seems quite tricky really.

My current thinking is that the new tool would not be based on a W3C
Recommendation (or at least, not on a set of tests described in a W3C
Recommendation). I expect a number of its tests would still be inspired
from either the Mobile Web Best Practices or the Mobile Web Application
Best Practices, but I'm fairly sure some of the tests wouldn't.

In terms of authority, I think its main source of authority would be its
actual usefulness and adoption by the community.

So, to define these new tests, I would call for the expertise from
people on this list about biggest pain points that can be automatically
detected by a tool, and get a first release with these tests. Further
improvements would be made based on feedback from the tool users (which
I expect we should make easier to get from the tool itself).

Now, if that list of tests stabilizes, and if there is demand to
standardize that list, we could start a new group to go through the
standardization process; but it's definitely not a primary goal for me.

(Note that standardizing these tests require a lot more wordsmithing
than just implementing them, since in the standardization case, you need
to describe them in a way that many people will interpret similarly,
defining a priori all edge cases)

> b. You mention that you think a "real" browser would be needed. I'm
> increasingly thinking that it would be quite useful to have a
> canonical headless browser but am worried that that would no doubt be
> a journey into a very deep swamp. The size of a large continent, I
> expect.

In terms of headless browser, I have been thinking of using Mephisto, a
headless browser built on top of Firefox:
http://temesis.github.com/Mephisto/usage.html (more on this in a
separate message)

Note that there is actually a W3C WG that is developing a common API for
operating headless browsers: http://www.w3.org/testing/browser/

> c. I remain in favour of an intermediate representation - currently
> MOKI but lessons no doubt need to be learned on that - not least to
> preserve at least theoretical open-endedness in application of some of
> the resulting software.

I understand that usefulness, although it will need to be balanced with
the cost in implementation and performance.

> d. A Checker is not just for Christmas. Emphasize the need for
> thinking about the ongoing maintenance that ought to accompany a
> revised initiative.

Absolutely! That's one topic where I'm hoping to get a lot of useful
input :)

I'm thinking that a dedicated W3C community group [1] (maybe just an
extension of that mailing list), with the role of maintaining the list
of tests and hopefully also maintaining the code would be a reasonable
approach; but a key for this to work is to have actual interest from the
community in contributing resources toward that — which I'm hoping this
discussion will help assess.

Dom

1. http://www.w3.org/community/

Received on Monday, 26 March 2012 13:53:01 UTC