If your client has a problem with a site, send them here and ask for details
supportdetails.com
supportdetails.com
1. Visit site. Enter my email address and maybe client name. It gives me a unique URL (supportdetails.com/jasd9s89ajd698/ or optionally support.mybusiness.com/clientname).
2. I email that to the client and tell them to click the link. [Risk of training them to click strange links...]
3. They visit the page and get a Thanks message. It automatically sends me all the info I need.
Burden on the client is lowered. First time I saw this site or similar (been around for years) I wondered about quickly building an alternative that offered white labeling and the above process instead. Easy weekend project for someone, I imagine.
Could be implemented as freemium, too, by charging for more than 7 uses a week to the same email address.
Cat mode sounds immature, but MailChimp gets by.
Is there another common process where by technical people need to collect information from internet battlers?
A "cat mode" that gets widely noticed could help many of us deal with clueless clients. Make the cat follow laser pointers and mutter lolcode while it collects every possible piece of information about the client's system. Really, anything to make it more viral would contribute to the Greater Good (tm) and more than compensate for immaturity.
Even something as simple as a browser-specific tuturial for clearing the cache would be immensely helpful. For example, Dropbox customizes its download & installation tutorial for each user's browser. It's really helpful.
What'd be great is a a-z0-9 unique code that's presented on each load. Then the user would only need to read me that code, I could go to the site and enter that, and immediately see all the details that were stored for that user.
I think the parent to your comment has it right; getting a transcription of an arbitrary long alphanum code right over the phone can be tedious.
Update: I also forged/made-up the from email address. Could have fun on an open wifi network with this. I suggest you stop, and think about all the ways this could be abused (and how you can prevent that) before proceeding.
Update2: The eamil "from header" actually has the forged address in it so if the recipient victim replies, the reply goes to the sender victim. Nice. The real culprit is clearly identified though:
X-Originating-IP: 173.193.132.135
Received: from heroku.com (unknown [10.9.180.5])
Update3: Sergey Brin is about to send an email to Zuck ;) just kidding.
You should really serve the site in HTTPS.
Thanks for all of the positive and constructive comments. We're really excited to take Support Details to the next level, and based on your comments, I think our ideas on the right track. As of late, we've been focusing on the accuracy and speed of the site (see http://imulus.com/blog/bryce/javascript/support-details-on-r...), but now that we've got that nailed down, we're excited to start rolling out some new features.
As an agency focused on client work, we've struggled in the past to make time for our own products, but we're set on making them a priority this year, so thanks again for the positive comments to encourage us to move forward.
I love seeing developers raise their hand on HN and say "I did this!" And kudos to you the project so far!
No affiliation, but I know some folks who have used their service and were happy with it.
Edit: P.S. should have mentioned that they historically have been an ASP[.NET] oriented product, an important detail I forgot about.
It did get the browser and OS version right.
I like the concept, but one suggestion. The rounded rectangles with the computers specs look like buttons. The onhover effect doesnt help either. I tried clicking for 5-10 secs before realizing they werent buttons.
Also, looks like its all the standard info that can be detected in general. More specific things like n/w info might be harder to get.
2. When partner sends a user to your site, they make a call to http://supportdetails.com/<api_key>?data=<random base64 string>
3. You collect details, and make a POST to the <callback_url> with all the information (including <random base64 string>) as JSON or XML and signed using a HMAC of the data with the shared secret
4. Partner verifies signature and then accepts the data. The <random base64 string> could contain information that the partner can use to identify the user/store session info, etc.
This protects your partners from fake submissions, if they care about that sort of thing.
Disclaimer: I co-founded WebEngage (http://webengage.com). And here's a shamless plug - WebEngage not only provides you all this client side info, it also captures a screenshot of the current page (on your website) the visitor is on.
Why do you include the IP address? This seems like the only bit of personal, identifying information, as opposed to information that could affect the rendering of a site.
You seem to parse any version of Linux as an unknown OS with version "Linux", rather than the OS "Linux" with an unknown version.
You should include the full browser User-Agent string, not just the parsed-out bits; among other things, that provides the version of Gecko or WebKit, not just the version of the browser UI.
* Speed testing and connectivity testing.
* Throw in reverse DNS data for getting info on their ISP.
* Add ad-blocker detection.
* Add silverlight detection.
I'd also like antivirus detection (for example Avast doesn't like one of our apps) and a pony :)
Of course it wouldn't be on a grand scale necessarily, but as they say in several contexts, "a hole is a hole."
What is KILLER useful is http://showmewhatswrong.com. Instant screencasts from users of what is going wrong.
Just list each line in plain-text.
What use cause does the item 'color depth' cover?