Help alpha test our new Heroku Add-on?
Hey IndieHackers! This is my first post so apologies if I'm committing a faux pas.
I'm launching a Heroku Add-On for ParrotQA.com and I need help testing it. If you're willing to install it, play around a bit, and send me some feedback, I'll give you access to our product free for a year!
Our value prop is simple: testing web apps is hard. But the alternative (not testing) leads to bugs (especially if you're iterating quickly). Parrot makes full-stack testing of web app features easy. No coding required!
Interested? Shoot me an email jake at parrotqa.com
why just heroku? also what about settings the tests automatically or by someone on your site, that would really be QA, as is better that someone else to do QA then the initial developer, then an even higher price would work.
Yep! Good ideas! We have a standalone site (not just a Heroku Add-On) at ParrotQA.com, and we do offer full service test setup and maintenance at our highest price points.
I see sorry then, but on a very quick look it didn't jumped to me, switched to How it Works and got the idea that I need to set up tests, which put me off a little, also no idea if it support SPA but quite good idea.
Hmm - do you think I should add a callout at the top of How it Works that's like: "Want us to handle all this for you? Get in touch"?
I clicked on "Get started for free" and a pop-up wanted to know all my company details etc.
Two black marks:
I wasn't warned you would be seeking this information.
There is no way to close the modal window or back out of the transaction.
I couldn't see the report that was being generated because the sign-up process I wanted to cancel was blocking whatever was being generated on the main screen.
I would not want to sign up to something, even if for free, without understanding what the product will give me. I don't mind a crippled version (I only check one link, one whatever and one whatever) but I do want to see what sort of tests you run before committing.
While I definitely see why that would feel frustrating, the data tells a bit of a different story. 70-80% of people register when they see that pop-up. That's actually a pretty high conversion rate, and it implies that the majority of visitors are willing to do a little quid pro quo - they give me a way to reach out to them, and I give them more access to the platform. When I reach out, I usually offer some value (I set up some more tests for them, point out a bug I found on their site, or just generally offer my help). If I hadn't asked for their email address, I wouldn't be able to do that. So while you're right that 20-30% of people may be frustrated, and I may be losing valuable customers in that 20-30%, my theory is that I make up for it by offering value to the other 70-80%.
But that's just a theory. I'd love to test it. Any thoughts on how to structure a good test of whether the existence (and placement) of that registration pop-up is good or bad for customers?
I don't have an issue with you wanting to collect information.
The issue is one of control. Don't ambush me and don't trap me. At present, the experience feels like being hustled by a pickpocket gang in the Underground - it's a bum's rush.
Given how many scams there are out there, being trapped in a transaction over which I have no control feels very scammy and bullying. It is certainly very bad practice to present a user with a modal window which they can only close on your terms.
As for testing, just set up two different test pages and randomly asign visitors to one or other of them.
My personal preference for the alternative structure would be something like the following:
Let's get started => click.
Before we start, we'd like to collect some information about you. If you're not yet sure, that's fine. We'll run the demo report for you anyway so we can get a flavour of what we do.
I either accept or decline the information-gathering step.
You run the demo report (I assume it is a cut-down version of the full thing).
After a few seconds, pop up your modal window.
Impressed? / Like what you see? Display your form but include a Cancel button so I can close the modal window gracefully. This is my user experience, not yours.
Then do whatever it is you do with the information I provide.
Oh yes: and I want to see links to your privacy policy and who you are right in that modal window. In the EU, at least, that is a requirement and it is best practice anyway.
Cool, I'll give that flow a shot!
I learned a new phrase this morning: dark pattern.
https://www.theverge.com/2013/8/29/4640308/dark-patterns-inside-the-interfaces-designed-to-trick-you
Alright, alright! I get it!
I implemented the test we discussed. You can try both test groups, if you want to see forced modals, you can type this into your js console (on parrotqa.com):
localStorage.setItem("abTest:modals", "aggressive")if you want to see dis-missable modals, you can type this:
localStorage.setItem("abTest:modals", "chill")My hypothesis - people in the
aggressivegroup actually end up having a better experience, as measured by them engaging and building out their own tests. I think average # of self-serve tests is the success metric. Make sense?Sorry! I didn't mean to come across as bashing you over the head. I was reading elsewhere and the term "dark pattern" was used.
As I didn't know what it meant, I went looking. It was pure coincidence that we had had our discussion at roughly the same time!
Your approach makes sense to me. I'll have a look when I get some free time.
Haha, all good! I'm very excited to see the results of the experiment. I'll write it up as an IH article, and give you credit for kicking off the whole conversation, if you don't mind!
I'm not about to complain if you want to stroke my ego!