Is this good enough for a first version?

https://docs.google.com/presentation/d/1hZTo_2wpgDJL0MxdKX5pZepKV1Dpc---CgudNLh1rrA/edit#slide=id.g8d8b9d4c88_4_12

I probably should upload these individually to Commons, but I am lazy.

And we need to break it down into individual tasks, but I wanted to check if that is OK as a first design for now.

Here it is on Commons: https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Early_mockups

Change 621548 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/extensions/WikiLambda@master] [WIP] Add ability for custom renderers for each ZObject type

https://gerrit.wikimedia.org/r/621548

Here's a more detailed design of the Object creation interface.

Note that this doesn't need to be followed slavishly - it is more a help than anything. We expect that the UI will be entirely rewritten at least one or two more times in the mid-term anyway, so let's not fret too much over this.

So if anything here seems hard to implement, feel free to switch to something easier instead.

This roughly follows the mock ups given here: https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Early_mockups#Create_an_object

We are describing here a Special page for create new objects (Special:CreateObject or Special:CreateZObject), but note that it would be great for most of the UX to be reusable in different places. In particular I assume that the Editing interface is almost identical and would use the same components.

It starts with a field to select the type. The field has a label that says "Type". The type is any of the built-in types or one of the use created types. Note that all built-in types should be reflected on wiki, so asking for just the types from the wiki should be sufficient. The input box is a magic input box set to expect a Z4/Type.

https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Early_mockups#/media/File:Wikilambda_early_mockup_create_object_1.png

(Note that we for now ignore the suggestions from the mock up, we will implement these laters)

Once a type is selected, we look up all the keys and the associated types defined with the keys. We create one label and magical input box pair for each key, with the label coming from the key definition and display them under the existing form. The input boxes are set to expect the types as given by the key definition.

https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Early_mockups#/media/File:Wikilambda_early_mockup_create_object_2.png

When a ZObject is complete and checks out as valid, a wild "Publish" Button appears. Once that Button is clicked, a new wiki page with a new Z2/Persistent Object is created with the value set to the new object we just filled up. ZIDs are assigned consecutively.

https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Early_mockups#/media/File:Wikilambda_early_mockup_create_object_7.png

Magical input box

The magical input box is an autocomplete box with two states, which control its behavior: the expected type, and the mode. The expected type is usually set on creation, and the mode is set to 'auto'. For now, we allow for three modes: 'auto', 'literal' and 'reference' (later, we will have three more modes, 'function call', 'parse', and 'text edit', but we ignore that for now. Also, it will later be possible to set the expected type to 'any', but we ignore that for now as well).

There is some UX element associated with the autocomplete box which allows to manually switch the mode. (Later also to change the expected type). In the mock ups it is the Unicode character 𝌹, but really this can be also just a hamburger menu or something else.

When the magical input box is to the mode 'reference', it searches for all objects of the expected type based on the text entered by the user. A selection of autocompletes appear underneath with matching labels (bold) and types (below).

When the magical input box is set to the mode 'literal', and the expected type has a single key of type Z6/String, then we assume that the entered value is the string value of that single key.

Examples: Assume that the expected type is positive integer and the mode is literal. Assume that the type for positive integers (say Z70) has a key "representation" of type Z6/String. If the contributor types 7 in the box, we assume that the value { "Z1K1": "Z70", "Z70K1": "7" } has been entered.

Assume the expected type is Z6/String and the mode is literal. Then a text "foo" will be interpreted as { "Z1K1": "Z6", "Z6K1": "foo" }

When the magical input box is set to the mode 'auto' and the expected type has a single key of type Z6/String, then we try to both finding a reference and interpret the input as a literal. This looks a lot like the mode 'reference', but the first autocomplete field is always a literal (as above). If there are no matching references, this field is also the only one.

That would look like this (Expected type Z6/String, mode 'auto'):

Field value entered so far: wikil

Autocomplete fields:

"wikil"
String
_
Project name (Wikilambda)
String
_
Wikilausanne
String
_

If the expected type has more than one key, then switching the mode to 'literal' replaces the value box with a label Type, a magic input box of type Z4/Type preset to the type of the outer expected type, and below the labels and magical input boxes based on the keys of the expected type (basically it is the same thing as the top level).

If the expected type is a Z10/List, things get a little more complicated (in particular since we don't have generic types yet). The value looks like the top level thing and starts with expecting a type to set (but can be left empty for the empty list). As an element of the list gets filled up, a [+] button appears, which allows to add a new element (which again looks like the top level thing).

Next to each element of a list there's also a [-] button to remove the element.

Changing a type throws out all its subordinate values for now.

Ideally, this whole thing is a single Vue component.

The whole thing is very recursive.

We will design the other modes in detail as they appear.

The autocompletion is powered by T260750.