To illustrate this, we are working on a demonstration that illustrates the ability of the Web on various connected devices: laptop, tablet, phone and TV.

Anyone who has had to work on setting up a network at Mobile World Congress has probably experienced the same as I have: setting up a reliable WiFi network in the midst of many other booths with WiFi networks and the unavoidable overlap of WiFi frequencies is at best a challenge, at worse impossible.

So this year, I’ll be trying an alternative set up, using bluetooth as a way to connect devices to the network, instead of (or in addition to) WiFi. It is to early too tell whether that alternative will work or if it will be necessary at all — the congress organizers have made (unclear to me at least) claims that the WiFi situation should be better this year. But I thought I would document what I’ve managed to set up so far, in case this can help others, and, more likely, in case I need a similar set up in the future.

I had originally thought of buying a bluetooth network hub, but they were rather expensive, and it didn’t seem that there was a lot of choice in this space. I then realized a simple and cheaper alternative: a laptop with bluetooth should be able to act as networking hub via bluetooth.

To set up an ubuntu laptop in that way, I’ve used the blueman package to provide a network service from bluetooth, installing along the bluez-compat package that provides the necessary pand and dund utilities.

To route the network from bluetooth to the laptop active network interface, I’ve bridged the created pan1 network interface to the ethernet one.

For the demonstration, I will need to expose locally-defined (in /etc/hosts) domain names to the bluetooth interface. blueman relies on NetworkManager to create that interface, and since Ubuntu 12.04, NetworkManager uses dnsmasq as a DNS cache (apparently to deal with better access to VpN, although with mixed results).

But NetworkManager starts dnsmasq with the --no-hosts parameter, which makes it ignore my locally defined domain names (see why).

So the easiest way to avoid that problem was to stop NetworkManager to use this dnsmasq plugin by commenting out dns = dnsmasq in the /etc/NetworkManager/NetworkManager.conf file.

With this done, I have been able to connect an Android phone running Android 4.2, an Android tablet running Android 3.2, and an iPad running iOS 4.3. For Android, once the two devices are paired (and assuming to above set up has been correctly done), one of the services one can pick from the laptop is internet access, and once selected, the connection works. For the iPad, no additional service selection is needed (presumably, it uses all the available services).

I have not been able to connect an iPhone that way; although I have not found a reliable confirmation of this, I think it is not possible to do.

One problem that I hit with the iPad is that it would not resolve the locally-defined names I was using with the pseudo .local TLD; because iOS reserves .local for mDNS resolution, I had to use a different TLD (e.g. .lan) to make it work.

I will likely have more mobile devices to test in that connection set up; I think there is a limit of the number of devices that can be simultaneously connected that way (7?), but I haven’t confirmed it yet.

I’ve spent a fair amount of my spare time over the past few months writing a book (in French) on mobile Web design and development, with my colleague François Daoust.

The book is now finally available, under the title Relever le défi du Web mobile (taking up the mobile Web challenge) — it can be ordered for instance from Amazon.fr.

We’ve also built a Web site to accompany the book, lewebmobile.fr, which allows our readers to follow the various links given in the book, copy the code samples, and get corrections and updates as we produce them.

We’ve also been honored by contributions from Dan Appelquist, Barbara Ballard, Wolfram Kriesing, and Daniel Glazman, offering their expert opinions on a number of selected topics.

We’re quite proud of the resulting book, and are very much hoping our readers will find in it the answers they need. It has been in any case a very rewarding (if somewhat time consuming) experience!

A good way to start this new year, that I wish excellent to my readers!

I was asked to contribute a paper to include in the proceedings of the conference, and while the proceedings haven’t been published yet, I’ve just published an HTML version of that paper.

The paper starts with reminding of the similarities between mobile Web access and accessibility in terms of requirements, and compares the W3C best practices and guidelines in these domains, building up from the work the Web Accessibility Initiative and the Mobile Web Initiative did over the past years.

It also highlights the concrete differences in the way the two domains are usually approached; in particular, while accessibility is often pushed to be integrated into the main Web site, mobile Web users often benefit from dedicated optimized Web sites.

The newest contribution of that paper probably lies in the last part, in the analysis of the synergies between improving the Web for mobile users and for persons with disabilities, and in particular how mobile Web applications can play a special role for an always more inclusive and rich Web experience.

Comments and thoughts on that hypothesis, and on the paper on general, would be very welcome.

(in that discussion, I distinguish Web apps, i.e. “applications” that run inside the browser, from widgets (in the W3C sense), and in general, Web-technologies based applications: a widget is a packaged/downloadable/installable Web application; as such, it’s closer to a traditional app than a Web app; they share with Web applications the use of HTML/CSS/JavaScript and access to the network as a primary feature.)

I think that struggling to find the boundaries between a Web site and a Web application is only natural, since I don’t think the boundaries are well-defined at all; as far as I know, originally, the word applications started to be applied to Web sites that provided advanced user interactions and capabilities that used to be available only through installable software (à la Google Docs).

One thing that tend to make Web sites look more like applications (in my view) is when they are self-contained, i.e. when they don’t get you to move out of their controlled space (or as little as possible). Under that perspective, I wouldn’t call a search engine or a portal a Web app in general; social network and Web mail are much more likely to fit that constraint.

Personalization as such is probably not a major aspect of making a Web site an application; after all, most traditional applications are only personalized as far as they are configurable, and some are not at all — this of course isn’t to say that personalization is not a major feature of any Web app; it is, and in fact is often a way they can be much more powerful than traditional applications.

What is the link between presenting a bookmark like a launcher and making a Web site an application? Technically, such a launcher is exactly a bookmark; practically, as a user, if you see something among your list of applications, and if it looks like an application when you start it (e.g. in the iphone, when using the <meta name="apple-mobile-web-app-capable" content="yes" />), then you’ll likely perceive it as an application, no matter whether it’s on the Web or not.

In the end, I think a Web site becomes a Web app when the developer presents it that way, and the user buys into that view.

In terms of what makes that story more credible, some of the parameters that seem important to me:

• self-contained (keep you in their controlled space as much as they can),
• rich/interactive user interface, possibly mimicking the native UI of the device,
• using advanced device capabilities (geolocation, camera integration, etc.) — technologies the Device APIs and Policy Working Group is developing,
• action oriented (rather than information oriented); a tool more than a book,
• not relying heavily on (or hiding when possible) the browser chrome (back button, reload button, URL bar),
• working off-line (e.g. using HTML5 ApplicationCache, localStorage, indexed database, …).

There are probably more of these, but that’s the ones that came off the top of my head. And of course, not all Web apps fit all these parameters; I think most of what people would call a Web app fit at least some of these parameters.

But then again, I don’t know that many people bother about categorizing things as “Web sites”, “web apps” or “native apps”; this is in general mostly a pure IT-world discussion, with a pinch of marketing considerations.

But with all these great new powers come great responsibilities, and one of the attached risk of exposing more of the users data to Web applications is to expose more data then the user wants or is aware of, and of getting these data re-used to her annoyance or harm.

This is a complex and multi-faceted problem to solve: to ensure we hear about as many of the possible solutions as possible, W3C is organizing a workshop on Privacy for Advanced Web APIs in London on July 12 and 13.

Participation is free and open to all, but requires submitting a 1 to 5 pages position paper; if you think you have a useful perspective to bring to that discussion, please read the call for participation and make sure to submit a position paper before June 1st!

I participated last month in a barcamp where we tried to explore the various differences between the development of an installable application based on the a “native” programming language, and an application that lives in the Web browser.

A white paper from a GIA analyst shows some of the reasons why some service and content providers choose native applications in preference to Web applications, according to a survey they made:

(the survey has plenty of other interesting results, e.g. on the higher retention rate of Web applications)

The top two reasons given are:

• Ability to build a superior user interface,
• Access to device hardware capabilities (e.g. accelerometer).

With the ongoing work in the HTML, CSS and SVG Working Groups, the Web is going to catch up quickly with the ability to build a superior user interface — and maybe even going to take the lead given the broad number of experimentations and sharing that the Web enables.

For advanced hardware integration, the WebApps, Device APIs and Policy, and Geolocation Working Groups are bringing a wealth of JavaScript APIs that will hopefully reduce that advantage of native applications in the coming months and years.

Native apps: bring it on!

Among the topics that were discussed, one theme popped up in several of the sessions I took part to: the differences between “native” mobile applications and mobile Web sites, in particular to answer the question that a number of people asked on which path they should choose for their content or service.

I’m summarizing below the main points that I remember being highlighted as differences between the two approaches. Due to the very informal nature of BarCamp discussions, the summary below is unlikely to be an exhaustive look at that question, and should not even be expected to be self-consistent :), but hopefully can it serve as a fodder for further discussion on this topic — that I have seen pretty regularly discussed over the past couple of years.

User Experience

Mobile applications are expected to provide a more integrated experience, using the device specific user interfaces, and with higher expectations in terms of polishing; in contrast, mobile Web sites more often rely on the Web-model of interactions (e.g. links), are more likely to bring themselves out of focus (e.g. through links to other Web sites), and are not necessarily as slick as a specially crafted native application.

Mobile applications can be started whether the user is on-line or not, and are expected to work at least minimally off-line; while the technologies to make Web sites work off-line have started to be deployed (e.g. with HTML5 ApplicationCache), they are not yet prevalent, and users are at this time unlikely to know or remember that they can use a given Web site even when disconnected.

Ease of Development

Some of the developers reported on their experience that developing a given application as a Web site or as a native application required roughly the same amount of effort — although it was noted that it was much simpler and often cheaper to find someone able to produce a Web-based application than a native one, and that the said application could be much more easily ported to other devices as well.

Ease of deployment

The barriers imposed by many applications stores and the unlikeliness that users would upgrade their installed applications made Web-deployed applications quite appealing as they can be released without anybody approval or control, and can be seamlessly upgraded without any user interaction.

The integration of usage statistics was perceived to be easier and more widespread on mobile Web sites, although some solutions have already been deployed on that space for native applications and are likely to grow over time to more applications.

Some people noted that deploying a Web site that would work across a number of devices was not trivial (although it seems to me a priori much easier and cheaper than developing applications for all the existing mobile platforms out there).

For some contexts (e.g. for confidential content or services), mobile Web sites might remain the only available option, at least for platforms where the installation of third-party applications is restricted.

Business Models

Native applications (when distributed through a store) provide an easy way to make money since they make it relatively easy for the user to pay and the provider to be paid — although it was noted that it is increasing difficult to be profitable in a market where the prices and the individual applications visibility are brought down by the number of available applications.

Several people noted that it was possible to get relatively easy user payments for mobile Web provided services (e.g. through premium SMS or through the mobile operator bill), but that they required a lot of interactions with operators.

Advertising was obviously a model available to both channels when providing free applications.

In both cases, the application can serve as additional value to an existing service and thus not require payment of any sort.

Access to advanced devices capabilities

The possibility to send notification to the user, or to interact with a device accelerometer were mentioned as typical examples of features to which native applications have access but Web sites for the most part don’t.

While Web technologies are catching up with access to more advanced capabilities (esp. through HTML5 and the ongoing work in the Device APIs and Policy Working Group where I work), they are more or less guaranteed to lag behind capabilities available to native applications since they require a larger set of actors to agree with each other.

As a counterpoint, as the number of supported capabilities grow, the number of cases where capabilities not available in the Web platform are required diminish, to the point where most applications could be built on the Web; I raised the question of whether at some point the cost of maintaining the many platforms and operating systems that the mobile industry currently offers wouldn’t pass the point (both for manufacturers and developers) where making it only Web-based would be the only viable option.

Discoverability

Applications stores are obviously the main source of discoverability for mobile applications, where particular care needs to be brought on the choice of the description and keywords — very much like the first days of the Web; likewise, the comparison between applications stores and early-Web sites directories was made.

For well-known brands and simple requests, application stores provide a filtered view that can make it easy to be discovered; but for the rest, users are still more likely to use their search engines of choices, where Web-based services dominate since they can be linked to, indexed, etc.

It is unclear how scalable the current model of applications store is, but there is little reason to doubt that they will progressively integrate more advanced search-engines capabilities (e.g. searching for applications that are relevant to the location the user is in).

Convergence

The convergences between the two models were also mentioned:

mobile applications interacting with the Web

many native applications already interact with the Web one way or another, e.g. to get and publish data for their users;

mobile applications incorporating Web content

a number of applications incorporate a Web browser component (e.g. WebView on iPhone/Android) to display existing content from a Web site

mobile applications based on Web technologies

Through the operating system SDK (e.g. Palm WebOS), or through development platforms such as PhoneGap, or through the deployment of Web widgets run-time engines, a number of seemingly native applications are actually developed purely using Web technologies, making a number of distinctions between native apps and mobile Web sites less and less relevant.

I’ve been working over the past few weeks on a nifty little tool that summarizes a number of W3C technologies, including the Mobile Web Best Practices, in a mobile-friendly format, called the W3C Cheatsheet.

See my post in the W3C blog to learn more about it, and send your feedback!

As one of the W3C Systems team member, I’m acutely aware how bad is the practice of fetching DTDs over the network over and over again.

Furthermore, the OMA XHTML MP 1.2 DTDs are broken – they include non-UTF-8 characters in the comments of one of the modules (bug that I have reported a while ago but that still hasn’t been fixed apparently).

But given that XHTML MP 1.2 is mostly equivalent to XHTML Basic 1.1, I thought I would validate the said files against that DTD – but I wanted to make sure I wouldn’t hit the network when doing so.

Unfortunately, the XHTML Basic 1.1 DTD was not installed in my local XML catalog by default as part of the others DTD in the w3c-dtd-xhtml package – I’ve filed a bug report in the hope that it will be in the future, along with the XHMTL+RDFa DTD.

So I looked into adding the XHTML Basic 1.1 DTD to my local XML catalog, and marking it as an equivalent of the XHTML MP 1.2 DTD at the same time. Given that this wasn’t exactly straightforward, I thought I would document here what I did to set that up on my Ubuntu Jaunty install, in the event that someone else would need to do something simiar:

• first, I added the following lines to my /etc/xml/catalog file:

  <delegatePublic publicIdStartString="-//W3C//DTD XHTML Basic 1.1" catalog="file:///etc/xml/w3c-dtd-xhtml.xml"/>
  <!-- Making XHTML MP an equivalent of XHTML Basic 1.1 -->
  <delegatePublic publicIdStartString="-//OMA//DTD XHTML Mobile 1.2" catalog="file:///etc/xml/w3c-dtd-xhtml.xml"/>

• I edited /etc/xml/w3c-dtd-xhtml.xml to add the following lines:

  <delegatePublic publicIdStartString="-//W3C//DTD XHTML Basic 1.1//EN" catalog="file:///usr/share/xml/xhtml/schema/dtd/basic11/catalog.xml"/>
  <!-- Making XHTML MP an equivalent of XHTML Basic 1.1 -->
  <delegatePublic publicIdStartString="-//OMA//DTD XHTML Mobile 1.2//EN" catalog="file:///usr/share/xml/xhtml/schema/dtd/basic11/catalog.xml"/>
  

• I created the directory /usr/share/xml/xhtml/schema/dtd/basic11/ and put the following files in it (available as a Zip file):
  • the SGML Catalog definition of XHTML Basic 1.1 – since I’m now using xmllint rather than the WDG validator, I’m not sure if it works or is useful as is
  • a modified XML Catalog file that points both the XHTML Basic 1.1 FPI (-//W3C//DTD XHTML Basic 1.1//EN) and the XHMTL MP 1.2 FPI (-//OMA//DTD XHTML Mobile 1.2//EN) to the XHTML Basic 1.1 DTD
  • a corrected version of the flat DTD for XHTML Basic 1.1, that includes all the necessary modules as a single file – while it was based on an old version developed by the XHTML Working Group, I had to update it quite a bit to make it actually represent what the XHTML Basic 1.1 spec says
  • I have also included other files that I had found in the similar catalog directory for XHTML Basic 1.0, but I think they’re only useful for SGML-based validation, rather than XML-based – they are also in the Zip file, but may not be useful

  With these changes, I’m now able to validate my XHTML MP/Basic files without hitting the network. But the main lesson for me remains that it isn’t exactly trivial to add DTDs to a catalog when it isn’t done by people who actually know what they’re doing…

  ]]> http://people.w3.org/~dom/archives/2009/06/validating-xhtml-basic-1-1/feed/ 0 http://www.w3.org/blog/MWITeam/2009/06/01/proposed_new_group_to_work_on_device_api http://www.w3.org/blog/MWITeam/2009/06/01/proposed_new_group_to_work_on_device_api#comments Mon, 01 Jun 2009 08:53:55 +0000 Dom http://www.w3.org/blog/MWITeam/2009/06/01/proposed_new_group_to_work_on_device_api Last week, W3C started the formal process to start a new Working Group that would focus on the development of client-side APIs that enable the development of Web Applications and Web Widgets that interact with devices services such as Calendar, Contacts, Camera, etc.

  If the group's creation is approved, this means that in a year or two, Web developers should have a bunch of new standard APIs to make their Web applications even more compelling and integrated with their hosting platforms; on mobile devices, this would make the Web platform an even stiffer competitor to the existing development platforms.

  Stay tuned - we should know more about whether this group will go ahead in a few weeks.

  ]]> http://people.w3.org/~dom/archives/2009/06/proposed-new-group-to-work-on-device-apis/feed/ 0 http://www.w3.org/blog/MWITeam/2009/05/07/xhtml_basic_1_1_proposed_edited_recommen http://www.w3.org/blog/MWITeam/2009/05/07/xhtml_basic_1_1_proposed_edited_recommen#comments Thu, 07 May 2009 15:43:43 +0000 Dom http://www.w3.org/blog/MWITeam/2009/05/07/xhtml_basic_1_1_proposed_edited_recommen http://people.w3.org/~dom/archives/2009/05/xhtml-basic-11-proposed-edited-recommendation/feed/ 0 http://www.w3.org/blog/MWITeam/2009/04/28/mobile_at_www2009 http://www.w3.org/blog/MWITeam/2009/04/28/mobile_at_www2009#comments Tue, 28 Apr 2009 14:17:24 +0000 Dom http://www.w3.org/blog/MWITeam/2009/04/28/mobile_at_www2009 http://people.w3.org/~dom/archives/2009/04/mobile-at-www2009/feed/ 0 http://people.w3.org/~dom/archives/2009/03/device-independent-or-accessible-at-european-accessibility-forum/ http://people.w3.org/~dom/archives/2009/03/device-independent-or-accessible-at-european-accessibility-forum/#comments Tue, 31 Mar 2009 15:34:41 +0000 Dom http://www.w3.org/blog/MWITeam/2009/03/31/device_independent_or_accessible_at_euro http://people.w3.org/~dom/archives/2009/03/device-independent-or-accessible-at-european-accessibility-forum/feed/ 0 http://people.w3.org/~dom/archives/2009/02/exploring-the-world-of-web-video/ http://people.w3.org/~dom/archives/2009/02/exploring-the-world-of-web-video/#comments Wed, 11 Feb 2009 14:33:20 +0000 Dom http://people.w3.org/~dom/?p=190 A colleague of mine recently pointed me to Michael Wesch’s great and inspiring anthropological introduction to YouTube, which made me curious about the use of video as an expression mechanism on the Web.

  Coupling this with my recent upgrade in the camcorder world to a fully digital device, and the early results of the Video in the Web activity W3C started a year ago, I had to start playing in this area to understand it better.

  As a starting point, I thought that I would use the video of the presentation I made to ParisWeb back in 2007 on the Mobile Web Best Practices, also available un-flashed on ParisWeb servers – usefully made available in a by-nc-sa Creative Commons license.

  One thing that I needed to take into account, but was also a driver for this exploratory work, is that we are about to adopt a W3C internal policy that we can only publish media on-line if we ensure a minimum level of accessibility – at this time, this minimum level requires providing a full transcript of any material.

  This post serves as an introduction to my adventures in the hazardous world of Web videos, where you’ll find me finding my way:

  • in the world of transcription, and the tools available to that end on linux,
  • in the formats for publishing and associating the transcripts with the video,
  • the proposed HTMLMediaElement DOM Interface to make it possible to synchronize events with media playing, adding a pinch of JQuery, RDFa and Media Fragment to taste.

  At the end of these stories, you will join me in rejoicing in front of a synchronized, close-captioned and annotated video and slides presentations viewer for your browser – if you browser lives sufficiently on the edge, that is (which I think at this time means specifically Firefox 3.1 beta), and if you’re patient enough to deal with video operations on a 85 MB video. And if you speak or read French.

  And if you’re not patient enough to go past these obstacles, I have prepared a screencast of the system in action:

  Transcript:

  [the screen shows a Web page in a browser, split in 4 zones]

  This is a screencast of a presentation viewer written in HTML and Javascript.

  You can see here [on the top left corner] the area where the video will appear, here [on the top right corner] the slides that will accompany the video presentation, and there [on the bottom left corner] a table of contents.

  If I start the video here [clicking on the play control of the video], you can see the closed captions appearing below the video.

  And then I can navigate in the video and the presentation using the table of content.

  And you can see how the video and the slides get updated live, and I can even have side notes appearing on the side [bottom right corner] of the screen.

  (also available as Ogg/Theora video with a Timed Text transcript.)

  ]]> http://people.w3.org/~dom/archives/2009/02/exploring-the-world-of-web-video/feed/ 1