"영영 안 끝나는 스피너는 애니메이션 붙은 거짓말이야. 진짜 상태를 보여줘. 그 진짜 상태가 '기다리는 중' 일 때도."
UI 가 시스템보다 더 자신만만하면 안 돼
정직한 오프라인은 데이터 규칙만이 아냐. UI 규칙이기도 해. 인터페이스가 시스템이 실제로 아는 것보다 더 확신에 찬 소리를 하면 안 돼. 오프라인이라 턴이 pending 이면 화면도 기다리는 중 이라고 말해야 해. 일이 돌아가는 척하는 스피너도, 다 끝난 척하는 체크마크도 안 되고. 트랙 2 에서 본 내부 상태 넷은 코드만 보라고 있는 게 아냐. 넷 다 사용자가 한눈에 읽을 수 있는 뚜렷하고 참된 얼굴을 하나씩 가져야 해.
네 상태, 네 정직한 얼굴
- Pending. 캡처는 됐고 아직 안 보냈어. 대개 오프라인일 때고. 그럼 그렇게 말하면 돼. '저장됨. Pippa 한테 닿기를 기다리는 중.' 차분하고 안전한 상태니까 UI 도 호들갑 떨지 말고 차분해야 해.
- Sending. 지금 한창 배달 중이야. 스피너가 여기선 정직해. 진짜로 뭔가 돌아가고 있으니까.
- Answered. canonical 호출에서 진짜 답이 나왔어. 이제야 답이 화면에 뜨고.
- Failed. 배달을 시도했는데 에러가 났어. 다시 보내기 버튼이랑 같이 있는 그대로 보여줘. 턴은 안전하고 다시 보낼 수 있으니까 UI 도 딱 그만큼만 말하면 돼. 호들갑 떨지 말고.
규칙은 일대일이야. 진짜 시스템 상태에 대응 안 되는 UI 상태가 있으면 안 되고, 눈에 안 보이는 시스템 상태도 있으면 안 돼. 이 둘이 맞아떨어지면 사용자 신뢰가 계속 쌓여. 보이는 게 늘 참이니까.
왜 '보이는' 이 '낙관적' 을 이기나
낙관적 UI, 그러니까 확인도 받기 전에 성공을 먼저 보여주는 방식은 빨라 보여서 인기가 많아. 근데 조건 나쁠 때의 신뢰가 존재 이유 전부인 클라이언트한테 낙관은 복리로 불어나는 작은 거짓말이야. 배달도 되기 전에 메시지를 '보냄' 으로 표시해 버리면, 링크가 불안할 때 사용자는 뭐가 실제로 나갔는지를 틀리게 기억하게 돼. Pippa Go 는 낙관적인 쪽 말고 보이는 쪽을 골라. 늘 참인 좀 심심한 pending 배지가, 가끔 거짓말하는 흐뭇한 체크마크를 이겨. 그 배지가 화면에 찍힌 약속이야.