Live data from Hacker News

Show HN: Stop asking your clients "What browser are you on?"

browser-details.com

71–80 of 85 posts

Re: Show HN: Stop asking your clients "What browser are you on?"

#71
post #59
post #36

We wrote our own version of this which took about 2 minutes to write. 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. 2. Open monitoring system, type error ID in. It's all there. Not only that, we use it for error monitoring to…

Does it account for users who change their user agent string like those using Opera, though?

No and I really don't care about those users - it's entirely their problem. We support vanilla IE7-10, Firefox 6+, Chrome 10+.

Any anti-virus, content filters, other browsers etc are up to the user to sort out - it's in their contract.

Re: Show HN: Stop asking your clients "What browser are you on?"

#72
post #45
post #36

We wrote our own version of this which took about 2 minutes to write. 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. 2. Open monitoring system, type error ID in. It's all there. Not only that, we use it for error monitoring to…

Seems kind of awkward. Thinking about it offhand using some Rails terminology, let's see. * Naive version: save user information after every request via after_filter or some other hook. Probably slow for sites that get a lot of traffic. * Slightly less naive version: check to see if current_user.browser_info has changed compared to the current request in an after_filter or other hook. If so, save it in the DB. This w…

That's naive and inefficient.

We only care if there is a system error, if the user phones up or they fill in the online support form. This is only to satisfy the path of the phone call. Everything else is passed around with context.

For the phone call, our logging system has a web interface (log4net appender -> postgres -> asp.net web forms page). you just visit a web page and copy and type the error ID in and you get everything from the entire context, session and client info to the stack dump.

Re: Show HN: Stop asking your clients "What browser are you on?"

#73
post #58
post #53

Earlier quoted context omitted.

Sure, but the usual support rep has no log access. But using a good knowledge base, he can answer things like "Flash 9 doesn't work" without tech assistance.

Why doesn't the tech support rep have access to the information he needs? The data is in the organisation.

Because he might not be qualified to read it and providing an aggregation of said data in a consumable form is too much implementation work?

In some organizations, he is not even allowed to read operational data without pre-screening.

Re: Show HN: Stop asking your clients "What browser are you on?"

#75

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. 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. Looks good though! Do you remember previous visits to the page as we…

You could just set up a redirect from blah.mydomain.com to myname.browser-details.com (whatever subdomain you choose). Then, just give out the url with your domain name, no hyphen, and they land on the browser-details.com page.

Re: Show HN: Stop asking your clients "What browser are you on?"

#76
post #36

We wrote our own version of this which took about 2 minutes to write. 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. 2. Open monitoring system, type error ID in. It's all there. Not only that, we use it for error monitoring to…

I appreciate that it's not exactly an earth-shattering problem, but "about 2 minutes" is a huge underestimation. I think "an hour or so" is still pretty optimistic but at least possible. At that point the $10/mo for the Pro plan starts to look pretty competitive to writing your own.

Re: Show HN: Stop asking your clients "What browser are you on?"

#78
post #62

Earlier quoted context omitted.

Correct, it's really not a solvable problem. It boils down to two problems: 1) SSL hostname has to match the hostname on the cert and 2) you can (realistically) only have one cert per IP address. For 1), you would have to upload the ssl cert and key into the third party's service. They would then have to configure their web server to use the correct ssl cert for your CNAME. On top of that they would need to add suppo…

The one-ip to one-ssl-host thing was solved quite some time ago with Server Name Indication[1]. You still need one cert per host, but that is a cost that could be transferred to the customer (not the user getting logged but the one wanting the log :). You can get incredibly cheap certs that would probably be appropriate for this case. 1. http://en.wikipedia.org/wiki/Server_Name_Indication

I mentioned SNI in my post. It doesn't work for anyone using IE (any version) on Windows XP. Unfortunately, that's enough people to make it impossible to use unless you have an extremely tech-saavy customer base.

Re: Show HN: Stop asking your clients "What browser are you on?"

#79
post #72
post #45

Earlier quoted context omitted.

Seems kind of awkward. Thinking about it offhand using some Rails terminology, let's see. * Naive version: save user information after every request via after_filter or some other hook. Probably slow for sites that get a lot of traffic. * Slightly less naive version: check to see if current_user.browser_info has changed compared to the current request in an after_filter or other hook. If so, save it in the DB. This w…

That's naive and inefficient. We only care if there is a system error, if the user phones up or they fill in the online support form. This is only to satisfy the path of the phone call. Everything else is passed around with context. For the phone call, our logging system has a web interface (log4net appender -> postgres -> asp.net web forms page). you just visit a web page and copy and type the error ID in and you ge…

> That's naive and inefficient.

So is having a user read stuff over the phone that you already know.

Re: Show HN: Stop asking your clients "What browser are you on?"

#80
post #36

We wrote our own version of this which took about 2 minutes to write. 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. 2. Open monitoring system, type error ID in. It's all there. Not only that, we use it for error monitoring to…

I appreciate that it's not exactly an earth-shattering problem, but "about 2 minutes" is a huge underestimation. I think "an hour or so" is still pretty optimistic but at least possible. At that point the $10/mo for the Pro plan starts to look pretty competitive to writing your own.

How come $10/mo is competitive with one hour ONCE?
Post reply on HN