WoltLab
The name of the input field inside the input field.
Nested input field naming for improved design and space efficiency. In my opinion, there's no need to describe the input field above and then repeat the description inside. Why duplicate information?
Examples:
This would save a lot of space and enhance the appearance.
Using placeholders as definition of a field is pretty bad since you can't see the text after filling that field. Placeholders should contain examples only.
On the attached examples, it can be seen that the text from the input moves up above the input. This takes up significantly less space than the text located above the input. Examples:
In my opinion, the best solution would be an input in this style, like a conceptual sketch. Such an input looks much more aesthetic, takes up less space, and serves the same functions as a regular one.
On WoltLab, there are numerous inputs that influence the appearance of individual sections. In my opinion, we should move away from the standard, less aesthetic input in favor of a more efficient solution, providing not only a visually pleasing effect but also occupying less space.
In my opinion, a model like this would work best:
You can see versions of various inputs here: https://mui.com/material-ui/react-text-field/
I’ve reviewed numerous inputs, and I believe the one for WoltLab would be the best option. It’s an input similar to what Google uses. You can see it here: https://mui.com/material-ui/react-text-field/
It’s aesthetically pleasing, takes up very little space, and is fully functional. I think that along with the template redesign in version 7.0, the inputs should also be refreshed. The user interface needs to be inviting and aesthetically pleasing.
@BurntimeX I realize that developing new inputs is a bigger workload, but there are really a lot of them on the site, so this will positively impact the UI/UX and save a lot of space. It would be great if it could be done in version 6.2.
This type of input field would require new HTML in practically every form template. This makes the implementation very time-consuming for us and for third-party developers.
In addition, it would lead to an inconsistent appearance if older plugins were used.
With version 7.0, the conversion of the input fields would be much easier, as almost all forms will probably be based on the FormBuilder standard by then.
You can also implement it gradually, starting with the homepage and finishing with the admin panel.