Abstract Wikipaedia/Early mockups

This page is a translated version of the page Abstract Wikipedia/Early mockups and the translation is 98% complete.

Outdated translations are marked like this.

Tracked in Phabricator:
Task T258902

Here ar a puckle gey early mockups for the Wikifunctions wiki.

Functions

The multiply function

Function definition

The heider shaws the label an the type o the object (here, a function). A function includes its signature as its type. Ablo that we see documentation.

Follaed ar the arguments o the multiply function, the return type, an a leet o available implementations. Ablo that we see a leet o tests wi a matrix o the implementations, an finally at the en a form whaur the reader can evaluate the function.

Implementation in JavaScript

This is ane o the implementations o the multiply function defined abuin, here in JavaScript.

Composition

This is anither implementation o the multiply function, this time composit frae ither functions in the wiki.

Test

Here is an ensaumple o a test for the multiplication function.

Succession

Note that aw NLG objects encode som specific approach. This isnae meant ti tak a decision regardin the specific NLG approach in advance, it is meant merely ti illustrate an visualise ideas. The concrete NLG approach which we will tak isnae decidit yet.

Constructor

This is the succession constructor. It shaws a complex constructor leadin til a clause.

Inglis renderer

This is a Inglis renderer for the succession constructor. It is gey semplified, an juist meant ti roughly display the idea.

Conjunction

Note that aw NLG objects encode som specific approach. This isnae meant ti tak a decision regardin the specific NLG approach in advance, it is meant merely ti illustrate an visualise ideas. The concrete NLG approach which we will tak isnae decidit yet.

This is a Inglis renderer for the succession constructor. It is gey semplified, an juist meant ti roughly display the idea.

This is basically the same, but haes an option regardin the Oxford comma.

Main page

Create a object

A new object is bein creatit. We first need ti select the type.

We chose the type "Test". Automatically, the relevant keys ar bein displayed.

In the first key, "function caa", we stairt typin an select a function, "multiply". Automatically, the relevant arguments for multiply ar bein shawed.

We stairt enterin the first value. This gets parsed as a literal o type positive integer.

Now in the second argument we type "add". This gets recognised as a function. Fields for the correct arguments ar bein added. We add literals.

The result condition is the saicont key o the test object. We stairt typin a function name, an select it. Result condition is o the type function takkin a object an returnin a leet o errors. We type "equal int", select the function, an it shaws the ane argument o that function.

Nou that we entered a literal, the object is complete an validates. It displays the publish button.

View a object

The follaein is a view on the newly creatit Test object. The assumption is that the name is a renderin o the test. It verra dinna leuk pretty, but can be duin automatically. Note that the view o the object is a specific view for Tests.

This is uisin the generic view for ZObjects, assumin that thare wad be no specific view for Test objects.

This is the view efter som body gaed throu the effort o creatin a nicer label, writin a bit o documentation (hou this Test is relevant), an addin the Test ti the multiply Function.

Eedit a object

This is the interface we en up wi whan eeditin the Test object. No that this disnae allou eeditin the label o the object or the documentation. This is the generic eeditin interface ti ZObjects. Note that it is basically the same as the Creation interface.

ZObject can become quite extensive. It is possible ti collapse the branches o the ZObject. Here we collapsed the pairt daein the addition in the saicont term o the multiplication.

Magic input box

A core pairt o the UX abuin is the magic input box. Hou ar these input boxes magical? Let’s tak a closer leuk at whit thay can dae: thay can tak fower types o input. Ilka input box haes a expectit type (in the worst case, the expectit type is “Any”).

A reference til a ZObject haein the expectit type, i.e. a ZID chosen bi its label or alias (or ID) an uisin a drop down selection (as whan choosin a item in Wikidata).
A function caa that results in a ZObject o the expected type. This is stairtit bi choosin a reference til a ZObject o a Function whose return type haes the expectit type, an as soon as this is chosen, the UI is updatit til allou for specifyin the arguments.
A literal. If the expectit type can be representit as a literal (e.g. for a string or a integer), that literal can be juist typed inti the input box. If the literal happens til also be possibly a reference o the right type, the drop down menu lists the literal as the first option. (Whether the expectit type can be representit as a literal depends on whether a function is specified for parsin values which taks a string an returns a instance o the expectit type.)
A poweruiser can switch any o these embeddit magical input boxes inti a muckler text field an dae raw eeditin. See the mock up efter this ane for that.

Since the magic will git it somtimes wrong (imagine, e.g. haein a expectit type o function(any, any), i.e. a arbitrary function, it will aye be unclear whether ye ar actually referencin a function, or whether ye ar makkin a function caa ti produce a function, an sae we micht en up in the wrong mode. The magic input box comes wi a toggle 𝌹 that allous ti lock ane o the fower modes explicitly (the nummer o modes can chynge slightly dependin on the expectit type, i.e. if the expectit type is function or any, thare isnae literal mode, etc.) as weel as chynge the expectit type.

This shaws a functional syntax for raw eeditin. Note that this is juist a UX thing — the input will git parsed an canonicalised afore storin. But particularly for codin a muckle nummer o fowk canna dae athoot copy an pastin etc., an no UI hae iver gatten this richt itherwise, sae we offer this option.

This is the same as the mock up afore, but instead o uisin a function syntax an labelised content it is raw as it can be an uises JSON an the ZIDs. Weel, it shuid eventually be a possibility.

Design alternatives

The follaein twa mock ups shaw som alternative design ideas ti mak the groupin o the forms mair explicit, here bi puttin a dashed boxed aboot the forms that belong thegither. It an aa shaws clearly whit the collapsin wad collapse.