Make it more obvious an image is resizable when uploading an image

UX
1

This drives me crazy almost daily.

  • I upload a retina screenshot
  • Immediately reach the mouse to the preview area to get the “resize controls” and size it down
  • The controls are not there on hover
  • I move mouse away
  • Then I reach back to the preview area again and the controls are there

Overall I am not even a fan of having “resize controls” a hover-only thing.

I can think of 2 options here of improving this

  1. We can fix the bug so, upload -> hover, shows controls right away.

  2. We can just display the “resize controls” unconditionally (maybe a bit more subtly)

Personally I prefer (2) but was wondering what @codinghorror and @awesomerobot and the community think here?

11 Likes
2

I don’t see this. Is it a latency thing?

1 Like
3

Extremely likely, 100% reproducible in Firefox in Australia against meta.

4 Likes
4

So the fix is relocation? :laughing:

10 Likes
5

Adding my vote for option 2. This is an extremely handy feature but I think it’s quite easy to miss if you don’t know about it.

3 Likes
6

I see no harm in showing the resizing controls in the preview unconditionally for three reasons:

The first is that we only “hide” them with opacity

which means they still occupy some space even when they’re invisible. The wrapper is absolutely positioned, but we add some padding to .image-wrapper

The second is that the feature would then work on mobile as well, which it currently doesn’t for me even though it’s supposed to work

The third is that it would increase the discoverability of the feature.

Short of that, what we can do is make it so that the controls for all images are visible when you hover the preview panel, not individual images. As well as fix the issue on mobile (which might only be limited to my devices)

If we make the controls unconditionally visible, we can also spend a bit of time on making them look nicer.

15 Likes
7

Yeah I’d prefer these to be always visible and an overlay on top of the image so the spacing doesn’t appear to be larger in the composer vs the actual post.

One reason why we didn’t originally do this is because you’d see the controls flicker terribly as you typed. I think there were some changes made that reduced the flicker, but the controls are still removed from the DOM entirely once you start typing… once that gets sorted out absolutely go ahead and restyle them so they’re always appearing @johani!

8 Likes
8

I am not seeing any flickering when I remove the opacity, so I guess we sorted the issue out?

I fixed (1) per:

But I still feel the meat here is that the issue is not properly discoverable and depends on hover.

@Johani maybe do a theme component for styling this now (since you can do pure CSS to get whatever you want) be sure to test this on a very very short image. Then install the component on dev and meta so we can live with it for a bit and decide if we prefer this or not?

8 Likes
9

Yeah I think a debounce was added at some point? Now that you fixed that first issue everything looks fine.

3 Likes
10

Wow I can’t believe 2019 was a whole year ago :lolsob:

3 Likes
11

I’m actually not in favour at all of this change personally. It makes it so much more busier. Was there any actual issue with discoverability of resizing?

1 Like