Reminds me of when I was in college (in the US, for those keeping track), and someone asked the guy who was from Hawaii, “What currency do you use over there?” He said, “Seashells.” With an implied “Duh.”

I’ve never thought you waffled, quite the opposite.

Well to further confuse the issue: I agree with you. WAP is here for now. WAP is totally fine. In fact I think it’s already evolved about as far as is meaningful as a mechanism for delivering content to limited devices like phones.

My argument if anything is this is never really going to be “the future of the web.” A device small enough to be a phone just can’t have the input methods or screen real estate to make it anything like a desktop computer’s experience. I do think people will access the web on the go, but, through devices that are essentially low-end PCs rather than high-end phones.

In my primitive home continent of North America, WAP is still barely catching on, for a variety of reasons. Some people view this as an ironic effect of the fact that land-line phone networks caught on more quickly here than in Europe, and later, Europe merely went straight to more advanced stuff like mobile phones.

My view is that in North America, mobile browsing is going to leap straight to access from more capable devices like big, bad PDAs and things like the Nokia Communicator or iPhone.

But… that’s a ways away. WAP is still here and quite a legitimate source of focus and discussion.

Sam Falaki
http://www.vudumedia.mobi

This is a useful debate - after first being a little shocked at the amount of negative reaction, I now see it is just a subject that is having a long-overdue debate. Web accessibility will change things on a wider scale than just catering for disabilities (a commendable effort by itself), it will improve the overall quality of web applications. With the drive to get sites mediuh-ed up the last few years, quality has taken a back seat. Admittedly this has been partly down to the pressures to get stuff out there, and business drivers. But that is short term thinking, better to think long-term, rather than following the same methodology councils use in road planning - wait til the roads clog up, then make the roads bigger, then wait til the roads clog up … etc.etc.

The MWI best practices are common sense, and many of basic principles can be found in the oldest software development books. We are dealing with logic in technology, and it is logical to have baseline standards. I havent used any of things mentioned (screen readers, braille readers), but I am guessing they are made, assuming certain standards. But reliance on the competence of accessibility hardware/software, or browser components/plugins, that is processing and displaying your data is never advisable!

Great debate - I have learnt much, just from this discussion thread.

Its disheartening to read that some people can not seem to grasp the concept of ‘one web’. The MWI is about making web pages as accessible as possible on mobile devices. It is not concerned with WAP (though it can be argued that WAP is part of the web). If mobile content developers want to continue making WAP sites then by all means please do. We all know that the MWI inititive is not going to provide THE solution to making the web work on all devices. If they want to try apply the MWI GUIDELINES (yes, thats right, for about the thousandth time, GUIDELINES) then even better

Perhaps it is due to this WAP vs WEB confusion that some people’s reactions to accessibility have been so out of line. Or, rather, i hope thats the case as some of the opinions have been nothing but ignorant and arrogant. I can fully appreciate how the WCAG impose too many hurdles on WAP developers but that’s no reason to dismiss them. Aiding the disabled should be everyones concern, (with respect to the web) not just the web developers, not just the software developers and not just the hardware developers. Palming off your responsiblilties as a decent citizen to someone else is nothing but a cop out. If we all did our bit the web would open up and enrich the lives of so many millions more.

My final thoughts go out to Mr kenneth gf brown who has gone worryingly quiet. Lets hope he’s back on his meds (or off them as the case may be) and did not suffer a rage induced heart attack.

I learned today that Segala’s Firefox extension will be backed by the W3C Semantic Web Education and Outreach (SWEO) special interest group. More soon.
I’m now heading to the European launch of the Family Online Safety Institute in the Hou…

I’ve read a lot of stuff, and dug into the MWI too, however it is quite likely I have missed some things, it’s quite a lot of info (and I do agree with a lot the thought processes that show in its wording, don’t get me wrong). Am I a ‘passani disciple’? For brevity I’ll just say ‘yes’ although I do think my focal point is different from Luca’s.

About BP, well I don’t think we structurally disagree here - one of my points was the misnomer: BP is actually not a BP, it is the ‘EWO’ - it is a system with which you can quickly whip up a site that just works. Fair enough, but I don’t think that is the stated purpose of the document(s) in question, since professionals would take one look at the results, blush and go the adaptation route. It’s not Best Practice, it is a placeholder until you have time to make a -proper- mobile site. yes, BP/MWI do say ‘use adaptation if possible’ here and there, but a BP document, in my opinion, should not direct away from itself.

Also you’re right on the braille thing, in so far as that I’ve never actually worked with one. What I did work with (involuntarily, hah) was the Microsoft Windows screen reader, that started dictating my entire screen out of the blue. I must’ve hit control-alt-shift-F6! ack! What struck me was that it started reading window titles, started giving me context descriptions etc, long before it actually started reading out the main text of the window in focus. Limited experience to be sure, but given that little anecdote I still think my intentions here were not totally unfounded

My wording in my previous post was wrong though - where I said ‘no formatting at all’ I was thinking of things like tables, css etc, while I should’ve put it differently. Obviously, a braille reader needs some cues to know where to ’skip to’ if the user tells the device he isn’t interested in the story currently being read. Leaving in things like and would of course make a lot of sense.

MobileOK last call in one week.. wow, I better hurry over there (Im sure the people there will be giddy with anticipation of my arrival )

(On the disability aside: You seem not to know how actual braille devices work in practice. They take Web Content, with images and structure and all. Unformatted text is much harder to deal with for a braille system).

The idea of MWI as a whole is to help make the web work everywhere. WURFL/WALL and their ilk are essentially the process being worked on with the Device Description group. As a comany that uses them (in Opera mini) I can assure you that while they are great, and the best open source stuff there is, they are not sufficient for all adaptation. (This is also why companies like Volantis, Drutt, and MobileAware make money…). This is the approach I expect from a content developer with the resources of CNN, the BBC, and similar sites that I actually use.

The idea behind the Best Practices is that for people like me, who make simple straightforward sites (a large proportion of the web) and even potentially for people like Google (who also make a pretty straightforward site) it is possible to make something that works reasonably well anywhere.

Naturally, the technology changes. The point of the baseline is that it provides something for developers who don’t meet it to aim for (Luca’s example of horribly broken browsers), and provides a target that many people will build content for (itself providing a push to developers who are behind).

The Best Practices explicitly says to take advantage of more powerful systems as appropriate. (Which means don’t add flash just to send some to any system that handles it, but also don’t be afraid to make SVG available to the many phones that can deal with it, just don’t assume that they all can).

Many of the things there are obvious, but many or most people still don’t do them, so it seems they are worth repeating. Others may not seem obvious, but in general have had a lot of thought and discussion behind them, and I think they are basically good ideas. (I can’t vouch for all the wording, but I think Jo Rabin did a good job of taking the various views and understandings and writing them into something that people will understand in roughly the same way - if they get around to reading it…)

MobileOK Basic, the very simple stuff that can be machine tested, is a start at something that people should be able to implement. It assumes that you may do masses of adaptation for anything but a device that is unknown and presumed to meet a base set of capabilities. And describes what you should give out *in that case*. If you do no further adaptation, your content will work on other places, but not look very exciting. (That’s mostly fine by me. Usually the content I write is about as exciting as this comment. I doubt CNN wil restrict themselves to that…).

And as it is in last call still, you could make comments on it and ths influence the spec… one of the benefits of W3C’s consensus-building approach

On the other hand, you better hurry. Comments are due by 6 March. (See http://www.w3.org/TR/mobileOK-basic10-tests/ for details)

1/ My beef with the original post was the idea that disabled people are ‘more specialer’ than other people who might have trouble using a mobile site. (hence my Voltaire thing).
2/ I never started about MWI, Paul did, citing them as stakeholders and people who ‘backed him’ about the disabled stance. I replied by saying these were needlessly limiting demands. I stand by that (see above). I wasnt (at that time anyway) discussing MWI stuff like ‘usage of multi-column tables’ or baseline standards.
3/ Then Paul discussed building sites with simple tools, and being happy with that design.
4/ I countered that one with my question about why MWI tries to put very strong limits on acceptable constructs. I indeed do find even the MWI’s baseline too constricting. 4 years ago, I would’ve agreed with it. Not so much now. Point me at someone who still uses a WAP 1.0 device and I’ll point you at someone who would never seriously use mobile internet anyway. But this deviated a bit from the original discussion, as Paul mentioned.
5/ I also remarked that while MWI/W3C does not demand anything, and seem to have their heart in the right place, I noted that they do have considerable pull in the mobile world, and for that reason I would prefer to influence them by trying to bring up hopefully valid points. Their standards will influence my work, wether I like it, or not. If I can actually influence them by nudging them in my own direction, then all the better.

Plus I like a good debate, now and then.

Avast!

Paul Littlebury> I’m not quite sure if you thought of me when you made your remark about tech details that make you suspicious, however as knee-jerk reactions go… seriously though, I can only speak from my own experience with developing mobile platforms that the best way to handle things like ‘baseline standards’ has to be to let the techies make a certain (hopefully human-readable) list of possible technologies, and then let the designers/ergonomics people see what they would need, perhaps suggest things they really would like, and so on. Obviously this process shouldn’t be too ‘ping-pong’ - in the best situation both sides know a bit about the other’s domains and just sit together.

The whole thing I am trying to underscore is that we can’t go to a maker of a braille device, and ask him how he would like to see a webpage, and take that as a standard. Of course we should listen to him to get the point of view. The problem is that a document with no formatting whatsoever would be perfect for braillereaders, but quite ugly for everybody else. Instead, we should be focussing an creating filter-able content, and proper filters. The other option (creating LCD content) will leave many users wondering why they bought this k-rad 320×240 touchscreen phone that only displays some text and a 1cm x 1cm image.

Sean> About the tables: certainly they should not be overused, but Id love to see you display a price list with prices to the right of the description in a human-readable way. More than 3 columns seems unlikely to work on the LCD’s, so I think that should be reccommended as ‘BP’.

Chaals> Of course the idea that (say) CNN.com should basically have a ‘mobile’ team that creates the mobile site, writes news stories completely independently of the ‘big’ site is a bad one. (maybe this is actually true currently, sometimes the world doesn’t work like you think it should). If this is what the MWI wants to fix with the ‘one web’ idea, then sure, I’m behind you.

But as I mentioned above, I think the actual debate isn’t about ‘one web’ vs. ‘two webs’ in the above sense of the word. What the debate IS about, is where to strike the content adaptation balance. Should content be simpler than HTML 1.0, and work on every device, and look like on every device, or should the content only work on that prototype apple iphone 2.0 and break on every other phone, or.. somewhere inbetween.

Now somewhere the whole disabled people discussion snuck in here as well, but frankly I find it mostly irrelevant. As I mentioned before, producing mobile-friendly content almost per definition also produces ‘disabled-friendly’ content. Braille devices are so rare, that any creator of such devices will instantly realise that he probably can’t dictate standards. Instead he will have to try to follow them. If they do, then a properly built mobile-friendly environment will hand it the data it needs to support the blind user.

I stand by my invocation of Voltaire, The fact that certain governments choose to follow some agenda is an inconvenience as best, and politically correct stupidity at worst, it does not detract from the validity of my point, it just means that being right doesn’t always imply a get out o jail free card.

But in my mind, the realy interesting discussion is about content design, content classification and content adaptation. Just agree on some way to assign values to how important certain screen elements are, and a renderer can make appropriate choices to filter this content down to whatever the specific output hardware can handle. Of course, advertising will open a whole new can of words here, but let’s leave that aside.

One thing I do disagree with is that following some baseline is good enough to make your site ‘perfect’. No. It will make a site that probably works, but that no designer would be proud of. It is the easy way out. This is not Best Practice, this is Easy Way Out. It has its merits, don’t get me wrong, but Best Practice is a misnomer. Instead, I would expect efforts to be underway to try to aggregate databases for devices to find out what a specific device can and can’t do, and pair that with some ‘web templating system ‘ that allows a user to easily build a website that indeed works OPTIMALLY on all devices without having to personally know each and every device.

And guess what. Check out WURFL and WALL - they seem to be at least a step in the right direction.

We could perhaps use BP guidelines for creating a system that sends the right (amount of data) for a device of a certain scale classification. If a device can legigibly display an X amount of text in a page design of complexity Y, hand him Z amount of ‘fluff’ to pretty up the page and show him links he might want to click he he feels bored. If the device is a braille reader, hand him the headlines.