페이지 처리의 사용자 경험

>웹개발을 하면서 아주 꺼림칙하지만 빼먹을 수 없는 것이 바로 게시판 등의 페이지 처리다. 사용자를 위해서는 당연히 반드시 있어야 하는 기능이지만, 꼴랑 저 숫자 몇 개를 표시해주기 위해서 쓸데없이 디비를 한 번 더 괴롭혀야 한다는 점이 못내 마음 한 구석에 앙금으로 남곤 한다

개요

웹개발을 하면서 아주 꺼림칙하지만 빼먹을 수 없는 것이 바로 게시판 등의 페이지 처리다. 사용자를 위해서는 당연히 반드시 있어야 하는 기능이지만, 꼴랑 저 숫자 몇 개를 표시해주기 위해서 쓸데없이 디비를 한 번 더 괴롭혀야 한다는 점이 못내 마음 한 구석에 앙금으로 남곤 한다.

이런 페이지 처리에도 여러가지 형태가 있는데, 이 중에서 몇가지를 살펴보고자 한다.

페이지 처리의 방식

아래의 분류는 내가 그냥 생각나는 대로 임의로 붙인 것으로, 공식적으로 통용되는 명칭이 아니니 어디 가서 괜히 꺼냈다가 창피를 당하지 않도록 하자.

고전 뭉탱이 형

고전적인 뭉탱이 형태의 페이징 처리 방식이다. 현재 페이지가 포함된 덩어리를 보여주는 방식이다.

예를 들어 현재 페이지가 3페이지라면, 이 방식에서는 1 ~ 10 페이지까지를 보여주고, 그 중에 현재 페이지를 표시해 준다.

naverblog_paging.PNG

네이버 블로그의 뭉탱이 페이징

이 방식의 장점은 아무래도 익숙하다는 것이 있겠다.

고전 뭉탱이 형태의 페이징 기법에서 논란이 되는 것은 이전/다음 버튼의 역할이다.

pagination_button.jpg

위와 같은 형태의 일반적인 페이지네이션에서 동그라미 친 버튼의 역할이 한 페이지 이전/다음인지, 한 뭉탱이 이전/다음인지가 그 것이다.

양 끝의 버튼은 처음, 이라는 점이 대체로 합의가 이루어져 있기 때문에 별다른 논란이 없다.

두 경우에 대해 숫자로 표기해 본다면 이렇게 된다.

한 페이지 이전/다음인 경우
1(처음) 22 20 21 22 23 24 25 26 27 28 29 24 100(끝)
한 뭉탱이 이전/다음인 경우
1(처음) 19 20 21 22 23 24 25 26 27 28 29 30 100(끝)

UX나 논리적으로나 사실 위쪽보다는 아래쪽 방식이 합리적으로 보인다. 하지만 관습적으로 위쪽 방식을 사용하는 사이트들도 아직은 많이 있다.

위쪽 방식의 가장 큰 문제점은, 이전/다음 뭉탱이로 넘어가기 위해서 늘 두 번 이상의 클릭을 요구한다는 데 있다. 마우스 커서도 좌우로 바삐 움직여야 하고.. 이런 방식은 유저의 빠른 탐색을 방해하고 짜증을 유발한다.

발전된 뭉탱이 형

뭉탱이 방식이긴 하지만, 고정된 1~10까지의 덩어리가 아니라 현재 페이지 앞 뒤로 일정 갯수의 페이지를 보여주는 방식.

dnf_event_paging.PNG

던전앤파이터 무기 아바타 콘테스트 이벤트의 페이징 (0번이 있는 건 이벤트 내용 때문임)

위 이미지의 경우에는 양쪽에 이전, 다음 버튼이 있지만, 이 방식에서는 보통 처음 버튼이 있는 경우가 많다. 이전, 다음은 이 방식에서는 사실 아무 쓸모가 없기 때문.

장점이라면, 사용자가 마우스의 움직임을 최소화 한 채로 원하는 쪽으로 계속 해서 탐색해나갈 수 있다는 것이 있다. 예를 들어서 다음 페이지 번호를 누르고 페이지가 넘어가면, 다음 페이지는 현재 페이지가 되고, 마우스 커서가 있는 자리에는 그 다음 페이지의 번호가 오게 된다. 단순히 클릭만 계속 해서 연속적으로 다음페이지로 갈 수 있다.

더보기 형

이 경우는 전체 게시물 갯수를 뽑아올 필요가 없는, 개발자 친화적인 방식이다. 단순히 목록 밑에 더보기 버튼을 두어서 클릭시에 이후 목록을 로딩해서 보여주는 방식이다. 혹은 스크롤을 목록 끝까지 내리면 자동으로 다음 페이지를 로딩하거나.

이런 방식은 페이스북이나 트위터, 혹은 최근 개발되는 여러 사이트에서 사용되고 있다. 아무래도 대량의 데이터를 다루게 되면 이 방식이 유리하긴 하다.

단점으로는... UX 가 엄청 나쁘다는 게 있다. 일단 페이지를 넘겨도 주소가 변하지 않고, 다음번 페이지 방문 시에 다시 보던 위치까지 돌아가려면 처음 방문시와 같은 횟수의 내비게이션을 거쳐야 한다. 그래서 이런 방식을 사용하는 사이트는 각 게시물의 퍼머링크를 제공하긴 하지만 이건 사실 최소한의 UX를 보장하기 위한 고육지책이다. 물론 그 목적만으로 넣는 건 아니지만..

페이저 형

이전다음 버튼만 있는 타입. 이것도 DB 부하를 줄이면서 앞의 더보기 형의 단점을 갖지 않는 방식이다. 주로 한 페이지에 많은 게시물이 있는 목록보다는 소수의 게시물이나 단일 게시물이 있는 경우에 많이 사용된다. 따라서 단순한 리스트와 UX 를 비교하기는 사실 쉽지 않다. 흔히 블로그 포스트에 사용되는 방식.

결론

개발자나 서버 입장에서야 단순 페이저 혹은 더보기 방식을 사용하는 것이 편하지만, 사용자 경험을 고려하면 뭉탱이 방식이 주는 편의성을 포기하기는 힘들다. 사이트 특성에 맞는 고려가 필요하지만, 예를 들어 텀블러에서 흔히 사용되는 더보기 방식 + 글 내용 전체를 보여주지 않고 클릭해야 글 내용을 볼 수 있는 방식(이건 스킨의 문제라는 말도 있다. 나는 텀블러를 사용해보지 않아서 잘 모른다)은 UX 측면에서 정말 최악이라는 건 꼭 짚고 넘어가고 싶다. 스크롤을 한참 내리다가 글 하나를 클릭해서 본 뒤에 뒤로가기를 누르면 원래 보던 위치로 돌아가는 데 엄청난 분노를 느끼게 된다. 혹은 고전 뭉탱이 방식에서 이전/다음 버튼의 잘못된 고려로 게시판 탐색하다가 마우스를 던지게 되기도 한다.

사소한 부분이지만 이런 부분이 주는 불편이 유저에겐 큰 불만이 될 수 있다는 점을 꼭 기억하자.

[이전 글] Windows Phone 8.1용 유가정보 앱 만들기

윈도 폰을 샀다. 보급형으로 싼 가격에 홍콩에서 주문했더니 하루도 안 걸려서 도착했다. 그래서 냅다 유심칩을 갈아끼고 그걸 사용하기 시작했는데, 아무래도 국내 환경에서는 여러가지로 안 되는 게 많다.