rosell-dk / webp-convert-filemanager Goto Github PK

See rosell-dk/webp-express#515

Let user select between proposed variants.

• Original is always available (put an .ignore file with otherwise same name as the converted)
• Existing is available if there is an existing conversion
• A lossy conversion, using default options (and lossy)
• A lossless conversion, using default options (and lossless)
• Unless lossless is a much smaller file, also let user see lossy conversion with quality parameter +10% and -10%
• Unless lossy is a much smaller file, also let user see lossless conversion with quality parameters +10% and -10%

They are presented as images side by side. Each image have a caption, ie "Existing conversion, 126kb" or "Lossless, q:80, 103kb". The images starts at zoom:100% and are cropped. A zoom slider can be used to zoom in or out on all images simultaniously. It should also be possible to move the viewports, ie by dragging. It should be quick and easy to select the desired variant. Ie by clicking on the image or a "select" button next to the image.

We could consider to allow another view, where the images are on top of another and radiobuttons to switch between the viewed variant.

We could additionally allow the user to add new variants. Ie a "-10%" button to add a variant with further quality reduction, and a "+10%" button.

We must add an optional "variant-id" option to the convert api, which gives the conversion a variant id.
We also need to add "select-variant" in the api.
When a variant is selected, the others are deleted.
If none are selected, the server can delete the variants after a period (say, half an hour)
The server could simply store the variants along the other conversions, using some naming scheme. Ie "logo-variant01.jpg.webp". This however introduces a minor risk of name clashing. To eliminate that risk, it is better to store the variants in a dedicated folder - this also makes cleaning up lingering variants easier.

https://dev.to/myogeshchavan97/how-to-create-and-publish-an-npm-package-20ln
https://vuejs.org/v2/cookbook/packaging-sfc-for-npm.html

Allow managing named presets.
Make it possible to quickly convert using a preset.

The presets could also be part of a rule setup.
Ie:

• if imageType equals "png", choose the preset named "PNG"
• if folder matches "highres", choose the preset named "HighRes"
• if file size is smaller than 10kb, choose preset named "Thumbnails"
• if folder matches "download", skip conversion
• else fall back to preset named "Standard"

Don't know about the rules, though. Seems they are mostly relevant for depending on imageType.

Let users compare the results of different convert options.
Two panes, two sets of conversion options.

In order to make sub options, we could make nesting like in JSON Schema - using type:object and "properties"
However, we need ui for sub options too, so it is not that great that these are separated (currently we have a "schema" property which holds the schema definitions and a "ui" property, which holds UI definitions, and these are siblings)
Suggestion: Flatten the structure. Remove "schema" object and put all its properties into parent.
Will this make the schema "dirty"? yes. It will not pass "strict" mode with unknown properties such as "ui" and "sensitive" (https://github.com/zaggino/z-schema#noextrakeywords)
But well well, webp-convert can be created such that it can return both clean JSON Schema and this hybrid.

Here is what it would look like:

{
    "title": 'Options',
    "ui": {
        'component': 'group'
        'title': 'Options'
    },
    "type": ['object'],
    "properties": {
        "general": {
            'title': 'General options'
            "ui": {
                'component': 'group'                
            },
            "type": ['object'],
            "properties": {
                "auto-limit": {
                    "title": "Auto-limit",
                    "description": "Enable this option to prevent an unnecessarily high quality setting for low quality jpegs. You really should enable this.",
                    "type": ["boolean"],
                    "default": true,
                    "ui": {
                        "component": "checkbox",
                        "advanced": true,
                    }
                }
            },
            ...
        },
        "cwebp": {
            'title': 'General options'
            "ui": {
                'component': 'group'                
            },
            "type": ['object'],
            "properties": {
                "command-line-options": {
                    "title": "Command line options",
                    "description": "",
                    "type": ["string"],
                    "default": ""
                    "ui": {
                        "component": "input",
                        "advanced": true
                    },
                    "sensitive": false
                }
                ...        
            }
        }
    }
}

A down side of above: UI and data structure becomes 1:1 (it already is, though - but we could alternatively solve the problem by totally separating ui and data and defining the data relation in the ui).
But maybe its not that bad to have this forced 1:1 relationship with UI and data structure. Server-side can reorganize if need be. So, this is simply the "UI data structure", which can be transformed.
But perhaps we need more UI components than data structure. Can we deal with that?

How would we implement separate ui and schema?
Perhaps something like this:

schema

{
    "title": 'Options',
    "type": ['object'],
    "properties": {
        "auto-limit": {
            "title": "Auto-limit",
            "description": "Enable this option to prevent an unnecessarily high quality setting for low quality jpegs. You really should enable this.",
            "type": ["boolean"],
            "default": true,
        },
        ...
        "cwebp": {
            'title': 'Cwebp options'
            "type": ['object'],
            "properties": {
                "command-line-options": {
                    "title": "Command line options",
                    "description": "",
                    "type": ["string"],
                    "default": "",
                    "display": "notEquals(state('data', 'encoding'), 'lossless')"
                }
                ...        
            }
        }
    }
}

ui:

{
    'component': 'group'
    'title': 'Options'
    'sub-components': [
        {
            'component': 'group'
            'title': 'General options',
            'sub-components': [
                {
                    'component': 'checkbox',
                    'advanced': true,
                    'schema': 'auto-limit',
                }
            ]
        }
        {
            'component': 'group'                
            'title': 'cwebp options'
            'sub-components': [
               {
                    "component": "input",
                    "advanced": true,
                    "sensitive": false,
                    "display": "notEquals(state('data', 'encoding'), 'lossless')",
                    "schema": "cwebp/command-line-options",
                }
                ...        
            }
        }        
    ]
}

So UI would point to the corresponding schema with some xpath-like syntax (ie JSON Pointer[https://json-schema.org/understanding-json-schema/structuring.html] or JSONPath. In the example, the UI has a group for general options and one for cwebp options, however the data is structured so all general properties goes in root, but cwebp properties goes into the "cwebp" sub-object. That is a nice thing to be able to do...
Note that pointing to "schema" could equally well be thought of as specifying data-structure - as json schema structure resembles data structure. So we could call it "data" instead of "schema".

Some options are easy to decide on. You want to set the option and never see it again.
However, which options is individual. Most people would for example have the same "metadata" setting always, but others might have it part of their tweaking.

Here is an idea:
How about adding a switch between "favourite options" options and "all options", and make it possible to personalize which options that are most relevant for you. For example, in the "favourite" view, when hovering an option, a "hide option" button could show up in the right side. In the "all options" view, a "add to favourite" / "remove from favourite" button could show up.

To begin with, we could have some of the options only in "all options". "Auto limit", "Sharp YUV", "Auto filter", "Low memory" and "Preset" are candidates

Especially useful for broken images...

Ie by making "Original" a link