Dock에 파일 열기나 Markdown 편집 기능을 바로 붙일 수도 있었다. 하지만 그 전에 사용자가 어떤 흐름으로 문서를 찾고, 쓰고, 미리보고, 명령을 실행하는지를 담을 화면 구조가 필요했다. 그래서 M1에서는 권한을 추가하지 않고 Application Shell부터 만들었다.
이번 단계에서 만든 화면
화면은 다섯 영역으로 나뉜다.
상단: Dock 이름과 명령 팔레트 진입점
왼쪽: document workspace와 문서 목록 자리
가운데: Markdown editor 자리
오른쪽 또는 아래: preview 자리
하단: 현재 문서 상태아직 document workspace를 실제로 선택하지는 않는다. 폴더 선택 버튼과 문서 목록은 다음 단계의 파일 권한 기능이 들어갈 자리다. 이 단계에서 버튼에 파일 시스템 권한을 미리 연결하지 않은 이유는, 화면 작업과 권한 작업을 한 번에 섞지 않기 위해서다.
빈 화면도 제품 경험이다
초기 앱에서 가장 먼저 보는 상태는 문서가 없는 상태다. 단순히 빈 공간만 보이면 사용자는 다음 행동을 알기 어렵다.
그래서 기본 화면에는 다음 안내를 넣었다.
- 문서 폴더를 선택하면 Markdown 파일이 표시된다는 설명
- 문서를 열면 preview가 나타난다는 설명
- 로컬 파일 기능은 다음 단계에서 연결된다는 상태 표시
문서 목록을 불러오는 중인 상태와 오류 상태도 별도 메시지로 만들었다. 실제 파일 읽기는 아직 없지만, 다음 단계에서 같은 자리에 상태를 연결할 수 있다.
작은 창도 별도 화면으로 취급했다
넓은 창에서는 sidebar·editor·preview를 나란히 보이게 한다. 폭이 줄어들면 preview를 다음 행으로 내리고, 더 좁아지면 모든 영역을 한 열로 쌓는다.
이 선택은 정보를 숨기기보다 흐름을 유지하기 위한 것이다. 작은 창에서 editor가 너무 좁아지거나 영역이 겹치면 문서를 쓰는 앱으로 사용할 수 없기 때문이다.
키보드 흐름을 같이 테스트했다
개발자용 문서 도구는 마우스만으로 쓰는 앱이 아니다. 그래서 화면이 보이는지뿐 아니라 Tab 키의 이동 순서도 component test에 넣었다.
명령 팔레트 열기
→ 폴더 선택
→ Markdown 편집기또한 main landmark, 문서 sidebar, editor region, preview region의 accessible name과 empty/loading/error 상태를 테스트했다. CSS class나 DOM 깊이가 아니라 사용자와 보조 기술이 인식하는 구조를 기준으로 삼았다.
확인한 결과
Windows x64에서 다음 자동 검증을 통과했다.
npm run check
npm run package
npm run test:e2e
npm run test:smoke개발용 Electron 창에서는 800px 폭과 480px 폭으로 레이아웃을 확인했다. 이후 production package도 직접 열어 화면 표시, 작은 창 레이아웃, Tab focus 순서가 정상임을 수동 확인했다.
다음 단계
다음 M2에서는 실제 document workspace를 선택하고 Markdown 파일 목록·열기·편집·저장을 연결한다. 이때는 파일 시스템 권한이 생기므로, 코드보다 먼저 document workspace authority와 IPC contract를 ADR로 확정할 예정이다.
