Select Widget behavior with a default value

#1

Perhaps this is expected behavior but I find it odd, so I am hoping there is something I can do to change it. I am trying to use a select widget with a default value to be an improvement over a text edit box and a button that can set the field value attached to the text box to a default value. I’m using a single file 5.3 wiki in TiddlyDesktop.

The behavior I see is that in order to set the field to the default value, I first need to select the widget, then select a value other than the default, then select the widget again and finally, select the default value. If instead, I select the widget (which is showing the default value) and then select the default value, nothing happens, the field is not set. This means that it is more difficult to set the field to the default than to any other value.

I won’t bother to include my code because if you go to tiddlywiki.com and go to the tiddler for the SelectWidget, the very first example shows exactly the same behavior. (At least it does for me using Safari and Firefox). The default value displayed in the menu is “HelloThere” and the corresponding field, shown below in a text box, remains empty unless one selects something other than “HelloThere”. Only then can you repeat the process and get the default value into the field.

Is there something I’m missing or some fix I can make to get the expected behavior- that is, selecting the default causes the field to be set to the default, rather than remaining empty?

#2

G’day,

Any field in any tiddler will only get a value when some action puts a value in the field.

Telling a select widget the default value to display is not an action that puts a value in a field; that’s just setting up visuals for the select widget.

Wherever you reference that field, the reference also needs to know what the default for the field should be, should the field have no value. (Akin to: hmm, no value in that field, so I will assume the default value.)

If you want to avoid the kind of approach described above, then you need an action on tiddler creation, or on the push of a button, to put the default value in the field.

Various ways of approaching this to accommodate various requirements.

#3

That isn’t really what I am saying. I realize that just setting a default for the select widget in the wiki text will not set the field value. What I find strange is that you don’t seem to be able to use the select widget to set the value to the default by selecting the default value the first time around. That is the action that I would expect to set the field. For any non-default value, you can 1) select the widget to get the menu to display and 2) click the menu item to set the field.

If it is the default value one wants, the only procedure that works for me is 1) select the widget to get the menu to display and 2) click any menu item that is not the default to set the field 3) click the widget again to open the menu a second time and finally 4) select the menu item that is set as the default for the widget in wikitext.

The effect of setting a default seems to be on the positive side that you see in the menu what the default is and don’t need to search for it, but on the negative side it takes twice as much user interaction to actually set the field to that default value.

#4

I have been struggling with this too, but I find @Charlie_Veniot 's answer meaningful: what’s the point of setting a value to a field if it’s the default value? In my understanding default means “when there’s no value” (I may be mistaken as English is not my native language).

Fred

#5

The point of the default value is that you never have to select it.

Any tiddler that does not have the particular field with a value, the setup all code to assume the default value.

Say 90% of the time, that field on whatever tiddler ought to be the default value, then why bother storing that default value in all of those tiddlers?

The trade-off here is avoiding putting the same value all over the place to save space (and save you the effort of going through all of those tiddlers should the default change: i.e. change the default in just a few places), but all of that is at the cost of having every filter/whatever out there knowing to assume default value should there be no field with a value.

Really, only setup a SelectWidget with a default if you want to get into the whole mess above.

That said, the whole “mess” above can be really worth it in some circumstances.

Patterns for handling default values for inputs
#6

The issue arises when the “target” tiddler and/or target field doesn’t exist.
As has already been noted, the $select widget doesn’t automatically set the default value.

However, if you really want the default value to be set when the target tiddler/field doesn’t exist, you can wrap the $select widget within an $eventcatcher that is triggered whenever the widget gets the focus, like this:

<$eventcatcher $focusin="""<$list filter="[[thetarget]!has:field[thefield]]"><$action-setfield $tiddler="thetarget" thefield="thedefault"/></$list>""">
<$select tiddler="thetarget" field="thefield" default="thedefault">
<option>one</option>
<option>two</option>
<option>thedefault</option>
<option>three</option>
</$select>
</$eventcatcher>

Thus, when the $select widget gets the input focus (i.e., on “focusin”), if the target/field doesn’t yet exist, the $eventcatcher will explicitly set the target field’s value to whatever default value you specify.

-e

1 Like
#7

In terms of what default means, in this case I would say it means the most common or useful value. I might say that my default choice for dessert is tiramisu. That means that I know I will usually order that if there is a choice. That is like setting the value in widget in wikitext. The widget now “knows” what the most useful setting is. I still need to tell the waiter what I want for dessert and that is like selecting the tiramisu menu item by interacting with the widget. I have to do it but then I want it to do something. Right now it is as if I need to order apple pie, then change the order to tiramisu immediately after making it. That seems very odd.

#8

The select widget is on your food order.

By default, it shows tiramisu.

That’s the desert you will get on that food order unless you select otherwise.

If you don’t want some other dessert on that order, then you have nothing to do.

#9

Interesting. I am about to try to set up a test tiddler to see if that solves my problem.

I have to say though, that even if it does, it still feels very strange. Maybe I’m not expressing myself well. Why does it need to be the case that it is twice as hard (twice as many steps by the end user) to get the widget to set the field to the default value as it is to get the widget to set the field to any other value? From a coding standpoint this doesn’t make sense to me. As far as I can see, what makes the default value special is that if the field does not exist, the default value is most prominent in the menu. That is great. Exactly what I want. I don’t expect the field to be set to that value without user interaction. However, I also don’t expect it to be impossible to set the field to the default unless I first set it to something else. Am I making sense?

In the meantime. The tiddler exists but the field does not. Based on what you said I checked what happens if the field exists but is empty and in that case, the default value is ignored and the widget opens the menu starting from the top item instead of the default. Not sure what that means but it also seems odd. The description of the widget states that the default is “Default value to be used if the tiddler, field or index specifies a missing value” I would think that empty should count as a missing value. Putting a value in the field that is not in my list (that is what I assume missing means in this sense) also just brings up the menu starting from the first item.

#10

If of any use, here’s some sample code that kind of shows what I’m talking about (meant to be put into a new tiddler at TiddlyWiki.com):

\define myDefault() HelloThere

<$select tiddler=<<qualify 'select-demo'>> default=<<myDefault>> >
<$list filter='[all[shadows+tiddlers]tags[]sort[title]]'>
<option value=<<currentTiddler>>><$view field='title'/></option>
</$list>
</$select>

<hr>

Current __''stored''__ value: {{{ [<qualify 'select-demo'>get[text]] }}}

Current value (or the default): <$text text={{{ [<qualify 'select-demo'>get[text]else<myDefault>] }}}/>

Screenshot 2023-07-21 8.09.06 PM
Screenshot 2023-07-21 8.09.06 PM810×422 20.7 KB

In a way, the top half of that tiddler is like selecting your dessert.

The last line in the bottom part is like showing the dessert portion of a food order. In this case, nothing was actually selected, so the default is assumed.

#11

What is the point of a default value if you need the value to actually exist in a field ?

A default value is for the scenario in which the field does not exist at all.

#12

Hi again, that isn’t the behavior that I’m seeing. To continue with my analogy. I know I probably want to order tiramisu, so that is my default. I might wish to choose something else and to reflect that, since I have not yet said anything the entry in the waiter’s notes has nothing in it. I have not yet ordered. In the TW equivalent, the field is empty. I now try to tell the waiter that I want Tiramisu. In TW I click on the select widget, click on tiramisu (easy because it is made more prominent by virtue of being the default) but what happens is the equivalent of not being able to speak to the waiter. I cannot tell him I want tiramisu. I have to tell him I want apple pie and then only once he is misinformed can I tell him that I want tiramisu.

If tiramisu was not the default, I would need to hunt for it in a potentially long menu but once I find it all I would need to do is select it (click the widget and select it from the menu) and I’d be done.

So to get back to your work on my analogy I would say that I will get no dessert on my order until I make a selection, default or otherwise. I think your earlier point, which was very true even if it wasn’t what I was getting at, is that just putting a default into the wikitext does not set the field, the user needs to take action. I totally agree. My point is that the user should be able to take the action of selecting the default value and getting it into the field and at the moment that does not work as far as I can see.

As an aside, if the select widget’s default was put into the field without user interaction then it would make perfect sense for selecting it from the menu when it is already in the field, to have no effect.

#13

ARG! Caveat:

In the particular scenarios I’ve described (i.e. allow no stored value, assume a certain value if no value stored.)

There’s the other scenario in which Eric’s code handles things really nicely: force existence of the field with the default value, every time.

Both scenarios have very valid use cases. Eric’s is, I think, the safest way to go, keeping everything nicely in close proximity. The one I’m focused on has little supporting bits scattered everywhere.

#14

From a usability point of view, I would say it is to make the most useful choice the most prominent choice. Setting a default makes the widget display that value and once selected the default is right there in the visible part of the menu.

To ask a counter question, because maybe I’m not understanding something- Why would you set a default value if you don’t want to actually have the choice of putting that value into a field where you can use it? I can’t think of a use cases but maybe there is one.

#15

I have felt that ARG many times. I will test Eric’s solution to see if it does what I am thinking. I’ve never used the event catcher so I can’t look at the code and say I understand what it will do but since Eric’s suggestions are never to be taken lightly and we’ve been discussing this and you seem to suspect it is in the right direction I will give it a try and report back.

#16

Thank you! That does it. In my test I get the behavior that I want. Just need to do it “for real” now and then wrap my head around the event catcher.

#17

As you’ve seen, the select widget provides an opportunity to show a default value, but the select widget does not prescribe what should happen in the case of the default value.

And the select widget should not prescribe, because there are different approaches that can be taken, and all approaches need extra bits to implement the approaches, i.e.:

  • automagically add the field and set it to the default value
  • add the field only when needed, and only needed when something other than the default is desired
#18

Here’s what I would do:

  • If there’s a “most common/useful value”, then I’d set this value in the field when I create the tiddler.
  • If “empty field” should mean something, then there should be an option for it too in the <$select> options
  • If “no field” should mean something else than empty field, then there should be an UI for it (maybe a radio button for “without field”, another for “with field” enabling the <$select>.

Just my 2 cents,

Fred

#19

I don’t think your point 1 is really fair and since I don’t think that is your intent, then maybe I’m still not being clear about this. There is nothing “automagic” happening or requested. It wouldn’t even be desirable.

Here is an example that most people have encountered. You have to chose your country from a list of 200+ places. They are alphabetized. Anyone not living in Austria, Australia, Albania etc will not even see their country listed and unless you live in Zimbabwe and can give the mouse wheel a mighty spin to get to the bottom, you have to hunt. If the designer knows that nearly all users will need to answer Sweden, then Sweden can be set to show up easily in the menu, that is it can be made prominent. The user still needs to confirm that Sweden is correct by actually selecting it. I don’t see anything automagic about that. The way the select widget works out of the box doesn’t behave that way because if you set a default (make a menu item prominent), you can select it in the menu but it does nothing and depending on how you set things up, the user can see that their selection did nothing. Menu items that do nothing (outside of the ubiquitous “Please make a selection” type item) feel wrong to any end user. Maybe the out of the box behavior is fine and Eric did give me code that allows the default value to actually do something (create the field and make an entry) if desired, so it works in the end but it isn’t automatic.

Since I’m not talking about anything automatic, the user has to make a selection, then not selecting leaves the field uncreated anyway, so as you say in your point 2, a field shouldn’t be added when it isn’t needed. I agree. Nothing is happening automatically. In fact I wouldn’t want it to since not making selection is a meaningful alternative in what I’m doing and means that there is no information, not that by doing nothing, the user causes a specific value to be used. BTW in case it makes things more clear, I don’t know ahead of time what fields might be included. Once the user interacts with the tiddler, then I know what menu items to display and what the default/prominent item should be. The field names are created dynamically and multiple fields may use the same menu to allow the same choices for information in different contexts as represented by the field name assigned.

I assume the use case you are thinking of is that the default can be used to display for the user what value will be used if they do nothing? That’s quite reasonable. Maybe in a perfect world the widget would have a switch to turn on allowing selecting the default from the menu to set the field?

#20

Hi Fred,

All reasonable in some applications but unfortunately, not selecting anything is meaningful for me in this particular case (it means no information and in that case not creating the field at all is what I want to do). Also the field names that might be used are created dynamically as the user interacts with the tiddler, so I wouldn’t want to set any values at tidddler creation and in fact I wouldn’t know what to create at tiddler creation time anyway.

You have made me realize that I have dropped the possibility in my new code for the user to change their mind and after entering information (and therefore creating a field) if they realize that they actually don’t know. The user used to be able to clear the data ( this would be deleting the field). I need to put that back in. Good to think about these things with other people sometimes. Thanks.