Blitz Scrolling

Digital search tools get better every day. There's system integration, global shortcuts, multimedia, advanced filtering, natural language support, and better algorithms than even a year ago. Nothing will beat a well made search tool for finding something you already know exists.

But, sometimes the keywords don't match, the available tools are bad, or you know what you need by an indescribable attribute like the shape of a table layout. A file you remember downloading but not the name of, or a photo of a place where you remember the lighting but not the date. In these cases, typically the only option is scrolling through wherever you think it is until you find it.

That might be pages of a PDF, your photo collection, or the contents of your downloads folder. Unfortunately, the things we've needed to search have scaled alongside search capabilities, and explicit organization has gone down. Brute force across the likely thousands of photos on your phone is slow, and the only way to speed it up is going through each item faster. Thankfully, this is a rare case where human limits aren't the bottleneck. You can recognize something visually distinct if you're looking for it in fractions of a second, but only if you have software prepared to show you that quickly.

I call this feature set, letting you skim through content as fast as you can process it, blitz scrolling. Speed is the main part, but it's not just about the performance. The ergonomics of scrolling (even if it's not literally scrolling) are just as important.

This isn't a requirement for your normal, everyday tools (though it's a nice bonus), it's to keep in your back pocket for when it's needed. Optimizing for blitz scrolling often requires making worse trade-offs for casual usage. Most PDF viewers aren't optimized for someone trying to skim a dozens of pages a second, and most video players expect you to watch at most at 3x speed. There's workarounds, but they don't scale well. It's much easier to miss a specific moment if you're spamming five second skips three times a second compared to watching a video at 15x speed.

Three attributes to look out for when looking for blitz scrolling tools.

Load Time and Optimization

If it can't load the content as fast as you need, it's out. For example, a file browser might let you instantly scroll through a few thousand files, but if the image previews load a second later it's not good enough. Most minor issues (e.g. stuttering during scrolling) turn up around hundreds of items, become sluggish in the thousands, and turn up major issues in the tens of thousands. Even in well optimized tools, you'll start hitting tradeoffs eventually. You'll want to audit your data and test using the higher end of what you find.

My test for ebook readers is load/search times on a file with a few thousand chapters and millions of words. This isn't a blitz scrolling test (text is too visually indistinct to be blitzed and it's by far the easiest thing to search anyway), but it's hitting the same performance requirements. If it can't even open the file in a few seconds, it's useless. It's technically possible to search that much text functionally instantly, but realistically I'll accept anything which starts showing results in a few seconds. If user interaction is frozen by the search or it takes tens of seconds to start showing results, I'll keep looking.

This is eventually limited by the quality of your hardware and how intense the content you're searching is. If you're watching a high-quality video on 15x, there's going to be frame jumps not from the sped-up frames but because the device can't decode all the frames fast enough. The criteria isn't if the software gets all the frames in on time, but how well it adapts to keep the speed going. If you skip to unloaded content in the middle of something, it should load within the second, not buffer through everything you just skipped past.

Most online tools are ruled out by this because networking is too slow. Some websites optimize for local usage, but it's exceedingly rare. Working locally on this scale will almost always be an order-of-magnitude improvement.

Input Speed

Speed includes both how fast you can input and how quickly an input is processed. Press-hold controls are much faster than spam tapping/scrolling (and more ergonomic), but neither matters if you get stuck in a mandatory transition animation. Similarly, it doesn't matter how fast you can skip through content is if inputs to stop get buffered for half a second. At these speeds, you're already racing your reaction speed to stop and will have to backtrack a bit to get to where you meant to stop. Any indeterminate input lag on top of that will significantly slow you down, especially if there's a decent false positive rate on recognition.

For software which uses literal scrolling, keep an eye out for responsive momentum based (scrolling) or high fixed speed (press-hold) controls. Momentum based scrolling is more adaptable, but difficult to use without high sensitivity and the muscle memory to stop on a dime.

Presentation Format

This varies depending on the content, but at this speed you're looking for something visually distinct. Less text, minimal framing, as much space as possible devoted to visual content. For a list of files, you want large and accurate thumbnails¹, not placeholder icons or dense tables. If you're scrolling through a PDF, page turns should have no animation and simply swap out pages in a fixed location so there's less motion to distract your eyes.

At high speeds, it may be better to have each item up for a shorter time than many items up for a longer time. I prefer to scroll through thumbnails for photos because they're so visually varied, but fullscreen PDF pages so I can focus on each page.

Imperfection

I treasure every app which even nearly satisfies all three criteria. No one is designing for this that I know of², it pops out incidentally as part of general goals to improve performance or cater to specialists. The way this use case can pop out of individual well designed features is a testament to the creators skill, if anything.

Nothing against apps which can't do the same, they're usually focusing on optimized search tools or designing to work spectacularly for the average user with human-scale amounts of data. I adore many of them both because of and in spite of these choices.

I also despise many of them for other reasons like questionable developer ethics or bad feature sets. But I still need to blitz, and they let me do that. You can't make something which hits all these criteria without someone thinking about the both performance and design. No matter how much I disagree with the rest, I have to respect that intent and effort at least.

It's the least I can do.

- Rew

Nightly Notes

Every day I tell myself I'll write more tomorrow, and every day I feel I've written less than yesterday. Feels good to get a long one out again, it's been a bit.

It took me so long to realize I was looking for this feature set, or that I was even using it. It's never the dealbreaker because it's not the core use case. Search is always the primary use case, it's too much faster not to be.

Being able to put a name to it and articulate why I'm annoyed when these specific features are missing is nice. I never feel like a power user because I'm only scraping the surface of tools made for power users, so I forget that my use case for everyday software is already outside the norm.

- Rew