On Apr 19, 2008, at 7:14 AM, Bruno Figueiredo wrote: > I would suggest you to put up a static version of what they're > waiting to load with a loading bar on top. That way users get a > general sense of what's to come and if it's worth it or not. Kinda > of what we did back in the days with no broadband where we used > lowres versions of the images to be loaded. > > About the willingness to wait, frustration hits at about 10 seconds.
I have to respectfully disagree with both of these suggestions. Loading bars might as well be a measure of the visitor's cumulative frustration level, and 10 seconds is far too much of the user's valuable time to waste, no matter how wonderful the end result might be. For the Flash-heavy advertising that is the main product of the Very Large advertising company where I work, the general rule is: "Load times SHALL take no more than three seconds, and if you need that long, it damn well better erase the viewer's memory of the wait ... and you're not a Vulcan." (That was the draft version of the rule I wrote; the final version was more diplomatic and took twice as long to get to the point.) Robert Hoekman's suggestion to "include additional content and/or interactive imagery" to the page is actually more of a requirement. There are two components to performance: actual and perceived. If you can't achieve actual performance gains, you must change the user's perception to exclude any experience of waiting. As several people on this thread have suggested, you can continue to load Flash content in the background while your visitors are otherwise engaged. In my opinion, we should flip that idea on its head: Never distract the visitor from what you're showing them NOW with the promise of things to come. Whatever you're doing on screen, you should be guiding and controlling the user's focus of attention. In most cases, the best thing you can put in that focus is *a meaningful message* rather than the melange of effects-driven, semi-abstract fireworks that one sees too often on Flash sites. One huge advantage of keeping meaningful content, presented well, in front of the user at all times is that their perception of time slows down as they consider that meaning ... and that's when your preloaders should be beavering away to set up the next act. > Users will only wait longer than that if they perceive the content > to be really worth it. The problem with convincing the user that the content they're waiting to see is 'worth it' is that they're *still waiting*. You've only increased their frustration and perception that your site performance sucks. By the way, user testing on 'office productivity software' (guess where that was) indicates that an actual performance problem in one area tends to have a 'bleed-over' effect on users' perception of performance across an entire product. If the user notices *any single performance problem*, previously acceptable performance times will suddenly become marginally unacceptable. > User testing won't really do for this since test users usually have > a higher tolerance for waiting than real users. True, you shouldn't insert performance-related questions during the main course of testing, as doing so almost always negatively colors the subject's overall assessment of the design being testing. However, you can expose your worst performance hotspots by asking the right followup questions after the main testing tasks are done. > If you put it up live, watch for top exit pages in your logs, if > they're leaving the content rich pages, you need to decrease the > loading times. Absolutely! But decrease the perceived loading times before they start leaving, because you're not just losing a customer, you're losing reputation. Will Parker [EMAIL PROTECTED] ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [EMAIL PROTECTED] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
