To be perfectly honest, there's no reason it can't be used on more 'prime time' real estate, but the primary converting audience thus far has been smaller web apps (averaging ~10-100 messages a day / surface) and 1-X person shops. I plan on continuing to target that segment to continue to feel out what features are needed and desired as it organically continues to grow (largely from referrals).
Does that 10-100/day/surface number refer to 'feedback' hits, or webapp/site usage? I'd think if that's 'feedback' messages it'd indicate a much larger amount of visibility-inducing traffic using the page the widget's made available on. And IMO, small orgs (of which I'm a 1x/shop), are & can be freelancers, or real jobs, that are/can be more than 'side projects'. To me, saying 'side project(s)' infers a less-than-professional implementation. Maybe not to everyone, but that's where my mind goes with that term. As a budding freelancer myself, my jobs are more than 'side projects', but rather 'sporadic contract employment'. I guess maybe I equate that term with more along the lines of 'for fun'. -So that's my 2 cents...
You should consider having a version that does not print the email in the invocation - it may get picked up and be spammed. one might not want to publicize the backend email recipient of the support/feedback. Another reason is that if someone figures out the fig api, they can send emails to arbitrary recipients thus blacklisting the fig domain.
One thought is that it ought to be a service that works with a hash/UUID and that value maps to a recipient email on your database. so the only people who know my email is fig itself. Still - one can in theory spam every fig user by scraping for fig js. that brings me to some sort of recaptcha, i'm not a robot support.
Added bonus: backend can route the message via any channel not just email.
4 comments
[ 1.1 ms ] story [ 21.1 ms ] threadOne thought is that it ought to be a service that works with a hash/UUID and that value maps to a recipient email on your database. so the only people who know my email is fig itself. Still - one can in theory spam every fig user by scraping for fig js. that brings me to some sort of recaptcha, i'm not a robot support.
Added bonus: backend can route the message via any channel not just email.