Unicode Bidirectional Algorithm basics is a repackaging of the initial part of “What you need to know about the bidi algorithm and inline markup” as a standalone article. It provides a gentle introduction to the behaviour of the Unicode Bidirectional Algorithm, and helps you understand why bidirectional text in Arabic, Hebrew, Thaana, Urdu, etc. behaves the way it does.

For Mobile World Congress 2013, W3C worked with several developers including Tomomi Imura (Nokia), Steren Giannini (Joshfire), and Dominique (Dom) Hazaël-Massieux (W3C) on two Web applications to demonstrate some of the new capabilities of HTML5 and related technology. I asked some of them about their experiences creating a camera app, a photo gallery app, and the server-side technology to stitch them together. The resulting demo worked as follows:

• The camera app takes pictures, displays them on the camera, and can post them to various sites, including W3C's own server.
• The W3C server receives the photos and publishes a feed that is updated as new photos arrive.
• The gallery app reads the feed and displays the photos useful on a variety of devices, in our case: smartphone, tablet, television, and laptop.

The camera project began in the Core Mobile Web (Coremob) Community Groupas a way to illustrate both the current capabilities and limitations of the Open Web Platform (OWP).

Ian: Tomomi, when did this project start?

Tomomi: Originally, the app was nothing more than a prototype I wrote for fun. John Kneeland, from Nokia also wanted to work an app that would showcase the capabilities of the OWP. The Coremob CG seemed like the right venue, and we developed the specsin the fall of 2012, shortly before a Coremob face-to-face meeting.

Ian: The Open Web Platform intends to lower the cost of cross-device development (see the related interview with Todd Anglin on the Kendo UI survey). As you built the camera app, what did you find was relatively easy to make work across devices? What was difficult (and how did you solve it)?

Tomomi: Creating a user interface that is platform independent is one of the keys to cross-platform development. When I created the UI for the camera app, I designed it to be independent of the platform's look-and-feel, so a common CSS was all I needed. Non-trivial CSS works fine on all targeted smartphone browsers so I can say that designing the UI was the easiest part. Also, canvas works as expected on most browsers so I did not need extra workaround to support cross-platform.

However, to be honest, it was not as easy to make it cross-platform as I initially expected. A big reason is that the app was meant to showcase new features, which means it relies on new Web technologies that are in the early phases of standardization and not yet broadly interoperable. I found there was no browser that implemented correctly all the APIs I used in the app. In particular, I struggled to use IndexedDB to write photos to local storage. At the time I was coding, only Firefox and IE10 had implemented IndexedDB according to specification. Chrome 18 (was the released version at that time. Now, finally Chrome 25 is out of beta) supports basic IndexedDB, but was using an older version of the specification with no blob support for the database. I had to write extra code to make the demo work on Chrome.

Beside the workaround code, I used PhoneGap for Windows Phone 8 because IE10 for mobile lacks HTML Media Capture capability, although all other features worked fine. This is a hybrid app that, I think, is useful for illustrating how to work with HTML5 in a transitional mode where features not yet available on certain platforms.

Ian: What would you like to do next with the camera app? It's an open source project - are you looking for help from the community on specific aspects?

Tomomi: We have a bunch of things in the pipeline, notably writing tutorials on all aspects of building this app (like providing camera access using HTML media capture, storing pics in IndexedDB, etc.). We also have a nice table with all the key features required to build this app and how well (or poorly) they are supported in different browsers. I definitely want to share our experience in more detail with developers. Before doing that, I plan to simplify some of the code (to remove some hacks). This will cause more browser incompatibility, but my goal is not to promote hacks and tricks, but rather working with Web standards.

Ian: Steren, Joshfire volunteered to be part of this project because you already had a Web-based gallery app. What has been your experience so far (generally) getting your app to work across different devices? In particular, the app works on some televisions. What has been your experience so far with Web technology on televisions?

Steren: Joshfire is creating tools to build applications for today's devices and the ones coming tomorrow. For us, Web technologies are the logical solution to build a multi-device application that is sharing the same codebase on all these devices. The Web Gallery was developed under this model: 80% of the code is shared by all the versions of the app, and the remaining 20% is just for layout adaptation, view hierarchies, and user interactions.

Web technologies have been selected by TV manufacturers as the official tool to build applications for connected TV. That's a good thing and their browsers are now getting better. It was not the case in 2011, where some TV browsers had critical bugs and suffered from major performance issues. Today, it is more easy to develop for TV, I would say it is similar to mobile web development.

Ian: From your perspective, what are the priority features of the Open Web Platform where you think we need to make progress in order to close the gap with native platforms?

Steren: I think developers need features, frameworks and documentation that will help them to build rich client side applications more easily. And to close the gap with native platforms, they also need to be able to access device specific sensors and features (as enabled by projects like Phonegap). Native platforms have application ecosystems that are more than simple URLs: they ask permissions, install locally and auto-update in background. I think the Open Web Platform should provide the same mechanisms. An important priority is also to identify browser problems in the implementation of the specifications. Today, developers notice too many implementation differences that do not appear to be a priority for browser manufacturers.

Ian: Dom, you built the server that hosted the camera and the gallery apps. What were your priorities in building the server? What solutions did you adopt?

Dom: As in any other project, my priority was to do as little as needed. In this case, the server mostly had to act as a go-between for the camera and gallery apps, receiving pictures from the former to display with with the latter.

I chose to develop a node.js-based solution, since I was confident it would let me assemble the various pieces I needed easily; also, one of the features that we were likely to use, Server-Sent-Events, is much easier to implement in an asynchronous environment such as the one provided by node.js.

Ian: We set up this apps to run in a local environment (that is, not on the Web). If we wanted to make available a Web version of these apps, what would you have to change in the server configuration? How would you deal with security? Privacy? Flooding our server with photos?

Dom: There are two options for having the app run in an open environment:

1. Put some sort of access control in front of the upload feature, where only selected users would be allowed to upload pictures, or
2. Put some sort of moderation in place so that any picture would need to be validated before being pushed to the gallery.

The first approach would require some changes in the camera app and the server-side component. The second would require a new client-side component, and would also benefit from different kinds of Denial of Service attack protection (e.g., rate limiting the number of pictures that can be uploaded, using techniques to avoid robot-based submissions, etc.).

I would probably handle privacy issues at a different layer. We would need a policy and a process to determine when and how a given picture can be posted (e.g., asking the submitted to vouch they're not posting a picture of someone without their agreement), and how pictures could be taken down.

Ian: Thank you all for the insights, and good luck with the evolution of these apps!

eBooks & i18n: Richer Internationalization for eBookson 4 June 2013 in Tokyo, Japan, will investigate international functionality that needs to be added to the Open Web Platform. The Open Web Platform includes core W3C technologies such as HTML, CSS, SVG, XML, XSLT, XSL-FO, PNG, RDF, and many more, that are used extensively in eBooks and eBook production.

The goal is to make the various eBook reading platforms suitable for electronic books that use the printing and typesetting traditions of different cultures. If you are interested in participating, please submit a position paper by 30 April 2013. See the Call for Participationfor details.

An Indic Layout Task Forcehas just been announced, as part of the W3C Internationalization Activity. Similar to the very successful Japanese Layout Task Force, the Indic group will provide input to the W3C Open Web Platform related to Indic Languages and Layout.

This task force will gather and integrate feedback from the participating members about the needs and technical feasibility of Indic requirements, and will report the results of its activities as a group back to the Internationalization Core Working Group, as well as to other relevant groups and to the W3C membership and community.

The chair of the Task Force is Swaran Lata, the contact person at the Indian Office of W3C is Somnath Chandra, and the Staff Contact is Richard Ishida. See the home pagefor more information.

In order to participate in, or follow, the work of the Task Force, please subscribe to the mailing list of the Task Force. You therewith also become a member of the Internationalization Interest Group.

Mobile Entrepreneurs Senegal seeks brilliant and motivated entrepreneurs for its second training course

Mobile Entrepreneurs Senegal(MES) is pleased to call for applications from interested individuals/teams seeking to be trained as mobile entrepreneurs, who would develop relevant local mobile applications for the Senegalese communities. MES is a group of mobile entrepreneurs and people interested in the opportunity that the mobile and Web technologies offer to the new generations.

Are you passionate about mobile technologies? Do you have an idea for a new web or mobile service that could change Senegal, Africa and the world? Do you want to become an entrepreneur, but you don’t know exactly how to do it? This is the opportunity for you.

The training program will start on 1st April 2013and will provide tuition, covering subjects ranging from creating mobile applications to putting it to market. We are looking for entrepreneurs who are passionate about leveraging mobile phone technology to develop applications that will bring useful service to local communities and create prosperous businesses.

• The number of seats is limited to 25.
• Please register soon(the registration form is in French).
• Registration fee is 15,000 XOF(approx 30 US$ or 23€)

More details on the training:
(the detailed call for participation is available in English and in French)

The training will take place from April 1 to May 4, 2013alternating between face to face sessions and remote sessions (through the W3DevCampus online training platform). Face to face training sessions will take place at Ecole Supérieure Polytechnique (UCAD).

After the training there will be a period of support and mentoring, during which the trainers will provide support for the development of project prototypes, or for starting new projects following the training.

In May, the participants will have the opportunity to present their project to a panel of international industry experts.

The training is split into three tracks:

• Technology track: Voice, SMS, Mobile Web services and applications, prototyping platforms, intro to HTML5 and Web accessibility;
• Business track: business models, revenue, dealing with operators, intellectual property;
• Design track: understanding your customers, structuring your service, making your service useful, usable, and engaging.

About Mobile Entrepreneurs Senegal:

MES is a project started by the Web Foundation, TNO, PT Inovação, CRS4 and ESMT as part of the European Commission project VOICES. Mobile Entrepreneurs Senegal is actively supported by W3C and Orange Labs.

The MultilingualWeb-LT Working Group published a First Public Working Draft of Metadata for the Multilingual Web – Usage Scenarios and Implementations. This document introduces a variety of usage scenarios and applications for the Internationalization Tag Set (ITS) 2.0

, ranging from simple machine translation or human translation quality check to training for machine translation systems or automatic text analyis. Many of the underlying implemementations will be showcased in the upcoming W3C MultilingualWeb Workshop12-13 March in Rome.

On native app stores, developers find it comparatively easy to bill users, either when they first install the app, or later with in-app billing for digital content. For web apps, developers are faced with a plethora of proprietary solutions often with a clumsy user experience, and to make matters worse, ads, the mainstay of desktop apps, don't work as well on mobile. Is it now time to consider work on standard ways to transfer money, demonstrate proof-of-purchase, and meet other payment needs?

As part of the headlights 2013 exercise, W3C is now conducting a study with a view to gaining a better understanding about the potential for open standards for web payments. We plan to report back to the W3C Advisory Committee in June/July, and will probably follow up with a workshop later this year.

We expect to collect information on the payments task force wikiand to prepare a questionnaire for web developers, as well as to seek input from a broad range of stakeholders. At this point, it tentatively looks like we need an API that is payment solution neutral, and as such can be built on top of existing (or new) payment technologies. In principle, this should allow for such things as proof of purchase, pre-paid vouchers, discount coupons, NFC for touch based payments, person to person payments, offline payments and so forth. The scope of any standards work that may follow is likely to start with a narrow focus, but it is valuable to get a broader understanding of the potential.

The Web Payments Task Forceis open to all, and we invite help from people with relevant expertise and an interest in realizing open standards for web payments. We're interested in help in understanding the ecosystem, figuring the best way to reach out to developer's and other key ecosystem stakeholders, and to provide insightful analysis on the path forward. If you want to contribute, please subscribe to the mailing list, and help us to gather information and organize it on the wiki.

Mind/the/gapby futureshape

I was last week at Mobile World Congress, one of the world biggest events dedicated to mobile, and it was great to see so much enthusiasm on the role that HTML5, and by extension the Web, can play on mobile devices.

HTML5 logos plastering booths, developers hunting for our "HTML5 everywhere" t-shirts, the large number of people that stopped by at our boothto learn how they can be involved, and the various announcements on Web-based operating systems (FirefoxOS, Tizen) all reinforced the Web's importance on mobile.

A lot of the visitors at our booth had questions on the state of various APIs or technologies they need. Every quarter I publish answers to those questions in an overview of Web apps technologies most relevant to mobile. Yesterday I updated the report, which I hope will allow all those interested in Web and mobile to track the abundant work happening in the field.

Yet, while it was great to see so much energy behind the Web, I could not ignore those who were not so enthusiastic: the ones that had tried to base their mobile development on the Web but failed to do so due to a variety of missing features, the ones that are investing in hybrid applications but are encountering hard to workaround bugs, the ones that have been hampered by specific performance issues in implementations, or the many that reported that Web apps are much harder to make known and monetize than their native counterparts.

As part of our annual W3C headlights exercise, I have agreed to lead a task force with the goal of tackling the most important ways in which Web applications lag behind native on mobile.

Our goal is to take a broad view of that gap, identify where the Web platform remains weak, define where its strengths lie compared to other platforms, and based on that analysis, propose an action plan to reduce our most critical weaknesses and take greater advantage of our strong points.

The topic of comparing Web apps and native apps has been discussed (and even sung) at great length; it is certainly not my goal to repeat these discussions (and trust me, you don't want me to sing). Nor is my goal to eliminate native apps: they've always co-existed with the Web (even back when we called them software), and will probably continue do so for a long time.

But it is also clear that many people would rather take advantage of the ability of the Web to reach every device rather than develop many versions of the same application, or would rather keep control on their link with their users rather than abandon it to an intermediary. The recent developer survey from Kendo UIwas certainly heartening in that regard. Still, many encounter a number of barriers when they try to do so.

Some of the barriers that I've heard mentioned frequently include:

• performance, in particular when it comes to user interfaces (e.g. scrolling), as it can affect the user experience dramatically; a whole headlight projectis actually dedicated to the topic;
• discovery: how can developers expose their Web apps to their potential users? How can users rate and review Web apps? What is the right equivalent of application stores for the Web? How centralized would it be? How does it relate to search engine? How can we make it possible to discover context relevant Web apps?
• developer tools: when native SDKs come with full-fledged IDEs, debuggers, profilers, the experience for Web apps developers remain ad-hoc in the best cases; are there systematic problems in our technologies that have made it hard to build good developers tools? how much of a barrier is the design inconsistency among our technologies that the Web legacy requires us to keep around?
• capabilities (e.g. hardware integration): we have already a lot of ongoing work in this space, but are there items that are so important we should dedicate a lot more resources in getting them done faster? Should we boost the efforts such as what the CoreMob Community Grouphas been doing to get greater convergence among implementors on a smaller set of features?

Some of the probably under-used strengths of the Web as a platform would be:

• users don't need to install Web apps, removing the need to "garden our phones" (as I heard Scott Jenson eloquently put it), and thus enabling use cases that are out of reach for native apps;
• the Web is pretty much the only contender when it comes to create apps that run in any connected device, and maybe more futuristically, that break the device barriers completely(e.g. in so called multi-screens scenarios).

Part of the difficulty of this problem is that addressing these barriers, and taking advantage of these strengths depends on whether we're talking of Web apps inside the browser context (with its specific security contraints), Web-based native apps (as defined by the W3C System Applications Working Group), or even hybrid apps.

I have started to collect a lot of my still messy understandingin the W3C wiki.

But the problem is broad enough that I or other people already closely involved in W3C are likely to miss some important perspectives.

So, what is it that you would fix to make the Web the best platform out there on mobile? How would you fix it? Feel free to either join our mailing list , send me mailor simply post comments to this article if you want to share your views!

A new FAQ page devoted to the topic of private-use characters, noncharacters, and sentinels has been posted on the Unicode web site. This FAQ aims to clear up confusion about whether noncharacters are permitted in Unicode text, and how they differ from ordinary private-use characters. The recently published Corrigendum #9: Clarification About Noncharactersmakes it clear that noncharacters are permitted even in interchange, and the new FAQ page addresses some of the fine points about their usage and about differences from other types of Unicode code points. The brief mentions of noncharacters in other FAQ pages have also been updated accordingly.

Are you unclear about what Unicode “noncharacters” even are? The new FAQ page also answers basic questions about noncharacters and private-use characters, and provides a bit of history about how they came to be part of the Unicode Standard.