Mobile Web or Mobile Internet (WAP)?
Triggered by a discussion on a W3C Mobile Web Initiative (MWI) email thread, I wrote a post yesterday which sparked huge debate (43 comments and counting).
Basically one of the participants of the group, Luca Passani, complained about the group using the W3C Web Content Accessibility Guidelines (WCAG) as a starting point for creating the MWI Best Practices document.
It was almost impossible to get across to Luca, that only relevant WCAG stuff was used. The group meticulously reviewed each checkpoint on conference calls and by email until it had exhausted each one. We then added best practices that were specific to mobile.
The conversation digressed into ‘why should we try to make everything accessible to disabled people anyway’. Nobody actually made such a claim in the first place and the conversation started to loose track as it did in my post. In fact, it’s still going on now so I’d like to take it to this post (if it hasn’t already died). Thanks to everyone who has contributed so far.
The post appears to be attracting attention from Luca’s corner of the world. That is, mobile developers who build WAP sites (and other types of mobile related applications). These are very qualified comments so I’m not putting them down in any way. I’m simply highlighting that the conversation needs to be balanced. I think this can be achieved by soliciting feedback from people who wish to see the desktop Web realised on more devices such as mobile phones. Apple and Nokia appear to think it will happen soon.
So, a little background to the MWI
The principal objective of the MWI Best Practice document is to improve the user experience of the Web when accessed from mobile devices.
It is primarily directed at creators, maintainers and operators of Web sites. Readers of this document are expected to be familiar with the creation of Web sites, and to have a general familiarity with the technologies involved, such as Web servers and HTTP.Readers are not expected to have a background in mobile-specific technologies.
So, the MWI is not about encouraging more WAP sites, or any other type of content that is specific to mobile devices and which doesn’t work on other devices such as desktop computers. People who wish to develop such content can do so. So there’s no need to slate the MWI though.
Luca and I violently disagree when it comes to the future of the Web on mobile devices. In short, Luca believes that WAP is the way forward. Or at least, something that is created specific for mobile devices only.
My view, is actually more along the lines of what Tim Berners-Lee wants to see happen (although I’m not speaking on his behalf). I could be wrong, but at least I’m in good company. I believe we should bring the Web as everyone knows it today, to mobile.
Naturally, you can’t just browse the Web on a mobile phone and expect a great experience ‘today’. But we should look to enable it as best we can by delivering content that is a contextual representation of the device accessing it. This will be enabled through standardised mobile browsers, Web enabled mobile devices, cheaper tarriffs and of course, best practices design techniques for developers.
- The number of people without access to the Web is greater than the number who do.
- Most of these people are in developing countries.
- Developing countries are more likely to use mobile as the primary access device for the Web as it’s cheaper than rolling out a fix line network.
- People in developing countries don’t give a toss about the weather or travel information as suggested by just about every mobile ‘expert’ I speak with or listen to. The world is bigger than Slough. And not every train goes from Slough to London.
However, there will *always* be a use case for mobile specific applications. I simply want to promote the Web so it can be accessed by anyone irrespective of their ability, device or location.
That doesn’t mean that every Web site must be accessible to everyone all of the time. It’s about best endeavours.
What do you think? Are you happy to continue using WAP sites or would you like to see better mobile devices, cheaper tariffs and best practices that help developers build mobile friendly Web sites?
When you go into a phone shop as I did recently and ask for a Web enabled phone, do you want to be handed a handset that only supports a list of WAP sites that the operator wants you to access? Or, like me, do you want to browse the Web on a mobile (assume for a second that it’s free) in the future?
I’d love to hear what you think, whether you agree with me or not, of course 
45 Responses to “Mobile Web or Mobile Internet (WAP)?”
Leave a Reply
W3C Web Content Accessibility Guidelines are a set of common sense rules, and I applaud this move as a general philosophy of web design. Though disability is main driver behind the guidelines, the guidelines also enable a best practice in design and usability. Would any project manager disagree with those aims?
In QA, we have to suffer a few years of chaotic web application development, and tidying up the mess left behind. A cruel generalization, but it is common (bad) practice, in effort to get sites up and running to impossible deadlines. Separating out mobile as somehow unique in this drive, has never been further from the truth than now. I have been out of the mobile arena for couple years, but my recent experience with handhelds highlights the fact that it is becoming irrelevant what device you are viewing a website from – what does matter is the extent of your audience. Limiting your audience, is preventing you from seeing outside what you percieve as “your market”.
Even in technology we see fear of progress of change, especially when it fuels a paranoia about excessive control. Development should be a creative endeavor, but it also needs to be tempered with technical and business realities. WAP provided a means to create sites for display on devices that struggled with traditional website applications.
This is now not the case – whether I access a site via mobile or PC or my PSP, I want to have a easy to navigate site, that displays professionally. I don’t care (as a user) what troubles a company is having getting their bloated sites to conform to standards. If I cant get to the site, or it looks shoddy, or prompts me to download numerous plugins, and the updates – you wont see me on your site again. I am sure I am not alone with that attitude.
[...] Just found this after (honest!) I wrote my post about the mobile web. [...]
Interesting question indeed. I think Luca is right when he says that you really need to build a different experience for mobile devices, where we mean “little phones”, than for the desktop. No amount of CSS finesse will bridge the gap between the two by itself.
(And Luca, if you’re reading this, I can only say that I think the MWI group consensus has long matched what we agree on here. The MWI is talking about how to build a usable site for tiny devices and making aggressive recommendations like “no tables” that are quite different than authoring for the desktop. Good news, we agree. If you like to think of it this way: everyone agrees with you.)
That said, I think the web experience you get on a little phone is hopelessly limited. It’s a necessary step, or a novelty, and one whose time will pass — though not any time soon, so, none of us need quit our day job!
I don’t doubt that people will want internet on the go, but, ultimately they’ll want what more sophisticated devices offer — thinking of at least a Blackberry, or the Nokia Communicator, or iPhone. These devices are little desktop computers, and some light transcoding from, say, Opera Mini isn’t going to break desktop sites. It *is* realistic to think that a well-autored one-web-friendly site can be rendered meaningfully on high-end mobile devices like those — really, they are low-end desktop devices.
I think Vint’s comments are, well, not inconsistent with this view — he’s not saying mobile web browsing on a little phone is great, but, it is what people do now and for the foreseeable future in large numbers! But I must disagree that in 20 years we’ll be attempting to access info on little postage-stamp-sized viewports.
For the next 5 years: WAP is the future!
For the future beyond 5 years: WAP is no longer the future of mobile browsing.
I’m with Paul. WAP sucks, it’s a relic which should be consigned to the dustbin ASAP. I am not a techie and I couldn’t give a fig about the details, content is king and one should be able to access it from any device without worrying about the browser or the underlying protocol. If sites have to be re-written multiple times to be viewed with multiple browsers under multiple protocols someone is not doing their job properly.
WRT to accessibility, I think we all owe a big debt to disabled people for helping to make web designers realise that well structured text based sites which give useful information beat the hell out of all those Flash sites which waste valuable bandwidth and time. “Back to Basics†didn’t work for John Major but IMHO it’s not a bad mantra for the web.
[...] Original post by Paul Walsh and plugin by Elliott Back [...]
As head of a company which developed some of the first WAP applications (a couple of which Luca linked to at the time) I feel I know WAP pretty intimately.
Having said that, I’m a strong advocate of having one version of a site not maintaining multiple versions of a site to be served up depending on the client app.
Paul, why did you abandon the other post?
it was so much fun!
Sean, we agree that in a 5 year perspective, WAP-like functionalities pretty much is what Internet on a phone is all about. Nobody knows for sure what’s happening after that period. (I can probably afford not to care for another 4 years
Paul, wanting to browse the big web on a phone is a legitimate aspiration, only problem is: this is not what people want. I’ll tell you more: if you ask your average mobile phone user if they want to browse the web with their phone, some will say yes, but, surprise surprise, they still don’t want to browse the web on their phone. They will try once or twice, sure, but then they’ll think the service has little value to them (particularly when compared against cost) and refrain from browsing the web until they get home. People buy phones for voice calls and SMS messaging. Other usages can only be stimulated by optimizing the user experience. MWI BP is not doing enough to communicate this need to developer and may, in fact, backfire by leading new-comers to believe that simple one-size-fits-all mark-up is enough.
Luca
Luca I can’t wait until you realize just how much we all agree. How is MWI recommending one-size-fits-all markup if it’s saying, for example, that mobile markup shouldn’t use tables? That’s implying that authoring for mobile is something way different than authoring for desktop. I really don’t see what difference of opinion you’re seeing.
What I think is happening is that you remember some comment from someone in MWI in late 2005, when you last participated, and it’s stuck in your mind. I think the MWI documents recommend something drastically different from desktop markup, and drastically customized for mobile — in fact if anything there are voices saying that MWI is suggesting something too extreme, too stripped down, too customized for small mobile devices. Like you, I think this is the most realistic and useful kind of recommendation to make right now.
Sean, as I said before, I am willing to contribute GAP practices to BP, as long as the the BP group gives up on the “one-web” postulate. This is my main objection to BP.
As far as which recommendation is best for new mobile developers , while I believe that GAP serves developers better than BP, I am the first one to say that GAP is just a “survival kit”. Acceptable results can only be achieved through adaptation, which doesn’t seem to be exactly around the corner for MWI…(I don’t even perceive that BPWG members agree on what is meant by adaptation).
Anyway, I know that you are putting a lot of effort into the MWI initiative and you are driven by good intentions. This is commendable. Best of luck.
Luca
You keep talking about “one-web” and I don’t know what you mean, in regards to the MWI documents. I really think you’re just remembering part of a conversation from over a year ago or something.
It specifically does not mention adaptation, or content negotiation of any kind. It specifically recommends developing different markup for mobile devices. What is “one-web” about that? I just don’t know what you’re talking about.
But… I am further confused that you derived GAP from the same set of guidelines, and call that “not one-web”, and then further say that really, you mean adaptation is vital, which is a very “one-web” principle to me.
We all have good intentions of course. I just wish I understood what you were talking about.
Sean, I could disclose a few emails that went by on BPWG which show how different people mean different things by “one web”. Of course, after many months spent massaging the wording, all the MWI BP-related documents mean everything any BPWG member wants it to mean (as an aside, that’s why they are not intellegible by your average developer). Anyway, disclosing member-only emails is probably not a good idea, so I’ll stick to definitions published on the W3C website:
http://www.w3.org/TR/mobile-bp/#OneWeb
“As discussed in the Scope document [Scope], One Web means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using. However, it does not mean that exactly the same information is available in exactly the same representation across all devices.”
In spite of the ‘however’-part, *this is bullshit*. If I want to build a web site, why should I necessarily care about people with mobile devices? this would just be a distraction and a hindrance, unless there is a business case for supporting mobile devices too.
The opposite case is even more true: if I want to build a mobile applications that only makes sense when people are mobile (downloads, billing), why should I be distracted by having to build a web interface too?
Of course, there can be cases where both a web and a mobile UI may make sense, but why should it be enforced and not just allowed? As a developer, I see “one web” as the attempt by W3C and other companies to gain mindshare and build a position in the industry in ways that I find sort of “unethical”.
The sooner “one web” is dropped, the sooner W3C has a chance to start talking sense again.
Finally, I don’t think it’s fair to say that I derived GAP from BP. First off, I (co-)authored some of the documents that BP took inspiration from (XHTML MP reference and guidelines from Openwave) and I was contributing to the discussions which generated BP. Secondly, I built GAP out of disagreement with the decisions that were being taken for BP, mainly because of stupid “one web”. Third, I made GAP open to feedback from real mobile developers, which further validated GAP’s content. In short, GAP is *not* derived from BP. GAP is original work.
Luca
I was part of the earlier post, and I was astounded at the reactions to the the planned improvements to guidelines to the web. Most of the adverse reactions are based around a paranoia that this is the thin end of a heavier policed internet. I fail to see their point, as the internet had already become a thriving ground for control freak corporations, insipid viral marketing, email spamming, companies buying their way into top search engine results, amateur coding, etc… could go on, but getting into grumpy-old-man territory!
Data should be machine-friendly – i.e. easy to read, easy to manipulate. This is period – not just websites.
These new movements will assist quality control – in design, coding and operation. What the resistance do not like is some set of guidelines telling them how they should code, for optimum web compatibility. Well, tough – code and design right in the first place.
WAP or web? Again, the progress of the web is not inevitable on this level. At 39, I am not in many target marketing groups, but I can see benefit of web browsing on mobile devices. As web surfing is still a major leisure activity for many age groups, so it seems logical to follow a web, not a WAP route. To make assumption that people do not want to surf the web on the mobile, is frankly naiive.
This wont be a popular statement, but “one web” is ultimately inevitable, and those who resist that aspiration now, will pay for it later. Although there have been some recent good movements in mobile industry (vodafine betavine), overall it is dragging its heels and has too much of an autonomous attitude. Rather than just find problems that dont exist yet, a more proactive attitude is better. Its a matter of everyone having to make compromises to move forward to a more cohesive and streamlined web, where it doesnt (and shouldnt) matter what device I view a site from. Basically less whining, more positivity – otherwise the next generation will be steaming past you double quick, to do what you failed to help push forward, “daddio”
In short, Luca you don’t want people to be able to access
the same Web on mobiles as they do on desktop PCs, at least, not as a result of
the MWI BPs. 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 WAP
disappeared?
Very interesting debate you got going on here. A topic I myself have thought and mashed about in head for a very long time. Some further opinions to add to the discussion from me:
* I think the debate is about whether websites should be designed to work well on both PCs and on mobiles without different versions for either.
* If the above is true, then my belief is the converse; I think for quite some time, content providers for desktop web that are interested in delivering to mobile will do so with a “separate” version of their site – a version designed to work well on a mobile. The reason why is that a) not all handsets support full web browsers yet and b) even if they did, I don’t think it’s necessarily desirable for most content providers *to both channels* design their “one web” sites so that they run great without modification on both desktop and mobile phone. The UI is just too different in a world where the UI is expected to see ever-increasing degrees of sophistication on the desktop. Just look at the extremes to which browsers/DHTML/Javascript/Flash are being used to deliver websites today on the desktop. That level of sophistication in the UI will just not work the same way in mobile. Not for a while anyway. Sure there will be smart innovations in UI and I/O on mobile, but I still believe for the next few years anyway, that desktop and mobile web, whilst sharing the same underlying technologies, will have different *design* aspects.
* I think the MWI provides an excellent set of guidelines for Content Providers to *design* great web sites that work well on mobile phones.
* Likewise, it seems to me that WURFL also aims to help Content Providers deliver better web sites for mobile phones.
* It seems to me that WURFL and MWI are great tools for a Content Provider who wishes to develop a web site that works great on mobile phones.
* But longer term, I think both desktop and mobile are desperately in need of a new runtime for connected Internet apps. We are taking browsers and Javascript to breaking limits and there needs to be something new. I really hope that, whatever it is, it sdopts the same runtime on PC as it is on mobile. We should avoid the problems that have plagued Java on both desktop and mobile. Look J2SE on the desktop it’s been rubbish-heaped by Flash. And whilst content providers have braved it with MIDP on mobile, I think it is not the long term answer beyond limited apps like games etc.
* I may have not fully understood the debate so apols in advance if I haven’t “got it”, but I guess I am mostly agreeing with Luca? But I think the MWI is a good thing too.
Jag
Yes *but* it doesn’t mean that a mobile user visiting o2.co.uk should see exactly the same content when using a desktop computer to access the same URI. It’s important that the content is a contextual representation of the device.
Content that is created specifically for mobile devices will always be required. WAP, iMode and Live will not be replaced. That is of course, unless users decide not to use them in favour of surfing the Web on more advanced mobile devices using a browser that supports an improved markup in the future. It’s important that I stress my belief and support for mobile specific content.
The MWI, is about helping developers build Web sites that work on desktop computers and which will work much better on mobile devices. Today, the best practices assume adaptation is required most of the time. It also assumes a baseline device which has specific capabilities. It’s not about delivering cut down content that works on the lowest common dominator.
We are working on the premise that markup is improving with XHTML-MP being the best of a bad lot today. We’re also working on the premise that device capabilities are improving and the cost of data will come down – all the usual suspects that prohibit a good users experience today.
I don’t think you’re fully in agreement with Luca. I agree that there is space for both MWI and WURFL. Luca doesn’t realise that he’s agreeing with the MWI, as pointed out by Sean many times. Luca doesn’t believe in trying to create any best practices that will encourage the design or development of content that works on both desktop and mobile. He believes in keeping the two completely separate (full stop). Something I’m passionate in fighting against because if we retain this view indefinitely we’ll split the Web.
I need to reiterate that I’m all for developing separate content for mobile, where appropriate. I also think there’s a use case for developing content that is platform agnostic and device independent.
Some repetition in there but you’ll see that a lot throughout this debate as people take paragraphs out of context when not backed up with explanations at every turn
Ok, I think I better understand it now. You said:
“The MWI, is about helping developers build Web sites that work on desktop computers and which will work much better on mobile devices. Today, the best practices assume adaptation is required most of the time. It also assumes a baseline device which has specific capabilities. It’s not about delivering cut down content that works on the lowest common dominator.”
Apologies in advance if I’m singling out this para and it takes it out of context, but I think that if what you said above reflects the intent of MWI, then that’s great; it reflects the practical “real” world. And, it seems to me that tools like WURFL *help* the Content Provider (CP) make decisions upon which adaptation of markup can be made for mobiles, which is a great thing too. Whether a CP chooses to maintain a different branch of the “code (markup) tree” (for all or parts of a website) or whether they choose to dynamically adapt from a single workflow at runtime is really up to the CP and what user experience they are trying to deliver. In other words WURFL is just one (potentially useful) tool in the CP’s armoury for developing a good experience for mobile.
So, all said, if I’ve understood the intent correctly there appears to be no debate, at least conceptually. I can see that Luca’s narrative on the difference between his GAP and the MWI BP outputs highlight some differences in opinion as to what is good practise or not, but overall the intent seems to be the same; i.e. a good experience for users of a website on their mobile phones.
Have I “got it”?
Jag – on the nose!
It’s worth pointing out that Luca’s colleague, Andrea, who also runs WURFL continues to contribute to the MWI in a very positive way. Luca has always been unhelpful. Although, there were times when Luca and I chatted on Skype and he appeared to support, or at least, understand the initiative.
What I would like to add is that the MWI is also creating a repository of device descriptions. WURFL relies on a community to contribute to its database but it’s unverified and incomplete. I do appreciate the significance of WURFL but we need something better. The MWI is creating a verified database with a standardised interface.
I remember having an interesting conversation with Andrea over a W3C dinner in Rome. I suggested that WURFL support the MWI and look to working with it, instead of against it.
A quick clarification here, the W3C DDWG (Device Description Working Group), which is also part of MWI, is not creating a verified database, but we are creating a standardised interface, and a core vocabulary to go with it. Once the interfaces are defined, we will call upon people to implement, so that it can be seen if they work. Resources permitting, we will answer the call ourselves too. Whether any or all of the eventual implementations are “verified†or not, will depend on the contributors, but you will at least be able to check (as it’s part of the intended API).
We are executing the process carefully. Over time, we will be putting more and more of our work onto the group wiki, and anyone can make suggestions for additions/updates via the public mailing list. We are working with the OMA to ensure our mutual interests are tended to, and to share our expertise. We are working with many representatives of the mobile community, and that also includes Luca and Andrea from WURFL, two gentlemen who have contributed much of their experience (and passion) regarding mobile technology, and for which as Chair I am grateful.
If all goes well, the Device Description Repository will come alive. It will be populated with key information about mobile devices to facilitate content adaptation, and hopefully it will continue to grow. You can read about the group’s goals on the group home page.
Does the goal of creating such a repository mean that we see adaptation as the only option? Do we expect that some clever transcoding coupled with the repository will solve all the diversity issues, and we will have “one Web� I don’t think so. Adaptation will get you only so far. It can help to avoid sending things to mobile devices that might not fit, won’t work properly, could crash it, will be rendered badly etc. It can help to select from options that are likely to work better, like certain styles, image formats, navigation links, form layout etc. It can even completely rewrite the markup.
What it cannot do is replace creativity.
Putting a large complex Web page (like something you find designed for PC browsers) onto a small screen mobile device is technically possible, but it lacks the human touch. We can use the same Web technology for all kinds of devices, but to get the best results we should use the technology in different ways when the circumstances (constraints and opportunities) demand.
Content adaptation can ease the burden, but if you want your mobile site to have the same impact as your big screen version, you better be prepared to do a little bit of work. Adaptation will take away much of the technical challenge, but engaging sites (mobile or otherwise) require the touch of an artist.
MWI BP, GAP, WCAG and all the other guidelines are there to help people who are willing to put in some effort. In some cases, you have no choice: your customers demand it, the government demands it, caring for your fellow human beings demands it! Then you have to do it within the confines of the resources available to you. Things like UAProf, CC/PP, WURFL and eventually the DDR, are there to reduce the technical overhead, so you can apply more resources to what matters: making your chosen aspect of the Web the best it can be.
Rotan, you said:
“Adaptation will take away much of the technical challenge, but engaging sites (mobile or otherwise) require the touch of an artist. … so you can apply more resources to what matters: making your chosen aspect of the Web the best it can be”
I really like the whole of your comment above, but I think those statements in particular speak volumes, and deserve to be heard again and again. Well said!
Rotan – thanks for the clarification regarding the repository. I am however, a little surprised (probably because I haven’t been following the DD work as closely as I should be, sorry!) that it’s not going to have a verified database. Wasn’t this something we discussed at the beginning?
So, how do we get a verified database because getting technical specifications isn’t easy and I don’t think we should be relying on the community to provide it (although it does help!)?
I remember speaking to Graham Trickey, Technical Director, GSMA (in 2005) at the Global Messaging Awards where we were both judges. I told him that Segala was thinking of creating such a database to help content providers accelerate new content to market. Without a prompt, he said he would help communicate with vendors to see what could be done, as the GSMA did try to do this when MMS was first launched. However, I never progressed the conversation after as my priorities changed. This was at a time when Segala used to do a lot of testing for O2 and we realised the importance of getting devices early, but also realising that they were shipped even to Operators, without specifications. The profiles they used weren’t particularly helpful either.
Jag – I agree
This is why the BPs are so important. They stress best practice design principles for developers.
Hi Paul,
Let me clarify my clarification. The DD group is not *chartered* to create a verified database, but that does not mean that verified data will not form part of the eventual solution. The only thing in our charter in this respect is a Call (that’s a capital C) for implementations (of the API and Repository). The API is expected to have the means to determine if you are dealing with verified data, or not.
We discussed at the beginning many ways in which we might be able to achieve a verified instance within the eventual implementations, and still see this as a valuable objective, even if it is not chartered. You cannot charter the W3C to bring together something that it has no control over, and information about devices is one such thing. Hopefully, by providing the technology and framework in which one could obtain reliable information, it will come to pass. Certainly, there will be many people in DD who will be working hard (probably behind the scenes) to make this happen.
It is also important to recognise the need to support unverified and private aspects of the eventual repository technology. If the solution demanded that all contributions were verified, then WURFL could not participate. Nor could you include information for your own use. What the DD group eventually decided was that the DDR could host (probably in a distributed manner) all contributions, validated according to a vocabulary (or ontology) and optionally verified. Furthermore, the API would have the means for a consumer of the data to determine the status of the data.
Think of it like the authoritative status of responses from a DNS server.
Everyone agrees that having information about the user agents (the devices and the software therein) is beneficial. Everyone also agrees that the information that is out there comes in varying quality. What we want to do in DD is find a way to bring it all together, sort it out and make it available to everyone. Just having somewhere for people to put this data will be a major achievement.
If anyone (including Segala) is thinking of gathering device information, the DDR will be the place to put it. If you want to host it yourself, then (just like a DNS server) you can. We don’t have the ontology or APIs designed yet, but anyone can help by reading our wiki, public mail or blog. To date, most of our work was in private, but now we are migrating to the public domain. As they say: watch this space.
Rotan – it’s brilliant to get it from the horse’s mouth
I was aware of what you just said. The only bit that I got confused over was
We discussed at the beginning many ways in which we might be able to achieve a verified instance within the eventual implementations, and still see this as a valuable objective, even if it is not chartered.
I took it for granted (doh!) that the Charter would include the database. However, I understand why it doesn’t.
Segala has not intention of creating such a database. However, I’d like to engage with Operators (and others) to see if we can create a central low cost verification process that would help content providers accelerate new content to market. I’ll write a specific post for this and ask for your feedback if that’s ok ïŠ
I like your suggestions Paul.
One thing I would like to point out is the difference between validated and verified data, because not everyone appreciates the difference. Validated data is data that adheres to a particular format, like an XML Schema or DTD. Many people know the annoyance of getting a device profile and discovering it wont parse.
Verification, on the other hand, checks the data against reality. If the information says that the screen is 260 pixels wide, then validation would merely check that the value exists, is a positive integer and uses pixels for units. Verification would involve someone you trust actually counting the pixels, or the original source of the information giving a guarantee that the information is correct.
In DD we think that validation will be the easiest issue to solve, because all data shall go in and out via the APIs and they will be responsible for managing the representations. It’s the verification that will be a problem. A low cost process sounds very interesting, and we’d welcome comments on the mailing list.
Rotan – yes, there are too few of us who get the difference. Wasn’t that a great debate on the w3c email discussion
I might have even used the wrong term in this instance, but you know what I meant
People, I am on holiday and the internet connection here is more expensive than using a mobile phone, so I am sorry that I can’t keep up with all of the discussions going on at this party. Just one point about something Paul wrote:
> 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
Luca – 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
We keep forgetting one very important question:
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
James – isn’t it interesting though, to see such passionate debates around the subject?!
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.
I don’t believe in your broad “every page for every context” ambition.
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.
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).
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.
“I [...] 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”
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
Ensure that they work and are contextual
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!
back from vacation and I see that the record needs to be set straight about a few things that have been said here.
> 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.
I must continue to completely agree with Luca about Web vs. WAP. They are not so similar that a little clever markup will bridge the gap. I think we’ll still need to think about mobile-specific sites, markup, technologies, and best practices for a while to come. So good that we have so many best practices to choose from!
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.
Sean, I am always happy when someone from Google in general and you in particular agree with me.
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
> I would think you would object to best practices
> concerning CSS media types or something,
> which does seem very “one-web†to me
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
My phone doesn’t care how the markup it gets is generated, whether by an adaptation engine or a text editor, by a machine or loving hands. So, what matters most is the markup that gets delivered, and how. The Best Practices now just cover the markup that gets delivered, not how you make it. Adaptation is just a separate question.
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.
[...] I’m please to report that they’re not bogus comments either, they come from well placed people within companies such as Google, .mobi, Opera, MobileAware, WURFL and others. The conversation has actually split into another post recently and the debate is still ongoing! [...]
[...] One of my recent posts amassed a staggering word count that exceeded 17,000, with comments from Google, .mobi, Opera, WURFL and more. I had to splinter the conversation into a different post which is still ongoing and awaiting a response from me. [...]
[...] This morning I read one of two posts (including all the comments) from Segala’s blog about the perceived difference between the mobile web and the mobile Internet. As my very limited understanding allows me to grasp it, the mobile web is given to the concept of developing web sites so that they are viewable across a variety of platforms, not just desktop web browsers. The mobile Internet is the term given to websites that are developed specifically for mobile platforms, using technologies such as WAP. [...]
Hi
i am not sure this is the right forum to ask, anyway let me shoot out my question
what is difference between WAP and Mobile WEB2.0
My understanding is as follows
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
Balajik that’s pretty much it. Although Web isn’t restricted by the XHTML definition, it’s even more open than that.
thanks paul for the quick reply
1)so does web supports WML as well. ?
and one more qtn
2) what are all other technology/protocol that compete with WEB 2.0 other than wap
Balaji – it is possible to get a browser that supports both WAP and Web rendering but for the purpose of this conversation, that only confuses the definitions.
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.