Previous Entry Share Next Entry
Is it likely to want multiple Types of the same Model?
querki
jducoeur wrote in querki_project
Here's a fairly subtle question, looking for opinions.

I'm currently working on Model Types -- the ability to create a higher-level Type in Querki, based on a Model. So if I have Model Foo, with three Properties defined on that, I can quickly and easily define a new Property whose *Type* is Foo, and which simply embeds a Foo right there in higher-level Things. This will allow you to define complex data structures, have lists of complex objects, and other such fun things -- I'm quite excited by the prospect. (It's been in the plans since the beginning, and there have been a few features waiting until it existed, but I've been waiting for a motivating Use Case, which mindways has given me.)

It's nearly working, but a small UX question has come up. Currently, the UI for Create Property shows you the list of currently-defined Types, and "Create a new Type from a Model" at the bottom. All well and good, but nothing is preventing you from creating a new Type from the same Model several times, for several different Properties. I'm trying to figure out whether that should be legal or not, especially since it is *very* easy to do by accident.

On the one hand, it doesn't *break* anything to do so -- indeed, it simply works. But it bulks up your Space with redundant Types, and makes the list of Types longer. (You wind up with multiple "Foo Type" entries in the Types list.) For a typical Space, this is probably not an issue (indeed, I expect only advanced users to use this feature at all), but it can get messy.

And I am of mixed minds about whether it makes sense semantically. It is basically equivalent in an ordinary programming language to defining two classes with identical structures and nearly-identical names. I can probably come up with strawman arguments for why you might occasionally want something like that, having to do with distinguishing things by their Types, but I don't know if there are any realistic examples of why you would ever want that. (And by and large, Querki is driven by practical reality.)

Opinions? It'll probably be allowed in the next release (simply because it is extra work to prevent it), but I'm trying to decide whether to call that a design bug...

  • 1
"For a typical Space, this is probably not an issue (indeed, I expect only advanced users to use this feature at all), but it can get messy."

Can you estimate how hard/annoying it would be to *fix* such a "mess"? Do you have a feature planned that will (eventually) make that easy, or is it necessarily going to involve a lot of hand-work? If the former, then there doesn't seem to be much point in complexifying the UI. If the latter, it might be worth popping up a warning/confirmation dialog when it happens.

Related question: I've been treating this as if the hypothetical "messiness" was a problem for the user. Is it a problem for Querki? That is, would such duplication of data cause a (noticeable) spike in the resource usage? (A spike which would be avoided by a more elegantly-structured Space.)

Well, the messiness is visible to me in my testing -- I have a Space where I am playing with this stuff a lot, and my Type list has wound up with three Types named "Basic Model Type". That's what sensitized me to this in the first place: if *I* didn't notice that I had already created a Type from Basic Model, it's probably near-certain that end users will make the same mistake.

But yes, the messiness (AFAIK) is just for the user. Model Types are proving to be a fairly complex feature to implement (mostly in the UI -- it proved nicely straightforward in the data model), but I have no reason to believe that, in practice, they will be *terribly* expensive for the system. (Slightly more expensive than native Types, sure, but not likely enough so to be an issue.)

Fixing it -- interesting question. Would probably involve hand-work in practice, unless we put in a lot of effort for this specific edge case. Cleaning it up would involve saying "Type A should be replaced by Type B", which means checking that they are equivalent; going through all of the Properties of A and replacing them with B, and then deleting B. Could be done in code, but is *not* easy.

If the latter, it might be worth popping up a warning/confirmation dialog when it happens.

Certainly possible -- the question is whether to allow it in the first place. What I'm really unsure about is whether there are any likely use cases for having two different Types based on the same Model. If not, then we shouldn't pop a warning; we should simply disallow it in the first place. (Probably by removing the Model from the list you can select from, if it's already defined as a Type.)

Why would using the same Model to create Types for distinct Properties be a problem?

Is the concern that Things that should be instances of one Type end up being made of their own Type or a group of Types?

If my Space is set up to be an Address Book (just a relatively simple potential use case off-the-top-of-my-head), I'm going to want types to represent Physical Locations. Even just sticking to addressable locations (as opposed to GPS coordinates, Latitude/longitude, etc.), I'm probably going to want several Types based on the same backing Model; the Properties associated with a PO Box is similar to, but distinct from, a building address. I am probably going to want different Types for each of the Address Property Things, based on the country sub-Property; there are several general address formats (primarily English Speaking countries; primarily Romance Language Speaking/continental EU nations, Malta, and Israel; Slavic Language Speaking Countries; Semitic Language speaking countries other-than-Israel and Malta), and some places just have their own unique formats (Japan, China). It would be nice to have the Thing be able to display itself correctly.

(Similarly with wanting related but distinct Types for Phone Number Things.)

Or I may be mis-understanding the distinction between Types and Models.

Why would using the same Model to create Types for distinct Properties be a problem?

Most obviously, clutter -- you can wind up with your "Select Type" dialogs gummed up with unnecessary and redundant Types. It can result in strange behaviour at the edges -- commands that work on Type (of which there are few yet, but might be more) might not produce the expected results. And simply that it is another potential complexity in the system, and Querki generally considers unnecessary complexity to be bad.

As for your example, it's an interesting case, and I'll need to chew on it. The real question, I suppose, is whether you ever want different Types if the fields contained in those Types are exactly identical -- I hadn't thought so, but you make an interesting point about the fact that they might want to *display* differently.

That said, Type still might not be the right level to handle that. A Type is mostly the glue between a Model (which defines the actual data structure) and a Property (which is a field that *uses* that data structure, which may be used in multiple places). There can totally be multiple Properties based on a given Type -- that's completely normal and common.

My instinct is to say that, in your example, the right way to represent the distinction would be different Properties rather than different Types, but the semantics are kinda subtle, so I should chew on it...

How hard/easy would it be to leave it as is but insert an 'are you sure you want to create a new Type *foo* identical to existing Type *bar*' message?

A thought that Alexx has beaten me to...

Probably more work than simply preventing it entirely; hence, the desire to figure out whether it is legitimately ever desireable...

My instinct: disable for now, re-enable if someone ever requests it as a feature - they'll presumably have a compelling reason.

Yeah, that's likely the sensible approach...

  • 1
?

Log in

No account? Create an account