Justin du Coeur (jducoeur) wrote in querki_project,
Justin du Coeur

Release 2.1.3

Today's release contains a whole bunch of tweaks to stuff that has been annoying users (including me) for some time. Going through it...

Reworking the Create Property box

I've been noticing for some time that the workflow for creating Properties, while theoretically clean and elegant, has a lot of little hiccups. Today's changes were primarily focused on smoothing those roadbumps.

Changed "Exactly One" to "Required": one of Querki's idiosyncrasies is that it doesn't make the usual assumption that values either exist or contain the magic value "null", as most databases and programming languages do. Instead, when you create a Property, you always specify its contents. I originally thought of that as how *many* elements it contains, which led to one of the choices being "Exactly One", but that's a weird non-adjective, and rubbed along poorly with "Optional". So I've changed that term to "Required", so that it contrasts better. So your choices are now "Required", "Optional", "List" and "Set". (Yes, List and Set are different. But I'm less and less convinced that this difference really matters to the user, so they might yet get squished together.)

The default Collection now depends on the Type: since the inception of Querki, new Properties defaulted to containing Exactly One value (what is now Required). But over the years of using it, I've concluded that that is almost never correct. In practice, the ideal Collection usually is related to the Type.

So the Collection now gets set to a default that depends on the Type you choose. Tags default to Set, Photos default to List and user-defined Model Types default to List; everything else currently defaults to Optional. These choices are not mandatory -- you can choose something different, and there are good use cases why you sometimes would want to -- but these defaults seem to be appropriate based on my experience of creating a lot of Spaces by now.

(Note that I am planning to tweak the semantics of Required in the not-too-distant future.)

Rearranged the Create Property box: to support the above, the choice of Collection now comes below the choice of Type. Previously you chose the Collection first, *then* the Type, but the other way around turns out to make more sense in practice.

Create Property box no longer resizes constantly: when you choose the Type you want, we show the documentation for that Type. Which is great, but it was resulting in the box size constantly shifting, and the buttons jumping around, which is really annoying. So the documentation now shows in a scrollable, fixed-size window instead.

"Pointer" types now require you to choose a Model upfront: this is actually the big one. Querki has two "pointer" Types -- Thing, which always names an existing Thing, and Tag, which is a name that *might* point to a Thing that you haven't created yet. There is a Restrict to Model meta-Property, that lets you say which Model this Property uses; for example, if you have a Meeting Model, with a Participants Property, that might be a Tag that is restricted to the Person Model.

In practice, you should *usually* restrict these Types to a specific Model: it means that, when you start typing, it can do a better job of prompting you with existing values that you've used before. But historically, the only way to get there was to manually create that other Model *first*, then create your Property, then edit your Property to point to the Model. It's been an ongoing pain point.

So this is now seriously revamped. When you are creating a Property, as soon as you choose "Tag" or "Thing" Type, it immediately presents you with a sub-panel that *requires* you to choose this upfront. You can choose to leave it free-form, or point to an existing Model, but most usefully you can tell it to create a new Model, and specify its name. It will immediately create a skeleton Model for you, and use that for the new Property. You can flesh out that Model later if you want, but don't have to -- it's not unusual to have a Model that exists solely to hang a particular kind of Tags off of.

This isn't necessarily the last word in this workflow, but I believe it'll be a big improvement, shaving 30 seconds off of Property creation in many cases. (Yes, that's a lot of time -- part of the point of Querki is that you can set up a Space in a few minutes.)

Model Type only shown in Programmer Mode: finally, when creating a Property, you can create it from an existing Model -- this is how you create complex data structures in Querki. This is *crazy* advanced, though: even I have only used this feature half a dozen times at the user level. (We use it internally in various places.) So we no longer display the option to do this in Builder mode: this is very much a Programmer feature, and it's only shown if you choose to be in Programmer mode.

Other Changes

Improvements to Facebook sharing: in the long run, being able to share Things on Facebook (and other such platforms) is a pretty high priority -- Querki is all about collaboration, and we want to work well with the social networks. But Facebook's rendering of links is, let's say, kind of persnickety. It's easy to deal with if you are writing a platform where everything is structured the same way, like a blog or news platform, but it's tricky for something as general as Querki, and there are a lot of details to get right. I've put in a couple of tweaks on this.

First of all, we now suppress HTML tags in the code we share with Facebook, because it turns out that they show up *as* tags rather than as the text you want. This fix makes the displayed text a *lot* more reasonable.

Second, if you specify one, Facebook linking will now show the contents of the Details Property on this Thing. (This change is actually subject to change: the more I think about it, the more I think it should be showing Summary instead. I'll likely tweak that shortly.)

Finally, I'm still trying to get the icon right. Suffice it to say, FB's rules for displaying a logo aren't especially obvious, so don't be surprised if this continues to evolve.

So far, I think I've taken it from "it sucks" to "it doesn't suck *too* badly". There's going to be more experimentation, to get us to a point where it looks reasonably good. (Suggestions welcomed.)

Design a New Model now works conventionally: Alexx pointed out to me that, when creating stuff (which he mostly does on mobile devices), he likes to long-press on links, and open them in a new tab, but that didn't work for Design a Model, either in the menu or the button. On a desktop browser, you similarly couldn't right-click and get the expected menu. Both of these were because those buttons weren't implemented as normal links, but as special magic that happened when you clicked on them. (This was so we could pop the "choose a Model" dialog before navigating.)

Suffice it to say, that mechanism has been completely rewritten, so that the menu item and button are now normal links. You won't see much difference, except that the URL changes at a different time in the process, and you can now do the long-press/right-click as expected.

Fixed Computed Name: this is one of the more advanced meta-Properties, and should be used when you don't want to give explicit Names to each Instance, but instead compute the Name based on its Properties. Somewhere along the line, links to Things with Computed Names stopped working, due to some parsing issues. This is now fixed, and they should work as expected.

Fixed Notifications: (I think.) I recently noticed that Notifications had gotten flaky. I've fixed one bug that could be causing that, but I'm not 100% certain that it was the only problem. If you find that you're not getting Notifications that you should be, please tell me.
Tags: releases
  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded