במשך השנים, צוות Blockly עיצב הרבה בלוקים משלו ועזר לאחרים לעצב בלוקים משלהם. ריכזנו כאן כמה מהלקחים שלמדו.
עדיפות לאבני בניין ברמה גבוהה
כשהדבר אפשרי, כדאי לבחור בגישה ברמה גבוהה יותר, גם אם היא מפחיתה את הביצועים או הגמישות של הביצוע. נבחן את הביטוי הבא ב-Apps Script:
SpreadsheetApp.getActiveSheet().getDataRange().getValues()
במיפוי של 1:1 שמאפשר לשמור על כל היכולות הפוטנציאליות, הביטוי שלמעלה ייבנה באמצעות ארבעה בלוקים. אבל Blockly שואפת לרמה גבוהה יותר, ותספק בלוק אחד שמכיל את הביטוי כולו. המטרה היא לבצע אופטימיזציה ל-95% מהמקרים, גם אם זה יקשה על ה-5% הנותרים. Blockly לא נועד להחליף שפות מבוססות-טקסט, אלא לעזור למשתמשים להתגבר על 'עקומת הלמידה' הראשונית כדי שיוכלו להשתמש בשפות מבוססות-טקסט.
המלצה: אל תבצעו המרה עיוורת של כל ה-API לבלוק.
כדאי להביא בחשבון את האפשרויות של הקלט מהמשתמשים
יש שלוש דרכים לקבל פרמטר מהמשתמש. תפריט נפתח הוא המגבלה ביותר, והוא מתאים למדריכים ולתרגילים פשוטים. שדה קלט מאפשר יותר חופש וטוב לפעילויות יצירתיות יותר. קלט של בלוק ערך (בדרך כלל עם בלוק צל) מאפשר לחשב ערך (למשל, גנרטור אקראי) במקום להיות רק ערך סטטי.
המלצה: בוחרים שיטת קלט שמתאימה למשתמשים.
שימוש בבלוק מותנה ובבלוק לולאה נפרדים
הבלוקסים הכי קשים למשתמשים חדשים הם תנאים וחזרות. בסביבות רבות שמבוססות על בלוקים, שני הבלוקס האלה מקובצים באותה קטגוריה 'אמצעי בקרה', ושניהם באותו צורה ובאותו צבע. לרוב זה מוביל לתסכול, כי משתמשים חדשים מבלבלים בין שני הקטעים. ב-Blockly מומלץ להעביר תנאים וחזרות לקטגוריות נפרדות של 'לוגיקה' ו 'חזרות', כל אחת בצבע שונה. כך ברור שמדובר ברעיונות נפרדים עם התנהגות שונה, למרות שהצורות שלהם דומות.
המלצה: כדאי להפריד בין תנאים לבין לולאות.
טיפול במספר משתנה של מקורות קלט
יכול להיות שבלוקים מסוימים ידרשו מספר משתנה של מקורות קלט. דוגמאות לכך הן בלוק חיבור שמחשב את הסכום של קבוצה שרירותית של מספרים, בלוק if/elseif/else עם קבוצה שרירותית של תנאי elseif או קונסטרוקטור של רשימה עם מספר שרירותי של רכיבים שהוגדרו מראש. יש כמה אסטרטגיות, לכל אחת מהן יתרונות וחסרונות.
א) הגישה הפשוטה ביותר היא לאפשר למשתמש ליצור את הבלוק מבלוקסים קטנים יותר. לדוגמה, כדי להוסיף שלושה מספרים, אפשר להטמיע שני בלוקים של הוספת שני מספרים. דוגמה נוספת היא מתן בלוקים של if/else בלבד, והתרת למשתמש להטמיע אותם כדי ליצור תנאי elseif.
היתרון של הגישה הזו הוא הפשטות הראשונית שלה (גם למשתמש וגם למפתח). החיסרון הוא שבמקרים שבהם יש מספר גדול של עיטורים, הקוד הופך להיות מסורבל מאוד וקשה למשתמש לקרוא אותו ולתחזק אותו.
ב) אפשרות אחרת היא להרחיב את הבלוק באופן דינמי כך שתמיד יהיה קלט אחד פנוי בסוף. באופן דומה, הבלוק מוחק את הקלט האחרון אם יש שני מקורות קלט פנויים בסוף. זו הגישה שבה השתמשו בגרסה הראשונה של App Inventor.
למשתמשים ב-App Inventor לא אהב את האפשרות של יצירת בלוקים באופן אוטומטי מכמה סיבות. ראשית, תמיד הייתה אפשרות להזין נתונים בחינם, והתוכנית אף פעם לא הייתה 'שלמה'. שנית, הוספת אלמנט באמצע המקבץ הייתה מתסכלת כי היא כללה ניתוק של כל האלמנטים מתחת לעריכה וחיבור מחדש שלהם. עם זאת, אם הסדר לא חשוב, והמשתמשים יכולים להסתדר עם חורים בתוכנית, זו אפשרות נוחה מאוד.
ג) כדי לפתור את הבעיה של החור, חלק מהמפתחים מוסיפים לחצנים של +/- לבלוק כדי להוסיף או להסיר באופן ידני את הקלט. ב-Open Roberta יש שני לחצנים כאלה להוספה או להסרה של קלט מלמטה. מפתחים אחרים מוסיפים שני לחצנים לכל שורה כדי לאפשר הוספה ומחיקה מאמצע הערימה. בחלק מהפלאגינים מתווספים שני לחצנים למעלה/למטה בכל שורה כדי שאפשר יהיה לשנות את הסדר של הערימה.
האסטרטגיה הזו כוללת מגוון אפשרויות, החל משני לחצנים בלבד בכל בלוק ועד לארבעה לחצנים בכל שורה. מצד אחד, יש סכנה שהמשתמשים לא יוכלו לבצע את הפעולות הנדרשות, ומצד שני, ממשק המשתמש מלא כל כך בלחצנים שהוא נראה כמו גשר של ספינת החלל אנטראנס.
ד) הגישה הגמישה ביותר היא להוסיף לבלוק בועה של פונקציית טרנספורמציה. הוא מיוצג כלחצן יחיד שפותח תיבת דו-שיח של הגדרות עבור הבלוק הזה. אפשר להוסיף, למחוק או לסדר מחדש את הרכיבים לפי הצורך.
החיסרון של הגישה הזו הוא שהמוטאציות לא אינטואיטיביות למשתמשים מתחילים. כדי להוסיף משתני מוטאציה, צריך להשתמש בהוראות מסוימות. באפליקציות שמבוססות על Blockly ומשויכות לילדים צעירים, אסור להשתמש במוטאטורים. אחרי שמבינים איך משתמשים בהן, הן פשוטות וחיוניות למשתמשים מתקדמים.
המלצה: לכל אסטרטגיה יש יתרונות וחסרונות, לכן כדאי לבחור את זו שמתאימה למשתמשים שלכם.