유료 강의의 내용을 일목요연하게 정리하는 것은 여러모로 문제가 있기 때문에 내가 앞으로 기억해두면 쓸 만한 내용 딱 세 가지만 정리한다. 책상 위에서 며칠째 나뒹굴고 있는 이면지를 처리하기 위한 목적도 있긴 하다.
1. 텍스트
기본적인 바디 텍스트 크기로 16px을 제안한다. 헤드라인(headeline)은 그를 기준으로 3em, 2단계 헤드라인(B-heads)은 1.5em, 내비게이션은 1em, 그리고 필자명 등의 부수정보(byline)은 0.75em을 권장한다. 줄 간격(leading)은 1.2~1.5em라는 기준을 제시했는데 결국 가장 바람직한 답안은 1.5em인 것으로 결론을 내렸다. 한 줄에 들어가는 글자 수는(CPL) 넉넉잡아 50~70, 조금 더 정확하게는 55~65 CPL이 적당하다고 한다. 글자 크기와 텍스트가 들어가는 가로 크기(여기에 모바일 환경에 대한 고려도 물론 포함한다), 폰트의 특성 등을 잘 고려하면 어느 상황에서나 모범적인 예시를 만들어낼 수 있다.
2. 색
솔직히 색은 잘 모르겠지만서도 최소 기본 테마색이 주어졌다는 전제하에 언제든 무난하게 어울릴 수 있는 색 조합을 찾는 것은 그리 어려운 일이 아니었다. HSB 또는 HSV 색 공간에서 단채도(monochromatic) 조합, 유사색(analogous) 조합, 보색(complementary) 조합만 찾더라도, 그것도 일정량의 센스(?)없이 공식에 때려 맞추기만 해도 된다. 단채도는 말 그대로 채도(hue)를 고정하고 나머지 요소를 조금씩 조정한 것, 유사색은 채도를 조금씩 바꾸어 나가는 것, 보색은 단채도 색 두어 개에 그와 채도에서 180도 차이가 나는 색으로 단채도 색 두어 개를 찾으면 된다.
3. 정리
그리드 디자인이며 폰트 매치며 이런 저런 내용이 있었지만 자명하거나 한글에 적용하기 힘든 내용 등을 제외하면 결국 어떤 기준으로 디자인의 완성도를 결정할 수 있느냐가 결론이 아닐까 싶었다. 코드스쿨에서 제안한 한 가지 이야기는 "옹호할 수 없다면 바꿔라.(If you can't defend it, change it.)"는 거였다. 다분히 주관적인 이야기지만 최소한 그게 한 사람에게나마, 또는 하나의 팀, 집단에게나마 유효하게 적용될 수 있다면 그럭저럭 쓸 만한 룰이라는 생각이다.
'CODE' 카테고리의 다른 글
객체지향적으로 생각하라! (0) | 2015.04.28 |
---|---|
팩토리 메소드를 사용할 때 빈 기본 생성자가 필요한 이유 (0) | 2015.04.03 |
동적 컨텐츠의 무한 스크롤 방식을 구현할 때 고려해야 할 점 (0) | 2015.03.17 |
이클립스(Eclipse) 안드로이드 프로젝트를 그레이들(Gradle) 안드로이드 프로젝트로 바꾸는 이야기 (1) | 2015.03.11 |
비동기 방식에서는 절대 플래그(flag)로 문제를 해결하려 들지 말라 (0) | 2015.03.06 |
Rails로 다중 언어 지원 애플리케이션 만들기 (0) | 2015.01.18 |
프로그래밍 숙제에서 발리지 않는 법 (0) | 2014.12.13 |
Ssign.net 서버 개발기 (0) | 2014.11.15 |
COMODO 보안서버 SSL 인증서 설치하기 (0) | 2014.11.03 |
워드프레스를 재설치할 때는 꼭 기존의 데이터베이스를 날려주자 (0) | 2014.10.31 |