Forget about the 2.0 as you could say that Web 2.0 generally speaking is in fact referring to Mobile Web due to the huge change it will have on society etc.

So, Web on a phone is anything that you can access using your desktop computer using a browser. Make sense?

I say don’t restrict the definition to XHTML because the W3C is currently working on a new language to help improve the Mobile Web experience.

we have GPRS at the lower level upon which the application protocol (wap/mobile web ) acts on

WAP : to access internat from mobile phones , but renders WML pages only. basically the wap browser/protocol supports only WML pages

MOBILE WEB 2.0 : to access internet from mobile phones, but render XHTML pages. Basically a subset of tags of PC Browser. So this is more in use than wap

correct me if i am wrong …

thanks is advance
BALAJIK

One might say that any discussion of mobile content must include adaptation, but I think you agree that you can tackle these questions separately since you’ve also chosen to write practices that don’t relate specifically to adaptation, but rather what is delivered. “Best” is always a loaded term, no doubt, but it’s really “best practices for developing effective mobile content” not “practices for developing the best, most flashy mobile content.”

Best practices are definitely, explicitly aimed at an existing device, the “Default Delivery Context”. Some would suggest it’s the device of yesterday even. This hasn’t changed since last time you said you didn’t understand this part months ago… DDC has been in the document for a long time.

One-web: maybe we have terms mixed up or else there is violent agreement. The document says nothing about content negotiation, if that’s what one-web suggests to you, or how one URL should or shouldn’t deliver mobile and web content. It’s just about the mobile content. It sure suggests nothing like writing one XHTML doc and making a mobile version purely from CSS @media=”handheld”, if that’s what you are thinking of.

As to whether media selectors should exist at all: I personally don’t know enough to speak intelligently on this. For what it’s worth the BP document isn’t promoting or discouraging them.

WURFL data is used internally, you bet.

absolutely. CSS media types are being pushed by Opera because they are the ones who invented it and put a lot of effort in supporting them first and making them a W3C thing right after. I can’t recall any discussion about usage of Media Types on WMLProgramming. Zero developer adoption.

As a developer, I think it’s better to have an extra technology more, rather than less. So, I am not saying that Media Types should be killed or aything. Having said this, because of the little sense one-web makes, I would say that media-types are also sort of misleading for authors new to mobile development. This is a bit like the SQL tag-libs for those who do JSP. Virtually everyone by now agrees that nesting SQL statements in your JSPs is a big no-no, yet SQL tag-libs are there, and there are certainly (small-sized) projects in which they are handy. Let’s just make it absolutely clear that the existence of a window does not imply that one should jump out of it, albeit that might be a legitimate escape path in case of fire

Of course, I think that references to media types in BP is bad. Not only have media-types zero mind-share among developers, but by making support of media types part of the baseline, BP has drammatically reduced the set of devices on which BP makes sense (not much outside of Opera). A giant step for my friends in Oslo, a very little step for mankind (and in the opposite direction!)

Luca

To clarify, GAP is not about optimal mobile experience. GAP is meant to be a mobile developer’s “survival kit”. If a developer doesn’t have a clue about mobile, has little resources, but still wants to go mobile, then GAP helps. Developers who want a optimal user-experience across multiple devices should look to either WURFL or one of the commercial frameworks out there.
Just to summarize why I decided to create GAP, the main point I brought to the MWI BPWG table initally (2005) was that the path to “best practices” must necessarily go through adaptation. This point has been refused by the group or, more precisely, BPWG has come to the conclusions that BP is not really about best practices for mobile development, but rather a useful introduction for web developers who want to go mobile but are not aware of the challenges involved (I am tempted to argue that this would have required that W3C gives up the “Best Practice” name: when I hear the term “best”, I think of Ferrari or Mercedes, hardly of Fiat Cinquecento).
At that point, I came to terms with the idea that “survival kit” could still be an OK initiative for W3C to carry out. The problem was that there was too much political s**t to mud the water, with one-web being the most cumbersome object of all. Also, it was not (and still is not) clear which devices BP is aimed at: existing devices? future devices? this lack of clarity is another deadly sin.
In the end, I became so frustrated with how BP was evolving that I decided to write my own version of such a “survival kit”.
Because of the lack of politics and the support of the WURFL community, GAP is superior to BP for the objectives that BPWG itself set.

Finally, GAP does not talk about UAProf, because UAProf is hardly edible for large content providers and operators, let alone other mobile developers. WURFL is a much better option than UAProf for practical purposes and I do point to WURFL from GAP.
By the way, I heard that google is using an adapted version of WURFL, is this true?

Luca

Luca your comments seem to concern content negotiation rather than one-web stuff, but I suppose this depends on what you call “one-web stuff”. I agree, the MWI BPs don’t say much of anything about this (”To determine what formats a device supports, Web sites may use any combination of device profile information such as the HTTP User-Agent header, HTTP Accept headers and UAProf.”). I don’t think that’s overstating Accept — just doesn’t say anything really. Your own doc likewise doesn’t talk about UAProf at all.

I think it’s on purpose… the best practices are about what you deliver when you know you want to deliver mobile content, however you decide that.

So, great, again I see more agreement.

I would think you would object to best practices concerning CSS media types or something, which does seem very “one-web” to me.

> the tone wasn’t harsh in any way, I apologise if
> I insulted you, that wasn’t my intention. I do however,
> believe you are being closed minded about the whole
> mobile web debate in favour of restricted WAP sites

I am not sure what you mean here. You seem to imply that the mobile web isn’t happening because Luca Passani is closed-minded. The world is what it is. I don’t know of any national regulations that say that one can’t make a site that works on mobile phones and desktop PCs. If one can build a site that makes sense both for mobile and web (possibly out of a unique XHTML page!), they are free to do it. The problem is when W3C wants to *enforce* this.
I always considered WEB and WAP very different media in many ways. So far, reality has shown that I have been right. There can be services that overlap over web and mobile, sure, but what I don’t get is why developers need to be told that the two must be made overlap (as MWI BP does), rather than just mentioning that while some services may require a “dual” interface (WEB and WAP), mobile is a different world with different rules. This seems to me like “one-web” dictatorship.

Now, this discussion would be purely accademic if it wasn’t for the fact that the one-web religion is forcing some pointless practices into BP/mobileOK. Obvious examples of this are:
* the attempt to levarage ACCEPT HTTP headers way beyond what makes sense in mobile
* the fact that UAProf (the only widely-supported standard in this area) is basically ignored by BP.

MWI BP is being driven in ways that do not take development needs into account. Ultimately, BP is a hindrance to the creation of mobile content rather than a aid. Being this the case, it only makes sense to ditch “one-web” as fast as possible and start thinking mobile for real, in the meantime, developers are better served by ignoring BP/MobileOK and looking at GAP/WURFL/WALL instead.

Unfortunately for you, Paul, a corollary of this is that Segala’s certifications for mobile probably don’t make much sense until BP is fixed (you would be certifying for sub-optimality).

Luca

PS: James raised some excellent points about blatant inconsistencies in what you wrote, and it seems to me you still owe your blog readers an answer that makes some sense.

That is, not creating two separate pages with each only working on specific devices. Make sense? clear as mud?

You’re in the pit with no getting out!

vs

“I believe content should be contextual to the device. That’s not the same as saying that a page which works on a mobile device should also work on a desktop PC. Note that I didn’t make the point in the other direction – Web to mobile”

Maybe I’ve been caught out with “would”s, “should”s, and double-negatives. But how are these two paragraphs consistent?

I had hoped not to get dragged into this thread, actually

every page for every context

I’ve never said this. I believe content should be contextual to the device. That’s not the same as saying that a page which works on a mobile device should also work on a desktop PC. Note that I didn’t make the point in the other direction – Web to mobile

I’m not saying I should go to bbc.co.uk and see exactly the same stuff on both mobile and desktop. I believe the BBC should try to create (and adapt) the content in such a way that it renders according to the device. So, it’s likely to look completely different given the size of the BBC’s Web site. However, it’ll be much easier for the long tail in the future (I hope).

despite an increase in cheap, web-enabled handsets, there’s going to be a high population of WAP devices circulating both the developed and developing worlds for many years to come.

I agree.

BTW, I’d consider myself (or at least Segala anyway) as experience in WAP as most - we were responsible for the testing both of O2’s gateways, all devices from 2002 and all content for over 3 years. We also built and maintained the WAP stuff for Vodafone Ireland. We did other stuff too but that’s the significant work.

So, we’re not all desktop people (as you know because it was my team that brought your testing tools into O2 :)). I’d like to think we appreciate the marriage between mobile and desktop.

Isn’t it the web’s answer to Esperanto? …homogeneity isn’t always a good thing.

For the developed world, where mobile is clearly an evolution of the internet, the focus should be on what is better about the mobile medium - which means making more of its unique contextual properties, and in doing so making it less relevant for the desktop.

We often forget this, but the WAP-heads rarely do (perhaps as a nice side-effect of the extra effort they had to put in!)

For the developing world, there is a slightly different mandate, I agree: ensure that humans can be connected to at least some of the internet where they previously were not at all.

But still, that’s not to say that in Africa, for example, on-line services won’t still more easily thrive when they capitalise on mobility; let alone telephony, timeliness and payment (especially payment).

And also, unfortunately, despite an increase in cheap, web-enabled handsets, there’s going to be a high population of WAP devices circulating both the developed and developing worlds for many years to come.

We can’t do anything about this troublesome situation. But we certainly can’t deny those users their right to access compelling mobile services.

So… yes, it sucks, but we’re stuck with it for a while. An overwhelming need to try to navigate a complex interplay of technologies, standards, commerce, human aspiration, morals and culture.

Certainly a tough nut to crack on our incendiary blog thread hence my hope for tolerance, evangelism, and JFDI-ness.

Correct me if I’m wrong, but isn’t .mobi’s position more straight forward. It cares that people have access to content via a mobile device, whether that’s accessible on a desktop PC or not isn’t an issue. That’s not a bad thing, as we all take a position.

I on the other hand, would like to ensure that (Web) pages that work on desktop computers also work on mobiles. At the same time, I would like to help ensure that (Web) pages built for mobiles also work on desktop computers.

WAP is excluded from this conversation as I’m not talking about stuff built with WML which doesn’t work on desktops. Web and WAP are technically and socially two different things. It’s like comparing apples with oranges.

Does anyone actually want to use the web on their mobile phone?

Actually it’s a trick question. The answers are “yes”, “no”, and “perhaps” - depending on which swathes of content or service you’re looking at.

Hopefully no-one really still thinks we should broadly “see the desktop Web realised on [...] mobile phones”. Not even Steve Jobs.

Since, by definition, little on today’s “desktop Web” caters for a user’s mobile context, it would be a next-to-worthless goal - at least if you were expecting to somehow persuade users to flock to this exciting new medium.

This is something that Luca and the WAP development world know well (since their markup is useless anywhere else): focus on the mobility.

(Oh, and don’t forget the handsets are all different. Oh, and - whilst you’re at it - take advantage of the other things that mobile devices & networks do well: timeliness, location, payment, imaging… Oh, and telephony, anyone?)

So how can we possibly expect current content and services to cater perfectly for mobile and fixed devices, mobile and fixed users, mobile and fixed contexts - without compromise somewhere? Compromise which won’t survive in a free market.

We, the mobilati, should waste less energy slugging out lengthy discussions on the meaning of “one web”, the subtleties and morals of device adaptation, and whether we like or dislike WAP Luca Passani. (Now… I wonder why the web development population finds mobile so opaque and unapproachable?)

We have standards bodies that put the effort into articulating best practices - whether you agree with them or not. We have motivated and talented individuals - who are doing their own thing. And we have many commercial organisations (that most of us work for) - that are entitled to have different positions again.

Each party has a role to play in shaping the evolving mobile ecosystem. Each has a right to participate. Each has a right to a fairly-heard opinion.

But we shouldn’t necessarily expect to agree: the mobile web is not a democratically-elected government. In fact it is more like a jungle (and not just endless, impenetrable and humid…). I mean in a Darwinian-survival-of-the-fittest, Grandmaster-Flash sort of way.

We must expect to have to [watch it play / fight it] out in the marketplace - where the meritocracy of economic forces rules. And where blog eloquence counts for nothing.

We all have a mandate to get the mobile internet into as many users’ hands as possible - its inevitable, yet barely defined or glimpsed evolution. Let’s make it happen out there, where it matters.

JP, CTO, .mobi

> I believe this because it would mean less reliance on WURFL.
> To take an extreme measure to demonstrate my point,
> what would you do if WAPdisappeared?

first WURFL has taken the world by storm, but it is not my job, or at least it is just one of the many activities I may perform in my job. I am an Openwave consultant and I earn my living by doing other things too (always mobile related of course).
Secondly, if WAP disappeared, there are a bunch of other areas in mobile that are not WAP and where I am sure I could contribute as part of a decently paid job (probably still as Openwave).

In short, I do not like the tone of this comment, Paul.
WURFL exists because of me (and Andrea), not the other way around.

Luca