완료라는 말 하나가 서로 다른 일을 가리킬 수 있었다. 프로그램이 예약을 접수하는 데 성공했어도 실제 게시 시각은 아직 오지 않았을 수 있다. 북극성의 상태 문구를 읽으며 실행기가 끝났다는 사실보다 사용자가 하려던 업무가 어디까지 왔는지를 보여 주는 것이 중요하다고 생각했다.
실행 종료와 업무 완료는 다른 축이다
현재 폼의 runNames는 running·succeeded·failed·needs_review·cancelled를 표시한다. 하지만 예약 결과가 있으면 그 안의status를 읽어 계획 확인, 예약 접수·실행 대기, 모든 작업 완료 확인으로 다시 나눈다. 바깥 실행이succeeded여도 안쪽 업무가queued일 수 있기 때문이다.
이 구분이 없으면 사용자는 예약 접수만 끝난 뒤 게시가 이미 됐다고 생각할 수 있다. 실행 상태는 프로그램을 감독하는 데 필요하고 업무 상태는 고객의 목적을 이해하는 데 필요하다. 둘 중 하나를 지우는 대신 어떤 수준의 완료인지 문장에 적는다. 같은 초록색 체크라도 무엇을 확인한 것인지 알 수 있어야 다음 행동을 고를 수 있다.
미리보기에는 아직 하지 않은 행동을 적는다
예약 결과의preview는 계획 확인이며 아직 접수하지 않았다는 문구가 붙는다. 소셜 결과도 미리보기 준비·게시하지 않음과 실제 결과 확인 완료를 구분한다. 화면에 결과 카드가 생겼다고 외부 행동까지 일어난 것으로 읽히지 않게 한 것이다.
업로드도 비공개 저장과예약 공개를 다른 문장으로 남긴다. 외부 서비스의 상태를 읽어 확인한 근거가 있어야 그 문구를 쓸 수 있다. 단순한 실행 응답에 사용자의 최종 목적을 대신 적지 않는다. 카피는 보기 좋은 요약이면서 실행 경계를 표현하는 계약이다. 어느 행동을 아직 하지 않았는지 알려 주는 짧은 문장이 중복 실행과 잘못된 보고를 줄이는 데 필요했다.
확인 필요를 실패나 완료에 억지로 넣지 않는다
needs_review는 결과 확인 필요로 표시한다. 일부 단계가 끝났어도 마지막 결과가 확정되지 않은 상황을 별도로 남긴다. 같은 요청을 다시 보내면 되는 단순 실패와 다를 수 있다. 전달 여부와 외부 효과를 읽어 확인해야 다음 행동을 판단할 수 있다.
공유 문구 모듈은 전달·관찰 결과·마지막 기록을 별도 선언으로 받아 이 차이를 보여 준다. 실제 원본 결과를 검증하거나 상태를 해제하는 도구는 아니다. 모순된 성공 선언은 거절하고 문구가 재전송 권한을 만들지 않게 한다. 원래 운영의 상태가 남아 있는데 화면 문장만 낙관적으로 고치는 방법은 문제의 해결이 아니다. 사용자에게 보이는 말도 원장의 뜻을 지켜야 한다.
과거 기록은 지금의 진행에서 한 걸음 물린다
과거 실행 품질 검수는 이전 수정 실패가 현재 오류처럼 반복 표시되는 문제를 다뤘다. 완료·실패·중지는 날짜 있는 과거 기록으로 접고 현재 진행만 펼친다. 실패 내용을 지우거나 성공으로 바꾸지 않고 읽는 위치를 바꾼 것이다.
현재 설치판에서는 내장 수리 runtime이 제거됐으므로 그 과거 화면을 지금 작동하는 자동 수리로 소개하지 않는다. 재사용할 것은 현재 진행과 역사적 사건을 다른 시점의 문구로 보여 주는 원칙이다. 합성 모듈의 history 표시는 live 안내를 off로 제안하지만 실제 스크린리더 검수는 아니다. 상태의 시점을 유지해야 새 오류와 옛 기록을 혼동하지 않는다.
상태 문구에는 다음 확인이 따라온다
진행 중에는 같은 실행의 상태를 읽고, 결과 대기에는 기존 결과를 기다리며, 확인 필요에는 원래 전달을 확인하도록 안내한다. 시작할 수 있는 버튼이 다시 나타났다고 같은 입력을 다시 보내도 된다는 뜻은 아니다. UI의 가시성과 실행 권한이 서로 대신하지 않는다.
이번에는 실제 표시 코드와 과거 검수를 읽었고 새 예약이나 게시를 만들지 않았다. 독립 문구 모듈의 시험은 선언된 합성 상태의 범위다. 내가 공유하려는 카피 기준은 낙관적인 완료 문장보다 지금 확인한 사실과 다음에 읽을 근거를 연결하는 것이다. 고객은 내부 상태 이름을 외울 필요 없이 무엇이 접수됐고 무엇이 아직 남았는지를 알 수 있어야 한다. 그 설명이 정확해야 프로그램의 편의도 믿고 사용할 수 있다.