There are a number of potential improvements to Media Viewer that could be considered in order to improve the speed perception experienced by users. However, there is no good way to verify that our intuition about these effects is correct. We need a solid way of user-testing 2 or more options in order to determine which one universally "feels fastest" to users, for any given product. Ideally it should be easy to set up, as we might have many combinations to test and we'll probably want to have a large sample of users to make the results meaningful.
Here are examples of hypothetical changes that may improve or worsen perceived speed on Media Viewer, which have been floating around as ideas or changesets but not merged because there's no good way to tell if they're really improvements:
- Getting rid of the animation from the blurred blown-up placeholder to the final image. While at first glance it might seem obvious that no animation is better (after all, we'd be displaying the visual information as soon as it's available), the jarring change might bring more attention to the waiting time that just happened.
- Switching from a blur effect to a pixellation effect for the placeholder.
- Having no effect at all and displaying the blown-up placeholder as-is, JPG artifacts and all.
- Not displaying any placeholder (leaving the screen black, or the previous image if any)
- Displaying a spinner on the thumbnail while Media Viewer's JS is loading.
- Displaying a black screen with minimal UI, including an indefinite progress bar while Media Viewer's JS is loading.
- Displaying an indefinite progress bar on the thumbnail followed by a real progress bar, until the actual image is loaded at which point we display the Media Viewer UI, including the sharp image.
- Displaying an indefinite progress bar instead of the real progress bar for images. The organic jumping of the real progress bar due to network conditions might feel distracting or frustrating.
- Not displaying the progress bar at all on fast connections. If the progress bar appear for less than a second/X milliseconds, it might be a distraction that makes the interface feel slow, while displaying the progress bar might be a useful placeholder when it takes several seconds to load the image. I.e. depending on how long it's on the screen for, the progress bar might be a good or a bad. An easy way to test this is to make the progress bar appear only if the loading has been taking more than X milliseconds.
- Adapting the preloading distance depending on how fast the person is prev/nexting images.
- Displaying the progressive vertical appearance of the image loaded so far, on top of the existing UI
- Displaying the progressive vertical appearance of the image loaded so far, on top of the existing UI minus the progress bar
- Displaying the progressive vertical appearance of the image loaded so far, on top of the existing UI minus the blurry placeholder
- Displaying the progressive vertical appearance of the image loaded so far, on top of the existing UI minus the blurry placeholder and the progress bar