Previous Entry Share Next Entry
Pull on a thread, and the whole ball of twine starts unwinding
device
jducoeur wrote in querki_project
A few days ago, mindways observed that the Property name "Display Text" was kind of confusing, especially given that there is also a "Display Name". I've been chewing it over, and to my annoyance, I think he's right. I honestly don't even know when I came up with that name -- I suspect it's from the original design documents, long before I started coding, and I haven't ever questioned the assumption since then. But given that it's one of the dozen most important (and visible) Properties in the whole system, it's probably worth fixing. And if I'm going to fix it, I should probably do so before Alpha, lest I wind up breaking end-user code.

Of course, the question is how I avoid breaking my *own* code. I think mindways is correct that the right way to handle this is a "rename" refactoring capability, and I've put that onto the to-do list. But doing that *right* is far from trivial: it really needs to combine code parsing with code rebuilding, and not all the pieces of that exist. It's probably 75% of the way there (due to the _code() method, which needs a lot of that), but hasn't worried yet about things like preserving formatting, which matter if you're going to do something like this. And frankly, I need a lot more test infrastructure in order to do this properly. So I don't want to hold Alpha up for all of that.

Still and all, I want *something* so that I can at least manually find and fix the references. And it occurs to me that the trivial manual first step is search. If I can search on the string "Display Text", that should reduce the difficulty of dealing with this by 90%. And of course, Search has always been in the plans, just not yet.

So I think I'm going to detour for yet another day or two, and add the very primitive beginnings of Search. It won't be pretty, and it's going to be a *very* long ways from where I eventually want it, but I suspect that I can implement a trivial "exact string match" version pretty fast, and that's probably good enough for half of all likely uses -- the bang for the buck is very high.

[ETA: Oh, right -- this is why I work in Scala. Okay, first draft of Search is working. *Extremely* crude in many ways, so don't expect too much from it, but it's a decent start. Will be released sometime in the next few days.]


In the meantime, I'll toss out a question to the audience: what should the new name be? The property called "Display Text" is basically the template that gets used to show this Thing to users: a mix of wikitext and QL expressions. It is *usually* (but not necessarily) defined on the Model and then used by the Instances. mindways suggested "Page View", which isn't bad but isn't obviously perfect, so brainstorming is requested. I'd specifically like to avoid programmer jargon: this is a crucial, end-user-visible Property, so try to think with a non-engineer's brain. (Hence, I'm cautious about actually calling it a "template" -- I'm not sure whether folks are likely to get that or not.) Suggestions solicited...
Tags:

  • 1
(Deleted comment)
D'oh -- as mindways observed downthread, I managed to confuse *myself* while typing, and casually typed "Display Name" a couple of times, when the intent was "Display Text". I suppose that drives the point home...

If I can search on the string "Display Name", that should reduce the difficulty of dealing with this by 90%.

The property called "Display Name" is basically the template that gets used to show this Thing to users: a mix of wikitext and QL expressions.

s/Display Name/Display Text/

Other ideas:
* Just "Display"
* "As a Page"
* "Render", "Render Text" (probably too technical)
* "Default View" / "Default Display" (implies there might be non-default ones; only use if this is true)

* Just "Display"

Interesting. I like the elegance of that. Possible.

* "As a Page"

Also possible -- nicely descriptive.

* "Render", "Render Text" (probably too technical)

Yeah, my suspicion is that it is -- the focus winds up on how it is processed, which doesn't seem quite right.

* "Default View" / "Default Display" (implies there might be non-default ones; only use if this is true)

As it happens, that *does* turn out to be true. This is one of those things that I never realized until I started doing a fair amount with Querki, and came to realize that alternate views are useful tools.

So this might actually be very exactly descriptive, although it hadn't occurred to me to think of it that way before...

Okay, time to choose. I think I'm going to declare "Default View" the winner: of the options we've discussed, it seems to be the one that most precisely fits the semantics of what the Property actually *does*. (Indeed, the way I wrote the documentation for _propLink actually reads better with this name change.) Thanks for the suggestion...

I wonder if you can teach your language to Grok...

Intriguing. Truth is, I've given almost zero thought to parsing so far -- it isn't terribly relevant to any of my use cases to date -- but it's likely to prove important to have.

Good point -- thanks...

Name brainstorming:

What do those end users actually use it for? Why is it shown to the users? (Why would users want to see the innards in that way?)

It's a good question, and the answer reflects the squishiness of "programmer" vs. "end user" in Querki. Time for a philosophical tangent.

Folks talk a lot about the "maker generation" nowadays -- the assorted hardware hackery that people are doing more and more. And it's been trendy for 5-10 years to talk about "mass customization" in all sorts of consumer goods: sometimes that's just marketing hype, but we are seeing a fair of shops that really do let you customize your goods along many dimensions.

Oddly, that seems to apply everywhere *but* software. Most programs offer, at best, a few configuration switches to play with, but by and large follow the "priesthood of programmers" model. An engineer builds the software; a dumb user uses that software, as dictated to them. If you're not the one building this program, you put up with what the programmer decided on.

Personally, I find that frustrating as hell, especially for the sort of data-management tasks that Querki is focused on. Peoples' needs really do vary, and I've rarely found *any* data-management software, from inventory control to cookbooks, that I thought was quite right for my needs. Using most of these is a question of finding the least-bad-fit, and putting up with a constant undercurrent of annoyance at it.

So Querki is intentionally radical in this respect: at the architectural level, it is designed for tinkering. Querki's "Apps" aren't hard and fast programs, they are *templates*, designed for adaptation. Adding a property or two, or even a couple of new Models, isn't just possible, it's intended to be SOP, at least for power users. It isn't clear that it'll even be possible in Querki to declare an App "final": the rule is that the consumer makes the final decisions, not the programmer.

(I am honest with myself that 80% of users will never customize in the slightest, and that's fine. But the capability is there, and the right answer to "I wish the program could do X" is to fix it -- or at least, to get your son-in-law to fix it.)

Since Display Text is how you actually *view* something, it's front-and-center to any customization. If you add a Property, you almost certainly need to tweak the Display Text to include it. Indeed, this is so important that the most challenging planned feature for next year -- Querki Explorer, which is going to be a *serious* UX adventure -- is all about building a wizard that lets you write/edit the Display Text without needing to "program".

Of course, there is a lot of hypothesis here -- we'll see how things work out in the long run. But that's the plan, and is why this template isn't simply confined to programmers in the Querki model: the line between "programmer" and "end user" is, very deliberately, blurry.

(And yes, I recognize the UX dangers in this approach. Querki almost certainly will be used to create a lot of software with horrifically bad UX, as a consequence of this "tinkering" model. I'm hoping that we can mitigate that by building a lot of best practices directly into the libraries, and otherwise recognizing that customization to individual taste is intentionally the highest priority...)

  • 1
?

Log in

No account? Create an account