Re: Limitations of the current checker

Dear all,

The idea introduced by Dom seems very interesting. When I was reading,
basically the same issues raised by Jo came to my mind.
Perhaps, leaving the mobileOK Checker as a separate checker which serves as
an independent self-sufficient reference implementation of the mOK Tests
1.0 W3C Rec would be good. Thus, I would create a new checker by, of
course, evolving the current Checker and reusing as much design and code as
possible. Needless to say that it is only an opinion :)

However, CTIC has no available efforts to be dedicated to its
implementation by now. We will gladly follow the discussion in the list and
provide feedback and ideas, as we are sure that the resulting tool will be
absolutely useful and welcome by the developer community.

Thank you very much for this initiative, Dom.

Best regards,

Nacho

----------------------------------------------------------------------------------------
Ignacio Marín Prendes
CTIC-Centro Tecnológico
Responsable de Unidad de Movilidad e Independencia de Dispositivo
Área de I+D+i
(Manager for Device Independence and Mobility / R&D Department)
Parque Científico y Tecnológico de Gijón
c/ Ada Byron, 39 Edificio Centros Tecnológicos
33203 Gijón - Asturias - España
Tel.: +34 984 29 12 12
Mobile: +34 657 30 59 55
Fax: +34 984 39 06 12
E-mail: ignacio.marin@fundacionctic.org
http://www.fundacionctic.org
Política de Privacidad: http://www.fundacionctic.org/privacidad
Privacy Policy: http://www.fundacionctic.org/privacidad
----------------------------------------------------------------------------------------



2012/3/26 Dominique Hazael-Massieux <dom@w3.org>

> 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/
>
>
>
>
>
>