태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.


'WEB'에 해당되는 글 3건

  1. 2011.05.13 [UI 디테일] 웹사이트 로그인, 어떤 방식으로 하는것이 좋을까? (4) by 위승용 (uxdragon)
  2. 2010.10.29 [UI 디테일] 미투데이의 Family UI 비교 – 웹, iOS 앱, 안드로이드 앱을 중심으로 (3) by 위승용 (uxdragon)
  3. 2010.03.14 웹사이트 마우스 제스쳐 비교 (크롬플러스, 네이버툴바, 파이어폭스) (4) by 위승용 (uxdragon)
2011.05.13 12:55

[UI 디테일] 웹사이트 로그인, 어떤 방식으로 하는것이 좋을까?

최근, 미투데이의 miriya 님이 올려주신 UX movement 링크를 보게 되었습니다.
http://uxmovement.com/forms/innovative-techniques-to-simplify-sign-ups-and-logins 



웹사이트의 회원가입과 로그인을 어떻게 하면 쉽게 할 수 있을지에 대한 몇가지 테크닉에 관한 글입니다.
그 중에도 인상깊었던 부분은 '웹사이트 로그인을 할때 어떤 정보를 통해서 로그인을 하게 할 것인가?' 였습니다.

로그인 방식은 다음과 같이 몇가지 유형이 있습니다.

1. ID + Password 로 로그인 하는 방법
국내 웹사이트에서는 거의 이 방식을 사용하고 있습니다.
이 경우에는 사용자가 ID를 기억해야 한다는 부담감이 있습니다.
ID 입력 방식도 사이트에 따라 천차만별이기 때문에 한 사람이 여러개의 ID를 가질 수 있습니다.(첫 글자가 숫자면 안된다는 규칙, 6자리에서 12자리 사이로 입력해야 한다는 규칙같은것들 때문이죠.) 저의 경우 4~5개의 ID와 마찬가지로 4~5 개의 Password가 있어서 상황에 따라 조합해서 가입하는 경우가 있습니다.
또한 회원 가입시에는 별도로 E-mail 정보를 입력해야 한다는 부담이 있습니다.(E-mail 정보를 ID, Password 확인 용도나, 이벤트 알림 용도로 사용할 수 있죠.) 

미투데이의 로그인 방식


2. E-mail + Password 로 로그인 하는 방법
외국 웹사이트에서는 거의 이 방식을 사용하고 있습니다.
이 경우에도 마찬가지로 사용자가 E-mail을 기억해야 한다는 부담감이 있습니다.
또한 상대적으로 ID보다는 긴 형태이기 때문에 입력하는데 시간이 걸리며, 인지하는데도 어느정도의 어려움이 있습니다. E-mail을 몇 개나 사용하고 있는지도 마찬가지로 천차만별입니다. 저의 경우를 비추어보자면 E-mail을 4~5개 정도 보유하고 있어서 이 경우에도 어떤 E-mail로 가입했는지 고민을 해야 합니다. 그렇지만 E-mail을 한 개만 사용하는 경우에는 크게 문제는 없을것 같습니다.  

또한 웹사이트에서는 E-mail 입력이 편한 반면, 모바일에서는 E-mail 주소 입력이 상대적으로 불편합니다. 이런 여러가지 생각들속에서 올바른 가치판단을 해야겠습니다.

페이스북의 로그인 방식



그렇다면 회원 가입 시 E-mail 인증 및 E-mail 중복 체크를 해야될까요?
E-mail 중복 체크는 꼭 해야 할것으로 보입니다. 하나의 E-mail로 두 명이 사용할 수는 없기 때문입니다. E-mail 인증 절차도 복잡하지않게 설계한다는 전제하에서 필요할 것으로 보입니다. '인증을 해서 사용자를 불편하게 할 것인가?' vs '인증을 하지 않아 입력단계를 편하게 하지만, 이메일을 잘못 입력했을 경우에는 사용자의 책임으로 전가할 것인가?' 를 사이에 두고 가치판단을 하여야겠습니다.

3. E-mail or ID + Password 로 로그인 하는 방법
E-mail 혹은 ID 둘 중 하나만 입력해도 로그인 하는 방법입니다. 이 경우 E-mail 과 ID 둘다 입력되어있다는 전제하에서 로그인이 성립 될 것 같습니다. E-mail 통해 가입하는걸 원하는 사람 혹은 ID를 통해 가입하는걸 원하는 사람이 있을 수 있으므로 둘 다 지원하자는건데, 개인적으로는 부가적인 방법으로 상황에 따라 적용하는 것이 좋다고 생각합니다.

4. 아예 회원가입을 하지 않고 로그인 하는 방법
회원 가입대신 Facebook이나 Twitter 로그인으로 대신 하는 방법이 있습니다. 원래는 이 방법이 보안을 위해 특정 어플리케이션에서 직접 ID, Password를 입력받지 않고 사용자의 정보에 접근하기 위한 표준이었습니다. 그러나 요즘에는 개인정보가 많이 필요하지 않은 경우 페이스북, 트위터 OAuth로 사용자 인증을 하는 서비스가 많아졌습니다. 

그 전에는 통합아이디 개념의 Open ID 가 하나의 방법이었는데, 요즘에는 이 방식이 점점 줄어들고 있는 것 같습니다. 미투데이에서도 Open ID를 지원하다가, 최근 어떤 이유로 인해 Open ID를 지원하지 않고 있습니다.

5. 전화번호로 로그인(인증)하는 방법
이 경우는 웹사이트보다는 모바일에서 적합한 방식으로 보입니다. '카카오톡'에서 이 방식을 사용하고 있지요. 이 방식은 회원가입 없이도 로그인을 할 수 있다는 장점이 있습니다. 하지만 전화번호가 바뀌거나 없어질 경우에는 이 방식이 문제가 됩니다. 카카오톡의 경우 문자를 주고받는 커뮤니케이션 앱이기 때문에 전화번호가 바뀌어도 크게 이상하지는 않습니다. 하지만 다른 종류의 앱들이 전화번호로 로그인을 할경우에는 다시 친구를 맺어야 하는 문제가 생길 수 있습니다. 
또한 어떠한 연유로 두 개의 전화번호를 가지고 있는 사용자의 경우를 고려할 필요가 있습니다. 카카오톡은 한번에 한 개의 전화번호를 인증하기 때문에 두 개의 전화번호를 인식할 수 있는 방법이 없습니다.

또한 카카오톡은 전화번호 정보밖에 가져오지 않기 때문에, 다른 서비스(이를 테면 웹)에 접목시키기가 매우 어려운 실정입니다. 추가적으로 ID를 입력하게 하는것도 이 때문으로 보여집니다. 

카카오톡의 로그인(인증) 방



웹사이트 로그인, 어떤 방식으로 하는 것이 좋을까요?
저는 요즘 'E-mail + Password' 방식이 좋은 것 같다는 생각이 듭니다. 여러분들의 생각은 어떠세요?


PS. Log in vs Sign in 어떤 용어를 쓰는것이 좋을까요? 
http://legendre.tistory.com/entry/Log-in%EA%B3%BC-Sign-in




* 본 블로깅은 PXD 사내메일의 글을 일부 포함하고 있습니다.
(글 쓰는데 많은 도움주신 이재용님, 無異님 감사합니다.)
* 좋은 자료 링크해주신 miriya님 감사합니다. 


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



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


Trackback 1 Comment 4
Ad Test...
2010.10.29 15:20

[UI 디테일] 미투데이의 Family UI 비교 – 웹, iOS 앱, 안드로이드 앱을 중심으로



Family UI의 정의
'Family UI'는 자동차 업계에서 사용되는 Family Look 이라는 단어에서 인용한 것으로 한 브랜드에서 나온 모델들에 브랜드 정체성을 부여해주는 디자인 요소를 말합니다. Family Look을 적용한 디자인은 모델이 다르더라도 특정 회사의 제품이라는 것을 바로 구별해 낼 수 있어서 브랜드 정체성을 강조해주는 효과와 함께 향후 구매력에 영향을 준다고 합니다.[각주:1]


미투데이의 Family UI 비교
웹, iOS 앱, 안드로이드 앱 미투데이를 사용하면서 느꼈던 Family UI 의 차이점을 디테일한 면 위주로 비교해 보았습니다. 전반적으로 미투데이는 웹, iOS 앱, 안드로이드 앱을 일괄적으로 가져가기 위해서 애를 쓴 모습이 보입니다만, 이 글은 차이점에 대해서만 기술함을 밝혀둡니다.
(*미투데이는 친구들과 실시간으로 이야기를 나눌 수 있는 150자 마이크로 블로그입니다. 자세한 설명은 여기에서 확인하세요.) 
 
1. 아이콘
미투데이의 아이콘중에서 '찾아보는' 이라는 아이콘이 있습니다. [그림1]에서 '찾아보는'은  키워드를 이용한 검색 기능을 제공하는데, 같은 레이블의 아이콘임에도 불구하고 아이콘을 서로 다르게 표현하고 있음을 알 수 있습니다. 실제 기능을 보면 좌측에 있는 '찾아보는'은 내가 등록한 키워드 위주로 보여주는 역할을 수행합니다. 우측에 있는 '찾아보는'은 키워드를 보여주기는 하나 '검색 기능'이 있기 때문에 다른 아이콘을 쓰고 있습니다. 다른 기능이라면 아이콘만 다르게 할 것이 아니라 레이블을 변경해야 하지 않나 생각합니다.


[그림1]
'찾아보는' 아이콘의 차이 (- 웹, - iOS 앱)

그 다음으로 '프로필'을 나타내는 아이콘을 보시겠습니다. [그림2]를 보시면 좌측에 있는 프로필과 우측 옵션 메뉴 키에 있는 프로필이 레이블은 같은데 아이콘을 다르게 표현하고 있습니다. 내용을 파악해보면 좌측에 있는 프로필은 엄연히 보면 프로필 설정 기능을 수행하며, 우측에 있는 프로필은 프로필 확인으로 해석할 수 있습니다. 마찬가지로 같은 레이블인데 다른 기능을 수행하므로 아이콘 뿐 아니라 레이블을 변경해야 할 것 같습니다.


[그림2]
프로필 아이콘의 차이 (- 웹, - 안드로이드 앱)

[그림3] 을 보시면 우측의 '사람찾기' 아이콘을 웃는 아이콘으로 표현하고 있습니다. 그렇다면 좌측의 아이콘도 과연 사람찾기일까요? 좌측의 아이콘은 아이콘을 변경할 수 있는 아이콘입니다. 이 상황에서는 좌측의 아이콘을 다른 아이콘으로 변경하는 것이 좋을 것 같습니다.


[그림3]
사람찾기 아이콘의 혼용 (좌,우 iOS 앱)

2. 레이블 
자 이제 레이블을 보시겠습니다. [그림4]를 보시면 좌측의 '댓글달기' 버튼과 우측의 '댓글쓰기' 레이블은 같은 기능을 수행합니다. 하지만 레이블의 차이가 있습니다. '쓰기' 버튼과 '올리기'버튼도 사실은 같은 기능을 수행합니다만 레이블의 차이가 있습니다. 물론 UI Flow 상으로는 문제가 없습니다만, 레이블을 통일시켜주는 것이 좋을것 같습니다.


[그림4]
레이블의 차이 (- 웹, - iOS 앱) 


3. 레이아웃
이번에는 레이아웃을 보시겠습니다. [그림5]번을 보시면 좌측의 글을 올린 날짜, 시간은 오른쪽 정렬로 되어있는데, 우측의 글을 올린 날짜, 시간은 왼쪽 정렬로 되어있습니다. 이때에는 두개를 통일시키는 것이 일관된 경험을 줄 수 있겠지요.
또한 날짜 시간 표현방식도 자세히 보시면 미묘하게 다름을 알 수 있습니다. 차이점이 보이시나요?

또한 아래 이미지 표현방식도 차이가 있습니다. 아이폰 앱에서는 한줄에 2개씩 보여주는데, 안드로이드 앱에서는 한 줄에 6개씩 보여줍니다.
* 추가: 아이폰에서 미투한 사람이 몇명이 기준인지는 모르겠습니다만, 많아질 경우 한줄에 5개씩 보여짐을 확인했습니다. 그래도 일관된 UI/GUI는 아니군요.


[그림5]
레이아웃의 차이 (- iOS 앱, - 안드로이드 앱)
 
4. 네비게이션
전체 네비게이션도 OS에 따라 차이가 있습니다. [그림6]을 보시면 좌측 안드로이드 앱에서는 홈(App dashboard) 화면이 있어서 어디를 들어가고 싶을때 홈(App dashboard) 화면을 거쳐서 이동해야 합니다. 하지만 iOS 앱에서는 하단 탭에 자기가 보고 싶은 카테고리 4개를 선택하여 구성할 수 있습니다. 이 차이점은 안드로이드 폰과 아이폰의 태생적인 차이점 일 수도 있겠지만, 한 회사의 서비스이니만큼 어느정도는 일관성을 지켜주는것이 좋겠다고 생각합니다.

[그림6] 네비게이션의 차이 (- iOS 앱, - 안드로이드 앱)

5. 그외에...
미투데이의 '화화'님께서도 iOS의 미투데이와 안드로이드 미투데이 앱의 사용상의 차이점을 기술 해주셨습니다. 작성한 글을 롱탭 했을때 UI가 다르다는 점을 기술하고 있습니다.



정리하며…
다음과 같이 미투데이의 웹, iOS 앱, 안드로이드 앱을 비교해 보았습니다. 
물론 미투데이의 웹 + iOS 앱 + 안드로이드 앱을 모두 사용하는 사람들은 많지 않을수도 있습니다. 그러나 한 서비스를 사용하다가 다른 서비스로 이동하더라도 동일한 경험을 제공하도록 하는것이 사용성 및 서비스의 새로운 가치 창출을 위해서는 꼭 필요하다고 생각합니다. 동일한 경험을 제공하되 각각의 플랫폼의 성격에 따라 최적화된 UI가 나오는것이 좋지 않을까요? 물론 그렇게 하는것이 쉽지는 않을 것입니다. 여러번의 시행착오와 개선이 필요하겠지요. 미투데이는 충분히 잘하고 있고, 잘하고 있기 때문에 더 아쉬운 점을 찾게 되는 것 같습니다. :)


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


  1. HCI 2009 학술대회 '멀티플랫폼에서 Family UI의 적용에 대한 사례연구'에서 인용 [본문으로]

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


Trackback 1 Comment 3
Ad Test...
2010.03.14 22:03

웹사이트 마우스 제스쳐 비교 (크롬플러스, 네이버툴바, 파이어폭스)


크롬플러스를 사용하다 보니, 우연히 마우스 제스쳐(mouse gesture) 기능이 있다는 사실을 알았습니다. 크롬플러스는 마우스 제스쳐 기능을 기본으로 제공하고 있더군요. 크롬플러스의 마우스 제스쳐 기능을 보다보니 문득 다른 브라우저(혹은 툴바)의 마우스 제스쳐는 어떻게 제공하고 있는지 궁금해지더군요. 그래서 크롬플러스, 네이버툴바, 파이어폭스(fire gesture)의 마우스 제스쳐를 조사해 보았습니다.

[그림 1] 크롬플러스 마우스 제스쳐 설정

[그림2] 네이버 툴바 마우스 제스쳐 설정

[그림3] 파이어폭스 Fire Gesture 설정

크롬플러스에서 마우스 제스쳐 기능은 기본으로 제공하는 기능이기 때문에 별 무리없이 사용할 수 있습니다. 그러나 네이버 툴바의 마우스 제스쳐 기능은 네이버 툴바를 깔아야하는 제약사항이 있습니다.(인터넷 익스플로어와 파이어폭스에서 설치가능) 파이어폭스는 Gesture를 제공하는 여러가지 플러그인이 있으며, 그중 Fire Gesture를 선택적으로 깔아보았습니다. 결국 크롬플러스를 제외한 다른 브라우저및 툴바는 이중으로 설치해야 한다는 부담감이 있습니다. (네이버 툴바의 경우 툴바를 설치하는 것 만으로도 부담으로 작용하겠지요.)  

[표4] 크롬플러스, 네이버툴바, 파이어폭스(Fire Gesture)의 마우스 제스쳐 비교 차트
클릭하시면 더 큰 화면으로 보실 수 있습니다.

크롬플러스, 네이버툴바, 파이어폭스(Fire Gesture)의 마우스 제스쳐 비교 차트는 [표4] 와 같습니다. 
사용하고 있는 마우스 제스쳐의 유형을 뽑아보면,

1. 상,하,좌,우 한 방향으로 이동 (ex. up) 

2. 상,하,좌,우 한 방향으로 이동 후 다른방향으로 이동 (ex.up-left)

3. 상,하,좌,우 한 방향으로 이동 후 다시 돌아옴 (ex. up-down)

4. 상,하,좌,우 한 방향으로 이동 후 다른방향으로 이동 후 다른방향으로 이동 (ex. down-right-up)

5. 상,하,좌,우 한 방향으로 이동후 다시 돌아온 후 다시 반대로 이동 (ex, down-up-down)

6. 상,하,좌,우 한 방향으로 이동 후 다른방향으로 이동 후 다른방향으로 이동 후 다른방향으로 이동 - 계단을 그리는 형태로 단순화 할 수 있습니다. (ex. right-down-right-down)

7. 상,하,좌,우 한 방향으로 이동 후 다른방향으로 이동 후 다른방향으로 이동 후 다른방향으로 이동 후 다른방향으로 이동 - 사각형을 그리는 제스쳐로 단순화 할 수 있습니다. (ex. left-down-right-up-left)

8. 다른 키와 접목하여 이동 (ex. wheel+up, ctrl+마우스동작)

와 같은 방식으로 나누어 볼 수 있습니다. 그 외에도 대각선 방향으로 움직이는 유형, 모양을 그리는 유형(삼각형, 사각형, 동그라미), 철자를 그리는 유형 (via MIRiyA☆) 이 있을 수 있습니다.

크롬플러스, 네이버 툴바, 파이어폭스(Fire Gesture)의 마우스 제스쳐 기능을 더 자세히 살펴보자면,

up, down의 경우 현재 페이지의 맨위, 맨 아래로 스크롤 하는 기능으로 주로 사용하고 있습니다. 파이어폭스(Fire Gesture)의 경우 새탭에 링크열기 기능으로 쓰고 있습니다. left, right의 경우는 모든 경우가 이전페이지, 다음페이지 이동으로 사용하고 있습니다. 네이버툴바의 경우 up, down의 길이에 따라서 up,down을 길게 수행할 경우 페이지의 맨위, 맨 아래로 스크롤하게 하였으며, up,down 을 짧게 수행할 경우 현재 페이지의 위, 아래로 조금씩 스크롤하게 되어있습니다.

up-left, up-right 의 경우 크롬플러스와 파이어폭스(Fire Gesture)는 이전 탭, 다음 탭으로 이동하게 되어있으나 네이버툴바의 경우 빈 페이지, 빈 탭으로 새창열기로 제공하고 있습니다.

down-left 의 경우 크롬플러스는 풀스크린보기 (f11과 같은기능) 로 사용하고 있으며, 네이버툴바는 새로고침 (f5와 같은기능), 파이어폭스는 다른이름으로 저장의 각기 다른기능으로 제공하고 있습니다. down-right 의 경우 크롬플러스, 네이버툴바, 파이어폭스(Fire Gesture) 모두 현재 탭 닫기로 제공하고 있습니다.

left-up, left-down의 경우 크롬플러스는 줌인, 줌아웃으로 사용하고 있으며, 파이어폭스(Fire Gesture)는 상단으로 스크롤, 하단으로 스크롤로 제공하고 있습니다.

right-up, right-down의 경우 크롬플러스는 새탭, new IE 탭을 여는데 사용하고 있으며, 파이어폭스(Fire Gesture)는 선택한 문장내 모든연결 열기, 선택한 문장을 다음으로 검색으로 사용하고 있습니다.

파이어폭스(Fire Gesture)는 마우스 제스쳐로 거의 모든 기능을 수행할 수 있도록 하고있습니다. 대신 이 모든 제스쳐를 외워서 사용하기 위해서는 많은 시간이 필요하겠지요. (마우스 제스쳐가 거의 게임에서 필살기쓰는 수준입니다.) 또한 이 스크롤 규칙들은 Default 값이며, 사용자가 자신이 원하는대로 스크롤 규칙들을 바꿀 수 있습니다.

그 외의 기능으로, 네이버툴바와, 파이어폭스(Fire Gesture)는 마우스 제스쳐 시에 선의 색상과 굵기를 조정할 수 있게 되어있습니다.


글을 마치며

1. 웹사이트 마우스 제스쳐의 현실적인 방식의 통일화가 필요합니다. 하나의 제스쳐를 잘 사용하고 다른 환경에 처하게 되면 새로 제스쳐를 익혀야 한다는 부담감으로 작용하겠지요. 이 논의를 하기전에 웹사이트에서 마우스 제스쳐가  과연 필요한가? 혹은 쓰기편한가? 에 대한 논의가 이루어져야 할 것 같습니다. 적어도 제가 마우스 제스쳐를 경험해 본 결과 다소 학습이 필요하다는 단점이 있으나, 단순한 제스쳐의 경우 단축키보다는 쓰기 편하더군요. 결국 마우스 제스쳐는 단축키를 익히기에 버거운 유저에게 쉽게 다가갈 수 있을듯 합니다. 하지만 그러기에는 설치의 장벽, 사용법을 익히기 위한 장벽들을 넘어야 하겠습니다.

[그림5] SKY Phone의 제스쳐 인식 기능

2. 웹사이트뿐 아니라 모바일웹에도 제스쳐 기능이 도입되면 어떨까요? 모바일은 터치 기술의 도입으로 다양한 제스쳐가 가능해졌습니다. 스카이의 터치폰의 경우 제스쳐인식 기술을 통해 음악재생관련 기능을 수행합니다. 물론 기본적인 상,하 Flick의 경우 스크롤의 기능으로 거의 안착이 되었기 때문에 웹사이트의 제스쳐는 좀 더 다양한 고민이 필요한듯 합니다. 웹사이트 상에서의 다양한 마우스 제스쳐의 경험을 모바일웹의 경험으로 옮길 수 있다면, 모바일웹에서의 좀 더 풍부한 사용 경험을 제공할 수 있으리라 기대해봅니다.

[참고##제스쳐##]

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


Trackback 1 Comment 4
Ad Test...