[정보디자인] adjacent in space

User Interface를 사람과 기계와의 대화라고 한다면 전 가급적 이 대화가 적었으면 합니다. 기계랑은 후딱 얘기를 끝내고 남은 시간을 좀 더 사람답게 사용하고 싶습니다.

Edward Tufte 가 얘기 한 adjacent in space rather than stacked in time 이라는 원칙을 정보 디자인에 적용하면 불필요한 대화(인터랙션)을 많이 줄일 수 있습니다. 사용자가 비교하고 선택하기 위해 정보를 나열하는 경우에는 비교에 필요한 정보 요소를 클릭같은 조작을 통해 하나씩 하나씩 보이게 하지 말고 같은 공간에 펼쳐놓아서 한 눈에 비교할 수 있도록 하라는 것입니다. stacked in time 방식을 터프티는 “It’s one damn thing after another” 라고 합니다. 의외로 이런 패턴이 많이 사용되고 있는데요. 몇가지 사례를 살펴보겠습니다.

이미지 출처 http://37signals.com/svn/posts/1128-learning-from-bad-ui

길찾기

요즘 운전할때 스마트폰으로 길찾기를 많이 합니다. TPEG 지원 네비게이션이 있어도 DMB의 여유 채널을 통해서 교통정보를 방송으로 내려받는 방식이라 내게 필요한 위치의 교통 정보가 방송으로 뿌려질때까지 기다려야해서 (주기가 5분이라고도 하는데 잘 모르겠네요) 그냥 스마트폰으로 빠른길을 찾아 볼때가 많습니다.

네이버나 다음 지도 앱의 길찾기에는 실시간 빠른길, 최적노선,최단 노선 등의 길 찾기 옵션을 선택할 수 있도록 하고 있는데요. 이런 방식이 stacked in time의 "빌어먹을 하나씩 하나씩" UI의 전형적 패턴입니다 :) 길찾기는 선호에 따른 설정이 아니라 비교를 통한 선택을 해야 하거든요. 보통은 많이 쓰는 실시간 빠른길을 디폴트로 찾는데요. 빨리 가는게 좋은 거긴 하지만 안 막히는 길로 돌고 돌아서 결국 운전하기 편한 최적 노선(큰길로 노선 변경없이 신호 대기 적은)보다 시간은 얼마 차이 나지 않는 경우가 있거든요. 그래서 아는 길이라면 대충 참고만 하겠지만 모르는 길을 가게 된다면 실시간 빠른길과 최적노선을 함께 비교하여 선택하는 경우가 대부분입니다. 이런 경우 하나씩 보게되면 앞에 본 걸 기억에 의존해서 비교하니 차이를 알기도 어렵고 불필요한 조작이 많습니다. 빨리 출발 안한고 스마트폰질이나 한다고 핀잔이나 듣게 됩니다.
 
 

네이버 지도앱에서 실시간과 최적 경로 비교. 경로 탐색 옵션을 변경한다.

다음 지도앱에서 실시간과 최적 경로 비교 (길찾기 검색 한 후와 옵션 변경시 실제로 이렇게 경로가 화면에 딱 맞지 않고 지도 위치도 바뀝니다)


그래서 전 실시간 빠른길과 최적 두가지 경로를 예상 소요시간이나 거리 정보와 함께 표시하여 한 눈에 비교할 수 있도록 만든 매쉬업을 사용합니다. 보통은 최적경로를 우선하고 길이 막혀서 실시간 빠른길과 시간 차이가 많이나면 빠른길을 택합니다. 택시 기사분이 어떤 길로 가드릴까요 물어볼때도 유용하게 사용하고요. 네이버의 길찾기 정보를 가져오는데 택시비도 거의 정확하게 맞더라구요.

lazy 길찾기 by 무이

지도 상의 경로 표시 정보도 고민해 볼 필요가 있는데, 가급적 경로상의 주요 랜드 마크와 경로를 함께 표시하는게 좋겠습니다. 사람이 길을 설명할때도 "강변북로" 타고 오다가 "갤러리아" 앞에서 좌회전 해 뭐 이런식으로 말하잖아요. 저는 랜드마크를 표시했는데 네이버는 경로 상의 주요도로를 표시하고 있네요. 그에 비해 다음지도는 별 필요없는 현 출발지 버블로 정작 중요한 지도상의 경로를 가리고 있습니다. 어떤 정보가 중요한지 고민이 좀 필요할 것 같습니다. 출발 도착 구분을 네이버는 텍스트로만 구분하고 있어서 구분이 쉽지 않고 다음은 색으로 구분했지만 의미와 색이 아무런 관계가 없기 때문에 헷갈리기는 마찬가지 입니다. 도착은 고정된 위치의 심볼로 출발은 pegman이나 자동차 같은 이동 가능한 대상의 아이콘으로 구분하면 인지하기 쉽습니다.

이 글을 쓰게 된건 iOS6에 포함된 애플 지도의 길찾기 UI 때문이었는데요. 여러 경로가 한 화면에 표시되어 아 역시 애플은 제대로구나 생각했습니다.(기존 지도에도 동일하게 적용되어 있습니다) 근데 써보니 아니더라구요 :) 애플 지도는 경로는 한번에 표시하고 있긴 하지만 정작 중요한 정보인 예상 소요시간이나 총거리를 보려면 결국 하나씩 선택해서 봐야합니다. 물론 시각적으로 경로 비교가 되고 바로 경로를 선택할 수 있어서 네이버나 다음처럼 경로옵션을 누르고 나오는 옵션 목록에서 선택하는 것에 비하면 훨씬 좋긴 하지만요.

애플  iOS6 지도앱

 

항공권 가격 비교

국내 항공권 비교 사이트는 대부분 항공사와 가격 위주로 정보를 표시하는 것 같습니다. 하지만 실제 여행 계획을 세우려면 출발 시간과 도착시간, 경유를 하는 경우에는 기다리는 시간이 얼마나 되는지 확인해야 합니다. 싸다고 공항에 갖혀서 밤 새울 수는 없잖아요. 이런 비교에 필요한 중요 정보를 함께 표시하지 않으면 매번 상세 정보를 하나씩 하나씩 클릭해 봐야 합니다.

투어익스프레스 http://airbooking.tourexpress.com/AirTop.html

자세히 살펴 보니 여행자가 탈 수 있는 출도착 항공편에 따라 정렬 되는게 아니라 여행사가 보유한 출발편,도착편을 조합한 "상품"이 나열되어 있습니다. 상품과 가격이 중심이고 소비자의 여행 경험은 UI에 반영되어 있지 않아요. 국내 대부분의 항공권 비교 사이트가 이런식인 것 같습니다. 항공사 사이트를 주로 사용해서 몰랐는데 심각하네요. 

메타서치 엔진인 kayak은 출도착시간과 총 소요시간을 한번에 노출하여 비교할 수 있도록 합니다.

kayak  http://www.kayak.com 

가격 외의 중요한 정보는 결국 출발,도착,비행시간, 경유 지연시간 등 결국 시간에 관한 것인데요. hipmunk는 타임라인을 이용한 그래프로 이런 정보들을 시각적으로 쉽게 인지하고 비교 할 수 있도록 합니다. 가격 비교도 다른 요소들이 방해하지 않게 한곳에 모아서 바로 비교가 되고 비행시간, 출도착 시간도 시각적으로 쉽게 비교됩니다. 타임라인에는 출발지와 도착지 현지 시간을 함께 표시하여 시차에 대한 고민없이 여행 계획을 세울 수 있고요. 자정과 정오를 숫자가 아니라 따로 표기하고 시간도 저녁과 새벽은 어둡게 낮은 밝게 표시는 등 소소한 디테일도 훌륭합니다.

hipmunk http://www.hipmunk.com

 

추가로 국내 포털은 어떤가 싶어서 찾아봤는데요. 네이버는 손을 떼고 서비스를 종료했고요. 다음 여행의 항공권 비교 페이지는 "모든 주요 여행사의 가격비교를 한번에!"라는 모토로 여행사의 할인 항공권 정보를 모아서 보여 주고 있네요. 제휴 여행사의 할인 항공권 검색 결과를 긁어서 그냥 쭉 나열하는 메타 서치 형태인가봅니다.
왕권 항복권을 검색했더니 결과가 55페이지가 나옵니다.(한페이지에 15개씩). 출도착편을 조합해서 상품으로 묶은 안티-여행자 편의적인 상품 x 티켓 유효기간 차이 x 제휴여행자 수 만큼 중복된 항공권이 나열됩니다. 가장 먼저 나오는 일본항공의 항공편은 출발 5편 도착 5편인데 이걸 조합한 각 여행사의 상품은 200개가 넘습니다. 이 정도의 정보 쓰나미는 사람이 감당하기 힘듭니다. 실제 항공편 정보인 출도착 시간 그리고 잔여 좌석 수를 보려면 하나씩 하나씩 768번을 클릭해야 하고요.

심각하게 왜 이런 페이지가 필요한지 고민이 필요할 것 같습니다. 이런식으로는 항공권 검색이라는 원래의 목적을 전혀 수행 할 수 없어 보입니다.

다음여행 항공권 비교 http://air.travel.daum.net/

캘린더 일정

아이폰에서 기본 제공하는 캘린더의 월별 보기는 일정 유무를 점으로 표시합니다. 상세 내용을 보려면 해당 날짜를 선택 하면 됩니다. 그래서 전 안써요. 귀찮으니까. 

이전 프로젝트에서 캘린더를 사용하는 사용자 행태를 조사했는데요. 단순하게 나누면 꼼꼼하게 시간 단위로 일정을 기록하는 사람과 그렇지 않고 그날 그날의 약속이나 할일을 메모하는 퍼소나로 나눌 수 있었습니다. 저처럼 후자인 경우는 달력에 기록된게 많지 않으니까 상세 일정을 보지 않고도 한눈에 훑어 볼 수 있게 하는게 훨씬 효율적입니다. 그래서 전 tapcal 이라는 앱을 사용하고 있습니다.

아이폰 캘린더 vs tapcal

블로그 검색

네이버나 다음 블로그 검색 결과는 포함된 이미지를 하나 보여주고 마우스 오버시 추가로 펼쳐 보여줍니다. 하지만 새로운 상품 사용기, 여행, 맛집, 공연, 전시 등 사용자의 리뷰 위주의 글을 찾아 볼때는 함께 올린 사진 자체가 중요한 정보입니다. 경험 법칙상 사진 잘 많이 찍은 블로그는 그 만큼 정성이 많이 들어갔으니까 도움이 되는 글일 확율이 높습니다. 클릭할 지 말지 짧은 시간에 판단하는데는 본문 내용의 발췌보다 사진이 더 좋은 정보가 됩니다. 그래서 블로그 사진을 더 많이 노출할 수록 검색 결과에서 비교 선택이 쉽습니다. 블로그글을 읽지 않아도 검색결과의 사진만 훑어 보는 것으로 많은 정보를 얻을 수 있고요. 

네이버 블로그. 하나의 이미지만을 보여주고 마우스 오버시 이미지를 펼쳐보여줍니다.

lazy 블로그 검색 by 무이. 블로그 이미지를 모두 펼쳐 보여줌

구글처럼 블로그 사진을 노출하지 않는 검색은 이미지 없는 이미지 검색 결과 처럼 구시대의 유물같은 느낌이 듭니다. 대신 구글은 마우스 오버로 홈페이지 미리보기를 제공하는데요. 본문 내 이미지를 함께 표시하는 것에 비해 stacked in time 방식으로 귀찮기도하고 이미지에는 글의 본 내용보다는 스킨이 차지하는 영역이 더 커서 (블로그에서는 글이 중요하지 스킨이 중요한게 아니니까) SNR이 낮아 유용성이 떨어집니다. 저도 구글을 좋아하긴 하지만 국내의 사용자 리뷰성 블로그 글을 구글로 검색하는 건 좀 바보같습니다. 남들처럼 네이버 쓰세요 :) 

구글 블로그 검색. 블로그 이미지 노출하지 않고 마우스 오버시 페이지 미리보기 이미지 제공

하지만 모든 요소를 다 노출하는게 꼭 좋은 것 만은 아닙니다. 네이버 블로그 검색에서 "검색어 표시"와 "블로그 내 검색" 링크는 새로운 정보를 담고 있지 않으면서 계속 반복되어서 오히려 노이즈가 됩니다. 정보가 아닌 기능이고 또 사용 빈도가 상대적으로 낮다면 마우스 오버시에 보여주는게 좋겠습니다. 구글도 구글플러스를 총력적으로 밀어보겠다고 검색 결과에 +1 버튼을 총총히 박아 넣었다가 욕먹고 결국 마우스 오버시에만 노출하는 것으로 변경한 것 처럼요.

브라우저 탭

아이폰의 모바일 사파리의 zooming UI와 carousel 을 결합한 탭 이동은 데모를 볼때는 상당히 그럴 듯해 보이지만 이걸 매일 사용하려면 불편하기 짝이 없습니다. 하나씩 하나씩 움직여서 선택해야 하니까요. 
이번 mountain lion 에 탑재될 사파리에도 핀치 제스처를 이용한 아이폰 사파리와 유사한 미리보기 탭 전환 기능이 추가되었다고 하는데요. 눈이 즐겁긴 한데 손이 편할지는 모르겠습니다. 기존 탭이 있어서 쓸 일이 많지는 않겠지만요. 다만 기존 탭 방식은 작은 영역을 포인팅하여야 하니까  fitts's law 에 따라 조작 비용이 큰데 비해 제스처를 사용하게 되면 조작이 쉽다는 장점은 있을 것 같습니다.
 

아이폰 사파리 탭 전환

그런면에서 안드로이드 크롬은 장점을 가지고 있습니다. 카드를 펼친 메타포를 사용해서 바로 다른 탭으로 이동 할 수 있습니다(한번에 보여지는 건3개).  
주위에서는 안드로이드를 쓰는 사람도 적은데다가 ICS 단말을 쓰는 사람이 없어서 써 보지는 못하다가 얼마전 iOS 크롬이 공개되어 사용 중입니다. 안드로이드 용으로 먼저 개발된 구글 크롬을 구글 안드로이드에서 쓰는 사람을 본 적인 없다는게 참 아이러니합니다.

아이폰 용 크롬

초기 아이패드의 사파리는 탭을 그리드 형태로 나열하였는데요. 탭 미리보기를 공간에 쭉 나열하여 바로 선택할 수는 있지만 문제는 미리보기 탭으로 전환하기 위해 상단 툴바의 작은 버튼을 포인팅하고 다시 아래쪽의 탭을 선택하도록 조작이 두 단계가 되고 동선도 길어져서 불편했습니다. 화면이 크니까 팔의 움직임도 커서 정말 귀찮았습니다. 결국 일반적인 탭 방식으로 대체되었는데요. mountain lion의 핀치 + 그리드 탭 조합이 된다면 괜찮을지도 모르겠습니다.

아이패드 사파리 그리드 방식의 탭 전환(현재 사용되지 않음)

아이패드 사파리 탭(현재)

트위터 멀티미디어 보기

저는 트위터를 컴퓨터에서 볼때 공식 사이트 대신 twtkr을 사용합니다. 공식 사이트가 업데이트 되면서 링크된 사진이나 동영상을 클릭 한번만 하면 한 화면에 펼쳐보여주는데요. 그래도 사진을 보기 위해 매번 클릭을 해야 한다는 걸 참을 수 없거든요. 이건 앞의 예들처럼 비교하고 선택하는 것은 아니지만 맥락 상 꼭 필요한 정보를 한 단계를 더 거쳐야 하는게 너무 귀찮습니다. 사람마다 트위터를 사용하는 행태가 다를 수 있겠지만 제가 팔로우하는 트윗들에서는 대부분 사진 자체가 정보인 경우가 대부분인데 이걸 어떻게 하나씩 하나씩 클릭해서 확인하나요.

twitter 첨부 사진이나 동영상을 보려면 매번 클릭해야 한다.

twtkr +크롬 확장. 첨부된 동영상,사진을 바로 펼쳐보여준다. twtkr 자체 기능은 아니지만 크롬 확장으로 단축url을 사용한 멀티미디어도 일일히 다 풀어서 미리보기를 제공한다.

결론

한 화면에 펼쳐 보여는 adjacent in space 의 표현 방식을 택하는게 좋은데도 하나씩 하나씩 보이게 하는 stacked in time 형태를 취하는 나쁜 안티 패턴은 다음과 같은 유형이 있습니다.

1. 옵션을 변경해서 하나씩 선택해 보기 - 길찾기

2. 필수 정보를 누락해서 하나씩 상세 정보를 클릭해 보게 하기 - 항공권 비교, 아이폰 캘린더

3. 중요 정보를 마우스 오버로 표시하기 - 블로그 검색

4. 한 화면에 보이는 선택지 개수를 적게 하기 결국 하나씩 보이게 하기 - 브라우저 탭 carousel 

5. 비교 요소는 아니지만 맥락상 중요한 정보를 바로 안 보여주기 - 트위터

이런 정보 표현 방식에 대한 관점으로만 살펴보아도 많은 UI 문제를 찾아서 개선할 수 있습니다. 물론 많은 경우 UI 측면에서 고려를 못했다기 보다는 시스템의 부하를 줄이기 위한 구조 설계에 기인했다거나 하는 사연이 있을 수 있는데요. 사용자 리소스를 희생할지 시스템 리소스를 희생할지 의사 결정이 결국 사용경험의 차이를 만듭니다. 

주위에 이런 adjacent in space 방식이 필요한 곳에 stacked in time 이 사용된 나쁜 사례가 있으면 제보해주세요.

[참고##정보디자인##]