Hacker News Reader

> 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"?

To be wildly pedantic, pessimistic rendering would then be immediately showing an error, only to later clear the error away if the request is successful.

I got thrown recently by an update log (powerapps solutions) which seems to do exactly this - an in-flight install/update is shown as a failure until it completes. Eventually figured out I should ignore entries with a null completion time.

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.

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

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

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.

It's especially bad if you're on mobile and in an area that might have spotty reception.

You post a message, it looks good, you move on.

Then later on you come back to it and it was never sent.

The new Slack on mobile is absolutely unusable. There are no way to know if the interface is up to date, when was the last update or to force an update.

The only way I found to know that your message has been received is to have an ack from your interlocutor.

My personal conspiracy theory is that Slack likes the way users "engage" with the mobile app when indicator badges don't clear right away. Often you will open the app because you see the badge, only to realize you've already read the message and the badge just hasn't cleared. They're hoping that you will then click something unrelated in the app, thus increasing "engagement".

Optimistic updating is when the message moves from the chat box into the conversion thread. It assumes that in most cases the message will be sent and it makes sense to update the UI. Usually though it’s accompanied by an indication of some kind to also show progress. If slack doesn’t indicate it in anyway that’s confusing.

I wonder if this is why slack for iOS (not sure about Android) will load the notification badge from the server before loading the actual messages, so when those get out of sync the UI is essentially saying "Someone is trying to contact you but that's all I can tell you".

> Facebook Messenger has the best UX paradigm for this I've seen

Viber had a similar thing long before FB's messenger: single gray check mark character if the message is sent, double gray check mark if it is received by the recipient and double check mark in purple if it is seen.

The only issue is with the purple color of the "seen" as it can sometimes blend into an image behind it (if the message was consisting of an image).

> 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 fixing things the right way.

Network roundtrip is still going to introduce noticeable latency even assuming everything else is literally instant.

>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.

> 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

>>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...