Yes/No or True/False?

[jducoeur]

Way back in the early days of Querki, I was figuring out what the major Property Types were going to be.  Figuring out the list was easy; figuring out what to call them was another matter, since I'm trying to avoid techie jargon in the basic parts of Querki.  So instead of "Markup", it's simply "Text", and "Integer" is "Whole Number".  (Yes,

Comments

[etherial]

I'd call the values "True" and "False" and the variable type "Truthiness".

[jducoeur]

Heh. I like it at a gut level, but in a post-Colbert Report world I think the connotations of "Truthiness" may not be quite right...

[jducoeur]

In that sense, I presume Querki has a type for "one from a sequence of choices", isn't this just the minimalist case for choice?Conceptually, sure. (In practice, it is currently much too much work to define a Multiple Choice, which interferes with that being a first-class concept from a UX POV. This is increasingly high-priority; I may well add the wizard to address it in the next week. It's currently a nice object lesson in UX: the concept is currently functional, but not usable

[jducoeur]

That's fair, and you may well be right -- the universality of the term "Boolean" in the software world suggests so. Indeed, that's more or less why I wound up with "YesNo" in the first place, and it wouldn't surprise me if I simply decide to change that to "TrueFalse", to slightly better match the usage. But it's going to be enough of a nuisance to make the change (since the type is pretty central), that I'm pausing to think about that and see if anybody's got cleverer ideas...

[jducoeur]

for users it might make sense to have a bunch of them--yes/no, true/false, left/right, up/down, enabled/disabled, and so forth

Hmm. Interesting point, and in principle I suspect you're right. In practice, though, it *is* actually a single type, and kinda has to show up in the UI that way in some places. (Eg, when creating a Property of this type, what do we call it?)

And that being the case, I worry that being inconsistent in the terminology may be pointlessly confusing. Indeed, that's the *precise* cause of me asking this question: I found that I was having difficulty being consistent typing "Yes" and "No" in the documentation, and keep reflexively using "True" and "False" because they sound more correct to me. I suspect that inconsistency is Bad, so I want to make a decision I can stick to.

Some folks simply won't think to grab the "2-choice" type and slap, say, "active/inactive" into the labels.True, and I probably don't care passionately if so -- using Multiple Choice should generally work, if with a bit more effort. But this "

[laurion]

I like the idea of the 'This or That' type. You can have this, or you can have that. But it's at least as terrible an abstraction as Boolean.

[jducoeur]

I should be clear: I don't mind the *abstraction* of Boolean -- I think it's somewhere between useful and strictly necessary. It's the *word* that I'm trying to avoid, because it's totally opaque to non-programmers. (So far, I'm leaning towards the crude but clear "TrueOrFalse", but continuing to think on it...)

[mindways]

I'm positive "Boolean" is the wrong terminology to use.

I strongly suspect that "TrueOrFalse" is better than "TrueFalse", and that either is better than "YesNo".

[jducoeur]

Mmm -- good point. I might well go with that...

[hudebnik]

Most people who attended a U.S. school are familiar with the notion of "true/false questions", so if you called it "TrueOrFalse" people would almost certainly understand what you meant (although they might have negative associations with test-taking, or conclude that as with a true/false question, you can flip a coin for the answer and you're 50% likely to be right). "TrueFalse" sounds oxymoronic to me

[jducoeur]

(Note: I'm getting into some of the technical details below. Much of it's not terribly obvious to the beginner, but is very relevant when you get into Advanced Querki, and start doing really programmer-y stuff with it.)

BTW, does "choices" mean basically an enum of finitely many discrete values, or does it cover polymorphism of distinct types too? For example, could I define List as "choice between Empty and (First Object together with Rest List)"?

The Multiple Choice Type means precisely the former -- indeed, it was originally called Enumeration, until tpau suggested Multiple Choice. (The concept is really a design pattern under the hood: it's a Link that is constrained to values of a particular Model whose values represent the enumeration. It's quite powerful, roughly cognate to Java's enumerations. But I'm finally getting sufficiently exasperated with it to wrap it up in a pseudo-Type + UI that does all the work behind the scenes

[hudebnik]

Yes, I was pretty sure you must already have a "list" type or equivalent; that was just an example of the kind of data definition one might want to be able to do with polymorphism.

Speaking of that programming language long long ago, in a galaxy far far away, I think its word for Boolean was "flag".

[jducoeur]

Hmm. "Flag" isn't bad -- so far, I think I like that and the call-it-a-spade TrueOrFalse best. Ponder...