Open Ruslan-Aleev opened 2 years ago
@Ruslan-Aleev - Thanks for going over this. To address your points:
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.
2)
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.
3)
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.
5)
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.
6)
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 - https://github.com/modxcms/revolution/issues/11856.
7)
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 :)
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.
Feature request
Summary
@smg6511 has done a global job at https://github.com/modxcms/revolution/pull/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.
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)
https://github.com/modxcms/revolution/pull/15773