Here are places it's useful to use [[Ajax]]: (This is a collaborative [[wiki]] list - feel free to add your own ideas to it)

<ol>

<li><strong>Form driven interaction.</strong>

<p>Forms are slow. Damn slow. Editing a tag (the old way) on a [[del.icio.us]] bookmark? Click on the edit link to load the edit bookmark form page, then edit the field and hit submit to wait for the submission to go through, then return to the previous page and scroll down to find the bookmark to see if the tags look right. Ajax? Click on the edit link to instantly start changing tags, click on the submit button to asynchronously send off changes to the tags and quickly see in place what changed, no reloading the entire page.</p>

<ol>

<li><strong>Form driven interaction- Subset:Linked Select Menus.</strong>

<p>Imagine a T-Shirt with 3 options; Size, Color, and Style. When tracking inventory for your product, you know you have Large, Red, Polo shirts in stock, but you're out of Small, Blue, T-Shirts... It is frustrating to the user to pick this combination and then receive an error on the checkout page stating that you are out of stock... and then have to go back to the selection process and reconfigure the item... Using AJAX, you can check the stock of the options <em>as the user picks them</em> and only return or show the items which are in stock.</p></li>

<li><strong>Form driven interaction- Subset: Autosave.</strong>

<p>Think of someone writing in Word. Which button do they use the most? Save.</p>

<p>With javascript you can do one better. Not only can you have a save & continue that works just like the [[del.icio.us]] forms - you can autosave! Remember to tell the user this, as simply knowing this relaxes quite a lot of people. Properly explained count-down clocks are prefered, for obvious reasons.</li>

</ol>

</li>

<li>*Deep hierarchical tree navigation.*

<p>First of all, applications with deep hierarchical tree navigation are generally a nightmare. Simple flat topologies and search/tagging works very well in most circumstances. But if an application really calls for it, use [[Javascript]] to manage the topology ui, and Ajax to lessen the burden on the server by lazy loading deep hierarchy data. For example: it's way too time consuming to read discussion threads by clicking through and loading completely new pages to see a one line response.</p></li>

ds

<li>*Rapid user-to-user communication.*

<p>In a message posting application that creates immediate discussions between people, what really sucks is forcing the user to refresh the page over and over to see a reply. Replies should be instant, users shouldn't have to obsessively refresh. Even Gmail, which improves on the old hotmail/yahoo mail 'refresh inbox, refresh inbox' symptom, doesn't really push Ajax far enough yet in terms of notifying new mail instantly.</p></li>

<li>*Voting, Yes/No boxes, Ratings submissions.*

<p>It's really too bad there are no consistent UI cues for Ajax submission, because submitting a vote or a yes/no response is so much less painful when the submission is handled through Ajax. By reducing the time and impact of clicking on things, Ajax applications become a lot more interactive - if it takes a 40 seconds to register a vote, most people would probably pass unless they really care. If it takes 1 second to vote, a much larger percentage of people are likely to vote.</p></li>

<li>*Filtering and involved data manipulation.*

<p>Applying a filter, sorting by date, sorting by date and name, toggling on and off filters, etc. Any highly interactive data manipulation should really be done in Javascript instead of through a series of server requests. Finding and manipulating a lot of data is hard enough without waiting 30 seconds between each change in views, Ajax can really speed this up.</p></li>

<li>*Commonly entered text hints/autocompletion.*

<p>Entering the same text phrases or predictable text phrases is something software/javascript can be good at helping out with. It's very useful in del.icio.us and GMail, for quickly adding tags/email addresses.</p></li>

<li>*Long Running Queries/Remote Calls*

<p>If a query or a call to a remote [[webservices|webservice]] is going to take a long time that cannot be avoided, Ajax works well to manage the time a user waits for the call to return. For example, [[SWiK]] uses Ajax to fill in results from webservices detailing new projects: a user doesn't have to wait for [[Google]] webservice to return before starting to edit a new project</p></li>

<li>*Computationally Expensive Operations*

<p>Unfortunately, [[Javascript]] has a tendency to be quite slow. Complex math or number crunching just isn't Javascript's forte. Additionally, heavy Javascript computation can slow the basic user interface to a crawl. An [[XMLHTTPRequest]] call can be helpful here, pushing expensive computations to beefier remote servers.</p></li>

<li>*Server Savings*</li>

<p>Sometimes, a process users do over and over on a site requires only a small amount of new data to be sent over the wire, but loading entire new pages can be a strain on the servers in bandwidth and resources. [[Ajax]] can be used to load pages more efficiently, as seen in various "tests":http://webperformanceinc.com/library/reports/AjaxBandwidth/index.html. Of course the ease of making new or multiple requests from the server using Ajax also means that it's easy to overtax server resources as well.</p>

<li>*Interactive Panning And Moving Over Data*</li>

<p>Moving and scanning over large data sets makes it impracticable to pre-load all of the data. Loading the data just ahead and just behind the user gives the appearance of the entire data set being accessible, and helps eliminate loading times. A great example of this is Google Maps' scrolling tiles system that gives the effect of moving over a map by picking up tiles behind and placing them ahead of the user, filling them with new data requested via Ajax.</p>

</ol>

ce porcarie ca poti edita pagina asta

Here are places it's useful to use [[Ajax]]: (This is a collaborative [[wiki]] list - feel free to add your own ideas to it)

<ol>

<li><strong>Form driven interaction.</strong>

<p>Forms are slow. Damn slow. Editing a tag (the old way) on a [[del.icio.us]] bookmark? Click on the edit link to load the edit bookmark form page, then edit the field and hit submit to wait for the submission to go through, then return to the previous page and scroll down to find the bookmark to see if the tags look right. Ajax? Click on the edit link to instantly start changing tags, click on the submit button to asynchronously send off changes to the tags and quickly see in place what changed, no reloading the entire page.</p>

<ol>

<li><strong>Form driven interaction- Subset:Linked Select Menus.</strong>

<p>Imagine a T-Shirt with 3 options; Size, Color, and Style. When tracking inventory for your product, you know you have Large, Red, Polo shirts in stock, but you're out of Small, Blue, T-Shirts... It is frustrating to the user to pick this combination and then receive an error on the checkout page stating that you are out of stock... and then have to go back to the selection process and reconfigure the item... Using AJAX, you can check the stock of the options <em>as the user picks them</em> and only return or show the items which are in stock.</p></li>

<li><strong>Form driven interaction- Subset: Autosave.</strong>

<p>Think of someone writing in Word. Which button do they use the most? Save.</p>

<p>With javascript you can do one better. Not only can you have a save & continue that works just like the [[del.icio.us]] forms - you can autosave! Remember to tell the user this, as simply knowing this relaxes quite a lot of people. Properly explained count-down clocks are prefered, for obvious reasons.</li>

</ol>

</li>

<li>*Deep hierarchical tree navigation.*

<p>First of all, applications with deep hierarchical tree navigation are generally a nightmare. Simple flat topologies and search/tagging works very well in most circumstances. But if an application really calls for it, use [[Javascript]] to manage the topology ui, and Ajax to lessen the burden on the server by lazy loading deep hierarchy data. For example: it's way too time consuming to read discussion threads by clicking through and loading completely new pages to see a one line response.</p></li>

ds

<li>*Rapid user-to-user communication.*

<p>In a message posting application that creates immediate discussions between people, what really sucks is forcing the user to refresh the page over and over to see a reply. Replies should be instant, users shouldn't have to obsessively refresh. Even Gmail, which improves on the old hotmail/yahoo mail 'refresh inbox, refresh inbox' symptom, doesn't really push Ajax far enough yet in terms of notifying new mail instantly.</p></li>

<li>*Voting, Yes/No boxes, Ratings submissions.*

<p>It's really too bad there are no consistent UI cues for Ajax submission, because submitting a vote or a yes/no response is so much less painful when the submission is handled through Ajax. By reducing the time and impact of clicking on things, Ajax applications become a lot more interactive - if it takes a 40 seconds to register a vote, most people would probably pass unless they really care. If it takes 1 second to vote, a much larger percentage of people are likely to vote.</p></li>

<li>*Filtering and involved data manipulation.*

<p>Applying a filter, sorting by date, sorting by date and name, toggling on and off filters, etc. Any highly interactive data manipulation should really be done in Javascript instead of through a series of server requests. Finding and manipulating a lot of data is hard enough without waiting 30 seconds between each change in views, Ajax can really speed this up.</p></li>

<li>*Commonly entered text hints/autocompletion.*

<p>Entering the same text phrases or predictable text phrases is something software/javascript can be good at helping out with. It's very useful in del.icio.us and GMail, for quickly adding tags/email addresses.</p></li>

<li>*Long Running Queries/Remote Calls*

<p>If a query or a call to a remote [[webservices|webservice]] is going to take a long time that cannot be avoided, Ajax works well to manage the time a user waits for the call to return. For example, [[SWiK]] uses Ajax to fill in results from webservices detailing new projects: a user doesn't have to wait for [[Google]] webservice to return before starting to edit a new project</p></li>

<li>*Computationally Expensive Operations*

<p>Unfortunately, [[Javascript]] has a tendency to be quite slow. Complex math or number crunching just isn't Javascript's forte. Additionally, heavy Javascript computation can slow the basic user interface to a crawl. An [[XMLHTTPRequest]] call can be helpful here, pushing expensive computations to beefier remote servers.</p></li>

<li>*Server Savings*</li>

<p>Sometimes, a process users do over and over on a site requires only a small amount of new data to be sent over the wire, but loading entire new pages can be a strain on the servers in bandwidth and resources. [[Ajax]] can be used to load pages more efficiently, as seen in various "tests":http://webperformanceinc.com/library/reports/AjaxBandwidth/index.html. Of course the ease of making new or multiple requests from the server using Ajax also means that it's easy to overtax server resources as well.</p>

<li>*Interactive Panning And Moving Over Data*</li>

<p>Moving and scanning over large data sets makes it impracticable to pre-load all of the data. Loading the data just ahead and just behind the user gives the appearance of the entire data set being accessible, and helps eliminate loading times. A great example of this is Google Maps' scrolling tiles system that gives the effect of moving over a map by picking up tiles behind and placing them ahead of the user, filling them with new data requested via Ajax.</p>

</ol>

Here are places it's useful to use [[Ajax]]: (This is a collaborative [[wiki]] list - feel free to add your own ideas to it)

<ol> """MANISH KUMAR SINGH IS THE KING'"""

<li><strong>Form driven interaction.</strong>

<p>Forms are slow. Damn slow. Editing a tag (the old way) on a [[del.icio.us]] bookmark? Click on the edit link to load the edit bookmark form page, then edit the field and hit submit to wait for the submission to go through, then return to the previous page and scroll down to find the bookmark to see if the tags look right. Ajax? Click on the edit link to instantly start changing tags, click on the submit button to asynchronously send off changes to the tags and quickly see in place what changed, no reloading the entire page.</p>

<ol>

<li><strong>Form driven interaction- Subset:Linked Select Menus.</strong>

<p>Imagine a T-Shirt with 3 options; Size, Color, and Style. When tracking inventory for your product, you know you have Large, Red, Polo shirts in stock, but you're out of Small, Blue, T-Shirts... It is frustrating to the user to pick this combination and then receive an error on the checkout page stating that you are out of stock... and then have to go back to the selection process and reconfigure the item... Using AJAX, you can check the stock of the options <em>as the user picks them</em> and only return or show the items which are in stock.</p></li>

<li><strong>Form driven interaction- Subset: Autosave.</strong>

<p>Think of someone writing in Word. Which button do they use the most? Save.</p>

<p>With javascript you can do one better. Not only can you have a save & continue that works just like the [[del.icio.us]] forms - you can autosave! Remember to tell the user this, as simply knowing this relaxes quite a lot of people. Properly explained count-down clocks are prefered, for obvious reasons.</li>

</ol>

</li>

<li>*Deep hierarchical tree navigation.*

<p>First of all, applications with deep hierarchical tree navigation are generally a nightmare. Simple flat topologies and search/tagging works very well in most circumstances. But if an application really calls for it, use [[Javascript]] to manage the topology ui, and Ajax to lessen the burden on the server by lazy loading deep hierarchy data. For example: it's way too time consuming to read discussion threads by clicking through and loading completely new pages to see a one line response.</p></li>

<li>*Rapid user-to-user communication.*

<p>In a message posting application that creates immediate discussions between people, what really sucks is forcing the user to refresh the page over and over to see a reply. Replies should be instant, users shouldn't have to obsessively refresh. Even Gmail, which improves on the old hotmail/yahoo mail 'refresh inbox, refresh inbox' symptom, doesn't really push Ajax far enough yet in terms of notifying new mail instantly.</p></li>

<li>*Voting, Yes/No boxes, Ratings submissions.*

<p>It's really too bad there are no consistent UI cues for Ajax submission, because submitting a vote or a yes/no response is so much less painful when the submission is handled through Ajax. By reducing the time and impact of clicking on things, Ajax applications become a lot more interactive - if it takes a 40 seconds to register a vote, most people would probably pass unless they really care. If it takes 1 second to vote, a much larger percentage of people are likely to vote.</p></li>

<li>*Filtering and involved data manipulation.*

<p>Applying a filter, sorting by date, sorting by date and name, toggling on and off filters, etc. Any highly interactive data manipulation should really be done in Javascript instead of through a series of server requests. Finding and manipulating a lot of data is hard enough without waiting 30 seconds between each change in views, Ajax can really speed this up.</p></li>

<li>*Commonly entered text hints/autocompletion.*

<p>Entering the same text phrases or predictable text phrases is something software/javascript can be good at helping out with. It's very useful in del.icio.us and GMail, for quickly adding tags/email addresses.</p></li>

<li>*Long Running Queries/Remote Calls*

<p>If a query or a call to a remote [[webservices|webservice]] is going to take a long time that cannot be avoided, Ajax works well to manage the time a user waits for the call to return. For example, [[SWiK]] uses Ajax to fill in results from webservices detailing new projects: a user doesn't have to wait for [[Google]] webservice to return before starting to edit a new project</p></li>

<li>*Computationally Expensive Operations*

<p>Unfortunately, [[Javascript]] has a tendency to be quite slow. Complex math or number crunching just isn't Javascript's forte. Additionally, heavy Javascript computation can slow the basic user interface to a crawl. An [[XMLHTTPRequest]] call can be helpful here, pushing expensive computations to beefier remote servers.</p></li>

<li>*Server Savings*</li>

<p>Sometimes, a process users do over and over on a site requires only a small amount of new data to be sent over the wire, but loading entire new pages can be a strain on the servers in bandwidth and resources. [[Ajax]] can be used to load pages more efficiently, as seen in various "tests":http://webperformanceinc.com/library/reports/AjaxBandwidth/index.html. Of course the ease of making new or multiple requests from the server using Ajax also means that it's easy to overtax server resources as well.</p>

<li>*Interactive Panning And Moving Over Data*</li>

<p>Moving and scanning over large data sets makes it impracticable to pre-load all of the data. Loading the data just ahead and just behind the user gives the appearance of the entire data set being accessible, and helps eliminate loading times. A great example of this is Google Maps' scrolling tiles system that gives the effect of moving over a map by picking up tiles behind and placing them ahead of the user, filling them with new data requested via Ajax.</p>

</ol>

Here are places it's useful to use [[Ajax]]: (This is a collaborative [[wiki]] list - feel free to add your own ideas to it)

<ol>

<li><strong>Form driven interaction.</strong>

<p>Forms are slow. Damn slow. Editing a tag (the old way) on a [[del.icio.us]] bookmark? Click on the edit link to load the edit bookmark form page, then edit the field and hit submit to wait for the submission to go through, then return to the previous page and scroll down to find the bookmark to see if the tags look right. Ajax? Click on the edit link to instantly start changing tags, click on the submit button to asynchronously send off changes to the tags and quickly see in place what changed, no reloading the entire page.</p>

<ol>

<li><strong>Form driven interaction- Subset:Linked Select Menus.</strong>

<p>Imagine a T-Shirt with 3 options; Size, Color, and Style. When tracking inventory for your product, you know you have Large, Red, Polo shirts in stock, but you're out of Small, Blue, T-Shirts... It is frustrating to the user to pick this combination and then receive an error on the checkout page stating that you are out of stock... and then have to go back to the selection process and reconfigure the item... Using AJAX, you can check the stock of the options <em>as the user picks them</em> and only return or show the items which are in stock.</p></li>

<li><strong>Form driven interaction- Subset: Autosave.</strong>

<p>Think of someone writing in Word. Which button do they use the most? Save.</p>

<p>With javascript you can do one better. Not only can you have a save & continue that works just like the [[del.icio.us]] forms - you can autosave! Remember to tell the user this, as simply knowing this relaxes quite a lot of people. Properly explained count-down clocks are prefered, for obvious reasons.</li>

</ol>

</li>

<li>*Deep hierarchical tree navigation.*

<p>First of all, applications with deep hierarchical tree navigation are generally a nightmare. Simple flat topologies and search/tagging works very well in most circumstances. But if an application really calls for it, use [[Javascript]] to manage the topology ui, and Ajax to lessen the burden on the server by lazy loading deep hierarchy data. For example: it's way too time consuming to read discussion threads by clicking through and loading completely new pages to see a one line response.</p></li>

<li>*Rapid user-to-user communication.*

<p>In a message posting application that creates immediate discussions between people, what really sucks is forcing the user to refresh the page over and over to see a reply. Replies should be instant, users shouldn't have to obsessively refresh. Even Gmail, which improves on the old hotmail/yahoo mail 'refresh inbox, refresh inbox' symptom, doesn't really push Ajax far enough yet in terms of notifying new mail instantly.</p></li>

<li>*Voting, Yes/No boxes, Ratings submissions.*

<p>It's really too bad there are no consistent UI cues for Ajax submission, because submitting a vote or a yes/no response is so much less painful when the submission is handled through Ajax. By reducing the time and impact of clicking on things, Ajax applications become a lot more interactive - if it takes a 40 seconds to register a vote, most people would probably pass unless they really care. If it takes 1 second to vote, a much larger percentage of people are likely to vote.</p></li>

<li>*Filtering and involved data manipulation.*

<p>Applying a filter, sorting by date, sorting by date and name, toggling on and off filters, etc. Any highly interactive data manipulation should really be done in Javascript instead of through a series of server requests. Finding and manipulating a lot of data is hard enough without waiting 30 seconds between each change in views, Ajax can really speed this up.</p></li>

<li>*Commonly entered text hints/autocompletion.*

<p>Entering the same text phrases or predictable text phrases is something software/javascript can be good at helping out with. It's very useful in del.icio.us and GMail, for quickly adding tags/email addresses.</p></li>

<li>*Long Running Queries/Remote Calls*

<p>If a query or a call to a remote [[webservices|webservice]] is going to take a long time that cannot be avoided, Ajax works well to manage the time a user waits for the call to return. For example, [[SWiK]] uses Ajax to fill in results from webservices detailing new projects: a user doesn't have to wait for [[Google]] webservice to return before starting to edit a new project</p></li>

<li>*Computationally Expensive Operations*

<p>Unfortunately, [[Javascript]] has a tendency to be quite slow. Complex math or number crunching just isn't Javascript's forte. Additionally, heavy Javascript computation can slow the basic user interface to a crawl. An [[XMLHTTPRequest]] call can be helpful here, pushing expensive computations to beefier remote servers.</p></li>

<li>*Server Savings*</li>

<p>Sometimes, a process users do over and over on a site requires only a small amount of new data to be sent over the wire, but loading entire new pages can be a strain on the servers in bandwidth and resources. [[Ajax]] can be used to load pages more efficiently, as seen in various "tests":http://webperformanceinc.com/library/reports/AjaxBandwidth/index.html. Of course the ease of making new or multiple requests from the server using Ajax also means that it's easy to overtax server resources as well.</p>

<li>*Interactive Panning And Moving Over Data*</li>

<p>Moving and scanning over large data sets makes it impracticable to pre-load all of the data. Loading the data just ahead and just behind the user gives the appearance of the entire data set being accessible, and helps eliminate loading times. A great example of this is Google Maps' scrolling tiles system that gives the effect of moving over a map by picking up tiles behind and placing them ahead of the user, filling them with new data requested via Ajax.</p>

</ol>

Here are places it's useful to use [[Ajax]]: (This is a collaborative [[wiki]] list - feel free to add your own ideas to it)

<ol>

<li><strong>Form driven interaction.</strong>

<p>Forms are slow. Damn slow. Editing a tag (the old way) on a [[del.icio.us]] bookmark? Click on the edit link to load the edit bookmark form page, then edit the field and hit submit to wait for the submission to go through, then return to the previous page and scroll down to find the bookmark to see if the tags look right. Ajax? Click on the edit link to instantly start changing tags, click on the submit button to asynchronously send off changes to the tags and quickly see in place what changed, no reloading the entire page.</p>

<ol>

<li><strong>Form driven interaction- Subset:Linked Select Menus.</strong>

<p>Imagine a T-Shirt with 3 options; Size, Color, and Style. When tracking inventory for your product, you know you have Large, Red, Polo shirts in stock, but you're out of Small, Blue, T-Shirts... It is frustrating to the user to pick this combination and then receive an error on the checkout page stating that you are out of stock... and then have to go back to the selection process and reconfigure the item... Using AJAX, you can check the stock of the options <em>as the user picks them</em> and only return or show the items which are in stock.</p></li>

<li><strong>Form driven interaction- Subset: Autosave.</strong>

<p>Think of someone writing in Word. Which button do they use the most? Save.</p>

<p>With javascript you can do one better. Not only can you have a save & continue that works just like the [[del.icio.us]] forms - you can autosave! Remember to tell the user this, as simply knowing this relaxes quite a lot of people. Properly explained count-down clocks are prefered, for obvious reasons.</li>

</ol>

</li>

<li>*Deep hierarchical tree navigation.*

<p>First of all, applications with deep hierarchical tree navigation are generally a nightmare. Simple flat topologies and search/tagging works very well in most circumstances. But if an application really calls for it, use [[Javascript]] to manage the topology ui, and Ajax to lessen the burden on the server by lazy loading deep hierarchy data. For example: it's way too time consuming to read discussion threads by clicking through and loading completely new pages to see a one line response.</p></li>

<li>*Rapid user-to-user communication.*

<p>In a message posting application that creates immediate discussions between people, what really sucks is forcing the user to refresh the page over and over to see a reply. Replies should be instant, users shouldn't have to obsessively refresh. Even Gmail, which improves on the old hotmail/yahoo mail 'refresh inbox, refresh inbox' symptom, doesn't really push Ajax far enough yet in terms of notifying new mail instantly.</p></li>

<li>*Voting, Yes/No boxes, Ratings submissions.*

<p>It's really too bad there are no consistent UI cues for Ajax submission, because submitting a vote or a yes/no response is so much less painful when the submission is handled through Ajax. By reducing the time and impact of clicking on things, Ajax applications become a lot more interactive - if it takes a 40 seconds to register a vote, most people would probably pass unless they really care. If it takes 1 second to vote, a much larger percentage of people are likely to vote.</p></li>

<li>*Filtering and involved data manipulation.*

<p>Applying a filter, sorting by date, sorting by date and name, toggling on and off filters, etc. Any highly interactive data manipulation should really be done in Javascript instead of through a series of server requests. Finding and manipulating a lot of data is hard enough without waiting 30 seconds between each change in views, Ajax can really speed this up.</p></li>

<li>*Commonly entered text hints/autocompletion.*

<p>Entering the same text phrases or predictable text phrases is something software/javascript can be good at helping out with. It's very useful in del.icio.us and GMail, for quickly adding tags/email addresses.</p></li>

<li>*Long Running Queries/Remote Calls*

<p>If a query or a call to a remote [[webservices|webservice]] is going to take a long time that cannot be avoided, Ajax works well to manage the time a user waits for the call to return. For example, [[SWiK]] uses Ajax to fill in results from webservices detailing new projects: a user doesn't have to wait for [[Google]] webservice to return before starting to edit a new project</p></li>

<li>*Computationally Expensive Operations*

<p>Unfortunately, [[Javascript]] has a tendency to be quite slow. Complex math or number crunching just isn't Javascript's forte. Additionally, heavy Javascript computation can slow the basic user interface to a crawl. An [[XMLHTTPRequest]] call can be helpful here, pushing expensive computations to beefier remote servers.</p></li>

<li>*Server Savings*</li>

<p>Sometimes, a process users do over and over on a site requires only a small amount of new data to be sent over the wire, but loading entire new pages can be a strain on the servers in bandwidth and resources. [[Ajax]] can be used to load pages more efficiently, as seen in various "tests":http://webperformanceinc.com/library/reports/AjaxBandwidth/index.html. Of course the ease of making new or multiple requests from the server using Ajax also means that it's easy to overtax server resources as well.</p>

<li>*Interactive Panning And Moving Over Data*</li>

<p>Moving and scanning over large data sets makes it impracticable to pre-load all of the data. Loading the data just ahead and just behind the user gives the appearance of the entire data set being accessible, and helps eliminate loading times. A great example of this is Google Maps' scrolling tiles system that gives the effect of moving over a map by picking up tiles behind and placing them ahead of the user, filling them with new data requested via Ajax.</p>

</ol>