I'd like my users to share some content generated on the server, but would like NOT to generate that content before user clicks the Share button.
There are three routes to take:
a social button - I need some kind of event before the popup opens since the data is still not there. Is there such an event?
add button/link that fetches the data and then calls FB.ui({ method: 'share' ... }) - when FB.ui() is called, the browser asks the user to allow popups from the website because it's no longer user-triggered. Is there a way to use the fact that the user clicked the button in the first place?
make the user click a button to submit the info I need, get the results and only then display the Share button with the data from server - seems the default way to go but hits usability by making the user press 2 buttons (and wait in between)
I DON'T want the user to give the app any permissions (and then share directly via the api), it's too much for what the app is doing.
So the question is:
Is there a way to implement the functionality using route 1 or 2, or is there a better way, or is 3 the only route to go?
Related
I am writing a Single Page Application in JavaScript. The URL changes but there are no page reloads.
In my app I have a browser-like navigation with a back button, that actually runs window.back() . I also keep a backCounter variable (increased every time a user clicks on a link or goes back, listening to popstate) to make sure that the app back button doesn't let user go a blank tab.
I realise that ther are security implications when reading the history, and I have read answers here about it.
Question: is there a reliable way for me to know when the user has pressed "back" within the same SPA? I can think of two possible paths:
Neutralise. I could maybe neutralise the function of the back button by forcing a specific location on popstate
Integration. I would love to be able to know if the user has clicked on back or forward so that I can update backCounter accordingly.
...ideas?
Ok so I have no code to show you guys since I have no idea how to even do the code for this but what my client wants is whenever changes or updates are made to a specific page on our website (we use Wordpress), that page's link in the navigational menu will blink.
So basically: page gets updated ==> link in menu blinks ==> link stops blinking when user clicks on page and views it.
There's lots of website change trackers out there but they only do email notifications. My client doesn't want email notifications. He wants the page link to blink in the menu.
Any idea on how to do this? Some sort of jquery or javascript code?
Your two options are a push or pull notification. Using push, you would implement web sockets so the server will push the update flag to the client that will allow the menu link to blink. Using pull, you would have to implement a timer method that periodically checks for updates. When an update is found, it no longer checks until the user clicks the link. There are many ways to implement, but that is the basic concept. Good luck.
Edit: just to clarify the pull method, that will be implemented client-side. A basic JavaScript timer is used and when triggered, you would perform an ajax call to your 'CheckForUpdates' method.
I am creating a web application.
I have a landing page which the user sees after logging in.
From the landing page they can click a link to go to detail page.
The detail page loads data for the default id to start with. It also contains a drop down for user to pick a different id. When user presses submit button it makes a get request to the same page, but uses the optional argument id=someID this reloads the page and shows the data for the newly selected id. All of this is working correctly.
My question is, if user chooses a few different ids from the drop down and clicks submit to view their data, now if he wants to get back to landing he has to go back through each id that he viewed. I would like to know if it is possible to set it up so that when they press back button they will go directly to landing page no matter how many times they've chosen new id's to view data for.
Here is the flow I'd like to achieve:
/landing -> /detail -> /detail?id=1 -> /detail?id=2 -> [press back button] -> /landing
Have the requests on the details page pulled in via ajax. You have to do some refactoring so that on a successful request, the information it receives will repopulate like a content block, but this will allow the information on the details page to update without you actually navigating to a new page. Then it'll leave you the ability to press the back button to go back to the landing page.
If you're already using a way to catch the amount of id's requested:
<INPUT Type="button" id="back" VALUE="Back" onClick="history.go(-"number of id requests");return true;">
I need to get the status of a twitter "follow" button on load, not on click.
I'm currently loading the button via ajax, and call twttr.widgets.load() to get the widjet.js to do it's magic.
I am aware of binding "follow" and "unfollow" to accept the callbacks from clicking the buttons, but how do I detect the current state of the button before any user interaction?
For instance, the page loads and the user is signed into twitter and currently following the target of the follow button, so it appears that they've already followed the user.
How do I detect this with javascript/jquery? I am not authorizing them through twitter at this point, so I can't check via their api.
Other attempts:
I've also tried getting the contents of the iframe via javascript,
since the twitter follow button iframe has a class specifying the
state of the button, but it doesn't seem to be possible due to CORS.
I expect the answer is you can't.
The twitter follow button is in an iframe expressly to prevent you from accessing it and obtaining information they don't want you to have.
Facebook operates similarly. The like button is in an iframe, and therefore you cannot use it to determine if a person has 'liked' a particular page. That information requires permission from the user.
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()">