로딩 상태

데이터가 도착하기 전까지 빈 화면을 그대로 보여 주던 시절이 있었습니다. 문서 목록을 열었는데 아무것도 없으면 사용자는 문서가 없다고 읽거나 화면이 고장났다고 읽습니다. 둘 다 사실이 아닌데 구별할 표시가 없었습니다.

행동도 그대로 갈렸습니다. 없다고 읽은 사람은 새 문서를 만들고, 고장으로 읽은 사람은 새로고침을 누르거나 창을 닫습니다. 1초 뒤에 목록이 채워져도 뒷사람은 이미 떠난 뒤입니다.

오는 중인 것과 없는 것을 구별할 표시가 필요했고, 로딩 상태가 그 자리를 맡습니다.

요청을 보낸 순간 켜고 응답이 오면 끕니다. 정할 것은 넷입니다.

1. 표현을 고릅니다. 돌아가는 원을 띄우거나, 들어올 내용 자리를 회색 뼈대로 먼저 그리는 스켈레톤 UI를 쓰거나, 아무것도 띄우지 않습니다. 뼈대는 도착 후 모양을 미리 보여 주니 목록과 카드에 맞고, 돌아가는 원은 모양을 예측할 수 없는 자리에 씁니다.
2. 켜는 시점을 늦춥니다. 200밀리초 안에 응답이 오는 요청에는 표시를 띄우지 않습니다. 떴다 사라지는 깜박임이 기다림보다 산만합니다.
3. 오래 걸리면 정보를 더 줍니다. 1초를 넘기면 진행 중이라는 표시를, 10초를 넘기면 남은 양이나 몇 번째 단계인지를 보여 줍니다.
4. 다음 상태로 반드시 넘깁니다. 갈 곳은 내용이 채워진 화면, 내용이 없는 빈 상태, 실패를 알리는 오류 상태 셋입니다. 영원히 돌아가는 로딩은 대개 세 번째를 빼먹은 결과입니다.

뼈대를 쓸 때는 실제 내용과 높이를 맞춥니다. 뼈대가 낮으면 도착한 순간 화면이 아래로 밀리고, 버튼을 누르려던 사람이 다른 것을 누릅니다.

서버 응답을 기다리지 않고 성공을 가정해 먼저 반영하는 옵티미스틱 UI를 쓰면 이 상태가 필요 없어지는 자리도 있습니다. 좋아요처럼 실패 확률이 낮고 되돌리기 쉬운 동작이 그렇습니다.

"로딩이 계속 돌아요. 오류 상태로 넘어가는 처리가 없는 것 같습니다."

실패했을 때 갈 곳을 안 만들었다는 지적입니다.

"150밀리초면 표시를 띄우지 않는 게 나아요. 깜박여서 더 어지럽습니다."

켜는 시점을 늦추자는 제안입니다.

"뼈대 높이가 실제보다 낮아서 내용이 오면 화면이 튑니다."

도착 전후 높이를 맞춰야 한다는 말입니다.

페이지덱 문서 목록은 뼈대를 씁니다. 민서가 뼈대 한 줄 높이를 실제 문서 한 줄과 같게 맞췄고, 태오가 200밀리초 안에 오는 응답에는 뼈대를 띄우지 않게 구현했습니다. 검색 실패 때 뼈대가 계속 돌아가는 문제도 있었고, 오류 상태로 넘기는 처리를 넣어 해결했습니다.