Is mobile web development compatible with the One Web?
Here’s the write-up of a talk I gave yesterday at the Betavine second birthday party (Betavine is "an open community for mobile application developers"). It stimulated some great discussion there (“Thanks to Bruce from Opera for putting forward the case for one web and stimulating a lot of debate!”); I hope it can continue here.
The talk was without slides, so here are reconstructed notes from the keywords I jotted down on postcards.
Is the One Web getting .mobi dicked?
Confession: I didn’t own a phone with a browser until started working at Opera. I had broadband in the office, and at home (where there are two adults, a ten year old and a seven year old) there are four computers. So why would I need the Web on a phone too?
My recent university lecture tour of Indonesia opened my eyes: whole university faculties using a line a quarter of the speed of my domestic line. Infra structural problems that can’t cope with the massive demand for internet mean that for many, mobile phones are the only practical way to access the Web.
As you might know from Opera’s State of the mobile Web reports, the biggest growth for mobile web is in the developing economies. It’s interesting to look at what people are looking at. Because the world’s most-used phone browser, Opera Mini is a proxy system, we have aggregated data that tells us what any particular country surfs (note to conspiracy theorists: it can’t look at individuals even if we wanted to, which we don’t). What’s perhaps surprising is that people all over the world look at the same stuff from their mobiles. From Jakarta to Johannesburg, from Berlin to Bombay to Beijing, from Brazil to Blighty, people surf trusted, uncensored information (BBC, Wikipedia), search engines, social networking. And porn.
Furthermore, we know that they want the “full web: from our April 08 mobile report: "Full Web surfing comprises more than 77% of all traffic. Content on WAP and .mobi sites accounted for 23% of mobile Web traffic. This share continues to decline.”
An anecdote illustrates the demand for the "full web". Orkut is the most popular social network in India (and Brazil. Who knows why such different countries should favour that over, say, hi 5 or facebook? Therein lies a PhD thesis). Anyway, Google introduced some device-sniffing code and began serving Opera Mini users a cut-down mobile version rather than the full version that they’d been served before. Cue outrage from mobile Orkut users who wanted the full website and a swift reversal by Orkut.
When I first started work, I had an ATM card that could only be used in my bank’s machines. Then along came the Link network, and I could use it any of four banks’ machines. Why shouldn’t you be able to use a Halifax card in a Lloyd’s machine? Now I can use my card in Thailand, Indonesia or anywhere else.
And the Web is like those ATM machines. Why should a site only be available for one type of machine? I’m very fond of the One Web. Philosophically: a web is interconnected. No-one is left out. Why should things look different across browsers, operating systems, devices? This is why we have standards: you write one web site that works anywhere.
But we’re seeing more and more mobile-only sites. More and more sites are "optimised for iPhone" (how is that any different from the now hilariously archaic late-90s message “best viewed in IE4 at resolution…). In fact, why are there "mobile" web sites at all?
So why walled garden sites?
Perhaps one reason is cultural? Mr Boss walks in one day and demands "a mobile site". All your competitors have a domain like mobile.acme.com, so that’s got to be the way to do it, right? Simply coax your CMS to squirt out the information that you think your mobile customers want, and job done.
It’s also hard to make web pages that work across devices and hard to find information. The web standards movement built up a huge bank of best practice on how to build cross-browser sites (and not sweat the minor rendering differences) but there isn’t that corpus of best practice yet for cross-device development.
Deja vu
But we’ve been here before. It reminds me of web accessibility, back when websites were steam powered back in 2002. Tesco launched a website that was highly optimised for users of assistive technology, and made a fortune from it. Blind people obviously have great difficulty going round a supermarket, locating products and then lugging it all home. From the comfort of their homes, they could order their goods without advertising or other distractions and have it delivered.
But some people with disabilities resented the fact that there was a special "disabled-only" walled garden website. They felt "separate but equal" was a kind of discrimination. Some said, why shouldn’t we get to see the ads too?
Since that time, web developers have built up a body of knowledge, user agents (browsers and assistive technologies) got better and now people who care about accessibility no longer build special accessible sites; we build just one website that can be used across browsers and assistive technologies.
A final note about the accessible Tesco site. We know that many people without disabilities choose to use that site because it’s fast, highly usable and lightweight. Hold on to that thought.
Writing one website for desktop and mobile
There are two complementary approaches:
- let the user agent do the work
- let the developer do the work
Let the browser do the work
Mobile browsers help to get over usability problems because they know they’re mobile devices so they optimise the experience with no input from the developer:
- By zooming into areas of a site, you can overcome the fact that most sites are "wider" than a mobile screen.
- Touch screen makes horizontal scrolling much more palatable.
- Opera browsers can reformat a page into a single column via a setting
- Opera users can choose not to download images (this is better than using CSS to hide them with
display:none;as that method downloads heavy images and does nothing with them; this method stops the browser even fetching the images, saving lots of bandwidth).
Development techniques
- browser sniffing leads to trouble; it’s fragile and isn’t future-proof
- using media types to send handheld stylesheets didn’t work because some user agents didn’t do what they were supposed to do; see Return of the Mobile Style Sheet (but beware the tables which mention the non-existent IE 7 and 8 for mobile).
- media queries: sending CSS depending on different attributes of the device, so you can say
@media screen and (min-width: 400px) and (max-width: 700px) { ... }to send certain CSS to devices depending on the screen size (in this case, those with screens between 400 and 700 pixels wide). This works in Opera. Safari, and is apparently going to be in Firefox 3.1. It won’t be in IE 8 (but no IE 8 for mobile anyway, as the miserably anti-standard IE 6 has been resurrected as Microsoft’s flagship mobile browser.) - A new and very interesting approach without browser sniffing or server-side stuff is documented by Dean Hamack at Bushido Designs: Mobile Device Detection and Style Sheets without User Agent Detection or Server-Side Scripting
Is there such a thing as mobile-only content?
I’ve heard arguments that some content isn’t appropriate for mobiles. I say, let the users be the judge of that (and remember the Orkut anecdote).
Some say that some content is only appropriate to mobiles for example, the tel: URI scheme that lets you set up a link like <a href="tel:07888123123">Call me on 07888 123123</a> and, when clicked, it causes the phone to dial the number. But I want that on my desktop, too—except there, I want it to fire up Skype and call the number.
A biggie is location-aware content. At Opera we’re very interested in that; our head of the browser core, Lars-Erik Bolstad, co-chairs the W3C‘s Geolocation group. But isn’t Geolocation equally applicable on the Nintendo DSi, netbooks and laptops, now that laptop sales outstrip desktops?
The main use case I hear for mobile-only sites are things like train and bus timetables. The thinking is: If you’re out and about and you hit a rail network site from your mobile, you must be either buying a ticket or checking a timetable, so make those the most prominent tasks of the site.
I agree. But that’s not because those are only appropriate for mobile users. 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!
Because desktops are big, there’s the assumption that punters want to see a message from your chairman, how well you’ve done on your E&D strategy or any of that kind of organisational vanity publishing. But people almost certainly don’t care about your immersive web experience just because they’re at home with a desktop. Wake up Mr Web Manager! People go to train websites to check timetables or buy tickets, regardless of whether they’re on the move or holding a small-screen device. There’s no excuse for my local station timetables to be a hulking PDF regardless of my device.
Like the fact that non-disabled visitors use the Tesco accessibility site because it’s faster and task-focussed, I’ve heard anecdotes (from Ribot and others) of people using mobile walled garden sites on their desktops, precisely because the transactions are more quickly accomplished using those. That supports my argument that most mobile content isn’t more suited to mobiles, it’s just better content than its flabby narcissistic non-mobile equivalent.
We’re approaching the tipping point
The market still fragmented, with lots of different devices, but convergence is happening. The most-used web browser in the world, Opera Mini, can optimise "full web" sites for the mobile phone. In America, 50% of the market is iPhone and Android operating systems, which can run browsers capable of rendering sites for the one web. Connection speeds are ever-faster, user agents are getting smarter.
Are the walled-garden mobile sites the equivalent of 2002’s "special accessible" sites that need to be developed alongside the full website, thereby costing more and yet are unnecessary? I think we may be at the tipping point when we can start to develop websites using standards that ensure the site can be read by any device, running any decent browser, for people with assistive technology or without.
What do you think?
Buy "Calling For The Moon", my debut album of songs I wrote while living in Thailand, India, Turkey. (Only £2, on Bandcamp.)
22 Responses to “ Is mobile web development compatible with the One Web? ”
Firstly, yes, we are being .mobi-dicked. Effectively asking user to experiment with .mobi domains could really hack them off.
Which is why I have to argue for dedicated mobile experiences.
Like experimenting with URLs on a mobile device, some things should be left for the desktop – somewhere where there’s time, a chair, a task to complete, and a proper QWERTY keyboard.
On the other hand, accessing the web one a mobile is often part of a larger process – one that is based on the fact that the user is … well, mobile. People are often in a rush when they access the web on their mobile. They need answers – fast. They don’t want to have to zoom in, or scroll, or decipher a website that has been designed for 1024 x 768.
What they do expect, is not to be limited – and this is where I need to clarify your definition of ‘Full Web’…
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. But surely, as there are increasing numbers of different devices, tailored for different purposes and contexts, presenting this data should be presented appropriately.
And it’s hard to design simple, appropriate experiences for extremely time-poor people who are being hassled by their hungary mates to find the name of a restaurant at 8pm on a Saturday night, but if we don’t provide appropriate interfaces no one will want to use the web on their mobiles, and we place our client’s growth at risk.
The success of Facebook mobile, plus the rise of app stores could be a testament to how people want to experience the web when they are in a mobile context.
The tipping point is still 2+ years away and the reason is there are no simple-to-use tools that would make one-web reality. Since we are talking mass usage here, the tools must be simple enough for mass adoption on the user and on the admin side.
At the same time the “.mobi dicked” momentum is building and I find this understandable. Bussines and marketing is making a push by reasoning “we must go mobile now, as this is deja vu of late 90ies”. As bussines owner of web site wants to go mobile and and the same time not alter existing web site (Do not fix what is not broken!) he will go for dedicated handheld form-factor site. Going this way are two benfits:
1. keeping existing web site untouched (It is not broken!)
2. protecting new (experimental) investment by entering the field slowly and figuring out what QoE works and what does not work. Retreat is simple as web site is untouched.
Bruce: I admire your faith in the Ever Growing March Of Technology. Unfortunately, I think that (a) fast web connections may make it to Japan and the US long before they make it elsewhere, (b) content on the internet tends to expand to fill the bandwidth allocated for it (we all got broadband rather than dialup and the universe responded by creating streaming video, etc; when we all get hyper-fast terabit connections, they’ll be filled up by downloading real objects or something). I can’t see problem (b) being solved ever, and I can’t see problem (a) being solved any time soon, so handwaving it away with Moore’s Law (not that that’s about bandwidth, but I know what you mean) is not helping people for the next five years…
Hi Bruce,
couldn’t agree with you more. We’re being completely .mobi dicked!
I don’t necessarily think that a full "one web" model is correct as the mobile and the PC are two completely different contexts.
But I do think that there should generally be "one web address" and the relevant parts of your site should be available to both contexts (if not more than just 2).
A good example of this is the live mobile poll we ran at Mobile Monday Sydney last night.
http://smartmobtoolkit.wordpress.com/2009/02/02/first-live-poll-for-2009-at-mobile-monday-sydney/
This didn’t just deliver the same thing but in different ways to both mobile’s and the PC that was driving the projector.
Instead it enabled all the mobiles and the PC driving the projector to work separately…but as a unified whole…to create something bigger than their individual parts. As the audience interacted with their mobiles the projected graphs updated in realtime to create a real sense of interaction and community.
On this topic, we’ve also released some GPL code that turns traditional device detection on it’s head.We call it "Not-Device Detection".
Checkout the overview here:
http://smartmobtoolkit.wordpress.com/2008/10/16/not-device-detection/
Ideally we could just rely on defining the correct stylesheets and the browser would handle the rest…but the real world just isn’t that simple.
Great article, I very much agree that the #1 concern should be giving the user what they want, and that should be choice (do i want to use the full site, do i only need to access a sub section of it).
I also agree with Stuart’s comments though to a degree and that is that we need to be pragmatic with the way we build websites. There’s still a long to go until a mobile browser can completely replicate the experience of a desktop, and we need to be aware of their limitations such as usability (eg lack of qwerty or touch screen in most mobiles) or technology (eg safari of iphones dont cache images in the same way as a desktop, mobile dont have the same power as desktops for JS animations etc).
We also need to cater for these limitations *now* without delivering a reduced experience to a desktop user.
Browser sniffing is therefore still a necessary evil for many websites, but even with that, there is no reason why mobile or desktop users cannot be presented with an option to change their environment more appropriate to their needs (sometime i may visit facebook on my phone for a quick update check, sometimes i may want to go and post photos etc and see all the info from my widgets).
Choice is key.
Bruce, one web will NEVER happen, until:
a.) Websites somehow deliver a completely restructured, lightweight, goal/task-oriented version of the desktop PC site, to a mobile. I think you recognise this with your timetables example. Now, PC sites could become mobile websites, stripped to the bone no matter what. But that ain’t gonna happen. We can have one web in terms of back end stuff, sure, but not with regards to the UI. Mobile will always want and need lightweight pages (due to bandwidth and processing issues) that are structured for minimum keypresses to goal, and for small screens. iPhone stats have proven that despite the best UI and browser for full web on mobile, users gravitate to specially formatted iPhone versions, for speed, screen layout, and goal-oriented site structure.
2.) Next problem: Opera Mini breaks HTTPS on mobile. Big, big, insurmountable problem, until Opera stops it. The only acceptable solution to breaking HTTPS on mobile is not to break it. I know they’re trying to arm twist W3C (which it appears is not difficult these days) into accepting this as a standard, but they (and others) will not succeed. HTTPS cannot be broken. Ever. It is wrong that currently Opera do not make this clear enough when accessing HTTPS enabled sites in Opera Mini (e.g. a clear and stark pop up) and also wrong that orgs like Barclays Bank in the UK recommend their users to use Opera Mini for mobile banking (insane!)
See about halfway down here: http://blog.masabi.com/2009/01/how-do-transcoders-affect-https.html
3.) Opera’s control over the transcoding is a weak link in the chain. There’s something fundamentally uncomfortable about putting total reliance for access to the net on a connection piped through one company’s servers. It’s a single point of failure. If Opera open sourced the Mini transcoder and made it 1-click installable on any web site space, that would solve this problem.
4.) Your 77% traffic figure is invalid for your argument, as Luca Passani points out here:
http://tech.groups.yahoo.com/group/wmlprogramming/message/29895
His post also addresses other problems with your one web arguments.
Kind regards,
Alex Kerr
Phonething.com
Hi Alex,
you claim that having Opera Mini support https transactions is a problem. I think that overstates the case. It is perfectly true that there is a potential point of failure (although let’s face it, given that most Opera Mini traffic is to social networks, most minimally intelligent hackers will decide that a bank is a more profitable target, unless their goal is to make you their facebook friend rather than crack your bank account). However, this is essentially no different to the fact that any browser is a potential point of failure. If Barclays recommends Opera Mini, then it is quite possibly because, being a bank, they have done a security analysis of different ways to carry out transactions and decided that on the whole it is one of the alternatives that actually protects their customers and themselves. (They don’t need to recommend it, and doing so means they are taking an active part in pushing certain user choices. There have been services which actively blocked the use of various browsers for security reasons, as well as for far more trivial reasons).
Would it be different if Barclays paid some company (many provide this service) to adapt the content at their end, so it was pre-optimised for whatever browser/device you used to connect? As far as I can see, either approach is a feasible way to deliver services to lots of users, and Barclays makes a decision based on their business model, their obligations with respect to security and the regulatory framework in which the bank operates, and their internal processes.
In any event, HTTPS is not a secure person-to-person protocol, it simply defines a way for two end-points which are not known to each other to communicate information so that no third party can intercept it without the consent of either end-point. That’s it. If your service does not have an “Extended Validation” certificate (and being relatively new, most don’t) then you don’t even have much idea of who you are really connecting to as a user – just someone who paid a certificate authority for a key, and gave a name.
Likewise with your concern about allowing access to go through a particular company. You are not forced to use Opera Mini (in principle – in practice there are sometimes few acceptable alternatives, just as I am effectively forced to have *a* bank acocunt in order to get paid) any more than you are forced to make all your searches go through MSN, or all your email go through Google. It is a choice you make as a consumer. Althugh Phonething.com may “prefer open source solutions”, there is no reason I can see why anyone would suggest that it *must* make all its work open source – it is up to the company to decide on its strategy and business practices. Why should it be any different for Opera?
Note that you can at least see anywhere what the transcoding itself will do through the demonstration applet – http://operamini.com/demo or even install that on your desktop and configure it the way you like (see my blog post http://my.opera.com/chaals/blog/2009/01/22/opera-mini-on-mac-os and the links it provides to the various people whose intstructions I basically recycled, or jsmanrique’s comment on how to improve it further). I believe this is equivalent to say Access making it possible to download and install NetFront so you can see how it renders content, or being able to see what Internet Explorer does, or how the browser on my Motorola L900 does it.
And yeah, I think Bruce’s use of the 77% figure may be somewhat casual (although he does provide the reference, he extrapolates from use patterns on Mini without demonstrating that these hold for the entirety of mobile web usage), but Luca’s specific argument against it is actually not a logically valid refutation, relying on assertion with no evidence to back it up. Dealing with statistics is a tricky thing…
cheers
Charles McCathieNevile
Chief Standards Officer
Opera Software
(Yes, I am a colleague of Bruce’s. And I work for the company that makes Opera Mini. A full list of friends, associates, people I had beer with and so on is unfortunately beyond my capabilities so to some extent you might have to trust that I call it like I see it rather than parroting someone else. I doubt my employer disagrees with what I said here, but it is my opinion.)
[I had already posted this comment. Got a message that the Admin had to look at it, but my comment never appeared. Trying again…]
– I am not familiar with Orkut, let alone with their mobile web version. I have no doubt believing that it was so bad that users actually preferred a transcoded version. But come on, that’s just one application. Everybody here knows that a typical mobile application
(even when relatively poorly coded) will always win hands-down when compared to any transcoded web version in terms of usability. There is no discussing it. You may come up with a scenario where the web site has
a function which has been left out in mobile, but trying to demonstrate anything else is like trying to demonstrate that a SUV is preferable when looking for a parking spot in the center of Rome.
– “77% of the traffic is reformatted full-web”: this only proves that users know that full-web is better when reformatted through OperaMini.
Users are using their regular browsers for sites which they know to work OK on mobile. Also, a full-web page is a lot of reformatting (i.e. higher number of reformatted pages per site) because of people clicking
around to find what they need. Mobile-optimised sites will typically make people find what they are looking for when they are mobile sooner (i.e. less clicks,i.e. less transcoding). In short, taking this 77% as
an indication that mobile surfing is less popular is wrong.
– The article does not mention WURFL: I think this is a deadly sin for someone who writes about the different ways to serve mobile content in 2009.
This is particularly true if you consider that Opera uses WURFL to decide which versions of OperaMini to provide to downloaders. This omission seems intentional to me, particularly if you consider the
other non-omitted options in the list (see next point):
– “Mobile Device Detection and Style Sheets without User Agent Detection or Server-Side Scripting”.
This is taken by the author for granted. Unfortunately for him, he refers to a poorly-informed blog by someone who has not understood the AdMob Metrics report (or, more simply, was desperately looking for stats to bend evidence to his point in the face of reality).
To make a long story short, it is not true that 50% of devices around can use CSS without UA detection/Server Side scripting. The AdMob metrics has a graph about device OSes where a deviceOS is a development platform
for developers (i.e. third-party apps can be installed on the device). This means that most feature phones (with simple, non-accessible, proprietary OSes) are not accounted for. Yet, those devices are 85%+ of the whole market! Bloggers, please do you homeworks before you blog.
Of course, let’s not forget that Opera is the producer of OperaMini, i.e. essentially a transcoding proxy. It is only obvious that their message is “people want the full web”, because they are making money on transcoding as much as they can (they partnered with ByteMobile last year). By now, we are not so easily fooled by transcoder vendors, are we?
Luca
About HTTPS. This is *the* way companies have to establish a secure end2end HTTP communication with their customers. It’s the foundation of eCommerce. Everything that breaks and undermines HTTPS is unethical, because it pollutes the environment for all other companies in the ecosystem which are trying to build a business on eCommerce.
The argument that there may be other points of failure in the chain (a browser plugin or a malicious browser) sounds as pathetic as a drug addict justifying their addiction with “so many people are dying in car accidents every year after all….”
— Bruce:
but we don’t need to? We can amend look and feel with CSS media queries, suppress images or reformat the screen with settings on the user agent. But we can do that by clever browsers and clever CSS without serving different sites.
—
Agreed (mostly), but while suppressing images may be a solution to reduce bandwidth, “reformatting the screen” would effectively serve a different website to a mobile user, and wasn’t that what you wanted to avoid? What is the difference (to a user) between user agent switching to redirect to a new “mobile friendly” page and switching to serve a brand new CSS file that restructures the page you’re viewing to make it look mobile friendly? Again, the point here is providing the user with a choice, not what methods we (as developers) use to deal with mobile user agents.
— Bruce:
I’m not sure about iphones caching images, but animations are a good point.
But do we need those on a phone? If we’re talking about the same thing (sexy bling like the webkit transitions and transformations) then using CSS would help; big screen devices would get blingy CSS, small screen devices wouldn’t.
Is that a realisitic or possible scenario?
—
The issue with iphones, is they have an upper limit to the file sizes they cache, and the standard optimisation rules recommended by the likes of Yahoo! etc (sprites, combining files to reduce http requests) dont apply so readily to the iphone (at the moment).
Also, CSS doesnt (or should i say “shouldnt”… thanks IE!) control functionality, just presentation. While you could use it to hide/show different elements, it cant change the JS functionality (or stop the JS from loading). If you also did want to go down that route, it would mean littering your code with duplicate html content to cope with desktop/mobile capabilities (eg. on div block containing copy that will fade out using a class or id target, and one that has the class/id removed so the JS wouldnt trigger etc). Even with the advent of 3G enabled devices and wifi on mobiles, very poor practice in terms of optimisation (not to mention the same content would be downloaded by the desktop machine)… you also run the risk of duplicate content and therein lies trouble with our lord Google!
@Bruce
your Orkut anecdote clashes with reality. People will make up their own mind about it.
As far as transcoding goes, reading these blogs will summarise pretty much everything that has been going on between transcoders and content owners. If something isn’t clear, I can explain:
http://wapreview.com/blog/?cat=19
For the record, OperaMini is also a transcoders. Up until recently, OperaMini was mostly opt-in in nature, so I wasn’t pointing at it as a major offender in the transcoding discussion. A few things have happened recently though:
– Opera has partnered with ByteMobile ( a major offender!) to transcode content with UA spoofing.
– Opera is also trying to leverage W3C’s BPWG to ratify scenarios to break HTTPS.
I found this very disappointing.
Luca
Bruce
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.
as you know, i still sit on the fence on this issue, but i want to pick out something from the second comment from daniel harris
“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…
I’ve blogged my thoughts about this: One Web Works Fine.
Oh, nearly forgot that Mobile-friendly websites and accessibility is a topic that’s just started on Accessify Forum.
That’s fine if you want one web, but you can’t get around these facts, even with the excellent Opera Mini:
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.
[…] colleague Bruce Lawson has gone into this in some depth in his post Is mobile development compatible with one web and, like him, I’m firmly in the “one web” camp. It’s still relatively […]
There’s a case for “mobile” sites that you’re missing out, possibly because you’re rocking the 3G and wifi on your phone and I’m still on GPRS. The average mobile site sends *less data* on the wire than the average non-mobile site, which means that it loads faster. Regardless of how clever your mobile browser is, regardless of how well it optimises display for a 320×240 screen, regardless of how well the site is designed to take advantage of progressive enhancement, etc, etc, the mobile version of GMail, with each page at about 12K, is better than the non-mobile version, with each page at about 80K. The browser can’t do any optimisation until it has the code to optimise.
Now, Opera Mini gets around this problem with server-side optimisation and a tight binary wire protocol, I admit it, but it’s still gonna take longer to ship more data, any way you slice it.
Perhaps in a few years everyone will have 3G or 3.5G or 4G or whatever the fuck acronym soup the mobile people foist on us, or there’ll be pervasive nation-wide wifi, but until then…I like mobile sites, ‘cos they load faster.