S9 · REF여정 렌즈 대응

TimelineJS

Knight Lab · timeline.knightlab.com

저널리즘이 다듬어 낸 서사 타임라인 오픈소스의 사실상 표준. 위에는 한 사건을 크게 보여 주는 슬라이드, 아래에는 전체를 조망하는 — 이 이중 표현 하나로 "상세를 읽으면서 맥락을 잃지 않는" 상호작용 관습을 웹에 정착시켰다.

무엇인가

TimelineJS 는 미국 노스웨스턴대학교 Knight Lab이 만든 오픈소스 타임라인 도구다. 뉴욕타임스에서 인터랙티브 저널리즘을 하던 Zach Wise 가 주도해 2012년 무렵 공개했고, 이후 개정판 TimelineJS3 로 이어져 세계 뉴스룸·교육 현장에서 가장 널리 쓰이는 서사 타임라인 도구가 됐다. 코드는 GitHub 에 공개돼 있다(NUKnightLab/TimelineJS3).

제작 방식이 이 도구의 성격을 말해 준다 — 프로그래밍 없이 구글 스프레드시트 템플릿에 행을 채우면(행 하나 = 사건 하나) 임베드 가능한 타임라인이 나온다. 데이터와 표현을 분리한 채, 표현 쪽은 강한 기본값으로 통일한 것이다. 화면 구조는 넷으로 정리된다:

구성물무엇인가비고
슬라이드(slide)사건 하나의 상세 카드 — 제목·본문·미디어 한 장면화면 상부를 통째로 차지, 좌우 화살표로 앞뒤 사건 이동
축(timenav)하단의 스크러블한 시간축 — 모든 사건이 마커로 놓임현재 슬라이드의 위치가 축 위에서 항상 표시됨
시대(era)축 배경에 깔리는 이름 붙은 구간 띠슬라이드를 갖지 않는 배경 층 — 맥락 라벨 전용
그룹(group)축을 가로 밴드 여러 줄로 나누는 분류인물별·주제별 병렬 트랙

철학은 데이터 시각화가 아니라 이야기하기다. Knight Lab 은 좋은 타임라인의 조건으로 "강한 서사가 있는 소재"를 들고, 슬라이드 수를 20장 안팎으로 절제하라고 권한다(문서 표현은 검색으로 확인 권장). 즉 TimelineJS 의 타임라인은 기록 전체가 아니라 편집된 한 편의 이야기이고, 축은 그 이야기의 차례다.

도판

웹 출처에서 직접 불러온 이미지(핫링크). §7 여섯 항목의 도판은 타임라인 도판 자료집에 함께 모아 두었다.

TimelineJS UI 성분 라벨링 도해 클릭 = 출처 페이지
이미지를 불러오지 못했습니다. GitHub 출처로 이동 →
TimelineJS 실사례에 UI 성분을 라벨링한 도해 — 상단 슬라이드의 Media·Date·Headline·Text·Credit·Caption과 하단 축의 Group·마커·Date·Era(색 막대)를 짚어 준다. '슬라이드 + 하단 축' 구조가 축에 어떻게 매핑되는지 대조해 보여줌.
Barnard College DHC (도해)|출처 Barnard DHC tutorials (GitHub) →|저작권 · 참고용

공식 데모의 '슬라이드 + 하단 축' 실동작 화면은 공식 사이트 상단의 라이브 예시에서 바로 볼 수 있다.

우리 모델과의 접점

우리 개념 모델의 1차 렌즈인 여정(언제)과 화면 어휘가 거의 겹친다. 대응은 이렇다:

TimelineJS우리 개념비고
슬라이드사건 시트사건 하나 = 카드 하나. "사건은 인생의 한 문장"(제2장)과 동형
축의 마커milestone(점) · span(구간)모양 셋 중 둘
era시대(index — 얇은 띠)배경 층이라는 위상까지 같다 — 단 우리 시대는 1급 사건이다(아래)
group 밴드프로젝트·주제별 레인병렬 트랙이라는 발상이 같음
슬라이드 순서(앞뒤 이동)책자 — 여정을 원고로 엮기타임라인의 선형 낭독 = 산출(제8장)의 원형

지도 문서가 적은 접점 — 상호작용 관습(슬라이드+축) 참고 — 의 핵심은 이 이중 표현이다. 상세(슬라이드)를 읽는 동안에도 축이 화면에 남아 "지금 삶의 어느 지점을 보고 있는가"를 잃지 않게 한다. 우리 여정 렌즈에서 사건 시트를 열 때의 방향감각 문제에 대한, 10년 넘게 검증된 답 하나다.

대응만큼 어긋남이 유익하다:

  • 발행 도구 vs 기록 도구. TimelineJS 는 저자가 스프레드시트에서 만들고 독자가 완성본을 보는 단방향 전시물이다 — 입력과 열람이 분리돼 있다. 우리는 "마스터 관리 화면은 따로 없다, 렌즈가 곧 관리 화면"(제5장)이므로 타임라인 위에서 바로 편집한다. 같은 화면 문법을 쓰되 데이터의 생애가 반대다.
  • '지금' 선의 부재. TimelineJS 의 축은 완결된 과거를 담는 그릇이라 시제도, 미래도, 겹(시나리오)도 없다. 우리 축은 '지금' 선이 과거와 여러 벌의 미래를 가르는 축(원칙 2·5)이다 — 이것이 우리가 이 관습을 그대로 이식할 수 없는 근본 이유다.
  • 큐레이션 vs 전량 기록. 20장 안팎 권고는 서사 도구의 절제다. 우리 여정은 수백 사건의 전량 기록이므로, 이 관습은 렌즈 자체가 아니라 산출물 쪽에 이식돼야 맞다.
슬라이드+축은 렌즈가 아니라 산출의 문법이다. TimelineJS 가 정착시킨 관습에서 가져올 것은 두 층이다 — 여정 렌즈에는 "상세를 열어도 축이 남는" 방향감각 유지 패턴을, 책자·공개(Publication, 원칙 9) 쪽에는 "큐레이션된 사건들의 선형 낭독"이라는 산출 형식을. 하나의 참고가 렌즈와 산출(다섯 문법의 두 칸)에 각각 다른 교훈을 주는 드문 사례다.

생각할 거리

  1. 사건 시트를 열 때 축은 어디에 있나. TimelineJS 는 상세와 조망을 한 화면에 상시 공존시킨다. 우리 proto 의 사건 시트(바텀시트)는 타임라인을 얼마나 가리는가 — 시트가 올라온 상태에서도 '지금' 선과 이웃 사건이 보이는가. 슬라이드+축의 교훈을 모바일 세로 화면에서 어떻게 번역할지가 설계 질문이다.
  2. "다음 사건"은 무엇인가. TimelineJS 의 좌우 이동은 단일 정렬(시작일)이라 자명하다. 우리는 점·구간·시대가 겹치고 레인이 여럿이다 — 사건 시트에서 앞/뒤 넘기기를 제공한다면 정렬 기준은 시작일인가, 같은 레인 안인가, 같은 시대 안인가. 이 답이 곧 책자에서 문장을 엮는 순서(제8장 산출)의 답이기도 하다.
  3. 시대는 슬라이드를 가질 자격이 있나. TimelineJS 의 era 는 라벨일 뿐 클릭해 들어갈 수 없다. 우리 시대(index)는 1급 사건이므로 제 시트를 가질 수 있다 — 시대 시트에는 무엇이 실려야 하나(기간 요약? 소속 사건 롤업? 성찰?). "저장보다 파생"(원칙 7)에 따라 롤업으로 채운다면 그 목록이 곧 시대의 미니 타임라인이 된다.
  4. TimelineJS 포맷은 수출구가 될 수 있나. 구글 시트 한 장 = 타임라인이라는 그의 데이터 계약은 사실상의 교환 포맷이다. 우리 백업(zip)·책자 외에 "여정 → TimelineJS 호환 시트" 내보내기를 두면, 기록의 소유·이동성(원칙 9)을 외부 생태계로 증명하는 값싼 수단이 된다 — 액션4 책자 포맷 벤치마크에 웹 산출물 후보로 넣을 것.

더 찾아보기

  • 공식 사이트: timeline.knightlab.com — 만드는 법·모범 사례 가이드까지 한 페이지에 있다.
  • 검색: NUKnightLab TimelineJS3 github · TimelineJS json format — 데이터 스키마(slide·era·group)를 직접 볼 수 있다.
  • 같은 장의 이웃: Cartographies of Time(이 화면 관습의 400년 계보), Facebook Timeline(같은 문법을 전시용으로 쓰다 후퇴한 반례), 생애 타임라인 제품군(이 문법을 제품으로 파는 현재 지형).

내 생각

이 메모는 지도 페이지의 같은 항목과 공유되며, 이 기기(브라우저)에 저장됩니다.