Abstract Wikipedia/Early mockups

Tracked in Phabricator:
Task T258902

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

Functions

The multiply function

Function definition

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

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

Composition

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

Test

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

Succession

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

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

English renderer

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

Conjunction

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.

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

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

Main page

Create an object

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

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

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

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

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.

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.

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

View an object

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.

This is using the generic view for ZObjects, assuming that there would be no specific view for Test objects.

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.

Edit an object

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.

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.

Magic input box

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.

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.

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.

Design alternatives

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.

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

Mobile mocks

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.
• 
  Here we move the collapse element to the left, giving a bit more space.
• 
  Here one of the boxes is collapsed, to visualize how it would look like.