드로어

화면 하나에 담을 수 있는 정보에는 한계가 있습니다. 그래서 목록을 보다가 한 건을 고치려면 오랫동안 두 가지 방법밖에 없었습니다. 새 페이지로 이동하거나, 뒤를 가리는 창을 띄우거나.

둘 다 대가가 있었습니다. 페이지를 옮기면 방금까지 보던 목록이 사라집니다. 스무 개 중 세 번째 항목을 고치고 돌아왔더니 목록이 처음 상태로 돌아가 있고, 걸어 둔 조건도 스크롤 위치도 다시 잡아야 합니다. 뒤를 가리는 창은 이동은 없지만 맥락이 끊깁니다. 지금 고치는 값이 옆 항목과 비교해서 맞는지 확인하려면 창을 닫아야 하고, 닫으면 고치던 내용이 날아갑니다.

페이지덱에서도 같은 장면이 반복됐습니다. 문서 목록에서 "지난주에 수정된 것만" 으로 조건을 걸어 놓고 한 문서의 공유 권한을 바꾸러 상세 페이지에 들어갔다가, 돌아오면 조건이 풀려 전체 목록이 다시 떠 있었습니다.

드로어는 이 왕복을 없애려고 만든 자리입니다. 목록은 그 자리에 남겨 두고, 고칠 것만 화면 옆에서 밀고 들어옵니다. 뒤가 절반쯤 보이니 비교하면서 고칠 수 있고, 닫으면 조건도 스크롤도 건드린 적 없는 상태로 남습니다.

평소에는 화면 바깥에 접혀 있다가, 사용자가 무언가를 누르면 한쪽 가장자리에서 안쪽으로 밀려 들어옵니다. 이 동작을 만들려면 네 가지를 정해야 합니다.

1. 여는 방법. 목록의 한 행을 누르면 열리게 할지, 행 끝의 별도 버튼을 눌러야 열리게 할지 정합니다. 행 전체를 누르면 열리게 해 두면 문서를 열려던 사람이 자꾸 편집 패널을 마주칩니다.
2. 방향과 너비. 오른쪽에서 나오는 것이 가장 흔하고, 모바일의 메뉴는 보통 왼쪽에서 나옵니다. 너비는 480픽셀처럼 고정값으로 두거나 화면의 40퍼센트처럼 비율로 둡니다. 비율로 두면 넓은 모니터에서 패널이 지나치게 벌어지므로 상한을 함께 겁니다.
3. 뒤 화면의 처리. 뒤를 살짝 어둡게 덮고 누르면 닫히게 할 수도 있고, 뒤를 그대로 살려 두고 목록을 계속 조작하게 할 수도 있습니다.
4. 닫는 방법. 패널 안의 닫기 버튼, 패널 바깥 클릭, Esc 키 셋을 모두 열어 두는 것이 기본입니다. 하나만 남겨 두면 그 하나를 못 찾은 사용자는 뒤로 가기를 누르고, 그러면 페이지를 통째로 떠납니다.

밀려 들어오는 움직임은 장식이 아니라 설명입니다. 트랜지션은 상태가 바뀌는 사이의 움직임을 뜻하는데, 드로어가 200밀리초쯤에 걸쳐 오른쪽에서 들어오면 사용자는 이 패널이 어디서 왔고 닫으면 어디로 갈지를 따로 배우지 않고도 압니다. 아무 움직임 없이 툭 나타나면 화면이 통째로 바뀐 것처럼 보입니다.

키보드로 쓰는 사람을 위해서는 열리는 순간 포커스를 패널 안으로 옮겨야 합니다. 포커스는 지금 키보드 입력을 받는 요소가 어디인지를 가리키는 상태입니다. 이걸 옮기지 않으면 탭 키가 뒤에 가려진 목록 위를 돌아다니고, 화면을 소리로 읽는 사람은 패널이 열린 줄도 모릅니다. 닫을 때는 열기 전에 눌렀던 요소로 포커스를 돌려놓습니다.

세 가지 자리에서 특히 자주 보입니다.

첫째는 목록 옆 편집입니다. 사용자·문서·주문처럼 줄줄이 늘어선 항목 중 하나를 골라 값을 고칠 때 씁니다. 옆 항목과 비교하면서 고쳐야 하는 일이라 뒤가 보이는 편이 낫습니다.

둘째는 조건 패널입니다. 조건이 예닐곱 개를 넘어가면 화면 위에 다 펼쳐 둘 수 없어서 옆으로 접어 둡니다. 패싯 필터처럼 속성별 조건을 겹쳐 좁혀 가는 방식이라면 조건 개수가 쉽게 열 개를 넘으므로 드로어가 기본 자리가 됩니다.

셋째는 좁은 화면의 메뉴입니다. 반응형 디자인은 화면 크기에 따라 배치를 바꾸는 설계를 말하는데, 넓은 화면에서 왼쪽에 고정돼 있던 메뉴는 폭이 좁아지면 들어갈 자리가 없습니다. 이때 메뉴를 드로어로 접어 두고 아이콘 하나만 남깁니다.

반대로 드로어를 쓰지 않는 자리도 분명합니다. 지금 답하지 않으면 다음으로 넘어갈 수 없는 질문, 예를 들어 "이 문서를 정말 삭제할까요" 같은 확인은 드로어로 띄우지 않습니다. 뒤가 살아 있으면 사용자가 그냥 다른 걸 누르고 지나가 버립니다.

"이건 모달 말고 드로어로 가죠. 뒤 목록 보면서 고쳐야 하는 화면이라서요."

앞뒤를 비교하며 작업하는 자리이니 뒤를 막지 말자는 제안입니다.

"드로어 너비 480으로 고정할까요, 아니면 화면의 40퍼센트로 할까요?"

넓은 모니터에서 패널이 얼마나 벌어질지를 정하자는 말입니다.

"드로어 열려 있을 때 뒤 목록이 같이 스크롤되는 것부터 막아 주세요."

패널 안에서 휠을 굴렸는데 뒤 화면이 움직이는 상태를 고쳐 달라는 요청입니다.

페이지덱에서 이 말이 가장 자주 오간 곳은 팀 관리 화면이었습니다. 구성원 목록에서 한 명의 권한을 바꾸는 흐름을 민서가 처음에는 별도 페이지로 그렸는데, 사용성 검증에서 참가자 다섯 명 중 넷이 권한을 바꾼 뒤 목록으로 돌아와 방금 누구를 고쳤는지 찾느라 헤맸습니다. 민서가 이를 드로어로 바꾸자 같은 과업의 완료 시간이 절반으로 줄었습니다.

태오는 여기에 한 가지를 더 챙겼습니다. 드로어 안에서 값을 고치다가 바깥을 잘못 눌러 닫히면 입력이 날아가므로, 고친 내용이 있을 때는 바깥 클릭으로 닫히지 않게 막았습니다.

드로어를 모달의 작은 형제쯤으로 여기는 경우가 가장 많습니다. 둘 다 기존 화면 위에 떠서 무언가를 보여 주니 자연스러운 오해입니다. 그런데 두 부품은 목적이 반대입니다. 모달은 사용자를 붙잡아 답을 받아내려고 뒤를 막고, 드로어는 뒤를 살려 두려고 옆으로 비켜 섭니다. 이걸 섞으면 삭제 확인을 드로어로 띄워 놓고 사용자가 답하지 않은 채 다른 작업을 시작하거나, 긴 편집 폼을 모달로 띄워 놓고 참고할 값을 못 보게 만드는 화면이 나옵니다.

드로어를 좁은 화면 전용 부품으로 아는 것도 흔합니다. 모바일 메뉴로 처음 접하는 사람이 많아서 그렇습니다. 실제로는 넓은 화면에서 더 유용한 경우가 많습니다. 폭이 1400픽셀인 화면에서 목록이 왼쪽 900픽셀을 쓰고 드로어가 오른쪽 500픽셀을 쓰면 두 가지가 동시에 보이는데, 이건 좁은 화면에서는 불가능한 배치입니다. 드로어를 모바일용으로만 분류해 두면 데스크톱 화면에서 같은 작업을 굳이 페이지 이동으로 만들게 됩니다.