Closed SEilertsen closed 7 months ago
Hey! Thanks a lot for all your issues. I know the scroll-shot requires some practice to use correctly, which is, of course, non optimal.
It seems that are two ways to fix this issue: Either some helper text/documentation on how to use the feature. Or an improved scroll shot algorithm. The last solution won't be made by me in the nearest future (by me at least). So do you think there is a way to solve the UX issue with improved documentation somehow?
Hej Nikolaj!
Jeg tager den lige på dansk (det engelske var mest så alle på projektet kunne læse det) håber det er cool?
Det er muligt man kan løse det med dokumentation – jeg synes godt nok det tager nogle forsøg hver gang at ramme en fart der giver et brugbart billede. Ved ikke om det måske også har noget at gøre med længden af scrollshottene, som gør det svært for mig at ramme rigtigt.
Jeg overvejede om man kunne lave en form for ”visualisering” af den optimale scroll-fart når man går i gang med shottet? Ved ikke om det overhovedet er teknisk muligt, men det ville være en stor hjælp at have en eller anden form for bjælke, der blev grøn, når man kunne scrolle videre - eller sådan noget lignende.
Hvis man skulle løse det udelukkende med dokumentation, kan det være man skal lave en eller anden timeframe på hvor hurtigt man ca. skal scrolle en skærmlængde. Det kommer nok til lige at tage lidt tid at lære, men er også en mulighed.
Håber det giver mening Mvh Silke
Good idea with some colored panel, indicating when to scroll further. Thank you so much for the detailed response.
(Tech alert) Also, i think we could decrease the delay between screenshots, in the scrollshot function. But beware as it is already a heavy task for desktop machines.
It is difficult to know the speed to scroll in when making the scrollshot. This results in either not capturing the whole image (if too fast) or duplicating parts of the image (if too slow).