태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.


'css'에 해당되는 글 4건

  1. 2018.07.05 과거의 디자인이 지금보다 딱딱하고 투박한 이유 (2) by 문한별
  2. 2016.05.12 세상에서 가장 쪼잔한 질문 - 체크박스 옆 라벨 커서는 어떻게 만들어야 할까? (8) by 이 재용
  3. 2014.06.12 [인터랙션] CSS를 이용한 로딩 애니메이션 (7) by Sungi Kim
  4. 2012.03.20 iOS 5.1 애플산돌고딕neo 과 애플고딕 by 無異
2018.07.05 07:50

과거의 디자인이 지금보다 딱딱하고 투박한 이유

어느 날, 저희 블로그 구독자분이 다음과 같은 방명록을 남겨 주셨습니다.

모자이크 브라우저(마크 안드리슨)를 보면서 생각이 들었습니다. '왜, 이런 486 시대에나 볼 수 있는 브라우저 디자인이 먼저 탄생했어야 했는가?

최근, 구글이나 기타 웹사이트 들을 보면 둥글둥글하고 매끄럽고 아기자기한 디자인이 사용된다는 느낌을 받습니다(개인적인생각). 앞서 말씀드린 모자이크 브라우저 같은것을 보면 뭔가 무뚝뚝하고 딱딱하고 투박한 느낌을 먼저 받습니다. 여기서, 왜 이런 순서로 디자인이 변해온것인지 궁금해집니다. 오히려 오늘날의 디자인이 옛것이고 시간이 지나면서 모자이크 브라우저같은 스타일이 오늘날로 업그레이드 될 수는 없었는지 괜한 생각이 들었습니다...ㅠ

물론, 이런 생각조차 이미 과거의 영향을 받았기 때문이라 생각이 듭니다.

왜 디자인은 과거의 것이 더 투박하고 더 딱딱하게 느껴질 수 밖에 없는것일까요; 아니면 이건 저만 느끼는 저만의 착각인걸까요...ㅠ? (디자인에 편견을 갖지 않는 안목을 가지고 싶습니다.)


To. 위 질문을 남겨 주신 '노트테이커' 님께

안녕하세요. 저희 피엑스디는 독자분이 남겨주신 방명록과 댓글에 최대한 답변을 드리려 노력하고 있습니다.

지난 6월, 이 질문을 보았을 때는 곧바로 답변을 드릴 수가 없었습니다. 과거의 투박해 보이는 디자인이 오늘날 둥글둥글하고 매끄러운 모습으로 변한 이유와 그러한 순서로 변한 이유에 대해서 딱 한 마디로 정리하기가 쉽지 않았기 때문입니다.

질문해 주신 포인트를 다시 곱씹어 보았습니다. '자연스러운 현상이 아닌가?' 또는, '일반화하기 어려운 주장이다.'와 같은 편견을 버리고 '왜 그런 느낌을 받게 되는가?'라는 점에서 다시 출발하여 다음과 같이 두 가지 주제로 정리해 보았습니다.

왜, 과거의 웹 디자인은 더 투박하고 딱딱해 보일까?

왜, 시간이 지나 둥글둥글하고 매끄러운 디자인으로 변해온 것일까?


마크 안드리슨의 모자이크 브라우저를 언급하셨기에 디스플레이를 매개로 삼는 웹/그래픽 디자인으로 범위를 좁혔습니다. 과거의 디자인은 투박하고 요즘은 매끄럽다는 점은 영역과 관점에 따라 전혀 다르게 주장할 수도 있겠지만, 질문자가 지적한 포인트 역시 충분히 공감됩니다. 그래서일까요? 이 질문에 대해 저희 피엑스디의 많은 분이 의견을 주었습니다. 그중에 몇 가지를 원문 그대로 소개해 드립니다.



1. 기술적 표현의 한계 때문이다

제 머릿속에 떠오르는 건 '기술적 표현의 한계' 때문인데요.


1. 디스플레이 해상도

90년대~2000년대 초반까지만해도 많이 사용되던 모니터 해상도가 800x600 ~ 1024x768 였는데 (...) 해상도가 낮으니 당연히 섬세한 표현이 어려웠던 것 같아요.


2. 드로잉툴의 불완전성

과거에 픽셀 찍어가며 이미지를 만들었던 건 픽셀작업이 재밌고 멋져서가 아니라 우선 툴이 그렇게 생겼기 때문인데요. 지금이야 포토샵에서 붓으로 찍은 점 가장자리 픽셀들이 투명+조정된 색상으로 표현돼 부드럽게 보이는 게 당연해보이지만 아래 포토샵 초기 인터페이스를 보면......


3. 과거 디스플레이들에서 출력 가능한 색상 / 웹 안전색상(216개)의 한계

웹에서의 이미지 표현이 안전색상(216개)에서 벗어난 건 생각보다 오래되지 않았는데, 이 안전색상이 별 의미가 없었다...는 기사도 본 기억이 나지만 어쨌든 2000년대 초반까지만해도 웹에서 사용할 수 있는 컬러는 대단히 제한적이라고 알려져있었고 지금은 당연하게 여겨지는 부드러운 곡선/곡면 표현이나 그라데이션 또한 색이 "모자라니까" 제대로 그려내기 어려웠을 거고요.


*사족으로...

웹브라우저 인터페이스와 웹페이지 디자인은 구분되어야할 것 같고요.

웹브라우저 윈도우에서는 상단 메뉴키나 하단 프로그레스, 경로, 파일명, 파일크기 등 정보 표시 영역이 필수적으로 존재하는데 콘텐츠(웹페이지)가 보여지는 영역을 최대치로 사용해야하는 한계가 있어 표현이 간소화되는 건 필연이라고 봅니다. 위의 표현적 한계와 제한된 인터페이스 영역, 과거 "버튼"이라고 인지되는 요소의 표준 형태 등을 고려했을 때 모자이크 브라우저는 당시로서는 표현의 최대치였을 것 같아요.



2. 시간을 그런 방식으로 경험했기 때문이다

참 어려운 질문이네요…

어떤 디자인은 시간이 지남에 따라 옛 것으로 느껴지기도 하고, 어떤 디자인은 오랜 시간이 지나도 여전히 현대적인 느낌이 드는데, 일부는 기술의 발전에 따른 것도 있지만, 대부분의 경우는 우리가 시간을 그런 방식으로 경험했기 때문일 것 같아요.

디자인 역사를 전공하신 교수님께 질문해 보시는 것이 좋을 것 같아요.



3. 더 좋아 보이는 것으로 대체된 것이다

과거의 디자인에서 표현 및 형태를 규정지었던 방식이 이후 시간이 흐르면서 더 좋아보이는 방식 혹은 다수가 받아들이는 새로운 방식으로 대체 되었을 때 ‘유행이 지났다’거나 ‘촌스럽다’고 느끼는 것 같아요. 그런데 어떤 디자인은 시간이 흘러서 일부가 바뀌었어도 여전히 그 표현 방식의 핵심이 유지되고 있는 것들이 있는데요, 우리는 이를 두고 ‘여전히 현대적이다’ 라고 느끼게 되는 것 같습니다. 시대가 지나도 유효한 표현방식을 취하고 있으니 이를 높이 평가하는 것이죠. (이런면에선 ‘모던디자인’은 여전히 ‘모던’ 한 것 같습니다)

이런 관점에서 보면 이 질문은 다분히 미학적인 질문이라고 생각되는데요, 미학과 교수님이나 진중권 선생에게 트윗을 해보면 어떨까 싶네요.



4. 클라이언트 퍼포먼스, CSS 때문이다

정답은 없고 주관적인 견해만 있을 질문이네요! 늦었지만 저도 답변 드립니다.

기술적 표현의 한계라는 큰 꼭지는 저도 같습니다. 웹 디자인은 클라이언트측 퍼포먼스와 밀접한 관계가 있는데 시간의 흐름에 맞춰 자연스럽게 디바이스 퍼포먼스는 좋아지고 전보다 높은 연산을 필요로 하는 표현법을 '공식적으로' 지원하기 시작하면 디자이너나 개발자는 새로운 기술을 비로소 적용하기 시작하는거죠.

Border radius는 옛날부터 어떤 방식으로든 구현 해 왔지만, 공식적으로 css3에서 지원하기 시작한건 그리 오래 되지 않았어요. 비슷한 예로 컬러모듈이나 미디어쿼리가 있죠. behance 2018 디자인 트렌드의 그라데이션도, 같은 이유에요.


CSS standard 를 보면, 트렌드라고 부르는 그 시점과 동일한것을 알 수 있어요. 또 웹과 앱 디자인은 트렌드를 공유하며 서로 영향을 받는 관계기 때문에 한쪽에서의 새로운 기술은 굉장히 쉽게 적용되고, 금새 트렌드가 되어진다고 생각해요. 회사에서도 한번 비슷한 주제로 얘기를 길게 한적이 있었는데 (누구였죠? 등판하세요!), 결국에 웹 디자인 트렌드는 CSS3에 큰 영향을 받는다고 생각해요.



5. 스큐어모피즘에서 플랫 디자인으로의 변화다

먼저 질문을 저희 식(?)으로 재해석 해보면...

과거: 투박하고 딱딱 -> 현재: 둥글둥글 매끄러운 디자인

=> 스큐어모피즘 -> 플랫 디자인으로의 변화로 바꿀 수 있을 것 같습니다.


하지만 스큐어모피즘이 투박하고 딱딱해 보인다(=촌스럽다)는 건 편향적이고 잘못된 시각입니다. 단지 요즘 트렌드가 아닐 뿐이죠.

과거에는 왜 스큐어모피즘으로 디자인 되었는가? 라는 더 나은 질문으로 바꿔서 생각해봅시다. 이에 대해서는 크게 두 가지 이유가 있다고 봅니다.


1. 어포던스

스큐어모피즘은 플랫디자인보다 현실 세계의 메타포를 적극적으로 표현하기 때문에 사용자에게 있어 러닝커브를 매우 크게 줄여줍니다.




과거엔 컴퓨터 보급률도 낮았고 디지털 기기의 경험치도 낮았습니다. 때문에 사용자가 현실세계에서 겪었던 개념을 그대로 반영하는 것이 사용성을 높일 수 있는 방안이었습니다. 시각적으로도 더 친숙하게 느낄 수 있기 때문에 진입장벽도 낮출 수 있는 유용한 방법이었을 테고요.

즉, 플랫 디자인보다는 어포던스가 높은 스큐어모피즘이 디자인적으로 더 효과적이었고 그래서 널리 사용되었습니다. 하지만 세살배기도 아이패드를 잡고 유튜브로 뽀로로를 보는 디지털 세대가 주류가 되면서, 이런 어포던스를 제공하는 것에 목맬 필요가 적어졌습니다. 많은 디지털 기기들을 접하면서 대충 어느 것은 버튼이고 어떤 것은 리스트고, 어떤 건 메뉴라는 것들이 이미 디지털 세대들에게는 체화되었기 때문이죠. 거기에 20여년 간 디지털 인터페이스들이 패턴화 된 것도 한 몫 하고 있고요. 그래서 플랫디자인이 사용될 수 있는 여건이 마련되었습니다.


2. 기술적인 한계

플랫 디자인은 위에서 말한 대로 어포던스가 비교적 떨어집니다. 하지만 기술의 발전이 이를 보완해줍니다. 바로 모션(트랜지션)의 등장입니다.


플랫 디자인은 모든 것을 형태와 색 정도로만 표현하기에 정적인 상태로만 표현되면 시각적으로 이해하기 어렵습니다. 하지만 어떻게 등장해서 사라지는지, 손을 댔을 때 어떻게 움직이는지 실제 물체처럼 표현한다면 (=매터리얼 디자인) 동작에 대한 예상(어포던스)을 더 쉽게 할 수 있게 됩니다.

과거에는 컴퓨팅 사양이 낮았기 때문에 모션을 제대로 표현하기가 어려웠습니다. 잘 표현하려면 많은 메모리, 뛰어난 그래픽 연산장치가 필요한데 예전 기술로는 정적인 이미지를 잘 표현하는 것도 힘들었거든요. 지금은 일반적인 웹브라우저에서도 실제와 가까운 모션을 자유롭게 표현할 수 있을 정도로 기술이 발달했고요.

결국 이렇게 모션을 통해 어포던스의 부족함을 채울 수 있게 되면서 플랫 디자인이 큰 문제없이 받아들여지게 됩니다. 재미있는 건, 모션이 얼마나 실제적이냐가 관건이 되면서 스큐어모피즘이 대체된 것이 아니라 오히려 모션 속에서 살아있다는 점입니다. 다시말해 시각적 스큐어모피즘에서 모션의 스큐어모피즘화라고 할 수 있겠습니다.


왜 플랫 디자인으로 바뀌는 걸까?

그냥 스큐어모피즘에 모션만 끼얹는 정도로 발전할 수도 있는 것 아닐까요?

이에 대한 답은 명확하지는 않습니다만, 미술 역사와 비교해 보면 약간의 힌트를 얻을 수 있습니다. 과거 미술도 회화중심의 그림이 위주였지만, 산업혁명 때 사진기가 대중화 되면서 현실을 사진보다 더 똑같이 표현하는 게 힘들어지자 추상적 표현 중심으로 바뀌었죠.

마찬가지로 디지털 세대가 주류가 되면서 더 이상 현실세계의 메타포를 사용하지 않아도 되게 되었고, 스큐어모피즘도 추상적인 표현인 플랫 디자인으로 바뀌어 가는 것이 아닌가 생각합니다.

그리고 스큐어모피즘은 제한된 디스플레이 크기에서는 현실 메타포를 표현하기 위해서 쓸데없이 많은 픽셀들을 소모한다는 단점이 있는데요. 이는 모바일 기기와 같이 작은 디스플레이에서는 매우 치명적인 단점이 됩니다. 때문에 모바일 퍼스트 시기와 맞물리면서 더 픽셀을 적게 소비하는 플랫 디자인으로의 변화는 필연적인 것 같기도 합니다.



마치며

지금까지 소개해 드린 총 다섯 분의 의견은 기술과 시대가 변하면서 그럴 수밖에 없었던 개연성을 말하고 있습니다. 이 글을 읽고 계신 여러분의 생각은 어떠하신가요? 또, 하나의 질문에서 이렇게 다양한 접근과 의견이 나오는 것을 보면서, UX 디자이너에게 '왜?'라는 질문의 중요성을 다시금 생각해 볼 수 있었습니다. 당연하게 쓰이고 있는 디자인 규칙과 인터페이스. 현재 이러한 모습을 보이게 된 기원은 무엇이었는지, 그 과정에 어떠한 일들이 있었는지를 곰곰이 생각해 본다면 근미래의 모습도 예상해 볼 수 있지 않을까요?


*이 글은 브런치에서도 볼 수 있습니다. @uxstar


<함께보면 좋은 글>

두 디자인 대륙의 충돌 - 메타포냐 메트로냐?

스큐어모피즘이란?

스큐어모피즘: 만져지는 UI로의 변화 과정

스팀펑크란?

[독후감] 사물의 이력




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


Trackback 0 Comment 2
Ad Test...
2016.05.12 07:50

세상에서 가장 쪼잔한 질문 - 체크박스 옆 라벨 커서는 어떻게 만들어야 할까?

웹에서 UI를 구성하다보면 별 작은 디테일까지 신경이 쓰일 때가 많다.

브라우저들마다 다 다른 행동을 하는 건 너무 짜증나는 일이지만 어느 정도는 마음을 비운 채로 대하게 되는데, 내가 직접 무언가를 설계하려면 드는 다음과 같은 작은 생각들은, 아 어떤 때는 내가 세상에서 가장 쪼잔한 질문을 하는 사람은 아닌가?하는 생각이 들게 한다.


버튼의 커서

예를 들어,

Quiz 1: 웹 브라우저 상에서 버튼 위에 마우스가 올라가면, 커서는 어떻게 바뀌어야 하는가? 

(이 글은 PC에서 마우스 포인터로 읽어야 제대로 이해가 될 듯)

1) 화살표 모양(arrow)일 것이다. 2) 손 모양(pointer)일 것이다. 3) I자 모양(text or caret)일 것이다.



   난 링크!


마우스를 올려보면 정답은 1) 화살표 모양이다. 반면 링크는 클릭 가능하다는 점을 알리기 위하여 손모양이 표시된다.

그렇다면 왜 버튼은 손모양이 아니고 화살표일까? 만약 이것을 손모양으로 바꾼다면 사용성이 올라갈까? 내려갈까?


너무 쪼잔한 질문이라 민망하지만, 다행히, 이 바닥에 이런 질문하는 사람이 나 혼자는 아니라는 점이 위안이 되기는 한다. 영문으로 자료를 검색해 보면 너무 많은! 질문과 답변이 올라와 있다.


1. 왜 버튼은 디폴트가 손모양이 아니고 화살표인가?

이것은 PC에 있던 장치를 웹에 그대로 가지고 왔기 때문인 것 같다. 링크의 경우 일반 텍스트와 비슷해서 누르면 클릭이 된다는 점을 분명히 해 줄 필요가 있지만, 버튼은 그 자체로 누를 수 있다는 표시가 너무 강해서 (업계 용어로 affordance라고 한다) 굳이 커서를 바꿀 필요가 없었는데, 그것이 웹으로 오면서 기존 규칙을 따르고 있다는 설명이 가장 그럴 듯 하다. (영어 답변 참고)


2. 그렇다면 이것을 손모양으로 바꾸면 사용성이 올라갈까? 그대로일까? 오히려 나빠질까?

그렇다는 사람, 아니라는 사람 모두 섞여있다. 우선 가장 강력한 목소리 하나를 보자.


Microsoft's Windows desktop applications > Design > Guidelines > Interaction > Mouse and Pointers에서 이렇게 설명한다. (Hand Pointers 항목)

Text and graphics links use a hand or "link select" pointer (a hand with the index finger pointing Screen shot of hand with index finger pointing ) because of their weak affordance  .. 중략 ..


To avoid confusion, it is imperative not to use the hand pointer for other purposes. For example, command buttons already have a strong affordance, so they don't need a hand pointer. The hand pointer must mean "this target is a link" and nothing else.

즉, 링크는 워낙 어포던스가 약하니까 손으로 바꾸더라도, 혼동을 피하기 위해 버튼에서는 (이미 강한 어포던스가 있으므로) 손모양을 쓰지마라!!라고 강조한다. 손모양은 링크에서만 써야지, 다른 곳에서 쓰면 안된다는 것이다. 비록 데스크탑 어플리케이션 가이드지만, 웹에서도 비슷하지 않을까?


물론, 우리 나라의 양대 포털이나 쿠팡 디자이너들은 이 생각에 동의하지 않는 것 같다. 네이버, 다음, 쿠팡 모두 버튼의 기본적인 커서 모양은 화살표가 아니라 손모양이다. 사실 이 생각도 공감이 가는 것이, 아무리 버튼이라도 클릭 가능하다면 분명히 마우스 커서의 변화로 알려주는 것이 좋을 수 있다. 텍스트 링크에 하두 익숙하다보면 이젠 커서가 바뀌지 않으면 약간 의심도 들 정도다. 더군다다 데스크탑도 아니고 웹에 있는 버튼이라면 <국제 표준이나 브라우저 디폴트는 따위는 무시하고> 강제로 CSS를 이용하여 커서를 바꿔 주는 것이 좋지 않을까?


체크박스의 커서

그런데 이 문제가 사실은 좀 더 복잡해지는 영역이 있다. 바로 체크 박스와 라디오 버튼이다. 


나 체크 박스1          


Quiz 2: 위 세 가지 형태의 체크 박스를 보고 어떤 차이가 있는지, 어떤 것이 브라우저 디폴트인지, 그리고 어떤 것이 사용성이 가장 좋은지 논하시오.



보통 별 고민없이 마구잡이로 만들면 1번처럼 된다. 즉 체크 박스의 디폴트 커서는 화살표이며, 이는 위에서 '버튼'에 대하여 설명한 바와 같다. 다만 1번의 경우 그 옆의 문구를 눌러도 체크가 되지 않는다. 이렇게 만들면 너무 작은 영역의 체크만 강요하게 되는 셈이다. 그래서 원래 제대로 구현하려면 2번처럼 구현해야 한다. 2번은 글자 부분을 클릭해도 체크가 된다. 그런데 문제는 여기서부터이다.


우선 체크박스가 버튼만큼 어포던스가 분명한가? 그래서 화살표로 해도 큰 문제 없을 정도인가? 개인적으로 동의하기 어렵다. 확실히 버튼만큼은 아닌 것 아닐까?


두 번째, 그러면 버튼 옆의 글자(라벨)은 디폴트 커서가 화살표이다. 이 화살표 만으로 (즉 I-beam 혹은 caret이 아닌 것 만으로) 이것이 클릭 가능하다는 점이 분명해 지나? 절대 아니다. 


그럼 마지막으로, 체크 박스는 화살표, 옆 글자는 손모양으로 해야 하나? 아니면 둘을 통일해야 하나?


나만 헷갈리는 것이 아니고, 아마 포털의 디자이너들도 헷갈리는 모양이다.

위 그림은 네이버(왼쪽 위), 다음(왼쪽 아래), 그리고 쿠팡(오른쪽)의 로그인창을 복사한 것이다. 나름대로 대표성이 있다고 생각해서 골랐는데, 마침 세 회사의 접근 방식이 모두 달라서 비교를 해 보았다.




네이버 로그인 창

  IP 보안 OFF
1회용 로그인
회원가입 아이디 찾기

먼저 네이버 로그인창인데 '로그인' 버튼도 손모양, 아래 체크와 체크 라벨 모두 손 모양으로 세 요소 간의 일관성을 유지하고 있다.
위 대략 구현한 것에서 체크박스, '로그인 상태 유지', 그리고 로그인 버튼 및 다른 링크들에 마우스를 올려 보고 클릭해 보면 어떤 느낌일지 알 수 있다. 역시 위에서 얘기한 '모두 클릭 가능함'을 정확하게 설명하는 느낌이다. 물론 반대하는 사람들은 이것이 너무 과도하다고 주장하는 것이고.

(참고로 네이버 로그인 버튼은 눌려지지 않는다. 눌렀을 때 파란 테두리만 나오고, 들어간 느낌은 보이지 않는다. 아주 옅은 회색의 배경색 지정으로 만들었다. 링크는 밑줄이 없는 형태이다.)



다음 로그인 창

다음, 다음 로그인창인데, '로그인' 버튼은 손모양으로 바꾼 반면 위 체크와 체크 라벨은 모두 화살표로 디폴트를 유지하고 있다.
위 예시에서 여러 요소에 마우스를 올려 보면 느껴볼 수 있다. 버튼이나 링크에 비하여 체크나 체크 라벨은 확실히 누를 수 있을 거라는 느낌이 덜 하지 않나 싶다. 그러나 반대쪽 입장은 이미 두 가지 요소는 인터랙티브한 요소여서 손모양으로 바꾸는 것이 과도하다는 주장이다. 물론 이 주장을 하는 사람들은 '로그인' 버튼도 화살표 커서여야 한다고 주장한다. (참고로 다음의 로그인 버튼은 눌려지지 않는다. 눌렀을 때 파란색 테두리만 나오고 들어간 느낌은 보이지 않는다. 약간의 음영이 들어간 이미지로 만들었다, 링크는 밑줄이 없는 형태이다)



쿠팡 로그인 창

로그인
아이디(이메일)

비밀번호


개인정보 보호를 위해 개인PC에서만 이용해 주세요


아이디 찾기 | 비밀번호 찾기 쿠팡회원이 아니세요? 회원가입

마지막으로 쿠팡인데, '로그인' 버튼은 손모양으로 바꾸었다. 그런데 체크 박스는 화살표로 디폴트를 유지한 반면, 체크 라벨은 손모양으로 바꾸어 버렸다.
역시 여러 가지 요소에 마우스를 올려보면, 느낌을 알 수 있는데, 아마 체크 박스 자체는 표준 권고를 따라서 안 바꾸었지만, 라벨에도 화살표 모양이라는 건 너무 알 수 없다고 생각했는지 라벨만 손모양으로 바꾸었다. 다만 그런 논리라면 '로그인' 버튼은 왜 손모양으로 바꾸었는지 모르겠다. 세 회사 중에 가장 버튼처럼 생겼는데 표준을 따른다면 로그인 버튼도 화살표로 해야 하는 것 같긴 하다.

구현 방법상 작은 차이는 네이버와 다음은 <label for="id" > 같은 형식으로 explicit하게 지정한 반면 쿠팡은 <label>안에 인풋 요소를 넣는 implicit label association을 사용한다는 점이다.

(쿠팡의 로그인 버튼도 눌러지지 않는다. 마우스로 눌렀을 때 파란색 테두리가 생기지만 눌러진 느낌은 보이지 않는다. 버튼은 CSS의 여러 요소를 활용해 만들었다)


세 회사 모두 로그인창 주변의 링크 텍스트는 기본 밑줄을 없애 버렸고 마우스가 올라 갔을 때 밑줄이 나오면서 커서가 손모양으로 바뀌는 변화를 주고 있다. 세 회사 모두 로그인 버튼의 커서는 손모양으로 바꾸었지만, 버튼이 눌리는 효과는 만들지 않았다. 귀찮아서 일까? 별로 중요하지 않다고 생각해서 일까? 아니면 버튼이 아니라 링크라고 생각해서 커서도 손으로 바꾸고 눌린 모습도 안 만든 걸까? (만들려고 마음만 먹으면 CSS로 간단하게 만들어진다)

 

2016년 4월 2일 현재. 세 회사 로그인창을 HTML 상태 그대로 가져오려고 했지만 똑같이 만들려면 작업이 너무 괴로와서 중요 동작만 비슷하게 만들었다, 물론 각 요소의 작은 디테일들이 인터랙션에 영향을 많이 주는 것을 알고 있지만 작업이 너무 괴로울 것 같아 포기하였는데 혹시라도 중요한 글의 요지에 영향을 미치는 중요한 디테일을 놓쳤다면 댓글 부탁드린다.


세 회사가 나름 이유는. 이유가 있을 것이다. 뭐 없으면 어떤가? 이런 쪼잔한 것까지 어떻게 신경쓰랴.. 


결론?

어쨌든 각 회사의 섬세한 정책은 잘 모르겠고, UI 디자이너가 취할 수 있는 정책은 세 가지가 있을 것 같다. 


1. 가이드라인과 기본 설정을 따르자. 

즉 원래의 국제 표준, 가이드라인, 그리고 웹 브라우저 디폴트를 따라야 혼동이 없다. 그렇다면 버튼과 체크 박스 등은 모두 화살표로 둔다. 이 경우 확실한 것 하나는, 체크 박스/라디오 옆 글자(라벨)까지 디폴트로 두어야할지는 모르겠다. 이 부분은 정말 불편하다. 


2. 웹에는 모든 것이 다르다.

따라서 모든 클릭 가능한 것은 손모양으로 바꾸어 준다. 아래의 CSS를 넣으면 된다고 한다. (테스트해보지는 않았다)


a[href], input[type='submit'], input[type='image'], label[for], select, button, .pointer { cursor: pointer;}


문제는 오랜 역사로 성립된 디폴트값을 이렇게 CSS로 강제적으로 바꾸는 것에 대해 많은 디자이너들이 우려와 불쾌를 표현한다는 점이다. 위 CSS의 출처: Give Clickable Elements a Pointer Cursor를 보시길.


3. 다른 건 다 표준을 따르되, 라벨만 좀 바꾸자

표준에 대한 존중이 중요하다. 하지만 라벨은 너무 사용성이 떨어진다. 그러므로 라벨과 라벨이 있는 체크/라디오만 좀 바꾸자. 

이 원칙의 문제는 너무 절충이라는 거? 그래도 개인적으로는 이것이 가장 좋아 보인다. 원래 성격이 그런 듯.



중요한 것은 '우리의 마음'이 이제 화살표 만으로는 '클릭 가능'이라고 잘 생각하지 않는 것 같다는 점이다. 네이버 등 한국 웹 사이트에 길들여져서 그런걸까? 구글은 버튼에 화살표를 쓰고, 페이스북은 버튼에 손모양을 쓴다. 페북에 길들여진 걸까?


다른 디자이너들은 어떻게 생각하는지 궁금하다.


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


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


Trackback 1 Comment 8
Ad Test...
2014.06.12 02:16

[인터랙션] CSS를 이용한 로딩 애니메이션

이전에 블로그에서 Youri Kim님이 '재미있는 로딩 애니메이션' 포스트를 통해 로딩 애니메이션에 대한 설명과 사례를 소개해주셨죠. 이번 글에서는 웹디자인/개발을 할 때 바로 사용할 수 있는 로딩 애니메이션을 공유하려고 합니다.

아마 웹디자인을 주로 하시는 분들은 더 많이 아실 것 같은데요, 최근 CSSDeck이나 CodePen같은 곳들을 자주 들어가서 구경을 하고 있습니다. 거기에 올라오는 여러 인터랙션 예제들이 재미있거든요. 전문 분야가 아니라 확실히는 모르지만, HTML, CSS, JavaScript등을 사용하는 웹 환경이 성숙해지면서 예전에 Flash, Animation GIF로 처리했던 것들을 이제 CSS, JavaScript를 이용하여 구현하는 것 같습니다. 그러다보니 글자로 된 코드만 공유하면 누구든 간단히 코드를 수정하여 애니메이션을 변형시킬 수 있는 환경이 되었고요. CodePen사이트의 타이틀만 봐도 'Front End Developer Playground & Code Editor in the Browser' 입니다. 그 Playground에서 찾아본 로딩 애니메이션을 공유합니다. 다소 식상할 수도 있지만, 코딩을 통해 구현했고 소스를 응용해 직접 사용할 수 있다는 것이 끌리게 만들었습니다.


*각 사례 상단의 'HTML'과 'CSS/SCSS/Stylus'탭을 클릭하면 소스를 보실 수 있습니다.

See the Pen Loader #1 by Sam Lillicrap (@samueljweb) on CodePen.

출처 : http://codepen.io/samueljweb/pen/LbGxi

See the Pen Simple CSS Loading animation by Dom Sammut (@domsammut) on CodePen.

출처 : http://codepen.io/domsammut/pen/eJbly

See the Pen Simple CSS3 Animation Example by Rex Kirby (@rexkirby) on CodePen.

출처 : http://codepen.io/rexkirby/pen/ftJro

See the Pen Spinny Loader by Tim Holman (@tholman) on CodePen.

출처 : http://codepen.io/tholman/pen/mgsBy

See the Pen CSS Spinning/AJAX Wheel by Jabran Rafique (@jabranr) on CodePen.

출처 : http://codepen.io/jabranr/pen/GLFjv

See the Pen Loaders (WIP) by Tania LD (@TaniaLD) on CodePen.

출처 : http://codepen.io/Zeneraith/pen/bdEmA

See the Pen Such Spinners, Much Loading by Hsu-Cherng (@Zeneraith) on CodePen.

출처 : http://codepen.io/Zeneraith/pen/bdEmA

See the Pen Tiny Single Element Loading Animations by J Howell (@lixquid) on CodePen.

출처 : http://codepen.io/lixquid/pen/ybjmr

See the Pen Twinner Spinner by Katy DeCorah (@katydecorah) on CodePen.

출처 : http://codepen.io/katydecorah/pen/tbjqx

See the Pen Super Simple CSS Spinner by Thomas Mandelid (@mandelid) on CodePen.

출처 : http://codepen.io/mandelid/pen/vwKoe

See the Pen Loading icon 4 by oboro (@obomemo) on CodePen.

출처 : http://codepen.io/obomemo/pen/vtpAl

출처 : http://tobiasahlin.com/spinkit/




마지막으로, 이 사례는 어떠신가요? 애니메이션이 잘 보이지 않을 수 있으니, 출처에 링크된 페이지를 열어서 보시는 것이 좋습니다.

See the Pen SVG animation by Olaf (@olliex) on CodePen.

출처 : http://codepen.io/olliex/pen/moyjI


[참고##영감 동영상##]

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


Trackback 0 Comment 7
Ad Test...
2012.03.20 10:36

iOS 5.1 애플산돌고딕neo 과 애플고딕

iOS 5.1 로 업데이트 하고 세상이 달라졌습니다. 비스타의 맑은고딕이 나왔을때랑 네이버의 나눔고딕이 나왔을때 처럼 너무 설레였습니다. (세가지 폰트 모두 산돌에서 만들었네요.)

그런데 몇몇 사이트들은 5.0 이전 보다 더 심각하게 나빠보이는 경우가 있습니다. 테블릿 버전 네이버 검색결과 이나 티스토리 페이지들이 어딘지 모르게 너무 더 이상해 보여서 살펴보니 5.1에 포함된 애플고딕은 이전 버전에 포함된 애플고딕과 다른 폰트였습니다. 친절하게 macos나 ios를 고려하여 css 서체 속성에서 AppleGothic을 포함한 사이트들은 오히려 가독성도 안좋고 못 생긴 페이지가 되었습니다.





간단히 테스트 페이지를 만들어서 폰트를 비교해보았는데요.

5.1에 포함된 애플고딕은 이전 버전보다 가늘어지고 글자 높이가 줄어들었습니다. 영문의 kerning도 뭔가 잘 못되어 있는 것처럼 보이고요.



결론

혹시 ios를 고려해서 css 파일의 font-family 속성에 appleGothic을 포함하고 있다면 빼주는 것이 더 가독성이 좋습니다.
꼭 좀 빼 주세요. 

[참고##애플고딕##] 

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


Trackback 1 Comment 0
Ad Test...