UX inaccuracies in TV creation forms

[Ruslan-Aleev]

Feature request

Summary

@smg6511 has done a global job at #15773, but there are UX inaccuracies that need to be discussed and corrected in the future.

UX inaccuracies:

1. What does the icon next to the TV name do in the description? I thought she was copying [[*Name-TV]], but it doesn't.

If it done for TV, then it should work for other elements (snippets, chunks, etc.). Although I personally do not like it and I would remove it from everywhere (some improvement for the sake of improvement).

2. The "Allow Blank" selection should always be at 100% and not mix with other TV parameters.
   This is a separate important parameter, and it is better to make it easier to find and it would always be in the same place.

3. On hover over fields, field control icons appear. But it is not clear by what logic these icons appear, why only for some fields? This is confusing...

4. In TV (at least with the "Date" input type), there is a select, where you can enter your value or select from the list.
   In my opinion, there is no need for input capability (field editable), otherwise you can do something like this:

5. The input field "Default value" for some TVs is not full width, although for others it is full width.
   TV where "Default value" is not full width: Date, Number, Text and Textarea.

6. Although for TV with an image type and a file, I would, on the contrary, reduce the width of the field "Default value", as it is now in the resource (not 50%, but 400px). Firstly, uniformity in the interface, and secondly, it is less to reach the mouse to the upload icon.
   It is also worth putting the image icon (not the file) in the input.

7. I also didn't understand the global checkbox logic. I would leave them in the form of checkboxes (and not toggle switches), otherwise it turns out that such toggle switches are in the resources and in TV, but why do they look different in other sections? Looks sooo strange.
   If it were only in resources, then it would make sense, as a design element with which the user communicates more often.

@smg6511: IMO all checkboxes that act as a switch should be in the switch style now for design consistency; it's really only the ones that are a data point (like those in the grids) that should strictly stay regular checkboxes. This communicates the purpose more clearly.

In general, having switches, even in resources, is not useful. Now they have appeared in TV :) I am almost sure that we will come to the conclusion that there will be a different interface without logic and that's it...

Why is it needed?

UX inaccuracies

Related issue(s)/PR(s)

#15773

[smg6511]

@Ruslan-Aleev - Thanks for going over this. To address your points:

1. Good catch there. I hadn't been clicking on the icon itself; I was using the icon as a visual cue that clicking the tag text would copy that text. I'll fine-tune that; the simplest way might just be to set the cursor to none for the icon.
2. This is one point where I just disagree. The field is always in first position and not difficult to spot IMO. The point would be moot though if we make the related UI change I'd mentioned in the PR (moving the field up to the right of the input type, making it a checkbox, and labelling it "Required?" or something of the like). I remember you liking that idea. I can pursue doing that if you and others like.
3. I know there's inconsistency here and would ultimately like to have these buttons for all fields. I explicitly placed these reset on fields whose settings could get complex, where it would be really irritating if a user made a mistake and wanted to get the original value back. The way I'd like to do this in the end is globally via a plugin, but knew that should be done outside of the PR in question.
4. This is the users responsibility IMO. It's explained in the help below to pick a setting in the list or type their own. What you're typing in via your example does not fit the pattern that's stated in the help.
5. I'll take a look at this. Generally I was looking to make the width of this field match more closely its content. To me, it's silly to have, for example, a date or number field be 1200px+ wide.
6. I have a proposal for this. From what I can see, it looks like you work on a large (maybe very large) screen. I do too some of the time. I think we should be constraining the overall form size (within the panel) to a certain max-width (probably 1000-ish px). I am generally strongly against hard-set pixel widths, as it's not responsive-friendly — an area I think we need more focus on.
7. So there's definitely more to do on the switch/checkbox front. If I read you right (aside from the current inconsistency in places), you just don't like the use of the switch style, period. What I was doing by adding them to the TV editing panels was following the newly-established pattern I saw in the resource editing panel. The one thing I'd like to change is that the rendered checkbox TVs be regular checkboxes instead of switches (could be a simple CSS change, I'll take a look) — that, I agree, looks pretty weird. I think otherwise, the usage is pretty logical — with the switch style being applied to on/off setting type checkboxes.

[Ruslan-Aleev]

All my comments come from thesis: If this works in most cases of the interface, then it is better to do so for the rest of the sections.

The field is always in first position and not difficult to spot IMO.

It is clear that the field is not difficult to find, but if for 13 types of TV "Allow Blank" is located separately and on the full width, then why should the other 4 types of TV mix "Allow Blank" with other fields?
You are creating a micro-inconvenience. It is not noticeable yet, but with constant work with TV, users will "stumble". It's just bad for the UX.

moving the field up to the right of the input type, making it a checkbox, and labelling it "Required?" or something of the like.

I would not change the interface, but change the lexicons, not "Allow Blank", but "Required" and in extJS I made the opposite condition. But this is a task for a separate PR.

I know there's inconsistency here and would ultimately like to have these buttons for all fields.

At this stage, in my opinion, it is worth removing this and adding this behavior in a separate PR and for all fields. Or not to add, because initially TV worked without it :) This behavior is now confusing.

To me, it's silly to have, for example, a date or number field be 1200px+ wide.

And why not silly, for example, for url or richtext, what's the logic here?
My reasoning is that if for 11 types of TV (excluding image and file) the field is full width, then for the remaining 4 types of TV it is worth doing the same. This is relevant for mobile devices and for consistency in design.

I am generally strongly against hard-set pixel widths, as it's not responsive-friendly — an area I think we need more focus on.

I agree with that, I'm just for consistency in design. Now in the resource image / file TV are equal to 400px and I would leave it for TV as well. And in the future it is worth considering this moment, and there is a separate issue - #11856.

you just don't like the use of the switch style

Yes, I don't see any point in switches at all, in my opinion they were made for "beauty" and its looks pretty weird in the interface (and switches and checkboxes do the same thing).
But this is my personal opinion :)

[Ruslan-Aleev]

8. Unhelpful lexicons that make code bigger and add translation work.

For example, before for all types of TV there was a field "Default Value" and a description for it.
Now each field has its own lexicons - "Default Option(s)", "Default Email Address", "Default File", etc. + and descriptions to them.
Does this field require so much explanation that additional lexicons is needed?

Here is another example of unnecessary lexicon:

Almost the definition of "Category" is indicated, which is initially clear.

And it is worth remembering that for each such line will need to create a translation, which increases the work of translators, the weight of the distribution and the control of lexicon files in the future.