Live data from Hacker News

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

browser-details.com

51–60 of 85 posts

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

#51
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…

" save user information after every request via after_filter or some other hook. Probably slow for sites that get a lot of traffic."

Probably really wouldn't be that slow, unless done really naively - much of that information is already being written to a web server logfile in most cases, and that doesn't slow things down too much. Send the info to a separate logging server/db. If you're getting a lot of traffic, you're possibly doing a lot of queries anyway - one more is incrementally painful, but shouldn't be a killer.

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

#52
post #21

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?

"Anyone have other ideas about how to handle the email support when it's like this?"

Basically all you need is a user ID + time or a session ID so that you can trivially (in one line) cat your log and grep the corresponding ID (you have to log the browser details once per session of course, which is trivial to do).

Note that I've been working on a project where the helpdesk would mandate user to take screenshots or their complaints wouldn't be going through, so I know what you're talking about ; )

Want an easy solution? Put the session ID somewhere in your screenshot that shall resist lossy compression (my users where forced to send PNG screenshots but YMMV: you may be getting JPG ones) but that is not readable by your users. Something like a #CCCCCC text on a #FFFFFF background next to the logo at the top of the page.

Now I'm not advocating everybody to do that: all I'm saying is that if, in your case, you're getting enough screenshots without being able to tie them to a session ID, then it's an easy solution that may save your day.

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

#53
post #42
post #40

Earlier quoted context omitted.

It's actually a lot easier, unless you have next-to-zero traffic, to ask _them_ to take an action that puts the info in your inbox, rather than dig in logs, which could have that specific user's information buried amongst hundreds of other entries. It's a time-saver. What if you have insufficient logging (Heroku sans a decent logging plugin, for instance)? What if you built the thing, but it's hosted by a third-party…

If you can't quickly identify your client in your logs you will have bigger problems.

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.

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

#55
post #23
post #4

I think it's a GREAT idea. 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 ... 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! However at $10 per YEAR, I would think it's a steal and jump at it. Not suggesting you should drop your pants on…

You've got to be kidding me. $10 a year may as well be nothing. I wouldn't do anything for anybody for $10/year. I probably couldn't even be bothered invoicing you. You're right that it's a very simple product, though. $5 a month with a 20% discount for $50/yr sounds fair to me. I like it though. Your textbook well executed MVP. The price might need some tweaks but hey, it's a product. Well done Jonas.

"You've got to be kidding me. $10 a year may as well be nothing. I wouldn't do anything for anybody for $10/year."

That makes no sense in the context of selling 0's and 1's where the marginal cost is close to zero.

What you should ask yourself is this: would you rather sell one hundred subscription at $120 per year or ten thousands subscription at $10 per year? I'm not saying these are the numbers that GP would have but you must take this into account.

Another way to put it: quite some people are very happy sitting on hundreds of thousands --if not millions-- of dollars selling games on the iPhone at less than $5 a pop.

Another comparison point: there are desktop apps way more complex than the webapp we're talking about here that can bought (not a subscription, but bought) when there are bundle sales at way less than $10. Once again, the problem is trivial: would you rather make zero sales to that target demographic (people buying apps bundles) or would you rather sell a few thousands license for you app at, say, $5?

Basically the two concepts that you don't understand are: a) economy of scale and b) it's all 0's and 1's.

"I probably couldn't even be bothered invoicing you."

That just shows how lame and inefficient your invoice and tax filling process is. (btw I can help: no latter than yesterday when the tools of the trade were posted here there were apps taking care of automated invoicing and tax fillings)

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

#58
post #53
post #42

Earlier quoted context omitted.

If you can't quickly identify your client in your logs you will have bigger problems.

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.

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

#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?
Post reply on HN