Fix iframe-positioning problem with frameMagic.js

A short followup on my previous post about iframes; as I happen to like simple drop-in solutions, I updated the javascript that handles the ‘blank 2nd page in an iframe bug’ to automagically work upon inclusion in the html.
So if you happen to have problems with the positioning of 2nd (or later) pages in iframes (due to the top part of the iframe not being visible in the ‘viewport’), just upload frameMagic.js to your webserver and add the following to the head of your html to ease your iframe-blues;

<script type="text/javascript" src="path/to/frameMagic.js"></script>

Optionally you can specify which iframes are to be treated this way (excluding the other ones) by doing

<script type="text/javascript">
var fM_conf="iFrame1,iFrame3";

You can find more information and examples on

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('');

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:

var firstrun = new Object();
function frameMagic(el) {
if (typeof firstrun[el] === ‘undefined’) { firstrun[el]=true; }
else { document.getElementById(el).scrollIntoView(); }
<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.

Jakob Nielsen on mobile web usability

Using websites on a mobile phones is “a cringeworthy experience” according to recent user tests performed by Jakob Nielsens company. His advice:

Although devices will get better, the big advances must come from websites. Sites (including intranets) must develop specialized designs that optimize the mobile user experience. Today, few sites have mobile versions, and those that do are usually very poorly designed, without knowledge of the special guidelines for mobile usability.

Great article, a must-read for those working on mobile(-friendly) websites!

It’s the basics, stupid!

Na enkele dagen vloeken, hebben we de thermostaat in het huis waar we sinds kort wonen, vervangen.
Ondanks de veelbelovende lcd-display, de zichtbare en verborgen knopjes en een heuse handleiding om die machine te leren programmeren, zagen de ingenieurs bij Elro namelijk 1 klein detail over het hoofd; je kunt de temperatuur niet met één simpele druk op de knop lager zetten! Om de thermostaat bijvoorbeeld op 18 in plaats van 19 graden te zetten, moet je 48 keer op een knopje drukken! Je kunt immers enkel stijgen, per half graadje en om lager uit te komen moet je dus helemaal rond. 48 keer, op een moment dat je het sowieso al te warm hebt!
Dus hebben we nu een nieuwe thermostaat. Zo een heel gewone, met een grote ronde knop waarmee je alleen de temperatuur kunt instellen. De basis-functionaliteit, niks meer, maar vooral niks minder!
Dat we de basics ook in 2009 niet uit het oog mogen verliezen! En da’s op veel van toepassing …

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
  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%.

Don’t let Google fool you; tame your Flash!

As I wrote some time ago, Google indeed does index Flash. Great? Well, maybe not: you might even lose valuable site visits this way! This is because Google does not direct users to the page on your site that contains the Flash (as it does for image search results), but to the standalone SWF-file. That means that people doing a normal search in Google, will in some circumstances get high-ranking links straight to your Flash-files instead of to your website and that these prospects will not be drawn into your website’s sales funnel at all. So much for SEO.
Solutions? Well, you could refrain from using Flash all together, there’s too much of that stuff around anyhow. Or you could prohibit googlebot (and others) from indexing swf-files by specifying this in your robots.txt-file.
These are both great remedies, but somehow I think not everyone will agree. So what if we could perform some ActionScript-magic to make a Flash-file force itself in its correct context? Although I am not a (Flash-)developer by any account, I hacked together a small demo (in ActionScript 2) to show how that could be done.

And indeed, if you point your browser to the standalone swf-file, you’ll see you are redirected to this page. How this is accomplished? Quite easily actually;

  1. add a flashvar (e.g. “embedded=true”) to the object/embed tags in the html
  2. check for the value of that flashvar in the first frame of your movie:
    var embedTrue=_root.embedded;
    if (embedTrue=="true") {
         // all normal flashyness goes here
    else {
  3. and in frame 2 we do the redirect to the correct url:
    onEnterFrame = function() {
    // weird, stupid test to avoid this from being executed more than once
    if (!runOnce) {
    		var targetUrl = "";

I’m sure the code stinks and it indeed is only actionscript2 and not 3, but maybe someone out there can build something usefull out of this general idea. And if not, I’ve had fun learning some (very) basic actionscripting. Now off to “Add/remove software” to get rid of that hog of an IDE! 🙂

Google lust Flash, maar willen we dat wel?

Ge weet het, ik ben geen fan van sites die geheel of grotendeels Flash-gebaseerd zijn (idem voor Flex of MS Silverlight, vanzelfsprekend). Daarvoor geloof ik te sterk in de kracht van gestandardiseerde html, css en javascript en hecht ik te veel belang aan toegankelijkheid, gebruiksvriendelijkheid en ‘searchability’.
Maar met de  ‘searchability’ van Flash zit het blijkbaar dan toch wel snor; Google indexeert blijkbaar ook swf-bestanden (flash dus). De “do no evil”-zoekgoden maken daarvoor gebruik van de Adobe Search Engine SDK die onder andere een applicatie bevat om (html-)strings uit een swf-file te halen. Swf2html lijkt qua functionaliteit gelijkaardig aan swfstrings, onderdeel van het open source swftools.
Dat Google nu ook Flash indexeert, is echter niet altijd ideaal. Probeer bijvoorbeeld een eenvoudige zoekopdracht naar “student woon samen sparen kbc“. Het 3de (!) zoekresultaat is een link naar een “instructie-filmpje” over de KBC Spaarservice. Normaal gezien krijg je die presentatie enkel in de KBC-site te zien, maar dankzij Google wordt het flash-bestand zonder die context ontsloten. Ik durf te wedden dat dat toch niet echt de bedoeling is? En dat een grootbank of webcommunicatie-bureau vermoedelijk toch prefereert dat zoekresultaten naar de site (van de klant) gaan, in plaats van naar het individueel geindexeerde flash-bestand?
Mijn mening over flash blijft dan ook grotendeels onveranderd:

  1. geef de zoveel mogelijk de voorkeur aan ‘plain old html’, zeker voor navigatie
  2. gebruik flash enkel voor pagina-elementen en niet voor hele pagina’s
  3. gebruik flash enkel als die technologie een duidelijke meerwaarde biedt (voor video of iets game-achtigs bv)
  4. zorg voor een beschrijving van de inhoud van de flash in de html (in de div waar de flash wordt geplaatst, of in noscript-tags)
  5. mijn enige nieuwe advies: voorkom dat swf-files worden geïndexeerd (dmv robots.txt) of voeg code toe aan je flash, zodat die enkel in de juiste context getoond wordt (ik veronderstel toch dat dat kan, zoals ook een html-pagina met wat javascript in de juiste iframe-context kan gedwongen worden?).

Om af te sluiten nog een bijzonder leerrijk (flash-)filmpje misschiens?

Over foute (web-)applicaties

Omdat Jakob Nielsen een slimme mens is, omdat hij een nieuw artikel geschreven heeft over web-applicatie design en omdat gratis kwalitatieve content alle aandacht verdient; “Top-10 Application-Design Mistakes“. Wat die tien design-fouten dan wel zijn moet ge zelf maar lezen, maar de bonus wil ik U hier niet onthouden:

“It’s almost always wrong to have a Reset button on a Web form. The reset button clears the user’s entire input and returns the form to its pristine state. Users would want that only if they’re repeatedly completing the same form with completely different data, which almost never happens on websites. Making it easy for users to destroy their work in a single click violates one of the most basic usability principles, which is to respect and protect the user’s work at almost any cost.”

Dat de man gelijk heeft!

Nog over web usability

web app usability posterGewoon een paar links naar interessante usability-related dingen die ik de laatste dagen feed-gewijs las: