Wikipedia Abstrak/Maket awal
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
Berikut adalah tampilan sebuah objek Test yang baru dibuat. Diasumsikan bahwa namanya adalah rendering dari uji coba. Memang tidak kelihatan cantik, tetapi ini bisa dilakukan secara otomatis. Perhatikan bahwa tampilan objek adalah sebuah tampilan spesifik untuk Test.
Ini menggunakan tampilan generik untuk ZObjek, dengan asumsi bahwa tidak ada tampilan spesifik untuk ojbek Test.
Ini adalah tampilan setelah seseorang menghabiskan waktu membuat label yang lebih cantik, menulis sedikit dokumentasi (mengapa Tes ini relevan), dan menambahkan Test ke Fungsi multiply.
Menyunting objek
Ini adalah antarmuka yang kita gunakan saat mengedit objek Tes. Bukan berarti ini tidak memungkinkan mengubah label objek atau dokumentasi. Ini adalah antarmuka penyuntingan generik untuk ZObjek. Perhatikan bahwa pada dasarnya ini sama saja dengan antarmuka Pembuatan.
ZObjek bisa menjadi cukup luas. Kita bisa menyiutkan cabang-cabang ZObjek. Di sini, kita menyiutkan bagian yang melakukan penjumlahan dalam suku kedua perkalian.
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.
Alternatif desain
Dua maket berikut menunjukkan beberapa ide desain alternatif untuk membuat pengelompokan bentuk lebih eksplisit, di sini caranya adalah dengan menempatkan kotak putus-putus di sekitar bentuk yang seharusnya dikelompokkan. Ini juga menunjukkan dengan jelas apa yang akan diciutkan oleh proses penciutan.
Di sini kita memindahkan ikon untuk menyiutkan sebuah kotak ke kiri.
Maket telepon seluler
Berikut adalah maket untuk UX telepon seluluer. Kita memiliki ruang horizontal yang lebih kecil, jadi mengelompokkan pohon berdasarkan indentasi akan menghadapi masalah.
-
Di sini, kita menggunakan kotak dan menyedikitkan indentasi. -
Di sini, kita memindahkan elemen ciutkan ke kiri, untuk memberikan sedikit lebih banyak ruang. -
Di sini, salah satu kotak diciutkan, untuk memvisualkan bagaimana tampaknya.
