On my Single Page Application (Javascript (AngularJs) webapp), I'm displaying a paginated items list.
I'm displaying 10 items per page.
In order to retain the current pagination opened by the user at any time while this one navigates on other page, I put the current page number on browser's localStorage.
Here's an example of workflow:
The user goes to myItemsList.html.
He opens the page 2 involving the url: myItemsList.html?page=2.
Then, he goes to another page: myOtherPage.html.
He goes back to the link initially pointing to myItemsList.html, that displays directly thanks to localStorage the page myItemsList.html?page=2 in order to potentially continue his navigation.
Would it confuse the user, maybe expecting to see the page 1 as a new starting navigation.
If I display at the top of the list, a kind of label like "Page 2" in order to warn him that he's seeing the preceding portion of his navigation, isn't it UX-friendly?
Or should I completely avoid persisting current pagination?
Here's what could happen if I don't persist the current viewed page:
The user goes to myItemsList.html.
He opens the page 2 involving the url: myItemsList.html?page=2
He opens an item in this page (the "show" page), leading to: myItemsList.html?id=123
He clicks on the browser's back button, causing a refresh of myItemsList.html (since a Single Page Application). The current pagination (page 2) would be lost and the user would need to restart it in order to continue its items discovery.
This seems really touchy...
What strategy should I choose for a use case like this?
saving the progress through navigation is the expected behavior in UX design of SPA, so maintaining the page he was in the correct choice, and since it is a pagination it won't be an issue even if the user wants to go back to any page, it will only take a click.
First of all I would avoid using localstorage and use a service instead to persist ur page counter.
Secondly u dont need to persist pg counter to anywhere else but in a scope variable for refreshing to mext page data. You can even think about just adding to results similar to infinitite scroll use cases. But either way, u can use local scope variable for pagination.
Whether to go directly to last viewed page - is a more business decision and will depend on needs.
But u can very easily persist or remove persisted data using broadcast and watch and decide on persistence based on event listened to.
Hope thos helps ...
How about maitaining a sort of heirerachy in JS like this :
Suppose a user navigates to a section called Customer Search
customer_search.customer_display.page = 2
Where customer_search is the a subsection , customer_display is the view with pagination you are targetting .
menu.menu_items.page=7
Where menu is the subsection , menu_items is the view with pagination
Might work if your application is organized in a reasonably hierarchical manner .
Probably you could also maintain the page in $scope for that particular controller .
The URL should dictate the navigation.
When I navigate to your website, e.g. example.com, I expect to be on the first page.
When I navigate to a (bookmarked) page of your website, e.g. example.com?page=2, I expect to be on the second page.
When I hit the back button, I expect to be presented with the previous page exactly as it was when I left it. You don't need to refresh the entire page, just listen to the history events and update accordingly.
And I strongly believe that this question doesn't belong to stackoverflow...
Related
I have the following flow:
HOME => DEVICES => ADD NEW => SELECT TYPE => PAIR
Users can of course go back at any time. Now after pairing is complete I go to the DEVICES index page again.
When a user presses the back button on that page, it returns to PAIR (which I don't want), I want it to go to HOME.
I've looked at ReplaceState on the final step which changes the PAIR page by the HOME page before redirecting to DEVICES. That way when the user presses back in the DEVICES page he/she comes back at the home page (great!), however when the user then presses BACK again he arrives at SELECT TYPE which I don't want.
How can I accomplish that when the PAIR is done, the ADD NEW, SELECT TYPE and PAIR page are removed from history?
Side note: I'm using Turbolinks and Rails, although I believe the answer would be JS.
AFAIK, you cannot delete from browser history. But you can prevent saving history by location.replace (see https://stackoverflow.com/a/21820194/4486609) or do another mad thing like turning off back button at all, but...
if you have classic web app (not SPA) then you have some system to prevent user jump to abitrary step at your wizard, and if you have it, it is already solves such problem, isn't it?
First, Thank you for watching this question!
I'm newbie to angularJS and i'm trying to make pagination to be more flexible to use.
Below is my situation.
I made pagination function
It works as my intention
But, When i get into other page(leave list page which includes pagination function), and try to go back, the problem appears!
(Here is what i want to solve) I go back to list page by clicking backspace key or clicking back button on view. and the params i entered in list page is gone!
In multi page application, the url can be '/tt?aid=11&bid=22&cid=33', and i get into detail view page, and i can retrieve to '/tt?aid=11&bid=22&cid=33' by just clicking back button. but in angularjs, it goes back to list page with no params.
And below is what i tried to solve above problem.
I used local-storage-service
I used onPageUnload event(of browser)
I'm not sure if this best fits.
Store the page no.
When you click back to get that list, feed that page no.
page no can be stored in a scope variable.
Your pagination function should be able to give the list based on page no.
Assuming I have an arbitrary point in my history (the point someone lands on my page), I would like to push some states as they do certain actions, and then when they are done I want to go back to the history point they were at when they landed on the page. So if they press forward, they are starting the actions again, and if they press back they go back to wherever they were before they landed on my page.
Now the problem is when I push states and then at one point they press back. E.g.
landing page
push state 1
push state 2
back
Now at this point if I want to return them to the landing page I only have to go back once (as opposed to twice). How do I calculate how far to send them back using javascript? It seems that history.length is pretty inconsistent, and using history.js' saved states doesn't work since a state gets added to that regardless of whether I use push state or whether they click back.
Any help is appreciated.
If you want to go to a particular url,just redirect to the specific url using window.location.replace(url).
In your case, on all page loads,increment a counter which is kept in session variable so it is not lost between postbacks and use it window.history.go(-count) to go back.
For further reading-
http://www.aspnettutorials.com/tutorials/database/hit-cntr-asp4-cs/
I'm new to ASP Web Pages. Trying to build a shopping like website. I have created Databases first, Now what I want is to display "some" items of users' interest only so as to keep page light. Later when user scrolls down, next "x" number of items are fetched from Database and are shown to the user. Its like something you can see on myntra.com, but definitely not like on ebay.com where number of items are fixed on one page. I know it will use javascript but can't figure out the correct timings of firing events and adding more items to page?? I saw on stackoverflow itself about scroll down event, but I think that was related to a particular ID on a page.
Here's how it's done on the client side:
http://www.youtube.com/watch?v=eziREnZPml4
In addition to that, you will need some server-side logic that will track what has been sent already, when a request for more contents comes in. One way you could achieve that is to always read the items in the same order, and have the browser send the "latest" item that it has with each subsequent request.
I have a bit of an interesting situation.
I have an application that uses an MVC framework to deliver the view to the user.
This is great for the overall design perspective.
There is a wrinkle though.
At certain times a user could be doing something on a page and they would be required to go to another page to perform a look-up service. I need to be able to uniquely identify each page that they go to and I am not able to use the URL, because all the subsequent pages that I visit from the parent page have the same URL.
Just an fyi, I care about this because I'm attempting to store the last known scrolling position on each page in cookies.
Example -
They are working on Page A.
They click a link from A and they are taken to page B.
On Page B they enter some values and click Search which will query a DB
A list of results is returned.
They can then select to "Return Value" of one of those search results.
The value is then returned to Page A.
When I run the following on each page (A and B) -
alert("${channelUrl}");
They are an exact match!
What else can I do to determine what page I am on within my javascript without resorting doing any sort of server side AJAX calls etc...?
Is what I am asking even possible?
Currently I am attempting to solve this problem by counting up the number of text fields on the page and appending that to my cookie name. This is not ideal, especially if a user visits a page that happens to have the same number of text fields.
Thanks.
One common way to handle this sort of thing is to open the second page in a new window. With this approach the parent and child windows know which is which (the child refers to parent as window.opener, and the parent refers to the child via the return value of the open call) so there's no need to manage URLs or anything to keep track.
People often use the part of the url after # to keep track of where you are under the a single URL. This is built-in supported with My Section which takes you to the element with id "my-section", but you can use libraries that take control of this section of the URL in other ways.