태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.


'iPhone'에 해당되는 글 12건

  1. 2012.07.13 [openUI] Lazy touch scroll 오픈 소스 UI (5) by 無異
  2. 2012.04.13 아이폰,아이패드를 위한 Touch Scroll UI (4) by 無異
  3. 2012.03.08 아이패드를 위한 네이버 모바일 블로그 리디자인 + 데모 (1) by 無異
  4. 2011.07.15 사용자의 80%만을 위해 디자인하라 - Apple Human Interface Guidelines의 역사 (3) by 이 재용
  5. 2010.12.05 [UI 디테일] Personal Network Service ‘Path’ (8) by 위승용 (uxdragon)
  6. 2010.11.25 모바일 앱 설정 UI 가이드 (11) by 無異
  7. 2010.07.26 스타일러스 펜 vs 손가락. 아이패드에서라면? (7) by 허 유리
  8. 2010.07.25 아이폰 앱 시작 아이콘은 어떤 색깔을 제일 많이 사용하고 있을까? (8) by 위승용 (uxdragon)
  9. 2010.07.19 작은 차이에서 완성도를 보여주는 아이폰 UI (13) by 비회원
  10. 2010.06.22 [정보디자인] 모바일검색 suggestion UI by 無異
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...
2011.07.15 18:29

사용자의 80%만을 위해 디자인하라 - Apple Human Interface Guidelines의 역사

UI 디자이너에게 표준을 지키는 일은 중요하다.
그러나 지난 번 글(UI 디자이너는 표준을 지켜야 하는가?)에서 밝혔듯이 표준을 지키는 일이 그리 쉽지는 않다. 하지만 많은 사람들이 이미 따르는 표준이라면 그 중요성은 배가된다. 특히 자신이 개발하고 있는 플랫폼의 표준을 익히고 따르는 것이 매우 중요하다. 이해를 돕기 위하여 4회에 걸쳐서 Mac OS 표준, Windows OS 표준, 그리고 ISO(International Standard Organization) 표준의 역사에 대해서 알아보기로 한다.

1. 사용자의 80%만을 위해 디자인하라 - Apple Human Interface Guidelines의 역사
2. 마침내 혼란을 극복한 Windows7 - Windows User Experience Interaction Guidelines의 역사
3. 그들만의 리그, 우울한 ISO UI 표준 - ISO 13407 & ISO 9241의 역사
4. 왜 어떤 가이드라인은 실패하는가? - 말보다 행동이 중요하다

참고 UI 디자이너는 표준을 지켜야 하는가? (http://story.pxd.co.kr/317)
안드로이드 UI/GUI 가이드라인 (http://story.pxd.co.kr/162)
Windows 7 Design Principles (http://story.pxd.co.kr/13)



1. 사용자의 80%만을 위해 디자인하라 - Apple Human Interface Guidelines의 역사

UI 개발자에게 표준을 따르는 일은 매우 중요하다. 특히 운영체계(Operating System)의 표준을 따르지 않으면 사용자에게 많은 혼란을 일으키기 때문에 치명적인 불편을 안겨줄 수 있다. 그렇기에 각 OS에서 제공하는 가이드라인을 숙지하는 것이 꼭 필요한 일이다.

하지만 이 Apple의 가이드라인은 여느 OS의 가이드라인과는 다른 위치를 차지하고 있다. UI에 관해 변변한 서적이 없던 시절, 유일하게 교과서적으로 이론을 배울 수 있을 뿐만 아니라 실무적으로 필요한 지식과 팁을 한 번에 배울 수 있는 서적이었기 때문이다. 하지만, 이제 볼 수 있는 책이 많아진 오늘날에도, Apple이 차지하고 있는 UI의 독보적 탁월함에 동의하는 사람이라면, 설령 자신이 Mac OS에서 UI를 개발하지 않더라도, UI 디자이너라면 언젠가는 한 번 꼭 보아야할 책이라고 생각하여 소개한다. (Apple의 기업 문화나 UCD와의 관계에 관해서는 Apple 디자인 성공의 비밀과 UCD)참고.

Apple은 자신의 OS에 대한 가이드라인을 Addison-Wesley와 함께 1985년부터 출판하고 있다. 맥 OS의 역사와 함께 Apple 가이드라인의 역사를 살펴보고자 한다.


1985년 Human Interface Guidelines: The Apple Desktop Interface

Human Interface Guidelines: The Apple Desktop Interface

1984년 1월 24일 애플의 OS인 System 1.0 이 출시되고, 1985년 4월에 System 2.0 이 출시된다. 처음 1985년에 출판된 가이드라인은 찾을 수가 없고 pxd 도서관에 소장하고 있는 것은1987년 11월 판이다. 1987년 11월이면 System Version 3.3 이고, 책에 언급하고 있는대로 Finder Version 5.5를 기준으로 설명하고 있는 책이 되겠다. 다행히 책 뒷면에 보면 원래 책 디자인을 커버만 다르게 한 것이고, 내용은 동일하다고 설명하고 있다.

책의 서문을 보면 매우 감동적이다.

서문에서 데스크탑 소프트웨어의 장점이 '일관성'을 유지해서 사용자가 쉽게 학습할 수 있게 하는 것이 최대 장점이므로 이 가이드라인을 통해서 일관성을 유지하도록하고, 예외적으로 이 가이드라인을 따르지 않으면서도 좋은 소프트웨어들이 있긴 하지만, 충분한 이유가 있을 때만 그러한 예외를 추종하도록 강조하고 있다.

제1장 '철학' 부분에서 애플은 사용자를 어떻게 보는가에 대해 설명한다
People aren't trying to use computers - they're trying to get their jobs done.
그러나 사람들의 일이란 얼마나 창조적이고 예술적인가에 대해 충분히 설명하고 있다.

1장에서 애플이 제시하는 10가지 디자인 원칙을 옮겨보면,
Mataphors from the real world
Direct manipulation
See-and-point (instead of remember-and-type)
Consistency
WYSIWYG (What you see is what you get)
User Control (not computer)
Feedback and dialog
Forgiveness
Perceived stability
Aesthetic integrity

Principles of graphic communication 부분에서는, Visual Consistency, Simplicity, Clarity 등을 별도로 제시하고 있다. 흥미로운 것은 '프로그래머'를위한 철학도 있는데, Modelessness, Event loop(언제나 사용자 이벤트를 받아들여라), Reversible actions, Screen(화면을 중시해라), Plain language가 들어있다. 아마도 당시에는 이런 부분들에 대한 정책은 프로그래머들이 정한 듯 하다. (물론 plain language를 위하여 전문 writer를 고용하라는 말도 들어있다)

또 1장에서는 User testing과 장애인에 대한 고려 사항에 대해서도 설명하고 있다.

2장부터는 각 화면 요소와 구성을 하나씩 설명한다. 특히 흥미로운 부분은 다이알로그 박스에 들어있는 Cancel-Ok 버튼 순서에 관한 설명인데, 이 부분은 설명이 기니까 별도의 기사로 쓸 계획이다.


1992년 Macintosh Human Interface Guidelines

Macintosh Human Interface Guidelines

1987년과 1992년 사이에 애플에서는 'Inside Macintosh' 시리즈를 통하여 각 부분 부분별로 Guideline에 대하여 설명하여 왔던 것 같다. 그리고 Human Interface Notes라는 것도 출판했다고 하는데 전혀 찾을 수가 없다. 사람들에게 가장 대중적으로 읽히고, 또 오늘날 Guideline계의 교과서라고 할 수 있는 Macintosh Human Interface Guidelines는 1992년에 처음 출판되었다. (아마존에서는 2판 판매)

이 책은 맥의 중흥기랄수 있는 System 7 (1991년 5월 출시)을 대상으로 하고 있다. System 7은 그 중간에 PowerPC 칩 적용으로 맥이 본격적으로 많은 사람들의 사랑을 받게된 시기이기도 하다.

 

서문에서 디자인 원칙으로
Mataphors
Direct manipulation
See-and-point
Consistency
WYSIWYG (What you see is what you get)
User Control
Feedback and dialog
Forgiveness
Perceived stability
Aesthetic integrity
Modelessness

이렇게 11가지를 설명하고 있다. 이전의 10개에 프로그래머용 철학 중 Modelessness를 추가하여 11가지가 된 셈이다.

글 서두에 거의 유일한 '실무 교과서'였다고 했듯이, 책의 전반부(Part One)는 다양한 원칙, 팁, 프로세스 등으로 가득차있다. 사용자 관찰 10단계, 복잡성 대처법, 인터페이스 확장법, 시장 요구 대응법 등을 포괄하고 있다. 특히 80% 솔루션에 대한 이야기가 처음 등장한다. 사용자의 80%만 만족시키려고 하면, 매우 단순한 제품이 나온다는 뜻이다. 나머지 20%까지 만족시키려는 순간 망한다는 말이다. 1992년에도 그들은 이걸 알고 있었다.

Part Two에서는 인터페이스의 다양한 요소들에 대해 설명한다. 앞의 책에 비해 언어 부분이 추가되었으며, 여러 리소스들을 부록에 포함시키고 있다. (당시로서는 매우 소중한 리스트였다)


2000년 Apple Human Interface Guidelines

Apple Human Interface Guidelines

2001년 3월 24일 정식 출시된 Mac OS X는 오랜 동안 클래식 맥 OS의 불안정함을 깬 역작이라고 할 수 있다. 초기 골수 사용자들로부터 반대도 많았다고 들었지만 한단계 도약이었음에 틀림이 없다. 디자인면에서는 이전부터 하드웨어에서 사용하던 반투명 디자인을 화면에 옮겨 'Aqua'를 시도하였던 것으로 유명하다. 알파와 베타 버전이 나오던 기간에 이를 위한 가이드라인은 여러 가지 이름으로 불렸다. 2000년 1월 20일에 나온 'Aqua Layout Guidelines'는 'Adopting the Aqua Interface', 'Inside Mac OS X: Aqua Human Interface Guidelines', 등을 거쳐 결국 지금의 이름인 'Apple Human Interface Guidelines'가 되었다.

이 때부터 책으로 나오지 않았기 때문에 온라인에서 언제나 접할 수 있는 장점이 있는 반면 예전 버전은 쉽게 찾을 수 없는 아쉬움이 있다. Pxd 도서관에는 2003년에 만들어진 (OS X 10.3 정식 발표 이전에 배포한)가이드라인 출력물을 보관하고 있다(사진).

 

이 책에서는 11개의 디자인 원칙으로
Mataphors
See-and-point
Direct manipulation
User Control
Feedback and Communication
Consistency
WYSIWYG (What you see is what you get)
Forgiveness
Perceived stability
Aesthetic integrity
Modelessness

등 같은 항목을 약간의 용어를 달리하고, 순서를 달리하고, 설명 분량을 줄여서 기술하고 있다. 또한 더 간략해지긴 했지만, 각종 방법들에 관해 설명한다.

이 시기 책에서 처음 'Experience' 라는 말을 사용한다. 'The Macintosh Experience' 에 대해 설명하면서, 포장, 설치 등에서 일관된 경험을 요구하고 있다. 이 버전부터 (이전 버전에서 열을 내어 설명하던) OK-Cancel 로직 부분이 대거 빠지게 된다. (그림 속에 아주 간단히 나타내는 정도) 그리고 재미있던 어펜딕스들이 대거 빠져 나갔다.


2006년 Apple Human Interface Guidelines

Pxd에서 보유중인 2006년 10월 3일자 가이드라인에는,'좋은 소프트웨어의 특징(Characteristics of Great Software)'라는 부분이 추가되었는데, High Performance, Ease of Use, Attractive Appearance, Reliability, Adaptability, Interoperability, Mobility가 그것이다.

 

또한 이 책에서는 12개의 디자인 원칙으로
Mataphors
Reflect the User's Mental Model
Explicit and Implied Actions
Direct manipulation
User Control
Feedback and Communication
Consistency
WYSIWYG (What you see is what you get)
Forgiveness
Perceived stability
Aesthetic integrity
Modelessness
를 제시하고 있다.

Macintosh Experience 파트에서 '포장'이나 '인스톨'부분은 다 뒤로 돌려 버리고, 그냥 소프트웨어적인 부분 설명하는 것을 맨 앞에 두었다.

Pxd에서 보유중인 2008년 1월 15일자 가이드라인에는, 2007년 10월 26일에 출시된 레오파드 Mac OS X v10.5 업데이트 내용을 반영하였으며, 이 즈음부터 책(PDF) 표지에 파란색 글씨로 'User Experience'라는 말이 들어갔다.


2011년 Apple Human Interface Guidelines

Apple Human Interface Guidelines

마지막으로 현재(2011년 7월) 인터넷 (애플 개발자 라이브러리)에서 다운로드 받을 수 있는 버전은 2011년 5월 31일 판이다. 트랙패드에서의 동작 인식에 관한 것이 추가되었다. 이전 책에서 사용자 입력에서 마우스, 트랙볼, 스타일러스 펜만 언급하였다면 트랙패드가 하나의 부분으로 추가되어, 핀치나 three finger swipe, four finger swipe 등에 대해 설명하고 있다.

Metaphors, Mental Model(Familiarity, Simplicity, Availability, Discoverability), Explicit and Implied Actions, Direct Manipulation, See and Point, User Control, Feedback and Communication, Consistency, WYSIWYG (What You See Is What You Get), Forgiveness, Perceived Stability, Aesthetic Integrity

이상으로 간단(?)하게 Apple Human Interface Guideline의 역사를 살펴보았는데, 예전 책을 들쳐보며 차이점을 찾은 것은... 사실 당장은 최영완님의 OK-Cancel에 관한 글을 읽다가 시작한 일인데, 개인적으로 재미있어서라기 보다는 누군가 한 번쯤 해 두면 다른 사람들이 편리하게 사용할 수 있을 것 같아서이다.

다음 글에서는 '2. 마침내 혼란을 극복한 Windows 7 – Windows User Experience Interaction Guidelines의 역사'에 대해서 살펴볼 것이다.

 

참고

iOS(iPhone,iPad,iPod)에 관심이 없더라도 꼭 보길 권한다.
iOS Human Interface Guidelines (Web) - 2014.01.11 수정함
iOS Human Interface Guidelines (PDF)


[참고##가이드라인##]



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


Trackback 0 Comment 3
Ad Test...
2010.12.05 22:13

[UI 디테일] Personal Network Service ‘Path’




글을 시작하며

안녕하세요. 오랜만에 글을 작성하게 되었습니다. 요즘 PXD 사람들은 Path라는 아이폰 어플리케이션에 푹 빠져 지내고 있습니다. 본 포스팅에서는 Path 어플리케이션에 대해서 알아보고 사람들이 이 서비스에 빠져드는 이유가 무엇인지 살펴보도록 하겠습니다.


그렇다면 Path 란 무엇인가? Path가 등장했는가?

'Path'‘Personal Network Service’ 라고 볼 수 있습니다. 또한 Path는 현재 아이폰 앱 을 중심으로 서비스 되고 있습니다. (현재 웹에서는 이미지 확인밖에 할 수 없으며, 웹 혹은 안드로이드 폰으로 확산될 것으로 예상합니다.) 'Path를 설립한 사람들을 살펴보면, 전 페이스북 시니어 플랫폼 매니저인 Dave Morin, Dustin Mierau 공동개발자 Macster, 냅스터 공동 설립자 Shawn Fanning 등입니다. Path 가 주목받는 것은 이런 공동설립자와 투자자들에게 있습니다.' [인용]

Path가 기존의 Twitter Facebook 같은 Social Network Service와 대비되는 가장 큰 차이점은 바로 ‘Social’ 이 아니라 ‘Personal’ 이라는 점입니다. Path는 개인과 최소한의 주변 사람을 중심으로 하고 있습니다. 그 동안 Twitter Facebook을 중심으로 한 Social Network Service는 개방, 확장을 중심으로 급속도로 성장하고 있었습니다. 그와 동시에 Social Network Service에서의 사생활 노출 문제가 대두되었습니다. Facebook에서 직장상사 험담을 하다 직장을 잘린 한 여성이 단적인 예라고 볼 수 있습니다

또한 모든 사람들이 Social 한 것은 아닙니다. Social 한 커뮤케이션 니즈가 있는 사람들(불특정 다수, 혹은 관련 분야의 사람들과 폭넓은 소통을 하고 싶은 사람)이 있지만, Personal 한 커뮤니케이션 니즈가 있는 사람(한정된 내 친구들과의 소통을 원하는 사람)도 있습니다. Path는 바로 ‘Personal’에 집중을 하고 있습니다.


[path 소개 영상]


Path 어플리케이션의 특장점

1. 간단한 입력방식, 이미지 중심 타임라인을 사용하여 손쉽게 사용 가능하고, 감성을 극대화함

실시간 사진’, ‘사람’, ‘장소’, ‘행동’ - 끝 -

(정말 끝이야?)

[그림1] Path 포스팅 화면 

Path에서 글을 쓸 때 입력해야 할 정보는 이게 끝입니다. 심지어는 실시간 사진만 있으면, 사람, 장소, 행동을 입력하지 않아도 됩니다. Path는 버전을 업그레이드하면서 미리 찍어놓았던 사진도 사용할 수 있게 바꾸었습니다. 이 때도 찍은 사진의 시간을 중심으로 하고 있습니다. 그만큼 실시간성을 강조하고 있습니다.

Path현장 이미지 중심으로 되어 있습니다. 그렇기 때문에 실시간성이 있고, 감성을 극대화 시키는데 일조합니다. 사람, 장소, 행동 정보는 입력하지 않아도 되지만, 사진을 꼭 찍어야 포스팅을 할 수 있습니다. 리스트도 이미지 중심으로 구성되어 있기 때문에, Path에서 이미지는 큰 비중을 차지하고 있습니다장소는 내 찍은 사진 뿐만 아니라, 모두가 찍은 사진의 장소를 풍부하게 보여줍니다행동은 내 행동 뿐만 아니라, 주변 사람들의 행동까지 보여주어 입력을 편하게 도와주고, 감성을 극대화시키는 역할을 합니다.(나 혼자 글을 쓰는게 아니구나... 같은 느낌일것 같습니다.) 물론 처음에는 포스팅 화면에서 어떻게 입력해야 할지 당황할 수 있습니다. 이 점은 익숙해지면 해결될 수 있는 문제겠지만, 사용상의 문제도 있기 때문에 개선의 여지가 있습니다.

Path댓글 달기 기능이 없습니다. 대신에 이미지를 본 사람들을 표시해줍니다. 이미지를 본 사람들은 7명까지만 순서대로 보여지며, 더 보기 버튼을 선택하면 이후에 본 사람들을 볼 수 있습니다. 이미지를 본 사람들을 보여주는 것은, 제한적 소통의 극대화라고 볼 수 있습니다. 댓글달기 및 추천 기능이 없는 Path의 경우 내 이미지를 누군가 보고 있다는 느낌을 이미지를 본 사람들을 통해 받게끔 해줍니다. 이러한 느낌은 Path 서비스만의 독특한 감성을 이끌어냅니다.

[그림2] 댓글달기 기능이 없음 

2. 친구를 50명으로 제한하여 내 사생활도 부담없이 노출할 수 있음

또한 Path에서 등록할 수 있는 사람은 50명으로 제한됩니다. 100명만 넘어가도 한 사람 한사람에 소홀해질 수 밖에 없는 것이 Social Network Service의 현실입니다인원 제한은 그만큼 한 사람 한 사람에 집중하겠다는 의미로 생각됩니다이미지를 올릴 때 입력한 인원 (같이 찍은 사람 혹은 같이 있는 사람들은 또 나름의 의미를 가지는데남이 찍은 사진이라도 사람에 내가 포함되어있으면 내 타임라인 안에 같이 보이게 됩니다.

제한된 50명은 내 소소한 일상을 공유할 수 있는 친구의 최대 숫자로 보입니다. 'Robin Dumbar 교수의 이론에 따르면 개인이 사회적 관계를 유지할 수 있는 최대의 인원은 150명이라고 합니다. 어떤 정보도 공유할 수 있는 관계의 사람들로, 그러한 관계를 만들 수 있도록 하고자하는 의도가 담겨있습니다.'  [인용]

Path는 그룹을 지원하지 않습니다. 이는 서비스를 최대한 간결하게 만드려는 시도인 것 같습니다. Path는 태생이 모바일 어플리케이션(정확히는 아이폰 앱) 에서 시작했기 때문에, 그룹 지원이라는 무거운 기능은 지원하고 있지 않습니다. 하지만 나중에 사람들이 많이 이 서비스를 이용할 경우에는 이러한 사용자의 Needs가 분명히 있을것이며, Needs를 반영할지, 반영하지 않을지는 앞으로 두고 볼 문제입니다.

현재 Path는 글을 올릴때에 나와 사진찍힌 사람들만 보이게 할 수 있는 옵션을 제공합니다. 다음과 같은 제한적 공유는 현재로써는 그룹 및 비공개를 대체할 수 있는 용도로 보여집니다.

[그림3] 그룹지원 대신 제한 공개 옵션 제공

Path는 비공개 성향이 강하기 때문에, 공유하고 싶은 경우 얼마든지 내 사생활도 부담없이 노출할 수 있습니다. 다른 Social Network Service에서는 불가능했던 (혹은 불안했던) 것들도 원한다면 얼마든지 노출이 가능합니다. 그렇다면 ‘Path’는 비공개 서비스일까요? 꼭 그렇지는 않습니다. 현재로써는 이미지를 내 친구가 아닌 이상 볼 방법은 없습니다. 그러나 글을 작성할 때 이미지의 위치, 혹은 현재 위치 (정확히 확인된 바 는 없음) 을 중심으로 다른 사람들이 작성한 글이 보입니다. 얼핏 보면 이 서비스가 비공개서비스처럼 보이지만 엄연히 비공개라고 할 수는 없습니다. 하지만 Path는 이 서비스를 쓰는 사람으로 하여금 비공개 서비스처럼 느끼게 하고, 충분히 비공개 서비스의 경험을 제공하고 있습니다.

 

3. UI/GUI의 디테일을 통해 감성을 유발함

Path는 그 외에도 UI/GUI의 디테일을 통해 감성을 극대화하고 있습니다. UI의 디테일은 서비스 자체의 성공에 영향을 미치는 중요한 요소입니다.

3-1. 이미지 올리는 화면에서 텍스트를 탭 할 경우 버튼이 꿈틀거립니다

버튼이 꿈틀거리는 효과를 줌으로써 의외의 즐거움을 선사합니다. 물론 사용성에 있어서는 크게 도움이 되지는 않습니다.

[그림4] 버튼이 꿈틀거리는 효과

3-2. 이전 정보의 경우 꼬리표가 점점 길어지는 효과를 사용하고 있습니다

꼬리표는 기존 아이폰 앱에서 사용했던 타이틀 밀어내기 효과를 꼬리표로 변경한 것입니다. 타이틀 밀어내는 효과는 실용적이기는 하지만, 무미건조합니다. 꼬리표는 이 무미건조함을 감성적으로 풀어내었습니다.

[그림5] 꼬리표가 점점 길어짐

3-3. 로딩 후 이미지를 처리하는 센스를 발휘하고 있습니다

이미지 리스트를 로딩할 때 하단에 보여지는 Hourglass 가 사라지면(로딩이 끝나면) 완성도있는 그래픽 소스로 대체됩니다. 이런 소소한 GUI 장치가 이 서비스의 품질을 높이고 있습니다.

[그림6] 로딩 후 이미지로 변경됨

UI의 몇 가지 아쉬움

지금까지는 Path에 대한 칭찬 일색 이었습니다. 그러나 이번에는 Path를 사용하면서 느낀 몇 가지 UI 문제를 공유하려고 합니다.

1. 포스팅 방식이 잘 이해가 되지 않음

사진을 찍고 포스팅을 하려고 다음 화면에 진입하면 왠지 글을 써야 될 것 같은 느낌이 드는 화면에 진입합니다. 글을 쓰려고 회색 글씨를 탭하면 글은 안써지고, 버튼만 꿈틀거립니다. 물론 사용하다보면 어떻게 사용하는지는 감이 오실 테지만 직관적인 UI는 아니라고 생각합니다.

[그림7] 글을 쓰려면 뭘 눌러야 되나?


2. 글 입력 과정이 불편함

글을 입력하려고 할 때 글자 입력 폼이 한 줄로 되어있어서 글을 작성하다 보면, 앞으로 밀려납니다. 이때 앞의 글자를 수정하기 위해서는 이전 글자까지 드래그를 계속 해야합니다. 아무리 이미지 중심 서비스라고 하더라도 입력이 쉽게 만들어야 하는데, 이점은 개선의 여지가 있습니다.

또한 이렇게 어렵게 글을 작성했다 하더라도, 글자를 직접 수정하는 방식을 제공하지 않습니다. 글자를 수정하려고 하면, 기존에 썼던 글은 유지하지 않은 채로 다시 입력해야 하는 번거로운 방식을 사용하고 있습니다.


[그림8] 이전 글자 수정이 어려움

3. 댓글 기능이 없다는 점은 양날의 검

앞에서도 언급되었습니다만, Path에서는 댓글 기능을 제공하고 있지 않습니다. 남들이 다 제공하는 댓글 기능을 빼기 위해서는 내부에서도 많은 고민을 했으리라 생각하고, 이 고민은 쉽지 않은 고민일 것으로 보여집니다. 댓글 기능 삭제는 이 서비스를 심플하게 만드는데 큰 공을 세웠습니다. 하지만 댓글 기능이 없음으로 인해 생기는 부작용도 있습니다. 그 부작용은 다름아닌 커뮤니케이션 오류입니다. Path는 일방향적인 이미지 및 글 공유로 인해 상대방이 오해할 소지가 다분합니다. 주관적인 글귀, 주관적인 이미지를 통해 일방향적으로 소통하면 상대방은 자기 스스로가 해석하고 싶은대로 해석할 수밖에 없습니다. 이 시점에서 댓글이 없다면 상대방이 본인의 의사를 밝히지 않거나, 본인 스스로가 오해의 가능성을 사전에 차단하지 않고서는 문제가 해결되지 않습니다

그런면에 있어서 Path는 의사소통의 용도로써는 어딘가 불완전해 보입니다.어디에서, 누구랑, 무엇을 했냐정도의 중립적인 커뮤니케이션을 통해서도 감성을 이끌어내는데는 부족함이 없습니다. 다만 글이나 이미지에 감정이 실리게되면 해석의 여지에 따라서 부정적인 감정이 파생될 수 있고, 부정적인 감정이 누적될 우려가 있습니다. – 이 점은 Path가 아니더라도, 사람과 사람이 해결해야 할 문제로 보입니다. 다만 인터페이스에서 이런 오해를 불러일으키게 한다면, 분명히 개선의 여지는 있다고 생각합니다.

 

글을 정리하며

다음과 같이 Path의 등장배경, Path의 특장점 및 UI 의 아쉬움을 기술하였습니다.

본 포스팅에서 살펴본 Path의 장점을 요약하자면 다음과 같습니다.

1.   Path는 기존의 Social Network Service가 간과했던 ‘Personal’ 요소에 집중한 서비스이다.

2.   Path는 모바일 환경에 맞추어 간결하게 만든 서비스이다.

3.   Path는 감성을 극대화시키는 여러가지 방법을 사용하고 있다
(UI/ GUI 디테일이 단적인 예)

Social Network Service 도 이제 많이 등장했습니다. 개방, 공유를 중심으로 한 Twitter, Facebook, Me2day 뿐 아니라, 특정 계층에 중점을 둔 다음 요즘, 위치 기반을 중심으로 한 포스퀘어 등 이미 서비스들의 홍수로 Social Network Service 시장은 포화된 상태입니다. 그렇기 때문에 Social’ 이 화두가 되는 이 시대에 Personal Network Service로 야심차게 등장한 Path의 행보가 기대됩니다

현재 ‘Path’는 아이폰 앱스토어에서 이 주의 앱으로 홍보되고 있으며, 꾸준히 업데이트를 하고 있습니다. 앞으로 Path에 어떤 기능이 추가될지, 어떻게 변화할 것인지 유심히 지켜보시면 한 서비스의 흥망성쇠가 어떻게 이루어지는지도 덤으로 배우실 수 있을 것 같습니다.



[참고##UI 디테일##]


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


Trackback 0 Comment 8
Ad Test...
2010.11.25 15:25

모바일 앱 설정 UI 가이드

아이폰은 왜 개별 앱 설정을 settings app에 모아두고 난리야?

아이폰은 앱 사용중 필요한 설정을 settings라는 별도의 앱에 모아두어서 불편하다는 트윗을 보았습니다. 그전에도 많이 들었던 불만이기도 하고요. 안드로이드처럼 개별 앱 설정이 앱 자체 안에 있으면 되지 왜 따로 빼놓은 거야. 요즘 모바일 앱 프로젝트들을 하면서 설정에 대한 고민을 많이 하고 있습니다. 모바일 앱의 설정 UI에 대한 가이드가 필요한 것 같아 정리할 목적으로 블로깅합니다.
결론은 애플이 잘못한게 아니라 앱을 잘 못 만든거에요 :) 설정은 사용 빈도에 따라 환경 설정(preferences)처럼 한번 설정하면(또는 디폴트로 설정되어 있는채로) 거의 변경하지 않는 것들과 사용 컨텍스트에 따라 기능을 변경이 필요한 것들로 나뉠 수 있습니다. 애플의 iPhone Human Interface Guidelines 문서에서는 이 둘을 settings와 configuration options라는 용어로 구분하고 있습니다. 지금은 iPad도 통합되어 iOS HIG로 배포하고 있습니다.

Settings should represent information, such as an account name, that users set once and rarely (if ever) change. Users view application-specific settings in the built-in Settings application

Configuration options are values that users might want to change frequently, such as category types displayed in a list; configuration options should be available within the application itself.

메일의 계정 설정 처럼 한번 설정해두면 앱 사용 중에 변경할 필요가 거의 없는 것들(보통 환경 설정)은 settings에 넣고 캘린더의 월/주/일 보기 처럼 앱 사용 중 사용 맥락에 따라 빈번히 변경될 수 있는 옵션 설정은 앱 자체에 넣으라는 것이지요. 
왜 이런 설정을 불편하게 settings에 넣은거야? 라고 생각되면 그 앱이 제대로 설계되지 않았기 때문입니다. 애플을 욕하지 말고 앱 개발사를 욕해 주세요. :)


설정 같은거 하지 말자

애플이 제안하는 최상의 방법은 설정 따위 하지 않도록 만들라.입니다. UI 디자인을 하면서 담당자끼리 의견이 서로 다르면 누구 말이 맞는지 싸워봤자 답은 안나오고 그럼 대부분은 옵션으로 넣고 사용자가 선택하게 하자라는 결론으로 마무리 됩니다. 지금 사용하고 있는 제품에 알 수 없는 옵션들이 당신을 괴롭히고 있다면 상당수 그렇게 떠넘긴 문제들입니다. 물론 사용자의 다양성을 존중하고 선택의 폭을 넓혀  주기 위해 제공하는 경우도 간혹 있긴하지만요.

설정을 최소화 하기 위해 애플이 제안하는 방법중 하나는 "80%의 사용자 니즈에 집중하라" 입니다.
퍼소나 방법의 접근과 비슷한데요. 모두를 만족시키는 마법같은 해결같은 건 있지않습니다. 소수의 사용자를 만족하기 위해서 추가적인 기능이 들어가게되면, 대다수의 사용자는 안쓰면 그만이니 win-win이 아니라 그만큼 사용이 복잡해집니다. 그냥 빼버리세요.
사용자를 배려하지 않는다고 공격을 받기도 하지만 그게 애플의 디자인 철학입니다. 상충된 해결에 트레이드오프가 있다면 심플한걸 택합니다. 그것이 싫다면 누구의 잘못이 아니라 그저 내가 애플의 타겟 고객이 아닌 것 뿐입니다. 다른 제품을 찾아보면 됩니다. 물론 내가 나머지 20%에 속할때는 정말 아쉽긴 하지만요.


애매하게 빈번한 설정은 어떻게 해야 하나?

설정 자체가 빈번한 성격의 유틸리티 앱
유틸리티앱은 설정을 settings에 두지않고 맥os의 대쉬보드 위젯에서 처럼 i 버튼을 누르면 화면을 뒤집어서 반대편에 설정화면을 제공합니다. 그렇게 하라고 가이드라인에 적고 있습니다.




옵션을 항상 노출시키기에는 사용 빈도가 낮은 경우
자주 쓰지는 않지만 사용 화면 중에 설정이 있으면 좋겠다 싶은 애매한 경우에 애플이 택한 디자인 해결은 살짝 감춰 두는 것입니다. ibooks 라이브러리의 썸네일/목록 보기나 주소록의 검색 같은 것들은 목록의 상단에 설정을 두고 평상시에는 가려놓습니다. 필요한 경우 페이지를 당기면 나타납니다.

 

이걸 어떻게 알고 쓰냐고요? 모르면 말라는거죠. 사용자가 필요로 하는 기능이면 물어보든 검색을 하든 찾아낼테니까요. 
척보고 모르겠다고 사용편의성이 나쁜게 아닙니다. 사용성은 학습성 말고도 효율성이 중요한데 여기에도 트레이드오프가 있을 수 있습니다. 모든걸 알기 쉽게 만들어야만 좋은 디자인이 아닙니다. 사용자는 초보자보다 중급자가 가장 많거든요.




잘못된 설정 사례

지도 서비스에서 지도로 보기와 위성 사진으로 보기는 사용 맥락에 따라 빈번하게 변경하게 되는 옵션입니다. 그래서 웹서비스에서는 화면에 바로 노출되는 컨트롤을 제공합니다. 하지만 모바일 앱은 화면이 작으니 화면에 노출되는 컨트롤 사용에 조심스럽게 됩니다.
아이폰에서 기본으로 제공하는 구글맵 앱은 옵션 들춰보기 같은 독창적인 방법을 사용합니다. 화면에 노출되는 컨트롤은 최소화하면서 여러 옵션을 제공할 수 있습니다. 화면효과에 현혹되지 않으면 애플은 지도 보기 옵션을 환경설정이 아니라 간단한 보기 변경으로 간주하고 있다는걸 알 수 있습니다. 옵션을 선택하면 옵션화면이 가려지면서 바로 적용 됩니다.




네이버 지도와 다음 지도는 보기 설정을 잘못 적용하고 있는 경우입니다. 지도 보기 옵션이나 실시간 교통정보 같은걸 별도의 설정화면에 함께 넣어서 완료를 하여야 적용되도록 만들어져있습니다. 그저 버튼 한번 더 누르는 수고일 뿐이지만 기본적인 UI 정책이 없어 보여서 아쉽습니다. 고쳐주면 좋겠어요. 쓸때마다 울컥하거든요.



정리하면
1. 거의 안쓰는 환경설정은 settings에 넣고 설정 아이콘도 눈에 안띄게 하여 사용자가 신경 안쓰게 한다.
2. 사용 컨텍스트에 따라 빈번한 설정은 화면에 노출시킨다
3. 둘 사이의 애매한 설정은 적당히 잘 감추고 필요한때 꺼내 쓸 수 있도록 한다.

0. 가급적 설정은 만들지 않는다.

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


Trackback 1 Comment 11
Ad Test...
2010.07.26 23:30

스타일러스 펜 vs 손가락. 아이패드에서라면?


아이패드의 등장으로 기대를 얻었던 기능 중 하나는 넓어진 화면으로 인한 자유로운 필기 또는 스케치 아닐까 싶습니다. 떠오르는 즉시, 편리하게, 자유롭게 기록하여 메일로 전송하거나 다른 사람들과 공유하는 등 지금과는 다른 행동 패턴들이 나타날 테니 말이죠.

편리하고 자유로운 기록을 위해 사실 손가락은 조금 부족한 느낌입니다. 그렇다면 스타일러스 펜이 이런 아쉬운 점들을 채워줄 수 있지 않을까요? 이번 주는 시중에서 판매되는 스타일러스 펜들에 대한 리뷰작성해볼까 합니다.

 

준비물
- 아이패드
- 스타일러스 펜 (pogo, dagi, boxwave 총 3종) 
* 아이패드에는 무광 필름이 부착되어 있음.

  

1. Pogo Sketch

메탈 느낌의 포인트 컬러 바디

Soft tip – 스펀지 재질

 

디자인 ★★★★★

필기감 ★★★☆☆

휴대성 ★★★☆

         


1 | 2
3 | 4

Pogo는 패키지가 가장 먼저 눈에 들어왔던 녀석입니다. 일반 펜보다는 조금 얄쌍('얄팍'이 올바른 표현임)한 굵기인데 오히려 스타일러스 펜으로써의 그립감은 더욱 충족되는 듯 합니다. 다만 문제가 되는 것은 스펀지 재질의 tip부분입니다. 접촉만으로는 인식이 되지 않으니 자연스레 꾹꾹 눌러쓰게 되고 결국 액정에 닿는 부분이 넓어져 정교한 필기를 하기에는 어려운 편입니다. 오랫동안 필기를 하게 되는 경우, 손이 쉽게 피로해지고 스펀지 모양이 눌려버리기 때문에 매번 손으로 모양을 잡아주어야 합니다. (사진3,4) (물론 원상복귀가 되기는 하지만요…)

    손으로 필기한 글씨


    pogo로 필기한 글씨


필기한 글씨로 비교해 보면,
손가락 보다는 훨씬 안정적으로 빠르게 필기되는 것을 느낄 수 있었습니다. 또한 좀 더 세밀하게 필기되는 덕에 글씨들이 더 작아지는 효과 또한 스타일러스 펜의 장점이라고 할 수 있겠네요.  





 

2. BOXWAVE


무광 블랙 바디
soft tip - rubber 재질

디자인 ★★★★☆

필기감 ★★★★

휴대성 ★★★★☆



1 | 2
3 | 4

Box wave의 외관 디자인에서는 그다지 눈에 띌만한 요소는 없는 것 같습니다. 그러나 패키지를 개봉하여 tip을 확인하는 순간, 이거다!! 싶은 생각이 들더군요. 탄성 있는 rubber재질이라 필기감이 좋고 인식력도 높아 pogo보다는 힘이 훨씬 덜 들었습니다. 다만 계속 필기를 하다보니, pogo의 얄쌍한 굵기가 그리워지기는 했습니다. 펜 끝부분에는 이어잭 부분에 꽂아 휴대할 수 있도록 작은 부속품(?)이 달려있습니다. 이어잭에 연결된 채로 필기를 할 수 있으려면 끈의 길이가 더 길어야 할테지만 그래도 개인적으로는 세가지 펜 중 가장 높은 점수를 주고 싶습니다.

    손으로 필기한 글씨

    Box wave로 필기한 글씨 


필기 결과는 Box wave도 마찬가지입니다.
pogo 보다도 손에 가해지는 부담이 적었고, 안정적으로 빠른 필기가 가능했습니다. 글씨체가 나아지는 것은 물론이거니와 비슷한 결과물이라고 해도 들이는 수고가 훨씬 줄어드는 느낌입니다.




 

 

3. DAGI 


무광 블랙 바디
hard tip - plastic 재질

디자인
★★☆☆☆

필기감☆☆☆☆

휴대성 ★★☆☆☆



1 | 2
3 | 4

Dagi는 무언가 전문가스러운(?) 외관 디자인이 특징입니다. 투명 tip이 가장 큰 포인트인데, 보통의 스타일러스 펜들이 tip부분 굵기 때문에 시작점을 짐작으로 해야 한다는 단점을 보완하고자 한 것 같습니다. 반투명한 원판의 중앙에 빨간색 점이 찍혀있고 이 점이 인식되어 필기가 되는데, 문제는 이 점마저도 정확하게 인식하지는 않다는 것이죠. (사진3,4) 게다가 이 빨간색 점이 액정과 닿기 위해서는 펜과 액정의 각도를 90도로 유지해야 하는 문제가 있습니다. 오랜시간 필기를 하기에는 부적합한 각도입니다.

    
손으로 필기한 글씨

     Dagi로 필기한 글씨



필기 결과는 조금 난해합니다. 오히려 손으로 쓴 것보다도 이상한 글씨가 나옵니다. 시간도 오래 걸릴 뿐더러 필기 자체가 어려워지는 느낌입니다.



스타일러스 펜을 사용하다 보니 생각지도 못했던 문제점을 발견했습니다. 바로 필기를 하면서 발생하는 손바닥과 액정의 접촉이 문제가 되더군요. 노트 관련 어플 중에는 손바닥과 펜이 동시에 접촉했을 때, 아예 노트가 되지 않는 경우가 많았습니다.

제가 알고 있는 어플 중에는 유일하게 penultimate 만이 손목접촉 방지 기능을 지원하고 있었는데요, 아직은 손바닥 때문에 작은 점이 묻어나는 등, 완벽하게 지원되지는 않고 있습니다.
필기 중 손목 접촉과 펜의 구분이 이루어지지 않는 점은 분명히 해결되어야 할 과제인 듯 합니다. 조만간 이 과제가 해결된 어플로 빠르게 스타일러스 펜을 이용해 볼 날을 기대해 봅니다.
 

스타일러스 펜 총평
- 스타일러스 펜 사용 시, 손보다 빠르고 안정적으로 세밀한 필기가 가능합니다.
  (전체적으로 손가락으로 썼을 때 보다는 글씨가 작아지는 편입니다.)
- 펜의 속도를 100% 따라가며 인식하지는 못합니다. (약 95% 정도)
- 손목과 동시에 접촉하는 경우, 필기가 되지 않는 경우가 많으니 주의가 필요합니다.
- 빠르고 안정적인 필기가 목적이라면 스타일러스 펜 사용을 권해드립니다.

 


 

[참고##review##]

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


Trackback 0 Comment 7
Ad Test...
2010.07.25 15:36

아이폰 앱 시작 아이콘은 어떤 색깔을 제일 많이 사용하고 있을까?

1 | 2 | 3 | 4
5 | 6 | 7 | 8


1.
어느 날 출근 시간에 지하철에서 재미삼아 제가 가진 앱의 시작 아이콘을 색상별로 분류해봤습니다.
1~6 번째 탭은 정보/유틸 관련 앱이고 7~8 번째 탭은 게임 관련 앱입니다.

조사해보니 정보/유틸 관련 앱은 '파랑색'계열이 많고, 게임 관련 앱은 '빨강색' 계열이 많더군요. 과연 이 결과가 우연일지 궁금해졌습니다.





2.
다른 사례로, 500개의 아이폰, 아이패드 App 색상을 조사한 결과도 마찬가지로 '파랑색'이 제일 많았다고 합니다. 두 번째는 '검정색'이라고 합니다.

http://teqnolog.wordpress.com/2010/05/19/half-of-all-iphone-apps-are-either-blue-or-black/




3.
아래에서도 마찬가지로 아이폰 앱 시작 아이콘의 색상을 사용할 때 '파랑색'만은 피하라고 하더군요. 당연히 파랑색이 흔하기 때문이겠죠.

Question: What color should your iPhone app icon be?
Answer: Not blue.

http://jeremiahlee.com/blog/2009/10/05/picking-an-iphone-app-icon-color/




4.
그런데 모든 앱을 대상으로 조사한 결과 실제로 가장 많이 쓰인 색은 '갈색'이었다고 하네요. 조금 의외의 결과입니다.
http://skinnywhitegirl.com/blog/iconrainbow-is-about-the-purdy-colors/42/


아이폰과 같은 스마트폰 환경에서는 앱의 시작 아이콘을 어떻게 디자인하느냐가 중요합니다. 앱스토어에서도 맨 처음에는 아이콘밖에 보여지지 않기 때문에, 아이콘이 별로면 눌러보지도 않으니까 말이죠.



아이폰(아이팟터치)의 첫 화면을 캡쳐한 사진입니다. 앱 시작 아이콘만 보면 어떤 앱인지 구별이 가시나요? 내가 필요한 앱인지 아닌지 알 수 있으신가요?


호기심에서 시작한 블로깅이라 결론을 맺기가 쉽지 않네요. 굳이 결론을 내 보았습니다.

1. App 시작 아이콘을 디자인할때 '다른 앱과의 차별화'가 목적이라면 남들이 다 쓰는 색상(파랑색, 검정색, 갈색)은 되도록이면 피하자.
(2010년 11월 6일 추가 - 이 결론은 App 시작 아이콘의 차별화에 초점이 맞추어져 있습니다. 그 전에 브랜드 아이덴티티나 앱의 Look & Feel 등의 고려를 먼저하는 건 당연하다고 생각합니다.)

2. App 시작 아이콘을 공을 들여서 잘 디자인하자.
- 잘 만든 아이콘 하나가 열 앱 안부럽다.


+ 추가 고민 1 : 왜 대부분의 게임 아이콘은 테두리를 그린 다음에 오브젝트가 살짝 걸치게 디자인 한 걸까요?

이와 관련한 흥미로운 논의는 아래 링크 에서 확인해보실 수 있습니다.
http://me2.do/GQX1Ctii (뉴상준님 페이스북에서 글 / 이미지 인용)


+ 추가 고민 2 : 왜 대부분의 채팅 서비스들 아이콘의 말풍선 끝이 왼쪽으로 가 있을까요?
(김선기님 Path에서 글 / 이미지 인용)



*본 블로깅은 pxd 사내메일의 내용을 일부 포함하고 있으며, 2010년 7월에 작성된 글이므로 현재 상황과는 다를 수 있습니다.
[참고##UI 디테일##]



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


Trackback 0 Comment 8
Ad Test...
2010.07.19 21:35

작은 차이에서 완성도를 보여주는 아이폰 UI

아이폰의 UI는 작은 부분에서 뛰어난 완성도를 보여주고 있는데, 이러한 예로 '받은 편지함'을 들 수 있습니다. 어떠한 디테일이 이메일의 사용경험을 살렸는지, 구글의 메일 앱과 간략하게 비교해 보겠습니다.

받은 편지함에서는 정보 요소는 크게 수신의 유무와 수신 날짜 그리고 보낸 사람, 메일 제목 및 내용 정도를 가지고 있습니다. 상황에 따라 다르겠지만 보편적으로 정보의 우선 순위를 둔다면 수신의 유무> 보낸 사람> 제목과 내용> 수신 날짜와 시간으로 생각해 볼 수 있습니다.

그렇다면 최우선 순위인 수신의 유무 처리를 어떻게 디자인했는지 요것만 가볍게 살펴보겠습니다.


사용자는 메일함 진입시 미수신 메일을 먼저 확인하고 글을 읽게 됩니다. 따라서 이미 읽었던 메일의 글은 사용자에게 불필요한 부하로 작용합니다. 그렇다고 읽은 메일을 숨기는 방법도 좋은 선택은 아닌 것 같습니다. 읽었던 메일을 다시 보는 메일의 특성이 있기 때문이죠. 그렇다면 아이폰과 구글에서는 이 문제를 어떻게 처리하고 있을 까요?

아이폰의 Mail App경우
부하를 최소화하기 위해 시선의 시작점인 좌측 여백에 구분기호를 두었습니다. 좌측 여백을 따라 내려가면서 읽지 않는 메일부터 확인하도록 디자인되어 있습니다. 이것은 시선에 가이드를 줌으로써 인지에 대한 부담감을 줄여주고 있습니다.

구글의 Mail App경우
시선의 시작점부터 애매합니다. 좌측의 여백에는 현재 Context에서 중요하지 않은 개별 선택을 위한 체크박스가 배치되어 있고 수신 유무의 구분을 리스트의 색으로 구분하여 상당량의 정보들이 불편하게 시야에 들어옵니다. 또한 스크롤하면서 텍스트를 읽을 때, 잦은 색 변화는 상당한 시각적 피로를 발생시키고 있습니다. 그리고 수신했던 메일이 dimmed처리가 되어 있어 가독성마저 불편함을 야기합니다.

사용자는 작은 차이를 모를수 있습니다. 하지만 머리 속의 신경과 손 끝은 기억하고 있지 않을까요?
[참고##UI 디테일##]

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


Trackback 0 Comment 13
Ad Test...
2010.06.22 14:25

[정보디자인] 모바일검색 suggestion UI

아이폰의 사파리에서는 웹 필드에 텍스트를 입력하면 필드가 강제로 가운데로 이동합니다.(iOS3 이하에서. 폼 입력시 전후 맥락을 함께 살펴보려는 의도였던 것 같습니다)  검색엔진에서 suggestion을 입력창 아래 목록으로 보여주는 방식을 사용하면 이런 이유로 2,3개정도 밖에 보여주지 못합니다.


Device-Specific Design

아이폰이 이상한걸 우리가 뭘 어쩌라는거야  식의 다른 검색포탈에 비해 야후는 사용자를 배려하여 디바이스의 제약에서도 최선의 결과를 만들기 위한 노력이 보입니다. 아이폰의 이런 입력폼 특성을 반영하여 검색제안어를 입력창의 위아래에 2컬럼으로 보여주는 인터페이스를 제공합니다. 일반적인 방식보다 훨씬 많은 제안어를 보여주긴 하지만 눈이 스캔하는 영역이 4군데로 나뉘어서 좀 어색하긴합니다.



#추가 네이버 재팬도 야후와같은 방식의 검색어 제안을 사용하고 있습니다. 


그런데 iOS4로 업데이트 되면서 아이폰의 이런 이상한 동작이 수정되어서 입력 창이 상단에 올라갈 수 있게 되었습니다.


웹에서의 UI를 그대로 답습하여 풀다운 메뉴를 사용하는 것 보다는 키워드 입력시 배경을 가려서 노이즈를 줄이고 2컬럼을 사용하여 더 많은 검색어를 보여주려는 야후의 방식이 장점이 많습니다. 하지만 이번 iOS4업데이트에 맞춰서 입력창을 위로 옮겨야 겠네요.

그런데 사실 구글과 bing은 애플에서 뭘 얻었는지 아이폰OS3 버전에서도 그런 작동 방식을 우회해서 입력창이 상단에 있도록 하고 있었습니다. bing도 suggestion을 보여줄때는 배경을 가려서 제안 키워드에만 집중할 수 있도록 하고 있습니다.




Suggestion Bubbles

제가 제안 하는 방식은 차라리 정렬을 포기하고 그냥 버블로 표시하여 더 많이 보여주는 것입니다. 다음에서 제공하고 있는 초성검색 제안어를 제대로 사용하기 위해서는 좀 더 많은 키워드를 보여줄 필요가 있습니다. 예로든 삼원가든은  제안어 목록에 있지만 표시영역의 제한때문에 다음 모바일웹에서는 보여지지 않습니다.



모바일 검색어 제안 UI를 설계시 유의점

1. pc와 모바일 환경이 다릅니다. pc를 그대로 따르지 마세요.

2. 입력 중 suggestion을 보여주는 상황에서 노이즈가 되는 화면은 가리고 키워드에 집중할 수 있도록 한다.

3. 정렬을 통한 빠른 인지 vs. 많은 키워드 노출 의 트레이드오프의 고민이 필요합니다.



추가

이후에 계속 사용해보니 역시나 정렬이 더 중요했습니다. :)  현재 사용 중인 표시 방법은 2컬럼입니다. 버블형태로 키워드를 감싸는 것도 노이즈이기때문에 없는 것이 좋더라구요.



2컬럼 표시를 할때 또한 주의해야 할 부분은 멀티컬럼 정렬처럼 보이지만 멀티라인으로 나열하는 경우입니다. 네이버 모바일의 연관검색어는 사실 여러줄로 나열한 형태라서 한 화면에 많은 정보를 보여주기는 하지만 빠르게 훑어볼 수 있는 정렬의 장점은 잃게됩니다. 또 사용자가 익숙한 멀티컬럼으로 혼동해서 왼쪽만 훑어보게 될 수 있어서 네이버는 상위 키워드의 색상을 달리하여 강조하는 편법을 쓰는 것 같습니다.  물론 이렇게 개수가 정해지지 않아 스크롤이 생기게 되면 N형의 멀티컬럼 정렬 방식은 스크롤을 두번해야하는 번거러움이 있습니다. 하지만 좌우를 번갈아가며 확인하는 Z형 나열에 비해서는 인지 부담이 적은 것 같습니다.
연관검색어가 많은 경우는 검색 행태를 반영하여 narrow와 expand로 그룹핑해서 나눠 보여줘도 좋겠고요. 




[참고##검색##]

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


Trackback 0 Comment 0
Ad Test...