91–100 of 139 posts
Bullshit. It's your fault. I'm your user, you took my money. We're done here. Everything is your fault.
Devs don't get that UX is all that matters for most software.
Earlier quoted context omitted.
This is a poor response: Abusive, insulting and makes only a token effort to advance the discussion. Does the fact that it sits at the top of the page mean that it's the most highly rated? And in practical terms, it seems totally theoretical. In my experience, more information is always valuable. It's not a matter of shifting responsibility, it's a matter of understanding what the problem is and efficiently getting i…
I apologize if anyone felt it was abusive or insulting, it certainly wasn't intended that way. I'm very passionate about holding myself directly accountable for the entirety of my user's experience with what they paid me for. It's possible that the message suggested by the OP would improve the user's experience, but I don't see how and the OP didn't make a case for that. Instead the article read to me as if the benef…
Unless the error message is a slightly-less-functional app, no.
Earlier quoted context omitted.
This is a poor response: Abusive, insulting and makes only a token effort to advance the discussion. Does the fact that it sits at the top of the page mean that it's the most highly rated? And in practical terms, it seems totally theoretical. In my experience, more information is always valuable. It's not a matter of shifting responsibility, it's a matter of understanding what the problem is and efficiently getting i…
I believe the key lies in the second sentence, 'Nobody cares why your site is down, and for most sites 99% of your users will have no clue what is meant by "This site is hosted by Heroku"'. My mother wouldn't care whom the hosting provider is nor understand what it is.
The hard fact is that /your app is unavailable/ and I promise that >99% of users won't care why. Did anyone care why Twitter used to Failwhale? It was down, and that sucked, and software exists these days (and has for >20 years) to eliminate single point of failure.
Earlier quoted context omitted.
The people who care that it's a Heroku issue not app issue (hint: not many) have probably already heard about the Heroku outage. Everyone else will be confused about what the hell this "Heroku" thing is. That said, if they don't use appropriate error codes (maybe 502 or 504 for Heroku issues and 503 for app issues?) they should. But I don't think error messages should mention "Heroku" by name.
I think that's true with Heroku, but gets less true as providers get bigger. If you tell a user that your service is temporarily down "because Google is down", even a lot of regular people will know what that means, and not really blame you for it.
Delusional. If it's down, it's done, and unless your product is a developer tool, >99% of people won't care why.
Why do you care? Do you think this helps your customer at all? Perhaps you're worried about your technical reputation. All you're doing is moving the blame to some part of your code to the decision you made to host on Heroku. Down is down. Unavailable is unavailable. To your customers that's all that matters. For what it's worth I think hosting on Heroku makes plenty of sense and I'm actually moving my app (Crisply)…
In my experience, users actually do care quite a bit. Back when my company was on Rackspace, we had several periods of significant downtime that weren't our fault. Customers who contacted us were very upset, but when we made it clear that it wasn't a bug with our software, but rather a problem with the hosting provider, they all calmed down. I believe there are at least a few key things a customer takes away from a m…
>"2) There's no point in getting mad at us. Sure we chose our hosting provider, but we're just as upset about the downtime as the customer is." And they're losing just as much business because /their/ site/service is now broken too. That is plenty of reason to get mad at you guys, since to them, /you are the total solution/.
>"3) This problem is affecting other websites as well. People seem to be better at handling stress if they think everyone else is stressed out too." Maybe, but then I'd just say "wow, so you have really bad planning and expect that this stuff is all very reliable then, no?" The internet goes down. Power goes out. Expect it and build around it.
>"4) There's a team of professionals working on the problem. My customers know I run a small company, and they seem to appreciate knowing that a much larger company handles the hosting." Yes, because I fully expect IBM to resolve my issue faster than a mom-and-pop store. If anything, that would make me /more/ anxious. Ever had to call Level3, Cogent, or ATT for a null route? It takes us ~1 minute and them at least 20, sometimes much longer.
Earlier quoted context omitted.
When you go to a restaurant to get lunch, and they are closed due to a power failure, do you blame them?
I agree with the other commenter that the analogies are getting stretched but I'll bite: 1. You haven't paid them for anything yet. 2. Wrong question!!! It's an opportunity . If I showed up for lunch and despite power being out (probably on the entire block or neighborhood) the proprietors were set up outside making cold sandwiches next to a sign that said "Sorry, power's out so only egg salad" I'd be thrilled. Here…
The relevant part of the analogy is that you, the end user, wouldn't actually know why the restaurant is closed. Could be a power outage, or it could be due to health code violations. Having this information accurately communicated to the customer could impact their willingness to return to the establishment.
This is misguided. Nobody cares why your site is down, and for most sites 99% of your users will have no clue what is meant by "This site is hosted by Heroku". And a good chunk of that other 1% isn't even going to bother reading the error text accompanying the whitescreen. In the end, you chose to host your site on a platform that went down. That is just as much your fault as a typo in the code. If you had a setup wi…
Couldn't agree more.
Further I wouldn't want anyone to know where the site is hosted anyway. We have some customers on a VPS at Media Temple and use custom dns so they don't see MT's dns servers (which of course they could find out if they want to check the IP obviously). They don't need to know that info. As far as they are concerned we are the vendor.
The message could simply say "We are having technical difficulties and we're working to get the service restored as quickly as possible".
Quite off topic, but I'm always sad to see really poor scalability: To my surprise, this blog post hit the top spot on HN at least briefly. My blog started throwing some app errors. I've had a couple of hit HN stories on my blog without a problem, and it was hosted from my apartment on an old server with 256MB of RAM. Now, it is static pages served through nginx, but I'm pretty sure that a few thousand hits shouldn't…
I doubt it requires anywhere near 10 dynos, normally I just run 1, and I suspect 2 or 3 dynos would work fine today... but since 10 dynos only costs 45 cents per hour, and it's presumably just for an hour or two, I simply threw two handfuls at the problem and went back to my actual work. Handling a one-time spike didn't seem like something worth optimizing when I could throw the price of a cup of coffee at the proble…
Earlier quoted context omitted.
In my experience, users actually do care quite a bit. Back when my company was on Rackspace, we had several periods of significant downtime that weren't our fault. Customers who contacted us were very upset, but when we made it clear that it wasn't a bug with our software, but rather a problem with the hosting provider, they all calmed down. I believe there are at least a few key things a customer takes away from a m…
>"1) This isn't a bug with our software. They don't need to worry about the security of their data or anything else like that." So I guess no one has ever loosed up a firewall rule when something was down to try to get it back up again, providing a perfect opportunity for someone with, let's say, stolen MySQL credentials to connect to your now-exposed DB. >"2) There's no point in getting mad at us. Sure we chose our…
Here's a related anecdote: it's common for potential customers to ask me about security before signing up. I used to actually answer them by explaining the details of our security practices, but no one understood what I was talking about. Now I tell people that the site is hosted on Amazon's servers so we can take advantage of the infrastructure they've built. Obviously this is a non-answer, but it makes people feel a lot better. They knew they wouldn't be able to evaluate our security anyway, they just wanted some sign that they can trust us (and they already trusted us because we're the only company that picks up the phone when they call).
So I guess what I'm saying is that when you're dealing with technology, it's good to be rational. When you're dealing with people, emotions are what matter.
[1] Just so you know, one other thing that I would say during the downtimes was that we were in the process of switching from Rackspace to Amazon precisely because of these problems. We weren't just sitting around accepting them. Since making the switch, the service has been rock solid, so customers know we meant what we said.
https://devcenter.heroku.com/articles/error-pages#customize_...