you said “Scrolling around a desktop version of a site to try and find what you want is a major pain.”

I agree, and that’s why you adjust the width of the page through media queries – resize my media queries test page and see how that works on Opera and Safari browsers.

you say “Hunting around in the site structure of a desktop-oriented site for things you want is a major pain.”

I agree for many, many sites. But that’s bad usability of those desktop sites, not an inherent quality of all desktop sites. A properly usable desktop site that is geared to the visitor, not to the organisation’s vanity, is good for mobile.

As I say in the article, “Those tasks are what most visitors to those sites want to, regardless of where they are or what device they use. It’s true that mobile users are task-focussed. But so is everybody else!”

You say “It will always take longer for…a full on device browser…to download and process a desktop site”

True. Mobile users know that, but still want the full web. A lot of the bloat is because desktop sites are so badly designed.

You say “Opera Mini, and other transcoding proxies are not the future and never can be, especially if they break HTTPS”.

What has breaking HTTPS got to do with the vision of “One Web”? Opera Mobile and Safari Mobile are not transcoding proxies, yet are full web browsers that support the One Web vision. I think you’re confusing the issue by bringing HTTPS into it.

1.) Scrolling around a desktop version of a site to try and find what you want is a major pain. You can’t engineer this away no matter how slick, clever and smooth your scrolling or tabbed jumps.

2.) Hunting around in the site structure of a desktop-oriented site for things you want is a major pain. One of the key points about mobile versions is the site structure is heavily streamlined.

3.) It will always take longer for Opera (or a full on device browser, e.g. S60 browser on Nokias) to download and process a desktop site than it will for a light, streamlined mobile version of the site.

I don’t care if the originating site, or Opera proxies (which is what Mini is), or the evil transcoders , or the full on-device browser, provide a lightweight site with streamlined navigation whose pages get on to my device as fast as a tuned mobile page, but something somewhere in the chain needs to be providing this.

Yes, mobile users should not have a mobile site imposed forcibly on them, but neither should they have a desktop site imposed forcibly on them, via Mini or a transcoder. Users should choose (links to either version at the top of each page are not difficult to implement).

Opera Mini, and other transcoding proxies are not the future and never can be, especially if they break HTTPS as they are currently lobbying hard at W3C to do (VERY bad). User choice is the future.

“For me, ‘Full web’ is the data – regardless of how it is presented, and the mobile web has to allow access to the entire raft of the internet”

take an information-dense page like, say, http://www.last.fm/user/patrick_h_lauke – there’s a lot happening, but on a large screen i can have most things in my peripheral vision and have a quick scan over the whole thing. on a small device i can certainly load the page and zoom in, scroll horizontally and vertically, and get to the stuff, but it’s a pain. or i could get the whole thing linearised, but then end up with an unmanageably-long vertical scroll (lacking anything even as basic as TAB to link or skip to next/prev heading on a mobile device – big hint: WANT! i just noticed that iphone has those buttons if you fill out a form field, allowing you to jump to the next/prev form field…great, as it means you don’t have to keep jumping into/out of on-screen keyboard). here, a tabbed interface might work a lot better (not because i’m “on the go”, not because it needs to be “more task focussed”, just because on a smaller device even linearising won’t help me wade through all the info – yes, you could argue that if it’s so complex, even on desktop/big-screen it’s a pain, but i can quickly skim things there which i can’t on a small screen). now, of course i could implement some fancy mobile stylesheet that does the tabbed interface for mobile but non-tabbed for large screens…but then again i’m potentially sending lots and lots of data over the wire, slowing down the connection (yes, yes, unless it’s piped through opera’s optimisers, but even so…). in some scenarios, it may not even be feasible to just magic up a mobile stylesheet to do this, and a separate tabbed ui may require separate construction on the server side.

so, as long as users have a choice to switch between tabbed/non-tabbed interface (and that choice is remembered via cookie), and on first visit the server makes a guess that perhaps iphone etc users may wish to see the tabbed ui, does this contravene the ideology? or are we not saying that this is the multi-modality we should be aiming for…as long as all content/data/functions/services are available in all modes, does it make a difference?

sorry, long and ranty…but i do think the answer is somewhere in between, rather than being black and white…

Great article and lots to think about and debate. From my perspective, being a Government employee, the communication channels must be geared to the lowest common denominator and analysis of the browser and operating system(s). At present the majority of our clients use a mixture of older browsers (ie 4+ and mozilla 4+) also the number sympian os and psp interaction is growing and not diminishing. So like all things it comes down to client preference, the ability to meet their needs and the resources available to deliver.