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

151–160 of 225 posts

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

#151

Post by gravitas »

JMTQp8lwXL wrote: post #136
jacquesc wrote: post #13

This backend outage reveals how horrible the Slack UI is implemented. You post a message.... you think it got sent. Then 1min later, it tells you it was not.

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…

> 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 checkmark means the other end has received (assuming read receipts are enabled, Signal allows them to be turned off for privacy reasons).

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

#152

Post by hansvm »

n4r9 wrote: post #143
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…

> pessimistic rendering: waiting for the server response before updating the UI I hate the phrase "I'm a realist not a pessimist" as much as the next person, but isn't this actually "realistic rendering"?

It depends on your frame of reference. If the message succeeds then there will be a window (all else equal and no funny business in the networking, around 1/2 round trip time) where the UI displays the message as spinning when it has in fact been successfully sent. If your frame of reference is not whether the message has been successfully sent but whether you know for certain that it has been successfully sent then I think you'd be right to call it "realistic rendering", but from the message's frame of reference "pessimistic" isn't a bad choice of words.

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

#153

Post by akiselev »

aidos wrote: post #126
brundolf wrote: post #44

Earlier quoted context omitted.

It's not an implementation detail, it's a whole (controversial) UX design pattern: https://www.smashingmagazine.com/2016/11/true-lies-of-optimi...

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…

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

It's not a 1-3% failure rate for the backend, it's a 0.01-0.1% failure rate for each request between dozens of microservices each with their own bespoke error handling, each owned by a team with more political clout than the frontend guys/gals who keep reporting Sentry errors due to "UnknownNetworkError" or some other such nonsense, all wrapped in some spaghetti code frontend thats written like the whole thing is running locally.

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

#154

Post by gomox »

gomox wrote: post #33
jacquesc wrote: post #13

This backend outage reveals how horrible the Slack UI is implemented. You post a message.... you think it got sent. Then 1min later, it tells you it was not.

You can tell it was built for Silicon Valley. The marginally lighter gray tone on unsent messages is only noticeable by design-aware people on fancy IPS monitors. Messages are reordered semi-randomly.

Did some poking around with Chrome dev tools.

The RGBA value for the "unsent" text is #1d1c1db3. Normal "sent" (or "attempting to send but haven't yet decided sending will fail" is #1d1c1d. The RGBA value (alpha = 0.7) ends up being equivalent to #616161 when rendered over white background which the Slack default skin does.

Demo for reference: https://jsfiddle.net/9smqe8y7/

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

#155

Post by jlokier »

n4r9 wrote: post #143
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…

> pessimistic rendering: waiting for the server response before updating the UI I hate the phrase "I'm a realist not a pessimist" as much as the next person, but isn't this actually "realistic rendering"?

The terminology is occasionally used with a more technical meaning in algorithms, so perhaps that's how it's being used here.

"Optimistic" often means "assume X, perform or calculate something, change the result if X turns out to be false".

"Pessimistic" often means "assume not-X, perform or calculate something, maybe change the result if X turns out to be true".

This comes up in other domains.

For example in compilers (and reverse engineering decompilers ;-) there are optimistic and pessimistic analyses.

An optimistic analysis might initially assume a particular variable has a specific value at a particular location, or a branch is always taken. Then trace through the program paths, using that assumption (which limits those paths). If it loops back to the location with a different value in the variable or different value for the branch condition, broaden the assumption and update the trace.

A pessimistic analysis might initially assume the variable at a particular location could have any value because it hasn't yet traced everywhere to find out the possibilities, or initially assume both directions at the branch could happen and include them both in the trace. By the time it finishes tracing all paths and values, those assumptions may turn out pessimistic and it can start pruning away unused options.

These two strategies can yield different answers, and for some analyses the optimistic strategy gives more accurate results than the pessimistic strategy.

So which one is more "real"? :-)

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

#156

Post by brundolf »

aidos wrote: post #126
brundolf wrote: post #44

Earlier quoted context omitted.

It's not an implementation detail, it's a whole (controversial) UX design pattern: https://www.smashingmagazine.com/2016/11/true-lies-of-optimi...

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…

On Slack it's only ever been an annoyance for me, because at least they visibly tell you when the message eventually fails to send. But on services like Twitter I feel gaslit when I've liked a tweet and then I scroll by it again later, un-liked. It undercuts my faith in the integrity of the entire interface. Any part of it could be lying to me in a way I may never find out about.

Overall I strongly dislike this UX pattern. Users should have immediate feedback about actions that haven't completed, but that feedback should only tell them the truth: that the operation has begun.

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

#157

Post by gtk40 »

strgcmc wrote: post #134

Just imagine what it's like for Amazon, that just rolled out Slack internally last 1-2 months. (hint: it's not great, but at least we can fallback to Chime)

Interesting. They keep trying to push Chime on us, so I'm surprised to hear they're using Slack internally.

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

#158

Post by jlokier »

sdflhasjd wrote: post #69
brundolf wrote: post #44

Earlier quoted context omitted.

It's not an implementation detail, it's a whole (controversial) UX design pattern: https://www.smashingmagazine.com/2016/11/true-lies-of-optimi...

It's pretty necessary to inform users when messages haven't sent though, especially when these little failure indicators are hidden in the channels themselves - i.e you need to be looking at the message to know it failed. If I post a message in a channel and go back to work, I don't want to find out later when I check for replies that my message didn't actually send - I need a notification!

A proper alert on send failure sounds like a good idea.

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

#159

Post by jlokier »

breatheoften wrote: post #91
gomox wrote: post #33

Earlier quoted context omitted.

You can tell it was built for Silicon Valley. The marginally lighter gray tone on unsent messages is only noticeable by design-aware people on fancy IPS monitors. Messages are reordered semi-randomly.

I frequently send - edit send - edit the same message in an effort to reduce the number of typos. Recently i've realized that this actually introduces more typos -- where a large number of phrases are duplicated or corrected typos reapplied. There's something wrong with slacks operational transform or CRDT implementation or whatever they use to get edited messages to converge

It's almost as if you're describing LinkedIn...

(Where a message sent doesn't match what was typed sometimes.)

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

#160

Post by [deleted] »

arbitrage wrote: post #58
notyourwork wrote: post #16

Earlier quoted context omitted.

Just experienced this and decided to context switch to hackernews for a few minutes. Ironic that this post is the top on homepage.

That's the opposite of irony, as one would absolutely expect weirdness on Slack to be talked about on HN.

[deleted]
Post reply on HN