I am building a small web site, and on one of the pages there is a d3.js/highchart visualization demo. The visualization is interactive, and can be modified by the user.
When the user leave this page and enter another html page by following a link in this demo page, the content of the page is not saved, and when he comes back, he has to modify the chart again. My question: is there any way to cache this demo page so that as long as the user does not close the browser page, it can be recovered?
My simplest idea is to have each client page a unique ID. So that I will save the status of the page when the user leaves, and when he comes back I can cover its content based on this ID. Then the question is how to implement this ID for client pages.
You can use History API here.
When a user changes the state of the chart, the page URL is updated with all the parameters needed for rendering the chart (via history.pushState call).
On page load you get the initial state (chart parameters) from the url and render the chart correspondingly.
A good thing with that approach is that you even can send such URL to another person, and they will see just the same customized chart.
You could also try storing the page state locally using either sessionStorage or localStorage (DOM Storage guide)
If you have two or more tabs I don't think there is a way to differentiate between then once they are closed. I would use Steve's idea about storing the ID in DB+cookie and when user come back to page I would provide them with a list of all their past modified charts based on cookie and DB query. Then they can choose which chart they want to reopen.
I can think of many ways to do something like this.
If it was me, I would simply store the users chart settings in a cookie, so when they navigate back to the page, you can simply read the cookie for the settings and use them to re-display the chart.
If you want to persists this longer, then send the settings to the server to be stored in a DB. The server can return a unique ID which is then stored in a cookie, or simple use the session cookie to associated the chart settings with a session.
An alternative which doesn't use cookies is to add chart settings to the 'back' url when you navigate away. When the user clicks to go back, the url contains the information necessary to restore the chart states. However, this doesn't work if they click the browser back button.
Related
Description
I'm using React.js with server side rendering using Next.js framework
I have "Search" page, which state is initialized using getInitialProps (loads data from API server), and "Object" page.
User can navigate from Search page to Object page, using simple <a> tag.
On search page user can filter data, each filter do new API request and recieve new data.
The problem
After filtering on Search page, user click on item and goes to Object page. Then user clicks browser Back button.
What is now - I got the same search page which was on first load without filtering. Can anybody explain how it is restored and what exactly is restoring?
What I need - I need restore html and state which was after filtering.
How can I achieve this?
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...
If I use ajax to change specific portions of the page, like a content section, which warrants a new URL (and requires one specifically for favoriting, or refreshing), is there some magic that I am not aware of that allows the user to click the back button and reload the content that was just there?
Or do you have to re-retrieve the data based on stored variables using popstate
Thanks!
I have a little web app (which only has 1 page) that allows user to input and select some options. The input texts and selections will be displayed in another div in the form of table. You may want to refer to the example here: http://jsfiddle.net/xaKXM/5/
In this fiddle, you can type anything and after you clicked submit it will get the text input and append them to another table #configtableTable
$('#labels #labelTable tr:last').after(addmore);
$('#configtable #configtableTable tr:last').after(displaymore);
I'm using cherrypy as a mini web server (and thus major codes are written in python) and i know that it has session here but i have no idea how to use it at all as the example given is not really what i want to see.
FYI, i'm not using PHP at all and everything is in a single page. i simply show and hide them. But I want the page to remain as showing #configtableTable and hiding #labelTable even after refresh. Note that the fiddle is just part of the web app which will only show all these after getting a reply from another device.
Not sure about cookie because all the links i've found seem broken. How about jQuery session? Is it applicable in my case? I need some examples of application though :(
okay, to conclude my questions:
1. can i save the page state after refresh? and how? which of the methods mention above is worth trying? is there any examples for me to refer? or any other suggestions?
2. can i simply DISABLE refresh or back after reaching a page?
Thanks everyone in advance :)
Don't disable Refresh and / or back navigation. It's a terrible idea - user's have a certain expectation of what actions those buttons will perform and modifying that leads to a bad user experience.
As for saving state, while you could use session or cookies, if you don't need that data server side, you can save the state on client side as well.
For example, you could use localStorage
Alternatively, you could create an object out of the data in the table, JSON.stringify() it and append it to the url like this: example.com#stateData.
In case of either option, at page load, you'd have to check if there is state data. if you find there is, then use it to recreate the table, instead of displaying the form.
The disadvantage of the first, is that not all browsers support localStorage.
The disadvantage of the second is that URLs have a length limit and so this solution won't necessarily work for you if you're expecting large amounts of data.
EDIT
It appears that Midori does support most HTML5 features including localStorage however, it's turned off by default.. (I'm trying to find a better reference). If you can, just point Midori to html5test to see what HTML5 features it supports.
I use a small JS to mark entries as Read upon click, before the user goes to the entry page.
When the user clicks Back, the removeClass I used doesn't seem to keep its effect.
Is there a way to force this on Back behavior?
IE 8, Firefox and other browsers remember form entries on a back button press. You can use this to store some state in a page for when the user hits refresh or back.
Create a hidden textarea on the page somewhere and store your extra state in there. I use onbeforeunload to stash the state and then pull it out again with onload.
Unfortunately IE6 and 7 don't support remembering your form values on back or reload, so you would have to resort to something like cookies if you care about those browsers. Remember to keep the amount of data you store in the cookies small since it will be sent to the server on every request. You will also want to have some way of clearing out that cookie.
When I want to keep a large amount of disparate state, I use JSON.stringify from Douglas Crockford's json2.js.
When the user clicks Back, the browser reloads the page from scratch (except Firefox, which remembers form values), and the old page's Javascript and its effects are gone.
To work around this, you can persist the page's state in a cookie, then read the cookie when the page loads and restore the state, using a Javascript cookie library.
As suggested, you can use cookies. Or if you don't want to do that, you can store the info in hidden form field(s), and on page load (or domready) read the value and set the page state as necessary.
The only way to do this with JS is by storing a cookie with the items a user accesses and mark the entries in the cookie as "visited" when the page is loaded. The drawback is that there will be a small delay between the items loading into view and them being marked as visited (kinda like the one here on StackOverflow with a user's ignored and favorite tags).
Other than this, you could use some server side code to remember the visited entries in session.
If the entries are <a> elements, you can style them with:
a:visited {}