When creating/editing an article with the custom field type "list" it selects the first list value without viewing the fields tab. The list item shouldn't select anything without the user selecting from the list. Note that when allowing multiple values it does not automatically select any of the custom fields.
Title |
|
Title |
|
Title |
|
Title |
|
||||||
Status | New | ⇒ | Closed | ||||
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-04-30 11:40:19 | ||||
Closed_By | ⇒ | Bakual |
very bad user experience.... we need to fix it, please.
Or we need to delete the "power through simplicity" from the Joomla! Development Strategy
We cant fix the way that the web works
if our dev team can't add a default empty option and make that the top one, we can try to write this info in the Field.
Originally I was attempting to set the default value to a blank space, however validation wanted an existing value. @brianteeman is right about how the web works, you can see this in action:
https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_select
Thanks @Bakual for the advise on solving the select issue. Works great.
very bad user experience.... we need to fix it, please.
Seriously?
if our dev team can't add a default empty option and make that the top one, we can try to write this info in the Field.
I think there is a misunderstanding. That's how you have to set up the list options if it should be possible to have an empty value selected:
Which results in this:
When you save that, you have "nothing" selected by default.
It's just a question to set up the field the way you need it. If "empty" is a valid option, you need to add it.
I hope we can write this instructions in the field if we can't add it by default.
That would mean that for consistency we would have to write instructions on every field everywhere explaining absolutely everything that there is to know about how the web works. Sorry but this is a crazy idea.
no, I have never written such a thing. Kindly avoid inventing strange allusions
I think we can expect some cleverness from people when they want to use custom fields in Joomla. If they are dealing with such use cases, then they have a certain level of Joomla experience.
Why?
An use can access in the Joomla control panel and for you it is an expert html users?
It is not our role to document directly into the CMS how basic HTML structures work or every known issue or quirk with everything. So yes, there is some expectations that users would either need a basic level of understanding on how some things work or do the research required to learn those things.
Custom Fields aren't designed to be used by complete web N00bs. I also would expect at least some basic knowledge from users setting up (not using!) custom fields. And if not, they will be able to figure it out with the help of forums and Google.
Many users choose to use CMS because they are not HTML expert.
And if for you Custom Fields aren't designed to be used by complete web N00bs you need to write it, only for expert in the Joomla menu :(
Joomla tries to follow the slogan “power through simplicity”
I can understand your reasoning for features not so in the foreground, like ACL. But custom fields are in the menu, immediate and simple to create. Really does not seem to be just for experts.
you are showing your age. That was the slogan of mambo. ;)
here the slogan: Joomla! Development Strategy https://developer.joomla.org/development-strategy.html
Alex, it is not our responsibility to explain how to use the web in the context of the CMS interface. So no, we should not add something to com_fields explaining how you configure a list form field from start to end or explaining every little quirk or issue that you have come across. Personally, I would find that experience degrading as an end user if the platform assumed I was a complete idiot.
This is why we have a suite of documentation and support channels. These are the places where things are explained in greater depth (to a reasonable extent, again, it's not our responsibility to explain the semantics and logic behind a <select>
element and its various configurations) or users go to ask questions that either might be above their skill level or deal with complex scenarios.
I would have created a blank list item from the get go, however I assumed validation would require text input. Indeed we do not want to over document something that follows HTML standards. Perhaps the default value field could accept a blank space as a valid input? Understandable if this is not a proper exception.
ok, you don't want to write info. But can the selection be like for the "Multiple" values ?
Having it auto select by default is slightly rougher user experience especially considering that we can already set the default value but cannot set a blank by default except for the scenario mentioned by Bakual.
NO it cant. That would not be the correct usage of a select
Sorry @AlexRed but multiple people have told you that this is not going to be changed the way that you are requesting. If you were any other commenter I would lock this issue. But because you are a "member" that will have no effect.
ok, you don't want to write info. But can the selection be like for the "Multiple" values ? (but limit it for only one value)
And what if I don't want the user to be able to leave the select empty? It absolutely depends on the use case if there should be such an empty option or not.
considering that we can already set the default value but cannot set a blank by default except for the scenario mentioned by Bakual.
Actually, you can have the "blank" option also at the end or in between. It just doesn't make much sense imho from an UX perspective. But the field by default will select the empty one regardless where it is in the list if you have left the "Default Value" parameter empty. I wrote that a bit misleading above.
Like for the module "Position", a select where you can insert only one value. And if you do not insert a value it is empty.
Not all select lists are optional and as such it should not be mandated to have an empty option nor the code try to create one when the user did not set up their field to behave as such.
Like for the module "Position", a select where you can choose only one value. And if you do not choose a value it is empty.
Because in the module, the position isn't a requirement and an empty value is absolutely fine. You can do that in the custom field as well, just set it up correctly.
As said, it depends on the use case if there should be such an empty value or not. There are many other examples of selects where you can't choose an empty value. Both are valid list fields.
The fact that a blank field anywhere handles this makes a description not needed. It's up to the admin to not assume that validation would fail it's submission.
And when you want to have an empty entry in all select fields, then you can define one in the list plugin and it will be populated on all list fields.
you need to add a third empty option and make that the top one
if our dev team can't add a default empty option and make that the top one, we can try to write this info in the Field.
Actually, you can have the "blank" option also
I think there is a misunderstanding. That's how you have to set up the list options if it should be possible to have an empty value selected:
So they are list OPTIONS and not list VALUES (HTML calls them "options", and other CMS call them options, for some reason we selected to call them "values")
Correct terms are:
List options
Checkboxes (or Checkbox options)
Radio buttons (or Radio options)
instead of
List values
Checkbox values
Radio values
same problem with the "sql" field. But here you can't add a default empty option and make that the top one so simple.
If you only add two values (eg Yes and No), it will indeed select the first one automatically. If you don't want that, you need to add a third empty option and make that the top one. That's how a HTML "select" works.
Closing as it is expected behavior.