We have a website product that allows users to search rental inventory, view results and then click through to a details page.
On the results page, we also allow users the option to refine their search via bedrooms, bathrooms, price, etc. When the form changes, we do not reload the page, we use Ajax to run a new search query and load the new results into the container.
For example, when the user first did a search, they got back 100 properties. Then they refine their search for 3 bed, 5 bathrooms, view = oceanfront and they get back 10 properties. Once the user finds a property they like, they typically click through to the details page. But, let's say they change their mind and click the browser 'back button'.
When that happens, all of our search params that were loaded via Ajax are now gone and our property count is back to 100 instead of 10.
So what I have realized is any data loaded via Ajax is not being cached in the browser so the original search is loaded not the refined search.
After doing some research, I think using history.pushState() and history.popstate() might be the solution but I'm having trouble wrapping my head around how to implement it for our problem.
Is there a better solution? If not, will history.pushState() work?
Related
I am trying to create a site with high rankings in accessibility and one of the things i have come across is. My live search (that makes a ajax request and shows suggestions from what you type in the search bar on "keyup").
The list of suggestions i full of links that will take you to the page you are looking for meaning there is no submit page containing your results you just click the links therefore a submit button would be in my opinion redundant and useless.
My question therefore: Is it possible to make a form ex a live search without a submit button without the site being ranked lower than if it had a search button?
Is it possible to make a form ex a live search without a submit button without the site being ranked lower than if it had a search button?
You have to read WCAG Success Criterion 3.2.2 On Input
The first technique proposed is G80: Providing a submit button to initiate a change of context
But there's another technique which would not require a submit button:
G13: Describing what will happen before a change to a form control that causes a change of context to occur is made
TLDR: yes, but.
Its usually considered good practice to have a 'fallback' scenario. Say, for instance, the user is not using JS (god forbid) or if the user is using a screen reader of some sort - the search box should direct the user to a new page with listed results.
A helpful guide to building accessible sites can be found at (https://www.w3.org)[https://www.w3.org/TR/WCAG20-TECHS/]
I have had 2 different display from a website that is shaped like a tab menu. For the first tab menu, data displayed does not require pagination, however for the second tab menu, data displayed requires pagination because the amount of data a lot.
How to display both of the data if the first tab menu did not need the presence of pagination and the second tab menu need pagination ??
Give me any suggestions step to resolve this.....
Either build pagination the normal way (with page refreshes, see the links in the comments to your question) and save a parameter to know that you're busy in the 2nd tab, or use ajax to load the paginated data in the 2nd tab. This requires you to build an api like functionality to obtain this paginated data as json and build the page with javascript. From the api you would call a method on your model that uses LIMIT and OFFSET to get the right data section.
I have a bit of a unique challenge today. I have a client that wants to be able to search for multiple items based on inserts into a cfgrid. Suppose we have the following web form:
A Country selection dropdown
A State Selection dependent AJAX dropdown
A city Selection dependent AJAX dropdown
An ADD Button
----------------------------------------------------
A CFGRID that will populate a row with selections when the user clicks the add button
----------------------------------------------------
And finally, a CLEAR button, and a GO button on the bottom.
The resulting page will then query the database and get some statistics about the cities selected. So, suppose an individual picks USA > Arizona > Scottsdale and USA > Arizona > Flagstaff. The grid below the options will 'save' each selection and reset to their default options, waiting for a user to pick additional options or click on 'GO'.
The resulting page will then generate columns that list some statistics about the communities and highlight the 'best of' between each selected community.
Each time a user selects the ADD button (assuming three criteria are selected) I want the information to be added into a CFGRID that displays the options selected. Then, After the user selects at least one country/city/state option, have all of the data in the CFGRID get passed to another page that does a query from the data selected. In theory, the user could pick as many communities as they want, assuming they are willing to let the database sludge through enough data to get what they want and wait through a 'loading' screen to get it.
I'm having these challenges, in no particular order:
- I have an HTML grid that I must use per client spec (No Java or Flash, must be HTML)
- I have no idea how to get the selected options into the CFGRID. I assume there is some JavaScript I can write that uses some sort of AddRow function to add data into the grid with the add button but cannot seem to find how to it on the interwebs
- After we conquer the above challenge, how do I pass the data from the grid into the results page? I thought about passing one big string or a structure, but I'm not sure how to do that through the URL or posting, nor how to get the data out of the grid. I wonder if I am better off coding some sort of string that gets passed from the options page to the results page with a get method instead of dealing with the stuff in the CFGRID and have the CFGRID serve only as a 'dummy' display container.
- Finally, after the pass is complete, I would need to loop through through the structure and perform a CFQUERY or CFSTOREDPROC on each row of data, then get the statistics I need to display on the results page. I assume this would depend on how I am getting the data from the options selection page to the results page.
THANK YOU ALL!
CFGRID is great to start, but it can be b*tch to customize and extend... Have you tried editable CFGRID with bind? See how far off it is from what you want first. If it turns out to be very far, then you might want to go for a jqGrid and code up some jQuery.
To start, read Using HTML grids and make the cfgrid editable.
http://help.adobe.com/en_US/ColdFusion/9.0/Developing/WSc3ff6d0ea77859461172e0811cbec22c24-7a01.html#WSc3ff6d0ea77859461172e0811cbec22c24-72e0
Once you got that working, look at these provided JS functions that you can use with CFGRID
http://help.adobe.com/en_US/ColdFusion/9.0/CFMLRef/WS0ef8c004658c1089-6262c847120f1a3b244-8000.html
http://help.adobe.com/en_US/ColdFusion/9.0/CFMLRef/WSd160b5fdf5100e8f-4439fdac128193edfd6-7f5f.html
If you still demand a bit more, you might need to dig into the underlying ExtJS component. At that point I would rather use jqGrid
I found out that the best way to handle this was by using a SerializeJSON call and a Deserialize JSON call back and forth. By using JavaScript notation we are able to pass a complex JavaScript object (array) between one page and another. This has the value add of not having to worry about sessions timing out and making URLs clickable from one solution to the next.
I know that you can capture the event when a person clicks a "like" button from within a Facebook tab via the edge.create method, but what im wondering is if there is a way to capture when the Facebook like button at the top of a page is clicked, the purpose being to be able to find out which tab within my fan page is generating likes.
When the page reloads i will know that the page IS liked, but i dont know if the like was generated from one tab, or another tab on the same page.
The only solution I can think about which is sufficiently accurate is the following:
Start a session on server side with the first app request.
Remember the like state from the signed_request and the timestamp when it was issued.
Embed a javascript interval in your tab app(s), firing an AJAX request to your server every couple seconds. I think you have go with something between 2 and max 5 seconds.
The AJAX request refreshes only the timestamp in the session.
If the user clicks like on top of the page, now, the whole facebook page gets reloaded - so does your app and you get a new signed request which has the liked state now set to 1.
Have a look at your session > was the state 0 before? Yes? Is the timestamp max. 6-10 seconds old? Yes? Well, its most likely then that the user liked the page while being on the tab.
I hate the solution with the AJAX interval polluting the network (and on a big site with many users this will stress your server), but I can't think of any other solution, because there is no other way to keep track if the user is still looking on your tab. If the interval is too high, the user would be able to navigate away to the wall or info section and like the page there. If he directly returns to your tab after this, you wouldn't be able to track if he left the tab at all...
Another solution would be to listen for the body.unload event and fire a AJAX request to the server, telling you that the user has left the tab, but it is possible that the event never gets fired on certain browsers or the AJAX request is not fast enough to be processed before the tab page unloads. On the other hand would this solution take way less resources of both the users network and your servers performance.
This are just theoretically solutions and have to be tested, first!
I think this could be accomplished like this:
When the like button on top of the page or on the left side are clicked, facebook refreshes the currently displayed tab.
You can capture this refresh if you record the like state from the signed request, and when a tab transitions from not-liked to liked you can count it as a conversion.
This should work, have never used it, and it's better then nothing. You will probably need to add a limit on the user ip address to prevent unlike/like events increasing the counter.
Good luck, and please post here if you find a better solution, this can be interesting.
I am familiar with several approaches to making the back button work in AJAX applications in various situations, but I have not found a solution that will work gracefully in my specific scenario.
The pages I am working with are the search interface for a site. You enter terms in a normal search box, click "go and wind up at a search results page. On the search results page there are a ton of UI controls for filtering/sorting the search results to find what you are looking for. Some of the operations triggered by these controls may take a (relatively) long time to complete (e.g. several seconds).
This latency is fine in case where the user is initially filtering/sorting their results... there's a nice AJAX spinner and so on... however when the user clicks on a search result and then clicks on the BACK button, I would like the page to instantly be restored to the state it was in when they clicked through.
I can restore the states using IFRAMEs/fragment identifiers as a dictionary of page history, but what ends up happening is that when the user first hits the back button the initial page is loaded, then it (re) makes the AJAX query to get the page state back, which triggers the AJAX spinner and another wait of possible several seconds.
Is there any approach that does not require this kind of two-stage load of the page when the user returns to the page via the BACK button?
Edited to add: I am partial to jquery but I'd be happy with solutions that depend on other libraries/toolkits or that are standalone/raw javascript.
Edited to add: I should've added that I'm trying to avoid cookies/sessions because this prevents people having multiple brower windows/tabs open and manipulating different sets of search results at the same time.
Edit: Matt, can you elaborate on your proposed solution (triggering a page change event via fragment identifer)? I see how this would help with BACK button clicks across the same page but not coming BACK to the search results page after clicking on a specific result.
Just use a cookie.
Have you investigated the YUI Browser History Manager?
Try to use localStorage object. Here is crossbrower libs jStorage and WEBSHIMS json-storage
Would it help to trigger a page change event using the "Add some info to the # at the end of the URL approach".
That way, clicking the back button shouldn't actually change the page, and you should be able to restore state without the first page load.
Use something persistent that is tied to the user's profile.
Cookies and sessions are good ideas, but you can also keep those stuff in the database. That gives you an added advantage of being able to save the user's filtering preferences accross different browsing session.(if, for exampple, he was looking for something in the office and then decided to continue searching when he is back at home).
It all depends on the complexity of the filters and weather or not it is something you think that the user will want to use accross diffrent browsing sessions..
Edited to add: I should've added that
I'm trying to avoid cookies/sessions
because this prevents people having
multiple brower windows/tabs open and
manipulating different sets of search
results at the same time.
You can create a random token and assign it to the fragment identifier.
on first page load create a token if no fragment identifier is set
before navigating out, store all the temporary ajax data in a cookie with that token as index.
when hitting back, if you have a fragment identifier set, load the data from the corresponding token in the cookie.
you can even add a "time" field to expire tokens, etc...
sample cookie (JSON):
{"ajaxcache":[{"token":<token>,"time":<time>,"data":<data>}, ... ]}