Show HN: Stop asking your clients "What browser are you on?"
browser-details.com
browser-details.com
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.
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...
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.
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.
So is having a user read stuff over the phone that you already know.
Any anti-virus, content filters, other browsers etc are up to the user to sort out - it's in their contract.
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.
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.
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?
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.
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 test how it works creating your own: http://www.justinsamuel.com/2006/03/11/howto-create-a-self-s...
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 don't think there is a nice solution for the other problem =)
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.
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.
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.
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/...
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?
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.
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.
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.
Once the email is submitted it goes right into our support queue.
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'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.
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)
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.
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.
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.
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.
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. ;)
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.
In some organizations, he is not even allowed to read operational data without pre-screening.
Just spit-balling here.
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.
https://news.ycombinator.com/item?id=4499435
https://news.ycombinator.com/item?id=3526446
and more.
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.
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.
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.
Just finished the Pro version and launched for real, would love some feedback from HN!
Tested with Opera and Chrome. (Firefox supports it as well.) Could lead to some confusion.
Just my 2cents
But, yours supports a few more details.