태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.


'Re-design!'에 해당되는 글 31건

  1. 2015.07.02 한국어 맞춤법/문법 검사기 리디자인 (14) by 無異
  2. 2015.06.15 정류장 맥락을 고려한 버스 노선도 리디자인 3/3 - 노선도 자동화 프로토타이핑 by 無異
  3. 2015.03.11 정류장 맥락을 고려한 버스 노선도 디자인 2/3 –버스 노선도 Redesign 과정과 결론 by 허 지민
  4. 2015.03.10 정류장 맥락을 고려한 버스 노선도 디자인 1/3 – 해외 버스 노선도 사례와 특징 by 허 지민
  5. 2014.10.07 무이단모음 키보드 (구글단모음 키보드 리디자인) (28) by 無異
  6. 2014.10.02 [정보디자인] 한글 자소 빈도와 키보드 히트맵 by 無異
  7. 2014.09.22 [정보디자인] 정보 소비 맥락을 고려한 시간표 리디자인 (7) by 無異
  8. 2013.05.21 [정보디자인] 에드워드 터프티를 위한 날씨앱 (37) by 無異
  9. 2012.11.19 [정보디자인] 버스 도착, 노선 운행 정보 (9) by 無異
  10. 2012.07.13 [openUI] Lazy touch scroll 오픈 소스 UI (5) by 無異
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...
2015.06.15 07:50

정류장 맥락을 고려한 버스 노선도 리디자인 3/3 - 노선도 자동화 프로토타이핑

맥락 없는 디자인

사용자와 사용 맥락을 이해하는 것은 UX뿐 아니라 모든 디자인에서 꼭 필요한 과정입니다. 정보를 시각화한 정보디자인의 경우 정보가 여러 겹으로 부호화되어 있어 글처럼 차례로 읽히지 않습니다. 정보 밀도가 높아 다양한 방식으로 읽힐 수 있는 건 좋지만, 사용 맥락에 따라 정보를 쉽게 찾아가도록 흐름을 만들어주어야 합니다. 네가 뭘 좋아할지 몰라서 다 넣어 보면 항상 실패합니다. 맥락을 모르고 이야기하는 사람과 대화하면 답답합니다.


그림1 - 개인이 현 위치 스티커를 붙여 놓은 현행 서울 버스 노선도


일상에서 매일 만나는 정보디자인인 버스 정류장의 노선도는 이런 맥락 없는 디자인으로 우리를 피곤하게 합니다. 같은 버스 노선도라도 정류장에서 볼 때, 버스를 타고 가면서 볼 때, 인터넷으로 찾아볼 때의 맥락이 각기 다릅니다. 버스 정류장에서 노선도를 확인할 땐 '내가 여기'에서 버스를 타고 원하는 목적지에 갈 수 있는지를 확인하고 싶은 거지, '버스'가 어디에서부터 와서 어디까지 가는지 서사적인 여정이 궁금한 게 아니거든요. '버스'만 있고 '내가 여기'라는 맥락이 빠져있는 디자인이라 우리를 불편하게 합니다. 현 위치에 빨간 화살표 스티커를 붙여 맥락을 부여하는 작은 차이만으로도 인지 부담이 많이 줄어듭니다.


그럼 왜 처음부터 이런 맥락을 반영한 디자인의 노선도를 제공하지 않는 걸까요? 돈이 드니까요. 인쇄와 컬러 출력의 차이보다 정류장마다 다른 노선도를 하나씩 그리려면 몇 배의 비용이 들 테니까요. 제가 타는 버스만 해도 정류장이 98개인데 많게는 159개도 있습니다. 현실에서 고려해야 할 많은 다른 요인들이 있기 때문에 디자인만 좋다고 채택하지는 못 합니다. 사실 그런 장애 요인들을 고려하지 못한 디자인은 좋은 디자인(해결)이라고 할 수 없습니다.


맥락을 고려한 버스 정류장 노선도는 현실을 고려하지 못한 이상일 뿐일까요? 앞의 글에서 예고했듯이 비용의 문제는 사람이 그리는 게 아니라 자동화함으로써 해결할 수 있습니다. 정부와 지자체의 공공 정보 공유 시책에 따라 버스와 같은 대중교통 정보들이 제공되면서 이런 디자인을 자동화(프로그래밍)하는 것이 더 수월해졌습니다. 리디자인 과정에서부터 실제 노선 데이타를 적용하여 테스트했던 워킹 프로토타입을 소개합니다.



특허출원 관계로 글이 늦어졌습니다. 아래글을 함께 읽어주세요.




불필요한 부분 덜어내기

정보를 디자인할 때 뭔가를 더 집어넣기 전에 불필요한 것을 덜어내는 것이 중요합니다. 내가 여기에서 어디로 가는가가 중요한 맥락에서 버스가 여기까지 어떻게 왔는지는 보다 더 중요한 정보를 방해하는 노이즈입니다. 전체 구간에서 화살표로 내가 어디인지, 어느 방향으로 가는지 표시하는 것보다 그냥 현 위치부터 시작하면 인지 비용이 훨씬 줄어듭니다. 어떤 구간은 왼쪽으로, 어떤 구간은 오른쪽으로 진행하는지 고민할 필요가 없습니다.


노선도 리디자인 - 그림1과 같은 노선 정보. 실 이용 구간만 펼쳐서 표시

문제는 어디까지 표시할지 입니다. 단순히 현 위치에서 종점까지 표시하면 반환점을 되돌아오는 구간이 중복되어, 이 역시 노이즈가 됩니다. 그렇다고 기계적으로 반환점까지만 표시하는 것도 문제가 되는데요. 버스 노선이 반환점을 바로 U턴해서 도는 게 아니라 반환점 주변을 크게 돌아 경로가 다른 경우가 많습니다. 같은 길을 되돌아오면 반환점 부근에서는 타려는 승객이 적어질 테니 이용이 많은 경로로 반환 경로를 정하는 게 유리합니다. 그래서인지 지하철역을 끼고 도는 경우가 많습니다.


지리적으로는 멀리돌아 가는 것이지만 승객 입장에서는 같은 길을 되돌아오는 것은 아니어서 충분히 이용할 수 있습니다. 조금 돌아가지만 내려서 갈아타거나 걸어가기 귀찮으니까요. 노선도 상에서는 어디까지 표시할지 애매하지만, 지도 위에 그려보면 되돌아서 기하학적으로 폐곡선이 되는 지점까지 표시해주는 게 합리적입니다.

위 노선에서 노선표가 제공하는 반환점 정보는 이수중학교이지만 사람들은 내방역까지 타고 가기도 합니다. 오갈 때의 경로가 달라 복선으로 표시된 구간이 사용자 인터뷰에서 공통으로 혼동을 주는 문제로 지적되었는데요. 이렇게 현 정류장에서 승객이 실제 이용할 구간만을 일렬로 펼쳐서 표시하면 혼동을 줄일 수 있습니다.


정보 덩어리 짓기

기존의 노선도에서는 각각의 버스 정류장 이름이 같은 형태로 반복되어 있어 어디에서 뭘 찾아야 할지 많이 어려워합니다. 목적지를 확인하려면 하나하나 찾아봐야 합니다. 지하철 역 정도가 강조색과 픽토그램을 사용해서, 지하철역 같은 주요 정류장을 우선 찾고 그 주변을 찾아보는 탐색 전략을 취하기도 합니다. 

정류장을 행정구역별로 덩어리로 묶어주면 상관없는 정류장을 빨리 제거해나가 좀 더 수월하게 찾을 수 있습니다. 분당처럼 시외로 가는 경우에 서울은 볼 필요도 없으니까요. 청크의 구분은 2단계로 나누었는데요. 광역 버스인 경우는 시 단위로 구분이 적절하고 지선이나 간선의 경우에는 동 단위로 좀 더 세밀한 구분을 제공하는 것이 유용하다는 피드백을 얻었습니다.

시나 구의 큰 단위는 묶음 기호로 구분하는 것뿐 아니라 정류장 사이에 여백을 두어 시각적으로 나뉘어 보이도록 하는 게 더 효과적이었습니다.




그 다리 위를 건너가는 기분을

버스를 타고 지나면서는 행정구역은 인식하지 못하지만, 강이나 고속도로를 지나는 지리 정보는 잘 기억합니다. 그 외는 다 똑같은 건물에 같은 길이라서 그게 그것 같으니까요. 강(다리)으로 노선을 구분해서 강남으로 가는지 강북으로 가는지 힌트만으로도 행선지를 이해하는 데 많은 도움이 됩니다.

노선도 정보에서는 제공되지 않지만, 서울의 경우 행정구역이 강을 따라서 나뉘기 때문에 인접한 두 정류장이 강북, 강남으로 바뀌면 한강을 건넌다는 것을 간단히 프로그램으로 알 수 있습니다. (버스 API 정류장 정보에 행정구역 정보가 포함되어 있습니다) 주변 정류장 이름으로 어느 다리를 건너는지도 추측할 수 있습니다. 선유도를 지나면 양화대교, 노들역을 지나면 한강대교를 지납니다. 마포대교남단 정류장을 지나면 당연히 마포대교를 건너겠지요.

시외로 가는 경우에 고속도로를 지나는 것도 중요한 정보입니다. 정류장 간 거리가 충분히 큰 경우에 고속도로나 도시고속도로를 타고 지나는 걸 알 수 있습니다.


랜드마크

분류를 위한 덩어리가 아니어도 같은 형태가 반복되면 어디까지 보고 있는지 신경을 써야 해서 피곤합니다. 기준이 되는 시각적인 이정표를 제공하는 게 도움이 됩니다. 사람들이 많이 찾는 정류장을 두드러지게 강조하면 그 정류장뿐 아니라 다른 덜 중요한 정류장을 찾아보는 데도 도움이 됩니다. 

우선 지하철역을 강조할 필요가 있습니다. 지하철로 갈아타기 위해 버스를 타는 경우도 많고, 지하철역은 대략의 위치를 잘 알고 있기 때문에 랜드마크로 활용됩니다. 현재는 비용 문제로 2도 인쇄로 지하철역 이름만을 강조하고 있는데요. 단지 지하철로 갈아타기보다는 특정 노선을 타려는 경우가 많으므로 지하철 노선의 고유색을 강조해 보여주는 게 더 효과적입니다. 


그 외 사람들이 기억하는 주요 랜드마크는 공공기관이나 대형 마트 등이었습니다. 학교 같은 공공장소는 자신의 목적지 부근만 기억하고 그 외는 잘 기억하지 못하는 것 같습니다.

사람들이 많이 타고 내리는 정류장도 잘 기억합니다. 빈자리가 날 확률이 높으니까요. 정류장에 많은 버스가 정차하면 사람들이 많이 이용하는 정류장일 가능성이 큽니다. 개별 버스의 평균 배차간격을 반영하여 특정 정류장에 시간당 몇 대의 버스가 오는지를 계산하면 이용률이 높은 정류장을 추정할 수 있습니다. 그런 중요 정류장을 볼드 표시하는 방법을 사용할 수 있습니다.


예상 소요 시간

정류장별 노선도를 개별적으로 그리게 되면 정류장별 예상 시간을 표시할 수 있습니다. 교통 상황에 따라 다를 수 있지만 대략 가늠할 수 있는 정보가 제공되는 것으로 도움이 많이 됩니다. 현재는 기점의 출발시각을 표기하고 있어서 별 도움이 되지 못하는 첫차, 막차 시간도 현 정류장의 실 도착시각으로 표기하면 유용할 수 있을 것입니다.

프로토타입에서는 꼼수를 이용해서 소요시간을 계산했는데 실 데이타 로그를 분석하면 평균 시간을 반영하여 표시할 수 있습니다. 인터넷에서 제공하는 버스 노선도에서는 시간별로 평균 소요시간을 제공할 수도 있을 것 같습니다. 다음, 네이버에서 제공해주면 좋겠습니다.


길 찾기가 아닌 위치와 경로 표시를 위한 지도

지도 위에 운행 경로를 표시한 간소 지도가 유용하다는 피드백을 많이 받았습니다. 글자로 쓰여 있는 것보다 지도에 표시되면 훨씬 쉽게 경로를 이해 할 수 있으니까요. 또 미니맵에서는 전체 경로를 옅은 색으로 표시하여 이전 정류장 노선을 없앤 것을 보완할 수 있습니다.


지도 API를 사용하면 소축척지도에서는 고속도로가 복잡하게 얽혀있어 정작 실제 경로는 잘 보이지 않고 지형이나 행정구역을 파악하기도 어렵습니다. 지도의 맥락이 운전자의 길 찾기에 맞추어져 있기 때문인데요. 내가 운전하는 것도 아니니 길은 별로 관심 없거든요. 대축척에서는 길이 블럭을 나누어 위치를 파악하는 데 중요한 정보이지만 소축척에서는 필요치 않은 경우도 많습니다. 여행지도를 만든다든지 할 때에도 내가 어디를 갔었는지가 중요하지 길이 중요한 건 아니니까 이렇게 고속도로가 지형을 울룩불룩 뒤덮은 지도가 아닌 간소화 지도가 제공되는 게 좋습니다. 프로토타입에서는 지형과 행정구역만을 단순화한 지도를 직접 그려서 사용했습니다.


내비게이션 용도를 우선한 소축척 지도



위치와 경로 표시에 적합한 간소화 소축척 지도 (다음지도에 오버레이 맵 사용)


노선도 간의 정렬

가로 형태의 노선도는 공간 제약으로 정류장 명을 기울여 써야 해서 읽기가 어렵습니다. 세로 형태의 목록을 사용하면 이름이 정렬되어 쭉 읽어나가기 수월합니다. 또 개별 노선도에서뿐 아니라 정류장에는 많은 노선도가 같이 붙어 있으니 함께 모여있을 때 보기 좋은 배치도 고려되어야 합니다. 현재의 그리드 형태의 배열보다는 한 줄로 나열된 형태가 시선의 이동이 줄어 더 보기 편합니다. 

그래서 세로 배열을 같이 실험해보았습니다. 세로로 나열하면 이름을 왼쪽 정렬하고 픽토그램을 노선 왼쪽에 붙여서 더욱 깔끔하게 정리할 수 있습니다. 가로로 기울여 쓴 것에 비해서 줄 간격을 줄여도 정류장 이름을 읽는 데 많이 불편하지 않기 때문에 공간 활용이 더 효율적입니다. 정류장이 늘어나면 줄 간격을 조절하여 노선도가 너무 길어지는 것을 막을 수 있습니다.







정류장 운행 지도

개별 노선도와 별개로 정류장마다 버스 노선 지도를 추가할 수 있습니다. 이 지도를 통해서 현 위치에서 갈 수 있는 목적지를 한눈에 확인할 수 있습니다. 개별 노선도와 같이 현 정류장에서 실제로 이용할 정류장만을 표시해서 방사형의 경로가 나타나게 됩니다. 모든 노선을 한 번에 표시하도록 지도의 스케일을 정하면 근거리 노선의 경로들은 가까운 곳에 뭉쳐서 잘 구분이 안 될 수 있습니다. 이런 경우에 먼 곳까지 운행하는 광역버스와 지선,간선 버스를 나눠서 표시하면 조금 더 보기 수월해집니다.


모든 버스 경로가 현 정류장 한곳에서 뻗어 나가므로 겹치는 노선이 생겨 원점에 가까운 곳은 구분이 어려워집니다. 색상은 이미 노선 구분에 사용되고 있어 마음대로 사용하는데 제약이 있습니다. 버스 별로 명도와 채도에 변화를 주고 노선을 조금씩 어긋나게 하면 완전히 겹치는 것을 줄일 수 있습니다. 버스 번호 레이블을 표시하는 위치에 대해서도 여러 가지 실험을 해보았는데 경로의 말단에 표시하는 것이 가장 보기 편했습니다. 중간에 표시하면 겹치는 경우가 많으니까요. 번호표 표시 위치도 될 수 있으면 경로와 겹치지 않도록 좌상, 우상, 좌하, 우하 네 영역으로 나누어 진행 경로를 연장하는 방향으로 그려주는 등의 규칙을 적용하여 그려주도록 하였습니다.




모두를 이롭게 하는 디자인

모두가 만족하게 하려는 디자인은 모두에게 그다지 좋지 않은 디자인입니다. 공공디자인에서는 특히 소수자를 배려해야 한다는 생각에 소수의 유스케이스까지 모두 반영 하다 보면 모두를 괴롭게 합니다. 누가 왜 어떻게 사용하는지를 이해하고 가장 적합한 맥락에 맞게 디자인을 하는 게 더 많은 사람을 이롭게 합니다. 


디자인은 결과라기보다는 과정입니다. 맥락에 맞는 버스 노선도가 아이디어 차원이 아니라 실생활에 작은 도움이 될 수 있도록 지속해서 지원을 할 계획입니다. 현재 개발 버전에서는 다음,네이버의 지도 API와 서울시 버스 정보 API 등을 이용해서 수도권의 모든 정류장의 버스 노선도를 자동으로 생성하고 벡터로 출력할 수 있습니다. 교통시설과의 담당 부문과의 협조를 통해 새로 설치되는 버스셀터에 새로운 디자인의 버스 노선도를 시범 운영해보고 시민들의 의견을 받아 개선해 나가는 방향을 고려하고 있습니다. 기존의 인쇄 노선도를 대체하는 방법과 현재 참여하고 있는 TFD 과제와 협업하여 투명디스플레이를 활용한 버스 정보 안내 시스템에 적용이 가능할 것 같습니다. 이후에도 진행 과정을 공유하도록 하겠습니다.



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


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


Trackback 0 Comment 0
Ad Test...
2015.03.11 07:50

정류장 맥락을 고려한 버스 노선도 디자인 2/3 –버스 노선도 Redesign 과정과 결론

버스 노선도 Redesign 과정과 결론

이전 글에서는  해외의 사례들을 살펴봤는데요. 이번 글에서는 각 사례에서 적용 또는 참고할 수 있는 부분들을 활용하여 우리나라의 버스 노선도를 리디자인한 과정을 정리해봤습니다.

요즘에 버스 노선도를 보면 빨간 화살표 모양의 스티커를 종종 볼 수 있습니다. 놀랍게도 이는 담당 시청이 아닌 한 대학생 청년이 시작한 일이었는데요.
평소 버스 노선도에 현 위치와 방향 표시가 안 돼 있는 상황에 문제점을 느끼고 있었고, 이를 개선하기 위해 직접 스티커를 붙이고 다녔습니다. 기존의 노선도는 해당 정류장을 이용하는 사람들을 고려하지 않고 다 같은 디자인, 즉 정류장 명만 줄줄 써있는 노선도를 사용해서 문제가 됐는데 어떻게 보면 이 학생이 이 정류장을 이용객들을 위한 정류장 맞춤 화살표를 붙이고 다닌 겁니다.


그는 직접스티커 붙이기를 진행하면서 여러 문제점을 발견했다고 하는데요. 지금 있는 정류장의 위치(노선도 상에서)를 알 수 없고 순환 노선의 경우 방향을 전혀 알 수 없는 점이라던지 방향 표시가 없어 버스를 역방향으로 타는 등의 것들을 발견했습니다. 특히나 스마트폰을 잘 사용하지 않는 노인의 경우가 가장 쉽게 오류를 범했다고 합니다.

어쨌든, 아주 간단한 이 스티커 붙이기로 인해 많은 사람이 현재 위치와 버스의 진행 방향을 잘 알아볼 수 있게 되었고(특히 처음 가는 지역의 경우), 이 청년은 서울시장 표창까지 받았다고 합니다. 이는 실생활에서의 사용자 경험을 간단하게 잘 해결했다고 볼 수 있는 좋은 사례입니다. 

참고자료 http://www.hani.co.kr/arti/society/society_general/531141.html

1. 사용자 유스케이스를 파악하다


위의 사례처럼 현재 버스 노선도에는 아직 해결되지 않은 문제들이 아직 많이 남아있습니다.
이를 해결하기 위해서 먼저 현재 사용자들의 버스노선도 유스케이스(usecase)를 조사해봤습니다.

우선 가장 주목할 점은 스마트폰 보급으로 인해 버스 노선에 대해서 아무것도 모르는 상태로 노선도를 보는 경우는 별로 없다는 것입니다. 
즉 이미 자신의 목적지로 가는 버스를 한 개쯤은 대강 인지하고 온다는 건데요. 하지만 버스정류장에서 사람들을 관찰하다 보면 꽤 많은 사람들이 버스 노선도를 보는 걸 확인할 수 있습니다. 그래서 사람들이 굳이 왜 버스 노선도를 보는 것인지 설문조사를 통해 알아봤습니다.

조사 결과 사용자들이 버스노선도를 보는 이유는 두 가지였습니다.
첫 번째는 비슷한 노선의 버스를 찾기 위해서,
두 번째는 버스의 방향이 맞는지 확인하기 위해서였습니다.

즉 모바일로는 위의 두 요소를 충족시켜 주지 못해서 버스 노선도로 확인차 본다는 건데요. 여기서 문제는 막상 버스 노선도를 보고 확인하려 해도 비슷한 노선을 찾거나 방향을 확인하기 어렵다는 것입니다. 결국 버스 기사님이나 주위 사람들에게 물어보게 되는 시간 낭비를 하게 되는 것이죠. 

일단 가장 큰 문제는 주위 환경을 고려하지 않고 똑같이 노선도를 디자인한 부분입니다. 모든 노선도를 다 똑같이 디자인해 버려서 불필요한 정보들이 많고, 형식에 끼워 맞춰야 해서 오히려 보여야 할 정보들(버스 방향 등)이 빠져 있었습니다. 예를 들면 현재 148번 버스가 지나가는 정류장에는 똑같은 형태의 148번 노선도가 붙어 있는데요. 여기에는 현 위치와 버스 진행방향 같이 각 정류장마다 다르게 들어가야 하는 요소들이 빠져 있는 경우가 많은 반면, 이미 지나온 노선 같은 필요없는 부분은 모두 들어가 있습니다. 

결국은 정류장 별로 맞춰진 '정류장 맞춤형 노선도'가 제작되어야 현 문제들을 개선해 나갈 수 있을 것으로 보입니다. 예를 들면 첫차/막차 시간이 항상 기,종점 기준으로 되어 있어서 그 이외의 정류장에서는 거의 쓸모없는 정보나 다름없었는데 이런 부분을 해당 정류장에 맞게 하는 것처럼, 다 똑같이 구성되어 있는 버스 노선도 또한 각각의 상황에 맞게끔 디자인되어야 합니다. 

물론 모든 버스 정류장마다 노선도 디자인이 다르게 되어야 한다면 엄청난 시간과 비용이 들겠죠. 정류장 맞춤형 노선도가 제작되면 각 정류장마다 노선도 디자인을 해서 인쇄를 해야 하는 문제가 발생할 수 있는데, 이는 “노선도 어플리케이션”을 활용해서 해결할 것으로 기대됩니다. (pxd에서 현재 개발 중입니다.) 

2. 기존 버스노선도에서 하나하나씩 개선하다


2-1) 이전노선 지우기/ 지리정보, 노선 지도 추가 
그렇다면 버스노선도의 어떤 점을 개선해야 이런 요건들을 잘 충족시켜 사용자들이 보기 편한 디자인 할 수 있을까요?
우선 현재 있는 버스 노선도를 하나하나 개선해 가는 방식으로 시작했습니다. 가장 쓰기 좋은 버스 노선도 두 개를 선정하여 조금씩 개선해나가기로 했는데요. 

 

  가장 먼저 한 일은 현재 정류장 이전의 노선은 과감하게 지워버린 것입니다. 이전 정류장들이 줄줄이 있으면 복잡해지기만 하고 봐야 할 정보들을 보기 힘들기 때문이죠. 그리고 이렇게 함으로써 버스의 진행방향을 화살표와 함께 알려주게 됩니다.
그리고 왼쪽에 버스 경로를 간략하게 보여주는 ‘노선지도’로 대략적인 노선을 쉽게 볼 수 있어, 비슷한 노선을 찾기 위해 하나하나 노선도 위의 정류장 이름들을 읽지 않아도 됩니다.
또한 지리정보(고속도로, 한강, 다리 등)를 넣어서 사용자가 쉽게 그룹핑 하여 필요한 부분만 볼 수 있게 합니다. 한강으로 강남과 강북이 구분되는 것처럼 사람들에게 지리적 정보는 매우 큰 랜드마크가 됩니다. 즉 1005-1 에서 분당의 정류장들을 보기 위해 필요없는 서울쪽의 정류장들까지 봐야 했던 이전 노선도들과 달리 “경부고속도로” 뒤편만 보면 되도록 구성했습니다.

2-2) 지하철 강조/하단 행정구역 표시
위의 개선안에서 조금더 개선을 해봤습니다. 




 지하철역 정보가 좀더 눈에 띄도록 노선 위에 배치했습니다. 기존 노선도에는 정류장 이름 뒤에 지하철 아이콘이 표시돼 있는 정도여서 중요한 정보임에도 눈에 잘 들어오지 않았습니다. 갈아타기 위해 역을 찾는 사용자도 많지만, 굳이 갈아타지 않아도 지하철역이라는 것 자체가 기준점이 되어주기 때문에, 이를 기준으로 자신이 탈 버스를 구분하는 사용자들을 위해 잘 보이도록 개선했습니다. 

반대로 잘 보이지 않아도 되는 요소들(노선의 검은색 줄, 동그라미 표시 등)은 컬러를 조정하여 노이즈를 최대한 제거했습니다.

노선도 하단에는 행정구역(시, 구)을 나누어 빠르게 버스의 경로를 인지할 수 있도록 했습니다. 기존 노선도에선 정류장 정보가 다 똑같이 분포되어 있기 때문에 사용자가 원하는 정류장을 보려면 일일이 읽어봐야 했습니다. 그래서 크게 행정구역을 나눠 노선도를 보는 순서를 더 간소화하도록 했습니다.
비슷한 사례로는 전화번호부를 들 수 있는데요.

출처 http://wjsekswl.tistory.com/notice/63
원하는 곳의 번호를 찾기 위해선 다음과 같은 단계를 거칩니다. 먼저 ‘음식점’이라는 큰 카테고리를 찾은 후, 가나다순으로 정렬된 목록에서 ㅈ-ㅊ 을 찾아 들어갑니다. 이제 여기서 원하는 종류의 음식을 찾고 해당 음식을 파는 곳에 전화를 합니다. 
이 순서처럼 리디자인 노선도 또한 버스번호를 보고 노선지도로 대강의 노선을 확인하고 큰 행정구역을 확인한 뒤 해당 구역의 정류장들을 확인하는 순서로 구성되어 보다 빠르게 목적지를 찾을 수 있습니다.

2-3) 유사 노선 비교 
하지만 아직 비슷한 노선의 버스를 한눈에 보기에는 아쉬운 것 같아서 좌측에 런던의 노선도의 특징을 대입시켜봤습니다.(참조_정류장 맥락을 고려한 버스 노선도 디자인1 –해외 버스 노선도 사례와 특징)

 

 각자 가장 비슷한 노선을 가진 버스를 하나씩 골라 맵핑을 시켜봤는데, 강남역같이 버스가 50대 가까이 오는 큰 정류장의 경우 같은 노선이 너무 많아서 왼쪽 칸에 다 들어가지 못할 가능성이 크기 때문에 불가능할 것 같다는 결론을 내리게 됐습니다. (개인적으로 꼭 해결하고 싶었습니다...)

2-4) 긴 노선도 형태 변형 
어쨌든 여기까지 개선해 나가다가 큰 문제를 발견했는데요. 노선이 굉장히 긴 버스의 경우 노선도를 억지로 꺾어야 한다는 겁니다. 현재는 ⊃자 또는 ㄹ자로 꺾어져 있지만, 갑자기 오른쪽에서 왼쪽으로 읽어야 하는 등 그다지 좋지 않은 방법이 사용되고 있습니다.
그래서 반대로 읽지 않아도 되도록 디자인을 해보기로 했습니다. 



 아무리 봐도 이어진 노선이 아니라 다른 노선을 억지로 끼워놓은 것 같은 느낌이 강하게 들고, 일반 사용자들이 보면 전혀 못 알아볼 것처럼 디자인이 돼버렸습니다. 또한, 계속 디자인을 하면서 느꼈던 점은 글자를 억지로 기울여서 배치하다 보니 너무 복잡해 보이고 읽기가 쉽지 않다는 평가를 하고 이 부분을 빨리 개선하고자 했습니다.

3. 가로 형식을 탈피하고, 노선 지도를 따로 사용하다


3-1) 세로 형식/박스 그룹핑 
그래서 이번에는 가로 형식에 얽매이지 않고 세로로 디자인해 보기로 하였습니다.

 

 그리고 세로 버전을 만들면서 가장 만족스러웠던 점은 시선의 흐름이 자연스러워졌다는 점입니다. 버스번호와 노선 지도를 보고 나서 행정구역을 확인한 뒤 자세한 노선을 보도록 하여 시간 낭비를 최소화할 수 있게 구성됩니다.
그리고 좀 더 쉽게 비슷한 경로의 버스를 확인할 방법을 구상하다가 중복되는 노선의 파트들을 박스로 묶어보는 것은 어떨까 하고 넣어 봤는데요. 위 두 개의 버스가 모두 교육개발원입구까지 동일한 노선을 가지고 있고, 분당에서도 일부 겹치는 노선이 있는데 이를 회색 박스로 묶어봤습니다. 

하지만 여기서 또 다른 문제들이 보이기 시작했습니다.
노선도 상단의 노선 지도와 같은 구간을 묶어주는 박스의 역할이 겹친다는 것입니다. 둘 다 주요 구간을 빠르게 보여주어 비슷한 노선을 가진 버스를 쉽게 찾을 수 있도록 해주는 역할을 하고 있기 때문입니다.
그리고 노선 지도는 버스마다 지도의 축척이 달라 노선의 길고 짧음이 구분되지 않는 문제가 있었고, 박스는 겹치는 구간이 여러 곳이 있거나 다 다른데 한 부분만 겹치는 경우 등 여러 가지 변수가 많은 것을 볼 수 있습니다.
결국 나름 유사노선 버스 찾기의 해결책이라고 생각했던 노선 지도와 박스 묶기 둘 다 제대로 된 해결방안이 아니었다는 결론을 내리게 되었고, 다른 방법을 찾게 되었습니다.

3-2) 노선 지도 분리 
그렇다면 차라리 노선 지도를 따로 떼어내서 현재 정류장에 정차하는 모든 버스의 노선을 한 번에 보여주는 것이 훨씬 노선 비교도 잘 되고 보기 편하지 않을까? 라는 생각으로 이어져 노선지도와 박스를 없애고, 모든 노선을 지도상에 배치해보기로 했습니다.

 


남아있는 노선도에 학교나 관공서, 쇼핑센터 등은 해당 장소의 전후 지역을 잘 구분할 수 있으므로 정류장들의 왼쪽에 아이콘을 넣었습니다. 또한 현위치와 종점 형태를 지하철 노선 표시 모양과 다르게 해서 헛갈리지 않도록 했습니다.


3-3) 모든 노선을 지도에 맵핑 
떼어내기로 했던 노선 지도들은 해외의 지도형 노선도를 참고하여 만들기로 했고, 아예 정류장을 하나 정해서 그 정류장의 버스 노선들을 그려보기로 했습니다.


버스가 지나가는 곳에서 나름대로 주요 지점이라고 할 수 있는 기준점들을 그려 넣고 노선들을 그려봤습니다.
하지만 아무래도 광역버스와 일반 간선, 지선 버스들은 노선의 길이 차이가 많이 나기 때문에 짧은 노선들은 가운데 뭉쳐서 잘 보이지 않는 문제가 따라왔습니다. 그래서 아주 멀리 가는 광역버스와 짧은 거리를 가는 다른 버스를 따로 배치하는 것이 좋을 것 같다고 판단하였습니다.


복잡한 요소들은 대부분 다 제거하고 버스가 지나가는 부분에서 기준점이 되는 구간들만 표기했고, 행정구역을 좀더 명확히 표기했습니다. 축척이 다르다 보니 좀더 효과적으로 노선들을 표기할 수 있는 듯합니다.

결과적으로 노선도 위에 붙어있던 노선 지도들을 하나의 지도에 전체적으로 표현하니, 비슷한 경로를 가진 버스나 주요 위치(강남역 등)를 훨씬 효과적으로 볼 수 있게 된 것 같네요. 
비슷한 사례로는 지하철의 주변지역 안내도를 들 수 있습니다. 


출처 http://blog.daum.net/stopthewar/20
역 마다 이 안내도를 설치해서 해당 역의 지하철이 어느 방향으로 가는지 또는 근처에 뭐가 있는지를 대략적으로 알 수 있습니다. 지하철과 연계되는 버스정류장들도 보여서 효과적으로 교통 정보를 전달할 수 있게끔 되어 있네요. 단순히 지하철에 대한 정보로 끝나는 것이 아니라 주변 지역을 안내해 주기 때문에 유용하게 사용되고 있습니다. 

3-4) 사용자 관찰 
마지막으로 직접 버스정류장에 배치하고 사용자들의 반응과 생각을 관찰해 보기로 했습니다. 진행하면서 어려웠던 점은 버스 정류장이라는 장소 자체가 사이클이 빠른 곳이기 때문에 심층적인 인터뷰가 불가능했고 대부분 1, 2분 전후로 참여해 주셨습니다. 

 

가장 큰 장점으로 뽑혔던 것은 현 위치에서부터 시작하니 버스 방향을 헷갈릴 염려가 없겠다는 부분이었습니다. 사용자들도 굳이 필요없는 정보는 있어 봤자 오히려 혼란스럽기만 하다고 느끼고 있었습니다.


주목할 점은 대부분의 사용자는 버스 번호만 보고 지나간다는 사실을 발견했습니다. 거의 1-2초밖에 걸리지 않는데 그 이유는 자신이 타는 버스가 이 정류장에 오는지만 확인하기 때문입니다. (이런 사용자들은 대부분 익숙한 버스를 타면서 습관적으로 흘끗 보는 경우나, 이미 몇 번 버스를 타야 하는지 앱으로 확인하고 왔기 때문에 자세한 부분은 생략하는 것으로 보입니다. 대부분의 버스가 자주 오기 때문일 수도 있습니다.)

5. 최종 디자인안




이런 과정들을 거쳐서 최종 시안이 나왔습니다. 적용한 정류장은 신사사거리 버스정류장입니다.
노선 지도와 일반 노선도를 배치하는데요. 전체적인 노선들을 보며 비슷한 노선을 비교하기 편하게 노선 지도를 본 후 (대부분 익숙하지 않은 길이겠죠), 원하는 버스의 노선도를 찾아 빠르게 목적지를 확인/비교할 수 있도록 디자인 하였습니다.
이전과 바뀐 점은 전반적으로 사이즈를 키우고, 버스번호가 멀리서도 잘 보이게 사이즈를 키운 것입니다.
노선도 사이즈는 180x700(mm)입니다.


마치며

이렇게 정리를 해보니 기대를 충족한 부분도 있지만 한계점이 같이 보입니다. 과감하게 이전 노선을 지워버린 부분이 특히 그런데요. “정류장 맞춤 노선도”라는 타이틀을 가지고 필요없는 정보들을 없애 방향성과 간결함을 강조한 것은 장점으로 볼 수 있겠습니다. 하지만 전체적인 노선을 봐야 하거나 반대편 정류장으로 가야 할 경우가 발생할 수 있는데, 그런 경우 이전의 노선도가 보여야만 해당 정류장이 반대편에 있다는 사실을 인지할 수 있습니다. 리디자인한 것에서는 확인할 수가 없죠. 이 부분이 장점이면서도 때에따라 단점이 될 수도 있는 부분이라고 생각합니다. 

또한 가로 형식이 훨씬 익숙하고 공간 활용이 세로에 비해 잘 되는 점이 있습니다만, 시선의 흐름을 자연스럽게 하고 일자 형태로 노선을 유지하기 위해 세로 형태를 택하는 등 가져감과 동시에 포기해야 하는 부분들이 분명히 존재하고 있습니다. 이를 잘 저울질해서 적용한다면 많은 사용자들의 니즈를 충족시킬 수 있을 것이라 기대합니다.

마지막으로, 두 달 동안 이 프로젝트를 진행하면서 공공디자인이라는 분야가 정말 고려해야 될 것들이 많음을 새삼 느꼈습니다. 저 스스로 불편하다고 느꼈던 점들을 개선해가며 디자인할 수 있었다는 것은 정말 좋은 경험이었습니다. 

버스 노선도 디자인 3편에서는 '노선도 작성 자동화 프로토타이핑' 에 대해 소개해 드리도록 하겠습니다.

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




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


Trackback 0 Comment 0
Ad Test...
2015.03.10 07:50

정류장 맥락을 고려한 버스 노선도 디자인 1/3 – 해외 버스 노선도 사례와 특징

해외 버스 노선도 사례와 특징

이번 겨울 저는 pxd의 인턴으로서 입사하게 되었습니다. 인턴 생활을 하면서 버스 노선도 리디자인 프로젝트를 진행하게 되었는데요. 이번 글에서는 이 프로젝트의 리서치부분을 소개하려고 합니다.


이 프로젝트는 얼마 전 새로운 지역에 갔다가 집에 오는 길에 버스를 타려고 정류장에 있는 버스 노선도를 보며 내가 타야될 버스를 찾으면서 시작되었습니다.
그런데 항상 느끼는 점이지만 버스 진행 방향이 헛갈리고, 현재 정류장이 어디인지조차 찾기 힘들 정도로 노선도를 보기가 어렵다는 걸 다시 한번 느끼게 되었습니다. 또한 비슷한 경로를 가진 버스를 찾기 위해선 노선도를 하나하나 다 읽어봐야 하고, 이를 비교해서 볼 수 없다는 것이 불편하여 결국 스마트폰으로 검색을 하게 되었습니다. 이는 저 뿐만 아니라 다른 사람들도 마찬가지였는데요. 매일 많은 사람들이 이용하는 버스노선도가 보기 어렵다는 것이 큰 문제로 느껴져 리디자인을 하게 되었습니다.

본격적으로 리디자인을 하기 전에 해외에는 노선도를 어떻게 디자인 했는지 알아보았습니다. 관광산업이 발달한 나라들에선 어떤 버스노선도를 사용하고 있을까요?

먼저 버스 노선도를 특징별로 나눠보면 다음 4가지 유형 정도로 분류할 수 있습니다.
1. 현 정류장을 시작으로 그린 노선도
2. 해당 지역 (ex.신사 사거리)의 모든 버스의 노선을 지도상에 표현한 노선도
3. 실제 경로 형태의 노선도
4. 시간표를 첨부한 노선도


이 네 가지 유형들의 사례와 특징에 관해서 정리해봤습니다.

1. 현 정류장을 시작으로 그린 노선도


출처: http://designworkplan.com/wayfinding/sds-defining-city.htm
이런 노선도는 주로 영국 런던에서 볼 수 있는데요.

출처: https://www.flickr.com/photos/51282757@N05/6218986902/in/photostream/
장점으로는 현재 버스정류장에서 몇번 버스가 어디로 가는지, 비슷한 노선은 뭐가 있는지 정리가 잘 되어 있다는 점입니다. 아마 시간 낭비가 많이 줄 것 같네요.

우리나라와 다른 점은 우리나라는 버스 번호순으로 노선도들이 쭉 나열되어있지만, 런던은 이 정류장을 지나가는 모든 버스의 경로를 한번에 보여줘서 서로 비교가 쉽게끔 만들어진 노선도라고 할 수 있습니다.

우리나라 같은 개별 노선도(하나의 버스 노선만 기록한 노선도)가 없는 대신 위 사진처럼 현재 정류장에 서는 모든 버스의 노선들이 한꺼번에 표시되어, 버스들의 경로가 어디까지 같은 곳을 가고 어디서부터 갈라지는지를 단순화해서 표현하니 굉장히 보기 편하고 효율적인 디자인이라는 생각이 듭니다. 그리고 기본적으로 똑같은 버스 노선도를 줄줄이 늘어논 형태가 아니라 각 정류장에 적절하게끔 노선이 디자인 되어있다는 부분이 굉장히 높게 평가됩니다. 

좀 아쉬운건 우리나라처럼 버스에 색이 빨강, 파랑, 초록, 노랑으로 나뉘어 있다면, 위 사진처럼 버스 노선에 임의로 여러색을 사용할 수 없기 때문에 노선들이 서로 겹쳐 보일 가능성이 매우 높아 적용이 쉽지 않을 것으로 보입니다. 그리고 버스의 수가 많으면 노선들이 합쳐져서 전체적인 부피가 늘어나 제대로 표현이 안 될 가능성도 있겠네요.

2. 지도상에 표현된 노선도


두 번째 사례는 해당 지역의 모든 버스의 노선을 지도상에 표현한 노선도입니다.

출처: http://transitmaps.tumblr.com/post/40871322662/asheville-art
유럽 대부분에서 확인할 수 있는 이런 지도형 노선도는 일반적인 개별 노선도와 함께 부착되어 있습니다.

출처: http://transitmaps.tumblr.com/post/40871322662/asheville-art
장점으로는 현재 지역의 모든 버스의 대략적인 경로를 한번에 확인할 수 있다는 점입니다. 이런 지도가 붙어 있다면 목적지나 그 근방으로 가는 버스들을 한번에 볼 수 있겠죠. 버스 노선을 하나하나 확인하지 않아도 된다는 것이 장점이라고 생각됩니다.

나름대로 버스 노선을 단순화해서 사용자들이 보기 편하게 해놓은 것들도 있지만, ‘버스 노선 지도’라는 걸 고려하지 않고 그냥 일반 지도에 노선을 올려놓은 것 같은 느낌이 드는 지도는 버스정류장에 필요한 정보로서의 역할을 제대로 수행하지 못할 것 같습니다. 필요 없는 정보들이 전반적으로 많아 보이고 오히려 지하철이나 랜드마크 등 필요한 보가 부족해 보이네요. 그리고 전반적으로 형식이 통일되지 않아서 이런 부분은 빨리 개선돼야 할 부분인 것 같습니다.

또 너무 많은 노선이 얽혀 있으면 뭉쳐서 알아보기 힘들 수 있고, 계획적으로 노선이 계획적으로 짜여져 있지 않은 지역은 오히려 복잡해질 수 있을 것 같다는 생각이 듭니다.

3. 실제 경로 형태의 노선도


세 번째는 버스 노선을 실제 경로 형태와 비슷한 모양으로 표시한 노선도입니다.


출처: http://parisbuslady.com/category/busing-around/
주로 프랑스 파리에서 많이 볼 수 있는데요. 버스 안에 부착된 경우도 많습니다.


출처: http://www.parisperfect.com/blog/2012/07/42-bus-best-sightseeing-paris/
이 노선도는 지리정보(강, 다리 등)를 활용하여 위치나 경로 등을 쉽게 인지할 수 있는 장점이 있지만, 가로로 긴 형태를 유지해야 하므로 동서남북을 임의로 돌려야 하거나 노선을 일자로 왜곡해야 하는 경우가 많아 사용자들이 혼란을 겪을 수 있는 단점이 있습니다. 제 생각에 이는 동서남북이 바뀌었다는 것을 정확히 표기하거나 작은 지도상으로라도 보여주면 조금 해결되지 않을까 생각합니다.

좀 더 자세히 보면 버스가 가는 방향의 정류장과 오는 방향의 정류장이 완전히 똑같지 않다는 것을 볼 수 있는데요. 여기서 문제가 발생합니다. 정류장 이름을 모두 위로 쓰다 보니, 사용자들은 읽을 필요 없는 정류장까지 읽게 되거나 정류장의 위치를 잘못 인식하게 되는 경우가 발생할 수 있다는 겁니다. 색을 다르게 하거나 아래로 내리면 덜 헛갈릴 것 같습니다.

4. 시간표 노선도


마지막 네 번째 유형은 시간표를 첨부한 노선도입니다.


출처: https://www.3fach.ch/blog/stosszyt_blog/so-fach-geburi
버스나 이용객이 많지 않은 지역이나 일본에서 많이 볼 수 있는 유형인데요. 정확한 시간을 알 수 있는 장점이 있지만, 우리나라 같은 경우에는 워낙 버스가 자주 오고 종류가 다양하여 굳이 도시에서는 적용할 필요가 없습니다.

지금까지 해외의 버스 노선도에 대해서 정리해봤습니다. 각자 나름대로 중점을 두고 디자인된 부분들이 있고 장단점을 가지고 있는 것으로 보입니다. 이 장점들을 토대로 다음 두 번째 글 '정류장 맥락을 고려한 버스 노선도 디자인 2/3 –버스 노선도 Redesign 과정과 결론' 에서 새롭게 리디자인한 노선도가 어떠한지 이야기하도록 하겠습니다.

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



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


Trackback 0 Comment 0
Ad Test...
2014.10.07 03:06

무이단모음 키보드 (구글단모음 키보드 리디자인)

한글날을 맞이해서 구글단모음 키보드를 개선한 한글 키보드 디자인을 소개합니다. 아래에 사용해 볼 수 있는 프로토타입을 만들어 놓았으니 귀찮으신 분들은 아래쪽만 보시면 됩니다. :)

좋은 키보드 디자인은 배우기 쉽고 효율적으로 빨리 칠 수 있고 또 피로가 적어야 합니다.

키보드를 익숙하게 쓰는 것은 머리가 기억하는게 아니라 근육이 기억(muscle memory)하는 것이라서 조작 방식이 달라지면 다시 배워야 합니다. PC에서 두벌식 자판을 잘 쓰고 있었어도 스마트폰에서 처음 두벌식자판을 엄지로 쳐보려고 하면 정확한 키 위치로 잘 움직여지지 않습니다. 머리가 기억한 위치로 손가락을 움직이는게 아니라 오른손 검지가, 왼손 약지가 각각의 열개의 손가락 근육이 어디로 움직일지를 기억하고 있었던거니까요. 기왕 다시 새로 배울거라면 쓰기 편한 자판을 사용하는게 좋지 않을까요?

우리가 알고 있는 두벌식(qwerty) 자판이나 휴대폰에서 쓰던 천지인, 나랏글은 기존의 하드웨어 키패드를 활용해야만 하는 제약에서 출발했습니다. 두벌식은 영문 qwerty 자판에 한글 자모를 잘 배열해보려는 고민에서 나왔고 천지인이나 나랏글은 3x4 숫자키에 24자의 한글을 잘 욱여넣기 위한 발명입니다.
기존에 잘 사용해왔던 자판이라 익숙하긴 하지만 제약에서부터 출발한 디자인은 손해를 감수할 수 밖에 없었습니다. 작은 휴대폰에서 사용하려니 두벌식은 각 키의 크기가 너무 작아서 조심해서 눌러야하니 속도도 느리고(fitts' law) 오타도 많습니다. 10키 방식은 적은 키로 더 많은 글자를 조합해야 하니 50% 이상(천지인 경우) 더 많이 키를 눌러야 되니 비효율적입니다. 디지탈로 넘어오면서 기능적으로 불필요한 아날로그 메타포를 그대로 따라하는 스큐어모피즘에 대한 비판이 많았는데요. 우리가 가장 많이 접하게 되는 인터페이스인 키보드에도 여전히 그대로 남아있습니다. 터치스크린을 사용하면 이런 하드웨어 제약이 없으니 둘 간의 적절한 균형점에서 분명 더 나은 키보드 디자인이 있을 것입니다.

구글단모음 키보드


그 적절한 균형점을 잘 찾아낸 디자인이 구글단모음 키보드입니다.



한글 자소 빈도 참고 


1. 구글단모음 키보드는 자소의 빈도를 고려하여 사용빈도가 낮은 ㅑㅕㅛㅠ 를 키를 제거하여 키를 줄 당 10개에서 8개로 줄였습니다. 키캡이 25% 커졌습니다. 그러면서도 한글자당 평균 타수는 2.54에서 2.62로 3%밖에 늘지 않습니다. 훨씬 이익이지요.
한글 모음 10자 중 ㅑㅕㅛㅠ 는 빈도 합이 7.6% 로 상대적으로 사용빈도가 적습니다. 4자를 제외한 ㅏㅓㅗㅜㅡㅣ 6자의 빈도가 77%, 여기에 ㅐㅔ를 추가하면 87%입니다. 모음키 8개만 있으면 87%는 키 한번만 눌러서 입력이 가능합니다. 

2. 쌍자음이나 복모음 입력 방식을 나랏글처럼 별도의 변환키(shift)를 사용하는 대신에 천지인처럼 같은 키를 여러번 누르는 멀티탭 방식으로 바꿨습니다.
PC 키보드에서는 열손가락을 사용할때는 쉬프트키가 양쪽에 있어서 반대편 새끼손가락으로 동시에 누르면 되었지만(물론 이것도 원래 새끼손가락의 편안위치(resting position)을 이동해야 하는 것이라 손에 스트레스를 많이 주긴 하지만요), 엄지만으로 타이핑하고 하나의 쉬프트키만 넣은 휴대폰과 경우에는 쉬프트키를 누르기 위해서 손가락이 훨씬 많이 움직일 수 밖에 없습니다. 쉬프트키는 화면의 가장 구석에 있으니 가장 멀리 움직였다가 다시 되돌아와야 합니다. 손가락의 움직임이 많아지면 피로가 커지고 속도가 더뎌집니다. 더블탭 (제자리 치기)방식은 타수는 같아도 운지거리가 줄어드니 보다 나은 선택입니다.
다만 더블탭 방식의 문제는 천지인에서 겪었던 것처럼 "학교" 의 ㄱㄱ이 연속으로 입력될 때 종성과 다음 초성으로 입력하려는 것인지 "하꾜" 처럼 ㄲ 을 입력하려는 것이었는지 기계가 사용자 의도를 구분할 수 없기 때문에 사용자가 명시적으로 스페이스나 방향키 을 이용해서 음절 나눔을 해줘야 했습니다.타수가 늘어나기도 하고, 이런 경우가 규칙적이지 않아 사람이 매 경우 판단을 해야하니 신경이 쓰입니다. 이 문제는 연속치기 지연 시간 제한을 두거나 단어사전을 이용해서 해결했습니다.


그래서 많은 사람들이 구글단모음 키보드를 사랑합니다. 저도요. 그래서 구글의 정식 Google 한국어 입력기 외에도 많은 한글 키보드들이 구글단모음 자판 배열을 지원하고 있습니다. 그럼 구글단모음 배열이 궁극의 휴대폰 한글 키보드 자판일까요? 하지만 저는 더 격렬하게 더 적극적으로 게을러지고 싶었습니다. 구글 단모음 키보드에도 여전히 문제는 있거든요.



Thumb Zone


1. 왼손의 분담 영역이 넓어 운지 거리가 깁니다.
모음을 줄이다 보니 두벌식에서 한줄에 정확히 자음, 모음 반반으로 나뉘던 자판이 자음이 5자 모음 3자로 비대칭이 되었습니다. 키보드 입력을 할때 대부분 양손으로 쥐고 엄지로 타이핑을 합니다. 히트맵을 보면 가장 효율적으로 resting position은 ㅇ과 ㅏ 키입니다. 이곳에 엄지가 놓이도록 잡으면 다른 키들을 누르는데 움직이는 거리가 최소가 되니까 자연스레 그곳에 손가락을 두도록 잡게 됩니다. 엄지의 관절 움직임을 고려하면 ㅋ을 중심으로 ㅇ 주변의 부채꼴 영역이 입력이 쉽고 벗어날 수록 근육의 긴장이 많이 됩니다. ㄱ ㅅ ㅎ 등은 엄지가 닿기 불편한 위치에 빈도까지 높습니다. ㄱㅅㅎ의 빈도를 합치면 40%나 됩니다. 그래서 왼손에서 멀리 떨어져있는 ㅅㅎ을 오른손으로 치려는 사람들도 있는데 자음과 왼손 모음을 오른손이라는 맵핑이 일관성이 깨지면 입력 리듬이 흐트러집니다.

이미지 출처 How Do Users Really Hold Mobile Devices?


편안위치를 고려한 왼손 엄지의 이동 범위 관련 참조


2. 모음 배치의 일관성이 부족합니다.
두벌식은 기본 ㅏㅓㅣㅗㅜㅡ의 모아쓰기 규칙에 따라 아래쪽에 위치하는 모음은 가급적 아래에 두려고 고민을 하였지만 비어있는 ㅛㅕㅑ의 자리로 ㅗ 를 이동하다보니 ㅗ의 위치가 애매해졌습니다. 그래서 이중 모음 ㅝ,ㅞ/ㅘ,ㅙ/ㅢ 의 키 조합 경로가 제각각됩니다. ㅝ ㅢ 는 아래에서 위로 올라가면서 조합을 하는데 ㅘ만 위에서 아래로 내려오게 되고요.


무이128(단모음) 키보드

그래서 두벌식을 편안위치에 따른 운지거리를 최소화하고 모음의 배치에 규칙성을 두도록 다시 배열해 보았습니다. 사실은 구글단모음키보드의 개선이 아니라 두벌식을 재조합하는 것에서 시작했는데 결과적으로 구글단모음과 유사하게 되어 무이단모음이라고 이름 붙였습니다. 원래는 자음과 모음의 갯수를 조절해가며 실험해보던 여러 시안 중에서 12개의 자음키와 8개의 모음키를 사용한 것이라 무이128자판이라고 부르고 있었습니다. :)
학습용이성 보다 효율성을 더 강조한다면 자음이 오른쪽에 오는 것이 더 좋습니다. 자음과 모음의 키 타수 비율이58:42 거든요. 오른손잡이라면 오른손에 더 많은(키의 개수,누르는 횟수) 키를 누르도록 할당하는게 훨씬 편합니다. 한글 쓰기가 왼쪽에서 오른쪽으로 쓰니까 자음이 당연히 왼쪽에 와야 하는거 아니냐고요? 쓰기 순서에 따라 자소가 와야하면 영어는 어떻게 하나요? 한글 쓰기와 한글 타이핑은 아무 상관없습니다. 그래서 제가 만든 다른 자판들은 대부분 모음이 왼쪽 자음이 오른쪽에 있습니다.
하지만 무이128 자판은 이미 휴대폰 두벌식에 익숙해 있는 사람들을 위한 타협에서 만들었습니다. 저부터가 새로 배우는게 귀찮아졌거든요. :)

파란색- 키 이동, 노란색 키 제거

1. 자음을 키 사용 빈도에 따라 편안위치(resting position)에 가까이 모았습니다. 빈도가 높은 ㄱㅅ이 편안위치와 가까워서 입력이 수월해집니다. ㅌㅍ 자음 두글자를 제거하고 ㅂㅎ키 위치를 이동하였습니다. 나머지 자음 위치는 그대로 유지하고 row 이동은 있지만 상대적인 위치는 유지해서 가급적 학습이 용이하도록 하였습니다. ㅌㅍ은 빈도가 낮아서 이어치기를 해야하지만 구글단모음에 비해서 타수가 2%만 늘어납니다. 빈도가 낮은 ㅋ에 ㅌ를 함께 두는게 좋겠지만 ㅋㅋㅋㅋ를 칠 수 있도록 독립된 키로 남겨두었습니다. :)

2. 모음 배열을 일관적인 규칙을 두고 배열하였습니다. 두벌식자판에서 가운데 줄에 있던 ㅗ 를 하단으로 내려 ㅜㅗㅡ 모음이 모아쓰기 규칙에 맞게 모두 아래쪽으로 배치되었습니다. 또 ㅔ의 위치를 조정하여 ㅜㅓㅔ/ㅗㅏㅐ/ㅡㅣ 를 나란히 배치하여 이중 모음 이어치기가 자연스럽게 되었습니다. ㅝ,ㅞ/ㅘ,ㅙ/ㅢ 가 바로 이어집니다. PC 두벌식에서는 이렇게 함께 조합이 되는 모음을 나란히 배열하지 않습니다. 같은 손가락으로 연이어 치면 타이핑이 느려지므로 다른 손가락에 배정한 것입니다. 하지만 휴대폰에서 엄지로 타이핑하는 경우는 결국 엄지 혼자 움직이는 것이니까 가까이 모여 있는 것이 더 효율적입니다. 또 엄지의 관절 움직임에 편한 경로에 키가 나열되어 있고 일관성을 가지고 윗쪽으로 손이 이동하도록 배치하여 손의 근육이 기억하기 수월합니다. 아래 구현한 프로토타입에서처럼 모음에 swipe를 적용하면 한번에 밀어서 ㅘㅝㅢㅙㅞ 를 입력할 수 있어서 입력이 편해집니다.

3. 한줄의 키가 7개로 줄어서 키캡의 크기가 43% 커졌습니다. 구글단모음키보드에 비해서는 14%커지고요. 그에 비해서 타수는 5%,2% 늘어남 셈이라 더 빨리 칠 수 있습니다. 단순 타수 비교보다는 손가락 움직임이 줄어들고 규칙성을 가지게 되었다는게 더 입력 속도에 영향을 주긴 하지만요.



무이128(단모음) 키보드 배열 (스킨은 Fleksy 참조)


작성 중인 문장은 한글 팬그램

실제 동작하는 무이128 키보드 프로토타입은 http://lab.pxd.co.kr/touchkeyboard/mue128.html 에서 테스트 해볼 수 있습니다. 아이폰 또는 안드로이드 크롬에서 사용해 볼 수 있습니다. 궁극의 키보드를 만드는 것이 목표였는데 트레이드오프가 있기 때문에 여전히 하나의 새로운 대안일 뿐입니다. 새로운 것을 실험해보기 좋아하시는 분은 한번 사용해보시고 의견 주세요. 

무이128 키보드 배열은 한글날을 맞아 CC 라이선스에 따라 공유하려고 합니다. 자판 배열이 괜찮다고 생각이 되는 능력있는 iOS,안드로이드 개발자님들은 키보드를 만들어서 자유롭게 배포해 주십시오.


크리에이티브 커먼즈 라이선스
무이에 의해 작성된 무이128(단모음) 키보드은(는) 크리에이티브 커먼즈 저작자표시-비영리 4.0 국제 라이선스에 따라 이용할 수 있습니다.


2014.11.8 수정안. 
위치가 바뀐 ㅂ 이 불편하다는 피드백이 있었는데요. 가급적 왼쪽끝이라는 기존 위치를 유지하려고 했지만 왼쪽 아래는 엄지의 이동이 불편한 영역이라서 ㅂ 처럼 빈도가 있는 글자가 있기에는 좋지 않은 것 같습니다. ㅋ처럼 빈도가 낮은 글자가 그 자리에 오는게 맞을 것 같아요. 어차피 새로 위치를 익혀야 한다면 입력이 편한 위치가 좋을 것 같아서 ㅂ 위치를 옮겼습니다.

위 본문의 편안 위치를 고려한 왼손 엄지 이동 범위 그림을 참고 해 주세요.




2015.5.25 수정안.

ㅊㅌ 키의 기본키를 ㅌ으로 ㅌㅌ 입력 시 ㅊ 이 되도록 바꾸었습니다. 둘의 빈도 수가 거의 비슷해 차이는 없으나 멀티탭 방식으로 ㄾ 받침 입력시 얄+ㅊ+ㅊ=얄ㅌ 가 되는 문제가 있습니다. 커키보드 의 웅이 님이 문제를 지적해 주었습니다. 외래어를 많이 쓰는 경우 ㅌ의 빈도가 높기도 한데 이는 개인차가 있습니다.



무이단모음 채용 키보드 앱

2014.11.11

아이폰용 한key 키보드 
무이단모음(128) 자판을 채용한 첫 서드파티 키보드가 앱스토어에 올라왔습니다.
이택규님이 개발하신 한key 단모음 앱입니다.  


아이폰용 단키 V2
엔비냥님이 개발하신 단키 1.3 버전에도 무이 단모음이 추가되었습니다.
단키는 무료로 단모음을 이용할 수 있고 스와이프를 이용한 편의 기능과 테마를 통해 키보드를 예쁘게 꾸밀 수 있습니다.
https://itunes.apple.com/kr/app/danki-danmo-eum-mu-i-danmo/id922851586?mt=8



안드로이드용

Multiling O 키보드로 무이단모음 자판 이용하기

http://lab.pxd.co.kr/touchkeyboard/

관대 님이 레이아웃 변경하는 방법을 댓글로 알려주셨습니다.

Multiling O 키보드의 한영 전환이 스페이스바를 스와이프하는 익숙치 않은 방법이라 한영 전환키를 넣은 무이단모음,영문 자판이 한 번에 설치되는 설정 파일을 만들었습니다.








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






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


Trackback 0 Comment 28
Ad Test...
2014.10.02 10:16

[정보디자인] 한글 자소 빈도와 키보드 히트맵

한글날을 맞이하여 한글키보드와 관련해 사내 메일로 주고 받았던 주제들을 모아서 정리해보려고 합니다. 우선 한글 터치 키보드 디자인에 대한 얘기입니다. 터치스크린을 채용한 폰이 나오면서부터 10키에서 벗어난 새로운 한글 자판의 배열을 고민하기 시작했습니다. 자판의 여러 시안을 만들어보긴 했는데 문제는 어떤게 좋은지 평가하기가 어려웠습니다. 매번 사람들에게 테스트 해보게 할 수 도 없고, 한 두번 사용해서는 제대로된 평가를 할 수 없으니까요. 익숙한 자판이 더 편하니까 충분히 숙달 되기 전에는 비교가 어렵습니다. 그래서 자판의 효율을 간단히 평가할 수 있도록 키의 배열과 빈도를 시각화 할 수 있는 heatmap 생성 툴을 만들었습니다.


한글 자소 빈도
휴대폰 자판의 경우 새로운 방식의 한글 자판을 소개할 때 기존의 천지인이나 나랏글보다 타수가 줄었다는 것을 많이들 강조합니다. 하지만 타수를 제대로 비교하려면 자소의 빈도를 함께 고려해야 합니다. 많이 쓰이지 않는 자소의 타수가 한 두번 주는것보다는 자주 입력해야하는 자소를 쉽게 칠 수 있어야 실제 어느정도 타수가 줄어들었는지 효과를 알 수 있습니다.

영어나 라틴어 계통 언어의 자소 빈도에 대한 연구는 많이 되어 있어 위키백과만 찾아도 자료가 잘 정리되어 있습니다. 하지만 한글의 자소 빈도는 공개된 자료를 얻기 어렵습니다.

자소 빈도는 분석을 위한 표본 문장을 어떻게 선정하느냐에 따라 차이가 납니다. 우리말에는 ㅊㅋㅌㅍ 같은 거센소리 자음이 많이 쓰이지 않지만 외래어를 전문용어로 많이 사용하는 분야의 서적에서는 빈도가 높겠지요. 그래서 보통 어휘의 편향이 적을 것이라고 생각되는 교과서 같은 책을 표본으로 분석하는 경우가 많습니다.

하지만 휴대폰 자판을 만드는게 목적이니까 문어체보다는 휴대폰에서 사용하는 문자 메시지 같은 구어체 문장을 표본으로 삼는게 보다 적합할거라고 생각합니다. 휴대폰으로 논문을 쓸 건 아니잖아요. 충분한 양의 다수 사용자의 문자를 수집하는건 프라이버시 문제로 어렵기 때문에 대신 트위터를 표본으로 사용하기로 했습니다.

트위터 stream API 를 이용해서 한글 트윗 2 만여개에서 60 만자 정도를 수집해서 자소를 분리했습니다. 충분히 많지는 않지만 절반인 30만자로 분석했을때와 빈도 변화가 거의 없었으니까 적절한 크기라고 생각됩니다.

한글은 초성 19 자 중성 21 자 종성 27 자(+ null 받침 없음)의 조합으로 구성되어 있습니다. 훈민정음에서는 더 다양한 자소의 결합이 가능했지만 현대 우리말에서는 이렇게 19*21*28 = 11172 자의 조합만을 허용하고 있습니다. 유니코드에는 이 조합의 순서대로 한글에 코드값을 부여하고 있는데, 이 규칙을 이용해서 반대로 각 자소를 간단히 분리할 수 있습니다.


트윗에서 영어나 숫자 특수기호등을 빼고 한글만을 분리해서 음절을 초성,중성,종성으로 나누고 각각의 빈도를 구합니다.



이렇게 구한 자소의 빈도별 순위는 아래와 같습니다. 보다 자세한 자소 빈도표 원본은 공유한 구글 문서를 참고하세요.


한글 자소빈도 by 무이 via 한글 트윈 자소 분석

초성에서는 o이 압도적으로 많고 ㄱㅅㅈㄷㄴ 순입니다. 받침에서는 ㄴ이 가장 많고 ㄹㅇㄱㅁ 순이고요. 받침없이 초성+종성 으로만 이루어진 글자가 56% 정도입니다.
원래 한글에서 모음없이 자음만 달랑있는 글자는 온전한 음절이 아닙니다만 요즘엔 그런 초성체가 많이 보입니다. 휴대폰에서 글자 입력이 귀찮으니까 이런 사용행태가 나온 것 같은데요. 분석한 트윗에서는 13%가 이런 초성체를 사용하고 있습니다. 그 중에 형태를 이용한 이모티콘으로 사용하는 경우도 있긴 하지만요. 가장 많이 사용되는 초성체는 역시나 ㅋㅋ인데요.정상적인 한글 문장에서 ㅋ의 빈도는 1.6%밖에 되지 않지만 이런 초성체를 포함하면 5.1%로 3배이상 높아집니다. 전 이런거 싫어해서 무시할까 했는데 :) 다행히 초성체를 포함하더라도 빈도 순위에 영향을 미치는 자소는 ㅋ 밖에 없었습니다. ㅎㅎ도 많이 사용하는데 ㅋ는 그냥 쓰는게 아니라 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 처럼 미친듯이 연이어 쓰는 경우가 많거든요. :)



키보드 Heatmap
자소의 빈도를 알았으니 이제 실제 자판에서의 키 사용 빈도를 구해볼 수 있습니다. 한글 자소와 자판의 키가 1:1 대응이 되지는 않으니 다시 계산해야 합니다. 더 적은 수의 키로 자소를 표현하기 위해서 키를 여러번 누르는 멀티탭 방식과 별도의 변환키를 사용하거나 키의 조합으로 입력하는 방식이 주로 사용됩니다. 멀티탭 방식은 천지인의 자음이나 나랏글의 모음에 사용되고있고 변환키 방식은 쉬프트키나 나랏글의 획추가, 쌍자음키에서 사용되고 있습니다. 요즘은 터치스크린에서는 키를 누르고 네방향으로 밀기(flick) 를 통한 입력도 많이 사용되고 있고요.

자판 배열을 자판에 사용되는 심볼을 이용해서 표시하고
초성,중성,종성 자소의 입력 규칙을 자판의 심볼을 이용해서 정의해 놓으면 그것으로 자판 키의 빈도를 계산하고 빈도에 따라 색을 달리하여 히트맵을 만들 수 있습니다.

두벌식 자판의 사용 빈도는 아래와 같습니다. 영어 자판인 qwerty,dvorak,colemak 자판의 heatmap을 비교한 자료는 온라인 상에서 쉽게 찾을 수 있지만 한글 자판은 처음 보실거에요. 어서 와. 한글 자판 힛맵은 처음이지?
http://lab.pxd.co.kr/heatmap/ 에서 두벌식과 세벌식, 천지인, 나랏글등 여러 키보드 히트맵과 자소별 타수 비교등 보다 자세한 정보를 볼 수 있습니다.
두벌식 자소 빈도 Heatmap by 무이

이렇게 자판 키의 사용 빈도를 시각화한 모형만을 가지고도 자판 설계의 여러 요소를 평가 할 수 있습니다. 진할 수록 키의 사용 빈도가 높고 흰색은 잘 사용되지 않는 키입니다. 우선 학습성을 고려하지 않는다면 어떻게 이 키들을 배열하는게 최선일까요?

다음 단어들을 실제 키보드에서 (폰이나 패드에서 말고요) 타이핑 해보세요.
address, traverse, exaggerate, trade secret, stress test, Easter egg
막 손가락이 꼬일 것 같죠? 키보드는 양손을 사용하라고 만든거니까 양손을 교대로 사용해야(한 손만을 반복해서 사용 하지 않아야) 손에 긴장을 줄여주고 입력 속도도 빨라집니다. 다행히도 한글은 자음과 모음을 조합해서 만드는 글자라서 자음과 모음을 양손으로 분리해 놓는 것만으로 양손 교대 입력이 어느정도 이루어집니다.


한글 자소 빈도와 키조합  L= left shift, R= right shift


qwerty 자판에서는 숫자키를 제외하면 3개의 키줄이 있고 각 줄에 10개의 키가 있어서 소지,약지,중지가 가운데 위 아래 3개의 키를 담당하고 검지가 6개의 키를 담당해서 입력합니다. 손가락을 키보드에 올려놓는 위치를 resting position이라고 하는데 손가락의 움직임이 최소가 되려면 가운데 줄에 손을 올려놓는게 가장 자연스럽겠지요. 그래서 가운데 줄에 빈도가 높은 자소를 배치하면 손가락을 덜 움직이게 되니까 편합니다. 관절의 움직임을 고려하면 아래줄 보다는 윗줄이 치기 쉬우니까 가급적 아랫줄에는 빈도가 낮은 키를 배열합니다. 새끼 손가락이나 약지보다는 힘이 센 검지나 중지에 더 많은 키가 할당되도록 배치하는게 더 수월합니다. 위의 손가락별 타수 빈도를 보면 적절한 듯 보이지만 세벌식은 왼손 새끼 손가락의 할당이 30% ,약지는 15%정도 더 적게 배열되어 있습니다.

아래의 두벌식 자판은 위에서 얘기한 원칙을 보다 잘 따르고 있다는것이 히트맵을 통해 잘 드러납니다. 아래 자판은 북한의 표준 자판입니다. 실제로 북한의 김영민 자판은 우리의 두벌식 KSC5715 보다 20%정도 입력 속도가 빠르다고 합니다. 입력 구조를 바꾸지 않아도, 자소 빈도를 세심하게 고려하는 것 만으로 보다 나은 자판 디자인을 할 수 있습니다.
북한 김영민안

다음에는 이 툴을 활용해서 휴대폰에서 엄지 손가락으로 입력하기에 적합한 자판을 만들어 보도록 하겠습니다.
이어지는 글 : 무이단모음 키보드 (구글단모음 키보드 리디자인)


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

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


Trackback 0 Comment 0
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...
2013.05.21 00:04

[정보디자인] 에드워드 터프티를 위한 날씨앱

LeanUX Lab에서는 요즘 날씨앱을 만들고 있습니다.
앱스토어에 별도의 날씨 카테고리가 있을 정도로 날씨앱은 굉장히 많습니다. 만들기 쉽거든요. 시장에서 경쟁도 심하고 더 이상 새로울 것도 없는 날씨앱을 만들기로 한 건 아직 세상에 딱 맘에 드는 날씨앱이 없었기 때문입니다. P랩의 모토는 make a dent in the universe 입니다. (스티브잡스가 한 말이기도 하고 37signals의 rework 책의 한 챕터 제목이기도 합니다) 날씨앱이 세상을 바꾸지는 못하지만 우주에 작은 흠을 낼 정도의 세상에 없던 궁극의 날씨앱을 만들 수는 있을 것 같거든요.

날씨앱을 만들기로 하고 다른 프로젝트와 마찬가지로 먼저 경쟁자 분석과 사용자 조사를 함께 진행했습니다. 현재 날씨앱이 어떤 유형이 있는지 어떤 정보를 어떻게 보여주는지, 어떤 앱이 인기가 있는지를 찾아보면서 동시에 사내에서 민첩하게 인터뷰를 진행했습니다. 어떤 날씨앱을 사용하는지 왜 선호하는지 이야기를 들어보다보니 메신저의 카카오톡처럼 부동의 1위를 하는 시장 주도 상품이 없고 각자 자기 취향에 따라 날씨 앱을 골라서 쓰고 있었습니다. 좋기도 하고 나쁘기도 한 결과였는데, 시장에 강력한 경쟁자가 없으니 진입이 수월하기도 하겠지만 결국 취향에 좌우되는거라서 궁극의 날씨 앱 같은건 없을 수도 있겠다는 우려도 있었습니다.



날씨앱의 경쟁 상대는 엄마

인터뷰를 통해 날씨앱(웹서비스) 사용 유무를 극명하게 나누는 요인을 발견했습니다. 바로 아침에 엄마(와이프)가 날씨를 알려주는가 아닌가였습니다. 아무리 훌륭한 날씨앱이라도 엄마에겐 상대가 안 됩니다. :) 폰을 꺼내서 앱을 실행하고 날씨 정보를 확인하고 그런 번거러운 절차 다 필요없거든요. 엄마가 "오늘 비오니까 우산 챙겨라.","바람 많이 불어서 어제보다 많이 춥다니까 옷 따뜻하게 껴입고 나가라." 라고 뉴스를 통해 얻은 날씨 정보를 요약해서 핵심만 말해주거든요.

엄마가 알려주는 날씨 정보에는 두 가지 중요한 포인트가 있습니다.

첫째는 날씨 정보 자체보다는 날씨에 따라 뭘 해야 하는지 action item 위주로 알려줍니다. 사람들이 일상에서 날씨가 좋은지 나쁜지 기상 상태 자체를 알고 싶은 것 보다 우산을 챙겨야 하는지, 옷을 껴입을지 가볍게 입을지, 세차를 할지 말지, 소풍을 (에버랜드로) 갈지 말지 판단하기 위해서 날씨를 확인하잖아요.
그래서인지 저는 비 올때 날씨 아이콘으로 비구름 대신 우산 모양 심볼을 더 선호합니다. 다른 구름 심볼과 구분도 잘되고 뭘 해야 하는지 직관적이니까요. 네이버랑 다음 날씨도 우산을 사용해서 익숙한데 이게 우리나라와 일본 정도만 그렇고 다른 나라에서는 잘 사용하지는 않는 것 같습니다.(다른 나라는 어떤지 왜 그런지 아시면 알려주세요)

둘째는 수치 보다는 내가 이해할 수 있는 체감 정보를 알려줍니다. 절대음감처럼 온도만 듣고 얼마나 추운지 따뜻한지 감을 잡기는 쉽지 않습니다. 그래서 엄마는 기온이 8.2° 라고 하기보다 어제보다 쌀쌀해졌다고 알려줍니다. 어제의 온도와 비교해서 알려주는 어제오늘 앱이 인기가 있는 것도 이 때문입니다.


날씨 정보 밀도

그럼 이렇게 엄마가 알려주는 요약된 날씨 정보를 그대로 날씨앱으로 옮기면 성공 할 수 있지 않을까요?
성공하기 어렵다고 생각합니다. 날씨 앱을 실행하는데는 보다 큰 비용이 들기 때문에 보다 많은 보상(정보)이 필요 합니다. 또 자신이 신뢰하는 사람이 아닌 경우, 근거가 되는 구체적인 데이타를 제시하지 않으면 추천이나 제안에 대한 신뢰가 낮습니다. 다른 프로젝트에서 이와 관련 있는 실험을 했었는데요. 전문가 시스템에 의한 추천이라해도 데이타를 보여주지 않으면 그것을 신뢰하는 사람과 그렇지 못하고 직접 데이타를 확인하려는 사람이 반반으로 나뉘었습니다. 엄마는 "추우니까 따뜻하게 입어라" 라고만 해도 되지만 앱은 사용자가 판단할 수 있는 근거가 되는 정보를 부가적으로 담아 보여줄 필요가 있습니다.


왼쪽부터 haze,solar,blue

요즘 haze,solar,blue 같은 미니멀하고 조작성을 강조한 날씨앱이 유행입니다. 이런 깔끔한거 저도 참 좋아하는데요. 제가 한 번 먹어 사봤습니다. "와 예쁘다.재밌다."라고 좋아라하고 그 후로 사용하진 않습니다. 정보 전달 측면에서는 완전 꽝이거든요. 날씨 정보는 현재의 날씨와 이후 시간의 예보가 둘 다 중요한데 앞의 앱들은 이후 예보를 보기 위해서 제스처를 통해 시간을 변경해야 해당 시간의 날씨 정보를 보여주는 형태입니다. 터프티가 싫어하는 stacked in time 방식입니다. 손맛도 있고 재밌긴하지만 비효율적입니다. 오후에 비가 내리더라도 시간대를 일일히 다 탐색해보지 않으면 알 수 없거든요. 또 온도 같은 건 상대적 비교를 통해서 따뜻해진다는건지 추워진다는건지를 알아야 하는데 이런 방식은 비교가 어렵습니다. 사람에게 주의는 한정된 자원인데 이런 하찮은 매 시간의 온도를 기억해서 비교해야 하는건 적합하지 않습니다.

터프티는 아이폰의 기본 날씨앱도 정보 밀도가 너무 낮다고 비판하고 있습니다.
동영상 : iPhone Resolution by Edward Tufte
요즘 이런 미니멀한 날씨앱이 인기가 있는건 기본 날씨앱보다 좀 더 많은 날씨 정보를 담아보려고 하다가 너무 복잡해서 질려버리게 하는 날씨앱에 대한 반발에서 나온게 아닌가 싶습니다. 하지만 터프티가 지적하고 있듯이 정보가 많아서 복잡해 보이는 건 아닙니다. 복잡해 보이는건 정보 자체의 속성이 아니라 디자인을 못했기 때문입니다.


한눈에 보이는 하루의 날씨 정보 시각화

날씨 정보에서 가장 중요한 정보는 맑은지 흐린지 비가 오는지 하는 기상의 변화와 추운지 따뜻한지 하는 기온 두 가지 입니다. 그런데 이 둘은 하루 중에도 변화가 심합니다.
출근 할 때는 따뜻했지만 퇴근 할 때는 추워서 떨었던 경험 많이 있었죠? 최고,최저 기온을 함께 표시되어도 언제가 가장 추운지는 알 수 없습니다. 아무리 추워도 그게 출근 전,퇴근 후면 나랑 상관없거든요. 비가 온다고 해서 번거럽지만 우산 챙겨갔는데 낮에 잠깐 내리고 말아서 펴보지도 않은 우산을 뻘쭘하게 다시 챙겨서 집에 돌아가기도 하고요.


아이폰5 기본 날씨앱

하루의 변화를 알려면 시간대별로 예보를 제공해야 하는데, 아이폰 기본 날씨앱처럼 매 시간별로 날씨 아이콘과 숫자를 나열하면 복잡해 보입니다.(그나마 깔끔한 디자인에도 불구하고) 숫자도 결국 심볼의 나열이라 인지적으로 처리해야 할 부하가 커질 뿐입니다. 폰의 작은 화면에서는 한 화면에 보여지지 못하고 스크롤을 해야 하니 더 불편합니다. 또 우리는 절대"온"감을 가진게 아니라서 숫자를 바로 이해하기 어렵습니다. 우리가 알고 싶은 건 온도의 변화지 숫자가 아니거든요. 변화를 이해하려면 다시 값들 간의 차이를 계산해야 합니다.
많은 양의 시계열 정보를 표시하는 가장 효율적인 방법은 그래프를 이용해서 정보를 시각화하는 것입니다.


weatherspark by 무이

그래서 디자인을 해봤는데요. 이 그래프는 기존의 날씨앱이나 뉴스에서 사용되던 그래프와 두 가지 큰 차이가 있습니다.

첫째, 체감적인 온도를 쉽게 가늠할 수 있게 어제와 기온 차이를 비교 그래프로 표시했습니다.
어제와 오늘의 그래프가 겹치면 어제랑 비슷한거고 차이의 면적이 크면 춥거나 더워진거죠. 위의 그림에는 새벽에는 어제보다 따뜻했지만(집에서 나가기 전이니까 관심없고) 9시 이후 부터는 어제보다 온도가 낮다는걸 시각적으로 보여줍니다. 어제 오늘 기온을 비교해주기는 하지만 하루의 기온 변화를 어제와 비교해서 그래프로 시각화해주는 건 없었습니다(찾아보니 없네요). 최고,최저 기온 값뿐 아니라 그게 언제 인지도 알 수 있습니다. 보통 새벽에 최저, 낮에 최고 기온을 기록하지만 위 그래프는 그렇지 않은 날의 경우를 보여줍니다.

이렇게 두 값의 차이를 영역으로 나타낸 그래프를 range area chart 라고 하는데(우리말로는 찾아봤는데 모르겠네요) 손으로는 쉽게 그릴 수 있지만 엑셀에서 제공하지 않기 때문에 우리에겐 익숙하지 않습니다. 하지만 이 그래프가 발명(?)된지는 꽤 오래되었는데요. 터프티의 The Visual Display of Quantitative Information 소개된 바에 의하면 1786년에 발행된 책 The Commercial and Political Atlas 에서 무역수지 (수출과 수입의 차이)를 시각적으로 보여주기 위한 그래프로 사용되었습니다. 이 기념비적인 책의 저자 중 한 명인 Playfair 는 스코틀랜드의 공학자이자 정치경제학자인데 우리가 아는 대부분의 그래프들 line graph(시계열 그래프), area chart, bar chart, histogram,pie chart 를 발명했습니다. 네, 그 놈의 파이차트가 태고부터 세상에 존재했던게 아니라 이 사람이 만들었습니다.

Playfair's trade-balance time-series chart, published in his Commercial and Political Atlas, 1786

둘째는 그래프가 0시에서 24시로 하루의 시간 축이 고정되어 있습니다.
모든 날씨앱의 기온 그래프는 현재 시간에서 부터 시작합니다. 이미 지난 정보라 불필요하니까 굳이 보여줄 필요가 없기도 하지만 날씨 정보를 제공하는 업체의 API가 이전 시간 정보는 제공하지 않기 때문에 그릴 수가 없습니다.
사실 이전 시간의 기온은 어제 오늘을 비교하는 것처럼 아침에 나올 때는 어땠는지 아니까 그걸 기준으로 이후 날씨를 판단하는데 도움을 주는 유용한 정보입니다.
또 우리가 관심 있는 시간은 한 시간 뒤나 세 시간 뒤 처럼 상대적인 것 보다 대부분  출근이나 퇴근 시간처럼 정해져 있어서 시작 시간이 가변적이면 매번 축 상의 시간을 먼저 확인해야 합니다. 하지만 시간 축이 고정되어 있으면 항상 같은 곳을 보면 되기때문에 훨씬 보기 편합니다.

하지만 많은 사람들이 그래프를 보면 반사적으로 어렵다고 생각합니다. 의미 있는 실 데이타가 아니라 시험 문제를 위해서 작위적으로 만들어진 그래프만 보아 온 사람들은 좀 더 그런 경향이 있는것 같고요. 제대로 된 그래프를 보는 것이 익숙하지 않아서 인것 같습니다.
게다가 이렇게 난생 듣도 보도 못한 날씨 그래프를 보면 더 어려워합니다. UI 디자인 회의를 하면 경험이 적은 디자이너들은 알려주기 전에는 모르는(학습비용이 큰) UI는 나쁘다고 뺀찌를 놓는 경우가 많습니다. 하지만 사용자는 초보자도,전문가도 아닌 중간정도의 사용자(perpetual intermediates)가 대부분 입니다. 연말정산 처럼 일년에 한번 사용하는 서비스가 아니라 매일 사용하는 날씨 같은 경우는 학습성보다는 효율성에 비중을 두는게 좋습니다. (그럼 연말정산 서비스는 학습성이 좋게 되어 있냐하면 그건 절대 아니더라구요) 결국 익숙한가 아닌가의 문제인데 익숙해지면 기존의 다른 날씨 정보는 너무 원시적이라 다시 돌아가기 어렵습니다 :)


Data Encoding

하단에 기상 상태를 보여주는 부분은 동일한 날씨 아이콘을 반복해서 그리지 않도록 했습니다. 비슷한 아이콘이 반복되면 정작 날씨가 언제 어떻게 변한다는 보다 중요한 정보가 묻히게 되거든요. 하루 종일 맑다고 태양만 계속 그려놓으면 잉크가 아깝잖아요.
오늘 날씨 어때? 라고 물으면 "계속 맑아"라고 답하지 "1시 맑고 2시 맑고 3시 맑고 4시 맑고.." 라고 말하면 이뭐병 이상하잖아요. 정보를 시각화하는 것도 같습니다.
그래서 동일한 날씨의 시간대를 bar로 묶으니 마치 구름처럼 보였습니다. 기상 상태는 결국 구름이 어떻게 변하느냐입니다. 맑은 날은 태양이 뜬게 아니라(태양은 언제나 떠 있습니다) 구름이 없는 날입니다. 구름이 많은지 적은지, partly인지 mostly인지 별로 중요한 정보는 아니라서 차이를 두지 않고(반투명 구름) 눈,비가 오는 정말 중요한 정보만을 눈에 띄도록 했습니다. 비가 오면 파란 구름이고 눈이 오면 하얀 구름이라 언제 우산을 준비해야 하는지 바로 알 수 있습니다.
참고 : 비오는 날 우산 준비하라고 문자 날려줄게요.

중요한 정보를 부각시키려면 대비를 크게 해야 하고 그러려면 중요한걸 강조하는게 아니라 덜 중요한걸 덜어내야 합니다. 그래서 맑은 날씨는 아무 표시도 없습니다. 구름이 없으면 맑거든요. (맑은 날이 별로 없는 북유럽같은 경우는 태양이 비추는 것이 더 중요한 정보이겠지만요)
날씨 심볼에 따라 좀 더 상세하게 나눠지긴 하지만 구름바는 단순히 맑음(없음),구름있음(반투명),우산 필요(비 또는 눈 - 불투명) 세 가지 상태만으로 표시합니다. 하루의 기상 변화를 이 3가지 상태의 조합 패턴으로 파악할 수 있도록 했습니다. gif 처럼 데이타를 압축하여 표시하므로 24개의 개별 날씨 심볼을 표시하는 것에 비해 효율이 높습니다. 디테일의 손실이 있지만 보다 중요한 정보를 빨리 전달 할 수 있습니다.

추가로 일출 일몰 시간이 기상이나 기온에도 영향을 주기때문에 시간축에 함께 표시하고 일몰시간에 표시한 달은 실제 달모양에 따라 변하도록 했습니다. 구름 위에 태양과 달이 떠 있는 디테일도 세계관을 반영한 디자인이라 만족스럽습니다 :)


일교차의 변화

주간 날씨에서 기온은 최고,최저 기온 두 숫자로 적어서 표시하는데 이 경우에도 기온의 변화나 일교차가 얼마나 되는지 눈에 잘 들어오지 않습니다. 그래서 최고,최저 기온을 두개의 그래프로 그려서 보여주기도 하는데, 최고,최저 각각의 기온 변화는 잘 드러나지만 하루의 기온 변화가 아니라 두개의 독립된 항목처럼 표시되고 있습니다. 일교차가 큰지 작은지도 중요한 정보인데(일교차 크니 주의하라고 알려주잖아요) 그래프에서는 비명시적(공백)으로 표현됩니다.



뉴스에서의 주간 날씨 표시


주간날씨 그래프 by 무이

이 문제의 해결도 역시나 range area chart를 사용하는 것입니다. 차이 자체가 데이타이니까 잉크를 아낄 필요가 없습니다. 리디자인인 된 주간날씨에서는 최고,최저 기온 그래프의 차이를 면으로 채우고 꺾은선이 아닌 곡선으로 표시했습니다. 관습적으로 두 개의 선으로 그려서 두 개의 정보로 나뉘어 인식되던 그래프가 면을 채워주는 것만으로, 일교차 하나의 정보로 인식되어 일교차의 크기도 잘 비교가 되고 경계인 최고,최저 기온의 변화 추세도 더 잘 드러납니다.
또 저 경계안에서 하루 동안 주기 그래프가 반복되는 것이니까 꺾은선 그래프보다는 연속적인 완만한 곡선으로 그리는 것이 자연스럽습니다. 신문이나 방송에서 주간날씨 예보로 이 그래프를 사용하고 싶으면 연락주세요. :)
날짜를 표시하는 레이블도 눈 여겨서 볼 필요가 있는데요. 공간이 충분하면 날짜와 요일을 함께 적겠지만 하나만 적는다면 요일이 좋겠지요. 또 아이폰 날씨 위젯에서는 모두 요일만을 표시하고 있는데 기준이 되는 오늘은 명시하는게 혹시 모를 혼동을 줄여줘서 좋습니다. 위 뉴스 사진에는 내일까지 적고 있는데 아마 맥락 상 저녁 뉴스이지 않을까 싶습니다.


세상에서 가장 예쁜 날씨앱

그럼 이렇게 만들면 누구나 좋아할까요?
인터뷰를 해보면 정보를 잘 보여준다고 좋아하는 사람은 안타깝게도 저 같은 데이타소수자들뿐이었습니다. 날씨 정보를 이해하기 쉽게 전달하는 기능적이고 이성적인 측면과 더불어 날씨 앱에서 중요한 건 역시나 감성적인 부분이었습니다. 대충 날씨만 알 수 있으면 예쁜게 최고였습니다. 그래서 위의 날씨앱은 취미로 만들어서 개인적으로 사용하고 있고 p랩에서는 예쁜 날씨 앱을 만들고 있습니다. :)

다른 날씨앱들을 살펴보면 기상 상태를 보여주는데 아이콘을 사용하거나 사실적인 날씨 풍경 사진이나 동영상을 사용하는 형태가 대부분입니다. 참고 날씨 어플 디자인 스타일,  Comparing iPhone weather apps at a glance
p랩에서는 지금까지 없던 형태를 찾아보기로 했는데요. 그래서 정한 컨셉은 실시간 데이타를 기반으로 날씨가 애니메이션되는 라이브 인포그래픽 입니다. 예쁜 일러스트 풍경을 배경으로 태양,구름,밝기,바람,비,눈,번개,나뭇잎 등의 요소들이 실제 날씨 데이타에 따라서 조합되어 애니메이션 됩니다. 말로 설명하기보다 아래 동영상을 봐주세요.
현재 앱스토어에 올라온 버전은 가장 기본적인 MVP(Minimum Viable Product)만을 구현한 버전입니다. 예쁜 라이브 애니메이션과 엄마가 알려주는 날씨정보를 컨셉으로 하고 있습니다. 최종 버전에서는 배경의 테마가 구글 두들처럼 날씨 이벤트에 따라 달라지도록 하려고 합니다. 아래 그림은 기본 배경이 아니라 벗꽃철에 한해서 제공되는 테마로 바람이 불면 벗꽃이 휘날립니다.
현재는 위의 날씨 그래프같은 정보를 추가한 버전을 준비 중입니다. 상이한 접근의 두 디자인이 잘 합쳐질 수 있을지 아직도 잘 모르겠지만요. 사용해 보시고 의견을 들려주세요.


인포그래픽과 데이타정크의 차이는 뭘까요?


1. Cloudia, 서울날씨(아이폰앱) -> App Store 다운로드
수정: Cloudia(아이폰앱,글로벌버전) 홈페이지

2. Weather Spark(웹앱) -> http://lab.pxd.co.kr/weatherspark/ 
   (iOS 기기에서만 동작합니다. 바탕화면 바로가기를 만들면 웹앱으로 동작합니다.)


Cloudia, 서울날씨



Cloudia, 서울날씨




Weather Spark



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

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


Trackback 0 Comment 37
Ad Test...
2012.11.19 18:56

[정보디자인] 버스 도착, 노선 운행 정보

네이버, 다음의 버스 도착 안내의 현재 운행 버스 위치는 왜 오른쪽에 있을까요? 또 서울시와 경기도, t맵와 올레맵도 왜 다들 오른쪽에 있는 걸까요? 아래 그림을 보며 이유를 한번 생각해 보고나서 계속 글을 읽어주세요.

그림: 왼쪽 상단부터 서울버스앱,네이버지도,다음지도,서울시버스정보,경기도버스정보,올레맵,T맵


질문: 왜 버스 운행 정보는 목록의 오른쪽에 위치할까?

1. 버스 운행 정보를 표시하는 가장 최적의, 궁극의 디자인이라서
2. 서울버스 앱을 베껴서 


거의 모든 모바일 버스 운행 정보 페이지들이 목록으로 왼쪽에 정류장 명을 정렬하여 보여주고 오른쪽에 노선도와 현 위치의 버스를 보여주고 있습니다. 서울버스 앱이 처음 나왔을때는 이렇게 목록과 그래픽을 섞은 정보디자인이 상당히 참신했습니다. 웹에서는 긴 노선을 가급적 한 화면에 담기 위해 구불구불한 노선도를 사용하였는데 모바일에서는 이런 목록 형태가 적합한 듯하거든요. 하지만 현재의 모습이 정보 전달 측면에서 최선의 디자인은 아닌것 같습니다.

우선 이런 전체 운행 정보 페이지를 누가 왜 보는지 이해할 필요가 있습니다. 저나 주변 사람들의 활용을 알아보니 정류장에 도착하기 전에 버스 운행 상황을 확인하는데 사용하고 있었습니다. 정류장에서 바로 버스를 기다리게 아니라, 집에서 나가기 전이나 버스를 갈아타기 위해 정류장으로 이동 중인 경우에는 처음 도착하는 버스 시간이 아니라 좀 더 나중의 버스 운행 패턴을 알 필요가 있습니다. 좀 더 미래의 더 많은 정보를 얻으면 보다 많은 선택지를 선택할 수 있는 자유가 생기니까요. 정류장에 도착했을 즈음에 얼마나 기다려야 할지 가늠해 보고, 사람이 많이 몰리는 시간이라면 만원 버스를 보내고 연이어 오는 다음 버스를 타야겠다든지 지하철을 타고 가다가 버스로 갈아탄다면 아예 다른 정류장에서 타야겠구나 판단하는데 활용할 수 있습니다. 다른 케이스도 있겠지만 이런 사용 행태가 주가 되는 것 같습니다.


왜 나쁜 디자인이 표준이 되었을까?

저는 현재 통용되는 디자인에 크게 두가지가 문제가 있다고 생각합니다.

가장 거슬리는 문제는 그냥 눈에 보이듯이 버스와 정류장 이름이 양측 정렬 되어있어 매칭이 어렵고 불편합니다. 왼쪽눈으로는 정류장 이름을 보고 오른쪽 눈으로는 버스 아이콘을 보라고 이렇게 한건 아니고 :) 아마 텍스트 목록을 기반으로 노선 그래픽을 부가적으로 덧붙이다 보니까 이런 형태가 나왔을 것으로 생각됩니다. 버스가 어느 정류장을 지나고 있는지가 가장 중요한 정보이니까  디자인을 공부하지 않았더라도 두 정보 요소를 같이 두어야 하는 건 너무 당연합니다. 서울버스앱은 처음에 학생신분의 개인 개발자가 디자인이 아닌 개발에서 출발했기 때문에 이런 모습이 되었다고 생각합니다. 하지만 이후에 정식적인 UI기획,디자인,개발,검수 절차를 거치는 대형 업체들에서도 동일한 형태를 그대로 답습했다는건 문제입니다. 그냥 누가 봐도 이상한데 왜 아무도 이상하다고 안했던걸까요? 대신 변명을 하자면 이상하지 않았을 것 같습니다. 익숙해졌으니까요. 

두번째 문제는 사용 행태에 따른 것인데 버스 노선의 목록 순서입니다. 버스의 출발지에서 종점까지 노선 정보를 받아와서 위에서 아래로 목록을 쭉 나열하여서 버스는 위에서 아래로 운행 합니다. 단지 노선도를 확인하는게 아니라 특정 정류장에 언제 버스들이 도착할지 확인하는 인지 과정을 따라가보면, 목록 위에서 아래로 훑어보면서 기준이 되는 정류장을 확인하고 다음에는 버스들이 어디쯤 오고 있는지를 시선의 방향을 반대로 바꿔 다시 위로 훑게 됩니다. 화면에 다 보이지 않으면 위로 페이지를 스크롤하고요. 우리는 대부분은 한 방향, 아래로 쭉 훑어보면서 아래쪽으로 스크롤을 내려보는데 익숙하기 때문에 이런 방식은 자연스럽지 않습니다. 그래서 어디가 버스 진행 방향인지 매번 헷갈리고요.


버스 운행 정보 디자인 probetyping



이런 문제 제기에서 출발한 리디자인을 해보았습니다. 처음에는 기존 화면을 캡쳐해서 포토샵으로 버스와 정류장 이름만 대충 정렬을 이리저리 바꿔보았습니다. 기존의 디자인을 개선하는 작업이라면 빈 화면에서 시작하는 것보다 이렇게 기존의 이미지를 활용하여 재조합해서 빠르게 아이디어를 시각해보는 lo-fi 프로토타이핑 방법이 유용합니다. 그냥 인쇄해서 오려붙이는 방법도 괜찮고요.
결과가 괜찮아 보여서 나중에 동작하는 프로토타입을 만들어보기로 했는데 몇달이 지나버렸습니다. 최근 감기 때문에 새벽에 깬 김에 대충 돌아가게만 만들어보기로 했다가 재미있어서 몇가지 디테일을 더했습니다. 정보 요소의 정렬과 목록 순서를 바꾸는 것 외에는 계획이 없었는데 나머지는 애자일 방식으로 하나씩 세부요소 디자인을 더해서 써보고 평가하는 방식으로 디자인 하였습니다. 이런 디자인 접근 방식이 정교한 방법론이나 툴보다 좋은 디자인을 만드는데 실질적인 도움이 되는 것 같습니다. 보다 빨리 자주 작은 실패를 경험해야지 디테일에 신경 쓸 수 있거든요. 직접 만지고 조작해보지 않고 화면을 상상해서 그리기만 해서는 디테일을 만들기 어렵습니다. 



버스도착안내 리디자인 by 무이


1. 운행 중인 버스 위치 표시를 버스 정류장 이름 왼쪽에 두어 버스와 정류장 이름이 함께 보이도록 했습니다. 이것만으로 훨씬 보기 좋아졌습니다. 정보 요소의 정렬이 가장 중요합니다.
- 기준이 되는 정류장에는 하이라이트를 주는 것과 더불어서 서있는 사람 아이콘을 넣었습니다. 정류장 이름 정렬을 일부러 깨서 눈에 잘 들어오고 의미적으로도 기다리고 있는, 기준이 되는 정류장이라는게 명확하도록 했습니다.

2. 버스 노선을 반대로 하였습니다. 버스는 아래에서 위로 진행하고 아래쪽이 이전 정류장입니다. 
- 기다리는 정류장을 찾으면 그 아래 보이는 버스들이 오고 있는 버스입니다. 그래서 아래쪽 한 방향으로만 훑어보면 되도록 하여 시선 흐름 유도가 자연스럽습니다.
- 오고 있는 버스를 더 확인하려면 보통 하던대로 아래로 목록을 스크롤 하면 됩니다. 기존 스크롤 습관을 일관되게 유지합니다.
- 기다리는 사람 아이콘과 정류장에 접근하는 버스 아이콘이 실제 버스 정류장에서 버스를 기다리며 바라보는 방향과 일치합니다.
- 네비게이션과 같이 나에게서 멀어지는 방향이 진행방향이 되어 멘탈모델을 형성하기 쉽습니다.


디자인 디테일
 

실제로 만들어진 순서와 거의 동일합니다. 핵심만 만들어서 확인하고 그 다음으로 중요하다고 생각되는 정보요소나 기능이 덧붙여졌습니다.

- 버스 차량 번호를 표시하지 않고 대신 정류장 도착 시간을 표시하도록 했습니다. 차량번호가 특별한 경우에 정말 유용한 정보이겠지만 평상시에는 노이즈입니다. 저상 버스라든지 하는 정보는 일반적인 경우에도 중요할 수 있으므로 잘 보이게 해야겠지만요. 버스에 도착 예상 시간을 표시 한것이 운행 방향의 큐가 되기도 합니다. 지나간 버스에는 시간표시가 없으니까요.  

- 정류장아이디를 정류장 이름 아래에서 오른쪽으로 옮겼습니다. 대부분의 경우 정류장 이름이 아이디보다 훨씬 많이 참조되는데, 왼쪽 정렬된 이름 사이에 다른 요소가 끼어있으면 시선을 방해합니다. 방해되는 정보를 옮기는 것만으로도 정류장 가독성이 훨씬 좋아졌습니다. 정렬이 단지 열과 오를 맞추는것 보다 사용 시나리오에 따른 정보요소의 중요도 순서를 고려하는게 보다 중요합니다. 오른쪽의 정류장 아이디는 기준 정류장을 변경하는 버튼 역할도 하게했습니다. 

- 기준 정류장이 맨 위로 가도록 페이지를 자동 스크롤 합니다. 지나간 버스는 중요하지 않으니까요.  모바일웹에서는 정류장에서 접근해도 기준 정류장을 표시하지 않아서 다시 정류장을 찾아 헤매야 하더라구요. (서울버스앱도 그래서 불만이라고 하고요) 단말 호환성 때문인지, 관심이 없어서인지 잘 모르겠습니다. 웹킷을 사용하는 브라우저는 자동 스크롤 정도는 쉽게 다 되는것 같거든요. 네이버 지도 앱에서도 정류장에서 버스 노선을 선택하면 이렇게 선택된 정류장이 맨 위로 오게 자동 스크롤 해줍니다. 그런데 아래로 보여지는 목록은 이미 지나간 버스라는게 함정. 그래서 목록의 방향이 중요합니다.

여기까지가 새벽에 만든 부분인데 기본 인상은 여기에서 결정 되었습니다.

- 방면 표시를 추가하였습니다. 방향이 반대인 같은 이름의 정류장이 있어서 헷갈릴 수 있거든요. 보통 사용하는 반환점이나 종점이 아니라 진행 방향에 가까운 지하철역명을 표시하게했습니다. 자주 타는 버스 기점이나 종점 아시나요? 대부분 노선의 중간에서 타고 내리기때문에 종점은 관심없는 경우가 많아서 방향을 알려주는 유용한 정보는 아닌 것 같습니다. 다니는 구간 안의 지하철 역은 그나마 잘 아니는것 같고요.

- 비슷한 이유에서 관습적으로 표시하는 기점-종점 정보를 뺐습니다. 버스 도착을 확인하려는 상황에서 별로 의미 있는 정보는 아닐테니까요. 대신 운행 대수를 가장 처음에 보이게 했습니다. 차가 끊겼는지 아닌지는 중요한 정보니까요. 막차가 떠난 정류장도 버스가 끊겼다는걸 알 수 있게 시각화했습니다. 어떻게 표시되는지는 막차 시간에 한번 보세요. :) 저도 그 시간에 잠 안자고 만들었거든요.

- 정류장에도 지하철역은 별도의 지하철 노선 심볼색을 사용하여 눈에 잘 띄도록 했습니다. 지하철 타려고 버스를 연결편으로 이용하는 경우가 많거든요. 또 텍스트로만 된 단조로운 정류장 이름 목록 사이에서 이정표 역할을 하여 노선을 찾아보는데 도움이 됩니다.

- 버스 노선 번호를  실제 번호판과 같이 버스 종류에 따른 색상을 배경으로 강조하여 크게 표시했습니다. 보통 지선,간선 같은 버스 종류 표기와 버스 번호로 두개의 정보 요소로 나누어 표기하는데 색상과 번호를 한덩어리로 인지하도록 했습니다. 지역별로 버스 종류가 다르기때문에 모든 경우에 적용할 수 있는 방식을 택한 것 같은데 효과적으로 정보를 전달하는 방식을 좀 더 고민할 필요가 있을 것 같습니다.

- 처음 로딩시나 새로고침하여 버스 위치가 바뀔때 애니메이션을 사용하여 버스가 움직이게 했습니다. 움직이면 멋질것 같아서 그냥 해봤지만, 버스 진행 방향을 무의식적으로 인지하도록 하는 목적이 있습니다. 

- 마지막으로 버스 위치를 업데이트한 후 얼마나 시간이 지났는지 시각화하여 보여줍니다. 네이버는 업데이트 시각을 표시하는데 최신의 신뢰할만한 정보인지 판단하려면 현재 시간에서 빼는 산수를 해야 합니다. 버스를 타냐 못하냐하는 크리티컬한 정보인데 트위터 만큼도 안해주는건 좀 아쉽습니다. 다음은 보다 친절하게 도착 예상 시간에 타이머를 걸어서 남은 시간이 얼마인지 카운트하면서 보여주고 있는데요. 친절하긴 한데 이게 틀리는 경우가 많아서 오히려 신뢰도가 떨어지기 때문에 적합한 UI라고 하기엔 좀 그렇네요. 여기에서는 부가적인 정보라는걸 감안해서 움직임이 주의를 빼앗지 않도록 표현을 절제했습니다.

- '홈화면에 추가'를 하면 버스번호와 정류장 이름으로 표지판 형태의 독립적인 아이콘을 생성합니다. 즐겨찾기 기능이 있어도 앱을 실행하고 즐겨찾기 기능을 선택하고 또 목록에서 선택하기 까지 여러 인지 과정을 거쳐야 합니다. 자주 확인하는 노선을 개별 앱처럼 홈화면에 꺼내놓고 바로 실행하는 최대한 간결한 형태가 되면 좋겠다고 생각했습니다. 아이콘에는 서울남산체가 아니라 한길체를 사용했습니다.


직접 사용해 보고 평가해주세요

http://lab.pxd.co.kr/bus 

위의 주소로 폰의 브라우저에서 사용해 볼 수 있습니다. 아이폰용으로 테스트했지만 안드로이드에서도 동작합니다. 화면이 조금 이상해지는것 같지만요. url에서 busno를 변경하면 다른 버스 노선을 볼 수 있습니다. 

기본적으로 다음이 제공하는 버스 정보를 가져오고 아이콘이나 DOM구조도 대부분 그대로 차용하였습니다. 디자인 아이디어를 빨리 실험해보기 위한 해킹에 가까운 작업이었기 때문에 정식으로 서비스하기는 어렵습니다.
아이폰과 안드로이드앱으로는 현재 개발 중에 있습니다. 

기존 디자인을 비판 하긴하였지만 하나의 한정된 사용 시나리오가 아닌 다양한 상황의 요구에 따라 더 많은 정보를 담으면서 일관성을 유지하기 위해서는 제약이 많이 생깁니다. 실제 프로젝트라면 안되는 이유가 백만개는 생겼겠지요. 다만 실험을 해보지 않은게 아쉽습니다.

정보 디자인에서 정보 요소의 정렬은  가장 기본적인 디자인 원칙입니다. 익숙한 것들을 기본에서 다시 돌아보는 계기가 되면 좋겠습니다.




이글은 techIT!에 기고한 글입니다.

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




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


Trackback 0 Comment 9
Ad Test...
2012.07.13 11:23

[openUI] Lazy touch scroll 오픈 소스 UI


예전에 소개해 드렸던 아이폰,아이패드에서 웹페이지를 보다 쉽게 스크롤 할 수 있는 Lazy touch scroll UI 스크립트를 오픈 소스로 github에 올려두었습니다. 모두가 더 게으르게 모바일 웹을 사용하는데 도움이 되었으면 좋겠습니다. :)

lazy touch scroll 간단 설명 : 스크린의 좌우 가장자리에 가상의 스크롤바를 만들어서 한 손으로도 쉽게 page up,down을 할 수 있습니다. 터치 휠 기능으로 세밀하게 또는 빠르게 스크롤을 할 수 있으며, 이미지가 잘려보이지 않게 똘똘하게 페이지를 내려줍니다.
 



개발자님, 함께 더 좋아질 수 있게 도와주세요.

https://github.com/taekie/lazy-touch-scroll
github에 자바스크립트 소스를 공개하였습니다. 함께 잘 다듬고, 안드로이드 같은 다른 플랫폼에서도 동작할 수 있도록 도와주세요. 



개인 사용자는 북마클릿을 만들어 사용할 수 있습니다. 

따라하기 동영상 



북마클릿 만들기
1. 아래 코드를 선택 복사합니다.
2. 현재 페이지를 LazyScroll 이란 이름으로 북마크 합니다.
3. 북마크를 편집합니다. 기존 주소를 지우고 복사한 코드를 붙여넣습니다. 
javascript:function%20touchscroll()%7Bvar%20d=document,z=d.createElement('scr'+'ipt'),b=d.body;try%7Bif(!b)throw(0);d.title='(touch)'+d.title;z.setAttribute('src','http://informationredesign.com/lab/lazy_touch_scroll.js');b.appendChild(z);%7Dcatch(e)%7Balert('Please%20wait%20until%20the%20page%20has%20loaded.');%7D%7Dtouchscroll();void(0)


웹 서비스 운영자 & 설치형 블로그 사용자는 사이트에 한 번 시험 적용해 보세요. 
 

아래 코드를 블로그 스킨 html 아래쪽에 추가해주면 iOS 단말에만 추가적으로 터치 스크롤 스크립트가 추가됩니다. 테스트 후 실제 적용 시에는 스크립트 파일을 서버에 복사해서 사용하시면 됩니다.
<script>
if (navigator.userAgent.match(/iPhone|iPod|iPad/)) { 
d=document,z=d.createElement('script'),b=d.body;
z.setAttribute('src','http://informationredesign.com/lab/lazy_touch_scroll.js');
b.appendChild(z);} 
</script>
지금 보시는 pxd 블로그에도 적용되어 있습니다. 아이패드로 pxd 블로그를 보면 쉽게 page up,down을 할 수 있어요. 아이폰으로 보면 모바일페이지로 넘어가니 하단의 [pc화면] 으로 전환해보면 테스트 해 볼 수 있습니다.

이 기능이 적용 되면 좋을 만한 사이트를 알려주세요. 함께 떼로 요청하면 들어 줄지도 모르잖아요 :) 개인적으로 블로그,웹툰,모바일 뉴스 사이트에 적용되면 좋겠습니다. 밀어서 스크롤하는거 너무 귀찮거든요. 안 귀찮으셨어요?


[참고##redesign##]

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


Trackback 0 Comment 5
Ad Test...