Yapılandırılmış İçerik Yönetim Sistemleri ile Başsız Projeler İçin Stratejiler

Başsız İçerik Yönetim Sistemleri (CMS'ler) ile projeler yürütürken son birkaç yıldır sahip olmak istediğim rehber bu. Geliştirici, kullanıcı deneyimi ve teknoloji danışmanı, proje yöneticisi, bilgi mimarı ve yazar oldum. Farklı şapkalar, bir süredir sözde "başsız" CMS'lerimiz olsa bile, onları en iyi nasıl kullanacağımızı düşünmenin hala bir yolu olduğunu fark etmemi sağladı.

Artık çoğumuzun, yalnızca düz sayfa mizanpajları uygulamak yerine, bileşenlerden ve kompozisyonlardan oluşan tasarım sistemlerini kullanarak ön uç çalışması için JavaScript çerçevelerine güvendiği bir yerdeyiz. Hem sunucuda hem de istemcide çalışan JAMstacks ve izomorfik/evrensel uygulamalara yönelik çok fazla ilgi var. O zaman bulmacanın son parçası, tüm içeriği nasıl yönettiğimizdir.

Geleneksel CMS'ler, ağ istekleri ve JSON biçimi aracılığıyla içerik sunmak için API'ler ekliyor. Ek olarak, yalnızca API'ler aracılığıyla içerik sunmak için "başsız" CMS'ler ortaya çıkmıştır. Yine de bu makaledeki argümanım, "başsız" hakkında daha az ve "yapılandırılmış içerik" hakkında daha fazla zaman harcamamız gerektiğidir . Çünkü bu sistemlerin temel niteliği budur. Bu sistemler tarafından ima edilen zanaatımız için pek çok çıkarım var ve bu teknolojilerle nasıl başa çıkmamız gerektiğine dair iyi kalıpları bulmak açısından hala gitmemiz gereken bir yol var.

Beşeri bilimlerde bir geçmişe sahip teknoloji danışmanlığına gelince, içerik merkezli bir yaklaşım benimseyen web projelerinin nasıl organize edileceği ve bu projelerle nasıl çalışılacağı hakkında çok şey öğrendim - hem yeni API tabanlı hem de geleneksel CMS'lerle. Bir CMS'den gerçek canlı içerikle nasıl erken başladığımı takdir ettim; Bunu disiplinler arası bir ortamda yapmak, yalnızca karmaşıklıkları daha erken bir aşamada ortaya çıkarmayı mümkün kılmakla kalmadı, aynı zamanda dahil olan herkese acentelik kazandırdı ve en geniş anlamıyla teknoloji ve tasarımın zorlukları ve olasılıkları üzerinde düşünme fırsatı verdi.

Bu makalede, yapılandırılmış içerikle çalışma hakkında nasıl düşünüleceğine dair bazı somut, gerçek dünyadan örneklerle birlikte bazı kapsayıcı stratejiler önereceğim. Yazma sırasında, API'ler üzerinden sunulan içeriği barındırmak için böyle bir içerik yönetimi hizmeti sağlayan bir SaaS şirketi için çalışmaya yeni başladım. Hem danışman olarak dahil olduğum projelerdeki geçmiş deneyimimden dolayı hem de yapmak istediğim noktaları uygun bir şekilde gösterdiğini düşündüğüm için ona atıfta bulunacağım. Bu yüzden bunu bir tür sorumluluk reddi olarak kabul edin.

Bununla birlikte, birkaç yıldır bu makaleyi yazmayı düşünüyordum ve hangi platforma gitmeyi seçerseniz seçin onu uygulanabilir hale getirmeye çalıştım. Lafı fazla uzatmadan, bugün nerede olduğumuzu biraz daha anlamak için zamanda yirmi yıl geriye gidelim.

Web Standartlarıyla İlk Hamleler

2000'lerin başında, Web Standartları hareketi, çalışma biçimlerini değiştirmek için bir alana ilham verdi. “Önce düzen” yaklaşımından, dikkatimizi bir sayfadaki içeriğin HTML kullanılarak anlamsal olarak nasıl işaretlenmesi gerektiğine yönlendirdiler: Bir web sitesinin menüsü bir <table> değil, bir <nav> ; Bir başlık bir <b> değil, bir <h1> . Kullanıcıların içeriği bulmasına, tanımlamasına ve almasına yardımcı olmak için içeriğin web'in oynadığı farklı roller hakkında düşünmeye yönelik önemli bir adımdı.

Web Standartları hareketi, anlamsal biçimlendirmenin erişilebilirliği iyileştirdiği ve bunun da Google arama sonuçlarındaki sıralamasını iyileştirdiği argümanını ortaya koydu. Bu aynı zamanda web içeriği hakkındaki düşüncelerimizde de bir değişime işaret etti. Web siteniz artık içeriğinizin temsil edildiği tek yer değildi. Ayrıca, web sayfalarınızın arama sonuçları veya ekran okuyucular gibi diğer görsel bağlamlarda nasıl sunulduğunu da düşünmeniz gerekiyordu. Bu daha sonra sosyal medya ve paylaşılan bağlantıların gömülü önizlemeleri tarafından desteklendi. Zihniyet, içeriğin nasıl görünmesi gerektiğinden, ne anlama gelmesi gerektiğine doğru değişti. Bu aynı zamanda yapılandırılmış içerikle çalışmanın anahtarıdır.

İnternete bağlı cep boyutunda cihazların benimsenmesiyle birlikte, web birdenbire uygulamalarda ciddi bir rakip haline geldi. Ancak rekabet, çoğunlukla son kullanıcının gözbebekleri içindi. Pek çok kuruluş, ürünleri ve hizmetleriyle ilgili bilgileri hem uygulamalarında hem de farklı web ortamlarında hâlâ dağıtmaya ihtiyaç duyuyordu. Aynı zamanda, web olgunlaştı ve JavaScript ile AJAX, API'ler aracılığıyla farklı içerik kaynaklarını birbirine bağlamayı kolaylaştırdı. Bugün, içerik getirmeyi ve durum yönetimini daha basit hale getiren GraphQL ve araçlara sahibiz. Ve böylece teknolojik bulmacanın parçaları yerine oturmaya başlar.

“Bir Kez Oluşturun, Her Yerde Yayınlayın”

Çoğunlukla “teknolojik bir değişim” olarak tanımlansa da, içeriğin JSON yüklerine yerleştirilmesi (HTTP tüpleri boyunca seyahat), dijital içerik ve çevreleyen iş akışları hakkında nasıl düşündüğümüz üzerinde çok büyük bir etkiye sahiptir. Bazı yönlerden, zaten var. Neredeyse on yıl önce, Ulusal Halk Radyosu'nun (NPR) konuğu Daniel Jacobson, programmableweb.com'da yaklaşımları hakkında bir blog yazısı yazdı ve bu, “Bir Kez Oluştur, Her Yerde Yayınla” anlamına gelen COPE kısaltmasında özetlendi. Makalede, o zamanlar (ve muhtemelen şimdi) çoğu CMS'nin yaptığı gibi, bir HTML işleme makinesi aracılığıyla değil, bir API aracılığıyla birden çok dijital arabirime içerik sağlayan bir içerik yönetim sistemi tanıtıyor.

NPR'nin COPE “veri yönetimi katmanı”, “başsız bir CMS” kavramı haline gelecek olan şeydir. COPE'nin ilk günlerinde, içeriğin XML'de yapılandırılmasıyla elde edildi. Günümüzde JSON, nesnelerin interneti cihazları ve web dışındaki diğer sistemler de dahil olmak üzere API'ler üzerinden veri aktarımı için baskın veri formatı haline geldi. Sohbet robotları, sesli arayüzler ve hatta görsel prototipleme için yazılımlarla içerik alışverişi yapmak istiyorsanız, HTTP'yi genellikle JSON aksanıyla konuşursunuz.

“Çözme” Terimi “Başsız CMS”

Google Trends'e göre, "başsız CMS" aramaları 2015'in sonlarında, yani NPR'nin COPE makalesinden altı yıl sonra popülerlik kazandı. "Başsız" terimi (en azından dijital teknolojiyle ilgili olarak ve 18. yüzyılın sonlarındaki Fransız aristokrasisiyle ilgili olarak), bir grafik kullanıcı arabirimi olmadan çalışan sistemlerden bahsetmek için uzun bir süredir kullanılmaktadır.

Not : Bir komut satırı arabiriminin, sunuculardaki veya test ortamlarındaki yazılımlar gibi gerçekten “grafiksel” olduğu iddia edilebilir (ancak bunu başka bir makaleye saklayalım).

Bu yeni CMS'leri “başsız” olarak adlandıran iki kafalıyım. Onlara "polisefali" de diyebiliriz - birçok kafası olan şey. Onlar CMS'lerin Hydras ve Cerbeuse'larıdır. “Başsız” aynı zamanda bu sistemleri, gerçek güçleriyle tanımlamak yerine, sahip olmadıkları yeteneklerle (yani, web sayfalarını oluşturmak için bir şablon motoru) tanımlıyor: içeriği web'in kısıtlamaları olmadan yapılandırmayı mümkün kılıyor. Bununla birlikte, bugün itibariyle bu kategorideki çözümlerin çoğuna “Neredeyse Kafasız Nick” de denilebilir. Çünkü düzenleme arayüzü hala sisteme sıkı sıkıya bağlı. “Başsızlıkları”, bir şablonlama motorunun, yani içerikten biçimlendirme üreten makinelerin eksikliğinden kaynaklanmaktadır.

Not : Neredeyse kesinlikle "Mimsy-Porpington" (Harry Potter evreninden bilinir) adlı bir CMS kullanırdım.

Bunun yerine, içeriği bir API aracılığıyla kullanılabilir hale getirirler, böylece bu içeriği nasıl, ne ve nerede görüntülemek ve kullanmak istediğiniz konusunda size daha fazla esneklik sağlarlar. Bu onları React, Angular ve Vue gibi popüler JavaScript ön uç çerçeveleriyle mükemmel bir arkadaş yapar. Ve “web sitelerine, uygulamalara ve cihazlara” içerik sunma iddiasına rağmen, çoğu hala web içeriğinin nasıl çalıştığıyla sınırlıdır. Bu, çoğu zengin metni işleme biçiminde en belirgindir - onu HTML veya Markdown olarak depolamak.

Geleneksel CMS'ler, şablon oluşturma sistemlerine ek olarak biraz genel API'ler eklemeye başladı ve kendilerini yeni rakiplerinden ayırmanın bir yolu olarak buna "ayrışmış" diyorlar. "Bütün bunlar ve API'ler de!"* iddiasıdır. Bu CMS'lerden bazıları, içerik modelleme söz konusu olduğunda oldukça agnostiktir. Örneğin Craft CMS, ilk kurduğunuzda içerik modeliniz hakkında neredeyse hiçbir varsayımda bulunmaz. Wordpress ayrıca içerik teslimi için API'leri kullanmaya doğru ilerliyor. CMS alanındaki eski oyuncularla yeni oyuncular arasındaki farkın biz ilerledikçe daralacağını düşünüyorum.

Bununla birlikte, içerik yönetimini (HTML oluşturucu yerine) API'lerin arkasına koymak, bir kuruluşun metinlerinin, resimlerinin, videolarının ve medyasının dijitalleştirildiği ve dahili ve harici kullanıcılara ve müşterilere maruz kaldığı bir çağda daha karmaşık çalışma yöntemleri için önemli bir adımdır. Yine de, eksik ön uç oluşturma yeteneklerini tanımlamaktan, bizim için gerçekten yapabileceklerine geçmenin zamanı geldi: bize yapılandırılmış içerikle çalışmak için bir yol verin . Peki bunlara “Yapılandırılmış İçerik Yönetim Sistemleri” mi demeliyiz? "Hayır Bob, bu her zamanki CMS'niz değil. Bu bir SCMS, güven bana, bir şey olacak.”

Başlıklarla İlgili Değil, Yapılandırılmış İçerikle İlgili

Yapılandırılmış İçerik Yönetim Sistemlerinin (SCMS) dayattığı en radikal değişiklik, içeriği bir sayfa hiyerarşisine göre düzenlemekten, içeriği uygun gördüğünüz herhangi bir amaç için yapılandırmakta özgür olduğunuz bir yere geçiştir. Yinelenen içerikten kaçınmak, güvenilirliği artırdığı ve yönetim yükünü azalttığı için açık bir avantajdır (birden çok kanalda yinelenen içerikle uğraşmak zorunda kalmazsınız). Başka bir deyişle: Bir Kez Oluşturun, Her Yerde Yayınlayın . Ürün açıklamanızı tek bir sistemde bir kez güncellemeniz gerekiyorsa ve bu, ürününüz kullanıcıya maruz kaldığı her yerde güncellenirse, bu açıkça bir avantajdır.

SCMS satıcıları, sayfa yapısında farklı düşünmeyi haklı çıkarmak için sıklıkla “web sitenizi ve bir uygulamanızı” kullanırken, yapılandırılmış bir içerik yapısından fayda sağlamak için nehri geçmeniz gerekmez. JavaScript çerçevelerinin popülaritesi ile birlikte, duruma ve bağlama bağlı olarak farklı içeriklerle "doldurulabilen" bireysel bileşenlerin bir bileşimi olarak web siteleri oluşturmak giderek daha yaygın hale geldi. Web uygulamanız boyunca birçok farklı bağlamda görünen bir ürün kartınız olabilir. Modern web geliştirmenin, belgeleri ve sayfaları ayarlamaktan, kullanıcı girdisi, algoritmalar ve özelleştirme karışımına göre bileşenleri oluşturmaya geçtiğini görüyoruz.

Tasarım sistemlerinin nasıl yapıldığına ve test etme, öğrenme ve yineleme süreçleri aracılığıyla ekipler halinde çalışmaya nasıl teşvik edildiğimize ilişkin bu eğilimler, içerik yönetimi alanını bazı yeni düşünme yolları için olgunlaştırıyor. Bazı modeller ortaya çıktı, ancak daha gidecek çok yolumuz var. Bu nedenle, içeriği öne ve merkeze koyan ve şimdi bunun için bir hizmet oluşturan bir ekibin parçası olarak (ve burada herhangi bir önyargının farkında olmanızı rica ediyorum), ekiplerde ve projelerde çalışma deneyimime dayanarak, şunu yapmak istiyorum: yardımcı olabileceğine inandığım bazı stratejiler ortaya koyun ve daha fazla tartışma için noktalar yaratın.

1. Çok Disiplinli Takımlarda İçeriğe Yaklaşım

Bir grafik tasarımcının, sorumluluğu tasarımı "uygulamak" olan bir ön uç geliştiriciye eski, piksel mükemmelliğindeki sayfaları teslim etmesinin geçmişte kaldığına inanıyorum. Artık, kutudan çıkar çıkmaz birden fazla olası durumla gelen bileşimlerde ortaya konan daha küçük bileşenlerden oluşan tasarım sistemleri yapıyoruz. Çoğu zaman, bu bileşenlerin kullanıcı tarafından oluşturulan girdilere karşı dayanıklı olması gerekir; bu, canlı içeriği sürece ne kadar erken dahil ederseniz o kadar iyi demektir. Bir ön uç geliştiricinin sorumluluğu, bir grafik tasarımcının vizyonunu yeniden oluşturmak değildir ; tarayıcıların HTML, CSS ve JavaScript'i nasıl oluşturduğuna dair karmaşık bir alanda manevra yaparak kullanıcı arayüzlerinin duyarlı, erişilebilir ve performanslı olduğundan emin olmaktır.

Netlife'da (kullanıcı deneyimi konusunda uzmanlaşmış bir danışmanlık) teknoloji danışmanı olarak çalışırken, geliştiriciler, tasarımcılar ve kullanıcı araştırmacıları arasında işbirliğine yönelik büyük adımlar atıldığını gördüm. İçerik editörlerimiz en başından beri projeye dahil olsalar da, katkıları esas olarak teknik sürtüşme nedeniyle tasarım iş akışına girmedi.

Darboğaz genellikle dokunamadığımız eski bir CMS'ydi veya tasarım düzenine bağlı olduğu için içerik yapısını oluşturmanın zaman almasıydı. Bu genellikle işin iki katına çıkmasına neden oldu: Genellikle Markdown dosyalarından ayrıştırılan içeriğe dayalı bir HTML prototipi yaptık, bu, kullanıcı testi tamamlandığında CMS yığınında yeniden uygulanması gerekiyordu ve herkes piksel kadar mutluydu. . CMS'deki sınırlamalar, sürecin sonlarında keşfedildiğinden, bu genellikle pahalı bir süreçti. Ayrıca tüm parçalar üzerinde "ilk seferde doğru yapmak" için baskı yaratır ve bir tasarım projesinde isteyeceğiniz türden deneyler için daha az alan bırakır.

Çok Disiplinli Çalışma Çevik Sistemler Gerektirir

Bir içerik modelini (alanların ve API'nin anında hazır olduğu) kodlamanın dakikalar aldığı bir SCMS'ye geçmek, sürecimizi alt üst etti - ve daha iyisi için. Projenin ilk günlerinde yeni u4.no'nun içerik editörüyle oturduğumu hatırlıyorum. Nasıl çalıştıkları ve içerikleriyle çalışmak istedikleri hakkında konuşmak. Oldukça hızlı bir şekilde, sonuçlarımızı tarayıcıda anında bir düzenleme ortamına dönüştürülen basit JavaScript nesnelerine çevirdik. Başlıklar için faydalı başlıklar ve açıklamalar bulmak. Farklı sayfalarda ve bağlamlarda yeniden kullanabilecekleri, kurum içinde "nuggets" adını verdikleri ve daha sonra orada oluşturduğumuz metin parçacıklarını nasıl istedikleri hakkında konuştuk.

Arayüz önümüzde yapılırken bir içerik editörü ve bir geliştirici birlikte konuşurken bu tür bir araştırmaya proje geliştirmenin başlarında izin vermek güçlü hissettirdi. O ve meslektaşları içerik üzerinde çalışmaya başlarken, React'te ön ucu tasarlamaya devam edebileceğimizi bilerek. Ve yapının ön uç kısmını nasıl kodlamanız gerektiğiyle sıkı bir şekilde birleştiği CMS'lerde sık sık yaptığımız gibi, kendimizi bir köşeye boyamaktan endişe etmiyoruz.

Bir İçerik Sistemi Deneme ve Yinelemeye İzin Vermelidir

Yaratıcı yeniden tasarım projeleri bir yana, yapılandırılmış içerik için bir sistem, tüm tasarım sisteminizin bir parçası olarak içeriğinizi geliştirmeye, test etmeye ve yinelemeye devam etmenize de izin vermelidir. UX tasarımcıları, Sketch veya Framer X gibi araçları kullanarak gerçek içerikle hızlı bir şekilde prototip oluşturabilmelidir. İçerik yönetimini, ister okunabilirlik ölçekleri, isterse içeriğin kullanıldığı yerde nasıl performans gösterdiği gibi nicel ölçümlerle zenginleştirebilmelisiniz.

Not : Hepimizin - bir şekilde - iyi kullanıcı deneyimleri oluşturma süreciyle ilgili olması gerektiği fikrine rağmen, yukarıda "UX tasarımcıları" terimini kullandım. Hepimiz farklı tasarım dizilerimizde UX tasarımcılarıyız.

Yapılandırılmış içerikle çalışmak, içeriği doğrudan web sayfası düzeninizde yalnızca WYSIWYG-ing'e alışkınsanız, biraz alışmayı gerektirir. Yine de, dijital tasarım alanının nasıl hareket ettiği ile daha uyumlu bir sohbete izin veriyor. Yapılandırılmış içerik, tasarımcılardan, geliştiricilerden, içerik editörlerinden, kullanıcı araştırmacılarından ve proje yöneticilerinden oluşan bir ekibin, kullanıcıların ihtiyaçlarını ve stratejik hedeflerini desteklemek için bir sistemin nasıl çalışması gerektiği konusunda topluca düşünmesini sağlar. Bu aynı zamanda içeriğin nasıl yapılandırıldığı konusunda farklı düşünmenizi gerektirir ve bu da bizi bir sonraki stratejiye götürür.

2. Bir Gagalama Sırasına İhtiyacınız Olmayabilir

Birçoğu için en dikkate değer değişikliklerden biri, yapılandırılmış içerik sistemlerinin, web sitesi gezinme yapılarını yansıtan klasör benzeri hiyerarşilere değil, koleksiyonlara ve belge listelerine yönelik olmasıdır. Bu yapılar, içeriğin bir kısmı başka bağlamlarda (chatbotlar, yazılı medya veya diğer web siteleri) kullanılacağı anda anlam kazanmayı bırakır. Geleneksel CMS'ler, yeniden kullanılabilir içerik bloklarına izin vererek bunu hafifletmeye çalıştı, ancak yine de sayfa düzenlerine yerleştirilmeleri gerekiyor ve API'ler aracılığıyla akıl yürütme zahmetli.

Her Sayfa Kendi Kendine

Temel Model'de belirtildiği gibi, ana referanslarınızdan biri Google veya sosyal medyada paylaşım olduğunda, her sayfayı bir açılış sayfası olarak görmelisiniz. Sayfa görüntülemelerinin dağılımına bakarsanız, bazı sayfalarınızın diğerlerinden çok daha popüler olduğunu fark edeceksiniz. Bir haber sitesi değilseniz, bunlar genellikle haber değil, kullanıcının web sitenizde elde etmeyi umdukları her şeyi başarmasına izin verenlerdir. Onlar işin gerçekte gerçekleştiği yerdir.

Dijital içeriğiniz, kendi stratejik hedeflerinizin ve kullanıcılarınızın bireysel hedeflerinin kesişimine hizmet etmelidir. Dijital ajans Bengler (sanity.io'nun öncülü) oma.eu için yeni web sitesini yaptığında, içeriği ayrıntılı bir sayfa hiyerarşisinden sonra yapılandırmadılar. Projelerden , kişilerden ve yayınlardan sonra, örgütsel günlük gerçekliği yansıtan içerik türleri yaptılar. Aslında, OMA-web sitesi, içerik hiyerarşisi açısından neredeyse tamamen düzdür ve ön sayfa, algoritmik ve editoryal kuralların bir karışımından oluşturulur.

Peki, nasıl gidilir? İçeriğiniz hakkında, kuruluşunuzun zihinsel modelinin nasıl bir yansıması olduğunu ve kullanıcılarınızın neye ihtiyacı olursa olsun yararlı olması için neye ihtiyaç duyduğunu düşünmenin bir karışımına inanıyorum.

İşte basit bir örnek: Bir çalışan sayfası oluştururken, muhtemelen person adlı bir içerik türüyle başlamalısınız. Bir kişinin adı, iletişim bilgileri, resmi, farklı organizasyonel rolleri ve kısa bir biyografisi olabilir. Bir kişi belgesi, kişi listelerinde, makale yazarı satır satırlarında, sohbet destek arayüzlerinde ve erişim rozetleri oluşturmada yeniden kullanılabilir. Belki de bu kişilerin kim olduğunu bilen ve bir API ile birlikte gelen bir şirket içi sisteminiz var mı? Harika, o zaman bununla senkronize et.

Ontolojik Tavşan Deliğinde Kaybolmayın

Google'ın web sayfalarını dizine ekleme yöntemine ve dünyadaki bilgileri nasıl dizine eklemeye çalıştıklarına dönmek yararlıdır. Bu nedenle bağlantılı verilere (RDFa, mikro biçim, JSON-LD) zaman ve emek harcıyorlar. Web sayfalarınıza JSON-LD öğeleriyle açıklama eklerseniz, arama sonuçlarında daha belirgin görünürsünüz. Bilgilerinizin sesli yardımcılar tarafından ne zaman söylenmesi ve bir yardımcı kullanıcı arayüzünde görüntülenmesi gerektiği de önemlidir. İçeriğiniz zaten yapılandırılmışsa ve bir API'de kolayca erişilebilir durumdaysa, onu bu mikro biçimlerde uygulamanız nispeten kolay olacaktır.

En azından editör amaçları için olmasa da, schema.org ontolojilerine ve çeşitli bağlantılı veri kaynaklarına girmeyi tavsiye edeceğimden emin değilim. Her şeyin uyduğu yerde mükemmel platonik yapılar oluşturmaya çalışırken bir tavşan deliğinde hızla kaybolabilirsiniz.

Newsflash : Asla olmayacak, çünkü dünya dağınık bir yer ve insanlar her şeyi farklı düşünüyorlar.

İçeriğinizi sezgisel mantıklı ve ihtiyaçlar değiştikçe uyarlanmaya müsait bir sistemde yapılandırmak daha önemlidir. Bu nedenle, tasarım ve geliştirme sürecinde içerik modellemeye erken başlamak önemlidir - nasıl kullanılması gerektiğini öğrenmeniz gerekir.

CMS Sözleşmelerinden Değil Gerçeklikten Özet

CMS'nizin beraberinde getirdiği kuralları takip etmek cazip gelebilir. Wordpress'in size nasıl "Mesajlar" ve "Sayfalar" vereceğini ve aniden her şeyin bu kutulara sığdırılması gerektiğini hatırlıyor musunuz? WYSIWYG zengin metin alanı, her şeyi eklemenize izin vermesi bakımından esnektir, ancak içerik yapılandırılmaz ve kolayca uyarlanamaz — yalnızca bir kez esnektir. Ancak bir içerik modelinin haritasını çıkarmaya başlamak için bir yere ihtiyacınız var. Benim önerim, insanlarla, yani yazarlar ve okuyucularla konuşarak başlamaktır.

İnsanlar içerik hakkında dahili olarak nasıl konuşur? İnsanlar farklı şeylere ne diyor? Etnograflar tarafından halk sınıflandırmalarını haritalamak için kullanılan bir yöntem olan ücretsiz listeleme alıştırması yapabilirsiniz. Örneğin, şunu sorabilirsiniz:

"Kuruluşumuzdaki farklı içerik türlerini adlandırın."

Veya daha spesifik bir düzeyde:

"Bu organizasyonda sahip olduğumuz farklı rapor türlerini adlandırabilir misiniz?"

Bu anketin amacı, insanların (genellikle tasarım süreçlerini rayından çıkarma eğiliminde olan) şeyler hakkındaki görüş ve hislerini değil, taşıdıkları içselleştirilmiş sınıflandırmaları ortaya çıkarmaktır. Üzerinde çalışabileceğiniz oldukça kapsamlı bir listeye sahip olmadan önce özellikle birçok kişiye sormanıza gerek yok. Muhtemelen listenizin bazı bölümlerinin mevcut CMS'nizdeki sözleşmelerden geldiğini göreceksiniz (biraz tadilat yapıp yapmayacağınızı bilmek güzel). Şimdi editörünüzle konuşmalı ve içeriğin ne yapması gerektiğini belirlemeye çalışmalısınız.

Sorabileceğiniz bazı sorular şunlar olabilir:

• Bu içeriği birden fazla yerde mi kullanmanız gerekiyor? Neresi?
• İçerik türleri arasındaki farklı ilişkiler nelerdir?
• İçeriğin bugün ve yarın nerede görüntülenmesine ihtiyacımız var?
• İçeriğin sıralanması için hangi yollarla ihtiyacımız var? Sıralama kullanıcı tarafından algoritmik olarak mı yapılabilir, yoksa manuel olarak mı yapılması gerekir?
• Diğer sistemlerde replikasyonu önlemek için senkronize edebileceğimiz sistemler veya veritabanları var mı?
• Standart içeriğin nerede yaşamasını istiyoruz? SCMS bunun kaynağı mı olmalı yoksa sadece mevcut içeriği, örneğin bir ürün yönetim sisteminde yaşayan ürünler için pazarlama kopyası mı eklemeli?

Bu, artık ılık olan banyo suyuyla geleneksel bilgi mimarisini çöpe atmanız gerektiği anlamına gelmez. Makaleler kuruluşunuzun içerik gerçekliğinin bir parçasıysa, içerik türü olarak makalelere sahip olmak yine de mantıklıdır. Ancak belki de soyut kategoriler kuralına gerçekten ihtiyacınız yoktur, çünkü bu makalelerin içlerinde hizmet veya ürün türüne nasıl atıfta bulunduğu. Ve bu ilişki, herhangi birinin iş tanımında “makale kategori yönetimi” olmasına gerek kalmadan, bu makalelerin mantıklı olduğu durumlarda sorgulanmasına olanak tanır.

Makale ayrıca içeriği sunum katmanından tamamen ayırmayı zorlaştıran şeydir. Makalenin düzenini ve stilini düşünmeye çok alışığız, ancak kendi içeriğinizi kendi alanınızda barındırmanızın ve ardından onu media.com gibi platformlara göndermenizin beklendiği bir çağda, zaten vazgeçmişsinizdir. görsel sunum üzerinde kontrol. Bu bizi bir sonraki stratejiye götürür.

3. Sunum Bağlamları Aynı zamanda İçerik Türleridir

Yeniden Tasarlamaya Hazır Olun

Tüm içerik mimarinizi yeniden oluşturmak veya klasör benzeri katı bir arayüze karşı savaşmak zorunda kalmadan web sitenizin gezinme yapısını da adapte edebilmek ve hızlı bir şekilde değiştirebilmek istiyorsunuz. Ayrıca bazı içerik hiyerarşisine sahip olmak istersiniz, çünkü bu bazen mantıklıdır ve bazen API öncelikli CMS'ler bölümündeki çoğu arabirimin fazla yardım sağlayamadığı iki düzeyden daha derine iner.

İlginç bir şekilde, sohbet robotları için içerik yönetim sistemleri, niyet ağaçlarını ve diyalog akışlarını düzenlemek için benzer hiyerarşik yapıları kullanma eğilimindedir. Bu, içerik hiyerarşilerinin farklı kanallarda farklı roller oynadığını, ancak genellikle içerikte gezinmenin yollarını sağladığını söylüyor. Buna yaklaşmanın bir yolu, içeriği referanslara göre düzenleyebileceğiniz ve web sayfaları, menüler veya konuşma arayüzleri için yollar oluşturabileceğiniz gezinme türleri oluşturmaktır.

İlişki tavsiyesi

Referanslar (veya ilişkiler), yapılandırılmış içerik için bir sistemi mümkün kılan şeydir ve web'deki içerik söz konusu olduğunda uğraştığımız her şeyin özüdür (ilk etapta mecazi olarak web olarak adlandırılmasının nedeni budur). İçerik parçaları arasında referanslar yapabilmek çok güçlü bir şeydir, ancak arka uçların bu tür verileri nasıl yazıp alabileceği açısından da maliyetli olabilir. Bu nedenle, çok sayıda belgeniz varsa, ölçek nadiren ücretsiz olduğu için farklı düşünmeniz gerekebilir.

Verileri birleştirmek için her zaman açık bir referansa ihtiyacınız olmadığını da dikkate almaya değer; çoğu zaman içerikle ilgili kriterlere göre yapılabilir, örneğin “bu coğrafi konumdaki tüm kişileri ve tüm binaları bana ver”. Her iki içerik türünde de bir konum alanında ima edildiği sürece, bina ve kişilerin birbirlerine açık bir referansı olması gerekmez.

Sunum türleri ve diğer içerik türleri arasındaki referanslar, verileri birleştirmek için onu sunum katmanındaki bir algoritmaya bırakamadığınızda kullanışlıdır. Bu sunum türlerini açıkça çizmek ve atıfta bulunulan içeriğin kompozisyonlarını yapmak biraz hantal görünebilir, ancak bu, SCMS'lerle sıklıkla karşılaşacağınız bir soruna çözümdür: İçeriğin nerede kullanıldığını bilmek zor. Gezinme türlerini dahil ederek, içeriği yalnızca bir sunuya değil, açıkça sunuya bağlayacaksınız. Bu, yol gösterdikleri içerikten bağımsız olarak seyir yapılarıyla çalışmayı akıl yürütmeyi mümkün kılar.

Örneğin, ekran görüntülerinde Google Experiments'ı rota türüne bağladık ve içeriğe referanslardan oluşan birden çok sayfa eklemeye izin verdik, bu da A/B testlerini neredeyse hiç içerik yinelemesi olmadan çalıştırabileceğimiz anlamına geliyor. Başka dökümanların referans gösterdiği içeriği silmeye çalıştığımızda da uyarı aldığımız için bu yapılanma, silmememiz gereken bir şeyi silmemizi engelleyecektir.

İçerik türleri arasındaki ilişkiler iki ucu keskin bir kılıçtır. Sürdürülebilirliği artırır ve tekrarı önlemenin anahtarıdır. Öte yandan, içerik arasında bağımlılık yaptığınız için kendinizi kolayca kesebilirsiniz, bu da (şeffaf yapılmadığı takdirde) verilerinizin görüntülendiği kanallarda istenmeyen değişikliklere neden olabilir. Örneğin, bir "rota" tarafından kullanılan bir "sayfayı" uyarı yapmadan kaldırabilseydik kötü olurdu.

Bu bizi bir sonraki stratejiye götürür; bu strateji, farklı sistemlerin nasıl yapılandırıldığıyla ilgili olduğu için bugün itibariyle normal kullanıcının gücünün kısmen ötesindedir. Yine de düşünmeye değer.

4. Zengin Metni Köşeye Koymayın

Zengin Metin HTML'den Daha Fazlasıdır

HTML'ye neden dijital içerikte bu kadar yaygınlık verildiğini anlayabiliyorum, ancak bunun bir şeyden geldiğini de biliyorum; bu, makine tarafından okunabilen belgeleri yapılandırmanın genelleştirilmiş bir yolu olan SGML'nin bir alt kümesidir. Claire L. Evans'ın "Geniş Bant: İnterneti Yaratan Kadınların Anlatılmamış Hikayesi" (2018) adlı harika kitabında belirttiği gibi, HTML tanıtıldığında bağlantılı belgeler hakkında düşünen canlı bir topluluk zaten vardı. Tim Berners-Lee'nin önerisi, o zamanlar diğer sistemlerden çok daha basitti, ancak muhtemelen bu yüzden yakalandı ve - şu an itibariyle - açık, ücretsiz web'i mümkün kıldı.

World Wide Web'de bir tarayıcıdayken, HTML harikadır. Basit HTML ile biten bir şey yayınlamak isteyen bir yazarsanız, Markdown harikadır. Zengin metin içeriğinizin tarayıcı olmayan bir şeye veya HTML'yi JavaScript ile karmaşık bileşenlerde artırmanıza izin veren popüler bir JavaScript çerçevesine kolayca entegre edilmesini istiyorsanız (evet, React ve Vue.js'den bahsediyoruz) , API yanıtlarınızda HTML olması biraz zor olmaya başlar - özellikle de onu ayrıştırmanız gerekiyorsa.

Hemen hemen herkes yapıyor, hatta bloktaki yeni çocuklar bile: headlesscms.org'daki tüm satıcıları inceledim ve belgelere göz attım ve ayrıca bundan bahsetmeyenler için kaydoldum. İki istisna dışında hepsi zengin metni ya HTML ya da Markdown olarak depoladı. Tek yapmanız gereken bir web sitesi oluşturmak için Jekyll'i kullanmaksa veya React'te desirelySetInnerHTML kullanmaktan hoşlanıyorsanız sorun değil. Peki ya içeriğinizi web'de olmayan arayüzlerde yeniden kullanmak isterseniz? Veya zengin metin düzenleyicinizde daha fazla kontrol ve işlevsellik istiyorsanız? Veya zengin metninizi popüler ön uç çerçevelerinden birinde oluşturmanın daha kolay olmasını ve bileşenlerinizin zengin metin içeriğinizin farklı bölümleriyle ilgilenmesini mi istiyorsunuz? Peki, ya bu işaretlemeyi ya da HTML'yi ihtiyacınız olan şeye ayrıştırmak için akıllı bir yol bulmanız ya da daha uygun bir şekilde, ilk etapta daha mantıklı bir şekilde saklamanız gerekecek.

Örneğin, zengin metninizin çıktısını bir ses arayüzüne vermek isterseniz ne olur? Sesli asistanların popülaritesinin arttığını biliyoruz. Bu asistanlar için en popüler platformlar, API'ler aracılığıyla sözlü içerik için metin alma yeteneklerine sahiptir. O zaman Konuşma Sentezi İşaretleme Dili gibi bir şeyden yararlanmak istersiniz. Taşınabilir metin sistemi, zengin metne daha agnostik bir yaklaşım benimser; bu, aynı içeriği farklı arabirim türleri için uyarlamanıza olanak tanır.

Önerilen okuma : SpeechSynthesis Arayüzü ile Denemeler Yapmak

Agnostik Zengin Metin Modeli Olarak Taşınabilir Metin

Taşınabilir metin, öncelikli olarak web için içerik hazırlarken de kullanışlıdır. Metninizi zengin metin dipnotu veya satır içi editoryal yorum gibi veri yapılarıyla iç içe yerleştirme ve artırma olanağına sahip olmak istiyorsanız ne olur? Veya A/B testi durumları için alternatif bir ifade veya ifade? Markdown ve HTML hızla yetersiz kalıyor ve Wordpress'in çözdüğü gibi özel kısa kod etiketleri gibi bir şey eklemeye güvenmeniz gerekecek. With portable text, you have an agnostic representation of content structures, without having to marry a certain implementation. 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.