태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.


'redesign'에 해당되는 글 15건

  1. 2017.05.19 [design hacking] 다음 뉴스 자동요약 바로 보기 by 無異
  2. 2015.03.11 정류장 맥락을 고려한 버스 노선도 디자인 2/3 –버스 노선도 Redesign 과정과 결론 by 허 지민
  3. 2015.03.10 정류장 맥락을 고려한 버스 노선도 디자인 1/3 – 해외 버스 노선도 사례와 특징 by 허 지민
  4. 2014.12.08 TableTalks 컨퍼런스 시간표 리디자인 (HCI 2015 시간표) by 無異
  5. 2012.07.13 [openUI] Lazy touch scroll 오픈 소스 UI (5) by 無異
  6. 2012.04.13 아이폰,아이패드를 위한 Touch Scroll UI (4) by 無異
  7. 2012.03.08 아이패드를 위한 네이버 모바일 블로그 리디자인 + 데모 (1) by 無異
  8. 2012.02.08 [정보디자인] 하이브리드 이미지검색 데모 (4) by 無異
  9. 2011.12.13 [정보디자인] pagination 안티패턴 (11) by 無異
  10. 2011.11.25 Play! 로드뷰 (1) by 無異
2017.05.19 19:04

[design hacking] 다음 뉴스 자동요약 바로 보기

다음 뉴스에는 기사를 자동 요약해 보여주는 기능이 있습니다. 예전에 야후가 summly 를 인수하면서 이런 뉴스 요약 서비스가 여러가지 의미로 화제가 되었었죠.

다음 뉴스 자동 요약의 품질은 초기에는 만족스러웠던 기억이 나는데요. 오히려 최근들어 기사 앞 문장만 그대로 따오는 경우가 많아서 좀 의문이 들긴 합니다. (두괄식으로 기사를 잘 써서인지) 그럼에도 저처럼 바쁘고 게으른 사람에게는 상당히 유용한 기능입니다.

다음 뉴스 자동요약 기능


버튼 누르기도 귀찮아요. 그냥 펼쳐 보여주세요.

그런데 사용이 그리 편하지 않습니다. 처음에는 클릭하는 방식이었는데 번거럽다는 의견이 있었는지 그나마 현재는 마우스오버만 하면 보여집니다. 이런 기능을 쓰는 사람들 속성을 잘 모르는 것 같아요. 게을러서 버튼에 마우스 옮기는 것도 귀찮거든요. 당연히 처음부터 펼쳐 보여주면 좋겠습니다. 왜 그렇게 안 할까 생각해봤는데 두 가지 정도 이유가 있지 않았을까 싶습니다.


1. 모든 사람이 요약이 펼쳐 보여지는 것을 좋아하진 않는다.

모든 사람에게 자동 요약이 보여지면 당연히 싫어하는 사람이 있습니다. 그래서 사용자 선호에 따라 선택하도록 해야 합니다. 그러면 복잡해 지겠죠. 그런데 별도의 설정 없이도 자동 요약 버튼을 눌러 한 번 펼쳐보면 브라우저 로컬DB에 상태를 저장하고 이 후에도 계속 펼쳐 보여주면 됩니다. 싫으면 토글로 다시 닫으면 되고요. 이런 기능 사용은 기사 자체 보다는 사용자 성향에 더 영향이 있어 쓸 사람은 계속 쓸 것 같거든요.

다만 자동 요약은 기사 본문과 확연히 다르면서 너무 주의를 끌지 않아야 합니다. 요약을 보고 싶지 않으면 별다른 인지 비용 없이 스크롤을 내려 방해 없이 본문을 읽을 수 있어야 합니다.


2. 요약이 바로 보여지면 본문은 안 읽고 바로 나가버릴 수 있다.

두번째는 서비스 제공자 입장에서 요약만 읽고 바로 나가서 사용자를 잃게 되는 걱정이 있을 수도 있을 것 같습니다. 테스트 결과가 있는지 모르겠지만 별로 영향은 없지 않을까 싶습니다. 요약과 상관없이 기사가 좋으면 계속 읽고 나쁘면 바로 닫으니까요.


자동 요약 바로 펼쳐 보기


자동 요약을 본문 앞에 바로 펼쳐보여주기

현재의 팝업 방식보다는 본문 앞에 위치하는 것이 읽기 수월합니다. 자동 요약을 별도 div 요소로 감춰두었다가 마우스 오버시 보여주는 방식인데요. .layer_summary 요소를 prepend를 이용해서 기사 본문 앞으로 옮기고 항상 보이도록 합니다. 그리고 스타일에서 글 상자 형태를 만들어 주고 자동요약이라는 레이블을 붙여줘서 본문과 구분되도록 했습니다.

$(“.article_view section”).prepend($(“.layer_summary”));
$(“.layer_summary”).prepend($(“<span class=summary_label>자동요약</span>”))


코드 https://codepen.io/taekie/pen/gWyOzW


사용자 주의를 뺏는 다단 사용하지 않기

글 줄 길이가 너무 길면 가독성이 떨어지기 때문에 문단 폭을 제한합니다. 넓은 모니터에 여백이 남으면 뭐라도 넣고 싶어집니다. 수익 광고나 사이트에서 벗어나지 않도록 잡아 둘 수 있는 인기 컨텐트 링크를 놓기에 딱 좋습니다. 하지만 이런 요소들은 기사를 읽는데 방해가 됩니다. goodui 에서도 가장 첫번째로 멀티컬럼을 사용하지 말라고 얘기합니다. 다양한 기능보다도 우선 주의를 분산 시키지 않고 메인 컨텐트에 집중 할 수 있도록 만들어 주는 것이 좋습니다.


기사에 집중 할 수 있도록 하는 디자인


저는 개인적으로 부차적인 다단을 없애고 기사에 집중할 수 있도록 디자인을 바꿔서 사용합니다. 이 부분은 광고 수익과 직접적인 관련이 있으니 코드를 공유하기보다 숙제로 남겨두겠습니다. 

다음에서도 뉴스에서만이라도 다단이 아닌 다른 방법을 고민해보면 좋겠습니다. 그렇다고 네이버 뉴스처럼 광고를 기사 머리에 딱 박아 놓는 것은 사용자는 물론 기사한테도 정말 예의가 아니라고 생각합니다. 네이버 뉴스도 좀 적당한 타협점을 고민해 주면 좋겠습니다.



[참고##Design Hacking##]


팀블로그 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.12.08 07:43

TableTalks 컨퍼런스 시간표 리디자인 (HCI 2015 시간표)


이전에 시간표 리디자인 에 대한 글을 쓰면서 pxd LeanUX lab에서는 학회 시간표를 좀 더 잘 만들어 볼 수 있지 않을까 고민하고 있다고 말씀드렸는데요. 이번 HCI 2015 에 맞춰서 진행되는 모습을 미리 보여드리려고 합니다. 아직은 다듬어야 할 부분이 많지만 저희가 생각한 가치가 사용자에게 정말 의미가 있는지 알아보는 유일한 방법은 조금이라도 빨리 직접 피드백을 받아보는 것이니까요.


TableTalks


간단히 설명하면 학회(또는 행사) 시간표의 각각의 셀(발표) 하나 하나에 게시판이 제공되는 서비스 입니다. 컨퍼런스에서 발표가 끝나고 QnA 시간이 있긴 하지만 시간이 한정되어 있고 또 뭔가 궁금한 점은 있는데 질문이 바로 잘 정리가 안되어서 머뭇거리다가 질문 기회를 잃는 경우가 많은 것 같았습니다. 그래서 질의 응답의 기회가 온라인 상에서도 열려있으면 좋겠다는 생각을 했습니다. 실제로 요즘 질문을 온라인 SNS를 통해 받는 경우도 있긴 하고요. 단순히 질의응답에 한정하기 보다는 같은 주제의 같은 관심을 가진 여러 사람들이 같은 공간에 모인다는 것이 굉장히 드문, 흔치 않은 기회인데 발표만 듣고 바로 또 다른 발표를 듣기 위해 흩어지는 것이 아쉽다는 생각을 했습니다. 오프라인에서는 시간이나 공간적인 제약이 있지만 같은 관심을 공유할 수 있는 온라인 공간이 제공되면 이런 제약을 넘어서 뭔가 재밌는 일들이 더 많이 일어나지 않을까 하는 생각에서 서비스 아이디어가 출발했습니다. 

외국의 큰 컨퍼런스 같은 경우에 공식 홈페이지이나 앱으로 세션마다 실시간 대화창을 만들어서 제공하거나 하는 경우도 있는데 저희는 범용적으로 누구나 쉽게 웹(모바일) 시간표를 만들어서 공유(토론) 게시판을 제공하는 서비스를 만들고 있습니다. 큰 규모의 학회만이 아니라 소규모 행사나 인디 밴드 공연 일정등에서 유용하게 사용될 수 있기를 바라고 있습니다. 


1. 보기 편한 시간표 만들기 (모바일에서도 보기 편하게 만들기)


이 서비스를 사용하게 되는 가장 큰 유인은 시간표이기 때문이라고 생각합니다. 시간표는 행사에 참석하는 마지막까지 확인하는 정보이니까요. 이런 공유/토론 게시판이 제공되기에 가장 이상적인 장소인 이유이기도 하고요.
그래서 우선은 시간표를 보기 편하게 만드는데 신경을 썼습니다. 이런 학회의 공식 홈페이지에서의 온라인 시간표(테이블)가 보기 쉽지 않은 이유는 정직하게 HTML table 요소를 사용해서 인 것 같습니다. 중고등학교 시간표처럼 정확한 시간 단위로 짜여져 있는게 아니라 세션마다 일정이 조금씩 다른 경우에 table의 셀에 채워 넣는건 한계가 있는 것 같았습니다. 컨퍼런스 시간표보다는 캘린더 앱에서 일정 표시 사례들을 많이 참고하여 디자인에 적용하였습니다.

학회에 참가해서는 대부분 PC가 아니라 모바일로 접근하니까 모바일에서의 표현과 인터랙션에 신경을 썼습니다. 작은 화면에서 많은 발표장이 있다보니까 모바일에서 가장 좋지 않은 가로 세로 스크롤이 동시에 생길 수 밖에 없는 상황이 됩니다. 스크롤이 되면 장소가 어딘지 시간은 언제인지 알 수 없게 되는 경우가 생기게 되는데 장소가 시간축을 고정하고 내가 어느 영역을 보고 있는지 길을 잃지 않도록 했습니다. 










2. 나의 시간표 만들기

온라인 시간표는 정보 전달의 용도이지 내가 어떤 세션을 들을지 계획해 놓는 매체로는 잘 활용되지 않는 것 같습니다. 실제로 HCI 학회에서도 종이에 인쇄해 나눠 준 시간표에 자기가 들을 발표를 체크해 두는 경우가 많았습니다. 
시간표를 보면서 찜(favorite)을 해서 나만의 시간 계획표를 만들 수 있도록 했습니다. 시간표 상에서는 심볼과 배경색을 사용해서 내가 관심있는 발표를 강조하여 표시하도록 했습니다. 각 게시판으로 이동하는 즐겨찾기는 이것들을 따로 모아 나만의 시간표로 표시하는 안과 일반 목록으로 표시하는 안의 절충안으로 날짜별로 그룹핑된 형태를 제공하고 있습니다.



3. 참가자 간의 공유 공간


온라인 공유 공간이라는 생각을 하면서 일반적인 게시판과 채팅방의 형태 중에서도 많은 고민을 했는데, 공유된 의견이 계속 쌓여서 정보가 되는 모습을 그리고 있어서 게시판이 더 적합하리라고 생각했습니다. 일반적인 카페의 게시판처럼 하나의 글에 댓글이 달리는 형태 보다는 한  주제에 대해서 토론을 할 수 있는 쓰레드 형태의 게시판을 참고하였습니다. 참여를 높이기 위해서 본문이 바로 노출되는 트위터와 페이스북의 형식을 우선 차용하였습니다. 이것이 최선의 형태는 아닌 것 같아서 보다 적합한 게시판 형식을 계속 고민하고 실험 중에 있습니다.





4. 발표자의 홍보 공간


처음에는 사용자로 청중에 포커스를 맞추었는데 개발 회의를 계속하면서 발표자에게 가치를 줄 수 있는 방향에 대해서도 고민을 함께 하였습니다. 사내에서 학회에서 발표했던 분들을 인터뷰 해보았더니, 발표자 입장에서 발표 준비에 시간을 투자하면서 기대하는 것은 보다 많은 사람들에게 내용이 전달되기를 ㅂ 발표자 개인의 입장에서는 홍보할 수 있는 채널이 한정되어 있었습니다. SNS를 통해 소개를 한다고 하여도 개인적인 소개글은 휘발성이 커서 전파력에 한계가 있었습니다. 자신의 발표 세션이 독립된 공간으로 토론을 할 수 있는 공간으로 제공이 되면 사람들에게 알리는데 구심점이 되고 발표 전에 참석자들이 어떤 부분을 궁금해 하는지, 또 발표 후에 피드백을 받거나 발표 자료를 올리고 지속적으로 내용을 공유하는데 도움이 될 수 있을 거라고 생각합니다.
발표 내용이나 발표자 소개를 보다 적극적으로 알릴 수 있는 공간으로써 활용할 수 있도록 고민하고 있습니다. 발표자에게 권한을 주어서 게시판을 꾸미고 관리할 수 있도록 준비하고 있습니다.

 


이번에 HCI 학회에 참가하시는 분이 계시면 사용해 보시고 의견 부탁드립니다. 아직  MVP(minimum viable product) 수준으로 기능 구현이 미흡한 부분이 많지만 버그 리포트도 좋고, 특히 활용 부분이나 필요한 기능에 대한을 의견을 주시면 많은 도움이 될 것 같습니다.

HCI2015 공식 홈페이지 http://hcikorea.sql.co.kr/hcik2015/index.asp
TableTalks x HCI2015 시간표 http://lab.pxd.co.kr/tabletalks/hci2015


No dictionary results were found. Please try another search.
Tip: Didn't want this definition pop-up? Try setting a trigger key in Extension Options.
[참고##리디자인##]

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


Trackback 0 Comment 0
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...
2012.04.13 23:13

아이폰,아이패드를 위한 Touch Scroll UI

아이폰,아이패드의 터치 스크롤은 정말 직관적입니다. 하지만 자주 쓰면 힘들고 귀찮습니다. 화면이 큰 아이패드에서는 더 힘들어요. 컴퓨터에서는 스페이스바로 페이지 단위로 이동하거나 마우스 휠로 손가락만 까닥하면 스크롤이 되는데 실질적인 이동 거리도 늘어나고 손목이랑 팔의 근육도 사용해야 합니다.

그래서 자주 사용하는 웹페이지에 가상의 스크롤 버튼을 만들기로 했습니다.
우선 두가지 원칙을 정했는데


1. 버튼이 충분히 커서 누르기 쉬울 것
2. 버튼이 컨텐트를 가리거나 눈에 거슬리지 않을 것

서로 모순되어 불가능해 보이는데요. 버튼을 투명하게 하고 고정된 위치에 배치하는 것으로 해결 했습니다.


page up,down 버튼 배치


그 다음은 어떻게 버튼을 배치할 것인가인데, 기본적인 page up,down 버튼 영역을 기존 앱들이 하는 방식을 참고하여 생각해봤습니다.


1.은 만화보기 앱 같은데서 사용하는데요. 웹페이지의 경우 하단의 컨텐트 링크를 클릭할 수 없게 되고, 또 상하가 따로 떨어져 있어 사용이 불편하기 때문에 배제하였습니다. 스크롤을 내리다 다시 올려보는 경우가 많거든요.

2. 대부분 페이지의 좌우 영역에 여백을 두고 있으니까 괜찮은 선택입니다. 하지만 한 손으로 쥐고 볼 때 사용이 불편하기 때문에 탈락.

3. 사실 킨들을 사용하고 있어서  처음 부터  이런 구조를 생각하고 있었습니다. 왼손이나 오른손 한 손으로 쥐고 있어도 쉽게 위 아래로 스크롤 할 수 있습니다. 빈도가 높은 page down의 영역을 더 크게 하고요.
그리고 아주 작게 페이지의 끝으로 바로 이동하는 영역을 두었습니다. 

Touch Scroll Wheel


페이지 단위 스크롤이 쉬워지고 나니 이제는 또 한 손으로 미세하게 스크롤을 조절하고 싶어졌습니다. page down을 했는데 이미지가 중간에 걸리게 잘리면 다시 조금 올려서 이미지를 보는 경우가 많았거든요. 손을 떼서 다시 밀어 올리려니 귀찮았습니다.
그래서 터치 영역을 터치패드의 스크롤 휠처럼 사용할 수 있도록 했습니다. 탭하면 페이지 이동 버튼으로 동작하고 터치 한 채로 밀면 스크롤 휠로 동작하는 거죠. 한 손으로 쥐고 엄지로 조작하는 경우가 일반적이라 작은 조작으로도 많이 움직이게 했습니다. 5배 정도로 하니까 적당히 빠르고 또 적당히 세밀한 이동도 가능해졌습니다.

Fast Direct Scroll


스크롤도 되니 이제는 또 원하는 위치로 더 빨리 이동하고 싶어졌습니다. 스크롤바의 thumb을 잡고 바로 이동 하듯이요. pdf 뷰어 앱 중에 thumb이 있는 스크롤바를 제공하는 것이 있는데, 스크롤바가 표시되면 눈에 거슬리니까 화면을 탭해서 스크롤바를 보이거나 가리게 모드를 전환합니다. 이런 방식은 귀찮고 아름답지 않습니다.
애플의 비디오 scrubber bar(seek bar)에서 사용하는 썸을 잡고 움직이다가 아래로 내려서 움직이면 미세조정이 되는 패턴을 반대로 차용했습니다. 테두리 부분을 touch and swipe 하면 상대적인 휠 스크롤이 되다가 손가락을 안쪽으로 옮기면 전체 페이지의 절대적인 위치로 바로 이동합니다. 스크린에서의 손가락 위치가 스크롤 바의 썸처럼 전체 페이지 길이 중에서 현재 페이지 위치가 됩니다.


Image Aware Pgdn


그래도 뭔가 좀 아쉬워요.
지금 이 블로그를 PC에서 읽고 있다면 글을 내릴 때 키보드의 페이지 다운(또는 스페이스바) 사용하나요? 아니면 마우스 휠을 사용하나요? 
전 게을러서 스페이스바를 주로 사용했는데 요즘은 마우스 휠을 더 자주 사용하더라구요. 톡 톡 키보드 누르는 게 더 편한데 왜 휠을 사용할까 생각해봤는데요. 요즘 블로그에 사진이 많아서 그냥 페이지 다운을 하면 사진이 중간에 잘려서 사진 전체가 보이게 스크롤을 다시 올리더라고요. 아하! 
그런 단순 반복적인 작업을 사람이 하면 안되지요. 페이지 다운 하다 중간에 이미지가 걸리는지를 확인하여 이미지가 모두 보이게 스크롤 위치를 조절하도록 했습니다.

일반적인 페이지 다운에서도 텍스트 글 줄이 중간에 걸릴 수 있기 때문에 정확히 window height 만큼을 내리지 않고  조금 위를 더 보여주도록 하고 있는데요. 간혹 이런 고려를 하지 않고 맨 마지막 줄이 중간에 걸려 글자의 윗쪽 반만 보이고 페이지 다운을 하면 글자의 아랫쪽 반만 보여서 결국 읽을 수 없게 만드는 몰상식한 앱도 있더라구요. 텍스트뿐 아니라 이미지도 잘리지 않게 고려해주면 편합니다.







[참고##redesign##]










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


Trackback 0 Comment 4
Ad Test...
2012.03.08 12:25

아이패드를 위한 네이버 모바일 블로그 리디자인 + 데모


누구의 문제인가?

요즘 집에서는 컴퓨터보다 아이패드로 웹서핑하는 경우가 많습니다. 검색을 통해 찾은 블로그를 보는 경우가 많은데 대부분 네이버 블로그 입니다. 사용자가 많아서겠지요. 침대에 누워 빈둥빈둥 블로그를 볼 수 있다는 건 의자에 앉아 pc를 보는 것에 비해 훨씬 편하지만(물론 그전에도 침대에서 노트북으로 봤지만) 네이버 블로그 디자인은 아이패드(아이폰)의 사용행태에 그닥 잘 적합하게 설계되어 있지 않습니다.

블로그 서비스를 제공하는 입장에서 누구를 위해 디자인할지 고민하면 우선 컨텐트를 만들고 트래픽을 가져다 주는 블로거를 고려할 수밖에 없는데요. 네이버 블로그를 운영하지 않고 댓글도 안달고 읽기만 하는 저 같은 사용 행태의 다수의 사용자 입장에서는 좀 불만이 있습니다. 그래서 제 나름의 해결을 공유하려고 합니다.




무엇이 문제인가?


1. readability.
 
네이버 블로그나 티스토리는 현재 아이패드(태블릿)용 페이지는 제공하지 않고 일반 웹페이지를 그대로 보여줍니다. (초기에 네이버 블로그는 모바일 페이지로 리다이렉팅했다가 원본을 보여주는 것으로 바뀐 것 같습니다.) 폭을 고정한 레이아웃이라 더블탭으로 폭 맞춤 확대를 한 상태에서도 글자가 작아 읽을 수가 없습니다. 침대에서 뒹굴거리며 여유있게 읽기에 적합한 크기가 아닙니다. 

모바일 블로그는 그나마 작게,크게 두가지 크기를 지원하며 각각 13px,16px 네요. 해상도 독립적인 pt 아닌 px 단위를 사용는데, 컴퓨터 모니터가 보통 96dpi(윈도우기준) 정도인데 비해 아이패드의 스크린은 130dpi, 아이폰은 160dpi(320x480기준) 라서 컴퓨터에서 보는 글씨보다 작게됩니다. pt로 환산하면 큰 폰트 마저도 대략 8pt (아이폰에서는 7pt) 정도로 보통 리포트가 10-12pt 인데 비해 많이 작습니다. 

게다가 큰 폰트를 선택했을때는 폰트 크기만 키우고 줄높이(line-height) 속성은 그대로여서 줄 간 여백이 거의 없이 글줄이 바짝 붙어 눈을 피곤하게 합니다. 이런 부분은 좀 화가 납니다. 거의 이천만명 정도가 네이버 모바일 블로그를 봤을텐데 디자인이나 개발, 검증의 문제를 따지기 전에 IT 관련 임원은 무조건 타이포그라피 수업을 받아야하는게 아닌가 생각해요. 정말로.


요즘의 블로그 편집기는 작성자의 자유롭고 개성적인 표현이 가능하도록 워드프로세서와 같은 강력한 문단,글자 편집 기능을 제공하고 있습니다. 읽는 사람의 입장에서는 제발 그런 권한을 좀 뺏았으면 좋겠습니다. 가운데 정렬, 심지어 오른쪽 정렬하는건 글을 읽지 말라는 것 같거든요.  

요즘 flipboard 같은 매거진형 aggregator를 많이 쓰는데 무엇보다 글자를 읽기 편해서 입니다. pc환경에서는 모르겠지만 모바일 버전에서는 작성자가 지정한 폰트 설정을 좀 제한하더라도 블로그를 읽는 사람이 좀 보기 편하게 보여주어야 한다고 생각합니다.

ios의 한글 폰트 applegothic은 못 생기기로 유명하여 웹폰트를 사용하여 나눔고딕으로 대치하면 좀 보기 좋습니다. 
 

2. bouncing rate.

네이버 이웃 처럼 즐겨찾기한 블로그를 주기적으로 방문하는 것 보다는 아이 데리고 놀러갈 데나 먹을 곳를 키워드로 검색해서 블로그를 주로 읽습니다. 여기 pxdstory 블로그도 검색을 통한 접근이 70% 정도고 나머지가 재방문입니다. 그러니까 실제 방문자 수는 아마 80% 이상이 검색을 통해 처음 이 블로그를 접할 것 같습니다. 검색된 글만 읽고 닫는 경우도 있지만 내용이 괜찮으면 다른 글도 읽어보게 됩니다. 관심사가 비슷하면 다른 글도 도움이 될 확율이 높으니까요. 

그래서 본문에 이어 바로 글 목록을 보여주면 나갈지 좀 더 머물지 판단에 도움이 됩니다. 현재는 본문에 이어 이전,다음글의 제목 링크가 보이긴 하는데 블로그 글을 순차적으로 읽는 경우가 없어서 별로 도움이 되지 않습니다. 즐겨찾기한 블로그라서 대부분의 글을 모두 읽는 경우라도 목록에서 가장 관심이 가는 글부터 골라 읽지 그냥 순서대로 읽는 경우는 드물거든요. 대부분의 사용자가 prolog처럼 블로그의 성격을 한 눈에 볼 수 있는 블로그의 첫페이지를 거치지 않고 검색을 통해 블로그 본문으로 바로 이동합니다. 모든 페이지가 랜딩페이지가 되므로 전체 블로그의 성격을 보여줄 수 있는 요소가 노출되도록 하는게 좋습니다.

목록 버튼이 있긴하지만 현재 보고 있는 페이지와 상관없이 목록의 가장 처음으로 매번 이동하기 때문에 근본적으로 목록을 훑어보면서 원하는 글만 골라 보기에는 자연스럽지 않고 번거로운 구조입니다. 목록 페이지로 직접 이동을 할 수 없으니 처음부터(오래된) 글 부터 보기는 불가능합니다.
보통 이전 버튼을 눌러 왔다 갔다 pogo-sticking 을 하게되는데 본문에 글 목록이 연이어 나오는게 일반적인 글읽기의 흐름에 더 자연스럽습니다. 
 pagination 안티패턴

모바일 티스토리는 본문을 다 읽고 나면 이어서 다음 검색 실시간 이슈 목록을 노출하고 있는데요. 간절한 마음은 전해지지만 좀.. 안스럽습니다. 


3. repetitive strain injury.

터치를 이용한 스크롤은 아이들도 바로 따라할 수 있을 만큼 직관적입니다. 배우기도 쉽고 원하는 위치로 정확히 이동하기도 편리하고 다 좋긴한데 귀찮고 힘듭니다. 폰에서는 손가락만 좀 튕기면 되지만 아이패드는 화면이 크다보니 동작이 커지거든요.
이게 ios 문제지 블로그 문제냐고요? 네. 게으른 제 문제입니다. 
큰 화면 스크롤하는게 귀찮아서 리디자인 된 블로그에는 자체적으로 스크롤바 기능을 만들어 넣었습니다. 이 부분은 별도로 포스팅하려고 합니다.


리디자인

네이버 모바일 블로그에 없는 기능은 없습니다. 다 할 수 있습니다. 하지만 그 기능들이 내가 사용하는 행태나 작업 흐름에 적합하게 구조화되어 있지 않습니다. 기능을 뽑아 나열하기 전에 누가, 왜 ,어떻게 사용하는지 사용 흐름을 이해하는 것이 필요합니다. 물론 사람마다 제각기 사용 하는 방식이 다르니까 누구에 맞춰서 디자인을 해야하는가가 진짜 문제이긴 하지만요. 저와 같이 사용하는 사용자는 무시하는 것도 퍼소나를 활용하는 좋은 방법이거든요.

암튼 그래서 전 제가 사용하는 행태에 맞추어 리디자인된 블로그를 이용합니다. 아이폰에서도 아이패드에서도 사실 pc에서도 이렇게 블로그를 봅니다. 사실 제가 보고 싶은 건 블로거가 만든 블로그가 아니라 내용만 쏙 뽑아낸 RSS 리더인지도 모르겠습니다.


데모 사이트

* 사이트 개편으로 현재는 동작하지 않습니다.
http://lab.pxd.co.kr/lazyblog/naver_blog.php?blogId=majosady

아이폰 아이패드로 접속하면 됩니다. 블로그 주소를 넣어주면 변환하여 보여줍니다. 
 


주.

- 실제 이용시에는

1. 블로그 페이지에서 북마클릿을 이용하여 변환하고 있습니다.
2. 자주 가는 블로그는 변환된 주소를 북마크 해두고 있습니다.
3. 바로 변환된 주소를 링크한 검색 엔진을 사용합니다. 검색엔진 리디자인

- uxcampseoul 2010 날로먹는UI디자인방법론 33p 이후 케이스스터디 '네이버 블로그 리디자인' 으로 발표한 내용인데 너무 오래되어서 아이패드용이라고 이름 붙였습니다. :) 처음부터 아이폰,아이패드에 대응하도록 만들어졌거든요.

- ios 5.1이 배포되어서 한글 폰트에 대한 불만은 조금 해소되었습니다.

[참고##리디자인##]



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


Trackback 0 Comment 1
Ad Test...
2012.02.08 13:56

[정보디자인] 하이브리드 이미지검색 데모

정보디자인 - 하이브리드 이미지검색  에서 소개한 이미지 검색 UI 의 데모 페이지를 열어두었습니다.

특징은

1. 썸네일 방식과 미리보기(큰 이미지)를 결합한 UI를 사용합니다. 
특정 이미지를 찾아내려는 것 보다는 빠르게 검토해 보려는 사용 패턴에는 썸네일과 원본 이미지를 왔다갔다하는 번거러운 pogosticking 이 빈번합니다. 썸네일과 함께 적당히 큰 원본 이미지를 한꺼번에 보여줘서 빠르게 훑어볼 수 있도록 하였습니다. 개인적으로는 이런 행태의 이미지 검색을 더 많이 하고 있습니다.

2. 그리드 방식이 아닌 타일 방식의 이미지 정렬을 사용합니다.
이미지간의 여백을 줄여 시선의 움직임을 최소화하여 눈의 피로를 줄이도록 하였습니다.

3. auto paging을 사용합니다.
다음 페이지 버튼을 누르지 않고 스크롤만 하면 검색 결과를 계속 볼 수 있습니다.

4. iPad ready
PC, 아이패드 동시에 사용하도록 만들었습니다.


데모 페이지
http://lab.pxd.co.kr/imagesearch/?q=mobile%20ui%20pattern



리서치를 할때 많이 유용합니다. 아이패드에서 아이한테 동물이나 자동차 그림을 찾아줄 때도 좋았고요.
기존의 구글이나 네이버 이미지 검색과 비교해 보시고 사용경험을 공유 부탁드립니다.

실제 이미지 검색 결과는 구글이미지 검색을 이용하고 있습니다.

[참고##redesign##]    

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


Trackback 0 Comment 4
Ad Test...
2011.12.13 18:24

[정보디자인] pagination 안티패턴

이 글을 웹에서 보고 계시다면 페이지의 맨 아래에 페이지 번호가 쭉 나열된 걸 보실 수 있을텐데요. 이런 UI 요소를 pagination 이라고 합니다. 블로그 글 목록이나 검색 처럼 자료의 양이 많으면 한 번에 표현하기 어려우니까 페이지 단위의 청크로 나눠서 보여주고 쉽게 원하는 부분으로 이동할 수 있도록 하는 UI 패턴입니다. 



좀 더 많은 pagination 디자인 유형은 스매슁매거진 기사에 잘 정리가 되어 있습니다.
http://www.smashingmagazine.com/2007/11/16/pagination-gallery-examples-and-good-practices/






이런 익숙한 UI 나빠요

이렇게 페이지 숫자들과 이전,다음이 나열되어 있는 형태는 상당히 많이 쓰이는 익숙한 UI인데요. 그냥 관습적 쓰일 뿐이지 사용성 측면에서는 실제 사용 행태를 반영하지 않은 나쁜 UI 패턴이라고 생각합니다. (페이지네이션의 사용 맥락에 따라서 다를 수 있으므로 블로그 글 목록으로 한정하도록 하겠습니다.)

페이징 사용 행태

실제 페이징을 하는 사용자 행태는 다음(이전) 목록을 순차적으로 보는 것이 가장 빈번하고 특정 페이지로 점프하는 경우는 상대적으로 적습니다. 대부분의 경우는 어떤 항목이나 글이 있는지 예상을 못하기 때문에 목록을 순차적으로 쭉 훑어보게 됩니다. 목록의 처음이나 끝으로 이동한다든지 새로운 글을 보기 위해 마지막 봤던 페이지로 이동하든지, 관심없는 글들을 스킵하거나 예전에 봤던 글을 찾기 위해 해당 날짜로 빨리 이동 한다든지, 무언가 예측 가능한 경우에만 특정 페이지로 점프하고요. 그렇게 사용하시죠?

이렇게 주 사용 행위가 나머지 행위의 사용 빈도 차이가 큰 경우에 primary action이라는 패턴을 사용합니다. 자주 쓰는 건 크게 강조하고 잘 안 쓰는 건 약하게 표시해야 보기도 편하고 조작도 쉬워집니다.
강조라는 것은 상대적이어서 중요한 걸 크게 하는 것보다 중요도가 적은 것에 주의가 적게 가도록 하고 노이즈를 줄여 주는게 더 효과적입니다. 선택지가 많으면 반응 시간이 느려질 테니까요. http://en.wikipedia.org/wiki/Hick's_law 


페이지 번호 나열을 보여줄 필요가 있나요?

이런 사용 행태를 고려하면 페이지 번호 나열을 없애는게 좋습니다. 페이지 번호 나열은 대부분의 경우에 불필요한 노이즈입니다. 검색 결과나 빈번하게 업데이트되는 SNS timeline 같은 경우에 페이지를 예측하기 어려우니까 특정 페이지로 점프하는 기능을 없애고 단순히 더 보기만을 사용하는 UI 사용이 늘고 있습니다. 네이버 블로그나 티스토리의 모바일 페이지가 이런 패턴을 사용하고 있는데요. 하지만 이건 또 잘 못 적용한 것 같습니다. 블로그는 검색이나 타임라인과는 성격이 달라서 극단적으로 페이지 이동을 없애면 또 불편하더라구요. 검색을 통해 접근한 블로그를 목록과는 반대로 시간순으로 훑어보려고 해도 페이지 이동이 안되니까 답답합니다.



그냥 링크를 다 보여주세요

페이지 번호 나열의 또 나쁜 점은 페이지라는 청크를 다시 10개 정도의 페이지 번호 청크로 나누어 인접 영역으로만 이동하도록하는 귀찮은 구조이기 때문입니다. 특정 페이지로 이동하려는 경우에 복잡한 페이징 구조를 만들게 아니라 그냥 전체 페이지 링크를 다 보여주는게 심플하고 좋습니다. 테이블 형태로 전체 페이지를 표시하면 현재 위치를 확인하는데도 수월하고요. 물론 항상 전체 페이지를 모두 보여주면 복잡하니까 처음에는 가려 두었다가 필요한 경우에 펼쳐 보이도록 합니다. ios의 리스트에서도 primary action 은 항목을 탭하는 것으로, secondary actions은 기능을 감추어 두었다가 detail disclosure button이란 파란 화살표 버튼을 누르면 상세 기능이 펼쳐지도록(상세페이지이동) 합니다.


실제로 구현을 해보면 모바일에서는 이전 다음을 하단에 배치하는 것보다 이전을 목록의 상단에 두고 목록을 계속 추가하는게 사용이 더 편리했습니다.





지금도 목록을 만들고 그냥 생각없이 페이지 번호를 그려넣고 있지는 않나요?




[참고##Pagination##]

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


Trackback 1 Comment 11
Ad Test...
2011.11.25 11:49

Play! 로드뷰


아이가 토마스 기차 놀이만 하더니 요즘 로보카 폴리와 디즈니 카2를 보고나서는 자동차도 가지고 놀고 있습니다.  놀이매트에 자동차 길이 그려 있어서 같이 자동차 경주를 하자고 했는데 별로 흥미가 없더라구요. 아이는 재미없어했지만 저는 장난감 자동차 가지고 놀면서 실제 로드뷰가 보이면 재밌겠다 싶은 생각이 들었습니다. 그래서 만들어봤습니다. 







원리는 단순합니다. 
아이패드의 지도 위에 자동차 장난감이 놓여있는 위치와 방향을 로드뷰로 보내서 보여주는 거지요.

장난감 바퀴 부분에 컬러 점토를 붙여서 3개의 접점을 만들었습니다. 점토가 굳어도 약간 수분이 남아있는 상태에는 전도체 역할을 합니다. (동영상을 찍을 당시는 점토가 너무 굳어버려서 약간 인식이 잘 안되었습니다) 자동차도 쇠로 되어 있어서 손으로 쥐고 있으면 3점을 누른 것처럼 되는 거지요. (디즈니에서 이런 형태의 appmate라는 장난감을 판매하고 있습니다.)
삼각형의 형태를 인식해서 장난감의 방향을 알아내고 접점의 위치를 가지고 지도 상의 위,경도를 다시 계산해서 보내주면 해당하는 로드뷰 화면이 표시되는 거지요.

아이가 동영상을 보더니 나도 하고 싶다고 굉장히 흥미를 보이네요.

요즘 입력 장치가 마우스에서 터치로 옮겨가고 있는데 좀 더 tangible한 인터랙션에 대한 방법을 고민하고 있습니다.

[참고##redesign##]  


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


Trackback 0 Comment 1
Ad Test...