Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Numeric value for quality slider & allow inputting those values via keyboard #242

Open
alexkaessner opened this issue May 10, 2021 · 4 comments

Comments

@alexkaessner
Copy link

I’m not sure why the quality slider doesn’t show a numeric value. Would be quite nice to see a percentage. Especially when experimenting with different file sizes, I could then remember which quality value I used the last time.

Combined with that it would also be handy to just type in a specific value for the quality or FPS. This way, I don’t have to fiddle around with the slider to get my desired values. GIF Brewery 3 supports that for some sliders and I like that it’s not that prominent with a normal textfield frame:
GIF Brewery

@sindresorhus
Copy link
Owner

Thanks for the feedback!

I’m not sure why the quality slider doesn’t show a numeric value.

I just never had a need to see the exact percentage, so I didn't add it initially. And in the 3 years Gifski has existed and with hundreds of reviews and feedback, no one has requested this. So doesn't seem like it's important, but I also don't have any argument for why we shouldn't add it.

@kornelski Any opinions?

Combined with that it would also be handy to just type in a specific value for the quality or FPS

I generally like small conveniences. We have up/down arrow key support for the text fields, for example. But in this case, I don't think it would save a lot of time. Instead of dragging the slider, you would have to double-click a tiny text field and then write the number. I'm pretty neutral about it. Lets see what other people think.

@kornelski
Copy link
Collaborator

The quality is an approximation, so I see no point entering exact numbers. People will be upset with me when I tweak the algorithm and change meaning of their favorite number.

If you want to make it easier to select consistent quality, I suggest changing it from a number to low/medium/high/max.

@vadimdemedes
Copy link

I just never had a need to see the exact percentage, so I didn't add it initially.

I agree with this. In all my time of using Gifski, I had never even touched the quality slider, to be honest.

As for FPS, sometimes I tweak it and see how it affects the estimated file size. Also, I don't think a text input would be useful for FPS either, because the step in the slider is pretty smooth, so it's easy to drag it to a desired value. If the range of values was in hundreds, for example, then yes, a text input would be more convenient.

If you want to make it easier to select consistent quality, I suggest changing it from a number to low/medium/high/max.

That's a good idea, although I wonder how long until someone suggests "better defaults".

@alexkaessner
Copy link
Author

So doesn't seem like it's important, but I also don't have any argument for why we shouldn't add it.

I always find it better to have some reference for a slider. Otherwise, as a user I don’t know in what kind of range I’m moving. What are the lowest and highest values I can get? Is it just a fine detail or does it make actual big differences. Not really easy to grasp.
Though yeah, the quality is admittedly a rather abstract thing anyway. Maybe I’m a bit of a numbers nerd in that regard, that I want to see the exact values.

The consistency topic is also maybe more of an edge case, but on the other hand a numeric number wouldn’t hurt or look too bad anyway. 🤷

I generally like small conveniences. We have up/down arrow key support for the text fields, for example.

Yes, I love this!! 👌 Should be a system-wide standard for numeric input if you ask me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants