Text for Accept button should be "OK" for HtmlUI::inputbox wrapper

[DanRathbun]

The Accept button name does not match UI::messagebox button name "OK".

The ArgumentParser#get_options_args() method is used (usually) when mimicking UI::inputbox, so it affords an opportunity to override the default as set in HtmlUI::Inpubox#initialize.

The definition of the local options hash object in ArgumentParser#get_options_args(), at about line 84:

      # Convert to option hash.
      options = {
        title: arguments[:title],
        accept_button: 'OK', # mimic UI.inputbox
        inputs: [],
      }

---

@matthes-b said ...

I support that the 'Ok' button should be called 'Ok'.

@thomthom said ...

A PR of customizing the title of the buttons will be accepted.

[thomthom]

PR accepted if it includes an option to also set the label for the Cancel button.

[DanRathbun]

PR accepted if it includes an option to also set the label for the Cancel button.

Huh? This is not about setter option(s).

It is about overriding the normal default label (which is set in HtmlUI::Inputbox#initialize)
for a specific scenario.
That scenario being the use of the inputbox class method where the default override is done in ArgumentParser#get_options_args() which is not used with the advanced hash paradigm.

The consumer(s) can already pass options that override any default labels using the
advanced hash paradigm's :accept_button and :cancel_button properties.

[DanRathbun]

Are you implying that reliance upon the normal default in HtmlUI::Inputbox#initialize remaining set to "Cancel" is fragile for the HtmlUI::inputbox scenario ?

---

I could also add that I think the native UI.inputbox automatically sets the button labels to localized string labels.
This example has no localization support for the buttons. (This would be a separate issue if ever we wanted to tackle this.)

[thomthom]

Oh, I see now. The other issues had so much activity that I had a hard time keeping up.

Ok, so this is about the HtmlUI::inputbox label being the same as UI.inputbox. What is the reason for this? Both Windows and macOS UX guides advocate using verbs for buttons. "OK" is a rather dated naming pattern. Mimicking the old UI for the sake of it doesn't seem that useful to me. Switching to an HtmlDialog approach like this allows you do gain improvements. As mentioned before, this was never meant to visually replicate UI.inputbox, only the API interface shim was added as a very trivial hot-swap alternative. Beyond "UI.inputbox did it", what are the reasons to use "OK"?

[DanRathbun]

Yes you are correct. It is an appearance issue. Some people do not like change.
Some (like me, ... heHhe) are nitpickers. They notice differences and it "bothers" a little. OCD and all that.

But if you think it's going "against the grain" of this repo, then we'll just make people use the advanced hash paradigm if they want to use an "OK" button.

I really think you should put your "philosophy aims" of the example in an introductory paragraph of the README.

[DanRathbun]

Speaking of Ui.inputobx mimicry ...

(Comments moved to new issue: 15 : Compatibility shim does not allow 2 args or an empty window caption.)

[thomthom]

I really think you should put your "philosophy aims" of the example in an introductory paragraph of the README.

I'll do that. It wasn't done originally because I hadn't expected the example to turn out to take on a life of its own.

[DanRathbun]

Ok then given the philosophical discussion on Trimble UX goals (above and in the closed "buttons" thread,) we shall close this issue, and you may remove the help wanted label and mark it works as intended.

---

@matthes-b You'll have to add the hash argument as shown in the initial post for your own edition if you really want it to be more like the native UI::inpubox interface.

There is no point in trying to "kick against" Trimble corporate UX goals. Thomas and the others on the SketchUp team are required to promote these goals.

[thomthom]

We are willingly and gladly promoting a unified updated UI/UX.