태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.


'adjacent in space'에 해당되는 글 6건

  1. 2016.06.02 중급 UX 디자이너로 성장하기 7편 - 시간 위의 디자인 by 이 재용
  2. 2015.07.02 한국어 맞춤법/문법 검사기 리디자인 (14) by 無異
  3. 2014.09.22 [정보디자인] 정보 소비 맥락을 고려한 시간표 리디자인 (7) by 無異
  4. 2012.07.03 [정보디자인] adjacent in space (3) by 無異
  5. 2010.05.20 다음 모바일 초성검색 자동완성 (2) by 無異
  6. 2010.03.24 아이폰 웹브라우저 페이지 전환 : adjacent in space by 無異
2016.06.02 07:50

중급 UX 디자이너로 성장하기 7편 - 시간 위의 디자인

초보 UX 디자이너에게 가장 해 주고 싶은 말은, "구체적인 데이터를 가지고 생각해라"이다. 예를 들어 리스트를 만들 때 추상적으로 생각하여 대충 이렇게 리스트를 만들면 되겠지?하고 만든 다음 "리스트에서 항목의 개수는 얼마가 가장 좋을까요?" 이런 식으로 질문하는 경우가 많은데, 그렇게 생각하지말고, 우리 앱의 사용자는 어떤 사람이고, 이 사람은 맛집 목록에서 대개 몇 개까지 볼 생각이 있을거야. 우리가 기술적으로 몇 개를 추천하면 이 사용자를 만족시킬 확률이 80% 이상일까? 그러면 몇 개의 항목을 보여주되, 이 사람이 가장 중요하게 생각하는 정보는 무엇일까? 이 사람은 항목 간 비교에서 무엇을 가장 중요하게 생각할까? 이런 문제들을 스크린 높이와 함께 고려하면, 자연스럽게 "사용자 목표를 가장 만족시킬 수 있는 리스트 항목의 개수"가 나올 수 있다.


특히 마지막 부분에서 나열한 항목의 '비교'는 어떻게 할까?라는 점을 고민하다보면, 초보 UX 디자이너들에게 두 번째 해 주고 싶은 말인, "시간에 쌓지 말고, 공간에 펼쳐라"가 나온다.

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

이 글을 꼭 읽어 볼 필요가 있다. 

[정보디자인] adjacent in space


서론이 길어졌는데, 이제 중급 UX 디자이너에게 하고 싶은 말은, 어쩌면 위의 말과 (언듯 보기에) 반대의 말처럼 보이는 내용이다.


중급 UX 디자이너에게 하고 싶은 말 - 시간 위의 디자인

말은 인터랙션 디자인 혹은 UX 디자인이라고 했지만, 실제로 오랜 동안 화면 위의 디자인, 혹은 UI 디자인을 해 온 것이 사실이다. 대부분의 고민은 위의 서론처럼, 공간 상에 어떻게 제시할 것인가에 대한 고민이었다. 제한된 자원인 화면 위에 어떤 요소를 어떤 방식으로 제시하여 사용자의 효율, 학습, 공감을 얻을 것인가에 대한 답을 제시하는 것이 가장 중요한 부분이다. 


공간 상의 배치는 먼저 가장 큰 화면 구분을 고민하고, 그 뒤에 Framework 이라는 큰 구분을 그어 네비게이션 영역이나 작업 영역으로 나누고, 거기에 필요한 요소를 배치해 들어가는 식으로 작업하며, 이에 따라 와이어프레임이니 스토리보드니 하는 다양한 문서를 만들게 된다.


그런데 '서비스 디자인'이라는 것이 나오면서, 시간 위의 사용자를 분석하고, 시간 위에서 디자인하는 것의 중요성이 처음 부각되었다. 사용자의 큰 흐름을 기술하기 위해 여정 지도(Journey Map)라는 문서 형식이 채용되었고, 디자이너는 이 도구로 시간의 흐름 속에 사용자가 어떤 감정을 느낄 것인가를 분석하거나 설계할 수 있게 되었다.


하지만 아쉬운 건 이 여정 지도는 공간의 대응 개념을 생각하면 대체로 Framework에 해당하는 큰 구분에 불과하고, 화면 설계서처럼 시간의 영역과 시나리오의 종류를 잘게 나누어 기술하는 문서 형식은 아직 없는 셈이다. 문제는 이러한 영역이 갈수록 "앱 서비스 디자인"에서 중요해 지고 있다는 점이다.


앱을 멋지게 디자인하기만 하면, 사용자가 알아서 써 줄 거라는 믿음과 달리 현실은 사용자가 처음 이 앱을 본 순간 무엇을 알아야 하고, 그 다음 날은, 그리고 그 다음 날은 또 사용자에게 무엇을 알려야 할 것인가를 치밀하게 디자인하지 않으면 무료 앱의 보유율(Retention)은 곤두박질치게 마련이다.


이렇게 큰 틀의 설계 뿐만 아니라, 우리 앱의 사용자가 이런 걸 원하는 순간에는? 저런 걸 원하는 순간에는? 하는 식의 사고에 대해, 과거에는 이걸 원할 때를 대비하여 이 버튼을 왼쪽에, 저걸 대비하여 이 버튼을 오른쪽에 두는 식으로 설계를 할 수가 없기 때문에 (공간도 좁고, 그려 두어도 보지도 않고 등등) 우리는 그것이, 그 순간 튀어 나오게 설계를 할 수 밖에 없다. 즉, 기능을 공간에 그리면 안 되고, 시간에 그려야 한다.


아울러 모바일 앱의 가장 큰 특징은,

인터넷 혁명의 가장 중요한 점은 공간의 한계를 극복한 것이며,

모바일 혁명의 가장 중요한 점은 시간의 한계를 극복한 것이다. 

즉 인터넷에서는 접근성이, 모바일에서는 즉시성이 가장 중요하다.

김이식 상무

이라고 볼 수 있다. 

기존의 웹이나 PC앱에서는 '알람'이 불가능하다. 하지만 늘 들고 다니면서 화면을 보는 모바일앱은, 적절한 시점(혹은 이벤트)에 푸시 노티를 보여 주거나 다른 방법으로 사용자의 주의를 끌 수 있다. 


예를 들어 택시 앱을 설계한다고 생각해 보자.

대부분의 UX 디자이너들은 사용자가 앱에 들어가면 지도를 아래에 보여줄까, 현재 위치를 위에 보여줄까, 자주 가는 목적지를 가운데 보여줄까 등 화면을 어떻게 구성할지 고민하게 된다. 물론 이것도 중요하다.


하지만, 중급 UX 디자이너라면, 어떤 이벤트와 어떤 시점에 무엇을 보여 줄까를 생각해야 한다.

예를 들어, 우리 사용자가 큰 길 가로 나갔다면 우리 앱은 뭘 보여줄까?

만약 사용자가, 밤 12시에 우리 앱을 켰다면 우리 앱은 맨 처음에 무엇을 보여주어야 할까? 반대로 아침 8시에 켰다면 무엇을 보여주어야 할까? 택시를 탔다면 무엇을 보여줄까? 택시를 내렸다면 무엇을 보여줄까? 등등, 어떠한 이벤트에 어떤 종류의 상호 작용을 시작할지를 매우 고민해야 한다.

이런 종류가 잘 시도된 것이, 구글 나우 서비스다. 월요일 아침에 집을 나서면, 오늘 날씨는 어떻고, 회사까지 소요 시간은 얼마나 걸릴 것인지 알려준다. 카카오 택시도 택시를 타면 안심 문자 발송을 물어보고, 택시를 내리면 기사 평가를 물어본다.


상호 작용의 시작을 잡았다면, 그 이후 어떻게 이 상호 작용을 사용자가 원하는 궁극의 만족감으로 이끌지를 고민하고 끝까지 완성하는 설계를 해야 한다. 작은 기사에 사용자가 관심을 보였다면, 그에 맞는 상품을 추천하고, 그 상품을 클릭했다면 비교해 볼 수 있는 상품이 자동으로 따라 나와야 하고, 그 상품에 대한 댓글이 제시되고, 이제 살 수 밖에 없는 가격 혜택이 있어 흐름을 따라가다보면 어느새 물건이 우리 집에 와 있는 경험을 설계해야 한다.


또 이러한 시작점과 흐름을 완벽하게 만들 수 있는 핵심은 개인별 데이터이다.


최근 Fabricio Teixeira가 개제한 The State of UX in 2016 (2016년, UX는 무엇을 말하는가?)에서도 픽셀 디자인의 종말이 보인다면서, Designing Around Time이 매우 중요하다고 주장했다.


그가 말한대로 우리가 지금 디자인하는 앱이 모두 없어지고 대화형 커머스/에이전트가 모든 것을 대체할지는 몰라도 적어도 UX 디자이너에게 시간의 흐름에 따라 디자인하는 것이 그 어느 때 보다도 중요해 지고 있는 것은 틀림없는 사실이다.


Smashing Magazine의 Anders Toxboe가 작성한 "Beyond Usability: Designing With Persuasive Patterns 사용성, 그 이상: 설득형 패턴 만들기)에서도 전반적으로 이러한 특정 사건을 기점으로 설득적인 전개를 하여 최종적인 목표를 이루는 것(Closing the Deal)의 중요성을 강조하면서, 시간에 따라 경험을 디자인하기(Designing the Experience Over Time)을 강조하고 있다.


이렇게 많은 사람들이 시간 위의 디자인이 중요하다고 생각하지만, 결국 무언가를 디자인할 때 시간 위에 디자인을 하기는 쉽지가 않다. 사람들이 생각하는 방식이 워낙 공간 위에 펼치는 것에 더 익숙하기 때문이다. 시간 위에 설계하기 위해서는 사용자 여정 지도나 서비스 블루 프린트 처럼 시간 축을 중심으로 하는 설계 도구들이 더 개발 되어야 하는 측면도 있다.


중급 UX 디자이너라면, 이제 우리 앱의 첫 화면을 설계하면서, 우리 사용자의 첫 일주일을 설계해 보자. 예를 들어 커머스 모바일 앱을 만든다고 하면, 첫 화면에 메뉴는 상품 카테고리일 거고, 아래로 주욱 이벤트 상품부터 추천 상품까지 상품 리스트가 펼쳐지며, 개별 상품을 누르면 개별 페이지로 갈 것이다. 공간에서는 달리 뭘 할 것이 많지 않다. 그러나 우리 앱을 오늘 처음 방문한 사용자가 "왜 내일 다시 우리 앱을 방문해야 하나?"라는 이유와 장치를 설계하기는 쉽지가 않다. 그것이 중급 UX 디자이너가 해야할 일이다.

[참고##프로젝트 방법##]



팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 0
Ad Test...
2015.07.02 07:52

한국어 맞춤법/문법 검사기 리디자인

많은 분이 애용하는 부산대학교 인공지능 연구실에서 만든 한국어 맞춤법/문법 검사기, 저도 잘 사용하고 있습니다. 사전을 기반으로 한 단순한 맞춤법 교정이 아니라 문법 규칙과 의미 분석, 오류 통계를 통해서 문맥상의 오류나 번역 투의 문체 오류까지도 잡아내어 바른 표현을 알려줍니다. 강력한 검사 기능과 더불어 충실한 도움말을 제공하여 바른 우리말 사용을 배우는 데 많은 도움을 얻고 있습니다. 이 글을 쓰면서도 맞춤법 검사기를 이용했습니다.


다만 UI 측면에서는 아쉬운 부분이 있어 좀 고쳐보았습니다. 스스로는 만족스럽게 사용하고 있는데요. 이런 UI 개선점을 반영해 주셔서 다른 사용자도 같이 더 편하게 쓸 수 있으면 하는 바람으로 블로깅 합니다.


추가 : 한국어 맞춤법/문법 검사기사이트에 제안한 UI가 실제로 반영 되어 서비스 되고 있습니다. 고맙습니다.:)

1. 사용 흐름을 고려하여 정보를 공간에 펼쳐두기


부산대의 맞춤법 검사기뿐 아니라 기존의 상용 맞춤법 검사기들은 모두 공통으로 원본에 밑줄을 긋는 식으로 오류 표기를 지적하고 별도의 창이나 팝업메뉴를 통해서 대치어를 제안하는 구조로 되어 있습니다. 하나씩 선택하고 바꿔주는 작업 흐름이라 많이 번거롭습니다. 개정된 UI에서는 교정표에 오류를 모아두고는 있지만, 문맥을 확인하려면 결국 원문과 교정표를 왔다 갔다 시선이 옮겨 갈 수밖에 없습니다.



그림1. 한국어 맞춤법/문법 검사기



 stacked in time vs. adjacent in space의 정보 표시 구조로 바라보면 현재 방식처럼 하나씩 살펴보는 것보다 공간에 펼쳐놓는 방식이 훨씬 바람직합니다. 종이에 적은 교정지가 원래 그랬습니다. 빨간 펜으로 잘못된 부분과 바꿔야 할 내용을 한 번에 보여줍니다. 



그림2. 대치어를 원문에 같이 보이기 리디자인



온라인에서 기존보다 더 비효율적인 방식을 택했던 이유는 아마도 맞춤법 교정 기능을 주로 사용해 온 워드프로세서가 문서 스타일을 꾸미는 데 집중했었기 때문이 아닌가 싶습니다. 문단의 꾸밈을 흐트러뜨리지 않고 교정 제안을 함께 표시하기가 어려우니 밑줄로 오류 표시만 한 것 같습니다. 


원문에 바로 대치어를 표시해주면 문맥을 보면서 확인할 수 있어서 현재처럼 분리하여 표시하는 것보다 훨씬 자연스럽습니다. 이때 오류 문구 자체를 하이라이트로 강조하기보다 틀린 것은 오히려 덜 두드러지게 하고 옳은 표현을 강조해 보여주는 것이 좋습니다. 간단한 실수는 굳이 내가 뭘 틀렸는지 재확인하지 않아도 대치어만 보고 수정하면 되니까 불필요한 인지를 줄여주어 보기 편합니다. 


인터랙션 부분에서는 원문에서 교정 내용을 확인하고 클릭하면 바로 수정하도록 했습니다. 현재에는 원문에서 틀린 부분을 클릭하면 교정표의 해당 항목으로 이동하게 되어 있긴 하지만 사실 이마저도 번거롭습니다. 도움말을 보거나 대치어가 여러 개 있어 확인이 필요한 경우에 그냥 단어에 마우스를 올리면 해당 항목으로 자동으로 이동합니다. 


같은 단어를 계속 틀리는 경우가 있는데요. 여러 번 등장하는 같은 오류는 한번 클릭으로 나머지도 한 번에 바꾸도록 했습니다. 별거 아니지만 같은 걸 또 입력하게 하는 UI는 내 말을 못 알아듣거나 무시하는 것 같아 기분을 상하게 하거든요. 회원 등록 양식에 같은 거 또 적게 하면 막 화나잖아요. 


이렇게 대치어를 원문에 함께 표시하여 사용 흐름을 바꾸는 것만으로 시선의 이동이나 마우스 조작이 현저히 줄어듭니다.



2. 사용자 대응 행위를 고려한 오류 컬러 코딩


오류 표시 색깔이 빨강, 파랑, 초록으로 달라서 사용하면서 무슨 차이가 있는지 항상 헷갈렸습니다. 보통 이렇게 연속적이지 않고 동떨어진 컬러 스킴을 사용하는 것은 의미가 다른 경우에 적용하는데요. 그래서 맞춤법이나 띄어쓰기 같은 오류의 유형에 따른 구분이라서 생각하였는데 도움말을 보니 확실히 틀린 건 빨간색, 규칙이나 문맥을 고려해서 찾은 오류는 녹색, 분석에 실패했지만 잘 못 사용한 것 같은 건 파란색으로 표시한다고 합니다. 

결국, 유형이 다른 것이 아니라 사용 경험 측면에서는 오류 검출의 신뢰성이라는 한 가지 속성에 따른 구분입니다. 이렇게 한 가지 속성값의 차이를 구분하는 경우에는 연속적인 색을 사용하는 것이 좋습니다. 등고선 표시를 생각하면 쉽게 이해가 됩니다. 알록달록 색상을 자의적으로 대응하면 의미를 이해하기 어렵지만 연속된 명도나 채도 또는 근접 색상을 사용하면 관계를 쉽게 유추할 수 있습니다. 


오류를 빨간색으로 표시하는 색상 대응은 익숙하니까 오류 신뢰도가 낮은 녹색과 파란색을 같은 계열인 주황색, 노란색 정도로 약하게 표시하는 게 자연스럽습니다. 빨간색도 간혹 틀리는 경우가 있고 녹색의 오류 검출 정확도도 높아서 둘의 차이가 잘 구분 되지 않았습니다. 그래서 둘 다 빨간색으로 하고 파란색만 한 단계 낮은 주황색으로 표시했습니다. 빨간색은 믿고 그냥 대치해도 되지만 주황색은 시스템이 틀렸을 수도 있으니 주의해야 하는구나 정도의 구분이면 충분한 것 같습니다. 



그림3. 띄어 쓰기 교정 부호 사용과 컬러 코딩 개선 리디자인



정확한 정보를 주겠다고 정보의 단계를 많게 하는 것보다 사용자가 대응하는 행위 구분이 명확한 수준으로 단순화하는 게 더 유용합니다. 요즘 자동차의 연비를 계기반에 실시간으로 보여주는 기능이 많이 채용되어 있는데, 상세하게 알려주는 것보다 파란색, 초록색, 빨간색 정도로 단순화하는 게 인지 부담도 적고 반응 행위도 쉽게 대응할 수 있어서 운전자의 행동 변화를 유도하는 데 더 효과적입니다. 


가장 빈번하게 틀리는 오류 유형이 띄어쓰기인데요. 이 정도는 바로 구분이 되면 좋겠습니다. 띄어쓰기나 붙여쓰기 같은 오류는 교정부호를 사용하고 교정부호에만 강조색을 사용하여 맞춤법이나 문법이 잘못된 오류와는 바로 구분되어 보이도록 했습니다. 문장 부호의 오류에도 같은 방법을 적용했습니다.



3. 정보가 드러나도록 장식 덜어내기


교정표의 테이블에는 정보 디자인에서 할 수 있는 다양한 실수들이 총체적으로 모여있습니다. 정보를 강조하기 위해 정보 자체가 아닌 불필요한 다른 요소를 추가하는 잘못은 일반인뿐 아니라 디자이너도 많이 합니다. 불필요한 요소를 추가하여 강조하면 그보다 더 두드러지기 위해 더 불필요한 요소를 또 덧붙이는 악순환이 계속됩니다. 테이블의 선이나 배경색 같은 것들은 실제 정보로부터 주의를 빼앗는 나쁜 잡음입니다. 정보를 강조하려면 이런 소모적인 경쟁이 아니라 덜 중요한 정보를 좀 내려두어야 합니다. 선보다는 여백과 정렬이 항목을 구분하는 데 더 효과적입니다. 

그림4. 교정표 테이블 리디자인

이런 안 좋은 디자인이 계속 양산되는 이유는 엑셀 같은 스프레드시트 프로그램이 기본 제공되는 템플릿 디자인 자체가 나쁘기 때문입니다. 엑셀은 출력보다는 입력을 위한 도구라서 셀 구분 선이 필요하고 구분 선이 있으니 항목을 강조하기 위해 울긋불긋 과도한 배경색을 사용하게 되는 것 같습니다. 

강조를 위해서 폰트의 크기나 굵기, 색상을 사용할 수 있는데 여러 요소를 섞어 사용하지 않도록 주의가 필요합니다. 한글은 획이 복잡해서 작은 크기에서 볼드를 사용하면 가독성에 문제가 있습니다. 문장 사이에서 강조하는 게 아니면 굵기보다는 크기를 키우는 게 효과적입니다. 
입력 내용의 오류 색상과 대치어의 링크 색상이 색상이라는 한가지 속성으로 각각 강조하면 서로 충돌이 생겨 어느 곳으로도 주의가 가지 않습니다. 크기를 키워서 둘을 강조하되 더 중요한 대치어에 오류 컬러를 적용하는게 보기 편안합니다. 고만 고만한 애들이 서로 경쟁하게 하지 말고 정보의 위계를 분명하게 하여 시선의 흐름을 만들어 주어야 합니다. 

거의 모든 경우에 테이블에서의 가운데 정렬은 좋은 선택이 아닙니다. 가운데 정렬은 정렬이 아니거든요. 될 수 있으면 글 선이 나란히 정렬되어야 읽기 수월합니다. 레이블의 경우는 매번 읽어야 하는 것이 아니니 잘 드러나지 않게 힘을 빼고 실제 정보의 열에 맞춰 오른쪽 정렬로 붙여두는 정도가 좋습니다.



4. 알림 팝업


알림과 경고를 구분하지 않고 잘 못 사용하는 경우가 많습니다. 수정된 내용을 클립보드에 복사하는 버튼을 누르면 복사가 완료되었다는 기본 경고 팝업이 뜹니다. 경고 팝업은 사용자가 알림을 인지하지 못하는 걸 방지하기 위해 명시적으로 확인 버튼을 누르기 전에는 다른 작업을 못하게 하는 modal dialog box를 사용하는 강력한 알림입니다. 

복사 완료했다는 알림은 내가 한 번 더 클릭 해 줘야 할 정도로 중요한 알림이 아닙니다. 하지만 기본 제공하는 alert 명령이고 다른 버그에 비해 별로 심각한 문제도 아니라서 우선순위에서 밀리고 무관심 속에 남용되고 있습니다. 카카오톡에서 사진 저장했다고 경고를 띄우면 안 된다는 거지요. 화가 나요. 1억 7000만 명의 사용자가 사진 저장하면서 매번 화를 낸다고요. 

이벤트에 의한 알림도 아니고 사용자 자신이 의도를 가지고 한 행위에 대한 피드백은 자동으로 닫히는 토스트 알림 정도로 충분합니다. 움직이며 나타나는 토스트 팝업은 모바일이 아닌 큰 화면에서도 효과적입니다. 다른 곳을 보고 있어도, 주변시에서 움직임에 대해서 본능적으로 주의하므로 알림을 전달하기에 충분합니다. 

 디자이너님, 개발자님. 자신이 만든 앱의 사용자 명령 피드백에 경고 상자를 잘 못 사용하지는 않는지 꼭 좀 확인해 주세요. 두 번 확인해 주세요. 요즘은 이렇게 변화가 잘 보이지 않는 명령 실행 완료의 피드백으로 명시적으로 텍스트 팝업을 띄우기보다 애니메이션을 이용해 간접적으로 표현하는 사례도 많으니 그런 걸 참고해도 좋겠습니다.



프로토타이핑


UI 개선 사항을 테스트 해보기 위해서 css 스타일과 스크립트를 오버라이드하는 코드를 만들었습니다. 간단히 테스트해보려면 아래 북마클릿을 북마크바에 드래그하여 저장 후에 맞춤법 검사기 의 검사 결과 화면에서 실행해 주면 됩니다.


추가 : 맞춤법 검사기에 UI가 이미 반영되어 북마클릿은 정상 동작하지 않습니다. 본 사이트를 사용하시면 됩니다.

맞춤법 검사 리디자인 북마클릿


매번 실행 하기는 귀찮으니 크롬 확장으로 자동으로 코드를 삽입 하도록 하고 있습니다. 더 편한 방법은 맥용 오토메이션을 사용할 수 있습니다. 미남이 님이 만들어 공개해 주신 맥용 맞춤법 검사 오토메이션 웍플로우에 스크립트를 추가하도록 했습니다. 받아서 실행하고 서비스에 추가하면 글 선택 후 맥락메뉴에서 한국어 맞춤법 검사를 실행 할 수 있습니다.


추가 : 맞춤법 검사기에 UI가 이미 반영되어 오토메이션은 정상 동작하지 않습니다.

맞춤법 검사 오토메이션





궁극적으로는 이런 편법보다는 UI개선 제안점이 반영되어 모두가 더 편하게 사용하면 좋겠습니다. 제가 디자인 한 교정 내용을 함께 표시하는 맞춤법 검사 UI 는 CC로 공유합니다. 한국어 맞춤법/문법 검사기 뿐 아니라 영리 목적으로 사용해도 좋으니 한컴 한글이나 MS word나 구글 문서 어디든 보다 편한 한글 맞춤법 기능을 제공해주면 좋겠습니다. 요즘은 대부분의 글쓰기 작업이 클라우드로 넘어가고 있으니 구글 문서나 네이버, 다음의 블로그, 이메일 작성창에도 제대로 된 맞춤법 검사 기능이 들어가도록 노력해주면 좋겠습니다.



리디자인이 적용되었습니다.

한국어 맞춤법/문법 검사기에 리디자인이 정식으로 반영되어 서비스하고 있습니다.

또 얼마 전 다음 맞춤법 검사기에도 같은 디자인이 적용되었습니다. 

고맙습니다.




한국어 맞춤법/문법 검사기 http://speller.cs.pusan.ac.kr





다음 맞춤법 검사기 http://alldic.daum.net/grammar_checker.do





Creative Commons License
교정 내용을 함께 표시하는 맞춤법 검사 UI by 無異 is licensed under a Creative Commons Attribution 4.0 International License.



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



팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 14
Ad Test...
2014.09.22 17:12

[정보디자인] 정보 소비 맥락을 고려한 시간표 리디자인

지난주에 저희는 HCI2014 학회에 참가하였습니다. (예 그렇습니다. 글을 쓰다가 내버려둔지 몇개월이 됐네요.) 학회 참가 기간 동안 몇가지 시간표들을 접하였는데요. 표의 열이나 행에 빽빽하게 숫자를 나열한 익숙한 형태였지만 시간표를 활용하는 실제 사용 맥락에서는 정보를 이해하기가 쉽지 않았습니다.
pxd에서는 이런 경우에 사내 전체 메일로 정보디자인 퀴즈를 내고 의견을 나누곤(주로 싸웁니다) 하는데, 업무가 바빴는지 참여가 저조했습니다. 그래서 이번에는 블로그를 통해 정보디자인에 관심있는 디자이너, 학생분들과 함께 고민해보려고합니다. 우선 제가 고민했던 부분을 공유합니다.


1. 도대체 리프트권 종류가 왜 이렇게 많아?

작년 학회 참가자들에게서 하이원 슬로프가 좋다는 얘기를 많이 들어와서, 저는 학회보다 스노우보드 타는데 더 관심이 있었습니다. 그래서 스키 신청 메일을 받자마자 바로 페이지를 열어봤는데요. 무슨 리프트권 옵션이 이렇게 많은지, 후야권, 야오권 이건 또 도대체 뭔지 알 수가 없어 많이 당황스러웠습니다.
리프트권 - 출처 : 하이원 홈페이지

시간을 어떻게 비교할까?

리프트권 구분에 사용되는 용어가 임의로 만들어진 조어라 이용시간을 꼼꼼히 살펴봐야만 나에게 적합한 리프트권을 선택할 수 있었습니다. 대충 보면 군더더기 없이 깔끔한 표이지만 막상 내가 원하는 시간을 비교하고 고르려고 하면 정신이 혼미해집니다.
정보를 전달하는 입장에서는 이런 표가 가장 효율적이겠지요. 적은 노력으로 누락없이 정확한 시간 정보를 전달합니다. 하지만 정보를 전달 받아 활용하는 사용자 입장에서는 표를 보고 비교 선택하는데 인지 부담이 큽니다. 수치로된 두 시간을 머리 속에서 개념화하여 기억해서 각각을 비교해야 하는데, 이런 정보 처리는 뇌가 익숙하게 할 수 있는 작업이 아니거든요. 단지 공간에 나열했다고 비교가 쉬운게 아닙니다.
이런건 머리 속으로 생각만 해서는 비교가 어렵기 때문에 우리는 뇌를 확장하려고 종이에 그려서 비교합니다. 이용 시간은 연속적인 시간의 구간이니까 공간의 한 축으로 치환해서 그래프로 시각화하기만 해도 비교가 수월해집니다. 비교 선택이 아니라 그냥 오후권은 몇시 부터 몇시까지에요? 라는 질문에 대한 정보를 제공하는 거라면 현재 표시 방법이 효과적이었겠지만요. 그럼 해결은 간단합니다. 추가로 표에 시각적으로 쉽게 비교할 수 있는 그래프만 더하면 될 것 같습니다. 그래서 제가 바로 그려봤을까요?
디자인을 하는데 있어 매우 중요하다고 거듭 느끼는 부분인데요. 문제가 무엇인지 정의(가정)하고 바로 문제를 해결하려고 하는 건 좋은 디자인 접근이 아닙니다. 그 다음 할 일은 비슷한 문제를 남들은 어떻게 해결했는지 열심히 찾아보는 것입니다. 다른 사람들의 해결을 살펴보면 내가 미쳐 보지 못했던 문제나 제약이 무엇인지 배울 수 있습니다.
처음에는 국내 스키 리조트의 홈페이지들을 찾아봤습니다. 하지만 역시나 시간을 숫자로 쭉 나열한 건 모두 똑같더라구요. *

그래서 이번엔 외국의 사례를 찾아봤는데요. 와. 스키 문화 자체가 달라요. 우리나라처럼 시간대별로 자잘하게 나눠서 리프트권을 파는게 아니라 하루권, 이틀권, 사흘권 이런 식이더군요. 일본의 근교 스키장 같은 경우에나 하루를 3개 정도 시간대로 나눠둔 정도이고요. 원하는 해결은 찾지 못했습니다. (좋은 사례를 아시면 알려주세요.)
그럼 이젠 직접 그려볼 차례입니다. 처음 한두개는 손으로 스케치를 해보다가 귀찮아서 표(HTML)의 시간을 읽어 그래프로 그려주는 스크립트를 짜서 돌렸습니다. 저는 코딩을 잘 몰라서 어렵게 했지만 요즘은 좋은 스크립트 라이브러리들이 많아서 이런건 간단히 할 수 있습니다.
redesign by 無異
숫자라는 심볼과 시간 개념(12 시간, 분과 시의 관계), 두 시간 간의 간격을 비교하려면 머리속에서 여러 차례 계산(변환) 과정을 거쳐야하지만 공간에 펼쳐놓으면 비교가 쉽습니다. 그래프의 위치와 길이 차이는 주의를 기울이지 않고도 바로 인지(pre-attentive processing)할 수 있거든요. 후야권이란건 오후+야간권이고 야오권은 야간+오전권 이었네요.


시간표는 24시간제를 표시하는게 좋다?

시간은 일반인에게 보다 익숙한 12시간제로 바꿨습니다. 제가 군인도 아니고, 제가 보는 시계도 12시간제로 되어 있어서, 24시간제로 표기된 시간을 보면 머리 속에서 한번 더 변환 과정을 거쳐야 하니 인지 비용이 발생합니다. 24시간제는 정보를 전달하는 입장에서 효율적입니다. 물론 12시간제로 표시하면서 동일한 오전,오후를 반복하여 표기하면 24시간제보다 더 복잡해 보일 수 있습니다. 하지만 대부분의 일상생활에서 맥락을 통해서 오전인지 오후인지 알 수 있는 경우가 대부분이라 평상시에 오전 오후를 생략해도 우리가 생활하는데 지장은 없습니다. 한 위 표에서는 그래프가 같이 있고 맥락상 오전 오후를 예측할 수 있어서 오전오후 표시는 간결하게 표시하였습니다.

또 시간은 개개인의 시간개념이 시간이라는 심볼에 맵핑됩니다. 오후 6:30 분이라는 시간을 들었을때 겨울철에 날은 얼마나 어둑해지는지 해가 지고 얼마나 쌀쌀해지는지, 배가 출출해질 때인지 무한도전 봐야할 시간인지 등 다양한 경험이 바로 연상 되지만 18:30에는 바로 맵핑이 되어 있지 않습니다. 군대처럼 모든 구성원이 24시간제를 쓰도록 강제되어 익숙해진 상황이 아니라면요. 24시간제를 사용하면 오전 오후에 대한 혼동이 줄게 되지만 일상적으로 사용하는 시간에 대한 경험의 연상을 잃게 됩니다. 우리가 외국어를 배울때 apple을 사과라고 말을 외우는게 아니라 정말 사과에 대한 표현에 있어서 24시간제는 leading zero가 붙어서 보기 좋게 정렬이 되는데 12시간제로 표시할때는 정렬을 맞추기 위해서 주의가 필요합니다. 저는 오른쪽 정렬 대신 opacity가 0인 투명한 0을 붙여주는 꼼수를 사용했습니다.
redesign by 無異
비교에는 선형적인 시간축 그래프가 좋긴하지만 그래서 다시 몇시부터 몇시까지 인지를 직관적으로 아는데는 방학 시간계획표처럼 아날로그 시계판에 표시하면 좋지 않을까 하는 생각이 들었습니다. 그래서 그려봤는데, 썩 좋지는 않네요. 주간과 야간을 색으로 구분해봤는데 별 도움이 되지 않는 것 같습니다. 파이가 별로여서 도넛으로도 그려봤는데 그것도 별로네요. 망했어요.

* 국내 스키 리조트 홈페이지의 리프트권 표시 방식이 모두 똑같다고 했는데 사실 모두 그런건 아닙니다. 곤지암 리조트는 리프트권의 시간이 정해져있는 방식이 아니라 me-time pass 라고 원하는 시간에 원하는 시간만큼 탈 수 있도록 시간권을 판매하여 이런 복잡한 시간표가 아예 필요없습니다. 서비스 디자인 측면에서는 이런게 더 좋은 해결이라고 할 수 있겠습니다.


2. 셔틀 버스는 얼마나 기다려야 오는거야?

대절한 버스를 타고 학회장인 호텔에 우선 내렸는데 제가 들으려던 강의까지는 시간이 꽤 남았습니다. 셔틀을 타고 숙소인 콘도로 가서 잠깐 쉬고 올까싶어 홈페이지에서 셔틀 시간표를 찾아보았습니다.

여기서 문제. 현 위치는 강원랜드 호텔이고 숙소는 마운틴 콘도 F 동, 현재 시간은 12 시입니다. 2시 강의를 듣기 위해 돌아와야 한다면 숙소에서 얼마나 쉴 수 있을까요? 차라리 그냥 기다리는게 좋을까요? **

셔틀버스 시간표 - 출처: 하이원 홈페이지
셔틀버스 시간표를 이용하는 주요 use case는 다음 세가지일 것 같은데, 이 세 가지를 한꺼번에 확인해야 하는 아주 피곤한 경우였습니다.
1. 현재, 현 위치에서 셔틀을 타려면 얼마나 기다려야하나? (언제 오나?)
2. 목적지까지 가는데 시간이 얼마나 걸리나?
3. 특정 시간까지 목적지에 도착하려면 언제 셔틀을 타야하나?

셔틀은 얼마나 자주 다니는 걸까?

사실 1 과 3 은 좀 특수한 경우고 보통은 대충 몇시쯤 정류장에 나가면 될지 주변 시간대의 배차 간격을 확인하게 됩니다. 셔틀이 자주 오면 빡빡하게 시간 맞춰서 움직일 필요가 없으니까요. 저 표를 보고 어떤 시간대에 셔틀이 자주 오고 어떤 시간대는 많이 기다려야 하는지 배차 간격을 바로 알기는 어렵습니다. 위와 같은 표는 숫자를 빽빽하게 적어서 정보효율이 높은 것 같지만 표를 이용하는 맥락에서 중요한 정보인 내가 셔틀을 이용할 시간대에 얼마나 빈번하게 운행을 하는지는 바로 알기 어렵습니다. 이런 정보를 드러내 보이려면 표보다는 시간을 축으로한 그래프를 그리는게 좋습니다.
Edward Tufte - The Visual Display of Quantitative Information
이런 운행 시간표 그래프의 가장 인상적인 예가 Edward Tufte 의 The Visual Display of Quantitative Information 의 표지에 실려있습니다. 빨간선이 난잡하게 그어진 추상화처럼 보이는 그래프는 사실 열차시간표입니다. 그래프의 레이블이 생략되어 있는데, 가로축이 시간 이고(아마 48 칸-30 분 간격 일거에요) 세로축이 정차역입니다. 예를 들어 맨 윗쪽은 서울역, 맨 아래는 부산역이라고 하면 그 사이에 천안, 대전, 대구, 밀양 같은 중간 정차역들입니다. 왼쪽에서 오른쪽으로 내려오는 사선은 하행선 열차이고 반대로 그어진 선은 상행선 열차입니다. 선의 기울기가 조금씩 다른데 기울기가 열차의 속도를 나타냅니다. 완행 열차는 모든 역에서 선이 끊겨있고(정차시간만큼) 급행열차는 일부 역은 그냥 지나칩니다. 굵고 진하게 그려진 선이 몇 개 있는데 이건 다른 선들보다 기울기가 급하죠. 특급열차입니다. 하행선은 하루에 4편만 편성되어 있는데 1시 3시 사이에 3편이 몰려 있습니다.


원래의 셔틀 시간표 그대로 세로를 시간축으로 하여 그래프로 옮기면 위와 같은 모습이 됩니다. 왕복 노선을 한번에 그리니까 정신이 없네요.
redesign by 無異
정류장과 시간 축을 바꾸고 왕복 노선을 분리했습니다. 세로축의 정류장 간의 간격을 운행 시간에 비례하게 조정하여 일직선이 되도록 했습니다. 셔틀은 아마도 일정한 속도로 운행할테니까요. 그렇게 하니 그래프의 정류장 간격으로 실제 지리적인 거리를 가늠할 수 있습니다. 구불구불한 꺽은선이 반듯하게 단순화되니 불필요한 노이즈가 사라져서 배차간격이라는 정보도 더 잘 드러납니다. 표에서는 알기 어려웠지만 그래프로 보면 시간대에 따라 배차 간격이 다르고 상행과 하행의 운행 패턴도 차이가 있다는걸 바로 알 수 있습니다.

어느 방면인지 쉽게 알 수 있게 하기

하이원 호텔에서 스키하우스로 돌아가는 노선은 표의 운행 순서를 반대로 뒤집어 그렸습니다. 원래대로 그리는면 사선의 방향이 나란해서 사실 더 예뻐보입니다. 나란해야 보기에도 좋고 마음도 평안을 찾습니다. 눈에 거슬리지만 뒤집었는데요. 셔틀이 하이원 호텔을 반환점으로 왕복으로 운행하기 때문에 표에는 같은 정류장이 두번씩 나옵니다. 그래서 처음 표에서는 어느 방면으로 가는 것인지 확인하는것에서 부터 헷갈렸습니다. 그런데 셔틀을 직접 타보면 산길을 따라가는 노선이라서 스키하우스 쪽로 올라가는지 아니면 내려가는지 지리적 위치에 따라 방면에 대한 맵핑이 자연스럽게 생기게 되더라구요. 그래서 내려가는지 올라가는지 방면을 사선의 방향으로 실제와 같이 반영하고 둘의 구분이 도드라지도록 했습니다. 어느 방면인지 확실하면 정류장을 하나하나 찾지 않아도 탐색 범위가 반으로 줄어드니까 원하는 정보를 찾기 수월해지겠죠.

정보가 아닌 요소를 덜어내어 data ink ratio 높이기

그래프에서 축의 그리드는 직접 정보를 담고 있는 것이 아니라 데이타를 보조해주는 말그대로 보조선이니까 실제 데이타를 방해하지 않게 가급적 없애거나 덜 도드라지게하는게 좋습니다. 터프티 책의 기차시간표처럼 실 데이타라인이 직선인 경우에는 보조선을 가늘고 옅게 하더라도 형태적으로 유사한 반듯한 선들이 겹치게 되어 복잡해 보일 수 있습니다. 주 정보를 도드라지게 대비를 높이려면 보조적인 정보는 가급적 다른 전주의처리 요소를 사용하는게 좋습니다. 시간 구분은 데이타를 읽는데 도움을 주므로 없애는 것보다는 이렇게 선 대신 면으로 구분하는게 좋을 것 같습니다. 30 분 간격의 보조선은 배경과 같은색으로 선이 추가된게 아니라 면이 나뉘도록 해서 복잡한 요소가 더해지지 않아 보이도록 했습니다. 대신 정류장을 구분하는 보조선은 각각의 포인트를 찍어주는 것에 비해 요소를 많이 줄일 수 있어서 사용하는게 더 효율적인 선택인 것 같고요.

목적에 따라 표와 그래프 선택하기

그래프로 그렸을때 숨겨져있던 정보들이 시각적으로 드러나긴했지만 그대신 가장 중요한 도착 시각을 잃었습니다. 특정한 목적에는 적합하겠지만 일반적으로 셔틀을 타기위한 맥락에 적합한 표현 방식은 아닐 것 같습니다. 물론 클릭하거나 현위치, 현재 시간을 자동으로 반영해서 시간을 표시하게 할 수도 있겠지만요. 하지만 전 가급적 인터랙션이 없는 걸 선호하거든요. 종이에 프린트를 해야 한다든지 해서 매체가 인터랙션을 지원하지 않을 수도 있고요.

redesign by 無異
그래서 시간표의 각 시간을 실제 시간에 해당하는 위치로 옮겨보았습니다. 시간도 바로 읽을 수 있고 배차 간격이라는 감추어진 정보도 드러날 수 있도록요. 똑바로 빽빽히 나열된 행을 좇아가다보면 오히려 헷갈릴 수 있는데 여백이 적당하게 또 불균등하게 있어서 굳이 그리드로 구분하지 않아도 뇌는 연속된 관계로 잘 인식 할 수 있습니다.여기에서 기존의 표와 시간축이 적용된 표를 전환해가며 비교해 볼 수 있습니다.
원래의 표에서는 반환점도 하나의 여정으로 쭉 이어서 표를 그렸는데요. 이건 셔틀을 운전해서 반환점을 돌아와야하는 기사에게 의미가 있지 버스를 타려는 사람에게는 혼란만 주게 됩니다. 이 혼란을 줄여보려고 (마운틴 스키하우스 ⇄ 하이원호텔  ⇄ 마운틴 스키하우스) 같은 표시를 하거나 (출발 → → → 도착) 같은 불필요한 설명을 표에 덧붙이다보니 오히려 더 복잡해집니다. 근본적인 해결은 방면에 따라 표를 분리하는 것입니다. 방면을 쉽게 구분할 수 있도로 오르막과 내리막으로 표시하고 주요 정류장을 표의 헤더에서 강조하여 쉽게 찾을 수 있게 했습니다.

표에 적합한 숫자 글꼴

표에는 text figure 인 Merriweather Sans 를 사용했습니다. text(lower) figure 는 소문자 알파벳처럼 높이나 위치가 달라서(전주의처리) 숫자 각각의 인지가 쉽고 모여있을때 리듬감이 생겨 덜 단조로워 보입니다. 한글에서는 대부분 한글자체가 네모꼴에 맞추어져있고 숫자도 그에 어울리게 같은 높이로 그리다보니 이런 숫자 글꼴이 잘 사용되지는 않습니다. 숫자가 보조적인 정보로 쓰일 경우에는 너무 튀지 않고 무난한 lining figure(같은 높이) 를 사용하는게 좋겠지만 자체로 중요한 정보라면 lower figure 를 사용하는것도 좋습니다. 다만 시간은 자릿수가 중요하니까 각자리의 위치가 정렬이 되어야 보기편한데, text figure 는 대부분 고정폭이 아닌 유동폭 글꼴이라 정렬이 안되는 문제가 있습니다.
** 나중에 알고 보니 학회기간 동안 셔틀을 증편 운행하여 시간표와 상관없이 배차 간격이 짧았습니다. 시간표는 별 의미가 없었습니다. :)


3. 학회 시간표에 누락된 정보는 무엇일까?

마지막은 예상 하셨듯이 학회 시간표입니다. 이런 학술대회의 시간표는 언제 어디에서 어떤 강연을 하는지가 필수적인 정보입니다. 한 강연을 듣는다는건 같은 시간의 다른 강연을 못 듣게 되는 것이니까 비교도 잘 할 수 있어야합니다. 표를 효율적으로 만들려면 가로축의 장소(강연장)에는 많은 정보를 넣지 못하니까 아래 그림처럼 별도로 발표장 지도를 제공합니다. 두개의 독립된 정보를 join 해서 찾아봐야 하죠. 저도 이번에 강연장을 못 찾아서 헤맸습니다. 호텔이 경사지에 지어져서 지상 입구로 들어오면 당연히 1층인 줄 알았는데 2층인가 3층이더라구요.

사진 출처 - HCI학회 페이스북
사실 제가 관심있는 부분은 현재의 학회 시간표 정보를 어떻게 효과적으로 표현할 수 있을까가 아니라 소통의 채널로서의 시간표입니다. 나와 공통의 관심사를 가지고 또 보다 구체적으로 같은 주제의 강연을 들으려는 사람들이 같은 시간에 같은 공간에 모이는 경우는 굉장히 드문 기회거든요. 강연을 듣고 몇분의 질문답변 시간을 가진 후 다시 뿔뿔이 흩어지는건 아깝다는 생각이 들었습니다. 시간표의 강연 한 칸 한 칸이 하나의 게시판 또는 대화방이 되어서 학회 전부터 어떤 정보를 얻고 싶은지 의견을 나누고 배경이 되는 지식을 공유하고, 또 강연이 끝나고 나서도 발표 자료를 공유하고, 궁금한 점들을 서로가 묻고 답하는 공간이 되면 멋지지 않을까 하는 생각을 했습니다. 실제로 SxSW 같은 대규모 컨퍼런스 같은 경우는 자체의 앱에서 이런 기능을 제공하고 있고요. 저희 LeanUX lab 에서는 요즘 이런 문제 제기에서 접근한 학회 시간표의 리디자인을 개발을 해보고 있습니다. 내 친구들은 어떤 강연을 듣는지 알 수 있고, 강연에 관련된 주제의 정보를 함께 강연을 들을 사람들과 함께 공유할 수 있으면 재밌지 않을까요? 학회만이 아니라 공연에서는 팬들과 뮤지션이 소통하는 공간이 될 수도 있겠고요.

시간을 공간에 펼쳐 놓기

원래의 표나 그래프를 이용하는 방법이나 전달되는 정보 자체는 동일합니다. 하지만 분명히 더 잘 설명해줄 방법이 있을텐데 자기가 편하고 익숙한 방법만을 강요하는 같아서 불친절하다는 느낌을 받습니다. 사용 맥락을 고려하여 시간 정보를 적절히 공간에 시각화하면 사용자가 정보를 해석하는 과정을 줄여 정보 소비를 좀 더 수월하게 해 줍니다. 익숙하게 사용하고 있는 다른 표들도 이용하는 맥락에서 정말 최선의 표현인지 깐깐하게 다시 돌아보면 좋겠습니다.

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

팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 7
Ad Test...
2012.07.03 07:06

[정보디자인] 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” 라고 합니다. 의외로 이런 패턴이 많이 사용되고 있는데요. 몇가지 사례를 살펴보겠습니다.




길찾기

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

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

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

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


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


lazy 길찾기 by 무이


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

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


애플  iOS6 지도앱



 

항공권 가격 비교

국내 항공권 비교 사이트는 대부분 항공사와 가격 위주로 정보를 표시하는 것 같습니다. 하지만 실제 여행 계획을 세우려면 출발 시간과 도착시간, 경유를 하는 경우에는 기다리는 시간이 얼마나 되는지 확인해야 합니다. 싸다고 공항에 갖혀서 밤 새울 수는 없잖아요. 이런 비교에 필요한 중요 정보를 함께 표시하지 않으면 매번 상세 정보를 하나씩 하나씩 클릭해 봐야 합니다.
자세히 살펴 보니 여행자가 탈 수 있는 출도착 항공편에 따라 정렬 되는게 아니라 여행사가 보유한 출발편,도착편을 조합한 "상품"이 나열되어 있습니다. 상품과 가격이 중심이고 소비자의 여행 경험은 UI에 반영되어 있지 않아요. 국내 대부분의 항공권 비교 사이트가 이런식인 것 같습니다. 항공사 사이트를 주로 사용해서 몰랐는데 심각하네요. 

메타서치 엔진인 kayak은 출도착시간과 총 소요시간을 한번에 노출하여 비교할 수 있도록 합니다.
가격 외의 중요한 정보는 결국 출발,도착,비행시간, 경유 지연시간 등 결국 시간에 관한 것인데요. hipmunk는 타임라인을 이용한 그래프로 이런 정보들을 시각적으로 쉽게 인지하고 비교 할 수 있도록 합니다. 가격 비교도 다른 요소들이 방해하지 않게 한곳에 모아서 바로 비교가 되고 비행시간, 출도착 시간도 시각적으로 쉽게 비교됩니다. 타임라인에는 출발지와 도착지 현지 시간을 함께 표시하여 시차에 대한 고민없이 여행 계획을 세울 수 있고요. 자정과 정오를 숫자가 아니라 따로 표기하고 시간도 저녁과 새벽은 어둡게 낮은 밝게 표시는 등 소소한 디테일도 훌륭합니다.
추가로 국내 포털은 어떤가 싶어서 찾아봤는데요. 네이버는 손을 떼고 서비스를 종료했고요. 다음 여행의 항공권 비교 페이지는 "모든 주요 여행사의 가격비교를 한번에!"라는 모토로 여행사의 할인 항공권 정보를 모아서 보여 주고 있네요. 제휴 여행사의 할인 항공권 검색 결과를 긁어서 그냥 쭉 나열하는 메타 서치 형태인가봅니다.
왕권 항복권을 검색했더니 결과가 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 이 사용된 나쁜 사례가 있으면 제보해주세요.


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

팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 3
Ad Test...
2010.05.20 17:12

다음 모바일 초성검색 자동완성

휴대폰은 컴퓨터 키보드에 비해 입력 자체도 불편하고, 운전을 하거나 걷거나 가방을 들고 있거나해서 키입력이 어려운 사용 상황이 많습니다. 그래서 가능한 키입력을 최소화 할 수 있는 방법이 요구됩니다. 안드로이드의 영어나 일어의 음성인식은 상당히 만족도가 높다고 하는데 이렇게 아예 키입력을 하지 않는 방법이 가장 좋겠죠. 하지만 우리말에 대한 지원은 아직 요원할 것 같고 현재는 키입력을 최소화하도록 predictive input을 잘 활용하는 수 밖에 없을것 같습니다.

제 차에 있는 네비게이션은 실시간 교통정보를 받지 못하는 모델이라 네비에서 검색하고 또 아이폰으로 빠른길 검색을 다시 하는 경우가 많습니다. 그럴 때마다 네비게이션의 초성검색이 많이 아쉬웠습니다.

이번에 다음 모바일과 아이폰 앱에서 초성입력의 검색어 자동완성을 제공하기 시작했습니다. 주말에 다녀온 두 곳을 입력해봤는데요. 서울동물원은 아주 잘 찾아주네요. 너무 좋습니다.

 

 

의도한 검색어가 제공되지 않을 경우의 처리

하지만 "삼원가든 대치점"을 찾으려고 “ㅅㅇㄱㄷ"을 입력 해봤더니 검색빈도가 낮은지 자동완성에는 나타나지 않습니다. 초성입력 상태로 그냥 검색을 하면 전혀 원하지 않는 결과가 나옵니다. 의도한 검색어 자동추천이 나오지 않으면 초성검색어를 지우고 다시 입력하여야 합니다.

이러면 검색어를 입력할 때마다 찾으려는 검색어가 유명한지 한번 고민해봐야겠네요. 지우고 다시 입력해야하면 오히려 손이 더 귀찮아지니까요. 머리 쓰는 건 싫으니까 그냥 원래 하던 대로 음절로 입력을 해야 할까요? 많이 사용해보지 않아서 모르겠지만 의도한 추천어가 매칭되는 비율이 어느정도수준에 미치지 못하면 초성검색어 추천기능을 알고 있는 사용자라도 이 기능을 사용하지 않게 될 것 같습니다.

 


POI 초성검색결과 표시

간단한 해결로, 초성만으로 검색을 하면 네비게이션처럼 장소에 대해서 초성매칭결과를 지역별로 적당히 잘 그룹핑해서 나열해주면 좋을것 같습니다.(초성매칭이 되는 모든 검색어를 나열해주는 건 무리가 있고요. 지역정보를 모바일에서 많이 검색하고 또 DB가 한정되어 있어서 현실적으로 가능하니까요)  매칭결과를 단순히 가나다순으로 나열하여서 저처럼 서울에서만 노는 사람한테 부산지역 장소가 맨처음 표시되면 짜증나니까 현재 위치 정보를을 활용하면 좋겠고요.

 

초성+음절 혼합 검색

검색빈도가 낮아서 표시가 되지 않거나 매칭되는 결과가 많아서 순서에 밀리는 경우에도 문제가 되는데요. 초성+음절을 입력하면 전체 장소 DB매칭결과를 자동완성으로 보여주는 것도 좋겠습니다. "삼원가든"을 찾으려고 "ㅅㅇㄱㄷ"까지 입력했는데 자동완성으로 나오지 않으면 마지막 음절을 계속 입력합니다. "ㅅㅇㄱ든"으로 입력하면 매칭결과가 더 한정되니까 전체 DB에서 검색하여 자동완성에 표시해줍니다.

 

아이나비 초성+음절 혼합 검색

 

 

다음 지도 앱 연동

보통 위치 검색을 하고나서 길찾기를 하는 경우가 많은데요. 결과에서 링크된 모바일 지도 웹페이지에는 길찾기도 없고 기능이 제한되어 있어서 불편합니다. 그냥 다음지도 앱이 실행되면 좋을것 같습니다.

이 경우에 커스텀 url 프로토콜을 이용하면 웹 결과 페이지에서도 다음 지도 앱을 직접 실행할 수 있습니다. 페이스북 같은 경우는 http://가 아닌 fb:// 프로토콜을 사용하여 링크를 탭하면 페이스북 앱을 바로 실행하도록 하고 있고요.

http://iphonedevelopertips.com/cocoa/launching-your-own-application-via-a-custom-url-scheme.html

 

 

아니면 모바일 지도에서도 기본적인 길찾기 기능을 제공하는것도 방법이겠고요.

 

quickfind 길찾기


물론 처음부터 다음지도 앱으로 검색하면 되긴하는데요. 근데 맛집 검색할때는 블로그를 우선 보고 평이 괜찮은지 맛있는 메뉴는 뭔지 알아보고 찾아가는 편이라서 지도검색보다는 블로그 검색을 우선하거든요.

 

quickfind 검색


팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 2
Ad Test...
2010.03.24 13:06

아이폰 웹브라우저 페이지 전환 : adjacent in space

 

아이폰의 사파리 브라우저는 모바일 스크린에서 제대로 웹을 사용할 수 있는 최초의 브라우저라는데 큰 의미가 있습니다. 폰의 작은 화면에서 웹페이지를 보려면 화면의 확대 축소가 꼭 필요하게 되는데, 아이폰의 사파리는 축소한 경우에도 이미지와 폰트를 깔끔하고 읽기좋게 렌더링하여 보여줍니다. 직관적인 핀치 제스쳐나 더블탭을 이용한 자동 폭맞춤은 확대축소 조작의 번거로움을 없애주고요. 폭맞춤 상태에서 스크롤을 하면 옆으로 삐져나가지 않고 상하로만 움직이도록 보정해주는 특허도 작지만 실제 경험적으로는 상당히 편리하고요

 

carousel 방식의 사파리의 페이지 관리

사용 효율보다는 간결하고 학습이 쉽도록 하는 애플의 UI 철학에 공감은 하면서도 폰에서 웹브라우징을 많이하다보니 사파리의 페이지(탭 또는 창) 관리 방식은 불편합니다. 하단 툴바 오른쪽의 페이지버튼을 누르면 화면이 줌아웃되면서 현재 열려있는 페이지들을 선택하는 모드가 됩니다. 이런 UI 디자인 패턴을 carousel 이라고 하는데 여러 요소를 보여주어야 하나 공간이 부족한 경우에 회전목마처럼 돌려가면서 보도록 하는 것이지요. 다른 페이지를 선택하기위해서는 한페이지씩 원하는 페이지가 나올때까지 넘기고 나서 다시 한번 tap해주어야 합니다.

검색에서 새창을 열도록 하면 다시 검색 결과 페이지로 돌아오기 위해서 이렇게 페이지 전환을 하는 경우가 빈번해서 많이 답답합니다.


 

 

오페라 미니의 페이지 전환 방식

https://www.youtube.com/watch?v=OpTCS3g-cBY&feature=player_embedded

 

이번에 아이폰용으로 발표된 오페라 미니는 페이지가 중첩되기는 하지만 한 화면에 보여서 따로 페이지를 넘기지 않아도 됩니다. 물론 썸네일 화면이 작고 제목이나 url을 표시못하는 트레이드오프는 있지만 사실 페이지를 선택하는데는 꼭 이미지가 크지 않아도 구분이 가능하거든요. 

또 오페라 미니는 전체 화면을 축소한 썸네일이 아니라 북마크에서 보이는것처럼 좌상단의 일부를 캡쳐하여 보여줍니다. 화면이 너무 작아져서 구분이 안될 수 있는 문제를 피하는거죠. 또 대부분 페이지가 좌상단에 로고를 넣거나 하여 아이덴티티 영역으로 사용하고 있기때문에 구분하는데 도움이 될것 같습니다.

새로운 페이지를 여는것도 사파리가 페이지버튼을 누른 후에 반대편에 새로운 페이지 버튼이 생기는것에 비해 바로 접근이 쉬운 위치에 생깁니다.

 

iPad의 페이지 관리

 

http://www.apple.com/ipad/features/safari.html

 

이번에 출시되는 ipad에서는 사파리의 페이지 관리가 그리드 형태로 바뀌어서 한번에 선택할 수 있게 되었습니다.

다만 새 페이지 열기가 맨 마지막에 표시되어 페이지 열린 수에 따라 항상 변하게 되는데 ipad에서는 툴바가 상단에 있어서 새페이지를 열기 위해서는 상단에 있는 페이지 버튼을 누르고 손을 많이 움직여줘야 하더라고요. 손목만 까딱하면 되는 마우스와는 달리 팔을 움직여야 하는 터치 태블릿에서는 새로운 스트레스증후군 http://en.wikipedia.org/wiki/Repetitive_strain_injury 이 나타날 수도 있을 것 같아요.

 

추가: 아이패드를 사용해보니까 아이폰에 비해서 편해지긴했지만 이 탭선택 모드로 들어가고 나오는것 자체가 짜증나더라구요. 예상대로 탭선택 버튼이 상단에(멀리) 작은 버튼으로 있어서 선택이 쉽지 않습니다. 탭선택 모드가 된 후에는 아래쪽에서 탭 썸네일을 선택해야해서 움직임이 많고요.


adjacent in space rather than stacked in time


edward tufte http://www.edwardtufte.com/ 는 항상 정보를 공간에 펼쳐놓는 것이 시간에 쌓아놓는 것 보다 좋다고 얘기합니다.

책에서는 정보요소간의 관계를 비교하고 컨텍스트를 이해하는데 있어 하나씩 하나씩 보기보다는 한꺼번에 보여주는것이 좋다는 의미로 쓰였지만 정보디자인 차원 말고도 불필요한 인터랙션을 줄여준다는 점에서 고려해볼 필요가 있습니다.

반복된 조작이 필요한 곳에서 이 원칙만 지켜지면 사용을 좀 더 편하게 할 수 있습니다. 그런데 의외로 꼭 필요하지 않은 경우에도 그냥 트렌드처럼 잘못된 디자인 패턴을 사용하는 경우가 많은 것 같습니다.

꼭 필요한 경우가 아닌데도 정보를 stacked in time 방식으로 잘못 사용된 경우가 또 어떤게 있을까요?

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


팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 0
Ad Test...