I'm creating a infinitely scrolled page that recursively loads and append the next page's content into the current page. I think the browsing experience can be great and immersive but the current method is not without usability drawbacks.
Incomplete progressive enhancement. It is always good to support the back button and provide deep linking when using Ajax. The current implementations of infinite scroll does not support this. There is no way a state can be bookmarked.
Some ideas on improving the UX of infinite scroll. Need opinion.
Change the URL hash with each load, e.g. /!#/2 -> /!#/3
Clicking the back button should scroll the page upwards. Clicking forward button should scroll it down.
Accessing a deep link should behave like it was before Ajax. Going to and also starting at page 3 should show only page 3 content and not page 2 and 1, since the user is not asking for them.
There should still be a way for him go to page 2 and 1, like if it was regular pagination. Since page 3 is loaded with scrollTop at 0, the scroll up event is not useful. For this we might still need a clickable link.
We need to check if the requested page number is greater than the current because we should not loaded page 2's content at the end of page 3.
What do you guys think?
Interesting question. I would suggest changing the URL hash in the form of #!/from/123/to/456, and increase the to ids as page loads.
Whether you are using hash or History API rewrite to modify URL, in UX sense, URL always represent the location of current content. For example, user will expect a bookmark, hitting reload, or copying the URL to other computer and click Go, will return the same page.
The only way for your infinite scrolling page to complete the logic of URL is the URL hash I suggested above. Otherwise just leave it; Twitter doesn't update URL hash on their home page.
Related
I have a single pager website where each of the buttons takes you to a separate section following an animation. I've set up an example here: https://dev.dport.me.
Currently when you navigate to a page, the URL stays the same. For example, navigating to the About section does not append #about to the URL. I would like the site to work more like a normal site in respect to navigation.
What is the best way to go about making it such that:
Navigating to a "page" changes the URL. Following the example, either to #about, or even better, /about.
Navigating directly to a subpage works. Meaning that if I navigate to https://dev.dport.me/about, it takes me straight to the subpage.
The back button works. Currently if you navigate into a subpage, you must use the back button on the page. The browser's back button just leaves the whole site.
Is there some pre-existing javascript library that does what I'm looking for? Or am I going to have to gun it alone, perhaps with something like this.
I think this question was asked in a similar form before but I didn't get a clear understanding how to implement it properly.
I have a site, which has different pages on their own urls, like '/contact', '/about', '/products'.
What's the technique to put a top bar on the top like this one http://nanobar.jacoborus.codes/?
Here is what I need:
User clicks a link on the page.
JavaScript handles the click, shows the progress bar, starts growing it then passes the event to browser.
Browser starts loading the page. At this moment, page clears and becomes white and blank.
As the progress bar was in some position that is not zero, say, 63%, and now there is no information on the new page about where it was.
So, I can technically run some function on every page, like showGrowingProgressBar(value), but since I don't know where it left, I cannot put it in the same progress state as where it left.
How do I make it look natural, like the user didn't leave the page, but more like an SPA experience?
I guess you want to build an one page web application where things load in the same page without refreshing.
You can use AJAX to do this. you can populate a particular div with the new html without refreshing.
It can be handled more easily using Angular JS. You can define routes for every page and can also have templates for different page, and can load that template when user clicks on the link. It will just replace the container div with new html codes and you can also handle the urls easily.
Turbolinks seems to be what you are looking for. It dynamically loads your pages and shows a loading indicator.
Turbolinks makes navigating your web application faster. Get the performance benefits of a single-page application without the added complexity of a client-side JavaScript framework. Use HTML to render your views on the server side and link to pages as usual. When you follow a link, Turbolinks automatically fetches the page, swaps in its , and merges its , all without incurring the cost of a full page load.
Your approach is:
User clicks a link on the page.
JavaScript handles the click, shows the progress bar, starts growing it then passes the event to browser.
Browser starts loading the page. At this moment, page clears and becomes white and blank.
As the progress bar was in some position that is not zero, say, 63%, and now there is no information on the new page about where it was
Your approach should be:
User clicks a link on the page.
JavaScript handles the click, browser starts loading the page. At this moment, page clears and becomes white and blank.
New page shows the progress bar, starts growing it then passes the event to browser. The growth can be picturized by the no. of API call completed divided by total no. of api calls, required for that page.
Facebook has two ways to display somebody's timeline: starting from the very top, showing the full banner, and semi-scrolled, so the banner is cut in half and the profile picture is very close to he floating navigation.
However, the semi-scrolled state seems very natural, there is no delay. The page does not suddenly jump when the content is loaded.
How is this feature implemented in general? Simple window.scroll seems not to be cutting it as it's too slow (has to wait for the content to load to actually have something to scroll) and rather hinders user experience.
You assume in your question the initial loading of the page. That assumption is wrong, because the "page", so to speak, is already loaded.
When you are visiting one facebook page, and then navigate to someone's timeline, it's not a full page refresh in the browser, switching from one page to another. Rather, it's all done via ajax. The "previous" page is not really unloaded by the browser, and the "next" page is loaded via ajax.
As for the url changing, that's a different topic (history pushState).
I have a page where navigation is handled by hiding and showing preloaded divs when users click on links. But, the users think they've actually changed pages, so they click on their browser's "back" button trying to go back to the div that was previously hidden. But of course, they go back to the page from which they came.
What's the best way to handle this? 90% of the traffic is from a login page. Should I just sandwich a redirect page in between the two? How is this done? Can I just change the browser's back button behavior?
If you are already using jQuery, why not simply add a history manager like jq-bbq or the hashchange or history manager? (Or, if you want to really go all out, switch to a MVC JavaScript framework like Sammy.) That way, the back button will work as the user expects, rather than hacking around their expectations by blocking the back button or throwing in redirects. (Unless you have a good reason to, of course :-) )
If you use a browser history plugin like the jQuery UI one you end up changing the history so that the back button doesn't actually unload the page.
http://yoursite.com
-> User clicks something
-> new address bar reads http://yoursite.com/#/something
because of the hash mark when user goes back it goes back to http://yoursite.com which should inturn fire your show previous div function
read more about the available history manager plugins available for jQuery. There are quite a few. Most if not all provide available callback functions that you can specify.
On change of the state of your page, write a unique set of parameters to the hash of your URL. You can change this via JS without causing the page to reload.
Set a timer on the page that checks the current location hash repeatedly, and if it changes (i.e. the user presses the Back button) then update the state of your page to match the URL.
I have this scheme working to great effect in a local application.
The jQuery Address library is another great alternative.
http://www.asual.com/jquery/address/
You can set the URL for different application states, and get the URL 'parameters' when the page reloads.
Two ideas:
1) onbeforeunload. Ask the user if they want to really go back.
2) Sandwidch a redirect page. Login -> redirect -> your page. A single back click would take the user to your redirect page.
The second is kind of a pain in the neck for people who know what they're doing though. I think the Back button (and all standard navigational elements) should be messed with as little as possible.
I would go with onbeforeunload:
function sure()
{
event.returnValue = "sure?";
}
...
<BODY onbeforeunload="sure()">
I'm using an iframe to display content that has links. When the user clicks around in the iFrame and hits "back," it goes back in the iFrame. This behavior is OK. However, once they're back to the first page of the iFrame and they hit "back" again, the entire window is taken back to the previous page. This is unwanted.
To prevent this behavior, I've put a fake "back" button within the iFrame. (In most cases this is bad UI, in this case, it works well). I'd like this fake back button to only go back if the previous page is the iFrame's page -- not the entire page. When they hit the fake back button in the iFrame, it should only move that iFrame back, nothing else. Is there a way to do this? Does an iFrame get its own history object?
Something that might be of benefit: the domain of the iFrame and the main window can be assumed to be distinct. So, if it's possible to read the "global" history object, I can check to see if the previous page was mine by checking to see if the domain is mine. If the domain is not mine, the fake back button will be hidden or not do anything.
Help greatly appreciated, and happy holidays!
document.location.href = document.referrer;
You should be able to use the javascript history object to push the user back; but you won't be able to stop it when the iframe-clicking runs out and the main page wants to go back. And you can't stop it because that's intentionally locked down pretty well in most browsers to prevent people from messing around with it maliciously.
You could write your own history tracking code and have the back button pop items off that stack, stopping when the stack is empty...
If you're using some complicated nesting of links - perhaps some javascript-based tree menu? That way the iframe never has a page refresh?
Without having an example, I have to say your design seems like poor UI... when I hit back, I don't want the navigation to change; I want to go back to whatever page I was just on.