100에서 멈추던 목록

목록 관련 테스트 케이스에 숫자가 둘 나왔다. 20개씩 불러오는데 100개에서 멈춘다.

Open Table of contents

상황 — 두 숫자가 나온 케이스

케이스는 이렇게 적혀 있다.

최초 20개 노출 및 스크롤 시, 20개씩 페이징
카테고리 당 최대 100개가 노출되는지 확인

두 숫자가 서로 다른 것을 정한다.

20    한 번에 가져오는 양
100   전체 상한

20개씩 페이징 은 한 번에 얼마나 가져오느냐이고 최대 100개 는 어디까지 보여 주느냐다.

앞은 요청 하나의 무게에 관한 값이고 뒤는 정책에 가까워서 20 을 다섯 번 채우면 그 지점에서 목록이 끝난다.

무한히 이어 붙일 수도 있는데 왜 자르는지를 짚어 봤다.

1~20     대부분 봄
81~100   거의 안 봄
101~     사실상 안 봄

81~100 으로 갈수록 보는 사람은 줄어드는데 가져오는 값은 줄지 않는다.

깊은 쪽이 더 비싸기도 한데 정렬해서 뒤쪽을 꺼내려면 OFFSET 앞을 다 훑어야 하므로 페이지가 깊어질수록 한 번의 조회가 무거워진다.

[상한 없음]  얼마나 깊이 갈지 모름
[상한 100]   최악이 100

상한 100 이 있으면 최악이 정해진다는 점이 셋 중 가장 크다. 왜 하필 100 인지는 케이스에 근거가 없어서 성능과 사용성 어느 쪽 판단인지 알 수 없다.

최대 100개 에 닿았을 때 무엇을 보여 주는지는 케이스에 없다.

[더 없음 표시]   끝났다고 알려줌
[그냥 안 늘어남]  스크롤해도 그대로

그냥 안 늘어나면 사용자 쪽에서는 두 상황이 같아 보인다.

[네트워크 문제]  더 있는데 못 가져옴
[상한 도달]      더 없음

네트워크 문제 면 다시 시도하는 것이 맞고 상한 도달 이면 그럴 이유가 없다.

구분이 없으면 사용자가 새로 고침을 되풀이하고 그 요청이 다시 부하가 된다. 앞서 본 문서에 네트워크 off 케이스가 그렇게 많았는데 여기에는 그 구분이 없는 것이 눈에 걸린다.

두 숫자는 서로 관계를 갖는다.

100 ÷ 20 = 5회

20 을 25 로 두면 네 번이 되고 100 을 나눠떨어뜨리는 것은 그대로다.

30 으로 두면 세 번에 열 개가 남아서 마지막 페이지만 어중간해진다. 그 자체가 잘못은 아니지만 마지막 개수가 다른 것이 상한 때문인지 자료가 부족해서인지 갈리지 않는다.

한쪽만 바꿀 때 이 관계가 눈에 안 들어오면 그런 상태가 생긴다. 앞서 본 것처럼 20 이 여러 화면에 각각 적혀 있으니 100 도 마찬가지일 가능성이 크다.

함께 봐야 하는 값은 가까이 두는 편이 낫다. 떨어져 있으면 한쪽을 고치면서 다른 쪽을 볼 계기가 없다.

같은 화면의 다른 항목도 눈에 걸린다.

홈 화면에서 하단으로 스크롤
→ 상단 로고 & 검색바 영역이 숨김 처리

상단 로고 & 검색바 를 접어 목록을 넓게 보이려는 처리로 읽힌다.

그런데 위로 스크롤했을 때 다시 나오는지가 케이스에 없어서 숨김 처리 만 적혀 있고 복귀가 안 적혀 있다.

복귀하지 않으면 검색바를 쓰려고 맨 위까지 올라가야 하는데 목록이 100 개면 한참이다. 화면을 넓히려던 처리가 다른 기능을 어렵게 만드는 셈이다.

다행히 다른 자리에 이런 항목이 있다.

위로 버튼 선택 → 목록 최상단 노출

목록 최상단 으로 한 번에 가면 숨었던 검색바도 함께 나올 것이다.

[숨김]      화면을 넓힘 — 상단 접근이 어려워짐
[위로 버튼]  상단 접근을 되살림

숨김 처리 와 위로 버튼 이 설계상 짝인데 문서에서는 서로 떨어져 있다.

숨김 항목만 보면 왜 숨기는지도 대신 무엇이 있는지도 안 나온다. 항목별로 나열하는 형식에서는 각각이 명확한 대신 항목 사이의 관계가 드러나지 않는다.

이 화면에는 짝인 값이 둘 있었다. 한 번에 가져오는 양과 전체 상한이 그렇고 상단 숨김과 위로 버튼이 그런데 둘 다 떨어져 적혀 있다.