Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Users may be unable to connect or experiencing degraded performance

status.slack.com

Post reply on HN
Print view View original

171–180 of 225 posts

Re: Users may be unable to connect or experiencing degraded performance

#171

Post by KajMagnus »

radicaldreamer wrote: post #108
c17r wrote: post #107

Earlier quoted context omitted.

I worked on a project that used this, I hated it. The excuse I was given repeatedly was "it's unlikely to fail" which I kept responding with "but when it does, the user is already 3 pages away and we have no good way to tell them so they're SOL"

You could surface a notification when it fails...

The user might have navigated 3 pages away to a different website ... Or exited a mobile app. (But well yes I suppose notifications are better than nothing)

I somewhat often send messages just before I have to run to catch the subway — and when I think the message got sent, I type `sudo poweroff`

Re: Users may be unable to connect or experiencing degraded performance

#172

Post by war1025 »

the_duke wrote: post #46

I have intermittently faced each of these issues over the last hour across several European and a US Slack: * Messages are shown as sent (not grey), then, after several minutes, a "Try to send again" message appears. Or the message turns grey. Or both. * The webapp randomly reloads. Sometimes already typed messages are preserved, sometimes they disappear. ( I assume a reload happens when a new version is deployed wit…

> The webapp randomly reloads. Sometimes already typed messages are preserved, sometimes they disappear. ( I assume a reload happens when a new version is deployed with some "force reload" flag )

I have been seeing some version of this on my laptop for months. Don't seem to have the same issue on my work computer. Maybe it will finally get resolved.

Re: Users may be unable to connect or experiencing degraded performance

#173

Post by gravitas »

ubercow13 wrote: post #161
gravitas wrote: post #151

Earlier quoted context omitted.

> Facebook Messenger has the best UX paradigm for this I've seen FYI, Signal has used this paradigm for quite some time (I'm not sure which software predates the other on this feature), it's two checkmarks which remind me of the old "open Apple, closed Apple" keyboard keys - message bubble is shown with two open checkmarks right away, a single closed checkmark means the server has received, the second closed checkmar…

I seem to remember BlackBerry Messenger doing this 15 years ago, I don’t think Facebook or Signal were close to being first

nod From a corporate reliability (and possibly auditing) perspective, this seems like a bread & butter feature for Blackberry back in it's heyday.

Re: Users may be unable to connect or experiencing degraded performance

#174

Post by war1025 »

ifaxmycodetok8s wrote: post #122
rexreed wrote: post #60

Is Discord a viable alternative to Slack? If not, why not?

If you're question is it a viable alternative to Slack for business purposes, the answer is no. And it's not bc of anything related to the application itself but because of the insane TOS. > By uploading, distributing, transmitting or otherwise using Your Content with the Service, you grant to us a perpetual, nonexclusive, transferable, royalty-free, sublicensable, and worldwide license to use, host, reproduce, modif…

Are these licenses actually enforceable?

Those absolutely seem like overreach in terms of what someone would consider reasonable from a user perspective.

Re: Users may be unable to connect or experiencing degraded performance

#175

Post by Wohlf »

throwawayy1001 wrote: post #163
JMTQp8lwXL wrote: post #136

Earlier quoted context omitted.

The concept is called 'optimistic updating' and the intent is to make the UI 'feel faster' by assuming a positive response from the back-end, and only reverting when things go awry. Given the vast majority of messaging attempts will complete successfully, it's easy to see why the interaction pattern is used. The converse is pessimistic rendering: waiting for the server response before updating the UI (and possibly sh…

> The concept is called 'optimistic updating' and the intent is to make the UI 'feel faster' by assuming a positive response from the back-end, and only reverting when things go awry. Given the vast majority of messaging attempts will complete successfully, it's easy to see why the interaction pattern is used. It's easier than making the UI and server faster for sure, I'm just not sure why engineers don't insist of f…

>I'm just not sure why engineers don't insist of fixing things the right way.

That's like saying "just fix global warming", it's more complicated than that.

Re: Users may be unable to connect or experiencing degraded performance

#176

Post by aidos »

TeMPOraL wrote: post #169
aidos wrote: post #126

Earlier quoted context omitted.

I didn’t know it was that controversial. I feel like that article is making a bit of strawman argument from the get go by talking about 1-3% failure rate from the backend. If I had a system that flaky, I’d be taking a good hard look at myself before blaming anything on my optimistic UI :-) There are other things to consider too. Like for example network failures vs backend failures. In the case of network failures yo…

The problem with failures and optimistic UI isn't that failures happen often - it's that they're not uniformly distributed. I do not have a 1% or 0.0001% chance of experiencing failure any given message. I have 0.0001% chance of experiencing failure, unless I'm currently in a tunnel, or my ISP breaks something again, or [insert dozen other infrequent client-side failure modes], at which point my failure rate briefly…

That’s what I was saying above, you can detect those scenarios a lot of the time and handle them reasonably. Oftentimes they’re temporary and will resolve without losing any data (in a well designed system). Like I say, you can even head those off before the user knows about them.

There are trade offs to consider in UX. You’re trying to make things as seamless as possible for the end user without distracting them with things they don’t care about.

Re: Users may be unable to connect or experiencing degraded performance

#177

Post by mike_d »

throwawayy1001 wrote: post #163
JMTQp8lwXL wrote: post #136

Earlier quoted context omitted.

The concept is called 'optimistic updating' and the intent is to make the UI 'feel faster' by assuming a positive response from the back-end, and only reverting when things go awry. Given the vast majority of messaging attempts will complete successfully, it's easy to see why the interaction pattern is used. The converse is pessimistic rendering: waiting for the server response before updating the UI (and possibly sh…

> The concept is called 'optimistic updating' and the intent is to make the UI 'feel faster' by assuming a positive response from the back-end, and only reverting when things go awry. Given the vast majority of messaging attempts will complete successfully, it's easy to see why the interaction pattern is used. It's easier than making the UI and server faster for sure, I'm just not sure why engineers don't insist of f…

> I'm just not sure why engineers don't insist of fixing things the right way

Einstein figured out why in 1907, and most of us have just been going along with the assumption that superluminal communication just isn't possible.

https://en.wikipedia.org/wiki/Tachyonic_antitelephone

Re: Users may be unable to connect or experiencing degraded performance

#179

Post by linsomniac »

"Uptime for current quarter: 99.97%" AFAICT, this outage has been going on 6 hours and is still showing a ton of services as "Incident" status in the slack status page. Seems like uptime could be more like 99.7% and dropping.

But, how do out count downtime of a distributed system? We probably need a new way of discussing availability.

An outage to part of your system might only impact one or a group of users, but to those users you could have been 100% down, effectively, even as other users were not impacted at all.

So maybe a series of user/%age counts? "This quarter 90% of our users/use cases had 100% availability", for example. With the gold standard being 100/100. Maybe numbers for 99, 90, and 50% of users/use cases? IOW: "1% of our users had 95% availability, 10% of users had 99.9, and 50% of users had 100%."

Re: Users may be unable to connect or experiencing degraded performance

#180

Post by NikolaNovak »

throwawayy1001 wrote: post #163
JMTQp8lwXL wrote: post #136

Earlier quoted context omitted.

The concept is called 'optimistic updating' and the intent is to make the UI 'feel faster' by assuming a positive response from the back-end, and only reverting when things go awry. Given the vast majority of messaging attempts will complete successfully, it's easy to see why the interaction pattern is used. The converse is pessimistic rendering: waiting for the server response before updating the UI (and possibly sh…

> The concept is called 'optimistic updating' and the intent is to make the UI 'feel faster' by assuming a positive response from the back-end, and only reverting when things go awry. Given the vast majority of messaging attempts will complete successfully, it's easy to see why the interaction pattern is used. It's easier than making the UI and server faster for sure, I'm just not sure why engineers don't insist of f…

>>It's easier than making the UI and server faster for sure

In majority of cases, I assume network latency will be the dominant factor, and that is outside the control of the engineers.

I happen to use slack from hardwired gigabit ethernet to a gigabit fiber internet connection. But I maintain some awareness that some others may use it from their older android phone with 2 bars of service, or on a laptop with 27 open blasting wifi spots, etc etc etc.

I will therefore put forward that assumption you can ensure instant communication, is the wrong wrong wrong way for engineers to write code...

Post reply on HN