Abstract Wikipedia/Early mockups

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search

Here are a few very early mockups for the function wiki.

Functions[edit]

The multiply function[edit]

Function definition[edit]

Wikilambda early mockup multiply function.png

The header shows the label and the type of the object (here, a function). A function includes its signature as its type. Below that we see documentation.

Followed are the arguments of the multiply function, the return type, and a list of available implementations. Below that we see a list of tests with a matrix of the implementations, and finally at the end a form where the reader can evaluate the function in place.

Implementation in JavaScript[edit]

Wikilambda early mockup multiply javascript.png

This is one of the implementations of the multiply function defined above, here in JavaScript.

Composition[edit]

Wikilambda early mockup multiply recursive addition.png

This is another implementation of the multiply function, this time composed from other functions in the wiki.

Test[edit]

Wikilambda early mockup multiply test.png

Here is an example of a test for the multiplication function.

Succession[edit]

Note that all NLG objects encode some specific approach. This is not meant to take a decision regarding the specific NLG approach in advance, it is meant merely to illustrate and visualize ideas. The concrete NLG approach which we will take is not decided upon yet.

Constructor[edit]

Wikilambda early mockup succession constructor.png

This is the succession constructor. It shows a pretty complex constructor leading to a clause.

English renderer[edit]

Wikilambda early mockup succession renderer english.png

This is an English renderer for the succession constructor. It is overly simplified, and just meant to roughly display the idea.

Conjunction[edit]

Note that all NLG objects encode some specific approach. This is not meant to take a decision regarding the specific NLG approach in advance, it is meant merely to illustrate and visualize ideas. The concrete NLG approach which we will take is not decided upon yet.

Wikilambda early mockup conjunction renderer.png

This is an English renderer for the conjunction constructor. It is overly simplified, and just meant to roughly display the idea.

Wikilambda early mockup conjunction renderer oxford.png

This is basically the same, but has an option regarding the Oxford comma.

Main page[edit]

Wikilambda early mockup title page.png

Create an object[edit]

A new object is being created. We first need to select the type.

Wikilambda early mockup create object 1.png

We chose the type "Test". Automatically, the relevant keys are being displayed.

Wikilambda early mockup create object 2.png

In the first key, "function call", we start typing and select a function, "multiply". Automatically, the relevant arguments for multiply are being shown.

Wikilambda early mockup create object 3.png

We start entering the first value. This gets parsed as a literal of type positive integer.

Wikilambda early mockup create object 4.png

Now in the second argument we type "add". This gets recognized as a function. Fields for the appropriate arguments are being added. We add literals.

Wikilambda early mockup create object 5.png

The result condition is the second key of the test object. We start typing a function name, and select it. Result condition is of the type function taking an object and returning a list of errors. We type "equal int", select the function, and it shows the one argument of that function.

Wikilambda early mockup create object 6.png

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

Wikilambda early mockup create object 7.png

View an object[edit]

The following is a view on the freshly created Test object. The assumption is that the name is a rendering of the test. It really doesn't look pretty, but can be done automatically. Note that the view of the object is a specific view for Tests. Wikilambda early mockup view object 1.png

This is using the generic view for ZObjects, assuming that there would be no specific view for Test objects. Wikilambda early mockup view object 2.png

This is the view after someone went through the effort of creating a nicer label, writing a bit of documentation (why is this Test relevant), and adding the Test to the multiply Function. Wikilambda early mockup view object 3.png

Edit an object[edit]

This is the interface we end up with when editing the Test object. Not that this does not allow editing the label of the object or the documentation. This is the generic editing interface to ZObjects. Note that it is basically the same as the Creation interface. Wikilambda early mockup edit object 1.png

ZObject can become quite extensive. It is possible to collapse the branches of the ZObject. Here we collapsed the part doing the addition in the second term of the multiplication. Wikilambda early mockup edit object 2.png

Magic input box[edit]

A core part of the UX above is the magic input box. Why are these input boxes magical? Let’s take a closer look at what they can do: they can take four types of input. Every input box has an expected type (in the worst case, the expected type is “Any”).

  • A reference to a ZObject having the expected type, i.e. a ZID chosen by its label or alias (or ID) and using a drop down selection (as when choosing an item in Wikidata).
  • A function call that results in a ZObject of the expected type. This is started by choosing a reference to a ZObject of a Function whose return type has the expected type, and as soon as this is chosen, the UI gets updated to allow for specifying the arguments.
  • A literal. If the expected type can be represented as a literal (e.g. for a string or an integer), that literal can be just typed into the input box. If the literal happens to also be possibly a reference of the right type, the drop down menu lists the literal as the first option. (Whether the expected type can be represented as a literal depends on whether a function is specified for parsing values which takes a string and returns an instance of the expected type)
  • A poweruser can switch any of these embedded magical input boxes into a larger text field and do raw editing. See the mock up after this one for that.

Since the magic will get it sometimes wrong (imagine, e.g. having an expected type of function(any, any), i.e. an arbitrary function, it will always be unclear whether you are actually referencing a function, or whether you’re making a function call to produce a function, and thus we might end up in the wrong mode. The magic input box comes with a toggle 𝌹 that allows to lock one of the four modes explicitly (the number of modes can vary slightly depending on the expected type, i.e. if the expected type is function or any, there is no literal mode, etc.) as well as change the expected type.

Wikilambda early mockup create object 7.png

This shows a functional syntax for raw editing. Note that this is just a UX thing - the input will get parsed and canonicalized before storing. But particularly for coding a lot of people can't do without copy and pasting etc., and no UI has ever gotten this right otherwise, so we offer this option.

Wikilambda early mockup magic input box text.png

This is the same as the mock up before, but instead of using a function syntax and labelized content it is raw as it can be and uses JSON and the ZIDs. Well, it should eventually be a possibility.

Wikilambda early mockup magic input box json.png

Design alternatives[edit]

The following two mock ups show some alternative design ideas to make the grouping of the forms more explicit, here by putting a dashed boxed around the forms that belong together. It also shows clearly what the collapsing would collapse.

Wikilambda early mockup with box collapse right.png

Here we move the icon to collapse a box to the left.

Wikilambda early mockup with box collapse left.png

Mobile mocks[edit]

These are mocks for the mobile UX. We have much less horizontal space, so grouping the tree by indentation might be problematic. Here we use boxes and minimal indentation.

Wikilambda early mockup mobile 1.png

Here we move the collapse element to the left, giving a bit more space.

Wikilambda early mockup mobile 2.png

Here one of the boxes is collapsed, to visualize how it would look like.

Wikilambda early mockup mobile 3.png