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

Progressively add descriptions for codec settings #1366

Closed
wants to merge 1 commit into from

Conversation

aryanpingle
Copy link
Contributor

@aryanpingle aryanpingle commented Jun 1, 2023

Every codec has a ton of settings to mess around with, but the average user won't know what half of them mean. I'm adding small, slightly technical descriptions for each parameter in their respective component's title attribute so that users can hover over it and read about its purpose.

All changes are progressive, so descriptions can be added on an as-needed basis.

  • AVIF
  • Browser JPEG
  • Browser PNG
  • MozJPEG
  • OxiPNG
  • WebP
Example
image

Copy link
Collaborator

@surma surma left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an amazing quality-of-life improvement for users. Really nice work. This is a really good start.

One thing we should talk about that the text in title is effectively inaccessible to mobile users, but this is already better than having no description at all.

Maybe as a follow-up we can move to custom tooltip so that we can control when and how it appears on mobile and maybe even do rich-text formatting and links.

I also have not review the descriptions themselves just yet.

Comment on lines +44 to +62
function wrapText(text: string, line_width: number = 60): string {
const lines = text.split('\n');
let balancedText = '';
for (const line of lines) {
balancedText += '\n';
const words = line.split(' ');
let runningLength = 0;
for (const word of words) {
if (runningLength + word.length + 1 > line_width) {
balancedText += '\n' + word + ' ';
runningLength = word.length;
} else {
runningLength += word.length + 1;
balancedText += word + ' ';
}
}
}
return balancedText.trim();
}
Copy link
Collaborator

@surma surma Jun 2, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function is for the UI and should probably in src/client/lazy-app/util or something. Rather than applying the text transform here, the UI should probably do it on render.

Copy link
Collaborator

@surma surma Jun 2, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also think we can simplify this. The algorithm here should probably be something like

  • Split text into arrays of lines
  • For each line:
    • While current output line is shorter than limit
      • Add the next word from the current line to the current output line
    • Emit current output line
    • Set output line to empty string.

(This could be a great use-case for a generator)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh you're right, it would be better suited for the utilities file. I'll make a generator version as well.

Comment on lines +67 to +68
quality:
'Trade-off between compressed file size and image quality\nHigher quality means larger file sizes',
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you use template literals and dedent, we can make this more readable:

Suggested change
quality:
'Trade-off between compressed file size and image quality\nHigher quality means larger file sizes',
quality: dedent(`
Trade-off between compressed file size and image quality.
Higher quality means larger file sizes
`),

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How didn't I know about dedent till now, it's exactly what I wanted LOL. I'll use it now.


// Until we make a better way of displaying information (like with modals), displaying a simple 'title' attribute should suffice for each codec parameter
type mozjpeg_param = keyof typeof defaultOptions;
const paramDescriptions: Record<mozjpeg_param, string> = {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the logic above removed, this file can be a singular default export of this dictionary.

<option
value="0"
title={
'Standard Quant Tables given in Annex K of the CCITT paper'
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason why you put some descriptions in the meta file and some are inline? I think it’d be nice to move these into the meta file as well, so all descriptions for a codec are in one place.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanna give descriptions for params and their options (like ImageMagick for quant_table). Problem is, for intellisense to do some nice autocompletion for the getParameterDescription arguments, I'll need an interface containing all params and their options, which ends up looking very verbose IMO.

So I went with using getParameterDescription for the params, and inlining the descriptions for the options.


I'll be refactoring all of this once I finish making a custom modal component (better explanations with better UI). For now I'll try to put all descriptions in the meta file; it'll definitely look cleaner once the modal is ready.

@aryanpingle
Copy link
Contributor Author

With the Modal PR this becomes pretty much obsolete

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

Successfully merging this pull request may close these issues.

2 participants