Metadata editor

[fhyoga]

I am currently doing feature development for metadata editing, and some issues need to be discussed.
What UX/UI do you want? Now there are two options

1. Fully use the original interaction
2. Improve some experience

Write down what you think and what you want to improve

[heyhippari]

I think we can rework the existing dialog quite a bit to make it more approachable and less dense (A barrage of 30+ fields isn't very welcoming).

Here is more or less what I have in mind for the general design of the modal version:

Do note that it is incomplete and only covers the first tab (Mainly because I'm not a UI designer, I barely know how to use Figma and this takes a ton of time to do, let alone do properly 😋 )

It's essentially a card modal with tab bar (vertical on desktop, horizontal on mobile, to make the best use of the available screen space) and a scrollable middle section (the form in the middle will be longer than what the modal can hold, so it'll scroll down).

The first section would hold the general information of the item: title, original title, sort title, release date (or start/end dates for a TV show, birth/death for a person), overview.

The second tab "Details" would contain more precise info: parental rating, genre, tags, studios, various IDs.

The third tab "Cast & crew" would contain the info for the people linked to that item. The heading of the tab should probably change depending on the type of item, since "cast & crew" doesn't make sense for music or books.

The fourth tab, "Images" would be the image editor (But that'd be in another PR down the line)

Essentially, the idea is to regroup information by relevance and importance. The first tab contains the most important information (Whatever is visible at a glance for an item and is typically what one would want to have a proper display of said item in the UI). The details and actors contain the rest, grouped by relevance (a person isn't handled quite same way UI/UX-wise as a normal input field).

It's somewhat easily adaptable to the tree-based editor (probably use an horizontal tab bar, like on mobile) and presents the info in a way that makes more sense than dropping everything in a list of fields.

Do note that the "eye" icon on the fields in that mockup would ideally be a lock icon, to allow the user to specify which fields are locked. It's the equivalent of the "Enabled Fields" section in the current UI, but presented in a way that makes more sense.

All of this is up for discussion and debate, of course.

[fhyoga]

In principle of big interaction, my thoughts are the same as @MrTimscampi . To split the original flat meta-information through tab pages. I have referenced Plex's interaction design.

For some fields that can be selected in the option pool, such as tag, genre. Can be made into a multi-select box with search and add.

For me as an implementer, some details need to be determined: (some may be misunderstandings caused by my unfamiliarity with this project)

1. For the locking of each field, the interface does not seem to be implemented at present
2. Transforming into a multi-select box also requires the help of the server developer

[heyhippari]

For 1, you can use the LockedFields property on BaseItemDto. You'll need to send a BaseItemDto object through ItemUpdateApi.updateItem(). The property seems to take an array of MetadataField.

The selection is pretty limited for now, but the server folks can probably get to that at some point in the future (It'll require very little changes on this side, I expect).

For 2, we do have endpoints for Genres and Studios. The only thing missing is Tags. These are available through GenresApi.getGenres() and StudiosApi.getStudios(). Both can take a "searchTerm" parameter to return relevant results.

So the only thing we'd have to eventually add is an equivalent TagsApi, but I don't think this is blocking for a first pass on this.

[fhyoga]

@MrTimscampi The internationalized json file is rewritten. I would like to know what is based on the consideration of rewriting instead of directly using the jf-web configuration. After all, it’s too painful to translate one by one, and the tool automatic translation is too rough 🤣

[heyhippari]

We're mostly rewriting things in the locale files, since we're following slightly different guidelines and the jf-web files are full of strings we would not use.

You can do your best for the en-US file, we'll suggest better wording in the review, if needed :)

If you need some writing guidelines, this project generally uses these: https://material.io/design/communication/writing.html

For translations, you can leave it to the community if you want. We handle translations through Weblate.

[fhyoga]

Hi @MrTimscampi
I completed the development of the main features, although there are still many details that need to be dealt with. But I want to go through the current implementation with you first, and align the expectations to ensure that the features I have made are consistent with expectations. You can review it first and give me feedback if you have any questions.