BBC 인터랙티브 콘텐츠가 AMP, 앱, 웹에서 작동하는 방식

BBC의 Visual Journalism 팀에서 우리는 계산기에서 시각화에 이르기까지 새로운 스토리텔링 형식에 이르기까지 흥미진진하고 흥미진진하며 대화형 콘텐츠를 제작합니다.

각 응용 프로그램은 자체적으로 생성하는 고유한 과제이지만 대부분의 프로젝트를 다양한 언어로 배포해야 한다는 점을 고려할 때 더욱 그렇습니다. 우리 콘텐츠는 BBC 뉴스 및 스포츠 웹사이트뿐만 아니라 iOS 및 Android의 해당 앱과 BBC 콘텐츠를 사용하는 제3자 사이트에서도 작동해야 합니다.

이제 AMP, Facebook Instant Articles 및 Apple News와 같은 새로운 플랫폼이 증가하고 있음 을 고려하십시오. 각 플랫폼에는 고유한 제한 사항과 독점 게시 메커니즘이 있습니다. 이러한 모든 환경에서 작동하는 대화형 콘텐츠를 만드는 것은 정말 어려운 일입니다. 나는 우리가 BBC에서 이 문제에 어떻게 접근했는지 설명할 것입니다.

예: Canonical 대 AMP

이것은 실제로 작동하기 전까지는 모두 약간 이론적인 것이므로 예제를 직접 살펴보겠습니다.

다음은 Visual Journalism 콘텐츠가 포함된 BBC 기사입니다.

이것은 기사의 표준 버전, 즉 홈페이지에서 기사로 이동하면 얻을 수 있는 기본 버전입니다.

이제 기사의 AMP 버전을 살펴보겠습니다.

표준 버전과 AMP 버전은 같아 보이지만 실제로는 동작이 다른 두 개의 서로 다른 엔드포인트 입니다.

• 정식 버전은 양식을 제출할 때 선택한 국가로 스크롤합니다.
• AMP iframe 내에서 상위 페이지를 스크롤할 수 없으므로 AMP 버전은 스크롤하지 않습니다.
• AMP 버전은 표시 영역 크기와 스크롤 위치에 따라 '더 보기' 버튼이 있는 잘린 iframe을 표시합니다. 이것은 AMP의 기능입니다.

이 기사의 표준 및 AMP 버전과 함께 이 프로젝트는 자체적인 복잡성과 한계가 있는 또 다른 플랫폼인 News App에도 제공되었습니다. 그렇다면 이러한 모든 플랫폼을 어떻게 지원합니까?

툴링이 핵심

우리는 콘텐츠를 처음부터 구축하지 않습니다. 노드를 사용하여 단일 명령으로 상용구 프로젝트를 생성하는 Yeoman 기반 스캐폴드가 있습니다.

새 프로젝트에는 Webpack, SASS, 배포 및 구성 요소화 구조가 기본 제공됩니다. 국제화는 또한 Handlebars 템플릿 시스템을 사용하여 우리 프로젝트에 적용됩니다. Tom Maslen은 반응형 웹 디자인을 다국어로 만들기 위한 13가지 팁이라는 자신의 게시물에서 이에 대해 자세히 설명합니다.

기본적으로 이것은 하나의 플랫폼용으로 컴파일하는 데 꽤 잘 작동하지만 여러 플랫폼을 지원해야 합니다 . 몇 가지 코드를 살펴보겠습니다.

포함 대 독립 실행형

Visual Journalism에서 우리는 콘텐츠를 iframe 내부에 출력하여 글로벌 스크립팅 및 스타일에 영향을 받지 않고 기사에 독립적으로 "포함"될 수 있습니다. 이에 대한 예는 이 기사 앞부분의 표준 예에 포함된 Donald Trump 대화형입니다.

반면에 때로는 콘텐츠를 원시 HTML로 출력합니다. 전체 페이지를 제어할 수 있거나 정말 반응이 빠른 스크롤 상호 작용이 필요한 경우에만 이 작업을 수행합니다. 이것을 각각 "embed" 및 "standalone" 출력이라고 부르겠습니다.

"로봇이 당신의 직업을 차지할까요?"를 어떻게 만들 수 있을지 상상해 봅시다. "embed" 및 "standalone" 형식 모두에서 대화형입니다.

두 버전의 콘텐츠는 대부분의 코드를 공유하지만 두 버전 간에 JavaScript 구현에 몇 가지 중요한 차이점이 있습니다.

예를 들어 '내 자동화 위험 찾기' 버튼을 살펴보세요. 사용자가 제출 버튼을 누르면 자동으로 결과로 스크롤됩니다.

코드의 "독립 실행형" 버전은 다음과 같습니다.

 button.on('click', (e) => { window.scrollTo(0, resultsContainer.offsetTop); });

그러나 이것을 "임베딩" 출력으로 구축하는 경우 콘텐츠가 iframe 내부에 있다는 것을 알고 있으므로 다르게 코딩해야 합니다.

 // inside the iframe button.on('click', () => { window.parent.postMessage({ name: 'scroll', offset: resultsContainer.offsetTop }, '*'); }); // inside the host page window.addEventListener('message', (event) => { if (event.data.name === 'scroll') { window.scrollTo(0, iframe.offsetTop + event.data.offset); } });

또한 애플리케이션이 전체 화면으로 전환되어야 하는 경우에는 어떻게 해야 합니까? "독립 실행형" 페이지에 있는 경우 이 작업은 충분히 쉽습니다.

 document.body.className += ' fullscreen';

 .fullscreen { position: fixed; top: 0; left: 0; right: 0; bottom: 0; } 

"embed" 내부에서 이 작업을 시도하면 동일한 코드에서 뷰포트가 아닌 iframe 의 너비와 높이로 크기가 조정되는 콘텐츠를 갖게 됩니다.

...따라서 iframe 내부에 전체 화면 스타일을 적용하는 것 외에도 호스트 페이지에 메시지를 보내 iframe 자체에 스타일을 적용해야 합니다.

 // iframe window.parent.postMessage({ name: 'window:toggleFullScreen' }, '*'); // host page window.addEventListener('message', function () { if (event.data.name === 'window:toggleFullScreen') { document.getElementById(iframeUid).className += ' fullscreen'; } });

이것은 여러 플랫폼을 지원하기 시작할 때 많은 스파게티 코드로 변환될 수 있습니다.

 button.on('click', (e) => { if (inStandalonePage()) { window.scrollTo(0, resultsContainer.offsetTop); } else { window.parent.postMessage({ name: 'scroll', offset: resultsContainer.offsetTop }, '*'); } });

프로젝트의 모든 의미 있는 DOM 상호 작용에 대해 이와 동등한 작업을 수행한다고 상상해 보십시오. 떨림이 끝나면 편안한 차를 마시고 계속 읽으십시오.

추상화가 핵심

개발자가 코드 내에서 이러한 조건을 처리하도록 하는 대신 콘텐츠와 환경 사이에 추상화 계층을 구축했습니다. 우리는 이 레이어를 '래퍼'라고 부릅니다.

DOM 또는 기본 브라우저 이벤트를 직접 쿼리하는 대신 이제 wrapper 모듈을 통해 요청을 프록시할 수 있습니다.

 import wrapper from 'wrapper'; button.on('click', () => { wrapper.scrollTo(resultsContainer.offsetTop); });

각 플랫폼에는 래퍼 메서드의 공통 인터페이스를 준수하는 자체 래퍼 구현이 있습니다. 래퍼는 콘텐츠를 둘러싸고 복잡성을 처리합니다.

scrollTo 함수의 독립 실행형 래퍼 구현은 매우 간단하며 후드 아래에 있는 window.scrollTo 에 인수를 직접 전달합니다.

이제 iframe에 대해 동일한 기능을 구현하는 별도의 래퍼를 살펴보겠습니다.

"embed" 래퍼는 "standalone" 예제와 동일한 인수를 사용하지만 iframe 오프셋이 고려되도록 값을 조작합니다. 이 추가 사항이 없었다면 사용자가 의도하지 않은 곳으로 스크롤했을 것입니다.

래퍼 패턴

래퍼를 사용하면 프로젝트 간에 더 깨끗하고 읽기 쉽고 일관성 있는 코드가 생성됩니다. 또한 메서드의 성능과 액세스 가능성을 높이기 위해 래퍼를 점진적으로 개선하므로 시간이 지남에 따라 미세 최적화가 가능합니다. 따라서 귀하의 프로젝트는 많은 개발자의 경험을 활용할 수 있습니다.

그렇다면 래퍼는 어떻게 생겼습니까?

래퍼 구조

각 래퍼는 기본적으로 핸들바 템플릿, 래퍼 JS 파일 및 래퍼별 스타일을 나타내는 SASS 파일의 세 가지 요소로 구성됩니다. 또한 각 래퍼가 자체 사전 컴파일 및 정리를 담당하도록 기본 스캐폴딩에 의해 노출된 이벤트에 연결하는 빌드 작업이 있습니다.

다음은 포함 래퍼의 단순화된 보기입니다.

 embed-wrapper/ templates/ wrapper.hbs js/ wrapper.js scss/ wrapper.scss

기본 스캐폴딩은 기본 프로젝트 템플릿을 래퍼가 사용하는 부분 핸들로 노출합니다. 예를 들어, templates/wrapper.hbs 에는 다음이 포함될 수 있습니다.

 <div class="bbc-news-vj-wrapper--embed"> {{>your-application}} </div>

scss/wrapper.scss 에는 애플리케이션 코드가 자체적으로 정의할 필요가 없는 래퍼별 스타일 지정이 포함되어 있습니다. 예를 들어 포함 래퍼는 iframe 내부에 많은 BBC 뉴스 스타일을 복제합니다.

마지막으로 js/wrapper.js 에는 아래에 자세히 설명된 래퍼 API의 iframe 구현이 포함되어 있습니다. 애플리케이션 코드와 함께 컴파일되지 않고 프로젝트에 별도로 배송됩니다. Webpack 빌드 프로세스에서 wrapper 를 전역으로 플래그 지정합니다. 즉, 애플리케이션을 여러 플랫폼에 제공하지만 코드는 한 번만 컴파일합니다.

래퍼 API

래퍼 API는 여러 주요 브라우저 상호 작용을 추상화합니다. 가장 중요한 것은 다음과 같습니다.

scrollTo(int)

활성 창에서 지정된 위치로 스크롤합니다. 래퍼는 스크롤을 트리거하기 전에 제공된 정수를 정규화 하여 호스트 페이지가 올바른 위치로 스크롤되도록 합니다.

getScrollPosition: int

사용자의 현재(정규화된) 스크롤 위치를 반환합니다. iframe의 경우 이는 iframe이 뷰포트의 맨 위에 있을 때까지 애플리케이션에 전달된 스크롤 위치가 실제로 음수 임을 의미합니다. 이것은 매우 유용하며 구성 요소가 표시될 때만 애니메이션을 적용하는 등의 작업을 수행할 수 있습니다.

onScroll(callback)

스크롤 이벤트에 대한 후크를 제공합니다. 독립형 래퍼에서 이것은 기본적으로 기본 스크롤 이벤트에 연결됩니다. Embed 래퍼에서는 스크롤 이벤트가 postMessage를 통해 전달되기 때문에 수신이 약간 지연됩니다.

viewport: {height: int, width: int}

뷰포트 높이와 너비를 검색하는 방법(iframe 내에서 쿼리할 때 매우 다르게 구현되기 때문에).

toggleFullScreen

독립 실행형 모드에서는 BBC 메뉴와 바닥글을 보이지 않게 숨기고 position: fixed 를 설정합니다. 뉴스 앱에서 우리는 아무것도 하지 않습니다. 콘텐츠는 이미 전체 화면입니다. 복잡한 것은 postMessage를 통해 조정된 iframe 내부와 외부 모두에 스타일을 적용하는 iframe입니다.

markPageAsLoaded

콘텐츠가 로드되었음을 래퍼에게 알립니다. 이는 뉴스 앱에서 콘텐츠가 작동하는 데 매우 중요합니다. 뉴스 앱은 콘텐츠가 준비되었다고 앱에 명시적으로 알릴 때까지 사용자에게 콘텐츠를 표시하려고 시도하지 않습니다. 또한 웹 버전 콘텐츠에서 로딩 스피너를 제거합니다.

래퍼 목록

앞으로 Facebook Instant Articles 및 Apple News와 같은 대규모 플랫폼을 위한 추가 래퍼를 만들 계획입니다. 지금까지 6개의 래퍼를 만들었습니다.

독립형 래퍼

독립형 페이지에 포함되어야 하는 콘텐츠 버전입니다. BBC 브랜드와 함께 번들로 제공됩니다.

래퍼 포함

콘텐츠의 iframe 버전은 콘텐츠에 대한 통제권을 유지하므로 기사 안에 들어가거나 BBC가 아닌 사이트에 신디케이트하는 것이 안전합니다.

AMP 래퍼

이것은 AMP 페이지에 amp-iframe 으로 가져오는 엔드포인트입니다.

뉴스 앱 래퍼

우리 콘텐츠는 독점적인 bbcvisualjournalism:// 프로토콜을 호출해야 합니다.

코어 래퍼

HTML만 포함하고 프로젝트의 CSS나 JavaScript는 포함하지 않습니다.

JSON 래퍼

BBC 제품에서 공유하기 위한 콘텐츠의 JSON 표현입니다.

플랫폼까지 래퍼 배선

BBC 사이트에 콘텐츠를 표시하기 위해 저널리스트에게 네임스페이스 경로를 제공합니다.

 /include/[department]/[unique ID], eg /include/visual-journalism/123-quiz

저널리스트는 이 "포함 경로"를 CMS에 저장하여 기사 구조를 데이터베이스에 저장합니다. 모든 제품과 서비스는 이 게시 메커니즘의 다운스트림에 있습니다. 각 플랫폼은 원하는 콘텐츠의 종류를 선택하고 프록시 서버에서 해당 콘텐츠를 요청할 책임이 있습니다.

도널드 트럼프의 대화식을 이전부터 살펴보겠습니다. 여기서 CMS의 포함 경로는 다음과 같습니다.

 /include/newsspec/15996-trump-tracker/english/index

표준 기사 페이지는 콘텐츠의 "embed" 버전을 원한다는 것을 알고 있으므로 포함 경로에 /embed 를 추가합니다.

 /include/newsspec/15996-trump-tracker/english/index /embed

… 프록시 서버에서 요청하기 전에:

 https://news.files.bbci.co.uk/include/newsspec/15996-trump-tracker/english/index/embed

반면 AMP 페이지는 포함 경로를 보고 /amp 를 추가합니다.

 /include/newsspec/15996-trump-tracker/english/index /amp

AMP 렌더러는 /amp 버전을 iframe으로 가져와 콘텐츠를 참조하는 일부 AMP HTML을 렌더링하는 약간의 마법을 수행합니다.

 <amp-iframe src="https://news.files.bbci.co.uk/include/newsspec/15996-trump-tracker/english/index/amp" width="640" height="360"> <!-- some other AMP elements here --> </amp-iframe>

지원되는 모든 플랫폼에는 고유한 버전의 콘텐츠가 있습니다.

 /include/newsspec/15996-trump-tracker/english/index /amp

/include/newsspec/15996-trump-tracker/english/index /core

/include/newsspec/15996-trump-tracker/english/index /envelope

...등등

이 솔루션은 발생하는 더 많은 플랫폼 유형을 통합하도록 확장할 수 있습니다.

추상화는 어렵다

"한 번 작성하고 어디에나 배포할 수 있는" 아키텍처를 구축하는 것은 매우 이상적으로 들리지만 실제로 그렇습니다. 래퍼 아키텍처가 작동하려면 추상화 내에서 작업하는 데 매우 엄격해야 합니다. 이것은 우리가 "[여기에 플랫폼 이름 삽입]에서 작동하게 하기 위해 이 해키한 일을 하라"는 유혹과 싸워야 한다는 것을 의미합니다. 우리는 콘텐츠가 배송되는 환경을 완전히 인식하지 않기를 원하지만 이는 말처럼 쉽지 않습니다.

플랫폼의 기능은 추상적으로 구성하기 어렵습니다.

추상화 접근 이전에는 iframe의 마크업을 포함하여 출력의 모든 측면을 완벽하게 제어할 수 있었습니다. 접근성을 위해 iframe에 title 속성을 추가하는 것과 같이 프로젝트별로 조정해야 하는 사항이 있는 경우 마크업을 편집하면 됩니다.

이제 래퍼 마크업이 프로젝트와 별개로 존재하므로 이를 구성하는 유일한 방법은 스캐폴드 자체에 후크를 노출하는 것입니다. 플랫폼 간 기능에 대해 이 작업을 비교적 쉽게 수행할 수 있지만 특정 플랫폼에 대한 후크를 노출하면 추상화가 깨집니다. 하나의 래퍼에서만 사용되는 'iframe 제목' 구성 옵션을 노출하고 싶지는 않습니다.

속성의 이름을 더 일반적으로 지정할 수 있습니다(예: title ). 그런 다음 이 값을 iframe title 속성으로 사용할 수 있습니다. 그러나 어디에서 무엇이 사용되었는지 추적하기 어려워지기 시작했고 더 이상 이해할 수 없을 정도로 구성을 추상화할 위험이 있습니다. 전반적으로 우리는 설정을 최대한 간결하게 유지하려고 노력하며 전역적으로 사용되는 속성만 설정합니다.

구성 요소 동작이 복잡할 수 있음

웹에서 sharetools 모듈은 개별적으로 클릭할 수 있는 소셜 네트워크 공유 버튼을 표시하고 새 창에서 미리 채워진 공유 메시지를 엽니다.

뉴스 앱에서는 모바일 웹을 통해 공유하고 싶지 않습니다. 사용자가 관련 응용 프로그램(예: Twitter)을 설치한 경우 앱 자체에서 공유하고자 합니다. 이상적으로는 사용자에게 기본 iOS/Android 공유 메뉴를 제공한 다음 미리 채워진 공유 메시지로 앱을 열기 전에 사용자가 공유 옵션을 선택하게 하는 것이 좋습니다. 독점 bbcvisualjournalism:// 프로토콜을 호출하여 앱에서 기본 공유 메뉴를 트리거할 수 있습니다.

그러나 이 화면은 '결과 공유' 섹션에서 '트위터'를 탭하든 '페이스북'을 탭하든 상관없이 실행되므로 사용자는 결국 두 번 선택해야 합니다. 콘텐츠 내부에서 처음으로, 네이티브 팝업에서 두 ​​번째로.

이것은 이상한 사용자 여정이므로 뉴스 앱에서 개별 공유 아이콘을 제거하고 대신 일반 공유 버튼을 표시하려고 합니다. 구성 요소를 렌더링하기 전에 사용 중인 래퍼를 명시적으로 확인하여 이를 수행할 수 있습니다.

래퍼 추상화 계층을 구축하면 프로젝트 전체에서 잘 작동하지만 래퍼 선택이 구성 요소 수준의 변경 사항에 영향을 미치는 경우 깨끗한 추상화를 유지하기가 매우 어렵습니다. 이 경우 우리는 약간의 추상화를 잃어버렸고 코드에 지저분한 분기 논리가 있습니다. 고맙게도 이러한 경우는 거의 없습니다.

누락된 기능은 어떻게 처리합니까?

추상화를 유지하는 것은 모두 훌륭하고 좋습니다. 우리의 코드는 래퍼에게 플랫폼이 무엇을 하기를 원하는지 알려줍니다(예: "전체 화면으로 이동"). 하지만 우리가 배송할 플랫폼이 실제로 전체 화면으로 전환할 수 없다면 어떻게 될까요?

래퍼는 완전히 깨지지 않도록 최선을 다할 것이지만 궁극적으로 방법의 성공 여부에 관계없이 작업 솔루션으로 우아하게 폴백하는 디자인이 필요합니다. 우리는 방어적으로 디자인해야 합니다.

일부 막대 차트가 포함된 결과 섹션이 있다고 가정해 보겠습니다. 우리는 종종 차트가 보기로 스크롤될 때까지 막대 차트 값을 0으로 유지하는 것을 좋아합니다.

그러나 AMP 래퍼의 경우처럼 스크롤 위치에 연결하는 메커니즘이 없으면 막대가 영원히 0으로 유지되며 이는 완전히 오해의 소지가 있는 경험입니다.

우리는 점점 더 우리의 디자인에 점진적인 향상 접근 방식을 채택하려고 노력하고 있습니다. 예를 들어 기본적으로 모든 플랫폼에 표시되지만 래퍼가 스크롤을 지원하는 경우 숨겨지는 버튼을 제공할 수 있습니다. 그렇게 하면 스크롤이 애니메이션을 트리거하는 데 실패하더라도 사용자는 여전히 애니메이션을 수동으로 트리거할 수 있습니다.

미래를 위한 계획

Apple News 및 Facebook Instant Articles와 같은 플랫폼을 위한 새로운 래퍼를 개발하고 모든 새로운 플랫폼에 즉시 사용 가능한 '핵심' 콘텐츠 버전을 제공하기를 바랍니다.

우리는 또한 점진적인 향상이 더 잘되기를 바랍니다. 이 분야에서 성공한다는 것은 방어적으로 발전하는 것을 의미합니다. 현재와 ​​미래의 모든 플랫폼이 주어진 상호 작용을 지원할 것이라고 가정할 수는 없지만 잘 설계된 프로젝트는 첫 번째 기술적 장애물에 빠지지 않고 핵심 메시지를 전달할 수 있어야 합니다 .

래퍼의 범위 내에서 작업하는 것은 약간의 패러다임 전환이며 장기 솔루션 측면에서 중간 집처럼 느껴집니다. 그러나 업계가 플랫폼 간 표준으로 발전할 때까지 게시자는 자체 솔루션을 출시하거나 플랫폼 간 변환을 위해 Distro와 같은 도구를 사용하거나, 그렇지 않으면 청중의 전체 섹션을 무시해야 합니다.

우리에게는 초기 단계이지만 지금까지는 래퍼 패턴을 사용하여 콘텐츠를 한 번 빌드하고 현재 청중이 사용하고 있는 수많은 플랫폼에 전달하는 데 큰 성공을 거두었습니다.