במהלך השנים הצוות שלBlockly ו-Blockly Games הלמד לקחים רבים שרלוונטיים למפתחים שמפתחים אפליקציות מבוססות-Blockly. הרשימה הבאה היא אוסף של טעויות שעשינו או טעויות של אנשים אחרים.
אלה לקחים כלליים שלמדנו מהסגנון החזותי של blockly, ויכול להיות שהם לא רלוונטיים לכל תרחישי השימוש או העיצובים. ייתכן שקיימים פתרונות נוספים. זו גם לא רשימה מלאה של הבעיות שהמשתמשים עשויים להיתקל בהן ואיך להימנע מהן. כל מקרה הוא שונה במקצת וייתכן שיש לו השלכות שונות.
1. סגנון גבול
בשנות ה-2000, מראה ה-Aqua היה בסגנון וכל אובייקט במסך קושט בהדגשה וצללים. בשנות ה-10, העיצוב של Material Design (עיצוב חומרים) בסטייל וכל אובייקט שמופיע במסך פשוט קיבל צורה נקייה, שטוחה וחסרת גבולות. ברוב סביבות התכנות ליצירת בלוקים יש הדגשה וצללים מסביב לכל בלוק. לכן, כשמעצבים גרפיים כיום רואים אותן, הם תמיד מסירים את העיצובים המיושנים האלה.
כפי שאפשר לראות בדוגמה של חמישה בלוקים (מ-scriptr.io) שלמעלה, ה'קישוטים המיושנים' האלה חיוניים להבחנה בין בלוקים מחוברים בעלי אותו צבע.
המלצה: אם תפרו את המראה שלBlockly, אל תתנו לאופנה של היום להרוס את האפליקציה שלכם.
2. ערימות משנה בתוך רכיב
לבלוקים בצורת C יש תמיד מחבר בחלק הפנימי העליון, אבל בסביבות מסוימות יש גם מחבר בחלק התחתון (למשל Wonder Workshop), ואילו לסביבות אחרות אין (למשל blockly ו-Scratch). מאחר שלרוב בלוקי ההצהרות יש מחבר עליון ומחבר תחתון, חלק מהמשתמשים לא רואים מיד שדפי החשבון יתאימו ל-C שאין לה מחבר תחתון.
כשהמשתמשים מבינים שבלוק הצהרה אחד מתאים באות דו, הם צריכים להבין שהצהרה אחת נוספת תתאים. סביבות מסוימות מוצבות בחיבור הנמוך יותר של ההצהרה הראשונה לתוך החלק התחתון של האות 'C' (לדוגמה, Wonder Workshop ו-Scratch), ואילו אחרות משאירות פער קטן (למשל,Blockly). הקינון הנוח לא מרמז על כך שאפשר לערום עוד בלוקים.
בין שתי הבעיות האלה אין אינטראקציה קבילה. אם קיים מחבר פנימי (וונדר סדנת), החיבור של ההצהרה הראשונית ברור יותר, אבל בגלל היכולת לגלות ערימות. אם לא קיים מחבר פנימי (Blockly), אי אפשר לראות בבירור את החיבור של ההצהרה הראשונית, אבל אפשר לאתר את המקבץ. כשבודקים באמצעות חסימת Scratch את המחבר התחתון של ההצהרה, אין שני מחברים פנימיים והצבתם בתוך המחבר התחתון (Scratch).
מניסיוננו, החיבור של ההצהרה הראשונית מהווה אתגר קטן יותר למשתמשים מאשר איתור של מקבצים. ברגע שמתגלים את הראשון, לעולם לא שוכחים אותו, ואילו השני זקוק להנחיות. ניסו מאוד את ה-Wonder Workshop וגם את Scratch, עד שיום אחד התרחש באג רינדור שהוסיף את הפער הקטן. הבאג הזה ראינו שיפור משמעותי במחקרי משתמשים ב-Blockly (כיום, זוהי 'תכונה' שאנחנו גאים בה).
המלצה: אם אפשר לפרוס מחדש אתBlockly, כדאי להשאיר את ממשק המשתמש של הסידור בערימה הקיים.
3. חיבורים סימטריים
ל-Blockly יש שני סוגי חיבור: צורות החידות האופקיות והחריצים האנכיים לסידור בערימה. ממשק משתמש טוב צריך לשאוף למזעור מספר רכיבי העיצוב. בהתאם לכך, מעצבים רבים מנסים לגרום לשני סוגי החיבורים להיראות אותו הדבר (כפי שמוצג בהמשך).
כתוצאה מכך, משתמשים חדשים מחפשים דרכים לסבב של חסימות, כדי שיתאימו לחיבורים שאינם תואמים. באופן ספציפי, רכיבי התכנות הופכים לויזואליים ומוחשיים, ולכן צריך לשים לב להצעות לא מכוונות של אינטראקציות של משתמשים שאינן נתמכות.
בהתאם לכך, ב-Blockly נעשה שימוש בצורת פאזל שמתאימה היטב לחיבורי ערכים, ובאזור יישור ייחודי מבחינה חזותית לערמת הצהרות.
המלצה: אם תכינו מחדש את התוסףBlockly, ודאו שחיבורים אופקיים ואנכיים נראים אחרת.
4. שמות של משתנים ופונקציות
מתכנתים מתחילים לא מצפים ש-location_X ו-location_x הם משתנים שונים. לכן, חברתBlockly פועלת לפי העיקרון המנחה של BASIC ו-HTML על ידי הגדרת משתנים ופונקציות ככאלה שאינם תלויי-רישיות. ב-Scratch יש גישה עדינה יותר (כפי שמוצג בצד ימין), והיא תלוית אותיות רישיות בשמות של משתנים, אבל לא לבדיקת שוויון.
בנוסף, ב-Blockly אין דרישה להתאמה של משתנים ופונקציות
לסכימה הרגילה [_A-Za-z][_A-Za-z0-9]*. אם רוצים לתת שם למשתנה List of zip codes או רשימת מיקודים, זה בסדר גמור.
המלצה: אפשר להתעלם מאותיות רישיות, ולתת שמות.
5. משתנים גלובליים
גם למתכנתים מתחילים מתקשים להבין את ההיקף שלהם. כתוצאה מכך, חברתBlockly עוקבת אחר ההובלה של Scratch והופכת את כל המשתנים לגלובליים. החיסרון היחיד של משתנים גלובליים הוא שרקורסיה היא מסובכת יותר (צריך לדחוף משתנים ולהוסיף אותם לרשימה), אבל זוהי שיטת תכנות שחורגת מהיקף משתמשי היעד של blockly.
המלצה: ההיקף לא תואם להיקף. אפשר להשאיר אותו למועד מאוחר יותר.
6. הוראות
אפליקצייתBlockly Games מיועדת במיוחד להוראה עצמית, ללא צורך בתוכנית של מורים או שיעורים. כדי להשיג את המטרה הזו, בגרסה הראשונה של משחקי blockly היו הוראות בכל רמה. רוב התלמידים לא היו קוראים אותן. הפחתנו אותן למשפט אחד, הגדלנו את הגופן והדגשנו אותן בבועה צהובה. רוב התלמידים לא היו קוראים אותן. יצרנו חלונות קופצים מודאליים עם ההוראות. רוב התלמידים סגרו את החלונות הקופצים בלי לקרוא אותם, ואז אבדו.
לבסוף יצרנו חלונות קופצים שלא ניתן לסגור. הם מתוכנתים לעקוב אחרי הפעולות של התלמיד, והם סוגרים את עצמם רק אחרי שהוא מבצע את הפעולה הנדרשת. את החלונות הקופצים האלה, שמודעים להקשר, קשה לתכנת, אבל יעילים למדי. חשוב גם שהן יוצגו בשדה הראייה, בלי להפריע לסביבת העבודה.
המלצה: ההוראות צריכות להיות קצרות ועקביות, אבל לא מעוררות גועל.
7. בעלות על הקוד
תרגילים שנועדו ללמד מושג מסוים מספקים לעיתים קרובות פתרונות חלקיים שהתלמידים צריכים לשנות כדי להשיג את האפקט הרצוי. כדי לתמוך בכך, נוצרה ב-Blockly מחלקה של בלוקים שלא ניתנים לעריכה, שלא ניתנים להעברה ולא ניתנים להקצאה. אבל התלמידים שנעו לתרגילים המלאים האלה. אין להם תחושה של בעלות על הפתרון.
קשה יותר לעצב תרגילים בחופשיות שמלמדים את אותם מושגים. אחת מהשיטות שהוכחה כמוצלחת היא שימוש בפתרון של התלמיד לתרגיל אחד כנקודת ההתחלה לתרגיל הבא.
המלצה: אל תכתבו קוד עבור המשתמש.
8. הפריסה של סביבת העבודה
יש שתי דרכים סבירות לפריסת מסך משמאל לימין. דרך אחת מתחילה בסרגל הכלים בצד שמאל, בסביבת העבודה במרכז ובתצוגה החזותית של הפלט משמאל. הפריסה הזו משמשת בגרסה 1 של Scratch, וגם בגרסה Made with Code.
הדרך השנייה מתחילה בהצגה החזותית של הפלט בצד שמאל, בסרגל הכלים שבאמצע ובסביבת העבודה מימין. הפריסה הזו משמשת את גרסה 2 של Scratch, וגם את רוב אפליקציות החסימה.
בכל מקרה, סביבת העבודה צריכה להתתארך כדי לפנות לגודל המסך הזמין – המשתמשים צריכים כמה שיותר מקום לתכנות שיש להם. כפי שניתן לראות בצילומי המסך שלמעלה, הביצועים של הפריסה הראשונה נמוכים במסכים רחבים כי הקוד של המשתמש ותוצג הפלט מופרדים. הפריסה השנייה מאפשרת שטח נוסף לתוכניות גדולות יותר, תוך שמירה על כל שלושת הקטעים קרובים.
הגיוני שמשתמשים יחשבו תחילה את הבעיה שהם מנסים לפתור, אחר כך לבחון את הכלים שמוצעים ורק אחר כך להתחיל לתכנת.
כמובן שיש להפוך את כל הסדר בתרגומים לערבית ולעברית.
במקרים מסוימים, למשל כשמשתמשים במספר קטן של בלוקים פשוטים, נראה שהגיוני שארגז הכלים יופיע מעל או מתחת לסביבת העבודה. במקרים כאלה, התכונה תומכת בגלילה אופקית בארגז הכלים, אבל כדאי להשתמש בה בזהירות.
המלצה: כדאי למקם את התצוגה החזותית של התוכנית לצד סרגל הכלים.
9. יציאה מהאסטרטגיה
תכנות מבוסס-בלוק הוא בדרך כלל נקודת ההתחלה לתכנות. בהקשר של הוראת תכנות מחשבים, זוהי תרופת שער שגורמת לתלמידים להתמכר, לפני שהיא מעבירה אותם לדברים קשים יותר. הוויכוח לגבי משך הזמן שבו הסטודנטים יקיימו את התהליך הזה, שמבוסס על בלוקים, נמצאים בדיון ער
לכן, סביבות תכנות מבוססות בלוקים שמשמשות להוראת תכנות צריכות להיות עם רמפה שמתאימה לתלמידים שלהן. ב-Blockly Games יש ארבע אסטרטגיות:
- כל הטקסט בבלוקים (למשל "if", "while") מופיע באותיות קטנות כך שיתאים לשפות תכנות מבוססות טקסט.
- גרסת ה-JavaScript של קוד התלמיד/ה תמיד מוצגת אחרי כל רמה כדי להכיר טוב יותר.
- במשחק הלפני האחרון, טקסט הבלוק מוחלף ב-JavaScript בפועל (כפי שמוצג משמאל). בשלב זה התלמיד מתכנת ב-JavaScript.
- במשחק האולטימטיבי, עורך הבלוקים מוחלף בעורך טקסט.
לסביבות תכנות מבוססות בלוקים שמשמשות להוראת תכנות, צריך להכין תוכנית מסודרת לסיום הלימודים. אסטרטגיית יציאה מוצלחת גם תורמת רבות למי שטוען שתוכניות מבוססות בלוקים אינן "תכנות אמיתיות".
המלצה: כדאי להביא בחשבון את יעדי הסיום של המשתמשים ולתכנן אותם בהתאם.