지난 몇 년 동안 Blockly 및 Blockly Games팀은 Blockly 기반 애플리케이션을 개발하는 개발자에게 적용할 수 있는 많은 교훈을 얻었습니다. 다음은 Google에서 범한 실수 또는 다른 사람이 흔히 저지르는 실수입니다.
이는 Blockly의 시각적 스타일을 사용하여 배운 일반적인 교훈이며 일부 사용 사례나 디자인에는 적용되지 않을 수도 있습니다. 다른 솔루션이 있을 수도 있습니다. 또한 사용자에게 발생할 수 있는 문제와 이를 방지하는 방법이 전부는 아닙니다. 모든 사례는 조금씩 다르며 고유한 장단점이 있을 수 있습니다.
1. 테두리 스타일
2000년대에는 '아쿠아' 스타일이 스타일리시했고 화면상의 모든 객체가 하이라이트와 그림자로 장식되었습니다. 2010년대에는 'Material Design'이 스타일리시하고 화면의 모든 객체가 깔끔하고 평평하며 테두리 없는 모양으로 간소화되었습니다. 대부분의 블록 프로그래밍 환경은 각 블록 주위에 강조표시와 그림자가 있습니다. 따라서 오늘날의 그래픽 디자이너는 이러한 블록을 볼 때 오래된 장식을 항상 제거합니다.
(scriptr.io에 있는) 위의 다섯 블록 예에서 볼 수 있듯이, 이러한 '오래된 장식'은 색상이 같은 연결된 블록을 구별하는 데 매우 중요합니다.
권장사항: Blockly로 리스킨을 한다면 오늘날의 패션으로 인해 앱이 중단되지 않도록 하세요.
2. 하위 스택 중첩
'C'자형 블록은 안쪽 상단에 항상 커넥터가 있지만, 일부 환경의 경우 하단부에 커넥터가 있는 반면 (예: Wonder Workshop)는 커넥터가 없는 반면 (예: Blockly, Scratch)에는 커넥터가 없습니다. 대부분의 명령문 블록에는 상단 및 하단 커넥터가 모두 있으므로 일부 사용자는 문이 하단 커넥터가 없는 'C' 안에 들어가는 것을 즉시 알 수 없습니다.
사용자는 하나의 명령문 블록이 'C'에 적당하다는 것을 알게 되면 두 명령문도 추가로 적합하다는 점을 알아내야 합니다. 일부 환경에서는 첫 번째 구문의 하위 연결을 'C' 하단에 중첩하지만(예: Wonder Workshop 및 Scratch) 환경에서는 작은 격차를 남겨둡니다(예: Blockly). 적절한 중첩은 더 많은 블록을 쌓을 수 있다는 힌트를 남기지 않습니다.
이 두 문제는 서로 관련이 없는 방식으로 상호작용합니다. 내부 하단 커넥터가 있는 경우 (Wonder Workshop) 경우 초기 구문의 연결은 더 명확해지지만 스태킹을 발견할 수는 없습니다. 내부 하단 커넥터가 없는 경우 (Blockly) 초기 문의 연결은 명확하지 않지만 스택을 검색할 수 있습니다. 내부 하단 커넥터가 없고 구문의 하단 커넥터 (Scratch)를 중첩하면 Blockly로 테스트할 때 검색 가능성이 가장 떨어졌습니다.
경험에 의하면 초기 문의 연결은 스택을 발견하는 것보다 사용자에게 덜 어려운 것으로 나타났습니다. 전자는 일단 발견되고 나면 결코 잊히지 않는 반면, 후자는 프롬프트가 필요합니다. 블록리는 원더 워크샵과 스크래치 접근 방식을 모두 시도하여 어느 날 렌더링 버그가 발생하여 약간의 차이로 인해 오류가 발생했습니다. 이 버그로 인해 Blockly의 사용자 연구가 크게 개선되었습니다.
권장사항: Blockly로 리스키닝하는 경우 기존 스태킹 UI를 그대로 두세요.
3. 대칭 연결
Blockly에는 가로 퍼즐 모양과 세로 스태킹 노치라는 두 가지 연결 유형이 있습니다. 우수한 사용자 인터페이스는 디자인 요소의 수를 최소화해야 합니다. 따라서 많은 디자이너는 두 연결 유형을 동일하게 보이게 하려고 합니다 (아래 참고).
그 결과, 신규 사용자가 호환되지 않는 연결에 들어갈 수 있도록 블록을 회전하는 방법을 검색할 때 혼란을 야기합니다. 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는 모든 변수를 전역으로 만들어 스크래치의 선도적인 방법을 따릅니다. 전역 변수의 유일한 단점은 재귀가 까다롭다는 것(변수를 목록에 푸시하고 팝해야 함)이지만, 이는 Blockly의 대상 사용자의 범위를 벗어나는 프로그래밍 기법입니다.
권장사항: 범위가 범위를 벗어납니다. 나중을 위해 남겨 두세요.
6. 안내
Blockly Games는 특히 교사나 수업 계획이 필요하지 않은 자기 주도형으로 설계되었습니다. 이를 위해 첫 번째 버전의 Blockly Games에는 각 레벨에 관한 안내가 있었습니다. 대부분의 학생은 읽지 않을 것입니다. 글자를 한 문장으로 줄이고 글꼴 크기를 늘린 후 노란색 풍선으로 강조 표시했습니다. 대부분의 학생은 읽지 않을 것입니다. 안내에 따라 모달 팝업을 만들었습니다. 대부분의 학생은 본능적으로 팝업을 읽지 않고 닫았다가 닫혔습니다.
마지막으로 닫을 수 없는 팝업을 만들었습니다. 학생의 행동을 모니터링하고 학생이 필요한 행동을 한 경우에만 스스로를 종료하도록 프로그래밍되어 있습니다. 이러한 맥락 인식 팝업은 프로그래밍하기에는 어렵지만 상당히 효과적입니다. 또한 작업공간을 방해하지 않고 시야에 위치하는 것이 중요했습니다.
권장사항: 안내는 짧고 지속적이어야 하지만 불쾌하지 않아야 합니다.
7. 코드 소유권
특정 개념을 가르치기 위해 고안된 연습에서는 학생이 원하는 효과를 얻기 위해 수정해야 하는 부분적인 해답을 제공하는 경우가 많습니다. 이를 지원하기 위해 수정 불가능하고 이동할 수 없으며 삭제할 수 없는 블록 클래스가 Blockly에 생성되었습니다. 하지만 학생들은 이 빈칸 채우기를 싫어했습니다. 솔루션에 대한 주인 의식이 없습니다.
같은 개념을 가르치는 자유 형식의 연습을 설계하는 것은 더 어렵습니다. 성공이 입증된 한 가지 기법은 한 연습에 학생 자체 솔루션을 다음 연습의 시작점으로 사용하는 것입니다.
권장사항: 사용자를 위해 코드를 작성하지 마세요.
8. 작업공간 레이아웃
화면의 레이아웃을 왼쪽에서 오른쪽으로 쓰는 합당한 두 가지 방법이 있습니다. 한 가지 방법은 왼쪽에 있는 툴바, 가운데에 작업공간, 오른쪽에 있는 출력 시각화로 시작하는 것입니다. 이 레이아웃은 Scratch 버전 1과 Made with Code 버전 1에서 사용됩니다.
다른 방법으로는 왼쪽이 출력 시각화, 가운데에 툴바, 오른쪽이 작업공간으로 시작합니다. 이 레이아웃은 Scratch 버전 2와 대부분의 Blockly 애플리케이션에서 사용합니다.
두 경우 모두 사용 가능한 화면 크기를 차지하도록 작업공간을 늘려야 합니다. 사용자는 최대한 많은 공간을 프로그래밍할 수 있어야 합니다. 위 스크린샷에서 볼 수 있듯이 첫 번째 레이아웃은 사용자의 코드와 출력 시각화가 분리되어 있으므로 넓은 화면에서는 성능이 저하됩니다. 반면에 두 번째 레이아웃은 세 섹션을 모두 서로 가깝게 유지하면서 더 큰 프로그램을 위한 추가 공간을 허용합니다.
또한 사용자가 해결하려는 문제를 먼저 고려한 다음 제공되는 도구를 살펴보고 프로그래밍을 시작하는 것이 논리적입니다.
물론 아랍어와 히브리어 번역의 경우 전체 순서를 뒤집어야 합니다.
일부 경우에는(예: 소수의 간단한 블록을 사용하는 경우) 도구 상자가 작업공간 위 또는 아래에 있는 것이 적합할 수 있습니다. 이러한 경우에 Blockly는 도구 상자에서 가로 스크롤을 지원하지만 주의해서 사용해야 합니다.
권장사항: 툴바 옆에 프로그램 시각화를 배치하세요.
9. 종료 전략
블록 기반 프로그래밍은 종종 프로그래밍의 시작점입니다. 컴퓨터 프로그래밍을 가르치는 맥락에서 볼 때 그것은 학생들을 중독되기 전에 더 어려운 도전으로 넘기게 하는 관문 약물입니다. 이러한 블록 기반 프로그래밍 기간이 학생들을 위해 지속되어야 하는 기간에 대해서는 뜨거운 논쟁이 벌어지지만, 프로그래밍을 가르치는 것이 목표라면 일시적이어야 합니다.
따라서 프로그래밍 교육에 사용되는 블록 기반 프로그래밍 환경은 학생들에게 적합한 진입로가 있어야 합니다. Blockly Games에는 4가지 전략이 있습니다.
- 블록의 모든 텍스트 (예: 'if', 'when')는 텍스트 기반 프로그래밍 언어와 일치하도록 소문자입니다.
- 더 쉽게 이해할 수 있도록 각 수준 다음에 학생 코드의 JavaScript 버전이 항상 표시됩니다.
- 두 번째 게임에서는 블록 텍스트가 실제 자바스크립트로 대체됩니다(오른쪽 참고). 이 시점에서 학생은 자바스크립트로 프로그래밍하고 있습니다.
- 최종 게임에서 블록 편집기는 텍스트 편집기로 대체됩니다.
프로그래밍 교육에 사용되는 블록 기반 프로그래밍 환경에는 학생의 졸업을 위한 구체적인 계획이 있어야 합니다. 또한 효과적인 종료 전략은 블록 기반 프로그래밍이 '실제 프로그래밍'이 아니라고 주장하는 사람들을 불러오는 데도 도움이 됩니다.
권장사항: 사용자의 최종 목표와 디자인을 적절하게 고려하세요.