Stimulus and media object: Using object name as default handle

[baranan]

When defining stimuli, it is easy to confuse the object name and its property handle.
For instance, many users would probably think that the name of the stimulus below is FB, and therefore they can refer to it as FB, for instance, in the actions showStim and hideStim:

FB: [{ 
			css:{color:'#FF0000','font-size':'2em'},
			media:{word:'Wrong choice, no points this round.'}, 
			location:{bottom:10}
		}]

In fact, they need to add data:{handle:'FB'}.
It might help if, by default, a stimulus receives its object's name as the handle, unless a handle is defined.

[baranan]

On a second thought, it might prevent researchers from learning how to use different stimuli with the same role in a trial (i.e., use the same handle for many different stimuli and use each of them as a target in different trials). So this feature might be problematic. Still, it will be good if we could somehow warn users about the mistake of confusing the object name with the handle.

[eladzlot]

I agree that we have a problem with the naming of stimuli. In general, people have a hard time grasping the idea that stimuli have names. The use of handle is confusing for most people, using name probably makes more sense.

It is currently possible to extract the name of the set that a stimulus was inherited from, but I'd advise against from two reasons. The first being that the sequencer was designed to be fully separate for the player and we have no guarantee that it won't be changed. The second leading from the first, is that we actually have a plan to change the sequencer so that you can inherit from multiple sets - and then what would the name be?

We might consider having an alternative API that would be far clearer.

Instead of:

const stimuli = [
    {handle:'focus', inherit:'focus'},
    {handle:'stim',inherit:'stim'},
    {handle:'error',inherit:'error'}
];

We can have:

const stimuli = {
    focus: {inherit:'focus'},
    stim: {inherit:'stim'},
    error: {inherit:'error'}
];

The advantage is that researchers are forced to organize their stimuli in a meaningful way.
And the names can be seen at the glance of an eye. The price we pay here of course, is the change of API (though we can keep backward support here...).
(BTW the same problem exists for inputs, and I'd suggest the same type of solution).

Regarding losing ease of naming several stimuli with the same name, I know of very little people that are using this feature - and I'm afraid many more are struggling with handles.