Early last week, I spoke to packed crowds at Web Design World in Boston. Clearly the conference scene is heating back up, as budgets for events and off-site training seem to be reappearing. The two sessions I presented (“Beautiful Interfaces with CSS” and “Throwing Tables out the Window“) were lots of fun. I had to bolt to the airport to catch a flight after my last talk. So I didn’t get to stick around to see the rest of the conference or talk to more of the attendees over the next two days.
However, I got to field a few questions from those who came up after each session. All questions were good, and quite relevant to what many of us do every day. Considering this, I thought I’d start sharing some of the questions people are asking after these conferences, along with my extemporaneous responses — sometimes informed, sometimes not so well-informed.
I don’t always have the answers on the spot, but I like to help find the answers when I can. And I think it’s helpful to know what our peers are asking about. If anything, these questions form the base for interesting discussion, and they pull in other people who can help provide answers or steer you and me in the right direction.
One question in Boston dealt with how to address portable devices (like phones and PDAs). Specifically, [my own paraphrased version] this gentleman was frustrated over certain devices, like the Pocket PC, which ignores style sheets linked with a handheld media type, but tries to apply any screen media type style sheets. It badly bungles portions of CSS, breaking the display of a style sheet intended for larger desktop browser windows. He would be fine if there was a way to hide screen media type style sheets from mobile browsers like we typically do with Netscape 4. But Pocket PC’s weakened support of CSS, along with trying to fit a larger desktop browser design into a small window, left him wondering what choices he had.
I’ve heard similar complaints in the past about the browser on Danger’s Hiptop.
First, my thoughts on why most mobile browsers don’t currently support the handheld media type. Then a potential solution for the short-term until they do. (I should state that these are completely my own observations and theories, and I’m an outsider to the entire mobile industry.)
Show of hands for handheld support?
So why isn’t the handheld media type supported more widely by now? Why aren’t mobile browser software companies doing the right thing from the start?
We’ve seen an explosion in the last year of mobile phones and PDAs that support web browsing (to some capacity). They’re doing a better and better job of it. Companies who make the browsing software for these devices want everyone using them to have the “richest” possible experience when they attempt to browse the web. 
If mobile browsers rendered a web page like it was 1996 without any styles applied — as would be the case with most sites that don’t offer a handheld style sheet — there would be a harsh disconnect between what people knew a certain site looked like viewed with their desktop or laptop computer, versus what it looked like on their phone or PDA. Some of the branding and familiar design elements of the site might be lost if mobile browsers didn’t attempt to render everything they could. These browsers render as much of the style for each site as they can. This often leads to problems for developers who try to do the right thing by supplying a handheld media type style sheet.
It’s a chicken and egg thing. Mobile browser software companies aren’t building in support for the handheld media type because virtually no sites are authored with a handheld media type style sheet — yet. However, designers and developers won’t start using the handheld media type until they know there are at least a few mobile browsers that reliably support handheld style sheets, and can immediately see the benefits of providing these additional style sheets.
Clearly, this mobile browsing thing isn’t another flash in the pan. It’s here to stay and it’s only getting more popular. We need to account for the millions of mobile devices attempting to hit our sites. And we need to be designing and building our sites to work everywhere. This includes devices for people with disabilities as well as mobile and all other forms of utility browsers we haven’t even seen come to market yet.
We don’t want to go back to 1997, where we had to build different versions of our sites for each new browser that entered the market. True, in some cases, sites may need to be customized for the best mobile experience, and this may mean a completely different architecture, let alone HTML structure. But when we have the chance, we want to optimize the design or presentation of content based on what type of device is used to view that content.
Things needs to change. It requires action from both browser makers and the designers and developers creating the leading-edge sites. Those sites set examples for everyone else. Neither side needs to think whether or not to go first, they just need to go.
Before I continue, I should note at least one company whose browser correctly supports the handheld media type. Opera has taken considerable steps toward dealing with the challenges of rendering web pages on mobile devices with its Small-Screen Rendering technology. For the majority of web pages that aren’t yet using handheld style sheets, Opera will optimize the page using its SSR technology. However, when Opera detects a page with an existing handheld media type style sheet, Opera assumes the author optimized the page for small screens, correctly applies the handheld style sheet, and disables SSR so as not to interfere with the author’s intentions. So in Opera, pages styled with handheld style sheets render as the author intends. But pages without a handheld style sheet get the SSR treatment. A brilliant fallback solution.
Until that day…
Even as Opera sets a good example, what about other browsers that aren’t yet supporting the handheld media type? How do we design and author our sites with robust style sheets applied to the same basic HTML, forming an attractive, usable site no matter what type of browser or device is used to access the site?
My response to this gentleman involved using JavaScript to force support for handheld style sheets and detect a screen size smaller than X. Some of you may not prefer to use JavaScript for browser type or window-width detection. But until more mobile browsers support the handheld media type, we need some type of proactive fallback solution so we can effectively target small screens and optimize designs for them.
I first suggested he go ahead and add a secondary handheld media style sheet. Then use JavaScript to detect smaller screen sizes. If detected, change the secondary style sheet to both screen and handheld, adding to (and overriding) the default screen media type style sheet. The secondary style sheet (intended for mobile browsers) might contain rules that eliminate floats and absolute positioning used for page layout, and remove any fixed widths for columns and containers. Ideally, a handheld style sheet allows the design to shift to a one-column flexible-width layout that shrinks or expands to fit available screen width.
The problem with my first suggested approach? Many of these new mobile browsers don’t completely support JavaScript yet — if at all. Others disable JavaScript by default for security or “user convenience” purposes. Bah humbug!
Take two
So how about the inverse of that approach?
What if we started by applying a very basic style sheet as both screen and handheld media types. The basic style sheet would only apply simple rules for color, typography, link treatment, and simple list styling. No complex floated columns or absolute positioning. This style sheet would take care of all CSS-supporting devices, whether or not they support the handheld media type.
Then, we use JavaScript to detect wider browser widths — those that might typically imply a desktop browser. If JavaScript is supported, and a wide width is detected (say 620px or greater — or maybe even 750 if your design only works at 750 or greater), then we assume not only a desktop browser, but that enough window real estate exists to render a multi-column design as intended. In this case, we add the main style sheet that divides the page into our standard multi-column layout. Browsers that either don’t support JavaScript (or where it’s been disabled) or browsers that don’t report wide enough screen size only get the basic style sheet.
Seems like that would work. Of course I only know enough JavaScript to hack my way through existing code, not enough to write my own from scratch. So I’m not even going to attempt to write something or create a test example. Others should feel free to suggest or create code, or test this approach however possible.
I’ll note that this is a very similar idea to the solution Cameron Adams recently devised for the opposite problem: how to provide more content or more design when the browser window is extra-wide. (See his Resolution dependent layout, 21 Sep 2004.) In this case, I’m simply recommending going back one step before what Cameron is doing. A simple, basic style sheet is applied as both screen and handheld media types, and takes care of the lowest common denominator that still supports CSS. Then detection of wider window widths results in the application of a more advanced style sheet that breaks the page into multiple columns. Then Cameron’s idea enters in for applying yet more styles for ultra-wide window widths.
Killing the FOUC
One important note if all the above is possible. I might also suggest setting a cookie with JavaScript if a wider window width is detected. Once a cookie is set, server-side code could check for the cookie on subsequent page views, and determine whether or not to add the main style sheet (or not) before resulting HTML is streamed to the client. This way, we avoid the FOUC for any page beyond the first page view.
Feedback, expansions, modifications, pitfalls? Code samples, examples, or other ideas?
Opera has a nice browser for mobile devices, based of the few times I tried it. While the javascript solution is almost painful to use just because companies decide to ignore standards, it sounds like the only solution at this point.
I would work on some code, but I am quite busy at the moment..
OK, here’s a quick proof of concept for you :). It seems to work OK in Firefox and IE6; I haven’t run it through a full test array though. Paste into your <head> and enjoy.
————————-
<link id="basicstyle" rel="stylesheet" media="all" type="text/css" href="basic.css" />
<link id="normalscreen" rel="alternate stylesheet" media="screen" type="text/css" href="norm.css" />
<link id="widescreen" rel="alternate stylesheet" media="screen" type="text/css" href="wide.css" />
<script type="text/javascript"><!--
function detectMinWidth()
{
for (var s in sheets)
{
if (window.screen && window.screen.width >= sheets[s][1])
{
var sheet = document.getElementById(sheets[s][0]);
if (sheet && sheet.setAttribute) sheet.setAttribute('rel', 'stylesheet');
}
}
}
if (window.addEventListener) window.addEventListener('load', detectMinWidth, false);
else window.onload = detectMinWidth;
// Instructions: Comma-separated arrays of stylesheet IDs and minimum widths at which to apply them.
// This is activating 'normalscreen' at widths >= 600 and 'widescreen' when >= 1024.
var sheets = [
['normalscreen', 600],
['widescreen', 1024]
];
//--></script>
————————-
(I hope that worked… that’s after a lot of search/replace character entities to get it to post OK!)
To implement CSS on handled devices, i used to check the HTTP_USER_AGENT and load the corresponding CSS . Of course, this method is server sided :/ But it works well.
One problem with Opera here is that it’s only available for mobile phones but not for Pocket PCs with Windows Mobile 2003 (SE). As long as this doesn’t change we’d have to work with IE Mobile Edition anyway :-(
If server-side technology isn’t a big NoNo then checking the HTTP headers could circumvent the resolution detection with JavaScript. At least the Internet Explorer bundled with Windows Mobile 2003 SE (from now on I will just refer to it as “IEME” ;-) )sends its resolution with also with the HTTP headers:
HTTP_UA_PIXELS := WIDTH “x” HEIGHT
As you’ve said JavaScript support in the mobile browsers is really limited. Esp. when it comes to DOM support. As far as I’ve seen IEME’s JavaScript parser can’t handle DOM related function at all. If you use a DOM function in one of your JavaScript functions, this function doesn’t work.
My only hope is, that Opera will finally port their browser also to the PocketPC plattform.
Yep, the javascript screen-resolution detection system is the way to go at this point. It’s an interesting question to ponder moving forward though because some people will tell you that the screen resolution itself is what’s most important when it comes to style rules, and other people will tell you that regardless of screen resolution, it’s the handheld’s physical interface that matters the most. In other words, if a user is mainly navigating with with a four-way thumb button instead of a mouse, that is what should determine the style.
In reality, it is probably a lot of both, and that is why I am more bullish on doing this sort of thing server-side. I’m not convinced that a singular HTML page needs to work perfectly on desktop browsers and handhelds with a mere stylesheet change. I’m convinced it can work decently, and that it’s a cheap way to support a broad range of devices, but what’s really needed to make a mobile site shine is a focus on mobile. If your content is abstracted well enough at the database level, you can use server-side templating to serve up only the content mobile users need instead of serving up the whole thing and then just hiding a bunch of stuff with stylesheets.
The Bloglines Mobile site is a shining example of this. Through server-side style and content negotiation, I can view my RSS feeds on a desktop browser, a Treo, a Pocket PC, or any other mobile device with any sort of HTML/CSS support at all. Since the server serves up a much simpler page from the get-go, the CSS doesn’t need to do so much complicated stuff to massage it onto my mobile screen. It’s quite nice.
I also think that serving up content this way greatly benefits disabled users. To a large extent, what mobile users need from a site is very similar to what disabled users need: simpler navigation and only the main content of the site. They don’t need promo boxes shoved all over the place beckoning them to click through to other places on the site and they certainly don’t need all the code associated with traditional ad-serving.
I think server-side content negotiation is going to get more important in the coming months and years and handheld users will be among the biggest beneficiaries.
Horst: Opera is going to release Opera for Windows Mobile
And now for being a bit political: Should we really cater for broken User Agents, such as PocketIE? I mean: There really isn’t a “mobile web” yet, unless you look at WAP and cHTML – both broken “solutions”.
If developers start circumventing the need for “handheld” support on mobile devices, we are giving browser vendors an incentive to never fix their browser. Do we really want that?
Arve: Thanks, but I wasn’t talking about Windows Mobile-based Smartphones but about Pocket PCs. Opera for Smartphones (Windows Mobile) can not be instdalled on Pocket PCs with Windows Mobile (2003 SE).
There is a very nice browser for Pocket PC’s and Windows Based Mobile Phones called ThunderHawk. It alows a zoomed out view of your website, as well as enabling you to zoom into certain sections to read.
I found it to render pages using standards extreemly well, although I am not entirely sure of its ‘handheld’ style-sheet support.
I did do a small test and review of the browser a month or so ago, and the results were pleasing.
This issue has been bothering me lately: Is it enough to just have a good stylesheet for mobile devices, or do we need to serve up different HTML? It seems to me that even if we have perfect CSS implementation, there’s just no way around the fact that a traditonal web page is huge compared to what mobile devices can swallow.
If I assume an average of 10K per page (HTML only, no graphics), my data plan with AT&T, which costs $8/mo, only lets me download 100 pages per month. If I throw in graphics, its probably on the order of 10-20 pages per month, and at a snail’s crawl of a pace.
It seems inevitable that we have to slim down the HTML as well as the CSS for mobile users. I was recently on the road and had to figure out a currency conversion – so I hit XE.com from my phone. To my absolute delight, they had a mobile version ready to go. It was then I realized that if they had just used CSS, it would have taken me ten times as long to complete that conversion. (Just visit the site and you’ll see why.)
There is another alternative: Server Side Client Sniffing. This doesn’t rely on Javascript being enabled on the client. All you need to do is detect the user agent string sent by the browser and send the correct stylesheet.
Using the same technique, you can streamline the content too.
More information (along with examples) here: Server Side CSS Sniffing – coping with troublesome browsers
Arve (#6): I’m not suggesting we enable browsers to continue to slack on handheld support. Rather, I’m saying that we don’t want to wait another two years for Microsoft and other vendors to respond. Some authors need real solutions now and can’t wait for all mobile browsers to be perfect.
For all those suggesting a server-side solution to detect a user-agent string… remember what Opera has enabled for several years now? Spoofing of the user agent string as MSIE, so that Opera users don’t miss out on content claimed to be for IE only. Couldn’t this same thing happen (or could it already be happening) with mobile browsers?
And if you start getting into user-agent strings, the list of browsers could become endless — whether you detect desktop or mobile versions.
Just wondering how much of a reality a server-side solution is, when we really want to detect window size, not the specific browser. The fact that the layout needs to change beyond a certain window size is independent of the user-agent string. I don’t think we want to go back to the days of browser-detection to determine what HTML to insert. Rather, we want to determine available screen real estate (and if we can detect that at all) and modify the design accordingly.
And with convergence, sub-laptops running Windows XP with tiny resolutions already exist, and conversely, some phones with full-length screens could possibly support an impressive horizontal resolution in the not-too-distant future.
And Mike (#5): great points about server-side content negotiation becoming much more important. This is what I meant when I stated above that some sites may need to be customized for the best mobile experience — we can’t serve up our 50K-80K desktop pages to mobile users or they won’t come back. Not only are there file size limitations and usability concerns, but the architecture of sites targeted toward mobile users might need to completely change.
Is it just me or is there a contradiction in your comment above Doug?
I don’t think we want to go back to the days of browser-detection to determine what HTML to insert.
great points about server-side content negotiation becoming much more important. This is what I meant when I stated above that some sites may need to be customized for the best mobile experience
To me that reads that we do need to consider going back to the days of browser-detection – ok maybe not browser-detection, but some form of detection – to serve content best suited to the application reading the page – i.e less/restructured markup for mobile devices.
Hmmm. It certainly sounds contradictory doesn’t it Keith.
I don’t think I’m implying that the same URL dynamically serves up different content based on which browser/device hits that URL, although I guess it’s pretty close to that.
Rather, in the circumstance I’m agreeing with Mike, what I’m thinking is that the same content is repurposed, and lives as both a simple and a full version, possibly at different URLs or filenames. Kind of like the difference between Movable Type templates: one for the front page, one for entry pages, and others for RSS/Atom feeds. Same content, just repurposed and at different lengths, depending on whether you hit this site with a browser or a feed reader, and which specific URL you hit.
I guess that might presuppose that mobile browsers might, by default, look for a default document with some other extension. But what do I know, eh?
I’m inclined to create the HTML as it should be with both a link to the ‘screen’ media type and to the ‘handheld’ media type. Then, if the browser uses the ‘handheld’ media type, good, we’re finished. But, when the browser requests the ‘screen’ media type, a server side script checks the HTTP_USER_AGENT and serves up the coresponding css file. The HTML is never altered, encouraging browser makers to provide proper support, and at the same time offering a transparent workaround.
This also, at least in part, addresses the browser spoofing problem. To my knowledge, Opera is the only major browser with the ability built in, and it would request the ‘handheld’ media type by default when needed, regardless of what browser is being spoofed. As there is no server side interfearance on this side of things (remember, we’re only checking when the ‘screen’ css file is requested), there is no problem. Although, I suppose, handheld browser makers could hardwire browser spoofing into their apps, although, I don’t know why they would. And there is the small annoyance of additional server load every time the more commonly requested ‘screen’ css file is requested. Still, that should be rather minimal.
I’m thinking Apache’s mod_rewrite would work. Set it up to only check requests to screen.css (or whatever you name your file) and only if the HTTP_USER_AGENT is a ‘handheld’ browser. Although, I suppose the RewriteCond could get rather lengthy as more browsers, and versions of browsers are added.
I just released a lite, browser-based version of our web-based project management software. To the management team, this meant a wireless, mobile-based version. Essentially, all I did was check the UA on the server-side. This was my last resort.
I would love a better way.
However, for me, it was beyond css/layout changes or support. It was functionality. The list of UAs determine which version of the software you see, not just how its laid out. For example, the project update screen and dashboard-style views change dramatically when displaying tabular data on a screen the size of my Blackberry device.
So, beyond better support, better identification methods would be grand as well. A standard piece of the UA string, maybe. A new key stating device type, maybe (HTTP_DEVICE_TYPE).
I have a T-Mobile Sidekick and some of the CSS designed sites work well. Normally liquid layouts work well because they can go down to size. They don’t look great, but most of us with these handheld devices are used to getting slightly mangled pages (you should really see how badly most table based designs look on handhelds).
Fixed CSS layouts on the other hand are hell on handhelds. They put things in the correct place, but you have no horizontal scrolling capabilities, so sometimes you’re left with navigational menus and other needed parts off the screen and out of view.
Normally on these devices, pages with little to no images and straight black and white text look the best and are the easiest to get information. Whatever Dave Shea does, both CSS ZenGarden and mezzoblue work really well on my sidekick (just pure text with no images). And oddly enough, your site, Doug, looks pretty good on it. I’ll see if I can take some pictures of what they look like and post in a link in a future post.
Someone mentioned about slimming down the html. Perhaps some HTTP compression can help.
First off, I am a client-side zealot (if I had to be categorized one way or another). I mention this because this comment is to say that this stuff (and beyond mobile phones all other device issues) should be dealt with on the server and the client should be be polluted with these issues.
some related resources:
http://www.webstandards.org/learn/askw3c/feb2004.html
http://www.w3.org/TR/2004/REC-CCPP-struct-vocab-20040115/
http://www.w3.org/2001/di/
Xslt is the perfect way to take content and massage it into different flavours. I can see my content in xhtml,html,plain text,flash,svg or even a quicktime movie depending on the “command line as Uri” and the device that requests it. Anything else is breaking the www or at the very least weakening it’s structure and foundations.
I am not claiming to be the master of these technologies or even to understand them, but my use of xslt and the recent .mobi domain name malarkey reinforced my opinions about this topic and thought I would share them here.
Using a server-side solution looking at the user agent seems like the best route to me and can be distinguished from the bad old days of 1997 in that you would only serve up a different style sheet. And, this would hopefully be a temporary solution until handhelds start accepting “handheld” style sheets. I am also very wary of relying on client-side, which is indeterminate, if I know something can take care of the solution server-side.
I like the idea of having a handheld style sheet, and then only checking when the screen style is requested. I also think that the best solution might be one similar to the one described in the entry: have a base screen style sheet, but deliver the full style sheet based on user agent instead javascript. In that case, you’re not browser sniffing to give “different” content, but to give “more” content, to the non-handheld.
At my work site, I’ve been using a Pocket PC to test the site’s display on handhelds. Initially, I was troubled to find that it does indeed read stylesheets intended for screens. However, it *does* read stylesheets intended for handhelds as well, whereas desktop browsers do not.
As it turns out, my work was much easier this way, because all I had to do was fix a few instances where the CSS was not behaving properly, as well as convert some horizontally displayed unordered lists to be displayed horizontally.
Yes, it would be ideal if handhelds would obey the proper stylesheets (and implement CSS properly), but on the other hand, a semantically marked-up page is not too difficult to adapt to a handheld display (in my limited experience).
Personally, I don’t see the need for using any kind of browser detection script.
I must be missing something.
Pocket PC 2002 and Windows Mobile do not render the style sheets from our work website.
We use the following code in the page:
<style type="text/css">@import url(http://www.uleth.ca/man/css/global.css);
</style>
In the CSS, we use:
@media screen{all the style rules
}
Works like a charm. Of course, it doesn’t allow for handheld-specific styling.
Nice article, Doug.
Only sort-of related: how do your guys test your layouts on mobile browsers? Most of us web nerds have a desktop computer or two handy for testing, but not all of us have each brand of cell phone, a Pocket PC, a Palm, a Blackberry, etc, etc, etc.
I suspect this will become a problem. I’ve got a Samsung phone and a PalmOne Zire 72, but the number of other handheld browsers out there is enormous — it seems like every cell phone manufacturer uses their own (right?).
Anyway, if anyone has tips for testing, I’d love to hear them.
Since I saw CSS rendering on N6230 or WM2003 for the first time I’ve been praying for Opera on PPC and Mozilla Minimo…
I do the dirty work on server – If something smells like a mobile device, it doesn’t get any screen styles.
[#21] WM2003 CSS parsing crashes on @media {} so it might be the reason.
Would it not be better to sniff for a pocketPC using some server side stuff and then serve a handheld stylesheet?
I’m assuming that pocketPC’s and all these wonderfull other devices identify themselfs in someway in the UA string, I think that would be a bit cleaner than using java.
That way you could add statements that detect the bad boys like the pocketPC and server them something proper.
I think this shows how important it is to order page content properly in the code itself. Using jump to links for menus etc. and leaving ‘style’ out for the most part on smaller devices. As Peter O. mentioned, many using these devices are paying a monthly fee or extra for the amount they download. How many of the smaller device browsers support the @import for loading a style sheet? Could that also be an answer for just giving a handheld device a simply styled list for a menu and content?
Right now I don’t feel comfortable designing for small screens. Seems like a lot of work since manufacturers are not supporting the handheld media type. I prefer to adhere to standards than write all sorts of hacks to support these broken agents.
Thanks Doug for your posting!
This clarifies better what you told me at the conference in Boston. However I haven’t tried your Javascript suggestion, because PocketPC doesn’t support javascript.
I am just thinking, there needs to be another working group within Web Standards that pushes PDA & Pocket PC manufacturers to get on board with CSS support for their browsers. I have not seen much discussion about this topic, so I am glad you posted and I am sure it will get some attention that it deserves.
When I was trying to test my site out with the Pocket PC, I used two different methods. One, I have a Dell Axim5 Pocket PC and an HP Ipaq. Second, I use Opera’s Mobile Browser Simulation Plug-in and this site:
http://relay5.yospace.com/ipaqbrowser/ipaqbrowser.html?http://www.yoursite.com
After the ? mark put your own web address where you published your site that is Pocket PC compatible and you will see how it actually looks.
I wish there was a way to talk to Microsoft to tell them that its time to upgrade browser versions in Windows CE Pocket PC operating systems. Since every new Pocket PC you buy comes with IE installed by default, Microsoft could improve its mobile browser but why would they do that, if there is no ROI….there is no competition in this area yet.
I think in the coming years we will see browser wars in the Pocket PC systems. Netscape, Firefox, Opera and other browsers will start a war against each other in this new turf which has not been challenged yet.
Just like our Desktop computers we should be able to have multiple browsers. But no one has developed a decent Pocket PC browser yet…
Sorry for the long post.
-S
One thing in my mind: With the emergence of mobile devices, are we looking at a “new” set of standards?
On the server side, one could test the HTTP_ACCEPT header field to find out what mime types the client can accept. If the browser sends a WML mime type for instance then deliver a WML document.
Using JavaScript to load a stylesheet for wider screen resolutions would mean that desktop users with JavaScript turned off wouldn’t get the styles intended for them. So I reckon I’d go down the server route, depending on the reliability of the user agent string, as mentioned above.
Good article – but interesting that you pull Opera out as the browser best supporting the devices. It’ll be interesting to see any further comments you make as development on Mozilla Minimo as that progresses for initial release in January.
Is possible with only with Xhtml1.1 and CSS!
See this web site: http://www.sionpassion.ch created with new CMS 1Work
Ooh, I’ve gotta say though: my Sony Ericsson T610 does a marvellous job of interpreting my websites. It seems to ignore the right stylesheets.
I like developing for user agents that do that.
i was just talking to a friend about this exact thing earier this morning for the first time and i happened to run across this article (while not searching for anything remotely related).
talk about coincidences…
real good info :) great read
I noticed that on my Hiptop/SideKick, browsing Yahoo is quite difficult with their new Javascript links and buttons. I can’t access them at all.
I totally support web browsing for smaller screens.
I even plan to make my website in a text only version that is much simplier so one can access the site easily to read and click links.
I was always wondering what to do with navigation for handheld devices? Should it be displayed at the top of the screen or at the bottom, or maybe elsewhere?
If I place it at the top, then users will need to scroll down on each page, which might come out as annoyance. But then again, if I only put it at the bottom, then users might get confused and not find the navigation.
What do you suggest?
On the Pocket PC user-agent spoofing is an extremely common practice. This is because a large number of banks exclude older browsers by sniffing the version number–and Pocket IE is mistakenly identified as unable to cope with the site. There are at least twenty different tools for spoofing user agents under Windows CE. Most manifest as IE 6 for Windows.
Just something to think about if you want to do server-side sniffing.
I just hope all this doesn’t lead to another 3/4 letter technology (html,cgi,xhtml,css,php,xml, blah blah). These technologies were ‘suppose’ to be created to address future implementations. So I think developers need to stick with what we have and use it as intended. I think far to often we see technolgies that try to start over from scratch and so we as designers end up having to learn several different code formats or whatever. It makes sense if its absolutely necessary to build upon what we already have, but I think its unresponsible and disorganized to try and create new formats from scratch. Its all about organization/structure and if we have 50 different code formats floating around trying to solve 1 problem then things will never be structured.
I think it’s an excellent ideal to create sites that work on all electronic media. However I believe that different electronic devices have their own specific design and usability needs. As such I think it makes much more sense to create separate sites for computer screens, IDTV and handheld devices, rather than take a “one size fits all” approach.
I’m stopping by to say hi since it’s de-lurker day… so hi and Happy New Year! :)
please don’t forget about large screens either. this website, which has pretty much design as anything done with movable type, and most other blogs, is an offender, but nothing comes as bad as webstandardawards.com.
on a 1280 * 960 the webstandardsawards website uses less than a third of the screen size. what a waste. really unfuctional either, you spend all your time scrolling. and of course, if you increase the font size for whatever reason (users hard of sight etc) the problem gets worse (even on a small resolution).
this website is ok using about 70%. but that’s really less, because the navbar space is wasted lower down (should use position: fixed). alistapart.com is also worse.
i really don’t get this “fashion” for fixed width websites. they don’t work on small screens, and they look ridiculous on large screens. please, as mr w3 says, use relative units. so if you must waste space either side (which is fine if you have less than a screen’s content), it’s never going to be too ridiculous.
Very nice article.
One thing we should consider when talking about developing for mobile devices is the question, whether we really want to display all the content of the web page on the page for mobile devices.
In my opinion it’s not only important to adapt the visual presentation but the amount of content, too.
What do you think?
I think Edgar made a good point on not trying to hack devices with broken support. I for one prefer the simple unstyled look (as discusting as that sounds). Also, when I think about targeting a small screen…who cares really what it’s going to look like. Targeting a screen the size of your palm just seems pointless. At that point I think the only reason people are getting on the internet on their cell phones and PDA’S is for the information…. and not necessarily just “surfin’ the net.”
Even as times progress and PDA’s get better technology there seems no point to put much effort into “designing for the PDA device.”
The difference would be like trying to compare a gameboy versus an x-box. although their technology is different, who surfs on the web with their cellphone just for kicks?
oh, and when I say “no point,” I mean that to a broad degree. I’m not browser elitist trying to say there’s no room for advancement. I suppose I sounded a bit harsh… but what I said for the most part is true.
In my opinion it’s not only important to adapt the visual presentation but the amount of content, too.
What do you think?”
It’s a good point. Ideally, one would serve handheld devices a different subset of the content. Granted, CSS wouldn’t be able to do this by itself. You’d need a CMS to do this.
I also wanted to comment on Mike’s way at the beginning:
To a large extent, what mobile users need from a site is very similar to what disabled users need: simpler navigation and only the main content of the site. They don’t need promo boxes shoved all over the place beckoning them to click through to other places on the site and they certainly don’t need all the code associated with traditional ad-serving.
For the record, no one really needs that…outside of the site’s marketing department. ;o)
In many ways, designing for a mobile device forces one to focus on simple navigation and short, concise to-the-point content. Not a bad thing for any site visitor. ;o)
Crap. Blockquote tags don’t work in comments. Sorry.
I’m sorry, but for a number of reasons this sounds like a horrible idea to me. English isn’t my first language, but I hope somebody gets my points.
1. I disabled Javascript in my Opera Browser. That way I would get a stripped down version of a page, although Javascript has absolutely nothing to do with page display.
Actually I’m used to not-working hover effects and other eyecandy on many sites because they are implemented using Javascript, but I’m really disappointed to read suggestions which basically have the same effect on a site like Stopdesign.
Rather start recommending tablebased design, font tags, frames, anything, but please no Javascript-based browser switch…
2. This is the main reason, which was already covered before by Arve.
> “I’m not suggesting we enable browsers to continue to slack on handheld support. Rather, I’m saying that we don’t want to wait another two years for Microsoft and other vendors to respond.”
If we don’t fix that behaviour with a number of hacks, then Microsoft will maybe fix the bug in the next two years. But as soon as the majority is going to implement browser switches and other hacks to circumvent that bug, Microsoft and also other vendors won’t fix that bug in two years, five or ten.
Look at the desktop version of the IE: When is Microsoft going to fix the numerous CSS Bugs? Maybe when they release a complete a new version and have to rewrite the rendering engine anyway. But until then they won’t put a single developer at work on those bugs. And that’s absolutely reasonable, I mean the IE runs fine on every webpage, everything’s rendered correctly.
Now imagine a perfect web without hacks, filters, etc: How many _days_ would it need until Microsofts released a fix for all the rendering bugs? Certainly not many, since no customer could visit a single XHTML page.
Ok that’s a dream, there are millions of IE installations and websites and one couldn’t change them all at once.
But the webbrowsing on PDAs, smartphones and so on is new. There aren’t many people using it yet, nor are there many websites with stylesheets especially for handhelds. I really really hope we don’t make the same mistake as in the desktop world again and end up with the same situation, where webdevelopers fix the bugs of the browser vendors.
You don’t have to be a prophet, to predict that with a Javascript-based browser switch for handheld devices, Opera will stay the only browser that supports “media=handheld” correctly.
web browsing on a PDA is simply too inefficient. Ack! I can’t do it.