Client side Javascript to fix a TERRIBLE form made using Qualtrics? | XM Community
Question

Client side Javascript to fix a TERRIBLE form made using Qualtrics?

  • 5 March 2021
  • 0 replies
  • 19 views

Long story short: I am a lowly wage slave at a megacorporate entity you've definitely heard of and I don't want to risk getting in trouble by naming 😉 (our HR can be.... aggressive about such things)
They made a form for us to use for a fairly common issue that arises at work - which winds up taking 20+ minutes when about 5 of that tops is spent figuring out or typing out what information to submit and the rest is due to the form's UI.

I want to fix that client-side with some simple javascript - I will just hide most of the current page, insert my own more sensible form inputs to collect the same info, then provide my own 'submit' button that sends some click events, manually sets some text input values, and finally sends a click to the actual page's submit button. The offending elements are easy to manipulate with JS but offer a terrible UX to do so by normal user input.

What I want to know is:

  1. Do Qualtrics forms do any fancy stuff that would allow javascript commands to seem to work as intended from a Chromium dev console, but get blocked somehow if run through, say, a greasemonkey script or other method of locally inserting and running some javascript?

  2. Do they care if some of their elements are hidden via CSS, but other than that have not been tampered with beyond being sent click events and having text input values set by script and not typed by the user?

  3. I'm not sure what to do about unexpected form submit failures - I will validate the user inputs on my end, but if the form throws back some error anyway, it's gonna look pretty broken on a page that has had most of its UI hidden and replaced. Is there some easy way I can listen for a failed/rejected response so I can at least delete my new html elements and unhide the default ones so users can try to fix it themselves and won't be any worse off than if they hadn't used my code? Or perhaps just remember their entered values, reload the form entirely, and repopulate those without hiding anything or adding any new elements - just doing a couple element.clicks and element.value="blah" statements and letting the user take it from there? Or is there some super aggressive local JS detection that would allow those actions to seem to work but then block the form submission anyway?


I am almost certainly overthinking every aspect of this, I know that. I just wanna be sure this damn tool can even work before I build it as a starter project and try to polish it up and distribute it to coworkers. They gave us this form as a QR code on our work phones to scan and use from our personal phones, and said nothing about what browsers or extensions to use, if it were on our internal phones I wouldn't even bother because Nameless Megacorp would never let me install tools like that on our work phones, and I dunno if they even run a version of iOS that supports any iOS browser that is capable of extension-like javascript-based tools, anyway. But Android phones have had that for ages and now there's at least 2 different forms of browser extension on modern iOS devices (Apple's Safari modules that have at least some cross-support with other WebKit iOS browsers, and Insight, the fancy new one with its own extension system that includes very straightforward javascript support.


0 replies

Be the first to reply!

Leave a Reply