Page 1 of 1

Radio Button Disable method

PostPosted: Tue Aug 16, 2011 10:21 pm
by mrbobbo
I think a radio button object should expose a method in responses on a page for disabling the RB so it can no longer be changed. I couldn't find one.

Re: Radio Button Disable method

PostPosted: Thu Aug 18, 2011 3:59 pm
by *noah
Agreed. I'm finding I can't preserve the state of a radio button group.

Re: Radio Button Disable method

PostPosted: Tue Aug 23, 2011 5:53 pm
by Nav
Bob,
If you are using the Flow Chart, this will happen automatically so the user cannot change the answer that led them to the feedback they are currently viewing.

If you are not using the Flow Chart, this could be useful... I'll add it to our list of candidates. In the meantime you could use a mask, which is a little more WYSIWYG, and a great way to control what a learner sees or has access to. A "mask" in this sense is a semi-transparent shape object that you show or hide as necessary.

Noah,
I'm not sure I understand your commend... Do you mean you can't persist a radio button's state? Across page views? Across sessions? That would be something else entirely.

Or are you saying simply that people can change their answer once they're viewing feedback? In that case the above masking should work.

- Nav

Re: Radio Button Disable method

PostPosted: Tue Aug 23, 2011 6:12 pm
by mrbobbo
Thanks for putting the request on your list Nav. Just a general comment about this kind of thing. You say a mask is more WYSIWYG. Agreed. I think there is a conflict in approach between WYSIWYG and object-oriented that may get more confusing the more we have to rely on masking. Masking as a form of disablement seems to me to be just a workaround for a missing OO capability: grouping of objects. I know there are display sets, but they have their own benefits and limitations. Here's what I mean about grouping. If I have five objects that I want disabled on some trigger, then as a group they must have some significance. Why not permit me to select them and name that multiple selection as a group. The group could have a few basic methods: disable/enable, show/hide, transparency and, if you're adventurous, save/load previous state. The latter would make it easy to return to a page and reset a bunch of objects without having to name a global for every one of them. Ok maybe that's over the top. Anyway, an object could be in more than one group. This would avoid proliferation of VISIBLE objects during composition. Every time there is a mask, that's one more piece of visual clutter to work around during authoring. And, again, thinking as an OO person, I don't want to see unnecessary visual devices. The WYSIWYG approach, if followed in extreme, would eliminate disable/enable and show/hide for all objects that have those properties, because hey, you can just mask them. I think it's a slippery slope, and I urge y'all to consider that when evaluating this and other similar requests. I personally would be happy if I never needed to use masking. Just sayin'... Bob

Not able to open ./cache/data_global.php