I am trying to simulate traffic on QlikView dashboards for the purposes of load testing. I have created a number of simple dashboards that I am viewing in a web browser. When I click anywhere on a graph or select a field in a list box, I can see that network traffic is generated as the application filters to display updated results.
I would like to simulate this traffic by opening the dashboards with PhantomJS and pretending to click on a few different places. Ideally, I would like to select an object such as chart or listbox and click on that programmatically but clicking on random coordinates within the page should suffice as well. However, the usual JS/JQuery click() operations do not appear to have any effect within QlikView even when displayed in a browser.
Any input as to how to approach this would be much appreciated.
Thanks.
Some additional info per comment: Yes, unfortunately I've tried everything on that page and just about everything else produced by stackoverflow/google searches. I can grab elements and do all the normal operations but the pages produced by qlikview are structured differently from any I've worked with. The majority of the elements are clickable and you actually interact with dashboards by dragging the mouse over sections of graphs to zoom in, or selecting criteria from listboxes. Somehow they fire Ajax calls from deep in qlikview's js but on the surface all elements appear as mostly divs and spans without explicit onclick functionality which may be why they don't respond to anything I've tried so far. For this reason I think moving further away from working with individual elements and simulating something like selecting a random portion of the screen may be best but no luck so far.
I'm looking to set up a Google Analytics experiment where we test two pages and tack if a user clicks one of a set of links (don't really care which one of the set).
However, the links will all go off-site and I was hoping to avoid adding a redirect somewhere in between.
What I'd love to do is have a bit of javascript that's called and is counted as a 'conversion' in the experiment, that way I could call it any time one of the buttons is pressed. I don't really care which button, just looking to track the total.
I'm testing this with the following code on two page:
Tracked Link
This is supposed to correspond to a goal I set up like this:
So far after three hours (and I've been clicking the link) there are no results howing up in the test.
I'm trying to build a webform that has multiple stages. I'm patterning it off of the Stack Overflow / Stack Exchange flagging webform. The problem is, I'm not sure how to trigger the "next stage" action.
To illustrate, if one wants to flag a question on Stack Overflow, you click flag and then a popup prompts you to make a choice. If you choose the second option ("it doesn't belong here, or it is a duplicate") the form automagically takes you to a second screen.
First screen:
Upon click, it auto-redirects to:
The problem is that I don't know what the underlying trigger is. How does clicking that radio button send the end user to the next screen?
I tried checking the source, but I have a feeling I'm only seeing half the picture:
No amount of HTML tutorials I find have any practice example similar to this. I suspect this is JavaScript, but I can't find the linked .js file that would trigger these actions.
So: How does the webform auto-redirect upon click? As a follow-up, if it's using JavaScript, is there an HTML/CSS-only workaround I can use?
It might help to think about this at a lower level than frameworks. There are two ways one could make a multi-stage form.
The first (and generally older) way is to store the state on the server. Each stage of the form is actually a separate form, and the client's progress through the questionnaire is kept on the server (for example, as part of the session data).
The second way (the more modern one) is to use JavaScript, as you suspected. There is actually very little black magic in this case, and no auto-redirects on clicks at all. All you do is have one very long form where you show/hide some of the elements depending on the user's selections (of course, you could have multiple <form> elements which you show/hide).
Well, I'd use some sort of jQuery wizard plugin and adapt it to my needs. I did it very recently and it wasn't that hard. You should try SmartWizard 3.0, it's pretty active, the last release was about 2 months ago and the coders answered my questions pretty fast.
Here it is: https://github.com/mstratman/jQuery-Smart-Wizard
You can trigger the wizard to advance to the next step linking an event to the action of clicking the radio button.
Good luck :)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I am currently building a registration page where if the user leaves, I want to pop up a CSS box asking him if he is sure or not. I can accomplish this feat using confirm boxes, but the client says that they are too ugly. I've tried using unload and beforeunload, but both cannot stop the page from being redirected. Using those to events, I return false, so maybe there's a way to cancel other than returning false?
Another solution that I've had was redirecting them to another page that has my popup, but the problem with that is that if they do want to leave the page, and it wasn't a mistake, they lose the page they were originally trying to go to. If I was a user, that would irritate me.
The last solution was real popup window. The only thing I don't like about that is that the main winow will have their destination page while the pop will have my page. In my opinion it looks disjoint. On top of that, I'd be worried about popup blockers.
Just to add to everyones comments. I understand that it is irritating to prevent users from exiting the page, and in my opinion it should not be done. Right now I am using a confirm box at this point. What happens is that it's not actually "preventing" the user from leaving, what the client actually wants to do is make a suggestion if the user is having doubts about registering. If the user is halfway through the registraiton process and leaves for some reason, the client wants to offer the user a free coupon to a seminar (this client is selling seminars) to hopefully persuade the user to register. The client is under the impression that since the user is already on the form, he is thinking of registering, and therefore maybe a seminar of what he is registering for would be the final push to get the user to register. Ideally I don't have to prevent the user from leaving, what would be just as good, and in my opinion better is if I can pause the unload process. Maybe a sleep command? I don't really have to keep the user on the page because either way they will be leaving to go to a different page.
Also, as people have stated, this is a terriable title, so if someone knows a better one, I'd really appreciate it if they could change the title to something no so spammer inviting.
As soon as I saw the words "prevent the user" I started to wail in agony. Never prevent the user, only help them.
If they see your registration page and run off, that's their choice. Pop up a javascript confirm box if they've already filled in some data (because they might be navigating away accidentally) but leave it at that. If they haven't touched the form, leave them alone - they don't want to fill in your form.
Look at other methods of engaging users. If your form is huge and scary, break it into simple manageable chunks or better yet, simplify things so much that the user only gives you data when you need it. For example, you might not need their address until you want to post something to them.
By breaking it into multiple parts you can hook them with a simple form and once they've invested that time, they'll be more likely to continue the process.
But don't harass users. If they don't want to register, pestering them with pop-ups and jaavscript dialogues will just chase them off the site completely.
With that in mind, assuming you're just trying to stop people half-filling-in forms, there are a couple of options to genuinely help people:
Detect if the form has changed and ask them a simple confirm() message.
This is all you can do. A CSS "pop-in" just won't work because you can't control* the window location in the unload event.
*You can put an event listener on all your page's links to fire off something to check the form, but this only helps if the user clicks on one of those links. It won't help if, for example, the user clicks back or closes the window. You could do both CSS and javascript but you end up with a bit of a mess.
Persist the state of the form behind the scenes.
An extension to #1. Instead of squabbling with the user, let them go where they want but save the content of the form either to session or cookie (if it'll fit) and put something on the page (like SO's orange prompt bars at the top of the page) that reminds them that they've started filling in a form and gives them a link back to the form.
When they click that link, you load the data out of the cookie (or session) back into the form and let them carry on. This has the clear benefit of letting them do what they like on your site and keeps the data safe.. ish.
If they don't come back and their cookie/session expire, that's their fault. You can only lead a horse to water. It's not your job to force it to drink.
Don't do it.
But if you want, try this. Record mouse positions and detect a quick upward thrust -- the user is reaching for the BIG X or the top left or top right. Now might be your chance for an unobtrusive box in the screen.
I've seen this implement on the web and it is evil.
If you want to trap links, you could rewrite the links in the page to go to a "you really want to leave?" javascript function, passing the destination URL as an argument.
If you wanna keep users from using their "Back" button, or keep them from putting another URL in the address bar, stop. Stop now. (1) Browsers were made to prevent exactly that kind of obnoxious behavior, and (2) Even if they allowed it, see the last two words of (1). It's freaking rude. Your site is not that special, no matter how cool you think it is.
window.onbeforeunload = function() { return "Message"; };
Use a JavaScript like this to display a leave confirmation message.
Here are just a couple of approaches I could think of but they are not without flaw:
Whatcha Gonna Do technique
Detect the mouse position going towards the edges of the browser as the user might be going to close the tab, window, go back, navigate elsewhere among other things. If so, immediately prompt them that that may be a mistake and they are going to lose out on something very valuable. However, the catch here is that you don't know for sure what their intentions were and you might piss them off with that popup. Also, they might use a bunch of shortcuts such as Ctrl+W etc to do the same.
You've Got Mail technique
If you've managed to get hold of the user's email address before they closed the page, you've hit a jackpot. As soon as the user types anything into the email box and then leaves it, immediately send it to the server using AJAX. Save the state of the page into localStorage or on the server using a cookie or something so it can be recreated later. Every couple of hours send them an email giving them a direct link to the previously saved form, and maybe with special offers this time.
History Repeats Itself technique
Then there's the infamous history manipulation where you keep stacking the current page into the document history so the back button renders effectively worthless.
Don't Put All Your Eggs In One Basket technique
Another technique off the top of my head is to create multiple windows in the background with the registration form and keep them all in sync when any the fields in any one changes. This is a classical technique and really puts the "don't put all your eggs in one basket" saying into real-life usage.
Another advantage of this awesome technique is even if the user closes one of the windows, and later comes across an identical cloned window with all the fields they filled up-to-date populated, they might get confused and think that they never closed the page. And guess what, this time they might just go ahead and fill out the registration form. But you have to be cautious with this as anything more than 2 or 3 clones will make it obvious as to what's going on.
You're Winner technique
Another technique is to tell every user they they are the Xth visitor on the site and use a good rounded number for X such as 1000, 10000, 50000, etc. Tell them that they can claim their prize once they register on the site. Imagine how special each user feels when they land on your site. The prize doesn't have to be anything tangible, it can simply be free coupons that you find on the intertubes.
Where Do You Want To Go Today? technique 1
This is basically a rip-off of your answer. Use document.location.href = 'some url' inside your onbeforeunload callback to navigate to a different page before it is unloaded.
1 Firefox only.
Note: there is no silver bullet solution here unless you write your own browser with your own security policies, but these are all optimizations that you can do to make it utterly impossible for users to leave.
Not all browsers support a modal popup, without which your page would go ahead and navigate anyway.
This is real awful requirement. The sort of requirement that is reasonable in a desktop application but entire unreasonable feature of a web site. Imagine being unable to leave a website.
The answer is either use the horrible confirm box and lump it. Or don't ask the user to enter too much data per page. Use a step by step wizard style data entry, the loss due to accidental navigation is minimised.
You can change the Value of the url using document.location.href = "www.website.com"
I can accomplish this feat using confirm boxes, but the client says that they are too ugly.
If the problem is the ugliness of the standard JS popup boxes, try something like this: http://www.sohtanaka.com/web-design/inline-modal-window-w-css-and-jquery/
Apart from that I second what most people are saying: do this with extreme caution if you don't want to lose users.
Background
I'm using POST form submissions instead of links with concatenated arguments inside a Web application, so I can exercise control over input.
Unfortunately this means users can't use the quick shortcuts they know to open links in new windows, like control-clicking or middle-clicking.
Problem
I've got what seems to be a workable way to use jQuery to capture mouse input and the various chord keys, based on the W3C DOM mouse events specification:
$("span#clickspan").click( function(event) {
buttonpress = event.button;
ctrlpress = event.ctrlKey;
$("#clickresult").empty();
$("#clickresult").append("<p>Click!</p>");
$("#clickresult").append("<p>Button # " + buttonpress + " pressed!</p>");
if (ctrlpress) {
$("#clickresult").append("<p>Control-click!</p>");
}
//form submission code would go here
event.preventDefault();
}
);
I can capture control-clicks this way (tested in Firefox 3 and IE7), and it correctly (?) reports left-clicks as coming from mouse button #0, but for some reason this code still isn't capturing middle-clicks on the span, and right-clicks still pop up the context menu. I'd like to capture middle-clicks, at least.
Can somebody help there?
What "control" means
The problem with a GET submission/link with concatenated arguments is that anybody can edit the address bar and type in anything. I've already worried about authentication and validation server-side. That's not why I want to work with POST.
I should only be showing users information that's meaningful. Internal database IDs aren't. I should only be letting users interact with the application in meaningful ways. Arbitrarily editing the address bar isn't one of those.
People make typos all the time. From the system's perspective, though, there's no difference between a typo in the address bar and a flaw in the application logic, and I'd rather not push the responsibility for deciding which one just happened off onto the users.
Short answer? Can't do it.
Long answer? Javascript mouse events. Still can't do it.
This begs the question: do you need to use POST or do you simply want to? The only reason why you'd need to is query string length. As to wanting to, you mention "controlling user input". What does that mean exactly?
You should never ever ever rely on the browser for input validation. You can do it there as a convenience but the server should always validate input.
Or is the reason aesthetic (ie shorter, "nicer" URLs)?
You're reinventing the wheel that is hyperlinks. I'm just trying to make sure you have a pretty darn good reason for doing so because it's counterproductive and you're never going to get the same browser support and compatibility as actual hyperlinks. Plus you're likely to simply annoy your users by having things they expect to work not work. Not good.