본문 바로가기
FrontEnd

[CSS] 타이포그래피 프레임워크 구축

DevInvestor 2022. 10. 12. 02:20
반응형

접근 방식을 요약한 치트 시트

타이포그래피 시스템을 이용한 리팩터링

 

  • 총 50개가 넘는 타이포그래피 스타일을 만나게 될 수 있음.
    • paragraph를 위한 11개의 스타일
    • header를 위한 21가지 스타일
    • 기타 22 종의 바리에이션
  • 또한 간격, 폰트 색상, 배경색의 변형이 타이포그래피와 통합되어 있음
As-Is

타이포그래피 시스템을 통해 50여가지를 6개로 줄일 수 있음.

To-Be

  • 색상을 변형으로 추출
  • 헤더의 수준으로만 Weight 통제

새로운 시스템은 13(base;기준 font-size) / 20 (line-height)으로 구성, 앞으로 13/20 시스템이라 호칭

  • 대부분의 텍스트는 검정
    • 플레이스 홀더일 경우 회색
    • 오류일 경우 빨간색 
    • 링크일 경우 파란색

리팩터링 10단계의 1, 2는 현황 분석임.
시스템을 새로 구축할 경우 3번부터 읽으면 됨

 

Step 1: Audit product for semantic hierarchy

(WAVE Chrome 플러그인 사용)

테스트 계정(모의 데이터로 채워진)의 여러 페이지에 대한 DOM 개요를 검사함

  • 많은 페이지의 최상위 헤더로 h5가 있었고 그 다음으로 많은 것은 h3임
  • 때때로 최상위 헤더가 없고 직접 h3로 시작함
  • 한 페이지에는 테이블 헤더가 h6으로 존재함
  • h1은 거의 사용되지 않았음.
의미론적 계층 구조가 정확하지 않다는 것이 분명함
이상적으로는 h1 다음에 h2다음에 h3가 오는 식으로 레벨을 건너뛰지 않고 연속되어야 함.
 
WAVE 도구는 모의 데이터로 채워진 페이지의 DOM 개요를 노출합함.

Step 2: Inspect visual hierarchy

  • 기존의 모든 서체 크기 및 해당 글꼴 두께를 내림차순으로 기록함
    • 시각적 계층 구조에만 집중할 수 있도록 할당된 의미론적 header의 레벨(h1 등)을 무시
관찰 결과
시각적 계층 점검

Step 3: Determine base font-size for body text

기존에 쓰고 있던 것이었고, 정보 집약적 EHR 시스템에 잘 작동하는 것처럼 보였기 때문에 13px 본문 크기를 사용하기로 결정.
(잘 동작하는 것을 바꿀 필요는 없음)
  • 글꼴 크기는 선택한 글꼴에 따라 다를 수 있으나, 일반적으로 10pt는 접근성을 위한 최소값이다.
  • 10pt는 대략 13px로 변환된다.
(Font size can vary based on the font chosen, but 10 point is usually a minimum)
  • 13px을 기준 사이즈로 결정

4단계: 본문 글꼴 크기에 적합한 줄 높이 결정(골디락스 접근 방식)

Determine line-height that works for body font-size (Goldilocks approach)

많은 시각적 탐색이 필요함
기준 font-size: 13px 및 line-height: 16px(앞으로 "font-size / line-height" 형식으로 표시)으로 시작함
인기 있는 8pt 기준선 그리드를 사용기 떄문에 줄 높이 16px는 가능한 옵션 중 하나임
line-height 값과 8pt 기준선 그리드는 가정이며 탐색을 통해 그것이 실제로 효과적인지 확인할 수 음
 
(시각적으로) 16px line-height가 너무 타이트해 보였음
그래서 다음 8px 척도를 선택하고 라인 높이 24px로 테스트하였음
그러자 이번엔 너무 멀리 떨어져 보였음
font-size / line-height = 13 / 16
Explorations (with mock data) using 13/16 and 13/24 (font-size / line-height format)
너무 먼 것과 너무 가까운 것 사이 즉, 16과 24 사이의 값을 찾기로 함.
짝수 값(18, 20, 22)만 보기로 함.
이러한 값만 여러 숫자로 나눌 수 있기 때문에 공간(spacing) 간격(interval)으로 사용할 수 있음.
 
18을 선택한다는 것은 6pt 베이스라인 그리드를 채택한다는 의미임. (인수와 배수)
(18은 6으로 나눌 수 있고 좋은 수직적 리듬을 유지하기 위해 모든 간격은 line-height에 비례해야 함).
 
  • 18px line-height 두 줄의 간격이 좀 좁아보임
  • 20px이 좋아보임

20은 4의 배수임. 이는 4pt 기준선 그리드를 채택했음을 의미함.

시각적으로 식별 가능한 간격을 제공하기 때문에, 가능하면 8의 배수를 주로 사용하는 것이 좋음
4pt 기준선 격자를 사용하면 더 많은 선택지가 있으나, 대부분 8pt 기준선 격자에서도 허용되는 값을 채택함

22는 많은 숫자로 나눌 수 없기에 별로암. (2와 11만 나눌 수 있음)
이런 식으로 13px의 기본 본문 텍스트와 함께 동작하는 20px의 줄 높이를 파생함. (13 /20)

13/18 및 13/20(font-size / line-height)을 사용한 탐색 결과(가짜 데이터 포함)

이 13/20 값은 WCAG 적합 기준 1.4.8(WCAG Success Criterion 1.4.8)에 명시된 요점 중 하나와도 완벽하게 일치함.
Line spacing (leading) is at least space-and-a-half within paragraphs
줄 사이의 간격이 최소 글꼴 크기의 1.5 배여야 합니다.
13/20은 1.538의 좋은 line-height 비율을 제공함

 

body / base line-height = minimum 1.5 x body / base font-size
(주 : 13 * 1.538 은 대략 20; 1.5배에 가까우면 좋음)
 

결과 : 기본 시스템 13/20 채택, 4pt 그리드 기준선 사용 - 할 수 있는대로 8의 배수 간격 사용

Step 5: Pick a ratio for the modular scale such that you have enough number of harmonious usable values

조화 수열을 이루는 글꼴 크기 값을 도출하기 위해 Tim Brown의 Modular 스케일을 사용함.(Tim Brown’s Modular scale)
가장 중요한 작업은 시스템에 적합한 비율을 찾는 것.
위 링크 블로그의 팁을 사용하여 모든 글꼴 크기에 대해 좋은 수직적 리듬을 보장할 수 있는 중요한 숫자를 생각해보자.
line-height (20px)가 좋은 출발점이라고 생각함.
이 경우 라인 높이 비율(Line-height ratio)은 20/13 = 1.538임.
효과가 있는지 확인하였으나, 스케일이 너무 넓게 느껴짐.
정보가 조밀한 레이아웃의 헤더에 대해 112px, 73px, 48px 등의 큰 서체를 사용할 수는 없음.
Modular scale at 1.538 ratio
훨씬 더 엄격하지만 여전히 20px가 있는 비율이 필요함
이것은 내 body의 줄 높이와 수직 리듬을 보장합니다.
저는 메이저 3th 비율(1.25)을 선택했고 현실적인 값을 도출할 수 있었음
가능한 경우  font-size 값을 4의 배수로 반올림함. 4pt 기준선 그리드로 더 예측 가능하기 때문.
이를 통해 내 서체 스케일로 사용할 수 있는 다음과 같은 조화로운 글꼴 크기를 파생함
 
결과 : 글꼴 크기 조합 파생 40, 32, 24, 20, 16, 13, 11, 8(px)
Modular scale at Major Third ratio (1.25)

Step 6: Start with defining h1

접근성 준수를 보장하려면 항상 h1으로 시작해야 함. h1을 건너뛰면 안됨.
이는 WCAG의 G.141 기술의 지침에 대한 해석임.(WCAG’s G.141 technique.)

다시 여러 화면에 걸친 시각적 검사의 단계가 필요함

여러 페이지에서 h1이 의미하는 바를 통합하기로 함.
우리 페이지 중 일부에서는 h1이어야 하는 헤더가 16px regular(span으로 코딩됨)였고,
다른 페이지에서는 32px light(h5로 코딩됨)였음
모든 페이지에서 일관되게 h1으로 사용할 수 있는 단일 값을 살펴봄
 
이전 단계에서 파생된 타이포그래피 스케일 중 기준 폰트 크기보다  큰 값(40px, 32px, 24px, 20px, 16px)으로 실험을 시작함
(주 : 기준 폰트 크기 13px)
h1의 40px는 환자 이름을 위해선 너무 커보임.
32px도 환자 이름에 비해 너무 커 보였음.
내가 시도한 다음 값은 24px regular였고, 두 시나리오 모두에서 잘 작동하였음

 

h1이 제품 전체에서 동일하게 보이는지 확인\

 

결과 : h1 폰트 사이즈를 24px로 결정

Step 7: Determine how many header levels you need and values for each

이전에 h1을 결정함.
제품의 다양한 레이아웃을 검사하여 필요한 헤더 수를 결정
나는 우리 EHR 시스템의 어떤 레이아웃도 6개 이상의 헤더를 필요로 하지 않는다는 것을 알게됨.
만약 헤더 수가 모자란 경우 다른 타이포그래피 비율(현재는 1.25 사용)을 채택하는 것을 추천.
해당 시스템에서는 5개의 헤더 수준이면 충분함.
 
h5는 label 또는 양식 값 범례 또는 테이블 캡션 또는 테이블 열 헤더와 동일한 수준임.
일반적으로 input 필드 / 라디오 버튼 세트 / 체크박스 세트와 양식 UI 컴포넌트와,
리스트 아이템 또는 테이블은 계층 구조의 끝에 있음(나는 "리프 노드"라고 함).
실제 콘텐츠를 포함하기 때문임.
 
이러한 모든 리프 노드는 정보 계층의 끝임을 사용자에게 매우 명확하게 하는 레이블과 같은 헤더를 사용할 수 있음.
Defining all other header values using the Modular scale

결과 : h1~h5(범례, 레이블, 캡션)의 폰트 사이즈 도출

Step 8: Define line-heights for all font-sizes

좋은 세로(vertical) 리듬을 만들기 위해서는 모든 글꼴 크기의 줄 높이가 서로 비례해야 함.
이를 수행하는 한 가지 방법은 다른 모든 줄 높이를 유도하기 위해 동일한 base font-size / base line-height 비율을 사용하여
계산된 값을 line-height로 사용하는 것암(아래 2단계 참조).
 
파생된 값은 base 그리드 기준선의(4pt) 배수로 판명되지 않을 수 있음
이는 목업에서 작업하는 동안 줄 높이 값을 기억하고 처리하기 어렵게 만들 수 있음.
 
줄 높이를 찾는 두 번째 방법은 파생된 line-height를 기준선 그리드의 가장 가까운 배수로 반올림하는 것임.
2개의 가능한 라인 높이 값 중에 옵션 중 1개를 배제하기 위해 시각적 탐색이 필요함.
같은 타이포그래피 비율을 모든 폰트에 그대로 사용하길 시고함
4의 배수가 아닌 경우 테스트 필요
적절한 4의 배수로 반올림한값을 시각적 탐색 후 결정

결과 : h1~h5(범례, 레이블, 캡션)의 폰트 사이즈 / 줄 높이 도출

Step 9: Determining font-weight for headers

글꼴 두께를 사용하여 계층 구조를 명확하게 할 수 있음
각 헤더에 어떤 글꼴 두께가 효과적인지 확인하기 위해 시각적으로 탐색하고 획 두께를 비교해봄.

 

예제 1의 16px regular(h3의 경우)는 획 두께가 13px regular와 유사해 보이기에

헤더로 식별하기 어려워보임.

h3과 h4가 별 차이 없어보임
 
 
h3에 16px semibold를 사용해보니 훨씬 보기 좋고 읽기 쉬움
h3에 16px  semibold 를 사용해보니  훨씬 보기 좋고 읽기 쉬움
24px light의 h1은 너무 눈에 띄지 않음

 

24px light의 h1은 너무 눈에 띄지 않음
24px semibold로 된 h1은 너무 튀어보임

 

24px semibold로 된 h1은 너무 튀어보임
h1을 24px regular로 설정하면 20px Regular 및 16px semibold와 동일한 획 두께를 갖게 되면서,
나머지 계층 구조와 매끄러워 보임
h1을 24px regular로

결과 : h3에 16px semibold, h1에 24px regular

Step 10: Think about DOM outline (top-down approach) to apply entire type system to any page

DOM 개요는 스크린 리더가 콘텐츠 사이를 이동하는 데 중요함.
종종 보조 네비게이션 시스템이 있는 경우, 네비게이션의 탭은 볼 수 있는 사람들의 헤더 역할을 함.
시각적으로는 탭의 내용에 대해 별도의 헤더가 필요하지 않아 보임.
하지만 스크린 리더는 네비게이션 탭을 헤더로 취급하지 않으므로 DOM에서 헤더를 명시적으로 지정하는 것이 합리적임.
사용자 중 누구도 스크린 리더를 사용하지 않는다고 확신하더라도, 가능한 한 의미 있는 DOM 개요를 작성하는 것이 좋음.
DOM 개요를 작성함으로써 일관된 하향식 방식으로 헤더 수준을 실제로 적용하고 있는지 확인할 수 있기 때문임.
이렇게 하면 헤더 수준을 건너뛸 가능성이 거의 없으며 모든 페이지에서 유사한 DOM 개요 프로세스를 따를 수 있음
전체 제품에 걸쳐 시각적 일관성을 가져오는 데 도움이 됨.
아래 예에서는 Summary, Profile, Encounter(2017년 6월 6일)에 대해 h2를 숨긴 후에도,
h2가 DOM에 여전히 존재하는지 확인함.
h2는 숨겨져 있으므로(큰 여백으로 뷰포트 밖으로 밀어내는 것과 같은 CSS 기술을 사용)
UI에 표시되지 않지만, DOM 계층에는 존재함

결론

타이포그래피 시스템을 통해
  • 타이포그래피 시스템의 중복 제거 및 일관성 향상
  • 사용 규칙에 대한 모호함이나 혼란 감소
  • 디자인 - 개발팀 간 의사소통 향상
  • UI 개발자와 QA 엔지니어의 효율성 향상
    • 설계 및 개발 팀 전체에서 많은 시간이 절약되기 때문에 다른 추가 프로젝트를 자유롭게 수행할 수 있음

다음엔 무엇을 할까요?

font-size와 lign-spacing은 퍼즐의 한 조각일 뿐임.
간격(spacing) 시스템을 설계하는 방법을 읽어보길 바람.(how to design a Spacing system)

Useful articles / video for reference:

반응형

'FrontEnd' 카테고리의 다른 글

빠른 디자이너-개발자 의사소통을 위한 색상(color) 시스템 프레임워크  (0) 2022.10.13
[CSS] Spacing(간격) 프레임워크 구축  (0) 2022.10.13
UI 치트 시트 : 간격의 우정(UI cheat sheet: Spacing friendships)  (0) 2022.10.11
RxJS로 HTTP 리턴 데이터 매핑하기  (0) 2022.10.08
RxJS를 이용하여 오류 처리하기  (0) 2022.10.08

'FrontEnd' Related Articles

티스토리툴바