Slashdot Mirror
Vodafone Move Invites Web Development Chaos
hoagiecat writes "Web developers want mobile phone users to be able to access their sites, but mobile browsers generally choke on heavyweight HTML put together for traditional Web browsers. A host of services have sprung up that allow two sites — one for mobile users, one for PC users — to coexist at the same URL, with the browser's user agent string distinguishing between the two. Vodafone has come at the problem from the other end, offering a new service that translates traditional Web pages into mobile-friendly ones on the fly — but it strips out the user agent in the process, breaking sites designed around the other strategy. And Web developers are mad. Will similar moves by other carriers disrupt this nascent Web development ecosystem?"
Because I'd love to do without the feature (read: crap) heavy pages and go straight to the content.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
yep. spoof the ua string.
Operation Guillotine is in effect.
As a Vodafone "business" customer for the last 15 months, Vodafone is doing exactly what the article claims:
... It's unclear if Vodafone removed the user agent capability for "diabolical" reasons, such as to maintain firm control over the content that users can access, or if it was a legitimate mistake, Harper said.
Companies that are on Vodafone's "white list," which is a group of Vodafone-approved services, were notified of the change and the operator is passing the user agent correctly for those services, developers say.
The issue at Vodafone is they need a revenue engine that cannot be hampered so they artificially create one. With the recent court rulings over VoIP services like Truphone, Vodafone is seeing disruptive technologies come into play. This is just business doing the right thing for itself but not for the customer.
For what it is worth, within the group of people I work with (about 2000 people), many of us are using Truphone over the wireless broadband we are provided. Suddenly, my 400-600 pound mobile bills are now down to 50/month with loads of unused minutes rolling over. The story is similar with many other people here and across other networks. Are you surprised?
1. Check IP address. It might all be filtered through the same server(s), so it would be a matter of updating your browser-detect scripts.
2. If there's no user-agent, output the simplest page possible. "But then clients with no user-agent get a simple page," you say. So? If they know enough to strip their user-agent, they might appreciate a simpler site anyway, and they should be able to understand the issue, at least.
Anyway, why would developers be annoyed? If a browser breaks your site, and you're following standards, the blame is on the browser, not on the developer. If it's just impossible to workaround this, it's not your concern. This thing doesn't have market share like IE, so I don't see the big deal.
Why is no one using stylesheets?
Awww did mean old Vodafone got an algorithm to reduce all the bloat web developers put on sites because they use Dreamweaver or other code generation tools?
:D.
Time for a addon for firefox with a on/off switch for mobile version of the website
On another subject if this is legal then blocking adds from sites is also no?
> Web developers are going to have to get used to it.
They have already gotten used to it. Checking sites on IE vs. a proper browser.
What I don't understand is how a tool controlled by vodafone which renders a page in a potentially non standard and undisclosed way would be the way to get used to. Maybe I misunderstood you?
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
The problem is that even if you code to W3C standard (which I do) using XHTML and CSS or whatever then you can still have a heavy page that is standards compliant but takes an age to load due to what you cram into it. At the simplest level then you could have a standards compliant site that uses Flash for part of it. With the (admittedly poor) idea of "serve depending on user agent" then you can serve simple content to the phone and have it work but a purely standards compliant site wouldn't help there.
Yes, the standards should fix most of the issue in that it should degrade well to a phone display etc, but it won't solve everything.
I have to disagree. I use Plone as a development framework for both "normal" web sites and WAP sites. The user agents are really useful to determine which mobile device is performing the request. This in turn enables me to, say, scale images to an optimal width server side. It saves a lot of bandwidth and makes full use of a larger screen.
I clean the ua's and apply a Jaro Winkler similarity algorithm. This approach results in a 90% successful match, and in the cases where the match is incorrect it return a sibling phone.
As far as the mobile world is concerned UA's are great.
It also hides the original Accept header, and presents a different list of MIME types. To make the problem even worse, it then refuses to pass across files that the phone would be perfectly capable of accepting. For an in-house site I work on, it broke our ability to deliver compiled WMLScript (application/vnd.wap.wmlscriptc) to phones that are perfectly capable of executing the scripts.
A nice concept that doesn't actually work in the real world today.
Hmm... I wonder how this fits in with Vodafone's charging.
By breaking the functionality that allows operators to display the mobile optimised pages, they are forcing people to download more content. Even if they only charge for the amount transmitted to the mobile after they've processed it, that's still likely to be significantly more data than people would have had with the optimised pages. And if they charge for the size of the original page (and I wouldn't put it past them), they really are ripping people off.
Either way, I would not be happy with this change if I was on a limited data tarrif.
most of those heavy pages don't really have any content anyway, why bother ?
Washington bullets will simply be known as the "Bulle
The problem as I see it is not really sending back different *web* content, but sending back different *executable* content designed for the phone.
Mobile phone sites use UserAgent to determine what wallpaper or ringtones the device that they're sending supports and send something back that is in the right format / the right size.
It's like when I go to "getfirefox.com" the site knows that I'm on a mac and offers me the Mac version first.
-- Sorry, I can't think of anything funny to say here.
The whole idea of the web is that any page should display on any user agent. It's the user agent's job to adapt the content to the display, not the server's.
This just shows you're not a web developer. You might as well say that you should be able to put petrol or diesel into your car and the engine should sort it out. There's very little content that's appropriate for both a 2560x1200 screen and a 120x160 phone display...
Code, Hardware, stuff like that.
Don't I know it. I use a BlackBerry to surf the web most mornings on the train, and I see these all the time. I've learned to avoid some links specifically because I don't want to waste my time trying to navigate a crappy mobile version of a site. For example, I no longer click on any Reuters or USA Today news links on Slashdot or Digg, because rather serve me the article I asked for, these sites entirely ignore the URL I sent it and drop me on their mobile page, from which (I guess) I'm expected to navigate to the thing I originally wanted. Unfortunately the mobile page contains links to news categories and a list of the most popular stories, and it's usually impossible to find the one I wanted. Many news sites use similar services. The big provider seems to be Crisp Wireless, which proudly announces its responsibility for this crapiness at the bottom of each mobile page.
My newest pet peeve is the BBC News site. If I type "news.bbc.co.uk" in my desktop browser I get the BBC News page. But on my BlackBerry the site ignores the URL and "helpfully" redirects me to a page where I can select whether I want their Mobile or Desktop edition. It's nice that I at least get an option, but it adds a page load to the process of simply reading the news. And when I select the Desktop link they send me to the main BBC site, not the News site, so I get to make a third page load when I click on the News link to visit the page I originally requested about a minute ago.
How are these mobile sites supposed to help us again?
Basically, the sites affected have two (or more) versions of their site and choose which one to serve depending on the user agent. So in the case, as this, when the browser or proxy agent does not give a useful user agent, don't try to get the mobile company to help you; they obviously are not interested; fall back to ASKING THE USER HIMSELF: just have a little (or big) check box: "click here for desktop, click here for mobile" page. Then store the preferece in the URL and/or cookies (do mobile browsers support cookies?) Or advertise a mobile page, eg:
http://m.whatever.com/ instead of http://www.whatever.com./
I doubt it will be long before mobiles can take on these "heavy weight" websites, so lets just wait a year, and then everyone will be happy and these workarounds will be meaningless.
"we've got trenchcoats and bad attitudes" - John Constantine, HellBlazer
How does Opera Mini handle user-agent? I understand it also does a server-side transformation of a webpage. Do web developers serve a special version of the page to Opera Mini?
The Nokia N-series phones have used WebKit based browsers long before the iPhone was a glint in Steve's eye.
They even released a proper open source version you can compile and install yourself.
IMHO, everybody who has developed sites for their mobile portal and had contact with Vodafone's PartnerML should know that Vodafone has always been weird on the technical side when it comes to WAP and mobile web.
A monkey is doing the real work for me.
Sounds similar to what Opera does with its Opera Mini browser where when you request a page the browser doesnt request it directly from the net but via a proxy, a server operated by Opera - which gets the page for you, shrinks it and sends it to you. Saves traffic and the page you get is far more pleasing to view on a small screen. I wanted to do something similar with squid on my small server at home - just to have more control about what happens during the adaptation process but havent had the time to read up all the docs on how it could be done.. anyone know of some good recipes that already do something like this?
Actually it does. See Vodafone.
Using openSUSE instead of Windows since 9th of October, 2007 and liking it.
The site content shouldn't need to change - only the presentation.
All that needs to be done is to serve up a different style sheet depending on the user agent, or a default 'safe' stylesheet, or none at all.
Determining which style sheet to use will necessitate peeking at the user-agent so Vodaphones approach could be problematical. Maybe if they had a meta tag to tell their gizmo not to process the site.
That's why I set up my .mobi site alongside my main one, to present a more appropriate (read: smaller, faster, search box at the bottom) view for mobile browsers. I don't have to guess or translate anything and nore does Vodafone: for this URL I generate .mobi-compliant XHTML straight off.
Other than V managing to content block me from one of my own sites in Australia for a while (even though I have content blocking turned off and there's nothing dodgy about the site) their service seems to work quite well. I don't like stuff being redirected via a 'transparent' proxy, but maybe I could use SSL to prevent that if I really cared I guess.
Rgds
Damon
http://m.earth.org.uk/
Not a web developer? IMO it shows he is a web developer and he's one who thinks about XHTML/CSS. For content that can be displayed on both then how about text? Whether it's widescreen or phone display then text should display fine. Have a page serve up content including:
...
<h1>Page title</h1>
<div class="menuFloatedRight">
<h2>Menu</h2>
</div>
<div class="contentWithBackgroundImage">
<h2 class="headerWithBackgroundImage">Some header</h2>
<p class="intro">Some paragraph of introduction</p>
<p>Main article goes here.</p>
<p>And here...</p>
</div>
then along with some CSS the content can be identical for all user agents and each user agent can decide which styles they want to support and hence adapt it. If you're on a mobile then you might want to ignore the background image and the right-floating of the menu, but keep those attributes on the desktop browser, and so the user agent is adapting the content to the constraints of the display.
If there's one thing I've learned from working in the mobile telephone industry for the past year, it's that mobile service providers and indeed, mobile handset manufacturers, have their heads so far up their asses so as to be completely out of touch with the rest of the world.
They understand their customers fairly well, but they show complete contempt for third party software developers and existing Internet and communications infrastructures. They lobomotise almost every new useful feature in the face of the demand for said features, and the pump steroids into the features which really aren't important (5 megapixel camera on my mobile phone, when the f**king thing won't even let me send the high quality snaps over anything but infrared?! Get out!)
Now, what's this I keep hearing about a Linux phone?
Today's weirdness is tomorrow's reason why. -- Hunter S. Thompson
CSS provides Media Descriptors that allow specific stylesheets to be used depending on the presentation media.
'Handheld' is such a descriptor.
Provided the device supports this and use the correct stylesheet there shouldn't be any need to do anything else.
There's very little content that's appropriate for both a 2560x1200 screen and a 120x160 phone display...
;)
Does a 404 count?
Care to give an example of content sized for a 2560x1200 display?
It's never too late to have a happy childhood.
I'm a web developer and I don't whine about chaos when someone's trying to work on my problems.
It's a simple one liner to set the right flag in your code if either the right URL or user agent is detected.
Given the mess we're used to when doing web dev work, panicking about this is laughable.
Straight to the content would be nice, but be careful what you wish for... There's no way advertisers are going to accept the idea that mobile versions of pages have no ads. With the screen area so small what will happen is that ads will appear on separate screens before the content you're trying to view.
Desktop browser ads are mild by comparison. They sit at the top or the side, easily ignored. The worst they ever manage is to waste a bit of bandwidth. I predict people with more powerful phones will soon be spoofing non-phone user agents in an effort to dodge the evil phone versions of ad-supported pages.
Please, just offer a different site. It's annoying as hell when you then can't browse to the version of the site you want to because of someone else's whim.
Otherwise you're just restricting access to a site someone's specifically navigated to. Offering a second site provides all the benefits you mention of image scaling, etc. without this downside. I'm sick of having to change user agent strings just to view websites.
And what if a blind person who uses a screen reader comes by? What if that person uses a Braille reader instead? What if it's someone able to see but a person who needs a big magnification? What if I come by using eLinks? And "making full use of a larger screen" needs to know the User-Agent how? The CEO of my company insists on setting his resolution to 800x600 even though it's on a LCD, I use 1600x1200, some folks with better hardware go higher -- and all have the very same User-Agent string.
Having a proper split between semantic markup and styling has none of these problems.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Most of the time, thanks to a combination of the User Agent Switcher and boredom, I'm usually seen from the other end to be browsing on a Commodore 64, a GE washing machine, or a potato with wires stuck into it.
Slashdot Burying Stories About Slashdot Media Owned
You won't believe what you can get from some sites if your user-agent string doesn't contain something familiar to them
So... this only broke websites where programmers blindly accepted user input and trusted it, right?
Jason Lotito
Well, Flash is to all intents and purposes its own user agent. It can make HTTP requests and it can render HTML. Assuming it renders alike on all platforms, it's a quick-n-dirty (TM) way of getting everything to look "right" cross-platform.
The proper thing to do in this case would be for Vodafone's content-munging proxy to declare its own user-agent ident, so that it's at least obvious at the server end that pages might not be rendered exactly as sent -- and knowing exactly what alterations are being made wouldn't hurt web designers, either.
Je fume. Tu fumes. Nous fûmes!
Why dont people just use media="screen|handheld|print" along with optimised code to a) reduce the amount of code sent in the first place, and b) position it properly based on the client I realise you have to download the same amount of HTML which might not be optimised for slower connections but seriously ... isnt that the entire purpose of the media="" attribute ??
--- Stop the world! I want to get off!
check out elinks or lynx and apparently w3m
http://freshmeat.net/projects/lynx/
http://freshmeat.net/projects/links/
http://freshmeat.net/projects/w3m/
boycott slashdot February 10th - 17th check out: altSlashdot.org
Crazy moderation there. This is the crux of the issue. If people start using standards -- developers AND phone companies, then the problems they're working around will no longer exist.
As someone who's been on the other side of this issue, I can tell you that Vodaphone is not the one creating the chaos. (Also note, some PC proxies will strip out the user agent.)
I've previously received mobile versions of websites on my desktop, merely because I was using a test version of Opera. Opera 9.0 for desktop hadn't been released yet, really neither had the version for Windows Mobile though that had received more notice. Because my user agent indicated I was using Opera 9.0 on Windows their server decided it really meant Windows Mobile and sent me the mobile version of the site.
Sorry, but having different versions of a site based on user agent is wrong because it is too prone to errors. They should use proper CSS media descriptors, or maybe use javascript to check the size of the screen. At least, unless they actually define a standard for user agent that explicitly indicates the platform type and they are sure most browsers follow that standard.
CSS? Mobile Phone? What???
CSS is a complex resource-intensive standard that no browser developer has yet to implement correctly.
A proper CSS implementation in a mobile phone with a 160x120 display and a few megs of memory? Yeah right!
There's also the fact that CSS inherently operates by telling the device what to remove once it has received the full page, as opposed to not sending the device the information in the first place. Not everyone lives in a UMTS or EV-DO coverage area, you know... Even if it formats well for display on my device (an above average 240x320 Windows Mobile 5 PDA phone), a "non-mobile-optimized" site often is 100-200 kilobytes, while a mobile-optimized one is 10-20 kilobytes. (Simpler HTML, no images or only very small ones, etc.) CSS won't help here because it fundamentally means "send everything and let the client sort it out".
Even with CSS, the differences between mobile and desktop versions of a site are more than just formatting. Try going to Google with a mobile device - You'll see that the differences in the site are far more than just formatting.
retrorocket.o not found, launch anyway?
No, you just think they are, because you only care about a few of the potential visitors to your site. That's probably why the rest don't use it, and why the many future web clients in PDAs, Digital TVs etc., blind user's screenreaders etc. will never use it either.
That's what SVG is for.
Seriously? Do you realise how many pontential users you're dimissing with an algorithm like that? Might as well hash the UA string, xor it with a random number generator, and take the value of the first bit for an if statement.
If so, it's only because the mobile manufacturers are doing the Wrong Thing.
Sure, we can make some sites for mobile phones, but, come on, mobile-phone formatted pages never caught on. It's like camera phones: there might be a case where you can use them, but unless the camera is comparable to a point-and-shoot, it's pretty useless. So too with the internet. Adapting the internet to a device ain't gonna work, because most cellphones are pretty poor at displaying large amounts of information, their processors are pretty damn slow, input is tedious and access speed often quite painful. Since there's little interest, there's little hope a "Standard" way will come about. So every site mucks around with mobile content, when the best solution is to just serve the page, and let the browser deal with it. If your cellphone sucks as a browser, no amount of optimizing will change that. If a website has for cellphones a "low-bandwidth" variant, chances are most PC users would prefer it too.
Yeah, Flash is a special case of the "large thing to download as web content" but it was the one that worked best for "great big thing that you need to download".
As an alternative, take dowfiles.com (and probably the whole FileFront network). Even if they coded to standards and used HTML without tables and CSS for all styling then they'd still have a 55KB header image and a total of 166KB of images to load. That means just using standards still won't make all sites mobile-compatible.
Don't see how this is news. Google Mobile has been doing this for at least a year. Any links to external sites that originate on my m.google.com homepage are automatically "mobile-i-fied" by Google. You can disable the service in your preferences I believe if you want the full size page.
Personally I love the service since it saves me valuable bandwidth and time.
I do not know if Google respects these special User-Agent strings for mobile-specific site versions - and frankly, as a user, as long as the site works, I don't really give a hoot who is parsing it. "Web Designers" need to get their heads out of their ass and realize that the web is a content delivery mechanism, not a publishing and layout mechanism. You have absolutely no guarantee whatsoever on what your content looks like to the end user. If you don't like that than get a real publishing job.
> Vodafone has come at the problem from the other end, offering a new
> service that translates traditional Web pages into mobile-friendly
> ones on the fly -- but it strips out the user agent in the process,
Sounds like Vodafone has been learning from Micro$oft on how to embrace, extend, and extinguish.
well if the vodafone life proxy connects always switch to the mobile versions of the site. this is simple. and just change the css if possible.
TBH I'd be appalled if any of my sites had a page anywhere near 100KB for the 'required' downloads (HTML and CSS file but not CSS background images, which wouldn't be "fundamentally required" images).
As for CSS on a mobile phone: 1) surely that means that XHTML and CSS is an even better combination, since the mobile will see the <link> tag and be able to ignore it because it is typed as "text/css" and it knows it can't handle it. It will then be able to just load and display the HTML, and 2) The last phone I bought was three years ago now, and it was bottom of the line (£30) then. The only reason I bought it was because it was about as cheap as buying a battery for my older phone. Yes, the new phone has Internet access (probably WAP) but I've never wanted to be ripped off by the rates they charge so I've never used it. All I know is that newer phones can use Opera Mini, I don't bother looking at what functionality that might include.
Google may give you a different site, but what I was saying is why should they need to? If your mobile browser can handle text and input boxes then why should Google need to serve it anything different as long as it is properly designed?
This is a bad idea. While there is an issue about how content is displayed, there is also an issue about how much content there is.
What is needed is a new (proposed) HTTP request header that passes the media types (classes) to the server. Then instead of trying to guess the media type from the user agent string, the server will know for sure. For example a request might have the HTTP header "MediaType: display/mobile;geometry=288x384" and a 2nd header "MediaType: audio/stereo;format=mp3,ogg,flac". The server then knows what kinds of media the device has or has enabled. If I turn the sound off, the sound mediat type won't be sent in requests. When I am at home and request a document print (as opposed to a screen print) it could send "MediaType: print/inkjet;hdpi=1200;vdpi=1200" which would clue in the server to limit the content to just what is appropriate for printing.
Your theory "The site content shouldn't need to change - only the presentation." is technically correct. But the point here is to preserve some bandwidth, too, by doing some presentation filtering (only send the media types in use) and optimization (server knows the display size, so it sends small display media or reformats). It's still the same content ... but the parts of the content not needed are not transmitted. On the server side, one way to implement this is to add some XML tags that identify what parts of the conent apply to what media types.
The whole "separate content and style" idea has long had the flaw that too much (usually all of it) content was sent all the time. My above proposal allows the content volume to be limited for transmission while still preserving the fundamental principle of that separation as it applies to the creation of the content. Web sites (such as Vodafone) are really trying to do some kind of content filtering now. This just makes for a standardized way to manage it (so the unreliable User Agent won't need to be used).
now we need to go OSS in diesel cars
Firstly, if you are differing content based upon the User-Agent header, you are doing it wrong. The User-Agent header was intended for bug workarounds, not feature queries. If you want to know if a browser supports a particular document type, you use the Accept header.
Secondly, another person posted that they block the Accept header. That's a real problem.
Thirdly, proxies that alter content are nothing new. There is an HTTP header that allows authors to mark content that should not be altered by proxies. It is Cache-Control: no-transform. Hardly anybody has heard of it, so I doubt Vodafone respects it, but if they do, then nobody should be complaining. Just use that to stop them messing with it. If they don't support it, then complain and ask them to add support.
Bogtha Bogtha Bogtha
The whole idea of the web is that any page should display on any user agent
I'm sorry, but that's just a crock of shit - A photo gallery is never going to display well on Lynx. User agents are so different that to cater for the lowest common denominator would result in an incredibly bland and static web. Don't blame the humble web developer for this situation. User agents have continually evolved and engaged in "arms races" in an attempt to propriatise (if that's not a word, it should be) the web. Standards are beginning to help, but there's a long way to go.
I think problem here is the same as in any other area of software engineering. One need software so one saves on engineering skipping it altogether. The result is a mess. The mess can be quite some nice environment for some. Any change to this world however (un)reasonable be fought with whatever means available.
I wonder - have I succeeded in getting modded to hell now or not?
Opera Mini works great for me. It has a built-in RSS reader. It renders most sites good on a small screen. Reduces traffic. Works with any mobile operator I tried (though I never used Vodafone). It compresses traffic and downscales graphics server-side. It handles Unicode and multilingual stuff. So far it is the best mobile web option for me. It works virtually anywhere, and it is good enough. I even prefer m.gmail.com-in-Opera.mini instead of gmail.app or Google Mobile.
I tried also new Nokia browser (webkit-based) on the E-series phones. It is really impressive, but requires a descent phone. Also it generates much more traffic as it loads the full-blown version of the page. Also some AJAX pages don't work nice with it (e.g. Picasaweb).
Google Mobile is a nice initiative, but it lacks polish and smoothness of Opera Mini experience. In fact it works only in built-in phone browser, which is crap in most phones (except above mentioned Nokia browser).
There are other services similar to Google Mobile (like http://www.skweezer.net/), but they are of inferior quality to plain Opera Mini.
Is it done on a server before it hits your phone or does the phone change the html?
If it is done on the phone just use the opera browser for your mobile phone instead of the build in browser. http://www.opera.com/products/mobile/
I think it rocks.
And why have a white list. Why not get the sites targeting the mobile market to use meta data much like the meta data used for search engines.
meta name="transformhtmlforbetterviewingsuage" content="nochange"
to me to have a white list is not very good. Imagine if all the mobile suppliers use this technology and all have a white list. bad idea. People develop there sites so they are displayed the way they want it to be. I would be pissed as well if someone changed the way my site looked especially if I made it especially for mobile phones.
wurfl.sourceforge.net maintains an XML file with LOTS of devices and an exhaustive set of capabilities.
And you always code for the lowest common denominator WAP browser. Features are added for specific capabilities, the most obvious being screen size. I'm all for non-fixed width layout, but it does make sense to fix the width for WAP browsers.
I was also skeptical until I actually designed a site for WAP and the usual browsers from the same codebase.
I agree that WAP sites are dumbed down, but sometimes that is really cool if all you want is the content. And I don't redirect you to a different site if you visit http://wap.bla/ from Firefox.
Correct. It makes much sense for the web server to see where the request is coming from- whether from a PC or a mobile. If its the latter, the web server can serve a stripped version of the page; if requested. Not all web sites can (or will) implement this feature, but a few select ones can give this a try. Getting a client agent to check what to serve and what to discard will be very sluggish.
Vodafone, as well as all web developers relying on the User Agent string are taking the wrong approach to this. There is a reason we can specify mobile for a style sheet. First, your website shouldn't be heavy on HTML and should be able to degrade nicely. Secondly, you use the mobile style sheet to tell the mobile browser how to render everything. It's dumb to rely on the user agent string for ANYTHING and completely ignore standards designed to help with this.
I presume you mean the ability to specify different stylesheets for different media ,
If so then no , its only for adjusting the layout and will in most cases result in the same stuff being downloaded.
A clever client could try to avoid downloading things that weren't going to be dispayed but most don't ( this is
also a way to pre-cache things).
personally i would do a simple standards compliant page that works on both , its hardly rocket science .
Convincing the marketing people not to fill it with crap is far far harder tho.
[site]
Then I guess we should stop helping mobile users by sending them smaller graphics at smaller file sizes... How silly of us to try and help them surf websites faster.
"With the screen area so small what will happen is that ads will appear on separate screens before the content"
By separeted screens, you meant: into (wichever) cell phone happens to be next to me, right?
sweeet.
Well, EDGE and EV-DO are more than capable of downloading large files quickly but... why is your website heavy in regards to file size in the first place? The layout of your website should NEVER be heavy (even highly complex layouts can be done without going above 100KB even with lots of graphics) so this isn't an issue.
If you're using large images for products (which should be the only items that take up more than 30KB per image), then why would you want it smaller anyway? I would rather the full version especially since if I'm loading it that means I want to look at it.
It seems everyone is missing the big picture. Relying on User Agent strings for ANYTHING is like adding concrete to a bridge that's falling apart. If you don't fix it and fix it the correct way, you're going to have tons of patches and eventually the whole thing is going to just fall. The services that make file sizes smaller are also quick fixes that don't really resolve anything and just allows web developers to become more sloppy.
I've been building web sites for over 10 years now and there is no reason you can't have a really complex and graphical website the size of Slashdot or CNN and have the entire page be under 100-150kb. Compression and file formats have come a long way and knowing when to use which one is key.
It is not copyright infringement because the content has not been nodified.
The CONTENT is just HTML code. Just because your website looks a certain what in your IE browser doesn't mean it looks the same when I view it in Lynx.
Does that mean I am guilty of copyright infringement because the site does not look the same as when you created it? Is it copyright infringement when a deaf person watches a film because they are modifying it by removing the sound?!?!?
Like I said above - site owners need to get their heads out of their ass. HTML has no guarantee over layout, that is not what markup is for. It is to offer up *suggested* layouts. If you want layout guarantee, use PDF or something.
It isn't necessary for a phone to implement a full-featured CSS parser, the display can't handle such rich content anyway. Have you ever hit a CSS-designed web page where for some reason or other it couldn't load the style sheet? The result is a pretty plain text page, which would be easily legible on a phone. Some basic formatting would prettify it a bit.
Now Apple has shown you how to do it
Yeah.. produce a stripped down browser with no flash or java and the fanboys will eat it up proclaiming it's the second coming.
That's how to do it.
Meanwhile, I'll stick with the full featured browser I've had on every phone for the last 3 years.
I've done it with Opera 6, you configure the .ini file to ask for the wap filetypes in preference to the html filetypes. I'm not sure whether Opera 9 is different.
Compare the Google mobile portal ( http://www.google.com/m ) and www.google.com and get back to me.
You'll see that http://www.google.com/m is designed more as a "mobile portal" (including support for location-based services depending on your mobile service provider, for example it automatically detected my location when adding weather.) than the basic www.google.com search page for desktops.
Google at least allows the user to override which page they use if user-agent-based detection fails though.
retrorocket.o not found, launch anyway?
"Clearly, the proper solution to this 'problem' is for mobile devices to have a proper web browser, rather than some half-arsed cut-down POS."
This sounds good at first blush, but it really isn't an ideal solution. I live in Japan and I have one of the latest au cell phones. It gets TV, I can use the camera to take pictures of Japanese characters and look them up in the included English/Japanese dictionary. And I can browse both normal "PC" (as the phone refers to it) websites and mobile sites.
I always, always, always use the mobile sites. Since I get charged by the packet, the mobile sites are much better because they are built to be low bandwidth (not to mention they're usually focused on the cellphone - the Final Fantasy site, for example, lets you purchase cell phone games and ring tones). I'd get killed (literally death by packets) if I browsed real web sites on the phone as the data transfer would KILL me (well sort of - the maximum I can get charged for more data is around $40).
"There is no time, sir, at which ties do not matter," Jeeves, (Jeeves and the Impending Doom)
But it really pisses me off when I connect to a site on my Nokia Communicator with its 640 pixel-wide screen and the page comes up crippled within only the left hand 120 pixels because some web-developer decided that's what I should have based on his/her ignorant assumptions!
In addition to the Opera browser that has already been mentioned, I'd like to point out that ELinks has pretty good CSS support for a browser that doesn't even do graphics.
The web was designed to deliver browser agnostic pages, that the browser made display decisions about based upon the platform (small screen, large screen, gui, text, etc.), OR based upon the wiewing preferences of the user ... NOT based upon the preferences of the server or page developer.
All of the web elements that have come along that force viewing decisions upon the client (browser restrictions, resizing the screen, etc.) are a blight upon the net.
Cry me an f'n river. "oh no! I'll have to write browser agnostic pages again! Like I should have for the last 12 years. Woe is me." Blow me. It's my screen, not yours. Learn how to write a real web page (meaning one that is browser agnostic), or get a new career.
Having web filters out there that make it hard or impossible for the server to force this crap upon the client is a blessing. I know nothing else about vodaphone, but on this issue: good work, and ignore the whiners.
Actually that concept does work in the real world where it is used, it's just not being used everywhere. Those places need fixing.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
While I agree with most of your points and know that a good XHTML/CSS website should be able to degrade gracefully on older/less capable platforms, and even while I consider that 100KB is already twice as heavy as a webpage should be at most, you have to consider the platform itself: something that fetches the "mobile" CSS and identifies itself as a mobile playform (user-agent) it means it's not a "computer/standard" device, so we can imply that it has one or two limitations: download speed (and mobile data rate, which aren't unlimited in a lot of cases) and display size/resolution.
It doesn't do anything good to send a 50KB, 400x300 JPEG photo to someone on a mobile device which has, say, a 240x160 display. It means the device must download the image, resize it, display it. So it takes longer to download (time, possibly money), takes processing time and power (time, battery life) to render something in lower resolution (with a possible huge loss of quality depending on the resizing method).
Take Opera for the Nintendo DS as a good example. I'd rather send a custom "version" of the website (custom CSS, custom website width and custom images, all the rest is the same) so people can browse in RSS mode: it loads faster, it displays faster, the graphics are lighter and sharper, it removes the need to scroll horizontally to read the content. I'm helping the user view my website for his platform. If implemented correctly, it's not that difficult to manage. I only have to remember to make a smaller image when I add something, the website does the rest.
If history has shown us anything, it's that the vast majority of "web developers" cannot be trusted with checking the User-Agent header. How many times have those of us who use non-mainstream browsers or platforms seen websites choke because some moron is doing this incorrectly?
Example: My bank's website works with Firefox on Windows and Linux and Mac, but not on any other platform Firefox runs on (like BSD or Solaris). Why? They've hard coded a few Firefox user-agents into their scripts. Result? To check my bank statement I have to find the nearest Win/Linux/Mac box.
CSS is a blunt hack that can only reformat the existing data, largely by hiding it. It cannot break it up into smaller pages, select different scripts to run, or negotiate different content altogether unless you have them download all the content for all media types then display only the types you want.
Plus, it's usually handhelds that have the poorest CSS support around.
Done with slashdot, done with nerds, getting a life.
It's a novel legal theory, but the value is mostly in the comedy of its assumption that your HTTP headers are a creative work. Are you preparing to sue Cisco because their routers modify the IP packets that you originate?
Done with slashdot, done with nerds, getting a life.
You are 100% correct! Imagine trying to complete say an advanced search page with many checkboxes on a cellphone - it is clunky without a stylus. But split the process into a few pages (think wizard) and suddenly you can do it all with simple HTML. YMMV depending on the problem of course.
No, standards alone won't help in this case (unless they used CSS properly and indicated that smaller images were available specifically for mobile devices).
The problem with Vodafone's proxy method, is that there's no way for site owners to know in advance that their site is about to be (possibly) munged. At least if it sent a special browser ident, and the details of its munging processes were published, then savvy people could code properly against it.
Je fume. Tu fumes. Nous fûmes!
Google.com: 2037 bytes of HTML
Google.com/m: 1436 bytes of HTML
For all of the extra links, that's not a lot of difference at the base HTML level.
As for it being a "mobile portal page", isn't that a different page to a "Google search home page for showing off Google's various capabilities"? If it is then it should have a different URL and not be UA dependent. After all, what's to stop someone who is non-portable or on a laptop wanting things like weather automatically added in without having to to an iGoogle page?
Yes, you could replace "Google search home page for showing off Google's various capabilities" with "mobile portal page" for mobile users accessing "http://www.google.com/", but the better solution would be for a URL to be a uniform locator for a given resource where the resource stays constant and that resource is then designed so it will degrade for any platform.
You wouldn't want the building at a street address to be a bookshop if you asked about it in a library and a bakery if you asked about it in a restaurant, would you? So why should google.com be "Google search home page for showing off Google's various capabilities" from a desktop and "mobile portal page" from a mobile?
'Handheld' is such a descriptor. Setting large parts of an HTML page to use a CSS class such that @media handheld {
The User-Agent is about the only consistent way to recognize a mobile device. The accept headers don't reflect the device capabilities 99% of the time. SOMETIMES a UA-Profile header is available which is supposed to link to device capabilities, but often that is missing, the link is dead, or the link points to the capabilities for a different phone. The reason for actually needing to know the specific device is not for standard web pages ( a waste of your phone ), but for delivering content such as wallpapers, ringtones, or videos that are actually in the size and format supported by your device. Once again this is never consistent across phones.
Great, now I'm going to spend all day contemplating the implications of a cell phone with horsepower.
Our wealth breeds emptiness
Advertisers (like Google AdSense) cannot dictate what you do when you offer your content in a separate medium, unless you have some sort of a contract with them.
The only one who would be upset about the lack of advertisements on the mobile version is the content publisher. They (content publishers) can integrate ads in a "screens" fashion like you suggested which will probably be bad for business. Or they can do what sites like Slashdot does, i.e. cripple the mobile version so it's only useful for a quick summary/scan, which forces the user to favor and use the web version that has advertisements.
If you can't mod them join them.
"And Web developers are mad"
You're telling me. Oh, wait, you meant the other kind of mad. Nevermind
Coder's Stone: The programming language quick ref for iPad
Probably for the same reason we don't have an attribute to define which browser the style is for or an attribute to define what screen size, orientation, and color depth th style is for. Most developers are to lazy to use such tools and those that aren't are mostly purists that don't think making multiple versions of content for different uses is acceptable.
Of course it's even worse on phones because most don't properly support the media attribute. They'll either use the screen style or, worse, use both the screen and handheld style. There is no sane behavior that works on every phone. Of course phone browsers should just be a real, fully standards compliant, web browser. There is no excuse anymore for crappy browsers that don't work well.
Handheld is kind of a dumb idea anyway because there are so many different handheld devices. It'd make more sense to be able to define screen sizes, orientation, and color depth for different styles so that the phones can try to figure out which, of several, styles to use. It'd also be nice for websites viewed on computers as it'd let you enable your site to work on ancient cruddy systems without holding back on making them really nice for modern systems. Anyone that has a site that sometimes gets viewed by some freak running IE4 at 640x480, especially if they are in management at your company, knows how painful it is to deal with. Sure most of your viewers may be using IE7 and Firefox with a screen size of 1024x768 or greater but they'll just have to look at an ugly, hard to use, site crammed over into the upper left hand side of their window.
So, it's the fault of developers. Lazy developers of web browsers for phones don't follow standards. Lazy developers of websites don't follow standards. Lazy standards bodies don't properly create standards to handle real world problems.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
You can't write browser-agnostic pages for mobile phones. The browsers suck too much. Writing browser agnostic will result in pages using the least common denominator of the mobile phone capabilities, and believe me it's not pretty.
That's not the same page. Google is looking at the User-Agent and delivering an appropriate page depending on whether it is a phone or a desktop accessing the site, which is exactly what the developers are complaining that Vodafone is preventing them from doing unless they are 'whitelisted' by Vodafone (currently free of charge, but how long will that last?).
Its not the HTTP headers of the request where the copyright problems are (they would not have sufficient creative content to be copyrightable), it is the derivative work that Vodafone's proxy creates before it sends it back to the mobile phone.
In the general case, they are performing a valuable service for their customers by making webpages that were designed for desktop look reasonable on mobile phones, and I wouldn't expect designers of desktop pages to be upset, provided they are not blocking or replacing ads. But where content providers are providing their own mobile versions of their pages, then Vodafone is living dangerously by going on record on their forums to say that they are deliberately replacing the User-Agent to ensure that their customers get the Vodafone mangled version of the desktop webpage, not the content providers' mobile version.
We have it already. Vodafone's proxy will send certain mime types through to the phone unmodified. The problem is that without the original User-Agent, content providers don't know when to generate the mobile optimised version of the page, and when to send the desktop version.
Yes, you can write browser agnostic web pages that work well on (desktop, laptop, text-only, PDA, mobile, multiple browsers instead of only on variations of IE, etc.) just fine. You just can't include useless crap in the page.
Too bad reliable SVG display doesn't work without either UA sniffing (either explicitly on the server, or using Javascript heuristics on the client), thanks to the most popular browser in the world. Nor are many people interested in downloading Adobe's SVG viewer (which is required to view SVG in IE, AFAIK). Nor is SVG even remotely useful for raster images (whodathunkit?), which is what most of the world's images are.
the entire mechanism of google maps is built around zooming in and out, so it's easier for them to implement mobile vs web browser scaling than it might be for other sites. and yet despite that they have a separate downloadable mobile app that will precache the images and other resources as a preferred method versus using the actual maps.google.com webpage in your mobile browser
I am a web developer but I agree with the OP. The original design intention of HTML was to enable content to be platform-independent. Of course the original concept of "content" was "TEXT content". Now we have web developers not only presenting text but also application user interfaces with HTML. Which is to say, it is all a completely broken ugly mess.
The first person who thought it was a good idea to insert script into HTML comment tags should have been slapped with a haddock.
We need a new sort of markup language/web service that can present graphics and UIs in a platform independent manner. HTML was never it. Flash isn't it. Silverlight may or may not be, but probably not because it is tied to Microsoft.
The $299 iPod runs full Web 2.0 sites, same as the $399 iPhone. Everyone who is not named Apple is copying that approach right now.
The idea that there is a separate mobile Web is anachronistic in the extreme. Even before the iPhone it was a stretch to think we were going to create a shadow Web for mobiles. Once you use an iPhone you can clearly see that we don't have to.
The whole idea of Web 2.0 development is you don't have to make multiple sites, you can build one site that scales. If you close your eyes to IE you see we are already living in the future. Mobiles are full citizens on the Web now, if you have a full Web browser.
Always on broadband network connection and no Web 2.0 browser? Bullshit. An anachronism.
Can someone mod the parent post of this one up... as it describes a real world situation where this is a big problem.
We develop java applications and games for mobile phones. There are thousands of handsets all with different capabilities, screen sizes, limitations, key-scan codes.
When the user wants to download a product from a wap site, they just want to click a link and get the correct version for their phone which has graphics the correct size, responds to the correct key codes, has sound in the correct format for that phone, includes handset specific features. Many users don't even know the model of handset they own! And there are significant differences between phones even of similar model number, eg. Nokia 6230 has a different screen size than a Nokia 6230i (128x128 and 208x208 respectively).
The mobile java libraries (MIDP) are very simple and do not have features such as image resizing; some phones have absurdly small memory limits (eg. 64K) which mean you can only afford to squeeze in graphics of the correct size and cut out features on those phones. eg. You can't make an application that looks good on a 352x416 sized screen (eg. Nokia N80 with several megabytes of memory) and a 128x128 screen (eg. Nokia 7210 with 64K file size limit).
Thus it is impossible to make a good quality non-trivial application that will run on all phones. We typically have over 50 different builds to support the several hundred handset models required to cover the most common phones used in Europe.
Using the user-agent in conjunction with databases of handset specifications such as the wurlf.xml file allows this to be automatic in most cases. If the user-agent is stripped out then this is impossible and you have to resort to something like asking the user what handset they have.
Another problem is trying to make network based applications mobile phone java applications. Many phones do not support Socket Connections in their MIDP implementation so the only solution is to use HTTP connections. Even on newer phones with Socket Connection implementation it doesn't work on all operators depending on calling plans, so HTTP is the only common fall back protocol. For a network based application you need the data that is included in the body to be what your server sent or else it will break the application.
When Vodafone turned this system on, instead of getting back our data from a HTTP GET request, it sent a Vodafone HTML page telling the user about the gateway.. of course my handset app had no idea how to handle this as it was expecting the data our server had sent it! If the user has previously agreed to the gateway, then all your data has vodafone headers and footers around your own body.
There are ways to disable the gateway, eg. setting cache-control header or setting the content-type to something other than text/html... but this should not have been neccessary.
The danger is now that other operators will do something similar, and each one will have a different work-around required, or it will be a full time job applying to be in white-lists. There are hundreds of operators around the world and we can't keep up to date with every quirk of their systems.
I copied this sig from someone else (but where did they get it from?)
I hear a lot of people calling out that they need the user agent to scale images, but it's more than that.
Certain phones do not support tables, some do. Some support background colors, some don't. Or some do in certain circumstances. They also can or cannot support left or right alignment of images. Some phones can talk wml, xhtml or some other lingo. Some phones support video, some don't. If they do support video, you definately want to know how large the screen is to make sure you provide the right links, and you want to know what kind of video it supports best: there is a huge difference in optimization there. Phones also support different kinds of ringtones (but that's common knowledge, I hope). Also, phones that claim in their request-headers to have a screen of 320x240, effectively have a screen of 300x220 because the browser itself takes a number of pixels from the border.
To optimize all these things, you need the user agent string. Not just the type of handset, but the exact string because each update of a handset can mean different settings for pixels, ringtones, video, page-layout, etc etc. For instance: an mp3-ringtone that works on a handset of operator A will be switched off by operator B "because they don't want their handsets to support mp3 due to legal regulations", which you can only see through the exact user agent string. If you're lucky...
So taking away the user agent string is one step taken too early. Phones do not support the same things at this moment, and a proxy server cannot "translate" all content for you, if a decision is made in the server what content you'll be served according to the user agent. And what they support depends heavily upon the mobile phone industry _and_ the operators that patch & hand out mobile phones...
Once all handsets support the same features and all have at least 640x480 screens, then Vodafone can do whatever they like. Roughly estimated that'll be when hell freezes over, or perhaps in a few decades.
Vector graphics should scale beautifully to any size. (It might be processor heavy though.) And some simple [java]script to manage a dynamic UI will hopefully not be too processor intensive.
Does anyone use .mobi domains?