บล็อกที่กำหนดเอง: คู่มือแนะนำรูปแบบ

ตลอดหลายปีที่ผ่านมา ทีม Blockly และ Blockly Games ได้เรียนรู้บทเรียนมากมายซึ่งเกี่ยวข้องกับเด็กที่กำลังพัฒนาบล็อกใหม่ๆ ต่อไปนี้คือคอลเล็กชันข้อผิดพลาดที่เราทำหรือข้อผิดพลาดที่ผู้อื่นมักทำ

นี่คือบทเรียนทั่วไปที่เราได้เรียนรู้โดยใช้สไตล์ภาพของ Blockly และ อาจใช้ไม่ได้กับกรณีการใช้งานหรือการออกแบบทั้งหมด มีวิธีแก้ปัญหาอื่นๆ ที่กล่าวมานี้ไม่ใช่รายการปัญหาทั้งหมดที่ผู้ใช้อาจพบและวิธีหลีกเลี่ยง แต่ละกรณีมีความแตกต่างกันเล็กน้อยและมีข้อเสียของตัวเอง

1. เงื่อนไขและลูป

การบล็อกที่ยากที่สุดสำหรับผู้ใช้ใหม่คือเงื่อนไขและการวนซ้ำ สภาพแวดล้อมแบบบล็อกหลายรายการจะจัดกลุ่มบล็อกทั้งสองเข้าไว้ในหมวดหมู่ "การควบคุม" เดียวกัน โดยทั้ง 2 บล็อกมีรูปร่างเหมือนกันและมีสีเดียวกัน ปัญหานี้มักทำให้เกิดความหงุดหงิดเนื่องจากผู้ใช้ใหม่สับสนระหว่าง 2 บล็อกนี้ Blockly ขอแนะนำให้ย้ายเงื่อนไขและลูปไปยังหมวดหมู่ "Logic" และ "Loops" แยกกัน โดยแต่ละรูปแบบมีสีต่างกัน วิธีนี้แสดงให้เห็นอย่างชัดเจนว่าแนวคิดเหล่านี้คือแนวคิดเฉพาะที่มีพฤติกรรมต่างกัน แม้จะมีรูปร่างคล้ายกัน

คำแนะนำ: แยกเงื่อนไขและลูปออกจากกัน

2. รายการแบบอิงรายการ

นักเขียนโปรแกรมมือใหม่รู้สึกแย่เมื่อต้องเจอรายการแบบศูนย์เป็นครั้งแรก ผลที่ได้คือ Blockly ติดตามหัวหน้าของ Lua และ Lambda Moo ด้วยการกำหนดรายการและการจัดทำดัชนีสตริงแบบพื้นฐาน

สำหรับการใช้งาน Blockly ขั้นสูง ระบบจะรองรับรายการแบบเลขศูนย์เพื่อให้การเปลี่ยนเป็นข้อความง่ายขึ้น ส่วนกลุ่มเป้าหมายที่อายุน้อยขึ้นไปกลุ่มเป้าหมายมือใหม่ยังคงแนะนำให้ ทำดัชนีแบบอิงตามเดียว

คำแนะนำ: หมายเลขโทรศัพท์แรกคือหมายเลขแรก

3. ข้อมูลจากผู้ใช้

การรับพารามิเตอร์จากผู้ใช้มี 3 วิธี เมนูแบบเลื่อนลงจะมีข้อจำกัดมากที่สุดและเหมาะสำหรับบทแนะนำและแบบฝึกหัดง่ายๆ ช่องป้อนข้อมูลช่วยให้มีอิสระมากขึ้นและเหมาะสำหรับกิจกรรมที่สร้างสรรค์มากขึ้น อินพุตบล็อกค่า (โดยปกติจะเป็นบล็อกเงา) ให้โอกาสในการคํานวณค่า (เช่น โปรแกรมสร้างแบบสุ่ม) แทนที่จะเป็นค่าคงที่เพียงอย่างเดียว

คำแนะนำ: เลือกวิธีการป้อนข้อมูลที่เหมาะสมสำหรับผู้ใช้

4. รูปภาพบล็อกสด

เอกสารประกอบเกี่ยวกับการบล็อกควรมีรูปภาพของการบล็อกที่อ้างถึง การถ่ายภาพหน้าจอเป็นเรื่องง่าย แต่หากมีรูปภาพดังกล่าว 50 รูป และแอปพลิเคชันได้รับการแปลเป็น 50 ภาษา ทันใดนั้น แอปหนึ่งก็เก็บภาพนิ่งไว้ 2,500 ภาพ จากนั้นรูปแบบสีก็จะเปลี่ยนไป และต้องอัปเดตรูปภาพ 2,500 รูปอีกครั้ง

เพื่อคลายเครียดจากฝันร้ายเกี่ยวกับการบำรุงรักษานี้ Blockly Games ได้แทนที่ภาพหน้าจอทั้งหมดด้วยอินสแตนซ์ของ Blockly ที่ทำงานในโหมดอ่านอย่างเดียว ผลการค้นหาจะดูเหมือนกับรูปภาพ แต่รับประกันว่าเป็นข้อมูลล่าสุด โหมดอ่านอย่างเดียวทำให้การปรับให้เป็นสากลเป็นไปได้

คําแนะนํา: หากคุณรองรับมากกว่า 1 ภาษา ให้ใช้โหมดอ่านอย่างเดียว

5. ด้านซ้ายอีกใบของคุณ

ความคิดเห็นจากเด็กๆ ในสหรัฐอเมริกา (แม้จะน่าสนใจว่ามาจากประเทศอื่นๆ ก็ตาม) เผยให้เห็นถึงความสับสนที่เกิดขึ้นอย่างมากระหว่างด้านซ้ายและด้านขวา ปัญหานี้แก้ไขได้ด้วย การเพิ่มลูกศร หากทิศทางสัมพัทธ์ (เช่น รูปโปรไฟล์) รูปแบบของลูกศรจะมีความสำคัญ เครื่องหมาย → ลูกศรตรงหรือ ↱ ลูกศรเลี้ยว จะทําให้สับสนเมื่อรูปโปรไฟล์หันไปในทิศทางตรงกันข้าม มีประโยชน์ที่สุดคือลูกศรวงกลม ⟳ นั้น แม้ในกรณีที่มุมที่หมุนน้อยกว่าลูกศรบอกไว้

คําแนะนํา: เพิ่มข้อความด้วยไอคอน Unicode หากเป็นไปได้

6. บล็อกระดับสูง

หากเป็นไปได้ คุณควรใช้แนวทางระดับสูง แม้ว่าจะลดประสิทธิภาพหรือความยืดหยุ่นในการดำเนินการก็ตาม พิจารณานิพจน์สคริปต์ Apps นี้:

SpreadsheetApp.getActiveSheet().getDataRange().getValues()

ในการแมปแบบ 1:1 ซึ่งคงความสามารถที่เป็นไปได้ทั้งหมดไว้ นิพจน์ข้างต้นจะสร้างขึ้นโดยใช้บล็อก 4 ชิ้น แต่ Blockly มีเป้าหมายที่ระดับที่สูงกว่า และมีบล็อก 1 รายการที่สรุปนิพจน์ทั้งหมด เป้าหมายคือการเพิ่มประสิทธิภาพสำหรับเคส 95% แม้ว่าจะทำให้กรณี 5% ที่เหลือยากขึ้นก็ตาม Blockly ไม่ได้มีจุดประสงค์เพื่อทดแทนภาษาต่างๆ ที่ใช้ข้อความเป็นหลัก แต่มีไว้เพื่อช่วยให้ผู้ใช้เข้าใจบทเรียนเริ่มต้น เพื่อให้สามารถใช้ภาษาแบบข้อความได้

คำแนะนำ: อย่าแปลง API ทั้งหมดเป็นการบล็อกไปเรื่อยๆ

7. ค่าส่งคืน (ไม่บังคับ)

ฟังก์ชันจำนวนมากในการเขียนโปรแกรมแบบข้อความจะดำเนินการ แล้วแสดงผลค่า ผลลัพธ์นี้อาจนำไปใช้หรือไม่ก็ได้ ตัวอย่างคือฟังก์ชัน pop() ของสแต็ก อาจมีการเรียก Pop ให้เรียกและนำองค์ประกอบสุดท้ายออก หรืออาจเรียกเพื่อนำองค์ประกอบสุดท้ายออกโดยไม่สนใจค่าผลลัพธ์

var last = stack.pop();  // Get and remove last element.
stack.pop();  // Just remove last element.

โดยทั่วไปภาษาแบบบล็อกมักไม่สนใจค่าที่ส่งกลับ บล็อกค่าต้องเสียบเข้ากับสิ่งที่ยอมรับค่า มีกลยุทธ์หลายอย่างในการจัดการกับปัญหานี้

ก) แก้ไขปัญหาที่เกิดขึ้น ภาษาแบบบล็อกส่วนใหญ่จะออกแบบภาษา เพื่อหลีกเลี่ยงกรณีเช่นนี้ เช่น Scratch ไม่มีการบล็อกที่มีทั้งผลข้างเคียงและค่าที่แสดงผล

b) ระบุ 2 บล็อก หากพื้นที่ในกล่องเครื่องมือไม่ใช่ปัญหา วิธีแก้ไขง่ายๆ คือการระบุบล็อกประเภทนี้ 2 บล็อกโดยให้ 1 บล็อกไม่มีข้อมูลผลลัพธ์ ข้อเสียก็คือ การทำเช่นนี้อาจทำให้กล่องเครื่องมือสับสน ซึ่งมีบล็อกที่เหมือนกันจำนวนมาก

ค) เปลี่ยนแปลง 1 บล็อก ใช้เมนูแบบเลื่อนลง ช่องทำเครื่องหมาย หรือการควบคุมอื่นๆ ที่ผู้ใช้สามารถเลือกได้ว่าจะมีค่าที่ส่งกลับหรือไม่ จากนั้นบล็อกจะเปลี่ยนรูปร่างโดยขึ้นอยู่กับตัวเลือก ดูตัวอย่างได้ในบล็อกการเข้าถึงรายการของ Blockly

d) กินคุณค่า App Inventor เวอร์ชันแรกได้สร้างบล็อกไปป์พิเศษซึ่งกินค่าที่เชื่อมต่อทั้งหมด ผู้ใช้ไม่เข้าใจแนวคิดนี้ และ App Inventor เวอร์ชันที่ 2 ได้นำบล็อกไปป์ออก และแนะนำให้ผู้ใช้กำหนดค่าให้กับตัวแปรแบบทิ้งช่วงแทน

คำแนะนำ: แต่ละกลยุทธ์มีทั้งข้อดีและข้อเสีย ให้เลือกสิ่งที่เหมาะกับผู้ใช้

8. บล็อกขนาดใหญ่

การบล็อกบางรายการอาจต้องใช้จำนวนอินพุตที่เปลี่ยนแปลงได้ ตัวอย่างเช่น บล็อกเพิ่มเติมที่รวมชุดตัวเลขที่กำหนดเอง หรือบล็อก if/elseif/else กับชุดคำสั่ง elseif แบบกำหนดเอง หรือตัวสร้างรายการที่มีจำนวนองค์ประกอบเริ่มต้นตามต้องการ กลยุทธ์มีอยู่มากมาย แต่แต่ละแบบก็มีข้อดีและข้อเสีย

ก) วิธีที่ง่ายที่สุดคือให้ผู้ใช้เขียนบล็อกจากบล็อกเล็กๆ ตัวอย่างเช่น การเพิ่มตัวเลข 3 ตัวโดยการฝังบล็อกการเพิ่ม 2 ตัวซ้อนกัน 2 ตัว อีกตัวอย่างหนึ่งคือการระบุเฉพาะ if/else บล็อก และกำหนดให้ผู้ใช้ซ้อนกันเพื่อสร้างเงื่อนไข elseif

ข้อดีของวิธีการนี้คือความเรียบง่ายในระยะแรก (ทั้งสำหรับผู้ใช้และนักพัฒนาแอป) ข้อเสียคือในกรณีที่มีการซ้อนจำนวนมาก โค้ดอาจสร้างความยุ่งยากและทำให้ผู้ใช้อ่านและดูแลรักษาได้ยาก

ข) อีกวิธีหนึ่งคือการขยายบล็อกแบบไดนามิกเพื่อให้มีอินพุตว่าง 1 รายการในตอนท้ายเสมอ ในทํานองเดียวกัน บล็อกจะลบอินพุตสุดท้ายหากมีอินพุตว่าง 2 รายการในตอนท้าย ซึ่งเป็นแนวทางที่ App Inventor เวอร์ชันแรกใช้

การบล็อกที่เพิ่มขึ้นโดยอัตโนมัติเป็นผู้ใช้ที่ไม่ชอบแอป App Inventor เนื่องจากเหตุผล 2 ประการ อย่างแรกคือมีการป้อนข้อมูลฟรีเสมอและโปรแกรมไม่เคย "เสร็จสมบูรณ์" อย่างที่ 2 การแทรกองค์ประกอบที่อยู่ตรงกลางกลุ่มจะไม่ค่อยน่าพอใจ เนื่องจากเกี่ยวข้องกับการยกเลิกการเชื่อมต่อองค์ประกอบทั้งหมดที่อยู่ใต้การแก้ไขและเชื่อมต่อองค์ประกอบเหล่านั้นอีกครั้ง หากการสั่งซื้อนั้นไม่ใช่เรื่องสำคัญและผู้ใช้จะรู้สึกสบายใจกับช่องโหว่ในโปรแกรมของตน ตัวเลือกนี้ก็เป็นทางเลือกที่สะดวกมาก

ค) นักพัฒนาซอฟต์แวร์บางรายเพิ่มปุ่ม +/- ลงในบล็อกที่เพิ่มหรือนําอินพุตออกด้วยตนเองเพื่อแก้ปัญหาหลุม Open Roberta ใช้ปุ่ม 2 ปุ่มดังกล่าวเพื่อเพิ่มหรือนำอินพุตออกจากด้านล่าง ส่วนนักพัฒนาซอฟต์แวร์รายอื่นๆ จะเพิ่มปุ่ม 2 ปุ่มในแต่ละแถวเพื่อให้แทรกและลบออกจากกลางกลุ่มได้ ส่วนปุ่มอื่นๆ จะเพิ่มปุ่มขึ้น/ลง 2 ปุ่มในแต่ละแถวเพื่อให้เรียงลำดับกองซ้อนได้ง่ายขึ้น

กลยุทธ์นี้เป็นตัวเลือกต่างๆ ที่มีตั้งแต่ 2 ปุ่มต่อบล็อก ไปจนถึง 4 ปุ่มต่อแถว ที่ปลายทางด้านหนึ่งคืออันตรายที่ผู้ใช้ไม่สามารถดำเนินการที่ต้องการ แต่อีกฝั่งหนึ่ง UI จะเต็มไปด้วยปุ่มมากมายจนดูเหมือนเป็นสะพานเชื่อม Enterprise ของบริษัท

ง) วิธีที่ยืดหยุ่นที่สุดคือการเพิ่มลูกโป่งการเปลี่ยนแปลงลงในบล็อก คอลัมน์นี้จะแสดงเป็นปุ่มเดียวที่เปิดกล่องโต้ตอบการกำหนดค่าสำหรับบล็อกนั้น คุณสามารถเพิ่ม ลบ หรือจัดเรียงองค์ประกอบใหม่ได้ตามต้องการ

ข้อเสียของวิธีการนี้คือการเปลี่ยนกลยุทธ์ไม่เหมาะสำหรับผู้ใช้มือใหม่ การแนะนำการเปลี่ยนรูปแบบต้องใช้วิธีการบางอย่าง แอปพลิเคชันแบบบล็อกซึ่งกำหนดเป้าหมายเป็นเด็กเล็กไม่ควรใช้เครื่องมือเปลี่ยนรูปแบบ แม้ว่าจะได้เรียนรู้แล้ว แต่ก็มีคุณค่าอย่างยิ่งสำหรับผู้ใช้ขั้นสูง

คำแนะนำ: แต่ละกลยุทธ์มีทั้งข้อดีและข้อเสีย ให้เลือกสิ่งที่เหมาะกับผู้ใช้

9. การสร้างโค้ดที่สะอาดตา

ผู้ใช้ขั้นสูงใน Blockly ควรดูโค้ดที่สร้างขึ้นได้ (JavaScript, Python, PHP, Lua, Dart เป็นต้น) และจดจำโปรแกรมที่เขียนขึ้นได้ทันที ซึ่งหมายความว่าคุณต้องออกแรงเพิ่มเพื่อให้โค้ดที่คอมพิวเตอร์สร้างขึ้นนี้อ่านได้ วงเล็บ ตัวแปรตัวเลข ช่องว่างที่อัดแน่น และเทมเพลตโค้ดแบบละเอียดทั้งหมดขัดขวางการสร้างโค้ดที่สวยงาม โค้ดที่สร้างขึ้นควรมีความคิดเห็นและต้องสอดคล้องกับคู่มือสไตล์การเขียนของ Google

คำแนะนำ: ภูมิใจกับโค้ดที่คุณสร้างขึ้น แสดงต่อผู้ใช้

10. การใช้ภาษา

ผลข้างเคียงของความต้องการใช้โค้ดที่เรียบง่ายคือ พฤติกรรมของ Blockly นั้นกำหนดอย่างชัดเจนในแง่ของลักษณะการทำงานของภาษาที่คอมไพล์แบบข้ามระบบ ภาษาเอาต์พุตที่พบบ่อยที่สุดคือ JavaScript แต่หาก Blockly ทำการคอมไพล์ข้ามภาษาไปยังภาษาอื่น ก็ไม่ควรพยายามรักษาลักษณะการทำงานเดิมของทั้ง 2 ภาษาไว้ เช่น ใน JavaScript สตริงว่างคือ false (เท็จ) ขณะที่ใน Lua สตริงนั้นเป็นจริง การกำหนดลักษณะพฤติกรรมรูปแบบเดียวเพื่อให้โค้ดของ Blockly ดำเนินการไม่ว่าภาษาเป้าหมายจะเป็นผลให้เกิดโค้ดที่ดูแลไม่ได้ซึ่งดูเหมือนว่าออกมาจากคอมไพเลอร์ GWT

คำแนะนำ: Blockly ไม่ใช่ภาษาใด แต่อนุญาตให้ภาษาที่มีอยู่มีผลต่อพฤติกรรม