5 tips to tackle the problem with iframes

Iframes have always been frowned upon by web-purists (confession: myself included). But things are never black and white and sometimes iframes can be the best solution for a problem (you could substitute “‘iframes” with “Flash” in the previous 2 sentences, but that’s another discussion). So here are 5 quick tips which might lessen some of the SEO- and usability-problems associated with the use of iframes;

1. Google loves doesn’t hate iframes done right!

Although Google is rather vague about the subject, iframes and SEO do not have to be mutually exclusive. But you will have to make sure it’s your main page that shines in search results, not the iframe-content. The main page (where the iframes are defined) has to be more then a mere placeholder for one or more iframes. Migrate as much information (titles, description and other text) from the iframe-content to your main page, which should describe what goes on in the iframe(s). Use the iframe title-property and insert alternative content between opening and closing iframe-tags. A quick example:

<h2>Calculate your mortgage rate</h2>
<p>Calculating your mortgage rate was never easier; just enter the loan-amount and the duration below!</p>
<iframe src=”http://page.url/iframe-container-page1″ …  title=”Calculate your mortgage rate here”>Your browser does not seem to handle frames properly, but you can calculate your mortgage rate <a href=”http://page.url/iframe-container-page1″>here</a></iframe>

2. Own the stage

Avoid visitors viewing the iframe-content out of the context of the main page (e.g. because they followed a link in search-results). Add javascript to the iframe-content to check if it is accessed stand-alone and redirect to the main page (or explain and provide link to the main page) if that is the case.

if(self.location==top.location) top.location.replace('http://contain.er/page-url/here');

3. Don’t draw blanks

When a visitor clicks a link at the bottom of a long page inside an iframe and the target is a shorter page inside the same iframe, then he/she will see a blank page which is … well not very usable, no? The (hackety-hack) solution; tell the browser to scroll to the top of the iframe each time a new page in it is loaded, by calling the function below (with the iframe id as parameter) when the iframe’s onLoad event fires:

<script>
var firstrun = new Object();
function frameMagic(el) {
if (typeof firstrun[el] === ‘undefined’) { firstrun[el]=true; }
else { document.getElementById(el).scrollIntoView(); }
}
</script>
<iframe id=”iframe” onLoad=”frameMagic(‘iframe’);”>

Update: the above code has been updated heavily, check my frameMagic.js blogpost

4. Your users really do need scrolling=”auto”!

Help your visitors access all iframe content no matter what configuration they’re using: don’t disable the iframe scrollbars! Disabling them will render the iframe partially inaccessible for some of your users, because the size your iframe-content needs depends on things outside your control such as operating system & versions (e.g. font & screen resolution), browser (e.g. css-implementation) and browser configuration (e.g. non-default font-size). Instead define a reasonable iframe-width and height, make the iframe-content width flexible (fluid) and let the browser decide if a vertical scrollbar is needed.
Update: squeezeFrame.js might be a solution to your scrollbar-woos

5. Smart sizing without scrollbars

If you really really really don’t want scrollbars, if you want your iframe to adapt to the size needed by the iframe-content automatically and if you’re not afraid to experiment; there are some nifty javascript-solutions that allow the iframe-content to communicate the required height to the main page. Check out Framemanager (stand-alone, has some issues though) and the JQuery-postmessage iframe-example (which does everything in javascript, which isn’t really ideal from an accessibility point of view).
Conclusion: iframes aren’t necessarily evil (either), but you’ll have to make a small effort to render them somewhat SEO- and user-friendly.

Is the web too fat for your IPhone?

So you have a spiffy mobile phone with a top notch browser that does a decent job at displaying “desktop-oriented” websites and you use it to surf the web regularly, visiting some of the bigger news-sites in Belgium. What does that mean, from the point of view of data transfer and bandwidth usage?

data usage for 4 pages on 5 sites (click on image for more, methodology see below)

That sure is a lot of data, Captain! What does that mean?

  1. You will have to be patient, because downloading 1 or 2 Mb for that initial page will probably be gruesomely slow (especially if you’re on EDGE because there’s no 3G-coverage)
  2. You will end up paying good money for all that data transfer, because data is money when you’re on mobile time
  3. You might even curse your handset or crashing browser (more on google), because all that data will end up in RAM and these devices do not come with tons of that.

In these broadband-times, website builders seem to have completely forgotten about best practices for download size of complete web pages (html + all js/css/images/…). This means that a lot of websites should be considered non-accessible on mobile devices.
If you want your normal website to be usable on IPhone’s, HTC’s and other Nokia’s, you’ll have to start taking download size into account again. That means taking some technical measures (using mod_deflate and mod_expires for example) and making hard functional choices to remove some stuff (on this blog dropping the rather useless mybloglog-widget saved me 210Kb, going from 10 to 7 posts per page another 200). And if you want to target mobile users specifically, you’d better invest in a mobile-specific version of your site!


The methodology followed to measure these download sizes;

  • disable flash (there’s no such thing on mobiles, with flash these figures would have been even far worse)
  • disable memory cache (in about:config), because it can’t be cleared easily
  • clear disk cache
  • open up firebug and click on ‘net’ to monitor downloads
  • download homepage, random 2nd page, random 3th page and the homepage again

The spreadsheet (on google docs) contains more data (compare above results with those for 2 mobile-specific sites)

Whack your Flash-crazy boss on the head with his iPhone3G!

Whatever you may think about the iPhone-hype, you’ll have to admit that the fact that it doesn’t do Flash makes for great ammunition in the discussion against developing your site’s core functionality in Flash.
Next time your CEO or marketing manager wants a Flex-only website, you won’t have to talk about some obscure geek who doesn’t want to install the Flash plugin, about that poor blind woman who is not able to “read” those Flash animations or about how Google indexing SWF-files might be more of a problem then a solution. No, instead, you’ll only have to point out it won’t work on his iPhone (*). Period.

(*) It won’t work on other mobile devices either; Flash Lite, which ships on e.g. Symbian and Windows Mobile powered devices, is not able to display those millions of fancy animations out there on the WWW either.

.

Are you doing Web2.0 the wrong way?

gapingvoid cartoonAccording to Jakob Nielsen, jumping on the web2.0-bandwagon often implies adding unneeded complexity instead of getting the basics right. I tend to agree; in our quest for sexier, more responsive web-sites and -applications, we seem to easily forget boring stuff such as accessibility and sometimes even usability. How much time did it take you to find your way around the new LinkedIn-UI? Have you tried to use a web2.0-site on a PDA or smartphone? With your keyboard instead of your mouse? Using a screenreader instead of your normal display? Or with JavaScript disabled (I installed the Firefox NoScript-extension to guard against XSS and other JS-attacks)? And if you have ever tried loading Gmail on a slow connection, you’ll surely have noticed that they automatically fall back to their more accessible “Web 1.0”-version?
Lately I’ve been reading a number of interesting articles on this subject and at work we’re carefully applying some Web2.0-techniques as well. Based on that, here are a few suggestions on how to build better websites and -applications:

  1. Don’t use GWT or Flex unless you’re building a complex desktop-style webapp and if you’re willing to invest in a second “basic html”-version as e.g. Gmail does. Let’s face it, most websites and even -applications do not have the level of complexity that warrants the use these RIA-frameworks.
  2. Develop your core functionality in “web1.0”-style, using semantic HTML (structure) and CSS (presentation) only and apply your usability- and accessibility-wisdom here.
  3. Sprinkle JavaScript (behavior) over that static foundation using an established JavaScript-framework to define event-handlers for objects and to modify the content of divs (but test if you can already write to the object, or you’ll get those ugly “operation aborted” errors in MSIE).  Give users a chance to opt out of this enhanced version, even if they do have JavaScript enabled. With this progressive enhancement (a.k.a. hijax) you add extra functionality for those people who can make use of it, without punishing users who can’t because of physical or technological impairments. Read more about progressive enhancement on London-based Christian Heilmann’s site.
  4. Only load your JavaScript-functions when you really need them, creating a kind of stub for methods of an object and only load the real method when it is needed. This technique is dubbed “lazy loading” and can help making your pages load & initialize much faster. To learn more about the concept of “lazy loading” on digital-web.com.
  5. Use <noscript>-tags if you absolutely have to use JavaScript without having a meaningful object already in place in your static version. Explain what is going on and provide a link to a normal page where the same information or functionality can be found.

Off course these tips won’t guarantee you a perfectly usable and accessible website or -application, but when done right, this will help to get 80% of the way. A good functional analysis and thorough testing, both keeping usability and accessibility in mind, will push you towards 99,99%.