Blockly ve Blockly Games ekibi yıllar içinde yeni bloklar geliştirenlere uygulanabilecek birçok ders öğrendi. Yaptığımız veya başkalarının yaygın olarak yaptığı hatalar aşağıda özetlenmiştir.
Bunlar, Blockly'nin görsel stilini kullanarak öğrendiğimiz genel derslerdir ve tüm kullanım alanları veya tasarımlar için geçerli olmayabilir. Başka çözümler mevcuttur. Bu, kullanıcıların karşılaşabileceği sorunların ve bunlardan nasıl kaçınılacağının da kapsamlı bir listesi değildir. Her durum biraz farklıdır ve kendine özgü ödünleri vardır.
1. Koşullu durumlar ve döngüler karşılaştırması
Yeni kullanıcılar için en zor olan bloklar, koşullu durumlar ve döngülerdir. Blok tabanlı birçok ortam, bu blokların her ikisini de aynı şekle ve aynı renge sahip olacak şekilde aynı "Kontroller" kategorisinde gruplandırır. Yeni kullanıcılar iki engeli karıştırdığı için bu durum genellikle hayal kırıklığına yol açar. Blockly, koşul ve döngülerin her biri farklı renkteki ayrı "Mantık" ve "Döngü" kategorilerine taşınmasını önerir. Bu, benzer şekillere sahip olmalarına rağmen farklı davranan farklı fikirler olduğunu açıkça ortaya koyar.
Öneri: Koşulları ve döngüleri ayrı tutun.
2. Tek Tabanlı Listeler
Acemi programcılar ilk kez sıfır tabanlı listelerle karşılaştıklarında kötü tepki verirler. Bunun sonucunda Blockly, liste ve dize dizine ekleme işlemini tek tabanlı yaparak Lua ve Lambda Moo'nun öncülüğünü yapıyor.
Blockly'nin daha gelişmiş kullanımlarında, metne geçişi kolaylaştırmak için sıfır tabanlı listeler desteklenir. Daha genç veya daha acemi kitleler için yine de tek tabanlı dizine ekleme önerilir.
Öneri: Bir, ilk sayıdır.
3. Kullanıcı girişleri
Kullanıcıdan parametre almanın üç yolu vardır. Açılır liste en kısıtlayıcıdır ve basit eğitimler ile alıştırmalar için idealdir. Giriş alanı daha fazla özgürlük sağlar ve daha yaratıcı etkinlikler için uygundur. Değer bloğu girişi (genellikle bir gölge bloğuyla), sadece statik bir değer olmak yerine bir değer hesaplama (ör. rastgele bir oluşturucu) fırsatı sunar.
Öneri: Kullanıcılarınıza uygun bir giriş yöntemi seçin.
4. Animasyonlu engelleme resimleri
Bloklarla ilgili belgeler, atıfta bulunduğu blokların resimlerini içermelidir. Ekran görüntüsü almak kolaydır. Ancak bu tür 50 görüntü varsa ve uygulama 50 dile çevrilirse aniden biri 2.500 statik görüntüye dönüşür. Daha sonra renk şeması değişiyor ve 2.500 resmin tekrar güncellenmesi gerekiyor.
Bu bakım kabusundan kurtulmak için Blockly Games, tüm ekran görüntülerinin yerine Blockly'nin salt okunur modda çalıştığını gösterdi. Sonuç, bir resimle aynı görünür ancak güncel olması garanti edilir. Salt okuma modu, uluslararasılaştırmayı mümkün hale getirmiştir.
Öneri: Birden fazla dili destekliyorsanız salt okuma modunu kullanın.
5. Diğer Solunuz
ABD'deki çocuklardan gelen geri bildirimler (ilginç bir şekilde diğer ülkelerden gelmese de) sol ve sağ arasında yaygın bir karışıklık olduğunu ortaya çıkardı. Bu sorun, okların eklenmesiyle çözülmüştür. Yön göreliyse (ör. bir avatara göre) ok stili önemlidir. Avatar ters yöne bakarken A → düz ok veya ↱ dönüş oku kafa karıştırıcıdır. Döndürülen açının okla gösterilenden daha küçük olduğu durumlarda bile ⟳ dairesel ok daha faydalı olur.
Öneri: Mümkün olduğunda Unicode simgeleriyle metni destekleyin.
6. Üst Seviye Bloklar
Mümkün olduğunda, yürütme performansını veya esnekliğini azaltsa bile daha üst düzey bir yaklaşım benimsenmelidir. Şu Apps Komut Dosyası ifadesini düşünün:
SpreadsheetApp.getActiveSheet().getDataRange().getValues()
Tüm olası özelliklerin korunduğu bire bir eşlemede, yukarıdaki ifade dört blok kullanılarak oluşturulur. Ancak Blockly daha yüksek bir düzeyi hedefler ve ifadenin tamamını kapsayan bir blok sağlar. Hedef, geri kalan% 5'i daha zor hale getirse bile% 95'lik durum için optimizasyon yapmaktır. Blockly'nin metin tabanlı dillerin yerine kullanılması amaçlanmamıştır. Kullanıcıların metin tabanlı dilleri kullanabilmeleri için ilk öğrenme eğrisini aşmalarına yardımcı olmak amacıyla tasarlanmıştır.
Öneri: API'nizin tamamını körü körüne bloklara dönüştürmeyin.
7. İsteğe Bağlı İade Değerleri
Metin tabanlı programlamadaki birçok işlev bir işlem gerçekleştirir, ardından bir değer döndürür. Döndürülen bu değer kullanılabilir veya kullanılmayabilir. Bir yığının pop() işlevi, buna örnek olarak verilebilir. Pop, son öğeyi alıp kaldırmak için veya döndürülen değeri yoksayılan son öğeyi kaldırmak için çağrılabilir.
var last = stack.pop(); // Get and remove last element. stack.pop(); // Just remove last element.
Blok tabanlı diller, genellikle döndürülen bir değeri yoksayma konusunda iyi değildir. Değer bloğunun, değeri kabul eden bir öğeye eklenmesi gerekir. Bu sorunla başa çıkmak için pek çok strateji vardır.
a) Soruna yön verin. Blok tabanlı dillerin çoğu, bu gibi durumlardan kaçınmak için dili tasarlar. Örneğin, Scratch'te hem yan etkiler hem de döndürülen değer içeren bloklar yoktur.
b) İki blok belirtin. Araç kutusundaki alan sorun değilse, biri döndürülen değer bulunan diğeri olmayan bu tür blokların her birinden iki tane sağlamak basit bir çözümdür. Olumsuz tarafı ise neredeyse aynı blokların olduğu karmaşık bir araç kutusuna yol açabilmesidir.
c) Bir bloku değiştirme. Kullanıcının döndürülen değer olup olmadığını belirlemesine olanak tanıyan açılır liste, onay kutusu veya başka bir denetim kullanın. Daha sonra bloğun şekli, bulunduğu seçeneklere göre değişir. Buna bir örnek, Blockly'nin liste erişim bloğunda gösterilebilir.
d) Değeri yiyin. App Inventor'ın ilk sürümü, bağlı tüm değerleri yiyen özel bir dikey boru bloğu oluşturdu. Kullanıcılar konsepti anlamamıştır ve App Inventor'ın ikinci sürümü boru blokunu kaldırıp bunun yerine kullanıcıların değeri atılabilir bir değişkene atamasını önerdi.
Öneri: Her stratejinin avantajları ve dezavantajları vardır. Kullanıcılarınız için doğru stratejiyi seçin.
8. Büyüyen bloklar
Belirli bloklar için değişken sayıda giriş gerekebilir. Örnekler, rastgele bir sayı kümesini toplayan bir toplama bloku, rastgele bir elseif deyimi kümesini içeren if/elseif/else bloğu ya da rastgele sayıda başlatılmış öğe içeren bir liste oluşturucusudur. Her birinin avantajları ve dezavantajları olan çeşitli stratejiler vardır.
a) En basit yaklaşım, kullanıcının bloku daha küçük bloklar halinde oluşturmasını sağlamaktır. Örneğin, iki adet iki rakamlı toplama bloğunu iç içe yerleştirerek üç sayı toplayabilirsiniz. Başka bir örnek de sadece if/else blokları sağlayıp kullanıcının bunları otherif koşulları oluşturmak için iç içe yerleştirmesini sağlamaktır.
Bu yaklaşımın avantajı, basitliğidir (hem kullanıcı hem de geliştirici için). Dezavantajı, çok sayıda iç içe yerleştirme olduğu durumlarda kodun çok kullanışsız hale gelmesi ve kullanıcının okuması ve bakımının zorlaşmasıdır.
b) Bir alternatif, bloku dinamik olarak genişletmek, böylece sonda her zaman bir boş giriş olmaktır. Benzer şekilde, sonda iki boş giriş varsa blok son girişi siler. App Inventor'ın ilk sürümünde bu yaklaşım kullanılıyordu.
Otomatik olarak artan engellemeler, App Inventor kullanıcıları tarafından birkaç nedenden dolayı beğenmemiştir. İlk olarak, her zaman ücretsiz giriş imkanı vardı ve program hiçbir zaman "tamamlanmadı". İkinci olarak, yığının ortasına bir öğe eklemek, düzenlemenin altındaki tüm öğelerin bağlantısının kesilip yeniden bağlanmasını içerdiğinden sinir bozucuydu. Bununla birlikte, sıra önemli değilse ve kullanıcıların programlarındaki deliklerden dolayı rahat hissetmeleri gerekiyorsa bu çok kullanışlı bir seçenektir.
c) Delik sorununu çözmek için bazı geliştiriciler, girişleri manuel olarak ekleyen veya kaldıran bloklara +/- düğmeleri eklerler. Open Roberta, alttan giriş eklemek veya kaldırmak için bu tür iki düğme kullanır. Diğer geliştiriciler, yığının ortasından ekleme ve silme işleminin gerçekleştirilebilmesi için her bir satıra iki düğme ekler. Bazıları ise yığının yeniden düzenlenmesine olanak tanımak için her satıra iki yukarı/aşağı düğmesi ekler.
Bu strateji, blok başına iki düğmeden satır başına dört düğmeye kadar birçok seçenek yelpazesini kapsar. Bir ucunda kullanıcıların ihtiyaç duydukları işlemleri yapamama tehlikesi vardır. Diğer tarafta ise kullanıcı arayüzü, çok sayıda düğmeyle dolu olduğu için uzay gemisi Enterprise'ın köprüsü gibi görünür.
d) En esnek yaklaşım, bloka bir mutator balonu eklemektir. Bu, söz konusu blok için yapılandırma iletişim kutusunu açan tek bir düğme olarak gösterilir. Öğeler istendiğinde eklenebilir, silinebilir veya yeniden düzenlenebilir.
Bu yaklaşımın dezavantajı, mutatörlerin acemi kullanıcılar için sezgisel olmamasıdır. Mutatörleri kullanıma sunmak için bir tür talimat gerekir. Daha küçük çocukları hedefleyen blok temelli uygulamalarda mutatör kullanılmamalıdır. Ancak deneyimli kullanıcılar için paha biçilmezdirler.
Öneri: Her stratejinin avantajları ve dezavantajları vardır. Kullanıcılarınız için doğru stratejiyi seçin.
9. Temiz Kod Oluşturma
İleri düzey Blockly kullanıcıları, oluşturulan koda (JavaScript, Python, PHP, Lua, Dart vb.) bakabilmeli ve yazdıkları programı hemen tanıyabilmelidir. Bu nedenle, makine tarafından oluşturulan bu kodun okunabilirliğini korumak için ekstra çaba sarf edilmesi gerekir. Gereksiz parantezler, sayısal değişkenler, sıkıştırılmış boşluklar ve ayrıntılı kod şablonları zarif kodlar üretmenin önüne geçer. Oluşturulan kod yorum içermeli ve Google'ın stil kılavuzlarına uygun olmalıdır.
Öneri: Ürettiğiniz kodla gurur duyun. Kullanıcıya gösterin.
10. Dil Bağımlılığı
Temiz kod istemenin yan etkilerinden biri, Blockly'nin davranışının büyük ölçüde, çapraz derlenen dilin davranışı açısından tanımlanmasıdır. En yaygın çıkış dili JavaScript'tir. Ancak Blockly'nin farklı bir dilde çapraz derleme yapması durumunda, her iki dilde de aynı davranışı korumak için makul olmayan herhangi bir girişimde bulunulmamalıdır. Örneğin, JavaScript'te boş bir dize yanlış, Lua'da doğrudur. Blokly'nin kodunun hedef dilden bağımsız olarak yürütülmesi için tek bir davranış kalıbı tanımlamak, kodun GWT derleyicisinden çıkmış gibi göründüğü, yönetilemeyen koda yol açar.
Öneri: Blockly bir dil değildir. Mevcut dilin davranışı etkilemesine izin verin.