This makes sense to me. I can update #2887 to use the uri of the thumbnail as the <img src>. In fact that might even be possible on this branch itself.

On a more general level, this flow doesn't support a loss of network and an upload timeout. The right implementation would have a little button that allows for retries in case of failure to upload.

We need to do the thumbnail before sending it though 😄

For retries we don't need a button, there is no reason why we shouldn't be retrying this automatically.

I noticed we are not doing that actively enough even for unsent messages. That will be a separate PR though.

Hmm. The big green box feels awfully loud to me -- almost like an error message.

(Would you post a screenshot? Good for this kind of UI discussion.)

Here's the original issue description:

When uploading an image, the upload might take several seconds or more, particularly if the image is large or the connection is slow.

We should give some visual feedback, like a progress bar, to indicate that the upload is happening.

and your reply:

Showing a progress would be quite involved (and ideally a cancel 'X' button)
But we can improve upon the current state with a much smaller feature.
We can initially just show placeholder with an indefinite spinner inside.

I think an image-shaped and -sized placeholder with a spinner -- Zulip-green on neutral background, like most of our spinners -- would probably work well.

Experimenting with it now, we do have a spinner: the usual outbox spinner shows up there just fine. So I'm actually a little curious just how users respond to the current UI -- is that spinner just too subtle? (It is pretty small.) Or is there another issue?

Hmm, in fact: what we don't have a spinner for is downloading, and rendering, the image. Experimenting with this on your branch, I still have the experience that it feels a bit stuck and I briefly wonder if it's making progress, because that part is slow and the message just looks blank. (In fact the green box might barely make it on screen for a frame or two, then it's blank for hundreds of ms and then fills in gradually from the top over a second or so.)

I think one thing that would improve the situation is if we can get the image to show as a gray box or something when it isn't downloaded yet -- then at least it would have clearly-defined boundaries in its own shape, so it's clear there is supposed to be an image there and things aren't just weirdly all blank.

Increases the maximum height of the images in the message list.
From 30vh to 40vh (viewport height). That is more consistent with
other mobile apps' image sizing and makes sure that a typical 4x3
photo will show as large as possible (touching the left and right
end of the list)

Interesting!

My initial reaction to seeing this is that it feels too tall. Here's a screenshot:

It feels like when there's an image at that height, it kind of dominates the screen and makes it hard to follow a thread of discussion from above to below.

I took a look at a couple of other apps:

• WhatsApp does about this height.
• Slack does not. The max height seems to be more like 30vh... but then to avoid shrinking portrait-shaped pictures too small, they crop the top and bottom. If you want to see the whole thing, you tap for the lightbox.
  • Much like Twitter seems to like to do, though my occasional use of Twitter is all on the web.

That difference fits with my own reaction: as much as we say that Zulip is better than Slack for having serious discussions, Slack has a need to optimize for that in a way that WhatsApp doesn't, because they are trying to serve teams collaborating.

Honestly I don't love the cropping solution either -- it often ends up displaying something that feels out-of-context. I might like it better than the status quo, which has its own way of making the image hard to understand. But I'm pretty sure I prefer either one (cropping the image, or making it smaller as we do now) over the 40vh solution -- basically, like Slack but more so, where we have to choose between optimizing the experience for reading text and seeing images, I'll pick the text.

(Maybe a cropping solution where it's somehow signalled visually that there's more that was cut off would help; I think a lot of the times that I find the cropping actually annoying are when I don't realize initially that there is anything I'm missing. I don't know of any existing demonstrations of that idea.)

@gnprice @borisyankov My two cents on this PR. I really like this and I think it will go well with #2887 which I'm cleaning up right now. I feel like we can add a simple condition class using JavaScript that determines whether an image is landscape or portrait. That way the "max" dimension could be set explicitly for both. Similar to whats described here

We don't even need any tricks. We can use the actual dimensions of the uploading image and generate a placeholder with the same proportions.
Bonus functionality if we can grab an actual thumbnail out of it and use that as a placeholder.

Sounds great!

Closing as stale and superseded by #4590.