Framer, Flinto, Origami, Invision. 많은 프로토타이핑 도구가 존재합니다. 디자인에 활력을 불어넣고 개발팀과의 커뮤니케이션을 위해 필수라고 하는 프로토타이핑. 어떻게 하기는 해야겠는데 어려운 도구나 코드를 공부하기엔 시간이 없고, 막상 열심히 공부하면 새로운 버전이 나오고, 더 좋은 도구가 나오고. 이런 경험을 많이 하셨을 겁니다. 프로토타이핑 도구로 멋지고 완결된 시나리오를 가진 결과물을 만들 수도 있습니다. 하지만 우리에게 당장 필요한 것은 지금 당장 떠오르는 아이디어를 보여줄 수 있는 아이콘의 간단한 모션, 쓱 움직이는 화면 전환 같은 것이 아닐까요? 오늘 배워서 바로 쓸 수 있는, CSS 애니메이션으로 하는 간단한 프로토타이핑 방법을 소개합니다. 



어디서, playground

코딩을 공부하려면 텍스트 에디터도 설치해야 하고, 각종 패키지도 설치해야 합니다. 결과물이 담길 파일도 생성해야 하고, 여러 파일이 연결되니까 폴더 구조도 고민해야 하죠. 이런 고민을 하다 보면 시작조차 하기 싫어집니다. 그래서 브라우저에서 바로 작성하고 확인하고 공유할 수 있는 온라인 코딩 플레이 그라운드가 있습니다. 대표적으로 jsbincodepen이 있습니다. 그냥 해당 서비스에서 가서 각 섹션(HTML 또는 CSS)에 맞게 코드를 입력하기만 하면 됩니다. 우리는 HTML과 CSS섹션만 사용할 예정입니다. js와 같은 다른 섹션은 최소화(minimize)해주세요.


어떻게 시작하나

html에 내용을 담고, CSS에 디자인(스타일)을 담을 겁니다. 당장 직접 작성하기는 어려우니 예제(https://codepen.io/yunkimoon/pen/BZEYgY)의 HTML과 CSS코드를 그대로 복사합니다. 코드의 주석(회색글씨)을 확인해 봅니다. 요약하면 아래와 같습니다. 


- 가장 바깥의 파란 배경 상자
- 이미지와 그걸 담고 있는 상자
- 파란 배경 상자에 hover(마우스 오버 이벤트)를 하면,
- left 포지션을 2%에서 80%로 변경


여기서 중요한 건 .box상자에 설정된 transition이라는 속성입니다. transition은 딱딱한 움직임을 부드럽게 해줍니다. 여기서는 position left를 2%에서 80%로 부드럽게 바꿔주었습니다. 위치뿐만 아니라 색상(color, background), 크기(width, height)도 자연스럽게 바꿔주는 속성입니다. “all 3s”라는 값을 가지고 있는데 “모든 변경사항에 대해 3초 동안 움직여라”라는 의미입니다. 


꼭 알아야할 3가지

CSS 애니메이션의 맛을 잠깐 보았습니다. transition을 통해 부드러운 움직임을 줄 수 있습니다. 하지만 더 복잡하고 멋진 움직임을 위해서는 많은 속성들을 이해하고 응용할 수 있어야 합니다. 하지만 모든 속성을 다 알아볼 수는 없으므로 가장 중요한 3가지를 알아보도록 하겠습니다. 미리 살펴본 transition과 transform, keyframe(s) 입니다. 


1. transition 
위에서 살펴본 것처럼 대상의 위치, 크기, 색상 등에 부드러운 움직임을 줍니다. 

2. transform 
대상의 위치, 크기, 방향 등을 상대적으로 변경합니다. 예제를 통해 알아보겠습니다. 



2.1. rotate 
대상에 각도 값을 설정합니다. 즉, 주어진 값만큼 회전합니다. 첫 번째 예제와 조금 다른 부분은 :hover { }에 작성된 내용입니다. transform:rotate(360deg)에서 rotate는 회전을 뜻하고, 360deg는 각도입니다. 즉, 360도(한 바퀴)만큼 회전하라는 의미입니다. 미리 transition이 걸려있었기 때문에 부드럽게 회전하는 모습을 볼 수 있습니다. 


2.2. translate 
대상의 이동 값을 설정합니다. 주어진 값만큼 이동합니다. 값은 좌푯값으로 x축, y축 값을 나눠서 줍니다. transform: translate(100px, 100px)에서 translate는 이동을 뜻하고, 이후에 나오는 값은 순서대로 x축의 이동값, y축의 이동 값입니다. 그런데 y축 이동 값이면 위로 올라가야 할 것 같은데, 그림은 아래로 이동합니다. 그 이유는 스크린에서 좌측 위가 기준점이기 때문입니다. 


2.3. scale 
대상의 크기를 설정합니다. 즉, 주어진 값만큼 늘어나거나 줄어듭니다. 값은 가로 값, 세로 값을 차례로 줍니다. transform:scale(1.5, 2)에서 scale은 크기를 뜻하고, 1.5와 2는 각각 가로값, 세로값을 뜻합니다. 가로는 1.5배가 늘어나고 세로는 2배가 늘어납니다. 그래서 그림은 세로로 긴 비율로 보입니다. 


이제 우리는 CSS만으로 대상의 위치, 크기, 회전 애니메이션을 줄 수 있습니다 :) 


3. keyframes

마우스 오버 액션에 대한 애니메이션을 보아왔습니다. 이렇게 사용자의 특정 반응(마우스 오버)이 없어도 자동으로 움직이도록 할 수는 없을까요? 앞의 두 예제보다 조금 복잡하지만 keyframes를 사용하면 가능합니다. keyframes는 미리 움직임을 지정해두고, 대상에 해당 애니메이션의 속성을 부여하는 방식으로 작성됩니다. 예제를 확인해 보겠습니다. 



3.1. spin

앞서 살펴 본 transform의 rotate를 미리 애니메이션을 만들어 놓고 대상에 animation이라는 속성을 설정했습니다. 

@keyframes spin 처럼 spin이라는 애니메이션을 설정합니다. 그 안에는 from과  to가 있는데 각각 시작과 끝을 뜻합니다. 즉, 시작할 때는 회전이 0(rotate(0deg))이고 끝날 때는 회전이 360도(rotate(360deg))입니다. 

대상과 keyframes를 연결할 때는 대상에 animation: spin 8s infinite linear;와같이 애니메이션 속성을 줍니다. spin은 keyframes의 이름, 8s는 8초 동안, infinite는 무한 반복을 뜻합니다. 여기서 linear는 easing을 나타내는데, 우선은 조금 딱딱한 애니메이션이라고 해둡시다. 


3.2. leftAndRight

transform의 translate를 활용해서 우측으로 이동했다 돌아오는 애니메이션을 반복시키는 예제입니다. from과 to대신 조금 상세한 타임라인을 가지고 있습니다. 0%, 50%, 100%는 타임라인을 구성하는 속성들로 전체 애니메이션 시간 동안 해당하는 타이밍에 맞게 속성이 변경됩니다. 역시 infinite 속성이 있어 계속 반복되고 있습니다. 그리고 마지막에 linear대신 ease라는 속성을 넣어서 조금 부드러운 움직임 표현했습니다. 


3.3. hideAndShow

앞서 다루지 않은 opacity(투명도)를 활용했습니다. 1이 100%이고 0은 보이지 않는 상태입니다. 1 → 0 → 1을 반복하며 보였다 안 보였다 하는 애니메이션을 보여줍니다. 

이제 우리는 CSS만으로 대상의 위치, 크기, 회전 애니메이션 반복적으로 사용할 수 있게 되었습니다. 그리고 무한 반복 애니메이션도 만들 수 있습니다. 


마무리 예제


앞서 살펴본 예제들을 활용한 마무리 예제를 만들어 보았습니다. 앞서 공부한 내용을 바탕으로 소스를 분석해 보시기 바랍니다. 각 버튼에는 transiton으로 부드러운 hover 전환 효과를 주었고, 녹색의 메시지는 keyframes를 주어 상하로 계속 움직이도록 했습니다. frame에 마우스가 올라가면 메시지는 프레임 바깥으로 밀려나고 사용자 메뉴가 프레임 안으로 이동하도록 했습니다. 메뉴는 하위 메뉴가 펼쳐지는 인터렉션을 가지고 있습니다. 


마치며

전문 프로토타이핑 도구보다 결과물이 투박하고, 지금 당장 만들 수 있는 장면도 제한적입니다. 자바스크립트 같은 동적 언어가 들어가 있지 않아 표현할 수 있는 화면도 많지 않습니다. 기본적으로 제공되는 템플릿이나 자원이 없으므로 하나하나 HTML로 코딩하거나 공개 소스를 넣어가면서 만들어야 하는 수고로움도 존재합니다. 

하지만 실행만 해도 막막한 도구들을 바라보며 “언제 한 번 해보나”하는 생각을 할 시간에 간단히 익혀 한 번이라도 써먹을 수 있다면 그 자체로 의미가 있지 않을까요? 물론 탄탄한 시나리오와 설계를 가지고, 제대로 만든다면 전문 프로토타이핑 도구보다 절대 뒤쳐지지 않을 것입니다. 그리고 우리가 만든 코드들은 커뮤니케이션을 위한 전달용이 아니고 실제로 쓰일 수도 있는 코드라는 점에서도 의미가 있습니다. 간단한 프로토타이핑이라도 지금 시작해 보면 어떨까요? 



참고 

w3school

- https://www.w3schools.com/css/css3_animations.asp

- https://www.w3schools.com/css/css3_transitions.asp

- https://www.w3schools.com/css/css3_2dtransforms.asp

- http://report.stibee.com/2017 by 슬로워크 스티비팀 조은지 디자이너



Posted by slowalk



들어가며


지난 글, “스타일 가이드로 웹서비스 개발하기”를 통해 스타일 가이드가 무엇인지, 그리고 웹서비스 개발에 스타일 가이드가 얼마나 중요한지 알아보았습니다. 스타일가이드는 단순히 디자인과 프론트엔드 개발의 참고안이 아닌, 서비스와 함께 성장하는 역할을 합니다. 서비스의 운영과 함께 지속적으로 업데이트되며 성장합니다. 

사용자에게 일관된 사용자 경험을 전달하기 위해 UI의 통일성과 확장성은 필수적입니다. 스타일 가이드는 이를 체계적이고 쉽게 할 수 있도록 도와줍니다. 또한, 점점 비대해지는 서비스의 뿌리 역할을 합니다. 

이번에는 스타일 가이드를 실제로 어떻게 작성하고 유지해가야 하는지 알아보겠습니다. 



어떻게 시작할까


하얀 캔버스 위, 비어있는 텍스트 에디터를 보면 난감합니다. 무엇을 만들지 먼저 고민해야 합니다. 먼저 스타일 가이드에 무엇이 들어가야 할지 구상해 봅니다. 서비스의 와이어프레임이나 화면설계가 미리 준비되어 있다면 매우 좋습니다. 그러면 이를 분해하는 작업부터 시작할 수 있습니다. 






화면설계에서 시작하기


서비스가 완성품이라면 스타일 가이드는 ‘조립’을 위한 ‘부품’의 모음입니다. 따라서 완성품을 분해하여 부품을 유추하는 과정으로 시작합니다.


화면설계를 분석하여 UI단위를 분리합니다. 버튼을 하나하나 따로 분리할 수도 있고, 버튼의 모음으로 분리할 수도 있습니다. 화면에서의 역할이나 목적으로 분리할 수도 있고, 개발 관점에서 <table>이나 <form>과 같은 HTML 태그 단위로도 분리할 수 있습니다. 어쨌든 부품을 만들기 위해 분해를 해야 합니다. 이 분해된 단위를 컴포넌트라고 합니다. 


컴포넌트를 나누는 기준은 매우 중요합니다. 너무 작은 단위로 나누면 “가이드”라는 말이 무색할 정도로 어렵고 복잡해질 것이고, 너무 큰 단위로 나누면 상황별로 재사용하기 어려울 수 있습니다. 저는 가장 중요한 기준은 ‘독립성’과 ‘재사용성’이라고 생각합니다. 분해된 ‘부품’은 너무 작지 않아야 합니다. 스스로 독립적인 “상태”를 가지고, “동작 또는 표현”할 수 있어야 합니다.


버튼을 예로 들어 보겠습니다. 버튼은 활성화, 비활성화, 마우스 오버에 대한 반응, 클릭 이후의 변화 등의 상태를 갖습니다. 그리고 가로, 세로, 여백(padding)과 품고 있는 텍스트의 크기와 같은 표현 값을 가집니다. 버튼의 역할을 부연설명하는 아이콘이 들어갈 수도 있습니다. 이 버튼은 독립적으로 존재하므로 하나의 컴포넌트라고 부를 수 있습니다. 버튼에 상태와 표현을 조금씩 변경하면 다른 상태, 모양의 버튼을 몇 번이고 재사용할 수 있습니다. 


화면설계서의 분해



화면설계가 없다면?


화면설계를 분해하면서 컴포넌트들을 정의하는 방법이 좋긴 하지만, 화면이 설계되기 전에 미리 스타일 가이드를 구성할 수도 있습니다. 웹서비스에 쓰일 부품부터 미리 정의해보는 겁니다. 웹서비스에서 자주 쓰이는 버튼, 드롭다운, 목록, 테이블, 양식(form)등을 미리 구상하여 통일성 있게 구성합니다. 

완성품을 예측하여 부품을 만들기란 매우 어려운 과정입니다. 설계 전에 정확히 어떤 요소가 필요할지 미리 알 수 있을까요? 설계하면서 변경되는 경우도 많을 것입니다. 잘 설계된 부품을 조합했을 때 원하지 않은 모습이 나올 수도 있습니다.


그럴 때는 공개된 스타일 가이드를 참고하는 것이 좋습니다. 유명한 Bootstrap이나 Foundation과 같은 프레임워크의 구성을 살펴보겠습니다. bootstrap이나 foundation은 그 구성이 매우 방대하고, 많은 테스트를 거쳐 견고한 상태입니다. 처음부터 이런 완성도를 기대할 수는 없고, 작은 부분부터 참고합니다. 


방대한 프레임워크 안에서 우리에게 필요한 것들을 추리고, 여기서 우리의 부품 만들기를 시작합니다. Bootstrap의 CSS를 보면 기본적인 헤딩의 타이포그래피부터 테이블 양식(form), 버튼 등 기본 UI들이 미리 구성되어 있습니다. 세부 내용을 보면 상황에 맞게 적용할 수 있도록 여러 크기와 상태로 구성된 것을 볼 수 있습니다. 여기서 우리에게 필요한 것들만 취해봅니다. bootstrap에서는 4가지의 크기와 5가지의 상태를 가진 버튼이 있지만 우리 서비스에 필요한 것은 3개라면? 그냥 그렇게 구성하면 됩니다. 스타일 가이드는 언제든 추가, 보완할 수 있으니까요.



프레임워크의 구성 참고



컴포넌트 + @


우리 서비스는 매우 단순하니까 몇 가지 기본 컴포넌트만 넣기로 했습니다. 계속해서 Bootstrap의 CSS를 살펴보는데 “Helper classes”라는 것이 보입니다. 구성에는 텍스트 색상, 정렬, 상자의 정렬, clearfix 등이 있습니다. 이건 어떻게 쓰는 것이고, 어떻게 우리 서비스에 도움이 될까요? 디자이너와 개발자의 취향의 문제이지만, 컴포넌트 외에 서비스 구성을 돕는 이런 “헬퍼”가 필요합니다. 이 헬퍼는 컴포넌트처럼 명확히 눈에 띄고 독립성을 가지진 않습니다. 다만 여러 컴포넌트에게 두루 적용할 수 있는 정렬이나 자주 쓰이는 색상과 상태를 미리 준비해 놓은 것입니다. 이런 헬퍼들이 있어야 통일성있는 CSS 코드를 작성할 수 있습니다. 무엇보다도, 편합니다. 


컴포넌트의 공통적인 상태를 정의하는 헬퍼



HTML, CSS 작성하기 


컴포넌트 구성이 끝났다면 실제 서비스에 적용할 코드를 작성해야 합니다. 서비스의 동적인 부분은 우선 무시하고 HTML과 CSS로 컴포넌트. 즉, 부품들을 작성합니다. HTML 마크업을 할 때는 되도록 컴포넌트 단위로 작성하고, 이후 쉽게 복사하여 사용할 수 있어야 합니다. 컴포넌트의 역할과 상태를 정확하고 알기 쉽도록 class 이름를 지어줍니다. box, area와 같이 혼동할 수 있는 이름보다는 heading-box나 contents-area와 같은 구체적인 이름이 좋습니다. 


CSS는 컴포넌트의 복잡한 정도에 따라 길어질 수 있습니다. 다양한 상태를 표현해야 한다면 코드는 복잡해지고, 다른 컴포넌트의 스타일 간섭이 있을 수 있습니다. 이를 막기 위해 SASS와 같은 전처리기를 사용합니다. CSS 전처리기는 간결한 문법으로 작성하고 이를 CSS로 변환하여 적용하는 개발 편의 도구입니다. 대표적으로 SASSLESS가 있습니다. 작성하기 쉽고, 무엇보다 유지보수가 편합니다. 코드의 가독성도 매우 좋습니다. 컴포넌트의 이름 단위로 nesting한다면 굉장한 업무 효율을 기대할 수 있습니다. 



SASS로 간결하게 




마치며


세상에 100가지 웹서비스가 있다면 개발방식도 100가지가 있을 것입니다. 어쩌면 100가지를 넘을 수도 있습니다. 디자이너와 개발자의 취향에 따라 많은 선택지가 있어 같은 사람이 같은 서비스를 만들어도 다른 결과물이 나올 수 있기 때문입니다. 내 머릿속에 서비스의 지도가 한 번에 그려진다면 어쩌면 스타일 가이드는 필요하지 않을 수 있습니다. 하지만 점점 커지는 서비스의 구석구석을 모두 기억하는 것은 불가능합니다. 무엇보다 우리는 혼자가 아니어서 하나의 결과물을 다수가 만들고 있습니다. 

여러 사람이 만들어도 마치 한 명이 작업한 것처럼 UI의 품질과 통일성이 보장되고, 지속적인 확장이 가능한 이유는 이런 스타일 가이드가 존재하기 때문입니다. 


스타일 가이드는 그 자체로 영감의 원천이 될 수도 있습니다. 컴포넌트를 분리하고 조합하는 과정에서 새로운 아이디어를 얻을 수 있고, 지속적으로 업데이트를 통해 서비스 품질을 향상시킬 수 있기 때문입니다. 아주 작게 시작할 수 있습니다. 스크린 단위의 화면을 디자인하기 전에 스타일 가이드를 고려해 보는 것은 어떨까요.





작성: 문윤기


Posted by slowalk

웹사이트의 95%는 텍스트로 이루어져 있다고 합니다. 여러분이 읽고있는 이 글 또한 웹에 적용된 타이포그래피라고 할 수 있을텐데요, 사이트 방문자가 콘텐츠를 잘 읽고 목적지를 쉽게 찾아갈 수 있도록 하는 웹에서의 타이포그래피는 인쇄물에서의 그것보다 더 중요하다고 해도 과언이 아닐 것입니다. 웹 디자이너가 적용할 수 있는 웹 타이포그래피 요소와 디자인 팁을 소개합니다.





다양한 폰트의 선택, 미세한 활자의 조정이 가능해 디자이너의 창의성을 발휘할 수 있는 인쇄 작업과는 달리 웹에서 완벽한 타이포그래피를 구현하기에는 한계가 있습니다. 그럼에도 불구하고, 다양한 스타일의 웹폰트와 CSS의 출연으로 그래픽툴을 이용하지 않고도 웹상에서 훌륭한 타이포그래피를 구현할 수 있게 되었습니다. 웹에서 좋은 타이포그래피를 구현하는 방법을 디자인의 원리와 요소를 통해 알아보겠습니다.


타이포그래피의 요소, 웹에 적용하기 

Hierarchy(계층)

신문이나 잡지 등의 인쇄 매체에서 텍스트를 보여줄 때는 일련의 계층 구조가 필요합니다. 웹도 마찬가지입니다. 가독성이 좋은 웹페이지는 중요도에 따라 헤더와 서브타이틀, 본문, 링크 등이 시각적으로 구조화되어 시각적으로 안정감을 줍니다. 웹에서의 텍스트 계층은 글꼴의 크기 차이를 두는 것 외에도 굵기, 컬러, 기울임, 폰트 선택 등으로 적용할 수 있습니다. 타이틀과 본문을 구분지어주는 기본적인 역할부터 중요도에 따라 콘텐츠를 나누어 사용자들이 잘 읽을 수 있도록 도와줍니다. 



계층이 명확한 컨텐츠 구조는 사용자가 어디에서부터 어떠한 방식으로 글을 읽어가야 하는지 안내해 줍니다.


 

Contrast(대비)

흰 배경에는 블랙 계열의 컬러를 사용하고 헤드라인과 본문의 텍스트 크기의 차이를 두는 것 모두 대비라는 요소를 적용한 것입니다. 일반적으로 배경과 텍스트 색상의 강한 대비는 가독성을 높여줍니다. 




크기와 컬러의 '대비'는 컨텐츠의 가독성을 높여줍니다.



하지만 지나친 대비는 오히려 사이트의 분위기를 해치고 텍스트 요소간의 결합을 흩뜨리며 가독성을 떨어뜨립니다. 흔히 블랙과 화이트의 강렬한 대비가 가독성을 높여준다고 생각하기 쉽지만, 빛을 내는 스크린에서의 이러한 강한 대비는 오히려 눈에 피로감을 줄 수 있습니다. 때문에 본문의 컬러는 완전한 블랙이 아닌 진한 회색 계열의 컬러를 사용하는 것이 좋습니다. 


컬러 

웹에서의 컬러는 시선을 유도하고 사용자들이 콘텐츠를 그룹화 해 읽을 수 있도록 도와주는 중요한 요소입니다. 전체 사이트의 분위기와 사용자의 행동까지 유도하는 웹에서의 컬러 선택은 그만큼 중요하다고 할 수 있을텐데요, 그렇다면 웹에서의 글꼴 컬러 선택은 어떻게 하는 것이 좋을까요?


1. 텍스트의 가독성을 위해 배경과 글꼴 요소간의 충분한 컬러의 대비를 부여합니다.

2. Less is more - 제한된 컬러의 사용은 콘텐츠를 더욱 돋보이게 해 줍니다.

3. 온,오프라인 컬러 시스템 통일 - 브랜드 로고 및 아이덴티티 컬러를 적용하면 사용자들에게 일관된 시각적 메시지와 통일감을 줄 수 있습니다. 때문에 브랜드에 사용된 컬러 시스템을 토대로 Main, Sub, Point컬러를 텍스트에 조화롭게 적용하는 것이 좋습니다. 



브랜드의 컬러 시스템을 적용한 웹사이트 (http://www.heungkuklife.co.kr/)




크기

텍스트의 역할과 중요도에 따라 달라지는 크기는 어떠한 요소를 강조하거나 그 반대의 경우를 위해 사용됩니다. 강조를 위한 너무 큰 크기의 사이즈도, 너무 작은 사이즈도 시각적인 균형을 깨트립니다. 때문에 보기 좋은 헤드라인과 본문 글꼴의 적당한 크기 차이를 두어 구성하면 시각적 안정감을 돕습니다. 일반적으로 타이틀에 사용되는 글꼴의 크기는18px ~ 32px, 본문에 사용되는 사이즈는 12px~16px 정도이며, 웹에서 잘 읽을 수 있는 최소 폰트의 사이즈는 13px, 0.813em라고 합니다. 



비율(Scale)

우리가 보는 웹페이지에는 다양한 크기의 텍스트가 적용되어 있습니다. 타이틀과 본문 등을 적당한 비율의 크기로 배치한다면 콘텐츠를 더욱 짜임새 있게 구성할 수 있습니다. typescale은 1.618이라는 황금비율을 포함한 다양한 비율을 적용해 폰트 크기를 비교해 볼 수 있는 사이트입니다.

 


http://type-scale.com/



행간(line-height), 자간(letter-spacing)

인쇄물과 마찬가지로 웹에서의 행간과 자간은 본문의 가독성에 중요한 역할을 합니다. 어느 정도의 줄간격은 가독성을 더욱 높여줍니다. 특히 폰트의 크기가 작을수록 자간을, 내용이 많은 문단일수록 행간을 늘여주는 것이 좋습니다. 너무 좁은 줄간격도, 넓은 줄간격도 좋지 않으며 폰트 사이즈의 150%이상의 행간은 읽기 좋은 본문을 만들어줍니다. 

참고글 - 웹디자인에서의 자간과 행간에 관한 고찰 



어떠한 폰트를 선택할까?

Less is More

모든 종류의 시스템폰트를 웹에 적용할 수는 없지만 '돋움체, 굴림체' 등 웹상에서의 폰트 선택이 제한적이었던 과거에 비해 다양한 웹폰트를 사용할 수 있게 되었는데요, 과연 웹페이지에서 많은 웹폰트를 적용한 화려한 디자인이 과연 좋은 디자인일까요? 좋은 웹사이트는 한 가지 폰트로도 위에 언급한 '대비'요소를 통해 크기와 두께, 색상의 변화만으로 사이트 전체에는 시각적 통일성과 안정감을 주고, 사이트의 무게는 더욱 가볍게 만듭니다.



이미 검증받은 폰트 선택, 절반은 성공!

오랜 역사와 대중성 있는 폰트는 그 자체로 가독성과 조형성을 갖추고 있습니다. 명조, 고딕이 들어간 웹폰트가 널리 사용되는 이유 또한 가독성이 높기 때문입니다. 다양한 굵기의 서체를 지원하는 Adobe의 본고딕 또한 깔끔하고 뛰어난 가독성 때문에 많은 사이트에서 이용되고 있습니다.



타이틀과 본문에 어울리는 폰트 선택.

같은 크기에서 가독성이 더 우수한 폰트가 있을까요? 헤더와 본문 등 각 영역에 어울리는 폰트는 따로 있습니다. 일반적으로 세리프(Serif)글꼴은 본문에 작은 크기로 적용되었을 때 뭉개지는 현상이 있는데요,(예외로, Georgia같은 폰트는 크기가 작을 때 더 좋은 가독성을 보입니다.) 때문에 폰트가 어떤 영역에 적용되는지에 따라 적합한 폰트를 선택해야 합니다.



'명조(Serif)는 본문이 아닌 타이틀에 크게 적용되었을 때 웹에서 더 우수한 가독성을 보입니다.



영문과 한글의 조화 

한글 웹폰트에 비해 영문 웹폰트는 선택 폭이 넓습니다. 한글과 영문을 함께 사용할 때, 한글 웹폰트로도 영문을 쓸 수는 있지만, 사이트의 심미적인 부분을 좀 더 고려한다면 영문 웹폰트를 독립적으로 사용하기도 합니다. 적용 명조체에는 세리프 서체, 고딕체에는 산세리프 서체가 잘 어울립니다. 사이트의 성격과 분위기에 맞는 한글과 영문의 조합은 시각적 통일성을 높입니다.



나눔고딕 + Lato 


나눔명조 + PT Serif 



좋은 타이포그래피는 웹사이트가 전달하는 메시지를 돋보이게 해 주며 명확하게 내용을 전달 해 줍니다. 웹에서의 타이포그
피 활용를 통해 방문자들이 더 머물고 싶은, 즐겨찾는 사이트를 디자인 하는 데 도움이 되길 바랍니다.


출처 : Smashing Magazine, tutsplus, typecast


by 소금쟁이 발자국

 

Posted by slowalk



디자이너와 개발자는 너무 다릅니다. 여러 가지 이유가 있겠지만, 작업 방식부터 다르기 때문이라고 생각합니다. 실제로 웹 개발실에서 일하면서도 많이 경험할 수 있었는데요. 그중 가장 문제가 많이 생기는 부분이 폰트라고 생각합니다.


서체의 경우, OS, 브라우저의 렌더링 스타일이나 유료폰트 구매 문제로 귀결됩니다. 하지만 자간과 행간은 맞출 수 있음에도, 디자이너분들과 소통하지 못했습니다. 저는 디자인을 전공했지만, 디자인을 정확하게 구현하고 싶은 마음에 개발을 시작했습니다. 하지만 초심과 다르게, 효율을 중시한 나머지 자간과 행간을 간과하는 경우가 많았습니다.


이 부분이 문제 제기되어 방법을 모색하게 되었는데요. 그 내용을 공유합니다.


여담이지만 디자인과 출신인 저도 자간, 행간에 대한 감각이 형편 없습니다.


자간과 행간의 기준은 디자이너들 사이에서도 많은 차이가 납니다. 모바일에서 잘 안 보인다고 만지지 않는 분이 있지만, 편집디자인처럼 세세하게 다 보시는 분도 있습니다.


다양한 디자인 의도를 정확하게 표현하기 위해, 가이드를 넘어 포토샵에 대한 이해가 필요합니다.



자간

포토샵에 자간을 작업하는 방식은 다음과 같습니다.




단위가.. 없네요


퍼블리싱 작업을 할 때 저 알 수 없는 단위를 어떻게 환산해야 할지 고뇌한 적이 많습니다. 솔직하게 말씀드리면 자간이 좁다고 생각되면 -1px로 처리했던 적이 많습니다. (디자이너분들에게 죄송합니다...)


저 단위 없는 자간의 정체는 무엇일까요? 어도비 공식사이트에는 다음과 같이 명세 되어 있는데요.


자간과 커닝은 모두 현재 문자 크기에 상대적인 측정 단위인 1/1000em으로 측정됩니다. 6포인트 글꼴에서 1em은 6포인트에 해당하고, 10포인트 글꼴에서 1em은 10포인트에 해당합니다. 커닝 및 자간은 현재 문자 크기에 정확하게 비례합니다.


쉽게 말씀드리면, 포토샵의 1000이 CSS의 1em(현재 폰트크기)과 일치합니다. (링크)



파이어폭스에서 구현된 자간. 거의 일치합니다.



가장 정확하게 렌더링하는 파이어폭스 기준으로 거의 일치하는데요.이제는 픽셀로 어설프게 맞추지 않아도 되겠네요. 

(*IE9 이하 등 구형브라우저에서는 소수점을 정수화 처리하기 때문에 정확하게 작동하지 않을 수도 있습니다. 링크)



행간

포토샵에서 행간을 넣는 방법은 이렇습니다.




자간과 비교하면 단위가 있어서 다행이네요.

하지만 포토샵과 CSS의 line-height의 방식은 다릅니다.




이처럼 포토샵은 글자의 가장 윗부분을 기준으로,

css의 line-height는 글자의 수직중앙을 기준으로 작동합니다.




결국, 이런 오차가 생길 수밖에 없는데요. 이 오차 때문에 가끔 글씨 위 아래로 애매한 여백이 생깁니다. 이 여백을 계산하는 공식((행간 - 폰트사이즈) / 2)을 사용하면 좀 더 정확하게 퍼블리싱 할 수 있습니다.  



행간과 자간을 디자이너의 의도와 비슷하게 맞추는 방법에 대해 알아봤습니다. 하지만 위와 같은 방법으로 해도, 아래의 예시와 같이 OS와 브라우저의 렌더링 방식에 따라 1~2px정도 오차가 있을 수 있습니다.


크롬에서 구현된 자간. 미세하게 오차가 있습니다.



웹디자인에서 자간과 행간의 문제는 개발자의 실력도 원인이 될 수도 있겠지만, 디자이너들과의 의사소통으로 간단히 해결할 수 있다고 생각합니다. 이런 소통을 통해 모두가 만족할 수 있는 프로젝트를 진행할 수 있었으면 좋겠습니다.




출처: Justin Marsan, 어도비 공식사이트


더 읽기 > 올바른 웹, 모바일 폰트 사용하기


by 원숭이발자국



Posted by slowalk

저는 요즘 사내에서 ‘야매코딩’이라는 스터디를 진행하고 있는데요. css에서 ‘포지션(position)’을 제대로 설명 못 해서 애먹었던 적이 있습니다. 적당히 이해하고 넘어가기에는 아주 중요한 요소인데요. 프룬트 블로그(FROONT BLOG)에서는 포지션의 개념을 gif로 쉽게 설명했습니다. 포지션의 개념이 어려운 분들을 위해 공유합니다.





웹 디자인의 포지션


웹디자인에서 ‘포지션(position)’은 매우 중요합니다. 당연한 얘기지만 포토샵이나 일러스트레이터에서의 캔버스와는 다릅니다. 왜냐면 스크롤이나 스크린 크기 등 여러 가지 요인이 작용하기 때문이죠.


포지션은 크게 ‘스태틱(static)’. ‘앱솔루트(absolute)’, ‘렐러티브(relative)’, ‘픽스드(fixed)’로 나뉩니다. 실제 영어 단어가 의미하는 것과 다르게 작동하기 때문에 헷갈릴 수도 있는데요. 예를 들어 스태틱(고정, 정지상태의)과 앱솔루트(절댓값의)는 실제 뜻과 달리 어디에 배치하느냐에 따라 달라집니다.





Z- 인덱스(Z-index)

포지션 개념을 설명하기 전에 Z- 인덱스가 어떻게 포지션에 영향을 주는지 알 필요가 있습니다. Z-인덱스를 쉽게 설명하자면 요소의 앞뒤를 설정할 수 있는 속성입니다.  포토샵이나 일러스트레이터에서 레이어 같은 개념이라고 할 수 있겠네요.


권고

- 버튼이나 클릭 할 수 있는 요소에 사용하세요.


주의 

- 버튼 위에 있는 텍스트에는 사용하지 마세요. 클릭 못 하는 경우가 생깁니다.

- html 구조를 잘 파악하고 써주세요. 잘 모르고 남용하면 z-index 지옥에 빠질 수가 있습니다.





스태틱(Static position)

포지션의 기본 속성입니다. 스태틱은 뜻(고정, 정지상태의)과 다르게 위에서부터 차곡차곡 쌓이는 속성입니다. 예를 들어 상단 gif에서 ‘WE’ 높이가 줄어든다면 아래 ‘ARE’, ‘STATIC’ 요소도 그만큼 올라가겠죠.


권고

- 콘텐츠가 바뀌어도 디자인을 유지하고 싶다면 최소, 최댓값(Min, Max limits)을 써주세요.

- 개인적으로 스태틱은 반응형에서 앱솔루트나 렐러티브 속성을 풀어줄 경우 씁니다.


주의

- 스태틱의 유연성 때문에 콘텐츠에 따라서는 디자인이 망가질 수도 있습니다.





앱솔루트 (Absolute position)

앱솔루트는 X와 Y 속성(css에서 top, bottom, right, left)에 따라 요소를 움직일 수 있습니다. 어려운 부분은 그것이 앱솔루트, 렐러티브, 혹은 픽스드 속성을 가진 부모 요소를 기준으로 작동한다는 것입니다. 만약 부모 요소가 이런 속성이 없다면 페이지, 즉 body 기준으로 움직입니다. 앱솔루트는 다른 요소의 위치에 영향을 받지 않습니다 . 즉, 플로우(링크 2번 항목 참고)와 별개로 움직이는데요. 일반 스태틱 요소 위에서 작동합니다.


권고

- 본문 레이어 위에 아이콘이나, 로고를 올려야 한다면


주의

- 반응형 웹 디자인에 친화적이진 않습니다. 스태틱으로 풀어줘야 하는 경우가 생깁니다.





렐러티브 (Relative position)

렐러티브도 스태틱처럼 작동하지만, 앱솔루트처럼 X와 Y 속성으로 움직일 수 있습니다. 또한 위의 gif처럼 자식 요소(움짤의 녹색 원)가 앱솔루트 속성을 가지고 있다면, 렐러티브 속성을 가지고 있는 부모 요소가 기준이 됩니다.


권고

- 앱솔루트의 부모 요소로 주로 씁니다.


주의

- 로고나 아이콘이 최상위 레이어에 있어야 한다면, 렐러티브 속성을 가진 요소 안에 넣지 마세요.





픽스드 (Fixed position)

픽스드는 브라우저 창 기준으로 고정 시켜버리는 속성입니다.


권고

- 주로 고정되는 네비게이션, 헤더 영역에 적합합니다.


주의

- 고정된 공간 뒤는 클릭할 수 없습니다.




실무에서는..


실무에서는 포지션을 섞어서 쓰는 경우도 있습니다. 예를 들어 내비게이션이 스태틱 상태였는데 스크롤을 내리면 픽스드 상태로 바뀌는 내비게이션도 자주 만들게 되는데요. 이럴 때는 자바스크립트의 힘을 빌리는 수밖에 없습니다.


포지션은 익숙해지면 쉬운 것 같지만, 작은 실수로도 엄청난 시간을 낭비할 수 있습니다. 모든 일이 그렇지만 css도 기초가 정말 중요합니다. 저도 포스팅하면서 포지션의 개념을 다시 잡을 수 있었는데요. 앞으로도 ‘야매’가 아닌 정석을 알려드릴 수 있었으면 좋겠습니다.




출처: 프룬트 블로그 



by 원숭이발자국


Posted by slowalk





웹 디자인의 역사는 어떻게 발전해왔을까요? 전에 반응형 웹 디자인을 짤방으로 설명했던 산디스 씨(Sandijs Ruluks), 이번에는 웹 디자인의 역사를 짤방으로 간단하게 정리했는데요. 그는 웹 디자이너들이 '디자이너가 개발을 배워야 하는가?' 논하기 전에, 웹 디자인의 역사에 대해 알 필요가 있다고 생각해서 이 글을 썼습니다.


1. 웹 디자인의 암흑기


웹 디자인의 역사


웹 디자인의 초창기는 매우 어두웠습니다. 검은색화면에 단색의 글씨만 존재했지요. 디자인이라고 할 수 있는 것은 특수문자와 탭키를 이용한 것이 전부였습니다.

 


2. 테이블 - 웹 디자인의 시작


웹 디자인의 역사


브라우저가 생기고 이미지를 올릴 수 있으면서웹 디자인이 시작되었습니다. 그리고 테이블을 통해 정보를 구성할 수 있었는데요. 하지만 사람들은 레이아웃을 잡기 위해 테이블을 사용했습니다. 수직 정렬이나 그리드를 맞추기가 편하다는 장점을 가지고 있었는데요. 하지만 이 방식은 테이블 본연의 기능이 아니고, 유동적이지 못했습니다.



3.자바스크립트의 구원

 

웹 디자인의 역사


자바스크립트가 html의 한계를 극복하기 시작했습니다. 예를 들어 팝업창이 필요하거나, 빠르게 코드를 수정하고 싶을 때, 자바스크립트를 사용했습니다. 웹사이트에 동적인 요소가 추가되면서 웹사이트는 한층 다채로워졌습니다. 요즘은 css가 좋아져서 자바스크립트를 대체하고 있지만, 그래도 여전히 강력한 재료입니다.

 



4. 표현력의 황금시대 - 플래시


웹 디자인의 역사


플래시가 보급되면서 웹 디자인의 표현력은 황금시대를 맞이합니다. 디자이너는 모양, 레이아웃, 애니메이션, 인터랙션, 그리고 어떠한 폰트도 사용할 수 있었습니다. 플래시는 사용자 컴퓨터에 최신 버전이 설치되어 있고, 약간의 로딩시간을 기다리면 마법처럼 현란하게 작동했습니다.


하지만 검색에 최적화 되지 않았으며, 높은 CPU 점유율 때문에 아이폰에서 제외됩니다. (그러면서 웹 디자인에서 플래시는 몰락하게 되죠.)

 



5. CSS


웹 디자인의 역사


플래시와 비슷하게 나온 css는 기술적으로 더 좋은 방식으로 접근하는데요. 플래시와 달리 기존 html로 구조를 유지하면서 css로 꾸미는 방법입니다. html을 뼈와 살이라면, css는 옷이라고 할 수 있겠네요.


css의 첫 번째 버전은 유연하지 않았습니다. 가장 큰 문제는 당시 구형 브라우저들이 css를 지원하지 않았는데요. 이 브라우저들이 css를 완전히 지원하기까지 오랜 시간이 걸렸습니다. 어느 정도의 표준이 생기고 css3까지 나오면서, 자바스크립트를 대체할 수 있을 정도로 발전했습니다.


이 글의 필자 산디스 씨는 css가 개발 언어라기보다 서술문에 가깝고, 디자이너들은 반드시 알아야 한다고 강조했습니다. 저처럼 영어가 익숙하지 않은 사람은 서술문이라는 표현은 동의 못하겠지만 디자이너가 반드시 알아야 한다는 사실은 동의할 것입니다.

 



6. 모바일 시대의 도래 : (column)을 이용한 디자인

 


웹 디자인의 역사


모바일로 웹사이트를 브라우징 하는 것은 대단한 도전이었습니다. 속도가 매우 느리고, 기기에 따라 디자인이 전부 달랐습니다. 또한, 잘 못 쓰면 폭탄 요금을 맞을 수 있었기 때문에 인터넷 버튼을 누르는 것조차 두려워했습니다.


하지만 스마트폰이 보급되고, 모바일 인터넷 환경이 좋아지면서 모바일 웹 디자인도 발전하기 시작합니다처음에는 단(column)을 이용하는 디자인으로 모바일에 대응했습니다. 대표적으로 960 그리드 시스템을 12단으로 나눠서 사용했습니다.


그다음으로는 자주 쓰이는 서식, 메뉴, 버튼 등 일반적인 UI를 쉽게 사용할 수 있는 라이브러리가 등장했습니다. 부트스트랩(Bootstrap)과 파운데이션(Foundation)이 대표적인데요. 모바일도 대응할 수 있는 웹 사이트를 빠르고 쉽게 만들 수 있게 되었습니다. 하지만 그만큼 디자인이 비슷한 사이트들이 많아졌으며, 디자이너들이 사용하기에는 코드가 어려웠습니다.

 



7. 반응형 웹 디자인

 

웹 디자인의 역사


디자이너 겸 개발자 에단 마콧 씨(Ethan Marcotte)는 같은 콘텐츠로 화면 넓이에 따라 디자인을 바꿀 수 있는 '반응형 웹 디자인'이라는 용어를 만들고 제안했습니다. 반응형 웹 디자인은 html 수정없이 css 수정으로 모든 크기의 화면에 대응할 수 있습니다. 모바일 웹사이트를 따로 만들 필요도 없어 효율적이며, 어디서나 같은 콘텐츠를 보여줄 수 있습니다.

하지만 반응형 웹 디자인에도 몇 가지 문제가 있는데요. 디자이너들은 반응형 웹 디자인을 위해 여러 가지 화면에 맞는 디자인을 각각 만들어야 합니다. 또한,개발자들은 이미지를 어떻게 사용할지, 데스크톱 혹은 모바일 우선인지 신경 써야 할 것이 많습니다.

 



8.플랫 디자인의 시대


웹 디자인의 역사


수 많은 기기에 맞춰 디자인하는 것은 시간이 오래 걸립니다. 이에 사람들은 정교하지만 오랜 시간이 걸리는 스큐어모픽 디자인을 버리기 시작합니다. 그리고 단순하고 콘텐츠가 돋보이는 플랫디자인을 선호하기 시작하는데요. 형태는 기능을 따른다는 말처럼, 이미 오래전부터 플랫디자인의 시대가 예견되었을지도 모릅니다.




9. 웹 디자인의 미래는?

 

웹 디자인의 역사


우리가 디자인한 이미지파일이 바로 브라우저에서 작동한다면 어떨까요? 거기에 웹 표준과 접근성까지 준수하면서 모든 환경에 대응한다면 어떨까요? 디자이너들은 디자인에 집중하고, 개발자들은 브라우저 호환을 걱정할 필요 없이, 실질적인 개발에 집중할 수 있을 것입니다. 물론 저 같은 웹 퍼블리셔는 일자리를 잃을 수도 있겠지만, 기술의 발전에 뿌듯할 것 같네요. 어쩌면 미래에 기술력보다 더 중요한 것은 좋은 웹사이트를 만들수 있는 기획과 창의력이 아닐까 생각해봅니다.



by 숭이발자국



출처: FroontBlog



 

Posted by slowalk