We wrote our own version of this which took about 2 minutes to write.<p>1. Client hits /support/client-info which generates a specific system error with a unique ID (right 6 digits of a GUID) and pumps browser, error and user context information via log4net into our logging system. Client tells us the error ID.<p>2. Open monitoring system, type error ID in. It's all there.<p>Not only that, we use it for error monitoring too.
You need to add support for custom domains so that I can tell people to visit blah.mydomain.com by setting a CNAME record in DNS.<p>This is especially important given that your domain name is less than ideal at present for support purposes; I've had enough of reading out hyphenated domains over the phone, and will avoid services that involve doing so.<p>Looks good though! Do you remember previous visits to the page as well?
Google Chrome on a Mac reports the following...<p>PDF: No - wrong Chrome has a built in PDF reader
JAVA: No - wrong I do have java
OGG-VIDEO: Probably supported - lol? probably
H.264-VIDEO: Probably supported - ^
WEBM-VIDEO: Probably supported - ^<p>And not to be a party pooper but why do I need to signup? Why can't I just click "Get Browser Details" get a unique hyperlink that I could then send to someone.<p>What if I have mulitple clients? I have no way of saying, okay Joe is using IE8, and Sandra is using IE9.<p>What if my client is using IE6. Bootstrap doesn't support IE6.<p>I think thats it for now.
I have found this to be useful:
<a href="http://supportdetails.com/" rel="nofollow">http://supportdetails.com/</a><p>What benefit does your service have over this one? Furthermore, if I send mycompany.browser-details.com links to two people, how does your system identify who clicked on the link?
I think it's a GREAT idea.<p>Now, this might just be me, and I don't want to sound negative, or take anything away from the effort you've obviously put into making this really good, but ...<p>For $120 / year I think, hmm I could probably build something that does this (just for me) in an hour, and it'd be fun!<p>However at $10 per YEAR, I would think it's a steal and jump at it. Not suggesting you should drop your pants on price, but that's my view on it.<p>I think charging for a CNAME is a good strategy.
The problem this doesn't solve is the customer who emails support, includes a screenshot. The screenshot doesn't include the browser frame, but just clearly shows something being rendered incorrectly. You kind of are stuck - first trying to reproduce locally, and then you have to resort to asking "what browser are you on?"... Anyone have other ideas about how to handle the email support when it's like this?
One of these gets posted on HN every month. I'm sorry, but I don't get the big deal.<p><a href="https://news.ycombinator.com/item?id=4499435" rel="nofollow">https://news.ycombinator.com/item?id=4499435</a><p><a href="https://news.ycombinator.com/item?id=3526446" rel="nofollow">https://news.ycombinator.com/item?id=3526446</a><p>and more.
In my Firefox @ WinXP it displays Java 10 :)<p>I guess it's an issue with the values reported by the browser (about:config lists Java plugin with 10.13.2.20). Chrome and Opera correctly say Java 7.<p>Also, the Flash version could be more detailed. <a href="http://supportdetails.com/" rel="nofollow">http://supportdetails.com/</a> lists precise version. Flash 11.2 vs 11.6 might make a difference. The more details, the better.
If I'm on the phone with a client and ask them to look at something I can generally figure out what browser they have (minus the version) by asking 1 or 2 questions and that's often good enough.<p>Now... if you used this data in a way to automate some typical developer->client BS then I could see paying for it maybe.<p>For example, let's say you load up a few VMs with every major browser / browser+version combo.<p>Then you can tell a client to goto some url, maybe it could be something like:<p><a href="http://browser.somedomain.com?for=somepage.com/preview" rel="nofollow">http://browser.somedomain.com?for=somepage.com/preview</a><p>If the client goes to that address it captures his browser details just like your site does but then:<p>1. Replicates his settings with one of the VM browsers.<p>2. Takes a screenshot of what somepage.com/preview looks like.<p>3. Sends the screenshot and data to my e-mail or have an API letting me get that data back in on my end.<p>That has pretty high value because when a client says "the border looks weird!" that means nothing to me. I have to see the problem to be able to fix it and people who aren't technical are horrible at explaining technical problems.
We semi-launched with a comment here: <a href="https://news.ycombinator.com/item?id=4499937" rel="nofollow">https://news.ycombinator.com/item?id=4499937</a><p>Just finished the Pro version and launched for real, would love some feedback from HN!
It detects that I have a Flash plugin. While this is correct, I have plugin on demand enabled, so it is not available until I either play it or whitelist it.<p>Tested with Opera and Chrome. (Firefox supports it as well.) Could lead to some confusion.
@jonasvp: I would be extermely interested in reading about how many people signed up for the service if you would be willing to share. As well as any other one service products you guys sell.
Why not just a JS API for this? I just cannot see the full application for this app. It is interesting but the work required to get that info by using JS and just plot it is not that high.<p>Just my 2cents
We use graylog for logging plus a client side logging script, and that gives us a lot of information. User id + agent + plus time they loaded the the site + any client errors they got.
What would make this <i>really</i> worthwhile, is if along with the browser details you included common/known bugs and quirks for the given browser version.
I've always been a fan of this one: <a href="http://supportdetails.com" rel="nofollow">http://supportdetails.com</a><p>But, yours supports a few more details.