Google Technical Writing Course - 2
문서에서 그림을 활용하는 법에 대한 파트로, 목차는 아래와 같다.
캡션(caption)이란 그림 밑에 조그맣게 달리는 설명 문구로, 그 그림에 어떤 설명을 붙일지를 먼저 생각해보라는 뜻.
즉 글의 흐름에 맞춰 어떤 이미지가 들어가야 하는지를 먼저 생각한 후에 맞는 그림을 넣으라는 의미다.
좋은 캡션은 아래와 같은 특성들을 가지고 있다:
짧다.
그림의 핵심 메시지(takeaway)를 잘 설명한다.
독자의 시선을 집중시킨다. 특히 사진이나 다이어그램에 세부 정보가 많을 경우, 어디에 집중해야 하는지 명확히 가이드해준다.
하기 3개 그림의 캡션은 모두 같다.
셋 중 어떤 그림이 캡션 및 의도에 가장 맞는 그림인가?
딱 봤을 때 C가 제일 낫다. "store content"와 "ref to the next node" 모두 표현하고 있기 때문이다.
여기에 모범답안의 설명을 조금 덧붙이자면
A는 예쁘고 시선을 끌지만, 캡션의 내용을 잘못 전달하고 있다. "single-linked"이지만 앞뒤 모두를 가리키는 것처럼 오해할 소지가 있다.
B는 나쁘지는 않다. 첫 번째에서 두 번째로 이어지는 연결 관계를 이해하는데는 도움이 된다. 하지만 "content"에 대한 내용이 빠져 있다.
하나의 그림에 너무 많은 정보를 담지 말 것. 하나의 다이어그램에는 한 문단 이상, 또는 리스트 기준으로 5개 이상의 항목이 나오는 분량의 내용을 담지 말 것.
가령 아래와 같은 그림이 있다고 하자. 이 다이어그램은 실제 시스템을 모두 표현하였지만, 지나치게 복잡하고 시각적으로 혼란스럽다.
이럴 때는 subsystem을 활용한다. 즉, 복잡한 전체 시스템을 subsystem으로 나눠서 굵직한 "big picture"을 먼저 그린다.
이후 각 subsystem의 세분화된 detail을 묘사한다.
Visaul cue, Callout 등을 사용해 독자가 그림에서 어느 부분을 집중해서 봐야 하는지 강조한다.
아래는 visual cue의 예시로, 빨간색 동그라미를 쳐진 부분을 강조한다.
callout이란 주의를 끌기 위한 시각적 요소로, 아래 그림의 화살표가 callout의 한 예시이다.
글의 초고를 여러번 편집하듯, 그림에 대한 검토를 하는 방법에 대한 이야기다.
하기와 같은 항목들을 점검할 수 있다.
어떻게 하면 더 단순화할 수 있는가?
더 단순한 2개 이상의 sub picture로 나눌 수 있는가?
그림 안의 텍스트는 읽기에 용이한가? 텍스트는 배경과 잘 대비되어 눈에 띄는가?
이 그림이 전달하는 핵심 메시지는 무엇인가?
예를 들어 1931년 이전의 런던 지하철 지도는 아래와 같이 도로와 선로의 커브, 축척까지 너무 디테일한 요소들까지 반영되어 시각적으로 복잡했다.
1931년 Harry Beck은 이러한 시각적 단점을 개선하고자 불필요한 요소들은 모두 과감히 없애고, 'A에서 B로 간다'는 지하철 맵의 본래 목적에만 맞도록 지도를 단순화했다. 물론 대성공이었고, 현재 지하철 지도도 이 디자인 방식을 따르고 있다.
하기 재귀적 풀이(recursive solution)을 묘사하는 다이어그램의 문제점 찾기. 즉 complexity 때문에 본래 전달하고자 하는 매시지가 흐려지는데, 정확히 어느 부분에서 그러한지 짚어낼 것.
참고로 의도하는 핵심 메시지는 아래와 같다.
For a recursive solution, call the function itself in the return statement until you reach a base case solution.
내가 생각한 포인트는 하기와 같다:
밑의 예시를 굳이 넣었어야 할까? 개념을 설명하는 첫 번째 블록으로도 충분할 것 같다. 만약 예시가 필요하다면, 개념 블록과 나머지 예시 블록을 구분하는게 나을 것 같다.
예시 블록의 경우 화살표 방향이 잘못되었다. 양방향 화살표가 아니라 4 > 3 > 2 > 1 을 가리키도록 수정되어야 한다.
‘factorial(4) = 4*3*2*1’ 이 부분은 화살표로 이어지는 것이 아니라 별도 텍스트 상자 등으로 삽입되어야 할 것 같다.
그렇다면 모범답안은 어떨까. 아예 예시 블록만 넣었고, 화살표가 수정되기는 했지만 거꾸로 올라가는 곡선형 화살표는 아직 왜 있는지 이해가 되지 않는다.
그런데 수정본에도 아직 문제가 있다고 한다. 그 부분을 모범답안에서는 아래와 같이 설명하고 있다:
다이어그램은 여전히 복잡하다. 한 문단 이상의 내용을 담고 있다. 따라서 불필요한 정보를 줄이거나 라벨을 추가함으로서 의미를 명료하게 할 방법을 생각해보라.
-> 여기서는 라벨을 추가하는 것이 더 나을 듯. 복잡하다는데는 동의하지만, 한 문단 이상의 내용을 담고 있지는 않은 것 같다.
함수간 호출 / 반환 화살표를 구분함으로서 의미가 더욱 명료해졌으나, 반환 화살표에 리턴값을 라벨로 명시하면 독자의 이해를 더 도울 수 있다.
-> 내가 의문을 품은 위 방향 화살표는 ‘반환 화살표(return arrows)라고 한다. 즉 리턴값을 라벨로 함께 표시한다면, 나처럼 ‘이게 뭐지?’하고 헷갈리는 경우를 방지할 수 있을 것이다.
다이어그램을 만들 수 있는 무료 (혹은 무료 옵션 제공) 툴 3가지:
- diagrams.net
- LucidChart
그리고 이미지 추출은 SVG(Scalable Vector Graphics)로 할 것을 제안하는데, 공간 제약 없이 자유롭게 사이즈 조정이 가능해서 이미지 퀄리티가 보장되기 때문이다. 즉, 사이즈 키워도 깨지지 않는다.
출처 : https://developers.google.com/tech-writing/two/illustrations#exercise_2