Selama bertahun-tahun, tim Blockly and Blockly Games telah memperoleh banyak pelajaran yang berlaku untuk mereka yang sedang mengembangkan blok baru. Berikut adalah kumpulan kesalahan yang telah kita buat, atau kesalahan yang biasa dilakukan oleh orang lain.
Ini adalah pelajaran umum yang telah kita pelajari menggunakan gaya visual Blockly dan mungkin tidak berlaku untuk semua kasus penggunaan atau desain. Ada solusi lain. Ini adalah juga bukan daftar lengkap masalah yang mungkin dihadapi pengguna dan cara menghindari mereka. Setiap {i>casing<i} sedikit berbeda dan memiliki konsekuensinya sendiri.
1. Bersyarat vs. Pengulangan
Blok yang paling sulit bagi pengguna baru adalah kondisional dan loop. Banyak lingkungan berbasis blok mengelompokkan kedua blok ini ke dalam 'Controls' yang sama kategori, di mana kedua blok memiliki bentuk dan warna yang sama. Hal ini sering menyebabkan frustrasi karena pengguna baru membingungkan kedua hal tersebut. Blockly merekomendasikan pemindahan kondisional dan loop ke 'Logic' terpisah dan 'Pengulangan' kategori, yang masing-masing memiliki warna berbeda. Ini memperjelas bahwa keduanya adalah ide-ide berbeda yang berperilaku berbeda, meskipun memiliki bentuk yang mirip.
Rekomendasi: Pisahkan kondisional dan loop.
2. Daftar Berbasis Satu
{i>Programmer<i} pemula bereaksi buruk ketika mereka menemukan daftar berbasis nol untuk pertama kalinya baik. Hasilnya, Blockly mengikuti tren Lua dan Lambda Moo dengan membuat daftar dan pengindeksan string satu per satu.
Untuk penggunaan lanjutan Blockly, daftar berbasis nol didukung untuk membuat transisi ke teks menjadi lebih mudah. Untuk audiens yang lebih muda atau baru pengindeksan satu platform masih direkomendasikan.
Rekomendasi: Satu adalah angka pertama.
3. Input pengguna
Ada tiga cara untuk mendapatkan parameter dari pengguna. {i>Dropdown<i} adalah paling ketat dan bagus untuk tutorial dan latihan sederhana. Kolom input memungkinkan lebih banyak kebebasan dan bagus untuk lebih banyak aktivitas kreatif. Blok nilai input (biasanya dengan blok bayangan) menawarkan peluang untuk menghitung nilai (misalnya, generator acak) alih-alih hanya menjadi nilai statis.
Rekomendasi: Pilih metode input yang sesuai untuk pengguna Anda.
4. Gambar live block
Dokumentasi untuk blok harus menyertakan gambar blok yang merujuknya tempat mesin terhubung. Mengambil screenshot itu mudah. Tetapi jika ada 50 gambar seperti itu, dan aplikasi ini diterjemahkan ke dalam 50 bahasa, tiba-tiba salah satunya mempertahankan 2.500 gambar statis. Kemudian skema warnanya berubah, dan 2.500 gambar perlu diperbarui -- lagi.
Untuk keluar dari mimpi buruk pemeliharaan mesin, Blockly Games menggantikan semua screenshot dengan instance Blockly yang berjalan dalam mode hanya baca. Hasil terlihat sama dengan gambar, tetapi dijamin selalu diperbarui. Hanya baca telah memungkinkan internasionalisasi.
Rekomendasi: Jika Anda mendukung lebih dari satu bahasa, gunakan mode hanya baca.
5. Sisi Kiri Anda yang lain
Masukan dari anak-anak di AS (meskipun menarik bukan dari negara lain) menunjukkan kebingungan yang meluas antara kiri dan kanan. Masalah ini diatasi dengan penambahan tanda panah. Jika arahnya relatif (misalnya, terhadap avatar) gaya panah. A → panah lurus atau panah belokan ↱ membingungkan saat avatar menghadap ke arah yang berlawanan. Yang paling membantu adalah ⟳ lingkaran panah, bahkan saat sudut yang diputar lebih kecil dari yang ditunjukkan panah.
Rekomendasi: Lengkapi teks dengan ikon Unicode jika memungkinkan.
6. Blok Tingkat Tinggi
Jika memungkinkan, pendekatan tingkat tinggi harus diambil, bahkan jika hal itu mengurangi performa atau fleksibilitas eksekusi. Pertimbangkan ekspresi Apps Script ini:
SpreadsheetApp.getActiveSheet().getDataRange().getValues()
Dalam pemetaan 1:1 yang mempertahankan semua potensi, ekspresi ini akan dibangun dengan menggunakan empat blok. Tapi Blockly menargetkan level yang lebih tinggi dan akan menyediakan satu blok yang mengenkapsulasi seluruh ekspresi. Tujuannya adalah untuk mengoptimalkan kasus 95%, meskipun itu membuat 5% sisanya menjadi lebih sulit. Blockly tidak dimaksudkan sebagai pengganti bahasa berbasis teks, melainkan dimaksudkan untuk membantu pengguna melewati kurva belajar awal sehingga mereka dapat menggunakan bahasa berbasis teks.
Rekomendasi: Jangan asal mengonversi seluruh API Anda menjadi blok.
7. Nilai yang Ditampilkan Opsional
Banyak fungsi dalam pemrograman berbasis teks melakukan suatu tindakan, kemudian
sebuah nilai. Nilai yang ditampilkan ini mungkin digunakan atau tidak. Contohnya adalah sebuah
Fungsi pop(). {i>Pop<i} mungkin dipanggil untuk
mendapatkan dan menghapus elemen terakhir,
atau mungkin dipanggil untuk menghapus elemen
terakhir dengan nilai yang ditampilkan
diabaikan.
var last = stack.pop(); // Get and remove last element. stack.pop(); // Just remove last element.
Bahasa berbasis pemblokiran umumnya tidak tepat untuk mengabaikan nilai yang ditampilkan. J harus terhubung ke sesuatu yang menerima nilai. Ada beberapa strategi untuk mengatasi masalah ini.
a) Mengarahkan masalahnya. Sebagian besar bahasa berbasis blok mendesain bahasa untuk menghindari kasus tersebut. Misalnya, Scratch tidak memiliki blok yang berisi efek samping dan nilai hasil.
b) Menyediakan dua blok. Jika ruang di {i>toolbox<i} tidak menjadi masalah, solusinya adalah dengan menyediakan dua dari setiap jenis blok ini, satu dengan dan satu tanpa nilai yang ditampilkan. Kelemahannya adalah, cara ini dapat menimbulkan kebingungan {i>toolbox<i} dengan jumlah blok yang hampir identik.
c) Mutasi satu blok. Gunakan {i>dropdown<i}, kotak centang, atau kontrol lain yang memungkinkan pengguna untuk memilih apakah ada nilai hasil yang dikembalikan atau tidak. Blok kemudian berubah bentuk tergantung dari pilihannya. Contohnya dapat berupa terlihat di blok akses daftar Blockly.
d) Menentukan nilainya. Versi pertama App Inventor membuat pipa khusus yang menghasilkan nilai apa pun yang terhubung. Para pengguna tidak memahami konsep, dan versi kedua dari {i>App Inventor<i} menghapus blok pipa dan sebagai gantinya merekomendasikan agar pengguna cukup menetapkan nilai ke variabel throwaway.
Rekomendasi: Setiap strategi memiliki kelebihan dan kekurangan, pilih strategi yang tepat pengguna Anda.
8. Blok pertumbuhan
Blok tertentu mungkin memerlukan jumlah input yang bervariasi. Contohnya adalah blok tambahan yang menjumlahkan sekumpulan angka, atau if/elseif/else blok dengan sekumpulan klausa elseif, atau konstruktor daftar dengan jumlah arbitrer dari elemen yang diinisialisasi. Ada beberapa strategi, masing-masing dengan kelebihan dan kekurangannya masing-masing.
a) Pendekatan yang paling sederhana adalah membuat pengguna menyusun blok dari kumpulan blok. Contohnya adalah menambahkan tiga angka, dengan menyarangkan dua angka dua angka blok tambahan. Contoh lain adalah hanya menyediakan blok {i>if/else<i}, dan membuat pengguna menyarangkannya untuk membuat kondisi {i>elseif<i}.
Keuntungan dari pendekatan ini adalah kesederhanaan awal (baik untuk pengguna maupun pengembang). Kerugiannya adalah bahwa dalam kasus di mana ada banyak jumlah bertingkat, kode menjadi sangat rumit dan sulit bagi pengguna untuk dibaca dan dikelola.
b) Alternatifnya adalah dengan memperluas blok secara dinamis sehingga selalu ada satu input bebas di akhir. Demikian pula, blok menghapus input terakhir jika ada dua input bebas di akhir. Ini adalah pendekatan yang dilakukan oleh versi pertama Penemu Apl digunakan.
Blok yang bertambah secara otomatis tidak disukai oleh pengguna App Inventor selama beberapa alasan. Pertama, selalu ada masukan gratis dan program tidak pernah 'complete'. Kedua, memasukkan elemen di tengah tumpukan adalah menjengkelkan karena melibatkan pemutusan semua elemen di bawah edit dan sehingga mereka dapat menghubungkannya kembali. Meskipun demikian, jika pesanan tidak penting, dan pengguna dapat merasa nyaman dengan {i>hole<i} dalam program mereka, ini adalah pilihan yang sangat nyaman.
c) Untuk mengatasi masalah lubang, beberapa pengembang menambahkan tombol +/- untuk memblokir yang menambahkan atau menghapus input secara manual. Buka Roberta menggunakan dua tombol tersebut untuk menambahkan atau menghapus {i>input <i}dari bawah. Developer lain menambahkan dua tombol di masing-masing baris sehingga penyisipan dan penghapusan dari tengah tumpukan mungkin diakomodasi. Yang lain menambahkan dua tombol atas/bawah di setiap baris sehingga menyusun ulang tumpukan itu dapat diakomodasi.
Strategi ini merupakan spektrum opsi yang mulai dari hanya dua tombol per blok, hingga empat tombol per baris. Di satu ujungnya adalah bahaya yang tidak dapat dilakukan pengguna untuk melakukan tindakan yang mereka butuhkan, di ujung lain UI dipenuhi dengan yang terlihat seperti jembatan pesawat antariksa Perusahaan.
d) Pendekatan yang paling fleksibel adalah menambahkan balon mutator ke blok. Ini direpresentasikan sebagai tombol tunggal yang membuka dialog konfigurasi untuk diblokir. Elemen dapat ditambahkan, dihapus, atau diatur ulang sesuai keinginan.
Kerugian dari pendekatan ini adalah bahwa mutatornya tidak intuitif untuk pengguna pemula. Pengenalan mutator memerlukan beberapa bentuk petunjuk. Aplikasi berbasis blok yang menargetkan anak-anak berusia lebih muda tidak boleh menggunakan mutator. Meskipun sudah dipelajari, keterampilan ini sangat berharga bagi pengguna tingkat lanjut.
Rekomendasi: Setiap strategi memiliki kelebihan dan kekurangan, pilih strategi yang tepat pengguna Anda.
9. Pembuatan Kode yang Bersih
Pengguna {i>Advanced Blockly<i} harus dapat melihat kode yang dihasilkan (JavaScript, Python, PHP, Lua, Dart, dll.) dan segera mengenali program yang mereka tulis. Artinya, perlu upaya ekstra untuk mempertahankan kode buatan mesin ini dapat dibaca. Tanda kurung berlebihan, variabel numerik, spasi kosong yang dihancurkan, dan template kode yang panjang akan menghalangi pembuatan kode yang elegan. Kode yang dihasilkan harus menyertakan komentar dan harus sesuai dengan Panduan gaya Google.
Rekomendasi: Berbanggalah dengan kode yang Anda hasilkan. Tunjukkan kepada pengguna.
10. Ketergantungan Bahasa
Efek samping dari keinginan akan kode yang bersih adalah bahwa perilaku Blockly sebagian besar ditentukan dari segi perilaku bahasa yang dikompilasi silang. Paling sering bahasa {i>output<i} yang umum adalah JavaScript, tetapi jika Blockly melakukan kompilasi silang bahasa lain, tidak boleh ada upaya yang tidak beralasan untuk mempertahankan perilaku yang sama persis di kedua bahasa. Misalnya, dalam JavaScript, {i>string<i} bernilai salah, sedangkan di Lua itu benar. Mendefinisikan satu pola dari yang akan dijalankan oleh kode Blockly, apa pun bahasa targetnya. menghasilkan kode yang tidak dapat dipelihara, yang sepertinya berasal dari kompiler GWT.
Rekomendasi: Blockly bukan bahasa, izinkan bahasa yang ada untuk memengaruhi perilaku.