Trong những năm qua, nhóm Blockly và Blockly Games đã học được nhiều bài học có thể áp dụng cho những người phát triển các ứng dụng dựa trên Blockly. Sau đây là tập hợp các lỗi mà chúng tôi đã mắc phải hoặc những lỗi mà người khác thường mắc phải.
Đây là những bài học chung mà chúng tôi đã học khi sử dụng kiểu hình ảnh của Blockly và có thể không áp dụng được cho mọi trường hợp sử dụng hoặc thiết kế. Có thể có các giải pháp khác. Đây cũng không phải là danh sách đầy đủ các vấn đề mà người dùng có thể gặp phải và cách tránh những vấn đề đó. Mỗi trường hợp đều khác nhau một chút và có thể có những ưu nhược điểm riêng.
1. Kiểu đường viền
Vào những năm 2000, giao diện "Aqua" rất phong cách và mọi đối tượng trên màn hình đều được trang trí bằng các vùng nổi bật và đổ bóng. Vào những năm 2010, giao diện "Material Design" rất phong cách và mọi đối tượng trên màn hình đều được đơn giản hoá để có hình dạng rõ ràng, phẳng, không đường viền. Hầu hết các môi trường lập trình khối đều có vùng đánh dấu và đổ bóng xung quanh mỗi khối, vì vậy, khi các nhà thiết kế đồ hoạ ngày nay nhìn thấy điều này, họ luôn loại bỏ những trang trí lỗi thời này.
Như có thể thấy trong ví dụ về 5 khối trên (từ Scriptr.io), những "trang trí lỗi thời" này rất quan trọng để phân biệt các khối liên kết có cùng màu.
Đề xuất: Nếu sử dụng lại tính năng Blockly, đừng để những phong cách thời trang hiện nay phá vỡ ứng dụng của bạn.
2. Cách lồng các ngăn xếp phụ
Các khối hình chữ "C" luôn có đầu nối ở phía trong, nhưng một số môi trường cũng có đầu nối ở phía dưới cùng (ví dụ: Hội thảo kỳ diệu), trong khi các môi trường khác thì không (ví dụ: Blockly và Scratch). Vì hầu hết các khối câu lệnh có cả trình kết nối trên cùng và dưới cùng, nên một số người dùng không thấy ngay rằng các câu lệnh sẽ nằm vừa trong chữ 'C' không có trình kết nối dưới cùng.
Khi người dùng xác định được rằng một khối câu lệnh nằm vừa trong một chữ "C", thì họ cần phải xác định thêm nhiều câu lệnh khác phù hợp. Một số môi trường lồng kết nối thấp hơn của câu lệnh đầu tiên vào phần dưới cùng của chữ "C" (ví dụ: Wonder Hội thảo và Scratch) trong khi một số môi trường khác để lại một khoảng trống nhỏ (ví dụ: Blockly). Lồng ghép vào nhau không có gợi ý về việc có thể xếp chồng nhiều khối hơn.
Hai vấn đề này tác động không tốt với nhau. Nếu có trình kết nối dưới cùng bên trong (Wonder Factory) thì việc kết nối của câu lệnh ban đầu sẽ rõ ràng hơn, nhưng sẽ mất khả năng khám phá tính năng xếp chồng. Nếu không có trình kết nối dưới cùng nào tồn tại (Blockly) thì kết nối của câu lệnh ban đầu không rõ ràng nhưng có thể phát hiện được cách xếp chồng. Không có trình kết nối dưới cùng bên trong và lồng trình kết nối dưới cùng của câu lệnh (Scratch) là vấn đề kém nhất về khả năng được phát hiện khi được kiểm thử bằng Blockly.
Kinh nghiệm của chúng tôi là kết nối của câu lệnh ban đầu ít thách thức hơn đối với người dùng so với việc khám phá việc xếp chồng. Sau khi được khám phá, dữ liệu thứ hai sẽ không bao giờ bị quên, trong khi đó, định dạng thứ hai cần được nhắc. Blockly đã thử cả hai phương pháp Hội thảo kỳ diệu và Scratch cho đến một ngày, xảy ra lỗi kết xuất và tạo ra một khoảng trống nhỏ. Nhờ lỗi này, chúng tôi nhận thấy nghiên cứu người dùng đã có sự cải thiện rõ rệt với Blockly (hiện là một "tính năng" mà chúng tôi tự hào về nó).
Đề xuất: Nếu chọn lại Chặn, hãy rời khỏi giao diện người dùng xếp chồng hiện tại.
3. Kết nối đối xứng
Blockly có 2 loại kết nối khác nhau: hình dạng khối xếp hình ngang và rãnh xếp chồng dọc. Một giao diện người dùng tốt phải cố gắng giảm thiểu số lượng phần tử thiết kế. Do đó, nhiều nhà thiết kế cố gắng làm cho cả hai loại kết nối trông giống nhau (như trình bày dưới đây).
Kết quả này sẽ khiến người dùng mới nhầm lẫn khi họ tìm cách xoay các khối để có thể vừa với các kết nối không tương thích. Công cụ này giúp các thành phần lập trình trở nên trực quan và hữu hình, vì vậy, người dùng phải vô tình đề xuất các tương tác không được hỗ trợ của người dùng.
Theo đó, Blockly sử dụng hình dạng giải đố phù hợp cho các mối liên kết giá trị và một rãnh căn chỉnh khác biệt về hình ảnh để xếp chồng các câu lệnh.
Đề xuất: Nếu bạn chọn lại một cách toàn diện, hãy đảm bảo rằng kết nối theo chiều ngang và chiều dọc trông khác nhau.
4. Tên biến và hàm
Các lập trình viên mới làm quen không mong đợi rằng location_X và location_x là các biến khác nhau. Do đó, Blockly đi theo hướng dẫn của BASIC và HTML bằng cách tạo các biến và hàm không phân biệt chữ hoa chữ thường. Scratch sử dụng một cách tiếp cận tinh tế hơn (như ở bên phải) và phân biệt chữ hoa chữ thường đối với các tên biến nhưng không phân biệt chữ hoa chữ thường để kiểm tra tính cân bằng.
Ngoài ra, Blockly không yêu cầu các biến và hàm phải tuân theo lược đồ [_A-Za-z][_A-Za-z0-9]* thông thường. Nếu ai đó muốn đặt tên cho một biến List of zip codes hoặc רשימת מיקודים thì hoàn toàn ổn.
Đề xuất: Không phân biệt chữ hoa chữ thường, cho phép mọi tên.
5. Biến toàn cục
Những lập trình viên mới làm quen cũng gặp khó khăn trong việc hiểu phạm vi. Do đó, Blockly tuân theo hướng dẫn của Scratch bằng cách biến mọi biến thành toàn cục. Nhược điểm duy nhất của biến toàn cục là đệ quy phức tạp hơn (người dùng phải đẩy và bật các biến vào danh sách), nhưng đó là một kỹ thuật lập trình nằm ngoài phạm vi người dùng mục tiêu của Blockly.
Đề xuất: Phạm vi nằm ngoài phạm vi, hãy để sau.
6. Hướng dẫn
Blockly Games được thiết kế đặc biệt dành cho hoạt động tự giảng dạy mà không cần giáo viên hay giáo án. Để thực hiện điều này, phiên bản đầu tiên của Blockly Games có hướng dẫn cho từng cấp. Hầu hết học sinh sẽ không đọc các phụ đề này. Chúng tôi đã giảm các phông chữ này xuống còn một câu duy nhất, tăng kích thước phông chữ và làm nổi bật các phông chữ đó trong một bong bóng màu vàng. Hầu hết học sinh sẽ không đọc các phụ đề này. Chúng tôi đã tạo các cửa sổ bật lên phương thức theo hướng dẫn. Hầu hết học viên theo bản năng đã đóng cửa sổ bật lên mà không đọc, rồi bị mất.
Cuối cùng, chúng ta đã tạo được các cửa sổ bật lên không đóng được. Các lớp này được lập trình để theo dõi hành động của học viên và chỉ tự đóng khi học viên đã thực hiện hành động bắt buộc. Các cửa sổ bật lên nhận biết theo ngữ cảnh này gây khó khăn khi lập trình, nhưng khá hiệu quả. Điều quan trọng là chúng phải ở trong trường nhìn mà không gây cản trở cho không gian làm việc.
Đề xuất: Hướng dẫn nên ngắn gọn và liên tục, nhưng không gây khó chịu.
7. Quyền sở hữu mã
Các bài tập được thiết kế để giảng dạy một khái niệm cụ thể thường cung cấp giải pháp từng phần mà học viên cần sửa đổi để đạt được hiệu quả mong muốn. Một lớp gồm các khối không thể chỉnh sửa, di chuyển và không thể xoá đã được tạo trong Blockly để hỗ trợ việc này. Tuy nhiên, học sinh ghét những bài tập điền vào chỗ trống này. Họ không có quyền sở hữu đối với giải pháp.
Việc thiết kế bài tập dạng tự do dạy cùng một khái niệm sẽ khó khăn hơn. Một kỹ thuật đã được chứng minh là thành công là sử dụng giải pháp của riêng học viên cho một bài tập làm điểm xuất phát cho bài tập tiếp theo.
Đề xuất: Không viết mã cho người dùng.
8. Bố cục không gian làm việc
Có 2 cách hợp lý để sắp xếp bố cục màn hình theo thứ tự từ trái sang phải. Một cách bắt đầu với thanh công cụ ở bên trái, không gian làm việc ở giữa và hình ảnh đầu ra ở bên phải. Bố cục này được sử dụng trong phiên bản 1 của Scratch, cũng như Made with Code.
Cách thứ hai bắt đầu với hình ảnh đầu ra ở bên trái, thanh công cụ ở giữa và không gian làm việc ở bên phải. Bố cục này được sử dụng bởi phiên bản 2 của Scratch, cũng như hầu hết các ứng dụng Blockly.
Trong cả hai trường hợp, không gian làm việc phải kéo dài để chiếm kích thước màn hình có sẵn – người dùng cần nhiều không gian để lập trình nhất có thể. Như có thể thấy trong ảnh chụp màn hình ở trên, bố cục đầu tiên hoạt động kém trên màn hình rộng vì mã của người dùng và hình ảnh đầu ra bị tách riêng. Trong khi đó, bố cục thứ hai vẫn có thêm không gian cho các chương trình lớn hơn mà vẫn giữ cả ba phần gần nhau.
Trước tiên, người dùng cũng nên cân nhắc vấn đề mà họ đang cố gắng giải quyết, sau đó xem xét các công cụ được cung cấp và chỉ sau đó mới bắt đầu lập trình.
Tất nhiên, toàn bộ đơn đặt hàng cần phải được lật để có các bản dịch tiếng Ả Rập và tiếng Do Thái.
Trong một số trường hợp, chẳng hạn như khi sử dụng một số ít các khối đơn giản, bạn nên đặt hộp công cụ ở phía trên hoặc phía dưới không gian làm việc. Chặn hỗ trợ thao tác cuộn ngang trong Hộp công cụ trong các trường hợp này, nhưng bạn nên thận trọng khi sử dụng.
Đề xuất: Đặt hình ảnh chương trình bên cạnh thanh công cụ.
9. Chiến lược thoát
Lập trình dựa trên khối thường là điểm khởi đầu cho việc lập trình. Trong bối cảnh dạy lập trình máy tính, đây là một loại thuốc cổng vào khiến học sinh bị nghiện, trước khi chuyển các em sang những chủ đề khó hơn. Còn nhiều tranh luận sôi nổi về thời lượng mà học viên lập trình theo khối, nhưng nếu mục tiêu của bạn là dạy lập trình thì đó chỉ nên là tạm thời.
Do đó, các môi trường lập trình dựa trên khối dùng để dạy lập trình phải có một đường dốc phù hợp với học viên. Blockly Games có 4 chiến lược:
- Tất cả văn bản trên các khối (ví dụ: "if", "when") đều là chữ thường để khớp với các ngôn ngữ lập trình dựa trên văn bản.
- Phiên bản JavaScript của mã học viên luôn hiển thị sau mỗi cấp độ để tăng mức độ quen thuộc.
- Trong trò chơi áp chót, văn bản khối được thay thế bằng JavaScript thực tế (như minh hoạ ở bên phải). Tại thời điểm này, học viên đang lập trình bằng JavaScript.
- Trong trò chơi cuối cùng, trình chỉnh sửa khối được thay thế bằng trình chỉnh sửa văn bản.
Các môi trường lập trình dựa trên khối dùng để dạy lập trình cần phải có kế hoạch cụ thể để tốt nghiệp cho học sinh. Một chiến lược thoát chắc chắn cũng rất hiệu quả trong việc ủng hộ những người cho rằng lập trình dựa trên khối không phải là "lập trình thực".
Đề xuất: Xem xét mục tiêu cuối cùng của người dùng và thiết kế sao cho phù hợp.