I need to capture telemetry information that captures details such as when the user opens a form, closes it or navigates away from the form.
To do this, I have javascript calls to a telemetry api. In the case below, when the user navigates away or closes the tab, I would like to trigger "mymethod" which will call the api method to capture this event.
I am trying to trigger a javascript method when the user navigates aways from the form. I have this script which is on the CRM form. The below code does not work.
window.onbeforeunload = function() {
console.log('onbeforeunload triggered...');
mymethod();
return true;
};
Ideally I would like to be able to detect when the user navigates away from the page, or closes the page. Any suggestions appreciated. Thanks in advance.
This will probably never work - that type of code within CRM is unsupported.
Microsoft Dynamics 365 and the importance of staying supported.
Microsoft provide a set of tools and guidelines describing the things
we can do, they also tell us the – unsupported – things we shouldn’t
do. It’s all on the MSDN. Un-supported scenarios that commonly occur:
All JavaScript interactions within the application pages must only be performed using functions defined in Xrm.Page & Xrm.Utility
namespaces, i.e. don’t directly interact with the page DOM.
I would suggest asking a new question which focuses on your end goal. You have told us something that doesn't work (but we wouldnt really expect it to) - you havn't actually told us what you are trying to achieve.
Related
We've ran into a weird edge case in our checkout flow where, after we create the order via the API and launch the PayPal window for the user's approval, they are able to escape out of the checkout flow somehow without triggering the onCancel callback.
We're contacting some users to figure out exactly how they did this, but we've been able to reproduce it by simply closing the original (parent) window while the PayPal window was still open. As far as we can tell, this or some other very similar situation (like a power failure) is the only way to hit this edge case.
Is there some sort of best practice for handling this situation? Obviously we could have some sort of chron job which looks for old non-accepted/non-canceled orders, but we would prefer some way of addressing them imediately. I've found docs for the beforeunload event. Should I just cancel the order with that if the page is closed?
There are many potential situations that can lead to an order not being approved by a payer, such as the power failure you mentioned or a window being left open forever with no action, or a browser crashing. Nothing about your business logic should depend on onCancel ever being called.
As for handling such a situation, simply don't capture such PayPal orders. They expire on their own. Your own system's record of the payment attempt / cart order can expire when you want it to.
I don't understand how does ECMAScript works. Check on MSDN and other forum it didnt tell us which version or values equal to javascrpt.
if (!Request.Browser.JavaScript)
//Do Something.
However, I was given a warning of obsolute and recommend me to use ECMAScript instead.
System.Web.HttpBrowserCapabilities myBrowserCaps = Request.Browser;
if (((System.Web.Configuration.HttpCapabilitiesBase)myBrowserCaps).EcmaScriptVersion.Major < 1)
//Does not have Javascript. Do something.
However, I tried both on/off my javascript. Somehow the function was not fired. I suspect certain values belong to javascript. However, I cant find anything related to value == javascript.
I understand I could a Then perform a redirect using meta tag. But I would like all these code to perform at the server.
First of all, see Should I bother to develop for JavaScript disabled? / How important is graceful degradation of JavaScript? .
Then, client-side Javascript only exists in the client and if it's off, no client-side logic will fire to check anything explicitly. So you cannot know it until the client sends at least one reply from your page (be it a GET/POST query or an XMLHTTPRequest) - i.e. only after the second request from that very user, generated by the very page you sent them, which may never occur if they just lurk around, even if you make every link on your page a form reply - they may use URLs from an external source. A CodeProject article linked from Check if javascript is disabled? is one example of such approach.
For this reason (and to avoid effort duplication to make both script and noscript versions - the practice that saw some use in the past), the best practice appears to have become making pages and frameworks JavaScript-agnostic and just warning the user with <noscript> that the page may not be fully functional if it's relevant.
E.g. Sharepoint does just that - with JS disabled, a warning appears on top while on the page, there are e.g. no scrollbars and editing is disabled completely. Which leads to conclusion that ASP.NET controls (which SP makes heavy use of) weren't designed to be functional beyond basic display with JS disabled in the first place.
I want to implement a 'live search' or 'search suggestions' feature in a web application that uses the Dojo Framework. It would be similar to the way Google and Bing searches display matches as you type: when you type in the search box, a list of potential matches appears below. Searches would be performed server side, with the results sent back to the browser using AJAX.
Does anyone know of a good way to implement this using Dojo?
Here are some potential options:
The built-in widget dijit.form.ComboBox
This has very similar functionality, but I've only seen it used with limited data sets. The examples always use small lists (such as the 50 states in USA) and preload the entire data set for client-side filtering. However I presume I could hook it up to a dojox.data.JsonQueryRestStore for server-side search — can anyone confirm whether that works?
QueryBox http://marumushi.com/code/querybox/
This implementation mainly does the job, but it has some minor bugs and doesn't look like it's being maintained. I'd have to do some bugfixes on the code before using it.
Medryx http://blog.medryx.org/2008/09/10/dijitsearch-part-2/
This also looks like it does the job, but it is described as 'alpha-level' code and the link to the code seems to be broken...
I could probably make one of the above work, but I'd like to know if there are any better alternatives out there.
I implemented it 5 years ago when Dojo was at 0.2:
http://www.lazutkin.com/blog/2005/12/23/live-filtering/
While the code is ancient, it is trivial, and hopefully it'll give you ideas on how to attack it. The rough sketch:
Attach an event handler to your input box, which is triggered on changes — use "onkeyup" to detect a change in the input box.
Wait until user stopped typing by setting a timer in your event handler, if it is not set yet. 200-500ms are good waiting times.
The timeout plays a dual role:
It throttles our requests to a server to prevent overloading.
It plays on our perception of time and our typing habits.
If our timeout is up, and we don't wait for a server ⇒ send server a string we have so far.
If we are still waiting for a server, cancel the request and ask again.
This part is app-specific: we don't want to overload a server, and sometimes a server cannot handle broken connections well.
In the example I don't cancel the XHR call, but wait it to finish first before submitting new request.
Server responds with relevant results, which are promptly shown.
In the blog post I implemented it as a widget. Obviously the exact packaging is up to you.
I'm trying to find the best approach for analyics on 3rd party JavaScript widgets - i.e. tools and content that is distributed to any number of arbitrary users, who include the widgets as HTML snippets with tags.
On the same domain
Note that the widgets do not load into an iframe element that has a document loaded from the external site. Instead, they load content into the DOM of the host page - i.e. they are treated as being on the same domain as the host.
Analytics for a fragment of the host page
So, essentially, I want to track stats (such as widget views, user clicks and custom interactions within the widget), but I only want to track stats for the fragment of the host page that is the widget. I don't want to track clicks on the host page that are outside the widget.
I want the stats to be collated together, so that stats for the widget on site A will be aggregated with those of the widget on site B and site C, etc.
Questions
Is it possible to use Google Analaytics in a custom way that satisfies these requirements? Or is it not possible to separate GA from the rest of the data collected on the host page?
If it is possible to use Google Analytics, then will there be a problem if the host page already uses GA (with a different GA profile ID), or is it possible to keep them safely apart?
Are there any other analytics packages out there that are properly suited to widget stats tracking, to meet these requirements?
Or, how else would you approach the problem of obtaining stats for these widgets?
GA can be used for this, though since it is a free tool, it is a bit limited compared to the other tools out there. Example of other tools out there are Yahoo Web Analytics (YWA), Omniture SiteCatalyst, and Webtrends.
Most of the tracking tools out there have the ability to do custom link and "event" tracking. Basically what you would do is lookup the necessary snippet of code for custom link tracking and put it into a wrapper function to be executed in an onclick event (or add an event listener, etc..).
The first thing you want to do is decide what "events" you want to have for the widget(s). You mentioned counting "widget views". That's easy enough to do: just put a snippet of custom code on the page the widget is embedded on.
But beyond that...does clicking any button count as a single event? Does each button signify a different event? etc... Also, are there any custom values you want to associate with the buttons, like a product ID or description or whatever.
Another important thing to ask yourself when deciding on what you want to track is "How actionable is this data?" There is very little you can't track, but there are a lot of things that aren't very useful for making real business decisions.
For example, it sounds like overall you are wanting to try to measure user interaction with widgets. I'm sure the idea is to figure out how useful, engaging, etc... they are to people, so you can figure out whether it's worth further developing them or throwing money at them or dropping them. Fair enough. But just remember to make the events goal-oriented. Knowing how many times a user clicked a button isn't very useful because all by itself it isn't very actionable. Knowing how many times people completed a process or step, etc.. is more actionable.
Once you have made a list of what all you want to track and when, then you can start building your custom code.
With GA, there are 2 main ways to track events and metrics: through steps/goals, and through custom variables. The way you setup steps/goals with GA is to have GA match what the URL of the page is. For example, if you have a newsletter signup form, the form page might be signup.html and the confirmation page might be signup_confirmation.html. You would then setup a goal in the GA interface. The goal would match for signup_confirmation.html and you could have a step be to look for signup.html. Then you can see how many people viewed your form and completed it vs. abandoned it.
You can use this same tracking method with events, by pushing a virtual page view to GA.
Here is an article detailing how to push a virtual page view:
http://www.google.com/support/analytics/bin/answer.py?hl=en&answer=55521
But basically, whenever the event happens (like a view of the widget, click of a button, etc.. you would execute the following javascript:
pageTracker._trackPageview(’virtual url here’);
Main thing to note about this method is that you can organize/categorize/provide hierarchy to your data by passing delimited values. This will help you rollup data for different widgets/sites.
The 2nd way to record events is with custom variables. Making use of custom variables during events provides a lot of reporting possibilities and flexibility. Here is a link to how to use them:
http://code.google.com/apis/analytics/docs/tracking/gaTrackingCustomVariables.html
I notice my site does not have a single <form> with the exception of logging in. I am not sure how or why it happened but i found i use jquery and ajax to post everything then refresh (or not if i dont need to). How and why would the user suffer from this?
Some of my 'forms' include
Leaving a comment on a page
Removing messages
Sending a private message (which i then do document.location=nextPage)
Marking as a favourite.
Forgetting for a moment that none of the site would work without javascript disabled, another side effect you might not realize, is that there is no default submit behavior anymore. This means a user cannot finish typing their entry and hit enter to submit the form. This is important for search forms and the like, but less important for comment forms.
Wrapping form fields in a form tag and having a submit input element (even if it is display:none) allows for a default submit action on enter or return. If you do this, you simply call preventDefault() into the submit() event handler to stop the real submit, and make an AJAX one instead.
Ok, back to the JS disabled thought. You have to make a choice:
Work backwards to implement unobtrusive JS on your site. Basically, the site works with or without JS, but it will work better (or more refined) with JS enabled
Or place a prominent message alerting your users to the fact that your site requires JS for the site to work. The cons to this method is you might limit the usefulness of your site in some corporate networks and on some mobile devices. As far as people who willingly turn of JS, the alert can let them decide if they want to stay around or not.
Given that the site is already coded, take a look at your target audience and make your best decision given the time and energy required to make the site work without JS.
From your comment, I see that you don't intend to support users without JavaScript, so the accessibility and backward compatibility argument is moot.
However, you are likely creating a lot of unnecessary requests by posting with AJAX and then refreshing the page. This is not how AJAX was intended to be used and is possibly an anti-pattern. The idea of AJAX is to send specific and receive specific data, and to update the page based on that received data, not refreshing.
Also, by not using form's, you disable the default submit functionality (pressing <enter>) as Doug Neiner pointed out