Archives for: April 2009
2009-04-30
New translation: 使用<select>鏈結到本地化內容
Thanks to Samuel Chong the FAQ-based article "Using <select> to Link to Localized Content" has now been translated into Traditional Chinese. [search key: qa-navigation-select]
2009-04-28
Mobile at WWW2009
Last week, I was participating to WWW2009 in Madrid - each year, the World Wide Conference, the mother of all Web conferences, hosts a track organized and animated by W3C.
I think it was the first time that the Mobile Web got so much visibility in this conference: most (if not all) of the rather prestigious participants to the Web 20th anniversary panel mentioned the potential of the mobile web in their thoughts for the future of the Web, and more generally, the mobile web was a recurrent theme in most of the keynotes of the conference.
The other big theme was clearly around social networks, a topic close to my heart due to my involvement in the Workshop on the Future of Social Networking that led to the recent creation of the Social Web Incubator Group in W3C.
And both of these topics were at the very heart of the W3C Track in the conference - this year, the track was run as a couple of camps: one on Mobile Widgets, the other on Social Web, with clearly some overlap of interests between the two sessions.
I thought that both sessions were quite a lot of fun - I got to write my first widget in the first camp -, and I really enjoyed the opportunity to interact with all of the participants that chose to take part to that exercice! Hopefully, I'll find some time to gather and formats the notes that were taken during the various discussions groups.
Overall, I enjoyed the conference very much, and I was glad to see that the number of people that look at you like you're a madman when mentioning the usage of Web on mobile devices as important is declining very quickly...
2009-04-22
New OWL 2 Working Drafts
2009-04-20
RIF completes "lucky 13th" F2F
2009-04-16
Mobile Widgets and Social Web camps at WWW09
W3C invites people to attend the W3C Track at WWW2009, in Madrid, Spain on 23-24 April 2009. Part of WWW2009, the first day of the track is a Mobile Widgets Camp and the second a Social Web Camp. Conference participants and the local developer community are invited to submit topics of discussion in advance, via the W3C Track wikis.
2009-04-10
Minutes of Feb. 16 teleconference published
The MW4D IG held its 14th teleconference on February 16th 2009.
The approved minutes are available at http://www.w3.org/2009/02/16-mw4d-minutes.html
Previous meeting minutes are available from the teleconference archives
2009-04-09
Try your mobile browser before you buy
In England there are several shops on the high street which sell mobile devices such as:
- Handset manufacturers - Nokia, Sony, Apple
- Operators - Vodafone, O2, Orange, T-mobile
- Independent retailers like Carphone warehouse, Phones 4 U, Currys & like wise
Only recently I've noticed that some stores allow you to surf the Web on your devices, such as the Nokia flagship store in Regent street, London. Perhaps your local mobile shop now offers a similar service?
Where shops do not offer this facility, please take a moment to politely request Internet access in order to test the mobile's browser(s) on your favourite Web applications.
And what test could you use? Try the WCTMB test and please submit the results.
Be aware that some shops seem to operate odd policies when it comes to photographing the device.
There are many different mobile devices with many different features to choose from. Please make a good quality Web browser be one of them!
2009-04-08
W3C Launches Social Web Incubator Group
Following the "Future of Social Networking" workshop report recommendations, W3C is pleased to announce the creation of the Social Web Incubator Group. The group's mission is to understand the systems and technologies that permit the description and identification of people, groups, organizations, and user-generated content in extensible and privacy-respecting ways (read also the group's charter for more details). The group will be co-chaired by Dan Applequist (Vodafone), Dan Brickley (Vrije Universiteit), Harry Halpin (W3C Fellow from the University of Edinburgh with support from Eduserv).
2009-04-07
New test
As the inputmode attribute has been dropped from the current draft of the HTML5 spec, we have now replaced the inputmode part of the Web Compatibility Test for Mobile browsers. In its place you will now find a new JavaScript framework test.
Modern web sites and web applications are becoming increasingly complex, often relying on large client-side scripts. A few different JavaScript frameworks aiming to ease the life of script authors have become very popular in recent years, and is today deployed on countless sites.
Any mobile browser that intends to make full use of said sites and applications must be able to load and use these libraries. Our new tests consists of loading the library of jQuery and the executing the simplest possible test using this library:
$(document).ready(function() { $("#jquery").addClass("green"); });2009-04-06
Social Web Incubator Group started at W3C
The What and Why of the Third Last Call
Since making our second Last Call for comments at the end of last year we've responded to all of them and have been completing work on the tools - the processors, the XSLTs and so on - all of which has now been done.
So why aren't we at PR yet? There are a couple of reasons for this. There has been an ongoing battle between (WG member) Stasinos Konstantopoulos and (W3C team member) Eric Prud'hommeaux over whether the POWDER Semantic extension applies to the data layer or the application layer. The two protagonists have agreed to differ whilst the document has gone forward.
The second issue that has arisen concerns the other area that has prompted a lot of comment - the canonicalisation section of the grouping doc. Despite many changes over the last year or so and input from the Internationalisation WG, (W3C team member) Thomas Roessler spotted more problems with this section.
After a lot of e-mail bouncing around on, I'm sorry to say, a team-only list, I had a long conversation with Thomas and (Semantic Web lead) Ivan Herman. Some context:
The Semantic Web (RDF, OWL, SPARQL etc.) is written solely about URIs, not IRIs. Furthermore, all URIs are opaque strings - they have no meaning. This goes back to Jeremy Carroll's useful distinction between "http://www.example.com" and <http://www.example.com>. In other words, for RDF etc. our issue of processing URIs/IRIs as meaningful strings doesn't arise.
IRIs - that is, URIs written in things like Cyrillic script, Japanese Kanji etc. - are going to be more important in the coming 12 - 18 months (according to Thomas who, among other things, represents W3C at ICANN and so has a good grasp of such things). For POWDER not to be useful now and in the near future across all parts of the Web would limit its potential usefulness.
As we have discovered, the encoding of IRIs and International Domain Names is less than clear. However, there is a recognised path to take in this area which involves converting IRIs into ASCII - essentially converting IRIs to URIs.
It is not the POWDER WG's job or wish to solve the whole issue, neither is it within our ability to do so.
The POWDER to POWDER-BASE transform XSLT doesn't do any of the canonicalisation stuff, and it would be hard, if not impossible for it to do so. Therefore, strictly speaking, some form of pre-processing is already necessary before the XSLT is applied (the Perl script does do the canonicalisation but now needs a bit of work).
Given all of the above, the group was faced with a choice between either making significant edits in all its documents to talk only about URIs or, as we have done, further amending the canonicalisation section to introduce the ToASCII function as defined in RFC 3490. It is this change that has prompted the new Last Call announcement, open until Monday 27 April. The documents published on 3 April to coincide with the Last Call reflect all the changes made following comments received in the previous calls and, with the exception of the highlighted sections of the Grouping of Resources document on canonicalisation, are considered stable.
One important, although editorial, change worth highlighting is in the Description Resources document. The definition of the describedby relationship type and the two POWDER Content Types is much improved. describedby is now included in the IANA registry of ATOM Link relationship types.
The Test Suite has been significantly updated in the 3 April version and is now unlikely to change significantly (we may add some new tests for the canonicalisation section). Perhaps rather perversely, the test suite does include a test for the informative section on HTTP Link. The Primer is considered stable and very unlikely to change further.
Minor adjustments to the POWDER Processors are in progress and, notwithstanding changes prompted by the last call, the group is expecting to go to Proposed Recommendation in May.
Five POWDER Documents published; Three Last Call Drafts
- Description Resources (Last Call); which details the creation and lifecycle of Description Resources (DRs), which encapsulate metadata
- Grouping of Resources (Last Call); which describes how sets of IRIs can be defined such that descriptions or other data can be applied to the resources obtained by dereferencing IRIs that are elements of the set.
- Formal Semantics (Last Call); which describes how the relatively simple operational format of a POWDER document can be transformed for processing by Semantic Web tools
- Primer
- Test Suite
2009-04-03
New SW Case Study by Twine
2009-04-01
eGovernment Stakeholder Meeting Summary Published
W3C MWI Opens Maputo Workshop on Fostering Development through Mobile Technologies
Today is the first day of the W3C Workshop on the Africa Perspective on the Role of Mobile Technologies in Fostering Social and Economic Development, in Maputo, Mozambique. The agenda of the Workshop focuses on the challenges of using mobile phones and Web technologies to deliver services to underprivileged populations of developing countries. International experts, local actors, researchers, and NGOs are participating in the meeting, hosted by the Ministry of Science and Technology of the Government of Mozambique and organized as part of the Digital World Forum project (European Union's FP7).
All webs in one, One Web for all (part 3)
This post is the last post of the One Web series. Previous part focused on the theory behind One Web. Time to focus on One Web in practice!
Neo: I know One Web!
Morpheus: Show me.
One address space
One Web says that you should use one address space: the different versions of a resource should share the same URI used to access the resource from a desktop browser, a mobile device or a TV set.
The need to use one address space applies to all the resources of a given Web site, and not only to the main index page. Deep links (i.e. links to specific pages within a Web site) are common on the Web. The structure of your Web site should be consistent from one version to the other.
Thematic consistency
One Web says that a URI should return predictable results over time and across devices. A user that accesses a URI from different devices, e.g. from his desktop PC and from his mobile phone, should feel that is is the same. In other words, the different versions of a resource should be thematically consistent.
Thematic consistency does not mean that the content has to match exactly. It means that, as far as is reasonable:
- the information provided by the resource should be the same
- the color, the logos, the layout of the content should be close
- the functionality on different devices should be similar
In short, it means that users who switch from one device to another should not have to wonder: "Where is this piece of information I'm looking for? I know it's there, I saw it on my laptop!" A single glance at the different versions should be enough to say "OK, that's the same thing".
The best time to start worrying about thematic consistency is when you design your content:
- Focus on the content or functionality you are trying to provide
- Ensure that the material that is central to the meaning of the page can be easily found on the page (see the CENTRAL_MEANING best practice). Conversely, ensure that the material that is not does not catch the user's attention and could thus be removed to provide a light and short version without creating any thematic inconsistency.
- Prepare alternatives to content that may not be accessible by some devices
- Develop for the Default Delivery Context as a minimum common base, then enhance the user experience for specific classes of devices.
Starting from a default version of your content, there are different ways to enhance the user experience:
- through the use of CSS Media Types to handle both mobile and desktop style sheets. See for instance Return of the Mobile style sheet
- through the use of scripting that degrades gracefully when the device does not support it. See for instance Graceful degradation and progressive enhancement
- through content adaptation. See for instance... below.
Content adaptation
To start using content adaptation and return a version of a Web page that fits the capabilities of the requesting device, you first need to know what these capabilities are.
The requesting device can be identified from the HTTP headers sent in the request, and in particular from the User-Agent, Accept and Accept-Charset HTTP headers. Once identified, the capabilities of the device can be retrieved from a Device Description Repository, i.e. a database that describes mobile devices. There are multiple databases available. The Device Description Repository Simple API standard defines a common interface to access such databases.
Once you know the capabilities of the requesting device, you can eventually exploit them and adapt the response consequently. In the HTTP headers returned with the response, add a Vary HTTP header so that proxies between your server and the final client understand that you use content adaptation and do not incorrectly cache and serve a version of the page that does not match the user agent.
If you start using the
User-Agent HTTP header to adapt your content according to the capabilities of the requesting devices, ensure that the HTTP response you return contains the following HTTP header:
Vary: User-AgentUser-Agent, and will not cache the response inappropriately. Content adaptation comes at a cost: that of having to maintain multiple versions of the same content. Since many devices share similar capabilities, it is good practice to use device classification, so that you only have to manage as few versions of a Web page as possible.
Think of users on the go
Once you've managed to create a few versions specifically tailored for a few classes of devices, you might want to go a bit further and start taking into account the context of the user at large. The capabilities of the user's device are but one side of the user context. Some other considerations:
- the network the device is connected to. A report from AdMob (PDF) shows that 8% of US mobile users browsed the Web over Wifi in November 2008. The usual mobile network constraints (low bandwidth, high latency, data cost) mostly do not apply to Wifi and you might want to provide an enhanced Wifi version. Conversely, when the user is roaming, bytes exchanged over the network are precious.
- the social context of the user. A user browsing on a couch has more time than a user walking in the street who probably just wants a precise piece of information right away. There again, this could lead to different versions.
The generic user context cannot be inferred from the request itself. The user needs to be able to switch from one version to the other, depending on his context. The context could be stored in a cookie, but cookies may be disabled or not supported. And so you need to use distinct URIs for the different contextual versions of a Web page in that case.
Wait! Doesn't that break the one address space rule? Not if you do it properly:
- Maintain and advertise a canonical URI for the Web page. The canonical URI should be used to bookmark the page and should return the most appropriate version of the Web page for the supposed context of the user.
- Ensure that the canonical page links to the other existing versions of the page, either explicitly using
alink elements in HTML pages that users can follow, or implicitly usinglinkelements in HTML pages so that machines (e.g. search engines or mobile browsers) can understand that the versions actually are different instances of the same resource.
The following HTML code says that the current version of the Web page is specifically tailored for mobile (
handheld) devices and that there exists a desktop (screen) version of the Web page.
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>[title]</title>
<link rel="alternate" media="handheld" href="" />
<link rel="alternate" media="screen" href="screen.html" />
</head>
<body>
[body]
</body>
</html> Contexts and versions
What if contexts are so different that thematic consistency seems to be wholly inappropriate? If you find yourself in this situation, you've probably reached the point where you are trying to represent different pages using the same address, and we've seen in the previous post that this is bad practice. Different URIs should be used for the different pages and, although guiding users through the different pages is a good thing, there is no need for a canonical URI per se.
A Web page that contains the biography of an author along with contact details is not the same as a Web page that only contains the author's contact details. The latter page should not be regarded as a mobile version of the former one, but as a different page with a different URI. The latter page may be part of a mobile context where users are looking for practical information.
The dividing line between what constitutes variations of the same page and different pages around the same topic is fuzzy. As a possible rule of thumb, imagine a user being referred to the Web page by one of his friends. If some contexts would leave him wondering what his friend is talking about, different pages are probably needed. Note this only works provided that the reference is more generic than "look at this picture", or "look at the third menu item". Can you think of a better rule?
Wrapping up the One Web series
Neo: What did she tell you?
Morpheus: That I would find the One.
- One Web simply follows from the architecture of the Web.
- One Web is not one version!
- One address space should be used whenever possible.
- Versions of a Web site should be thematically consistent.
- The user context may encompass more than just his device.
- Keep ubiquity in mind while writing content, to reduce the number of versions needed and the amount of adaptation required
- Different contexts may go further than different versions.
Search
Categories
Mobile Web Test Suites Working Group blog
- Announcements (11)
- Opinions (1)
- Testing tools (2)
- Web Compatibility Test (7)
- Widgets testing (3)
Archives
- September 2011 (7)
- August 2011 (23)
- July 2011 (17)
- June 2011 (13)
- May 2011 (18)
- April 2011 (14)
- March 2011 (24)
- February 2011 (15)
- January 2011 (11)
- December 2010 (12)
- November 2010 (19)
- October 2010 (18)
- More...
Misc
XML Feeds
What is RSS?
Who's Online?
- Guest Users: 7
