HTML [SugarCube 2.x/Tweego] Button swap/tab input

[Purukitto]

I wanted to make a user input with Buttons that can be clicked to be active and the other options would be deactivated.
I honestly don't know what to call it so here are examples from two games I played recently:

Spoiler: Screenshots

You don't have permission to view the spoiler content. Log in or register now.

I went through the documentation and some other online resources and wasn't able to find what I wanted, could be simply because I don't know what these will be called.

The only way I can currently think of is using JS to update the variable (how browser tabs work) but was wondering if there's a better/simpler way to do it

 

[telotelo]

if i'm not mistaken it's simple link/button macro with css styling to grey out the other option
the freecities one i'm sure of it because it's inpage switch macro to display it
as for the deactivated, did you mean you can't click them after chose one of the option?
then it might be choice tag that fit the description closely, afaik

 

[Alcahest]

I wanted to make a user input with Buttons that can be clicked to be active and the other options would be deactivated.
I honestly don't know what to call it so here are examples from two games I played recently:

Spoiler: Screenshots

You don't have permission to view the spoiler content. Log in or register now.

I went through the documentation and some other online resources and wasn't able to find what I wanted, could be simply because I don't know what these will be called.

The only way I can currently think of is using JS to update the variable (how browser tabs work) but was wondering if there's a better/simpler way to do it

If you want to make a html game, the easiest way to replicate stuff from other html games is to simply check the code.

 

[guest1492]

I don't know how it's done in the two screenshots, but I would set up a CSS class with pointer events turned off and dimmer colors for 'deactivated' buttons. Example:

.deactivated > button {
    pointer-events: none;
    filter: grayscale(50%);
}

When you wrap an element with the class 'deactivated' around the button, then the button will become deactivated. The reason that you need to wrap an element around the buttons is because in SugarCube, the button macro on its own does not allow you to specify element styling and attributes.

There are two ways I can think of to deactivate buttons off the top of my head.

Method #1
The buttons obviously set some variable to some value. In the passage, the buttons should be either wrapped inside a 'deactivated' class or not, dependent on the variable. When you click on a button, it should set a variable and reload the current passage.

Method #2
All the buttons should already be wrapped in some element that has an ID. Each button will set a variable and use the addclass macro to add the 'deactivated' class to the wrapping element of each button that should be deactivated.

You can also do some more stuff directly with jQuery, but that would be more complicated.

EDIT: The attached file has a few examples I came up with. While writing the second example, I realized it was too much trouble to do everything with the addclass and removeclass macros with so many buttons when I already know how to do it with jQuery.

 

[PTSdev]

You must be registered to see the links

 

[stevejackhammer]

I wanted to make a user input with Buttons that can be clicked to be active and the other options would be deactivated.

Already several good answers. Just note that from a UI point of view, there is already a standard HTML widget for mutually exclusive selections called the radio button. No extra programming required -- just create a set of radio buttons assigned the same "name" attribute, and they automatically select and deselect so that only one is active at any given moment. Likewise determining which is selected is a single line of jQuery code.

My attitude is that if there's already a widget designed for the interaction I'm looking for, I need a really good justification for replacing it with something handcrafted to do the same thing, especially if that other thing is designed for a different purpose. A classic button initiates an action when pressed. A classic button would be paired with radio buttons -- the radio buttons guide the user into making mutually exclusive choices, and then classic button is used by the user to confirm (confirmation is the "action") those choices so that the game can act on them.

(Admittedly it is confusing that for historical reasons, we have "buttons" and "radio buttons". Of course, that's because in old style radios, the preset selections were selectable with a button that, when pressed, would cause the currently depressed preset button to pop up -- hence only one button was selectable. In the HTML code, the input type is "radio" -- the word "button" doesn't appear.)

And there are numerous web pages out there with examples of restyling radio buttons in fun and interesting ways so you can move beyond the circle-dot paradigm if you prefer.

 

[stevejackhammer]

Looking at the example screenshots, I note that the first set of radio buttons (male/female) presumably affect the selection of the second set. The screenshot shows androgynous/masculine/very masculine as the secondary choices -- I would guess that three different choices exist when the "female" option is the primary choice.

Let's assume that "male" and "masculine" are the defaults, and "feminine" is the default of the secondary choices if you change "male" to "female" on the primary choice.

Let's say I clicked "male/very masculine". Then I think, "What does 'female' offer?". I click "female", fiddle with the secondary choices, change my mind, and go back to "male" as the primary choice. I click "OK", not noticing that the secondary choice went back to "masculine" from "very masculine" when it rebuilt the "male" selections, since "masculine" is the default. Dammit!

Or as the programmer, I need to write code that remembers the temporary choices made on the secondary list so that switching back and forth from "male" to "female" doesn't affect those sex-specific secondary choices.

Given that there's a total of 6 combinations, it might be easier to just offer one set of choices as a list of radio buttons:
"male/very masculine", "male/masculine", "male/androgynous", "female/androgynous", "female/feminine", "female/very feminine"

You also get a cool spectrum effect. You could even color-code the choices a bit for a bit of eye candy, going from deep blue to hot pink.

Why would this be better? None of the options are hidden. I don't have to click back and forth between "male" and "female" to see the range of secondary choices. If there's a description box associated with the combination to explain game mechanics affected by the choice (as in "As a very masculine male, you will find it easier to blah, blah"), the layout is simpler, as is the programming. The user experience is easier too -- just click up and down a single list to browse the full set of options.

As a user, I'm confident I didn't miss anything. Clicking "OK" feels less of a gamble.

Adding extra choices that don't fit the "male/female" dichotomy is easier too, since that dichotomy isn't baked into the UI. A seventh choice of "Ambiguous ET" just gets added. With the original UI as shown, you'd add "Ambiguous ET" after "Male" and "Female". When selected, you'd probably have to hide the other three buttons altogether, then reveal them again when the user goes back to "Male" or "Female". Or add "ET" and reduce to the secondary choice to one button "Ambiguous". So much extra programming that really isn't necessary, as well as a "blinky" UI with bits coming and going.