ui Suggestion: minimum size for scroll bar

[Chris Messina]

The scrollbar becomes VERY TINY when there are LOTS of results. Seems like there should be a minimum height/width?

 

[vitor]

If I saw that out of the corner of my eye I’d think it was a bug on the screen!

 

Agreed it should never get that small. Should that be a setting in the theme builder, somewhere else, or just have a new minimum which isn’t configurable?

 

The third one would be easiest to implement, and I don’t imagine anyone complaining of lack of configuration on that regard. But maybe. Perhaps there’s a fourth option: Make it a checkbox: if off, it doesn’t constrain the size; if on, it constrains it to the fixed amount of (example) a third of the height of a row (according to your theme). Fifth option! Make it a slider! “Smallest scroll bar size, in relation to result row height”: ∞ → ¼ → ⅓ → ½.

 

No preference on the option (thought the fifth is the most fun. Are there any other slider in Alfred, even?), just thinking of solutions out loud. But I agree this one makes sense to implement. It’s excellent that Alfred is so performant that the scrollbar can get so tiny, but it can impair readability at such small sizes.

[Chris Messina]

Thanks for thinking through some solutions!

 

It's funny, I actually do set different widths (sometimes very narrow widths!) in my themes in order to achieve different appearances.

 

What seems most "Mac-like" would be for Alfred to implement a near-hover behavior that grows the size of the scroller as the cursor approaches.

 

This is what macOS does, after all:

 

[Andrew]

I'm moving this to feature suggestions as this isn't a macOS scroll bar, it's a non-interactive theme-able scroll indicator. If you want it wider, you can make it wider in the theme editor. The indicator has actually been like this for the past decade, so I'm not going to treat it as a bug.

 

Having said that, there is an argument for giving it a minimum vertical size cap, even though this reduces the actual usefulness (as it currently shows quite how many results there are).

[nikivi]

Was fun seeing my workflow as example.

This is nothing though, here is me using https://github.com/lox/alfred-github-jump to search my 21,300 GitHub stars.

 

 

Can't even see it. Although personally I don't find it an issue. I use the scroll bar size as indicator of how many results are being returned so current behavior is perfect for me in achieving this.

Edited February 11, 2021 by nikivi

[Chris Messina]

8 hours ago, Andrew said:

I'm moving this to feature suggestions as this isn't a macOS scroll bar, it's a non-interactive theme-able scroll indicator. If you want it wider, you can make it wider in the theme editor. The indicator has actually been like this for the past decade, so I'm not going to treat it as a bug.

 

I agree it's not a bug and should have been filed as a feature suggestion.

 

While you can make the width wider for the theme (which would affect the aesthetics), my issue is more about functionality. Even with an enormous amount of results — I assumed that it was intended as a functional scrollbar to move vertically through results, rather than merely a "non-interactive theme-able scroll indicator".  Perhaps my expectations were too high! 

 

Anyway, not a priority — just seemed something that could be improved for workflows with lots of results...

[Andrew]

15 hours ago, Chris Messina said:

I assumed that it was intended as a functional scrollbar to move vertically through results

 

Alfred is primarily designed with keyboard and type-ahead filtering in mind, the input focus is always in the search / filter field, and the expectation is that you can always type a few characters to filter down the list of results to just the relevant items.

 

Even in your example animated image in the original post, it looks really inefficient scrolling to find something - if this workflow has been correctly designed, typing a few more characters will present you with the most relevant results, negating the need to scroll. That's why this is an indicator rather than a functional scrollbar.

 

It's very rare that I need to move past the first "page" of results because of this, and I never use the mouse with Alfred. It's also worth noting that you can really fly through pages of results using fn+down and fn+up for pagination.

 

Cheers,

Andrew

[Chris Messina]

8 hours ago, Andrew said:

Even in your example animated image in the original post, it looks really inefficient scrolling to find something - if this workflow has been correctly designed, typing a few more characters will present you with the most relevant results, negating the need to scroll. That's why this is an indicator rather than a functional scrollbar.

 

Yes — actually, if I typed a space and then some characters, the workflow would have filtered the results. You are correct.

 

Sometimes I forgot the specific text that I'm looking for so don't know which characters to type, and that's when I would use a scrollbar so that I can visually browse the results, but indeed, this is very much an edge case.

Edited February 12, 2021 by Chris Messina