Slack was down

TL;dr- complex systems are complex, and trying to understand them isn't usually possible for outside parties.

Bridges are also super handy for integrating with IRC, Slack and similar.

If I own this service, it's not enough that I just reboot the service when it goes down. I'm now responsible for when it's slow, when it doesn't do what someone expects, when the user doesn't understand what the service does correctly, when someone forgets their password, etc.

"Foo as a Service" is as much (or more) about transferring the customer service responsibilities for dealing with the end users as it is for delivering the service itself.

This is a pretty reasonable complaint when you're talking about a system with 2gb, and a chat application that uses 1.5gb of memory...or heck, a 16gb system when you have programs that legitimately need as much memory as you can give them and are being starved of it. Nobody would begrudge this usage if it was necessary for the task, but it isn't. Not even close.

Edit: Apparently this is better than it used to be, but there have been times when Slack also ate up CPU like crazy. Which, again, no biggie if you have plenty to spare, but when you don't...and even then, if you have plenty to spare, you're still going to be annoyed with Slack if it's eating all of your battery because the CPU is working really really really hard at...um...dunno? If it were mining bitcoin/monero without your knowledge or consent then at least it would be DOING something.

> 1. While today's incident was unfortunate, Slack has been historically reliable.

Screen sharing and video have not been reliable in the past month. With several public incidents.

> 2. There's a team of real people that works very hard to keep it that way. Using dismissive language just dumps all over their hard work.

I feel very little sympathy for an engineer who make couple of hundred thousands per year. Not accounting stock options, vacation, and work environment. And Slack won't fire the culprit.

> 3. It's easy to be dismissive but once you move away from Slack you'll realize how much an app that size gives you. IN other words the "sucks less" statement has shades of ignorance, and of course subjectivity

We invest our own time building integrations. Why should be doing that for Slack and not for the competition?

> 4. Why be rude at all? Even if you don't buy into any of the above, is it that hard to be nice in making a point?

I don't think OP's "It sucks" is dismissive or rude. You can be nice and still thinking something sucks. It helps no one to lie by choosing less explicit words.

You won't be able to receive new e-mails, but if you use a local client like thunderbird, you can still access your old e-mails.

With slack down, I can only access the messages that I (luckily) have cached locally.

Yes it has and it is a great thing - hopefully no messages would be lost assuming that downtime is relatively short. This still does pose a (possibly minor) problem when some mails are urgent.

Except that you could work from home, check your e-mail using mobile.

Blackberry was absolutely massive before the iPhone, email has always been the largest use of the internet (until media became possible), and Google search became successful because it actually worked, unlike everything available at the time.

I do agree with your sentiment, though. To the user, the UI is the product.

Take slack as an example: ircd with logging enabled + elastic search/sphinx/lucene + web frontend (use any existing web irc client and integrate that with elastic search results). MVP really seems as a one guy one weekend project. And that was lying underutilized for decades. While my original comment was just a snarky remark, I really think that there are other areas where such a (relatively) simple MVP could allow huge productivity boost to many businesses and allow them to use an existing tool that right now is just too hard/too complicated to use by a wide audience.

And of course the market will reward those that will find the right solution and come up with a great UX improvement to that tech. The hard part is creating the GUI that is both efficient and easy-enough , and the hardest part is of course finding the right tool and the right problem to solve. (edit: formatting)

Pretty tangential, but I observed that exact phenomenon recently after looking at the recent VR headsets: Oculus Rift and HTC Vive existed for at least a few years. Tried them, was pretty fun, but tangling with wires, having to have a powerful PC on hand, that 1-2min set up every time before you want to use it, it was all killing the usability for me.

Then Oculus Quest comes out earlier this year. Pretty much similar tech (a few differences, no need for PC, but can be used with one through easy sideloading), but no wires and no need for a PC connection. Every time I want to use it, I don't need to fiddle with my PC. I put the headset on, it wakes up in a few seconds at the exact spot I left it last time. I put it down, it goes to sleep in 15 seconds.

I ended up spending an hour or two almost every day for the past two months playing with it, as opposed to the previous headsets (most of which were left on the shelf a few weeks after the initial purchase). The only major advantage that Quest has over previous gen is easy and frictionless UX.

It got to the point where every single friend of mine who tried it at my place ended up purchasing their own headset the day after. And those people were some of the biggest VR skeptics, after their experiences with original Vive and Rift.

What can be said with writing can also be said with speech.

But with speech, you also have verbal queues, pauses, tone, inflection, that implies so much more.