구조적 콘텐츠 관리 시스템을 사용한 헤드리스 프로젝트 전략

이것은 헤드리스 콘텐츠 관리 시스템(CMS)으로 프로젝트를 실행할 때 지난 몇 년 동안 있었으면 하는 가이드입니다. 저는 개발자, 사용자 경험 및 기술 컨설턴트, 프로젝트 관리자, 정보 설계자 및 저자였습니다. 다양한 모자를 통해 우리가 소위 "헤드리스" CMS를 사용한지 꽤 되었지만 가장 잘 사용하는 방법에 대해 생각하는 방법이 여전히 있다는 것을 깨닫게 되었습니다.

우리는 이제 플랫 페이지 레이아웃을 구현하는 대신 컴포넌트와 컴포지션으로 구성된 디자인 시스템을 사용하여 프론트엔드 작업을 위해 JavaScript 프레임워크에 의존하는 경우가 많습니다. 서버와 클라이언트 모두에서 실행되는 JAMstacks 및 동형/범용 앱에 대한 많은 관심이 있습니다. 퍼즐의 마지막 조각은 모든 콘텐츠를 관리하는 방법입니다.

기존 CMS는 네트워크 요청 및 JSON 형식을 통해 콘텐츠를 제공하는 API를 추가하고 있습니다. 또한 API를 통해 콘텐츠를 독점적으로 제공하기 위해 "헤드리스" CMS가 등장했습니다. 하지만 이 기사에서 내 주장 은 "헤드리스"에 대해 이야기하는 시간을 줄이고 "구조화된 콘텐츠"에 대해 더 많이 이야기해야 한다는 것입니다. 그것이 이러한 시스템의 본질적인 품질이기 때문입니다. 이러한 시스템이 암시하는 기술에 대한 많은 의미가 있으며 이러한 기술을 처리하는 방법의 좋은 패턴을 파악하는 측면에서 여전히 갈 길이 있습니다.

인문학에 대한 배경지식에서 기술 컨설팅을 시작하면서 저는 콘텐츠 중심 접근 방식을 취하는 웹 프로젝트를 구성하고 작업하는 방법에 대해 많은 것을 배웠습니다. CMS에서 실제 라이브 콘텐츠를 일찍 시작하는 방법에 대해 감사하게 되었습니다. 학제간 환경에서 그렇게 함으로써 초기 단계에서 복잡성을 발견할 수 있을 뿐만 아니라 관련된 모든 사람에게 권한을 부여하고 가장 넓은 의미에서 기술 및 디자인의 도전과 가능성에 대해 성찰할 수 있는 기회를 제공합니다.

이 기사에서는 구조화된 콘텐츠 작업에 대해 생각하는 방법에 대한 몇 가지 구체적이고 실제적인 예와 함께 몇 가지 중요한 전략을 제안합니다. 글을 쓰는 시점에서 저는 API를 통해 제공되는 콘텐츠를 호스팅하기 위해 이러한 콘텐츠 관리 서비스를 제공하는 SaaS 회사에서 일하기 시작했습니다. 나는 컨설턴트로 참여한 프로젝트에서 과거 경험과 내가 말하고 싶은 요점을 적절하게 설명한다고 생각하기 때문에 언급할 것입니다. 따라서 이것을 일종의 면책 조항으로 생각하십시오.

그렇긴 하지만, 나는 이 기사를 쓰는 것에 대해 몇 년 동안 생각했고, 당신이 선택한 플랫폼에 적용할 수 있도록 노력했습니다. 그러니 더 이상 고민하지 않고 20년 전으로 시간을 거슬러 올라가 오늘날 우리가 어디에 있는지 좀 더 이해해 보겠습니다.

웹 표준을 사용한 첫 번째 움직임

2000년대 초반에 웹 표준 운동은 한 분야에서 작업 방식을 바꾸도록 영감을 주었습니다. "레이아웃 우선" 접근 방식에서 그들은 HTML을 사용하여 페이지의 콘텐츠를 의미론적 으로 마크업하는 방법에 대해 주의를 기울였습니다. 웹사이트의 메뉴는 <table> 이 아니라 <nav> 입니다. 제목은 <b> 가 아니라 <h1> 입니다. 사용자가 콘텐츠를 찾고, 식별하고, 받아들이도록 돕기 위해 콘텐츠 웹이 수행하는 다양한 역할에 대해 생각하는 중요한 단계였습니다.

웹 표준 운동은 시맨틱 마크업이 접근성을 개선하고 Google 검색 결과에서의 순위도 향상시켰다는 주장을 도입했습니다. 그것은 또한 웹 콘텐츠에 대한 생각의 변화를 의미했습니다 . 귀하의 웹사이트는 더 이상 귀하의 콘텐츠가 대표되는 유일한 장소가 아닙니다. 또한 검색 결과나 화면 판독기와 같은 다른 시각적 컨텍스트에서 웹 페이지가 표시되는 방식에 대해서도 생각해야 했습니다. 이것은 나중에 소셜 미디어와 공유 링크의 내장된 미리보기에 의해 촉진되었습니다. 사고 방식은 콘텐츠가 어떻게 보여야 하는지, 무엇을 의미 해야 하는지로 바뀌었습니다. 이것은 구조화된 콘텐츠 작업의 핵심이기도 합니다.

인터넷에 연결된 포켓 사이즈 장치의 채택으로 웹은 갑자기 앱에서 심각한 경쟁자가 되었습니다. 그러나 경쟁은 대부분 최종 사용자의 눈알을 위한 것이었습니다. 많은 조직은 여전히 ​​앱과 다양한 웹에서 제품 및 서비스에 대한 정보를 배포해야 했습니다. 동시에 웹이 성숙해지고 JavaScript와 AJAX가 API를 통해 다양한 콘텐츠 소스를 쉽게 연결할 수 있게 되었습니다. 오늘날 우리는 콘텐츠 가져오기와 상태 관리를 더 간단하게 만들어주는 GraphQL과 도구를 가지고 있습니다. 그래서 기술 퍼즐의 일부가 제자리에 떨어지기 시작합니다.

"한 번 만들고 모든 곳에 게시"

대부분 "기술적 변화"로 설명되지만 JSON 페이로드(HTTP 튜브를 따라 이동)에 콘텐츠를 포함하는 것은 디지털 콘텐츠 및 주변 워크플로에 대해 생각하는 방식에 엄청난 영향을 미칩니다. 어떤 면에서는 이미 있습니다. 거의 10년 전 NPR(National Public Radio)의 Daniel Jacobson 게스트는 programmableweb.com에서 블로그 접근 방식에 대해 블로그에 올렸습니다. 이 접근 방식은 COPE(한 번만 만들고 어디에서나 게시)라는 약어에 요약되어 있습니다. 이 기사에서 그는 당시(그리고 틀림없이 현재) 대부분의 CMS가 그랬던 것처럼 HTML 렌더링 머신을 통하지 않고 API를 통해 여러 디지털 인터페이스에 콘텐츠를 제공하는 콘텐츠 관리 시스템을 소개합니다.

NPR의 COPE "데이터 관리 계층"은 "헤드리스 CMS"의 개념이 될 것입니다. COPE 초기에는 콘텐츠를 XML로 구조화하여 달성했습니다. 오늘날 JSON은 사물 인터넷 장치 및 웹 외부의 기타 시스템을 포함하여 API를 통해 데이터를 전송하기 위한 지배적인 데이터 형식이 되었습니다. 챗봇, 음성 인터페이스 및 시각적 프로토타이핑을 위한 소프트웨어와 콘텐츠를 교환하려는 경우 JSON 억양으로 HTTP를 사용하는 경우가 많습니다.

"헤드리스 CMS"라는 용어를 "언코이닝(Uncoining)"

Google 트렌드에 따르면 "headless CMS"에 대한 검색은 NPR의 COPE 기사가 나온 지 6년 후인 2015년 말에 인기를 얻었습니다. "헤드리스"라는 용어(적어도 18세기 프랑스 귀족이 아니라 디지털 기술과 관련하여)는 그래픽 사용자 인터페이스 없이 실행되는 시스템에 대해 오래 전부터 사용되어 왔습니다.

참고 : 명령줄 인터페이스가 서버 또는 테스트 환경의 소프트웨어와 같이 실제로 "그래픽"이라고 주장할 수 있습니다(그러나 다른 기사를 위해 저장하겠습니다).

저는 이 새로운 CMS를 "헤드리스(headless)"라고 부르는 두 가지 생각을 가지고 있습니다. 머리가 많은 "다두증"이라고 부를 수도 있습니다. 그들은 CMS의 히드라와 케르베우스입니다. "Headless"는 또한 이러한 시스템을 진정한 강점으로 정의하는 대신 부족한 기능(즉, 웹 페이지 렌더링을 위한 템플릿 엔진)으로 정의합니다. 즉, 웹의 제약 없이 콘텐츠를 구성할 수 있습니다. 즉, 오늘날 이 범주의 많은 솔루션을 "거의 머리가 없는 닉"이라고 부를 수도 있습니다. 편집 인터페이스가 여전히 시스템과 밀접하게 연결되어 있기 때문입니다. 그들의 "머리 없음"은 템플릿 엔진, 즉 콘텐츠에서 마크업을 생성하는 기계가 없기 때문에 발생합니다.

참고 : 저는 "Mimsy-Porpington"(Harry Potter 세계에서 알려짐)이라는 CMS를 거의 확실히 사용할 것입니다.

대신 API를 통해 콘텐츠를 사용할 수 있으므로 이 콘텐츠를 표시하고 사용하려는 방법, 대상 및 위치에 대해 더 많은 유연성을 제공합니다. 따라서 React, Angular 및 Vue와 같은 인기 있는 JavaScript 프론트엔드 프레임워크의 완벽한 동반자가 됩니다. 그리고 "웹사이트, 앱, 장치"에 콘텐츠를 전달할 수 있다는 주장에도 불구하고 대부분은 여전히 ​​웹 콘텐츠가 작동하는 방식에 따라 제한을 받습니다. 이는 서식 있는 텍스트를 HTML 또는 Markdown으로 저장하는 대부분의 처리 방식에서 가장 두드러집니다.

전통적인 CMS는 또한 템플릿 렌더링 시스템 외에 다소 일반적인 API를 추가하기 시작했으며 이를 새로운 경쟁자와 구별하기 위해 "분리"라고 부릅니다. "이 모든 것과 API도!"*가 주장입니다. 이러한 CMS 중 일부는 콘텐츠 모델링과 관련하여 매우 불가지론적입니다. 예를 들어 Craft CMS는 처음 설치할 때 콘텐츠 모델에 대해 거의 가정하지 않습니다. Wordpress는 또한 콘텐츠 전달을 위해 API를 사용하는 방향으로 나아가고 있습니다. CMS 분야에서 기존 선수와 새로운 선수 사이의 격차는 앞으로 갈수록 좁아질 것이라고 생각합니다.

그럼에도 불구하고 (HTML 렌더러 대신) API 뒤에 콘텐츠 관리를 두는 것은 조직의 텍스트, 이미지, 비디오 및 미디어가 디지털화되어 내부 및 외부 사용자와 고객에게 노출되는 시대에 보다 정교한 작업 방식을 위한 중요한 단계입니다. 하지만 부족한 프론트엔드 렌더링 기능을 정의하는 것에서 벗어나 그들이 우리를 위해 실제로 할 수 있는 일, 즉 구조화된 콘텐츠로 작업할 수 있는 방법을 제공 해야 할 때입니다. 그렇다면 이를 "구조적 콘텐츠 관리 시스템"이라고 불러야 합니까? "No Bob, 이것은 일반적인 CMS가 아닙니다. 이것은 SCMS입니다. 저를 믿으십시오. 일이 될 것입니다.”

머리에 관한 것이 아니라 구조화된 콘텐츠에 관한 것입니다

SCMS(Structured Content Management Systems)가 부과하는 가장 근본적인 변화는 페이지 계층 구조에 따라 콘텐츠를 정렬하는 것에서 벗어나 원하는 목적에 따라 자유롭게 콘텐츠를 구성할 수 있는 곳으로 이동한 것입니다. 중복 콘텐츠를 피하는 것은 안정성을 높이고 관리 부담을 줄이기 때문에 분명한 이점입니다(여러 채널에서 중복 콘텐츠에 대처할 필요가 없음). 즉 , 한 번 만들고 모든 곳에 게시 합니다. 하나의 시스템에서 제품 설명을 한 번만 업데이트해야 하고 제품이 사용자에게 노출되는 곳마다 업데이트된다면 분명히 이점이 있습니다.

SCMS 공급업체는 페이지 구조에 대해 다르게 생각하는 것을 정당화하기 위해 "귀하의 웹사이트와 앱"을 자주 사용하지만 구조화된 콘텐츠 구조의 이점을 얻기 위해 강을 건너야 할 필요는 없습니다. JavaScript 프레임워크의 인기로 인해 상태 및 컨텍스트에 따라 다른 콘텐츠로 "채울" 수 있는 개별 구성 요소의 구성으로 웹 사이트를 구축하는 것이 점점 더 일반적입니다. 웹 애플리케이션 전반에 걸쳐 다양한 컨텍스트에서 나타나는 제품 카드가 있을 수 있습니다. 우리는 현대 웹 개발이 문서 및 페이지 설정에서 사용자 입력, 알고리즘 및 사용자 정의의 혼합에 따라 구성 요소를 구성하는 것으로 이동하고 있음을 보고 있습니다.

디자인 시스템이 만들어지는 방식과 테스트, 학습 및 반복 프로세스를 통해 팀으로 작업하는 방법에 대한 이러한 추세는 콘텐츠 관리 분야를 새로운 사고 방식에 맞게 무르익게 만듭니다. 일부 패턴이 나타났지만 아직 갈 길이 많습니다. 따라서 콘텐츠를 최우선으로 하는 팀과 프로젝트에서 일한 경험을 바탕으로 현재 서비스를 구축하는 팀의 일원으로서 도움이 될 수 있다고 생각하는 몇 가지 전략을 제시하고 추가 토론을 위한 요점을 만듭니다.

1. 다분야 팀의 콘텐츠 접근

나는 그래픽 디자이너가 디자인을 "구현"하는 책임이 있는 프론트엔드 개발자에게 낡고 픽셀 완벽한 페이지를 넘겨줄 수 있는 과거의 일이라고 믿습니다. 이제 더 작은 구성 요소로 구성된 디자인 시스템을 만들고 기본적으로 여러 가지 가능한 상태를 제공하는 컴포지션에 배치됩니다. 대부분의 경우 이러한 구성 요소는 사용자 생성 입력에 대해 탄력적이어야 합니다. 즉, 라이브 콘텐츠를 프로세스에 빨리 도입할수록 더 좋습니다. 프론트엔드 개발자의 책임은 그래픽 디자이너의 비전을 재현하는 것이 아닙니다 . 브라우저가 HTML, CSS 및 JavaScript를 렌더링하는 방법에 대한 복잡한 분야를 조작하여 사용자 인터페이스가 반응적이고 액세스 가능하며 성능이 좋은지 확인하는 것입니다.

Netlife(사용자 경험을 전문으로 하는 컨설팅 회사)에서 기술 컨설턴트로 일할 때 개발자, 디자이너 및 사용자 연구원 간의 협업을 향한 큰 진전을 보았습니다. 콘텐츠 편집자는 처음부터 항상 프로젝트에 참여했지만, 주로 기술적인 마찰로 인해 그들의 기여가 디자인 워크플로에 들어가지 않았습니다.

병목 현상은 종종 우리가 건드릴 수 없는 레거시 CMS이거나 디자인 레이아웃에 의존하기 때문에 콘텐츠 구조를 구축하는 데 시간이 걸렸습니다. 이는 종종 작업을 두 배로 늘리는 결과를 가져왔습니다. 우리는 종종 Markdown 파일에서 구문 분석된 콘텐츠를 기반으로 HTML 프로토타입을 만들었습니다. 이 프로토타입은 사용자 테스트가 완료되었을 때 CMS 스택에서 다시 구현해야 했으며 모두가 만족했습니다. . CMS의 한계가 프로세스 후반에 발견되었기 때문에 이는 종종 비용이 많이 드는 프로세스였습니다. 또한 모든 부품에 "처음에 올바르게 작업"해야 하는 압력을 가하고 설계 프로젝트에서 원하는 종류의 실험을 위한 공간을 덜 남깁니다.

다분야 작업에는 민첩한 시스템이 필요합니다.

콘텐츠 모델을 코딩하는 데 몇 분이 걸렸던 SCMS(필드와 API가 즉시 준비됨)로 이동하면서 프로세스가 완전히 바뀌었고 더 좋았습니다. 프로젝트 초기에 새로운 u4.no의 콘텐츠 편집자와 함께 앉아 있었던 것을 기억합니다. 그들이 어떻게 일했고 그들의 콘텐츠로 일하고 싶은지 이야기합니다. 오히려 빠르게 우리는 우리의 결론을 브라우저의 편집 환경으로 즉시 변환되는 간단한 JavaScript 개체로 변환했습니다. 도움이 되는 제목과 제목에 대한 설명을 파악합니다. 우리는 그들이 서로 다른 페이지와 컨텍스트에서 재사용할 수 있는 텍스트 스니펫을 원하는 방법에 대해 이야기했습니다. 이 스니펫을 사내에서 "너겟"이라고 불렀고 그때 그때 그 자리에서 만들었습니다.

우리 앞에서 인터페이스가 만들어지는 동안 콘텐츠 편집자와 개발자가 함께 이야기하는 프로젝트 개발 초기에 이러한 종류의 탐색을 허용하는 것이 강력하게 느껴졌습니다. 그녀와 그녀의 동료가 콘텐츠 작업을 시작하는 동안 React에서 프론트엔드를 계속 디자인할 수 있다는 것을 알고 있습니다. 그리고 구조가 프론트엔드 부분을 코딩해야 하는 방법과 밀접하게 결합된 CMS에서 자주 했던 것처럼 모퉁이에 자신을 그리는 것에 대해 걱정하지 않아도 됩니다.

콘텐츠 시스템은 실험과 반복을 허용해야 합니다.

독창적인 재설계 프로젝트를 제외하고 구조화된 콘텐츠 시스템을 통해 전체 디자인 시스템의 일부로 콘텐츠를 지속적으로 개선, 테스트 및 반복할 수 있어야 합니다. UX 디자이너는 Sketch 또는 Framer X와 같은 도구를 사용하여 실제 콘텐츠로 신속하게 프로토타입을 만들 수 있어야 합니다. 가독성 척도 또는 콘텐츠가 사용되는 곳에서 콘텐츠가 어떻게 작동하는지에 관계없이 정량적 측정을 통해 콘텐츠 관리를 강화할 수 있어야 합니다.

참고 : 나는 우리 모두가 어떤 면에서는 좋은 사용자 경험을 만드는 과정과 관련되어야 한다는 의견에도 불구하고 위에서 "UX 디자이너"라는 용어를 사용했습니다. 우리는 모두 다양한 디자인 분야의 UX 디자이너입니다.

웹 페이지 레이아웃에 콘텐츠를 직접 WYSIWYG 방식으로 표시하는 데 익숙하다면 구조화된 콘텐츠로 작업하는 데 약간의 적응이 필요합니다. 그러나 디지털 디자인 분야가 어떻게 움직이고 있는지에 더 부합하는 대화에 적합합니다. 구조화된 콘텐츠를 사용하면 디자이너, 개발자, 콘텐츠 편집자, 사용자 연구원 및 프로젝트 관리자로 구성된 팀이 사용자의 요구와 전략적 목표를 지원하기 위해 시스템이 작동하는 방식에 대해 집합적으로 생각할 수 있습니다. 이것은 또한 콘텐츠 구조에 대해 다르게 생각해야 하며, 이는 우리를 다음 전략으로 안내합니다.

2. 주문이 필요하지 않을 수도 있습니다.

많은 사람들에게 가장 눈에 띄는 변화 중 하나는 구조화된 콘텐츠를 위한 시스템이 웹사이트 탐색 구조를 반영하는 폴더와 같은 계층이 아니라 문서의 컬렉션과 목록에 맞춰져 있다는 것입니다. 이러한 구조는 일부 콘텐츠가 챗봇, 인쇄 매체 또는 기타 웹사이트와 같은 다른 컨텍스트에서 사용되는 즉시 의미를 멈춥니다. 기존 CMS는 재사용 가능한 콘텐츠 블록을 허용하여 이를 완화하려고 시도했지만 여전히 페이지 레이아웃에 배치해야 하고 API를 통해 추론하기가 번거롭습니다.

각 페이지 자체에

핵심 모델에 나와 있는 것처럼 주요 참조 대상 중 하나가 Google이거나 소셜 미디어에서 공유하는 경우 모든 페이지를 방문 페이지로 고려해야 합니다. 페이지 조회수 분포를 보면 일부 페이지가 다른 페이지보다 훨씬 더 인기가 있음을 알 수 있습니다. 당신이 뉴스 웹사이트가 아닌 이상, 그것들은 뉴스가 아니라 사용자가 당신의 웹사이트에서 달성하고자 하는 모든 것을 성취할 수 있게 해주는 경향이 있습니다. 그들은 비즈니스가 실제로 일어나는 곳입니다.

디지털 콘텐츠는 자신의 전략적 목표와 사용자의 개별 목표가 교차하는 부분에 서비스를 제공해야 합니다. 디지털 에이전시 Bengler(sanity.io의 전신)가 oma.eu를 위한 새 웹사이트를 만들 때 페이지의 정교한 계층 구조에 따라 콘텐츠를 구성하지 않았습니다. 그들은 조직의 일상적인 현실, 즉 프로젝트 , 사람 , 출판 이후를 반영하는 콘텐츠 유형을 만들었습니다. 사실, OMA 웹사이트는 콘텐츠 계층 구조 측면에서 거의 완전히 평면적이며 첫 페이지는 알고리즘 및 편집 규칙의 혼합으로 생성됩니다.

어떻게 해야 할까요? 귀하의 콘텐츠에 대한 생각은 조직의 정신 모델과 사용자가 필요로 하는 모든 것에 유용해야 하는 방식을 반영하는 것으로 생각합니다.

다음은 기본적인 예입니다. 직원 페이지를 작성할 때 아마도 person 이라는 콘텐츠 유형으로 시작해야 할 것입니다. 사람 은 이름, 연락처 정보, 이미지, 다양한 조직 역할 및 짧은 전기를 가질 수 있습니다. 개인 문서는 연락처 목록, 기사 작성자별, 채팅 지원 인터페이스 및 건물 액세스 배지에서 재사용할 수 있습니다. 이 사람들이 누구인지 알고 API와 함께 제공되는 사내 시스템이 이미 있습니까? 좋습니다. 그러면 동기화합니다.

존재론적 래빗 홀에서 길을 잃지 마십시오

웹 페이지를 색인화하는 Google의 방식과 세계 정보를 색인화하려는 방법으로 돌아가는 것이 유용합니다. 그렇기 때문에 링크된 데이터(RDFa, microformat, JSON-LD)에 시간과 노력을 들이고 있습니다. JSON-LD 요소로 웹 페이지에 주석을 추가하면 검색 결과에서 더 눈에 띄게 표시됩니다. 정보를 음성 비서가 말하고 비서 UI에 표시해야 하는 경우에도 관련이 있습니다. 콘텐츠가 이미 구조화되어 있고 API에서 쉽게 사용할 수 있는 경우 이러한 마이크로포맷으로 구현하는 것이 상대적으로 쉬울 것입니다.

나는 schema.org의 온톨로지와 다양한 연결된 데이터 리소스에 대해 모든 것을 추천할 것인지 확신이 서지 않습니다. 적어도 편집자의 목적은 아닙니다. 모든 것이 들어맞는 완벽한 플라토닉 구조를 만들려고 애쓰는 토끼굴에 빠르게 빠져들 수 있습니다.

Newsflash : 세상은 어지러운 곳이고 사람들은 사물에 대해 다르게 생각하기 때문에 절대 그럴 수 없습니다.

직관적인 의미가 있고 요구 사항의 변화에 ​​따라 적응할 수 있는 시스템에서 콘텐츠를 구성하는 것이 더 중요합니다. 이것이 디자인 및 개발 프로세스 초기에 콘텐츠 모델링을 시작하는 것이 중요한 이유입니다. 사용 방법을 배워야 합니다.

CMS 규약이 아닌 현실의 초록

CMS와 함께 제공되는 규칙을 따르고 싶은 마음이 들 수 있습니다. Wordpress에서 "게시물" 및 "페이지"를 제공하는 방법을 기억하고 갑자기 모든 항목을 해당 상자에 맞춰야 합니까? WYSIWYG 서식 있는 텍스트 필드는 무엇이든 넣을 수 있다는 점에서 유연하지만 내용은 구조화되지 않고 쉽게 적응할 수 없습니다. 한 번만 유연합니다. 그러나 콘텐츠 모델 매핑을 시작할 장소가 필요합니다. 내 제안은 사람들, 즉 작가와 독자와 이야기하는 것으로 시작하는 것입니다.

사람들은 내부적으로 콘텐츠에 대해 어떻게 이야기합니까? 사람들은 다른 것을 무엇이라고 부릅니까? 민족지학자들이 민속 분류법을 매핑하는 데 사용하는 방법인 무료 목록 작성 연습을 실행할 수 있습니다. 예를 들어 다음과 같이 질문할 수 있습니다.

"우리 조직의 다양한 콘텐츠 유형을 지정하십시오."

또는 보다 구체적인 수준에서:

"이 조직에 있는 다양한 유형의 보고서를 말할 수 있습니까?"

이 설문 조사의 요점은 사람들이 가지고 있는 내면화된 분류법을 설명하는 것이지, 사물에 대한 의견이나 감정(종종 디자인 프로세스를 방해하는 경향이 있는 것)이 아닙니다. 당신이 작업할 수 있는 꽤 철저한 목록을 갖기 전에 특별히 많이 물어볼 필요는 없습니다. 목록의 일부가 현재 CMS의 규칙에서 나온 것임을 알게 될 것입니다. 이제 당신 은 당신 의 편집자 와 이야기 하고 그들이 해야 할 콘텐츠 가 무엇 을 필요 로 하는지 알아내려고 노력해야 합니다 .

다음과 같은 질문을 할 수 있습니다.

• 이 콘텐츠를 여러 곳에서 사용해야 합니까? 어디에?
• 콘텐츠 유형 간의 다른 관계는 무엇입니까?
• 콘텐츠가 오늘과 내일 어디에 표시되어야 합니까?
• 어떤 방식으로 콘텐츠를 정렬해야 합니까? 주문은 사용자가 알고리즘적으로 수행할 수 있습니까? 아니면 수동으로 해야 합니까?
• 중복을 방지하기 위해 동기화할 수 있는 시스템이나 데이터베이스가 다른 시스템에 있습니까?
• 표준 콘텐츠가 어디에 있기를 원합니까? SCMS가 소스가 되어야 합니까, 아니면 기존 콘텐츠를 보강해야 합니까(예: 제품 관리 시스템에 있는 제품에 대한 마케팅 카피)?

그렇다고 해서 지금은 미지근한 목욕물로 기존의 정보 아키텍처를 버려야 한다는 의미는 아닙니다. 기사가 조직의 컨텐츠 현실의 일부인 경우 기사 를 컨텐츠 유형으로 갖는 것이 여전히 합리적입니다. 그러나 이러한 기사에 서비스 또는 제품 유형에 대한 참조가 있는 방식 때문에 카테고리 의 추상 규칙이 실제로 필요하지 않을 수도 있습니다. 그리고 이 관계를 통해 누군가가 직무 설명의 일부로 "기사 카테고리 관리"를 요구하지 않고도 적절한 상황에서 이러한 기사를 쿼리할 수 있습니다.

이 기사 는 콘텐츠를 프레젠테이션 계층에서 완전히 분리하는 것을 어렵게 만드는 요인이기도 합니다. 우리는 기사의 레이아웃과 스타일에 대해 생각하는 데 너무 익숙하지만 자신의 도메인에서 자신의 콘텐츠를 호스팅한 다음 이를 medium.com과 같은 플랫폼에 신디케이트해야 하는 시대에 이미 포기했습니다. 시각적 표현을 제어합니다. 이것은 우리를 다음 전략으로 이끕니다.

3. 프레젠테이션 컨텍스트는 콘텐츠 유형이기도 합니다.

재설계 준비

전체 콘텐츠 아키텍처를 재구축하거나 엄격한 폴더와 같은 인터페이스에 맞서 싸울 필요 없이 웹사이트의 탐색 구조를 조정하고 신속하게 변경할 수 있기를 원합니다. 때로는 이해가 되기도 하고 때로는 API 우선 CMS 부서의 대부분의 인터페이스가 많은 도움을 제공하지 못하는 두 가지 수준보다 더 깊어지기 때문에 일부 콘텐츠 계층 구조를 가질 수 있기를 원합니다.

흥미롭게도 챗봇용 콘텐츠 관리 시스템은 의도 트리와 대화 흐름을 정렬하기 위해 유사한 계층 구조를 사용하는 경향이 있습니다. 이는 콘텐츠 계층 구조가 채널마다 다른 역할을 하지만 종종 콘텐츠를 탐색하는 방법을 제공한다는 것을 의미합니다. 이에 접근하는 방법은 참조별로 콘텐츠를 정렬할 수 있는 탐색 유형을 만들고 웹 페이지, 메뉴 또는 대화형 인터페이스에 대한 경로를 빌드하는 것입니다.

관계 조언

참조(또는 관계)는 구조화된 콘텐츠를 위한 시스템을 가능하게 하며 실제로 웹 콘텐츠와 관련하여 처리하는 모든 것의 핵심입니다(이것이 은유적 으로 웹 이라고 불리는 이유입니다). 콘텐츠 비트 간에 참조를 만들 수 있다는 것은 매우 강력한 기능이지만 백엔드가 이러한 데이터를 쓰고 검색할 수 있는 방법 측면에서 비용이 많이 들 수도 있습니다. 따라서 스케일은 거의 무료로 제공되지 않으므로 문서가 많은 경우 다르게 생각해야 할 수도 있습니다.

데이터를 결합하기 위해 항상 명시적인 참조가 필요한 것은 아니라는 점을 고려해 볼 가치가 있습니다. 대부분 콘텐츠와 관련된 기준에 따라 수행할 수 있습니다(예: "이 지리적 위치 내의 모든 사람 및 모든 건물 제공"). 건물과 사람은 두 콘텐츠 유형의 위치 필드에 암시되어 있는 한 서로에 대해 명시적으로 참조할 필요가 없습니다.

프레젠테이션 유형과 다른 콘텐츠 유형 간의 참조는 데이터를 결합하기 위해 프레젠테이션 계층의 알고리즘에 맡길 수 없을 때 유용합니다. 이러한 프리젠테이션 유형을 명시적으로 그리고 참조된 콘텐츠의 구성을 만드는 것이 다소 번거롭게 보일 수 있지만 SCMS에서 자주 만날 수 있는 문제에 대한 해결책입니다. 콘텐츠가 사용되는 위치를 아는 것이 어렵습니다. 탐색 유형을 포함하면 콘텐츠를 프레젠테이션에 명시적으로 연결할 수 있지만 하나만 연결할 수는 없습니다. 이를 통해 탐색 구조로 이어지는 내용과 독립적으로 탐색 구조로 작업하는 것을 추론할 수 있습니다.

예를 들어 스크린샷에서 Google 실험을 경로 유형에 연결하여 콘텐츠 참조로 구성된 여러 페이지 를 추가할 수 있도록 했습니다. 이는 콘텐츠 중복이 거의 없이 A/B 테스트를 실행할 수 있음을 의미합니다. 다른 문서에서 참조하는 콘텐츠를 삭제하려고 하면 경고를 받기도 하므로 이러한 구조화 방식은 삭제해서는 안 되는 항목을 삭제하지 않도록 합니다.

콘텐츠 유형 간의 관계는 양날의 검입니다. 지속 가능성을 높이고 중복을 방지하는 데 중요합니다. 반면에 콘텐츠 간에 종속성을 만들기 때문에 쉽게 자해할 수 있으며, 이는 (투명하지 않은 경우) 데이터가 표시되는 채널 전체에서 의도하지 않은 변경으로 이어질 수 있습니다. 예를 들어 경고 없이 "경로"가 사용하는 "페이지"를 제거할 수 있다면 좋지 않습니다.

이것은 우리를 다음 전략으로 이끕니다. (당연합니다!) 이것은 다른 시스템이 어떻게 구성되어 있는지와 관련이 있기 때문에 오늘날 일반 사용자의 능력을 부분적으로 넘어서는 것입니다. 그래도 생각해 볼 가치가 있습니다.

4. 서식 있는 텍스트를 구석에 두지 마십시오.

서식 있는 텍스트는 HTML 그 이상입니다.

HTML이 디지털 콘텐츠에서 그렇게 널리 퍼지는 이유를 이해할 수 있지만 또한 무언가에서 비롯된다는 것도 압니다. 이것은 기계가 읽을 수 있는 문서를 구조화하는 일반화된 방법인 SGML의 하위 집합입니다. Claire L. Evans가 훌륭한 책 "Broad Band: Untold Story of the Women who made the Internet"(2018)에서 지적했듯이 HTML이 도입되었을 때 이미 링크된 문서에 대해 생각하는 사람들의 활기찬 커뮤니티가 있었습니다. Tim Berners-Lee의 제안은 그 당시 다른 많은 시스템보다 훨씬 간단했지만, 이것이 아마도 이것이 현재로서는 공개된 무료 웹을 가능하게 만든 이유일 것입니다.

월드 와이드 웹의 브라우저에 있을 때 HTML은 훌륭합니다. 간단한 HTML로 끝나는 것을 게시하려는 작가라면 Markdown이 좋습니다. 서식 있는 텍스트 콘텐츠를 브라우저가 아닌 다른 항목에 쉽게 통합하거나 복잡한 구성 요소에서 JavaScript로 HTML을 보강할 수 있는 인기 있는 JavaScript 프레임워크를 원하는 경우(예, React 및 Vue.js에 대해 이야기하고 있습니다.) , 특히 구문 분석이 필요한 경우 API 응답에 HTML을 포함하는 것이 약간 번거롭습니다.

그래도 거의 모든 사람들이 하고 있습니다. 심지어 새로 온 아이들도 마찬가지입니다. 저는 headlesscms.org의 모든 공급업체를 살펴보고 문서를 검색했으며 언급하지 않은 사람들도 등록했습니다. 두 가지 예외를 제외하고는 모두 서식 있는 텍스트를 HTML 또는 Markdown으로 저장했습니다. 웹사이트를 렌더링하기 위해 Jekyll을 사용하거나 React에서 위험하게SetInnerHTML을 사용하는 것을 즐긴다면 괜찮습니다. 하지만 웹에 없는 인터페이스에서 콘텐츠를 재사용하려면 어떻게 해야 할까요? 아니면 서식 있는 텍스트 편집기에서 더 많은 제어와 기능을 원하십니까? 아니면 인기 있는 프론트엔드 프레임워크 중 하나에서 서식 있는 텍스트를 더 쉽게 렌더링하고 구성 요소가 서식 있는 텍스트 콘텐츠의 다른 부분을 처리하도록 하고 싶으십니까? 글쎄요, 당신은 마크다운이나 HTML을 당신이 필요로 하는 것으로 구문 분석하는 현명한 방법을 찾거나, 더 편리하게는 처음부터 그것을 더 합리적으로 저장하도록 해야 할 것입니다.

예를 들어 서식 있는 텍스트를 음성 인터페이스로 출력하려면 어떻게 해야 합니까? 음성 비서의 인기가 높아지고 있음을 알고 있습니다. 이러한 보조자를 위한 가장 인기 있는 플랫폼에는 API를 통해 음성 콘텐츠에 대한 텍스트를 가져올 수 있는 기능이 있습니다. 그런 다음 Speech Synthesis Markup Language와 같은 것을 활용하고 싶습니다. 이식 가능한 텍스트를 위한 시스템은 서식 있는 텍스트에 대해 더 불가지론적인 접근 방식을 취하므로 동일한 콘텐츠를 다양한 종류의 인터페이스에 적용할 수 있습니다.

추천 자료 : SpeechSynthesis 인터페이스 실험하기

불가지론적 서식 있는 텍스트 모델로서의 휴대용 텍스트

이동식 텍스트는 주로 웹용 콘텐츠를 수행할 때도 유용합니다. 서식 있는 텍스트 각주 또는 인라인 편집 주석과 같은 데이터 구조로 텍스트를 중첩하고 보강할 수 있는 가능성을 갖고 싶다면 어떻게 하시겠습니까? 또는 A/B 테스트 사례에 대한 대체 문구 또는 문구? Markdown과 HTML은 빠르게 부족하며 Wordpress에서 해결한 것처럼 특수 단축 코드 태그와 같은 것을 추가하는 데 의존해야 합니다. 이식 가능한 텍스트를 사용하면 특정 구현과 결합하지 않고도 콘텐츠 구조를 불가지론적으로 표현할 수 있습니다. Your content ends up being more sustainable and flexible for new redesigns and implementations.

There are also other advantages to portable text, especially if you want to be able to edit content collaboratively and in real time (as you do in Google Docs); you need to store rich text in another structure than HTML. If you do, you'll also be able to take advantage of microservices and bots, such as spaCy, in order to annotate and augment your content without locking the document.

As for now, portable text isn't widely adopted, but we're seeing movements towards it. The specification isn't very complex and can be explored at portabletext.org.

5. Make Sure Your SCMS Is In Service For Your Editors, And Not The Other Way Around

Digital content isn't just used for your organization's online web page leaflets anymore. For most of us, it encapsulates and defines how your organization is understood by the world, both from those within it and those outside: From product copy, micro texts to blog posts, chatbot responses, and strategy documents. We are millions of people that have to log into some CMS every day and navigate interfaces that were imagined twenty years ago with the assumptions of people who have never made much effort to user test or challenge their interfaces. Countless hours have been wasted away trying to fit a modern frontend experience into a page layout machine. Fortunately, this is soon a thing of the past.

As a technology consultant, I had to read through pages of technical specification whenever someone thought it was time to acquire a new CMS for themselves. There were demands from which server architecture it should run on (Windows servers, of course) to their ability to render “carousels” and “being able to edit web pages in place”, despite also requesting a “modular redesign”. When editors had been allowed to contribute to these specifications, they were also often dated to the what the editors had begotten used to. They seemed not aware that they could demand better user experiences, because enterprise software has to be big, lumpy and boring.

This is partly the fault of us making these systems. We tend to communicate technology features and specifications, and less what the everyday situation working with these systems look like. Sure, for a frontend designer, something supporting GraphQL is shorthand for how conveniently she is able to work against the backend, but on a higher level, it's about the systems ability to accommodate for emerging workflows, where a content model could survive visual redesigns and design systems should be resilient to changes of its content.

Questions To Ask Of Your (S)CMS

If we are to embrace design processes, we can't know prior to solving the problem whether the user tasks are best solved by making carousels ( newsflash: most probably not ), or whether A/B-testing makes sense for your case, even though it sounds cool.

Instead, ask questions like this:

• Is it possible, and how exactly will multi-disciplinary teams work with this system?
• How easy is it to change and migrate the content model?
• How does it deal with file and image assets?
• Has the editorial interface been user tested?
• To what extent can the system be configured and customized to special workflows and needs of the editorial team?
• How easy is it to export the content in a moveable format?
• How does the system accommodate for collaboration?
• Can content models be version controlled?
• How easy is it to integrate the system with a larger ecosystem of flowing information?

The goal of these questions is to explore to what degree a content management system allows for a cross-disciplinary team to work effortlessly together, without too many bottle-necks or long deployment cycles. They also push the focus to be more about the content should be doing, and less about how things should look in a given context. Leave that for the design processes, where user testing probably will challenge assumptions one may have when looking into getting a new content system.

There are, of course, many factors in addition to this that probably have to be taken into consideration. The easiest thing to assess is the fiscal cost of software licenses and API-related costs if you are on a hosted service. The invisible cost (in time and attention spent by the team working with the system), is harder to estimate. From my experience, many of the SCMSs in combination with one of the popular frontend frameworks can significantly cut development time and allow for an agile ( there's my coin for the swear jar ) design process. With the caveat that your team is prepared to solve some of the problems that come out of the box with traditional CMSs.

Towards Structured Content

The ways we work with digital content has changed dramatically since the World Wide Web made working with interconnected documents mainstream. Organizations, businesses, and corporations have amassed gigabytes of this content, which now is stuck in rigid page hierarchies, HTML markup, and clunky user interfaces.

Using a Structured Content Management System can be a great way to free your content from a paradigm that begins to feel its age. But it isn't a trivial exercise, and success comes from being able to work multi-disciplinary and put your content model to the test. You need to get rid of some conventions you have grown used to by dealing with CMSs designed to output hierarchical websites. That means that you need to think differently about ordering content, make presentations types in order to make it easier to orchestrate content across multiple channels and to consider how you structure rich text so that it can be used outside of HTML contexts.

This article deals with some of the high-level concerns working with SCMSs. There are, of course, loads of exciting challenges when you start working with this in your team. You have to rethink stuff we've taken for granted for many years, but that's probably a good thing. Because we are forced to evaluate our content, not only from its place on a digital page but from its role in a larger system that works for whatever goals your organization and your users may have.

I believe that we can achieve content models that are more meaningful and easier to sustain in the long run, and that means saving time and expenses. It means more flexibility in terms of inventing new outputs and services, and less tie in with software vendors. Because a well-made Structured Content Management System will make it easy for you to take your content and go elsewhere. And that makes for some interesting competition. Hopefully, all in favor of the users.