You have you database driven search. You have your nifty search results with alternating row colors and links built in to the results. Lets take that one step further and add a little something to keep your users from leaving while the search is executing.
A Page Loading message will generally be taken for granted, but the user will stay because they see something more than a blank page. Without realizing it they may wait the 2 or 3 seconds longer than they would have if they merely saw a white page and a slow loading bar in the bottom. Here is the basic concept. What we want to do is make sure that the first thing we output to the user is the html, head, and beginning body tags. This way we can send a little extra information to them before the intensive portion of the page starts. In normal cases your server will attempt to buffer this information until the entire page has been generated by the script, but we are going to turn the buffer off and basically stream html to the end user as we generate it.
<% Option Explicit Response.Buffer = False 'turn the buffer off %> <html> <head> <!-- We will be adding some script here --> </head> <body> <% 'heavy code execution here %> </body> </html>
Now what we want to do first is to create a div to use as our loading message. It is going to need an ID to make it easier to access later on, so lets go ahead and get that out of the way, as well as some empty script tags. Code:
A difficult concept for some web developers to grasp in the beginning is that the page load on the client browser does not occur until long after the server-side script has finished. Basically the browser waits until it has received all of the information for the page, and then it fires the onLoad event. Knowing this we can add a little function to our page to make the div disappear and call it from the body onLoad event. This way the user will see the loading message right up until the data has finished downloading and is ready to be displayed.
Now we can extend this further by adding some look and feel to our message, but I will leave that to you. Instead lets look at some of the additional functionality we can add.
Perhaps we have a submission or search results page that can execute in anywhere from half a second to five seconds. Someone with a quick query is going to see a flicker and then the results, and without enough time to understand what just flashed in front of the page they may think it was unintentional. Never let the user think they saw something unintentionally, as that is unprofessional. What can we do about this? How about adding a minimum load time of two seconds? This should be enough time for the user to register the loading message we spent so much time on, but not enough time to get antsy. Obviously we don't want to slow down the transmission or execution on the server-side, so lets see how we can do it on the client-side:
The first change we made was to add a startTime, endTime, and minWaitingTime. We set the start time by writing it's value from the seconds on the server at the beginning of execution. At the very bottom of the page, after all of the intensive calculations have been processed we then write the value of the endTime. Now we needed a function to compare these times so we created the waitMessage function to compare the start time plus the minimum wait time to the end time. If the wait time has been too short than we need to force the browser to wait for the rest of the minimum time before removing the message. We then needed to change the onLoad to call our new function.
*** Special thanks to NadN for pointing out a mistype in the code concerning function names.