Wikipedia Abstrak/Maket awal

This page is a translated version of the page Abstract Wikipedia/Early mockups and the translation is 57% complete.
Outdated translations are marked like this.
Tracked in Phabricator:
task T258902

Berikut adalah beberapa maket sangat awal untuk wiki fungsi.

Fungsi

Fungsi pengali

Definisi fungsi

 

Kepala halaman menampilkan label dan tipe objek (yang ini adalah sebuah fungsi). Fungsi mengandung penanda berupa tipenya. Di bawahnya kita bisa melihat dokumentasi.

Berikutnya adalah argumen untuk fungsi pengali, tipe yang dikembalikan, dan daftar implementasi yang tersedia. Di bawahnya kita bisa melihat daftar uji coba dengan sebuah matriks implementasi, dan terakhir di paling bawah adalah formulir di mana pembaca bisa mengevaluasi suatu fungsi.

Implementasi dalam JavaScript

 

Ini adalah salah satu implementasi dari fungsi pengali yang ditetapkan di atas, yang ini dalam JavaScript.

Komposisi

 

Ini adalah implementasi lain dari fungsi pengali, yang ini terdiri (terkomposisi) dari fungsi-fungsi lain di wiki.

Uji coba

 

Berikut adalah contoh uji coba untuk fungsi perkalian.

Pergantian

Perlu diingat bahwa semua objek NLG mengodekan suatu pendekatan tertentu. Ini tidak dimaksudkan untuk menentukan pendekatan NLG spesifik dari awal, ini hanya untuk mengilustrasikan dan menggambarkan ide. Pendekatan NLG yang sesungguhnya kita akan ambil belum ditentukan.

Konstruktor

 

Ini adalah konstruktor pergantian. Terlihat sebuah konstruktor yang cukup rumit dan berakhir menghasilkan sebuah anak kalimat.

Renderer bahasa Inggris

 

Ini adalah sebuah renderer bahasa Inggris untuk konstruktor pergantian. Bentuknya sangat disederhanakan, dan hanya dimaksudkan untuk memberikan gambaran kasar ide.

Konjungsi

Perlu diingat bahwa semua objek NLG mengodekan suatu pendekatan tertentu. Ini tidak dimaksudkan untuk menentukan pendekatan NLG spesifik dari awal, ini hanya untuk mengilustrasikan dan menggambarkan ide. Pendekatan NLG yang sesungguhnya kita akan ambil belum ditentukan.

 

Ini adalah sebuah renderer bahasa Inggris untuk konstruktor konjungsi. Bentuknya sangat disederhanakan, dan hanya dimaksudkan untuk memberikan gambaran kasar ide.

 

Ini pada dasarnya sama, tetapi dengan pilihan mengenai tanda koma Oxford.

Halaman utama

 

Membuat objek

Objek baru sedang dibuat. Kita perlu kembali memili tipenya.

 

Kita memilih tipe "Test". Secara otomatis, kunci-kunci yang relevan ditampilkan.

 

Di kunci pertama, "function call", kita mulai mengetik dan memilih sebuah fungsi, "multiply". Secara otomatis, argumen-argumen untuk perkalian ditampilkan.

 

Kita mulai memasukkan nilai yang pertama. Ini ditafsirkan sebagai sebuah literal bertipe integer positif.

 

Sekarang di argumen kedua kita ketik "add". Ini dikenali sebagai sebuah fungsi. Muncul isian untuk argumen fungsi tersebut. Kita mengisinya dengan literal.

 

Kondisi hasil adalah kunci kedua dari objek uji coba. Kita mulai mengetik nama fungsi dan memilihnya. Kondisi hasil adalah fungsi tipe yang mengambil objek dan mengembalikan daftar galat. Kita mengetik "equal int", memilih fungsinya, dan ditampilkan satu argumen dari fungsi tersebut.

 

Sekarang kita sudah memasukkan sebuah literal, objeknya lengkap dan divalidasi. Ditampilkan tombol terbitkan.

 

Melihat objek

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.