anthonyalfimov
commented
3 years ago This post will be updated with options and decisions for the preset browser design details.
Details
Touch-friendly
I would like the preset manager design to be touch-friendly without any modifications.
This means we shouldn't rely on mouse hover.
Double-click could be represented by double tap, but for context menus a long press is a more common gesture.
UI elements should be big enough to use with fingers.
Preset navigation buttons
Preset navigation buttons should step through all presets. If there are preset folders, these buttons have to go through presets folder by folder, in the same order they are in the preset list.
Preset navigation buttons should circle back to the beginning of the preset list when reaching the end, and vice versa.
Navigation buttons could be positioned next to each other, or either side of the preset name field.
Buttons next to each other should make it faster to change the direction of preset browsing. On the other hand, they require more precision (and attention) with mouse positioning.
If buttons are positioned next to each other, they should be well-defined and large enough to make avoiding misclicks easy.
Preset name field
Preset name field opens the preset browser dropdown.
I think there should be a downwards arrow clearly indicating that the field can be interacted with to open the dropdown. Adding this arrow favours positioning the preset navigation buttons next to each other on the left side of the field.
Access to presets
Accessing presets should take the least amount of clicks possible. This is the main focus of a preset browser.
Preset navigation buttons in the main plugin window are important for fast preset access. But they cannot replace quick access to the preset list itself.
Hence, I think that the preset browser dropdown should contain some actual presets, not just folders. These could be top-level presets that are not placed in a folder, or favourites.
The first iteration of the preset browser might not support folders at all, and all presets would be displayed as top-level.
Preset folders
Having to scroll through a long list of presets will slow down access to a desired preset. So supporting folders is preferred.
Since the plugin is fairly simple, folders don't have to be implemented right away.
Supporting nested folders is a question. While it can be handy for organisation, navigating multiple levels of nested dropdowns is a poor UX. I believe that with simpler plugins, it is ok to not support nested plugin folders.
A possible solution to nested preset folders is to open folders in place. Instead of opening a new dropdown with the contents of the folder to the right of it, there would be a single panel where the contents of the current folder are displayed. An "Up" or ".." button would be used to navigate out of the folder. This approach will likely mean that we won't be able to use the regular dropdown class.
While not a top priority, it would be useful to be able to move presets between folders. This feature can be omitted as long as we expect to have a fairly small number of presets and simple folder organisation (no nested folders).
Favourites / top level presets
Some presets should be directly accessible in the main preset browser dropdown. This will speed up access to some select presets.
These top-level presets can be just ones that the user chose to not put into any folders. It would be handy to add a "Move to top level" button to the preset editing menu. This way, the user will be able to choose presets they will have quick access to. This will also require an option to move top-level presets into a folder (at least).
An alternative would be a "favourites" system. All presets will have to be created in some folder. The preset editing menu will have a "Favourite" checkbox. Favourite presets stay in their folder, but they are also displayed in the main dropdown menu along with the folders. This way, the folder organisation of presets is preserved when we make some presets quickly accessible. It also doesn't require the capability for moving presets between folders.
Factory presets
I strongly believe that it should be possible to delete any factory content.
There should be an option to restore factory presets. This can be done though the installer.
Even before preset folders are introduced, the factory presets in their own sub-menu. However, this could be misleading. Having a "Factory" folder would imply that folders can be created, while it's not the case. Perhaps, before folders are introduced there should be a fairly small selection of factory presets, so they don't require a sub-menu.
When preset folders are implemented, it would make sense to place factory presets in the "Factory" folder. However, not having any top-level presets could reduce the likelihood of users checking out the presets. Implementing a "favourites" system that flags preset to be shown as top-level would solve this. We could add a selection of factory presets to favourites on first installation. NB: in this case, reinstalling or updating the plugin should never overwrite the user's favourites selection.
Saving presets
I don't think that saving presets necessarily requires as few clicks as possible.
It is more important to avoid accidentally overwriting a preset.
"Save" and "Save as"
We can have separate buttons for just overwriting the current preset and saving the new one (with preset name entering). Having both "Save" and "Save as" buttons is a familiar pattern, so it should prompt the user that "Save" will cause an overwrite.
Adding a confirmation prompt to the "Save" doesn't make sense, because then it will take the same amount of clicks as using "Save as". In this case, it's better to leave just the "Save as" button.
Therefore, the "Save" button should be placed so that misclick is not likely. That is, inside the dropdown menu and not in the main plugin window. The button should also be well defined, big enough, and have enough space around for touch use.
As mentioned, the alternative is to have just one "Save as" button that always asks to enter the preset name. The name should be pre-filled with the current preset name, so you can easily overwrite the preset. The preset name prompt could display a text warning when the entered name matches an existing preset and overwriting will occur.
In case of a single-button setup, it is preferred to call it "Save as" vs "Save" to clearly communicate that the button will not just overwrite the current preset.
"Save" button in the main plugin window
I am not sure if we should have a "Save" button in the main plugin window. It would split the browser functions between the main window and the dropdown.
And if we do, should there also be a "Save" button in the plugin browser dropdown?
I think it would make sense only if it is the only browser function button outside of the preset editing menu. Then, the dropdown would only contain the preset list, with no other controls.
In this case the "Save" button will have to follow the requirements for the single "Save" button from above. It should be called "Save as" for clarity and always prompt for the preset name.
The preset name field could be used for entering or confirming the preset name, or cancelling. However, normally it should still open the preset list dropdown. Text editing should be enabled only after the "Save as" button is pressed. During editing, two buttons should be available: Confirm and Cancel. So it might be easier to just use a separate pop-up for this.
The pop-up could perfectly line up with the preset name field, so it appears as if it's used for text entry.
When the entered name matches an existing preset, a text "overwriting" warning could be displayed in the popup.
Preset and preset folder editing
I would like to avoid having to select a preset to edit it.
A good option for preset editing could be a "..." menu on each preset and preset folder item. Positioning the "..." menu on a folder item is a question though. Also, having this menu button on every item could create visual clutter. Perhaps, it should only appear on mouse hover? But using mouse hover is not touch interface friendly.
An alternative is a right-click menu. It's a very logical pattern outside of the plugin world. But I don't think I've ever seen a right-click menu on a preset list item in a plugin. And since users are not used to it, it can be confusing.
Exporting and importing preset files
Menu options to import end export presets could add clutter, and I don't think it's a priority.
Instead, there could be a button to open the presets folder in the system file browser.
Alternatively, the preset and folder editing menu could have an option to "Open preset/folder location in file browser".
SWONIC
The top post will be updated with options and decisions for the preset browser design.
General requirements
Design patterns
Summary of distinct design patterns for a plugin preset browser.
Buttons
Preset browser functions are realised using buttons in the main plugin window. The preset name field usually opens a dropdown with presets and/or preset folders. Sometimes the preset name field is not interactive at all.
Pros:
Cons:
Notes:
Menu button
In addition to the preset name field, there is a preset menu button. This button opens a dropdown with all the preset browser functions. The preset name field usually opens a dropdown with presets and/or preset folders.
Pros:
Cons:
Notes:
This looks like an ok option, but I don't like splitting the preset browser between two dropdown menus.
Right-click menu
Left click on the preset name field opens a dropdown with presets and/or preset folders. Right click on the preset name field opens a dropdown with all the preset browser functions.
Pros:
Cons:
Notes:
I've rarely encountered this pattern and it's not intuitive, so it will not be considered.
Dropdown
The preset name field opens a dropdown with all preset browser functions. The preset list is usually represented as a sub-menu in this dropdown. Often, multiple preset folders are available as sub-menus of the main dropdown. In some cases, top-level presets are also displayed in the main dropdown.
Pros:
Cons:
Notes:
This is the most common option among the plugins I've looked at.
Window
The preset name field opens a dedicated preset browser window / panel.
Pros:
Cons:
Notes:
Personally, I don't like preset browsers that open in a separate window or cover the whole plugin window. Even though they are functionally superior, it feels like they're pulling me out of the tweaking flow. This option is also an overkill for the kind of plugins I am currently capable of creating.
Design pattern choice
For all options, I want the entries in the preset list to have a context menu for renaming, deleting, etc.
Clicking on the preset name field should open some form of a preset list dropdown. Some select presets should be directly accessible in this dropdown.
A. Single button
Preset name field opens a preset list dropdown. It contains preset folders and top-level presets. Most of the browser functions are handled by context menus for preset list items. This includes: renaming, deleting, moving, adding to favourites, opening location in system file explorer, etc.
In addition to the preset navigation buttons and the preset name field, the main plugin window contains a "Save as..." button. This button always prompts to enter the preset name to protect against accidental overwriting. The name is pre-filled with the current preset name to simplify overwriting.
No other preset browser controls are present neither in the main window, nor in the dropdown.
Mockup
Pros:
Cons:
B. Dropdown-window hybrid
Preset name field opens a dropdown with two panels.
One panel contains buttons for browser functions. These include: save, save as, initialise, open preset folder in system file explorer, refresh preset list, etc.
Another panel contains the preset list: preset folders and top-level presets. Preset-wise operations are handled by a context menu: renaming, deleting, moving, adding to favourites, etc.
The main plugin window does not contain any preset browser controls other than the preset navigation buttons and the preset name field.
Mockup
Pros:
Cons:
Transition from current design
A two-button design ("Save As...", "Delete") could be used to implement a preset browser without list item context menus. This could be an intermediate step between the current browser and Design A or B.
Mockups