Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Stop asking your clients "What browser are you on?" (browser-details.com)
93 points by jonasvp on Feb 18, 2013 | hide | past | favorite | 82 comments



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 too.


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 way you can not only check what they're using right now, but what they were doing yesterday when they did something that caused your site to go haywire.

* I'm sure the above can be improved on: it'd be nice to package it up as a gem. This is not rocket science.

Looking in the logs is easy enough, but it's data that should be very easily available to support people, and they probably should not have ssh access to the server...


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.


> That's naive and inefficient.

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


Some people like to call up and chat or vent. We give them the choice.


" 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.


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.


Versus piss around with integration (any software engineer knows this is a time sink), breaking API changes, subscription management and billing, PATRIOT act data protection issues (what happens if PI data is in the request?) as we're in the UK, the risk that one day you disappear off the planet and finally actually throwing client confidential information by email.

It actually took 47 minutes looking at my work log and if I remember a lot of that was making the error page look nice.

It doesn't add up. sorry.

In the build vs buy debate the time versus money theory rarely applies.


How come $10/mo is competitive with one hour ONCE?


$150/hr for a good developer means this thing can run for a year and still be cheaper. Any improvements or enhancements they add you basically get for "free" over that time.

Plus, I have yet to see the feature that requires coding once and never needs touching again. When I upgraded my app from Rails 2 to Rails 3, there were all sorts of 1-offs like this that I had to tweak and fiddle to get working right again. It takes well over an hour just to remember what you were thinking when you originally wrote it.


Not if you design it well and comment it properly...


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.


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 well?


Thanks! CNAMEs are supported in the Pro version you can upgrade to. Previous visits are remembered, you can access all the data from your control panel or click the permalink in the e-mail you receive on new visits.


how do you handle SSL with CNAMEs? I'd like to offer CNAMEs for my customers as well, but the lack of SSL support means I don't for security. Suggestions?


Tricky one. I don't think there's any way to solve that, other than creating certificates for every CNAME - which is too expensive and complicated for your clients.

I've run into this with Campaign Monitor and they simply don't do SSL for CNAMEs. Since they do everything else perfectly, I'm assuming there's no way to solve this problem.


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 support for whatever intermediate and CA certs that have to be included. Some CAs require multiple intermediate certs. If you simply upload the main cert and key then older browsers, android, and IE will all freak out. I have missed an intermediate cert before and it's not fun to track down the root cause. There are no errors in apache; you just get reports of your site being compromised or the cert expired.

Not to mention the problem of SSL accelerators/load balances and costs associated with adding new SSL certs and keys to them.

Even if they figured out a way to automate the cert/key/PEM/intermediate upload and server config steps then the one IP per ssl cert problem kicks in. Basically, the SSL handshake goes something like this: 1) browser looks up IP address for host. 2) browser connects to IP and establishes a ssl connection. 3) server reads the request and serves up content based on hostname. The problem is that the server does not get the hostname during step 2 so it can only serve up one cert for the IP.

Now, there is a process called SNI that attempts to solve it. Unfortunately it's not well supported enough to use. Mostly because it does not work on IE on XP at all (regardless of version).

And that's why third parties generally don't offer SSL CNAMEs.


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.


It's really a major deficiency on how things work together (SSL, HTTP, CNAMEs)

Maybe the solution is having stuff.blah.com redirect to blah.com/stuff and do SSL from there

Ugly, but it gets the job done.


You can solve this problem by using a "wildcard certificate". It's like 300$ more expensive than a normal one.

You can test how it works creating your own: http://www.justinsamuel.com/2006/03/11/howto-create-a-self-s...


You can solve this problem by using a "wildcard certificate". It's like 300$ more expensive than a normal one.

Incorrect. You cannot create a wildcard domain for every domain in existence. That would somewhat undermine the whole point of SSL.

Edit: I think I misunderstood slightly. You're correct if you mean using the same domain for clients (e.g. client1.domain.com, anotherclient.domain.com), but not if you want clients to be able to use their own domains with your service.

On a related note, StartSSL (http://www.startssl.com) are a cheap option for wildcard certificates, and SSL certificates in general, since they only charge to validate your identity - you can issue as many certificates as you want (for domains you own) thereafter.


I misunderstood your original concern :S, I meant what you said in your edit.

I don't think there is a nice solution for the other problem =)


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.


Google Chrome on a Mac reports the following...

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 - ^

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.

What if I have mulitple clients? I have no way of saying, okay Joe is using IE8, and Sandra is using IE9.

What if my client is using IE6. Bootstrap doesn't support IE6.

I think thats it for now.


The "probably" comes directly from the HTML5 Media spec. Browsers can't say for sure that they support a certain video format.

media.canPlayType(type) - Returns the empty string (a negative response), "maybe", or "probably" based on how confident the user agent is that it can play media resources of the given type.

~ http://www.whatwg.org/specs/web-apps/current-work/multipage/...


Actually Java is right. You can no longer run Java applets in Chrome on Mac as Java 7 isn't compatible with it.

http://support.google.com/chrome/bin/answer.py?hl=en&ans...


Hrm java applets load for me... Maybe I need to investigate more lol.


Similarly, it reports no PDF plugin for my Firefox 20 on OS X, but pdf.js works great to view PDFs.


Not on chrome but I get the wrong browser too I'm on IE 8 (yeah, big corp...) and the report states I am using IE 7.


Similar results on Chrome Linux


I have found this to be useful: http://supportdetails.com/

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?


Definitely, support-details.com was the inspiration. However, we didn't want to send our clients to some other site - we needed a branded version.

As for identifying users: you can add multiple recipients in case there are several people in your organisation using it.

We figure that you'll mostly have your client on the phone or are sending an email and expect an answer within minutes - so you know who it was. In the future, we might add a "Subject" line.


That's assuming it's a single client on the phone at a single time. Which is wrong. There could be multiple clients on the phone or multiple phone calls with multiple clients.


Right, that's when the "multiple recipients" come into play. You alone probably won't be on the phone with multiple clients.


That's confusing? Okay billy you send your results to cindy and bob sends his to chad and ashley sends hers to alex and anyone else send theirs to the next person on the list?

lol?

What's wrong with

domain.browserdetails.com/somerandomidhere

It allows you to reference it without going into an email. Allows anyone to view it (rather then forwarding the email to 15 different people) and makes it easy to transfer.

I fail to see the reason why email would be better in any sense. It doesn't allow for the same control as one would require for such a service. You also can't organize it as it doesn't come from "client" so if you are looking for it down the road you generally search "Client Name" and it would never turn on.


Needed a branded version? This is when you're talking to clients that can't tell the difference between one browser and another? These clients can't tell the difference between a big blue e, a fox or a colourful circle? Yet you needed a branded version?

I'm just pulling your leg, I understand that you needed a branded version and that wasn't influenced by your clients inability to distinguish between core brands in the online space.


My company used this as a model when we built our own solution. I think between our designer and developer we had it designed and built out in 2 or 3 days. Ours also supports file uploads.

Once the email is submitted it goes right into our support queue.


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 price, but that's my view on it.

I think charging for a CNAME is a good strategy.


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.


Thanks for the kind words! The pricing is obviously geared towards agencies, not freelancers. We'll see how it pans out, your feedback is greatly appreciated!


The point isn't if it's worth it to the developer to charge you that much. It's an automated billing process. The point is that the price point is low enough that people won't think twice about paying it. In this case, more than 5 times as many as would go for $50/year.


"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)


You seem to have missed the fact that this is a service. It's a SAAS targeted at businesses. The economics have little to do with iphone apps and desktop software. And complexity of software has no relation whatsoever to its utility.

Running a service is expensive. First you have customer acquisition, which is not magical and free as you seem to believe, then you have servers to run, email services to pay, security updates, new features, server admin, customer support .. unless you are running at an amazing scale you just cannot do that for $10/year.

> would you rather sell one hundred subscription at $120 per year or ten thousands subscription at $10 per year

Where on earth are you getting these numbers from? You don't automatically get 100x the sales if you drop the price. This is just pure fantasy IMO. More likely he is going to get 100 sales either way, because he might manage to get his product in front of 100 people for whom the problem solving value exceeds the cost, and who has a $10/yr problem?

Fact is this a product targeted at businesses. The type of people who are actually interested in paying money for someone to solve their problem do not care about the difference between $10 and $100. Do you save them $101 worth of time? Then sold! If anything I would be suspicious of a low price like $10/yr because I know it's not viable.


Selling it for $10 a year would be the same as saying, "This is a worthless toy. It isn't really worth your time to look at, much less to think about integrating."

My advice for would-be owners, never price your item based on how quickly a developer could build it. Price it based on how much pain you can solve your customer.

In this case, I would push the "so easy to integrate before you need to spend five times the cost on the first problem and still have to build or integrate it". Of course, I wouldn't make it sound that awkward. ;)


Why make this a pay monthly thing? You should offer a block of uses on a pay-as-you-go scheme, like 20 uses for $10.


I have to agree, at $120 a year I could build it. I don't think you'll be able to charge more then $10 a year.


Build, deploy, host and maintain for an hour per year? I think that might be a bit optimistic.

Certainly for an agency to do this will cost them more than an hour of developer time. $120 per year is a steal, OP should add different pricing brackets to capture more value from bigger agencies.


what sort of "agency" are you talking about? a web development agency?

I 100% agree this would take more than an hour to develop with a nice UI, and there's some ongoing maintenance, but it's still pretty low numbers. And there's still arguments for a DIY approach - for instance, Aa DIY approach means you can improve/iterate/integrate at your own pace.


Yes, a web development agency, though really any profitable business that could use this.

Each hour you spend improving/interating/integrating your DIY app is an hour of developer time that you can't bill for.

You'd easily spend over an hour per year on a DIY app. Agencies charge at least $120 per hour so the choice between building yourself or paying someone else to do it is a no-brainer.

At the enterprise level $500 is the amount employees can generally spend themselves without getting approval, so there should really be a plan at that level of pricing too.


Unless your client's problem is "I can't log in", why not just look in your log to see which browser they are on?


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 that limits log access? What if you want some non-technical or not-that-technical person to handle the issue?

As hackers, we tend toward "do-it-yourself", but there are a lot of cases where that isn't practical or economical.


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.


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.


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?


At the risk of making your service/site appear error-prone, you could make it evident on each page what a user should do if there is a problem. Basically have a method for the user to send an email to support with what is equivalent to a stack trace for that page: include their browser info, and any other relevant generic info.

Just spit-balling here.


Hate to thread-jack, but that's exactly the use case I built BugMuncher (http://bugmuncher.com) for :)


"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.


One of these gets posted on HN every month. I'm sorry, but I don't get the big deal.

https://news.ycombinator.com/item?id=4499435

https://news.ycombinator.com/item?id=3526446

and more.


And this product was already posted in one of those threads:

https://news.ycombinator.com/item?id=4499937


In my Firefox @ WinXP it displays Java 10 :)

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.

Also, the Flash version could be more detailed. http://supportdetails.com/ 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.

Now... if you used this data in a way to automate some typical developer->client BS then I could see paying for it maybe.

For example, let's say you load up a few VMs with every major browser / browser+version combo.

Then you can tell a client to goto some url, maybe it could be something like:

http://browser.somedomain.com?for=somepage.com/preview

If the client goes to that address it captures his browser details just like your site does but then:

1. Replicates his settings with one of the VM browsers.

2. Takes a screenshot of what somepage.com/preview looks like.

3. Sends the screenshot and data to my e-mail or have an API letting me get that data back in on my end.

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.


I've noticed that screenshots (a la https://browsershots.org/) don't really help either as there's no way to debug - you'd change something and need another screenshot to see what happened. I guess we'll have to integrate http://browserstack.com (which is an incredible service).


If you are doing that much to just see one simple page, might as well try something like browsershots.


I could but I would still have to send the client to some url to get his browser data so I know what to look up.

If I'm sending a client a url, why not take it 1 step further and eliminate any work on my end by just providing me the correct screenshot and info? Then I can shoot a client an e-mail, ask him to click a link and seconds later I'm looking at what he's looking at with his browser settings without having to do anything.


We semi-launched with a comment here: https://news.ycombinator.com/item?id=4499937

Just finished the Pro version and launched for real, would love some feedback from HN!


https://aboutmybrowser.com/ does the same without any signups


Oh look this one has a unique url.


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.

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.

Just my 2cents


You could also request the http info and simply show that to a person on a page. In rails it would be as simple as calling 'request.user_agent' and printing that value on screen.


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 really 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: http://supportdetails.com

But, yours supports a few more details.


The Authentication forms should ideally submit to HTTPS, but it looks like you haven't setup SSL, but should.


Would be great if it also took note of the DPI so retina-style devices could be detected.


please stop creating projects for this issue. there are already tons of them.


It reports Windows Phone 8 as Windows 8.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: