- 1 What's Coremob?
- 2 What is Coremob here to do?
- 3 Appendix: Down the Rabbit Hole - What is a Modern Mobile Web Application?
To begin at the beginning, with some fundamentals:
The goals of Coremob are noted in its charter. Given continuing confusion it seems that it is necessary to elaborate the wording of that charter.
Simply put, Coremob is a W3C Community Group whose goal, according to the charter is:
"to accelerate the adoption of the Mobile Web as a compelling platform for the development of modern Mobile Web applications."
Elaborating on that statement, bit by bit:
What is a W3C Community Group?
As noted on its home page : "A W3C Community Group is an open forum, without fees, where Web developers and other stakeholders develop specifications, hold discussions, develop test suites, and connect with W3C's international community of Web experts."
In other words, a W3C Community Group (CG) is a group operating under the auspices of the W3C that has more relaxed process, membership and other requirements than those of a W3C Working Group. The differences between various types of W3C group are tabulated. Notable differences are that membership of a CG is free, it has different IPR licensing obligations.
The reports (or other outputs) generated by a CG do not necessarily have the intention of attaining W3C Recommendation status.
A CG has access to W3C resources such as a Community Group Web site, a mailing list, a Wiki, an IRC channel and the W3C Issue Tracking system. Those resources, in respect of the Coremob CG, are linked from the Coremob Home Page, which is most easily found by redirection from http://coremob.org. The way the Coremob CG currently uses those resources - and a couple of others - is described at the work mode page.
What does "accelerate the adoption ..." mean? And what is a Mobile Web App, anyway?
Without wishing disappear down a rabbit-hole of semantic salami slicing (well not yet, we'll do that in a minute), it's not unreasonable to ask what is a Mobile Web app, let alone what is a "modern" Mobile Web app. The statement from the charter isn't very helpful on this as it has a somewhat circular structure. "Making the Mobile Web ... suitable for modern Mobile Web applications", isn't strictly meaningful, since surely for all <x>, <x> must be suitable for deployment of <x> applications, otherwise they would not by definition be <x> applications.
OK that's enough casuistry. What this is getting at is as follows:
Much though HTML5 is talked about as a nirvana for developers seeking to develop once, deploy everywhere, the reality falls short of that to some considerable degree. Developers find that it is hard to impossible to develop quite simple applications that work at all - or that work consistently on a cross-platform basis.
Note: Here, cross-platform means across hardware, across operating systems and across browser vendors; and HTML5 is taken in its broadest "marketing" sense, meaning that it includes related technologies that are not HTML5, but are promoted as belonging to the same family of technologies, or platform, by W3C and others - see http://www.w3.org/html/logo/#the-technology.
These problems are not unique to "mobile" devices, but are more apparent because of the contrast between mobile related features that are easy to implement in native applications but difficult or impossible to realise in Web applications. To be clear, the features required are not only features that resonate more strongly to a mobile use case than a desktop use case, the contrast is more concerned with practicality of development using Web technology as opposed to native technology.
However, today, just as there is a strong case for developing some applications using native platform technologies, there should be a strong case for developing a very wide range of other applications using Web platform technologies. The problem is that there are often significant obstacles to doing so. So the issue is not one of principle, but one of pragmatism. The Page "Philosophy" on the Coremob Wiki develops these themes further.
The features that are required to build mobile applications that are suitable for development on the Web platform, depending on which feature you mean, are somewhere on a spectrum between "widely deployed and consistently implemented" - all the way to the other extreme of work not having started on specification of a standard for that feature.
There is a very useful document summarising this status Standards for Web Applications on Mobile: current state and roadmap, which is periodically updated by Dominique Hazaël-Massieux (Dom).
We'll come back to more discussion of "What is a Mobile Web App" at the very end of this note.
What is Coremob here to do?
So in practice, this is what Coremob is here to do.
CoreMob is here to make the Mobile Web a reasonable platform for developing Mobile Applications ... it is not that today, it's much too hard.
Coremob is not here to develop new technologies, it's here to:
- help bring existing not quite standardised technologies to fruition,
- to suggest areas of priority for standardisation,
- encourage the implementation of sets of standards so that developers can "rely" on certain feature sets being available at any time across implementations,
- to help develop tests that measure the functional conformance of those implementations to the standards (but not, at present, benchmarks of performance).
Coremob is here as a forum for developers to express their requirements and have those requirements represented to standardisation groups and to industry.
Its areas of focus are:
1 List Sets of Features
Establish a priority list of features that are required for building a set of application types that by consensus view among developers, equipment manufacturers, browser vendors, operators and other relevant members of the industry, are strong candidates for being built on the Mobile Web platform.
2 Encourage the Real Life Availability of Usable Sets of Features
Encourage relevant parties to
a. complete the standardisation, if necessary, of those features - taking into account any adjustments to those features that may be suggested by Coremob
b. prioritise the implementation of those features in browsers (or whatever the relevant part of the Web platform is)
c. to do so in a conformant way, as judged by an agreed set of conformance test suites.
3 Assist with Testing Implementations for Conformance to Features
4 Help develop relevant conformance tests and a framework within which such conformance tests can conveniently be exercised.
We'll discuss these in more detail after a small discussion of Ringmark.
What has all this to do with Ringmark?
As explained in a number of places, most recently by Matt Kelly, at the recent Coremob F2F 2012-10-02 Coremob F2F 2012-10-02, Facebook initiated its proprietary Ringmark scheme as a result of its experience of the difficulty of using Web technologies to provide Facebook services on mobile - and as a result of wishing to establish some set of baseline tests for mobile Web platform compatibility.
Subsequently, at Mobile World Congress 2012, Facebook announced its intention along with other founding partners, to work with others in the context of a W3C Community Group (Coremob) to develop the themes that it had initiated as part of Ringmark.
Coremob owes a debt of gratitude to Ringmark, and hence to Facebook for being the catalyst that brought it to life. However, it is not a Facebook initiative, it's a W3C Community Group with - see [ http://www.w3.org/community/coremob/wiki/Participating_Organizations many significant organisations represented] as well as many "developers unrelated to those organisations. And though it may be inspired by Ringmark technologies, the group's job is not to adopt the any of them as they currently stand.
Indeed while the work of the group originally centred around a similar layered testing scheme to Ringmark (Ringmark's ring 0, 1 etc being echoed by Coremob as Level 0, Level 1 etc) this is no longer the case, since the CG decided to centre its testing work around a time based "aspirational feature set". This is known as "Coremob 2012" which is intended to be a set of features that are understood to be to some degree aspirational at this time (aspirational in that they won't be universally implemented, but are very much needed for some understood use cases).
Furthermore, while Facebook has made its test runner and test suites available to the group and others as Open Source - it would not appear that these will be directly used by Coremob in its deliverables (though again, it may take inspiration from them).
Finally, it's not a specific intention of the Coremob CG to produce a graphical display such as the distinctive rings of Ringmark. Admiration for the directness and simplicity of the representation has been expressed in the group, and the view has been expressed that without such a distinct graphical representation much will be lost in the messaging of what Coremob is about.
In response to this, the group plans to deliver is a platform on which anyone can exercise their creativity and ingenuity and come up with user interfaces or automated scripts which execute a common set of tests, defined against Coremob 2012. It's very much my hope, at least, that Facebook decides to adapt its ring based interface to use the group's output, and it's the expressed view of the group that it's important that such interfaces exist (not least because testing won't be possible without such interfaces).
So, all that said, what are the deliverables of the group and where has it got to with those deliverables?
What is the Group Going to Deliver?
Our current plan (as discussed at our recent face to face meeting, October 2012) is to deliver, or initiate the delivery of five things.
1) A "Use Case" and requirements document, identifying some key features of Mobile Web apps, by examining the requirements of a set of specific popular native application types.
2) Coremob 2012, which documents the specific technologies required to implement the set of features identified in 1) above. Of significant note is that some of these technologies may not yet have been stardardized in the Web context.
[It has subsequently been decided to combine 1) and 2) above into a single Coremob 2012 document]
3) A test Framework specification which documents how the W3C tests suites can be executed to carry out tests for the technologies identified in 2) above
4) An implementation of the test framework to allow the tests to be executed.
5) A "Gap" Analysis of which areas of Coremob 2012 are short of tests and some thinking about how to make good that short fall.
When will the Group Deliver them?
As suggested by the title of the document, the plan is to deliver Coremob 2012 by the end of December 2012. It's logically dependent on the delivery of use cases and requirements so it's possible that these will be delivered in one piece. Given the different in pace of standardization of the technologies identified, the remaining pieces will probably be dleivered in an incremental and iterative way over the succeeding months, and years.
Appendix: Down the Rabbit Hole - What is a Modern Mobile Web Application?
... just in time to see it [the rabbit] pop down a large rabbit-hole under the hedge. In another moment down went Alice after it, never once considering how in the world she was to get out again.
To some extent this is a discussion about how many angels may dance on the head of a pin. But in other respects it's important. The group's charter states that the point of its existence is to accelerate the adoption of modern Mobile Web Apps. it seems logical to think that measurement of its progress or success depends upon some understanding of what this means - in other words it's part of the scoping of the group's activities to have at least some kind of understand of some definitions.
We'll take the term "modern" as meaning using some subset of the features of HTML5 (in a broad "marketing" sense, as discussed above).
On "Mobile", to start with. It's quite difficult, and somewhat pointless in my opinion, to try to define precisely what characteristics make something mobile. However there are a number of recognisable features not all of which need to be present in order for us to say that we want to treat something as Mobile. In other words it's a family resemblance rather than there being any single feature or features that are always common. Multi-Platform Aware might be a better term than Mobile, these days, but Mobile is widely if imprecisely understood to capture what is meant.
Mobile can be seen as being used mainly to make a contrast with assumptions about the Delivery Context that might be made, if assuming a Web user is stationary at a table using a desktop or laptop computer. In the context of the Coremob CG, we mean Mobile as in where you might use Web technology in place of "native app" technology and hence the term isn't distinct from the use of "Web", by which we man "HTML5" in this context.
Finally, when we talk of a Web application, we're not the first to struggle with what this might mean and probably won't be the last. The CG currently has a discussion open on this topic see ACTION-66 which is to summarise the earlier discussion under ACTION-47 http://www.w3.org/community/coremob/track/actions/47.