search

SuffolkLITLab / docassemble-AssemblyLine

Quickly go from a paper court form to a runnable, guided, step-by-step web application powered by Docassemble. Swap out branding and pre-built questions to meet your needs.
https://suffolklitlab.org/docassemble-AssemblyLine-documentation/
MIT License
42 stars 5 forks source link

Stop shifting the layout when displaying document previews #311

Closed BryceStevenWilley closed 2 years ago

BryceStevenWilley commented 3 years ago

When showing document previews, we aren't specifying any width or height of them, so there's a few seconds before the full pdf image loads where nothing is shown on the screen, and then suddenly shifts. This kinda sucks for users, who might try clicking on "next" before the screen suddenly changes and they end up clicking on the preview.

I think it's referred to more broadly as layout shift, and Google's webdev page has some more good info on how to fix it.

nonprofittechy commented 3 years ago

@plocket ? Feel free to remove yourself if not interested

plocket commented 2 years ago

I don't want to mess with how a DAFile handles itself in markdown, so I've made a new method to show the file with hardcoded dimensions. What's a descriptive name for this method? .show_stable_preview()? .as_dimensioned_preview()? .get_dimensioned_thumbnail()? Other ideas?

plocket commented 2 years ago

Currently trying to understand how responsiveness can fit into the picture. Hard-coding the width and height just gives the browser an aspect ratio, the images don't have to stay that size. To that end, it would be nice if we could figure out the aspect ratio of the file ourselves without the developer having to hand it in to us.

That and it might be worth experimenting with bringing the .show() width back in and keeping its max-width attribute, just adding height: auto or something, as described in [the google link and] https://blog.logrocket.com/jank-free-page-loading-with-media-aspect-ratios/.

Does someone know off-hand how to get the dimensions of a PDF (or, ideally, all types of files).

I wonder if just adding that information to the function description would be enough to clarify that for developers or if there's a way we could change the names of the parameters to more clearly express what's they're doing.

plocket commented 2 years ago

For the future

getting PDF page dimensions: https://stackoverflow.com/questions/6230752/extracting-page-sizes-from-pdf-in-python. Not sure what PDF libraries we use.

video/audio possibly: https://stackoverflow.com/a/45416805/14144258

[Not too far distant future, I hope. I'm working on an upstream update now.]

plocket commented 2 years ago

The current PR won't address the layout shift that the audio control switching creates. I'm not yet sure how we can handle that.

plocket commented 2 years ago

Is this resolved by https://github.com/jhpyle/docassemble/pull/491?

plocket commented 2 years ago

Update with the fix was released in https://docassemble.org/docs/changelog.html#1315---2022-01-06, though the changelog doesn't show it. Have to look at the diff.

BryceStevenWilley commented 2 years ago

Ran a quick report with Lighthouse, on test_aldocument, the cumulative layout shift is only 0.054, which is great (don't have any data to compare against before, but eh).

That last remaining layout shift (which could be big enough to shift a clickable element up a line) comes from the audio control elements, which are at the top of the every page we use. It's minor, but it would be nice to reduce that as well, so I made a new issue, and continuing this there.