Strategi Untuk Proyek Tanpa Kepala Dengan Sistem Manajemen Konten Terstruktur

Ini adalah panduan yang saya harap saya miliki beberapa tahun terakhir ketika menjalankan proyek dengan Sistem Manajemen Konten (CMS) tanpa kepala. Saya telah menjadi pengembang, pengalaman pengguna dan konsultan teknologi, manajer proyek, arsitek informasi, dan penulis. Topi yang berbeda telah membuat saya menyadari bahwa meskipun kita telah memiliki apa yang disebut CMS "tanpa kepala" untuk sementara waktu sekarang, masih ada cara untuk memikirkan cara terbaik untuk menggunakannya.

Kita sekarang berada di tempat di mana banyak dari kita mengandalkan kerangka kerja JavaScript untuk pekerjaan frontend, menggunakan sistem desain yang terbuat dari komponen dan komposisi, daripada hanya menerapkan tata letak halaman datar. Ada banyak daya tarik terhadap JAMstacks dan aplikasi isomorfik/universal yang berjalan di server dan klien. Bagian terakhir dari teka-teki adalah bagaimana kita mengelola semua konten.

CMS tradisional menambahkan API untuk menyajikan konten melalui permintaan jaringan dan format JSON. Selain itu, CMS "tanpa kepala" telah muncul untuk menyajikan konten secara eksklusif melalui API. Argumen saya dalam artikel ini, adalah bahwa kita harus menghabiskan lebih sedikit waktu untuk berbicara tentang "tanpa kepala", dan lebih banyak tentang "konten terstruktur" . Karena itulah kualitas penting dari sistem ini. Ada banyak implikasi untuk keahlian kami yang tersirat oleh sistem ini, dan kami masih memiliki cara untuk mencari tahu pola yang baik tentang bagaimana kami harus menangani teknologi ini.

Datang ke konsultasi teknologi dari latar belakang humaniora, saya telah belajar banyak tentang cara mengatur dan bekerja dengan proyek web yang mengambil pendekatan konten-sentris — baik dengan berbasis API yang lebih baru maupun CMS tradisional. Saya mulai menghargai bagaimana memulai lebih awal dengan konten langsung yang sebenarnya dari CMS; melakukannya dalam pengaturan lintas disiplin tidak hanya memungkinkan untuk mengungkap kompleksitas pada tahap awal tetapi juga meminjamkan agensi kepada semua orang yang terlibat, dan memberikan kesempatan untuk merenungkan tantangan dan kemungkinan teknologi dan desain dalam arti luas.

Dalam artikel ini, saya akan menyarankan beberapa strategi menyeluruh, dengan beberapa contoh nyata dan nyata tentang cara berpikir tentang bekerja dengan konten terstruktur. Pada saat penulisan, saya baru saja mulai bekerja untuk perusahaan SaaS yang menyediakan layanan manajemen konten semacam itu, untuk menghosting konten yang dikirimkan melalui API. Saya akan membuat referensi untuk itu, baik karena pengalaman masa lalu saya dengannya dalam proyek-proyek yang saya ikuti sebagai konsultan, tetapi juga karena saya pikir itu dengan tepat menggambarkan poin yang ingin saya buat. Jadi anggap ini semacam disclaimer.

Karena itu, saya telah berpikir untuk menulis artikel ini selama beberapa tahun, dan saya telah berusaha untuk membuatnya berlaku untuk platform apa pun yang Anda pilih. Jadi tanpa basa-basi lagi, mari kita melompat dua puluh tahun ke belakang untuk lebih memahami di mana kita berada hari ini.

Langkah Pertama Dengan Standar Web

Pada awal 2000-an, gerakan Standar Web mengilhami bidang untuk mengubah cara kerja mereka. Dari pendekatan “layout-first”, mereka mengarahkan perhatian kita pada bagaimana konten pada halaman harus ditandai secara semantik menggunakan HTML: Menu situs web bukanlah <table> , melainkan <nav> ; Judul bukanlah <b> , melainkan <h1> . Itu adalah langkah signifikan menuju pemikiran tentang berbagai peran yang dimainkan konten web untuk membantu pengguna menemukan, mengidentifikasi, dan menerimanya.

Gerakan Standar Web memperkenalkan argumen bahwa markup semantik meningkatkan aksesibilitas, yang juga meningkatkan peringkatnya dalam hasil pencarian Google. Ini juga menandai perubahan dalam cara kami berpikir tentang konten web . Situs web Anda bukan lagi satu- satunya tempat konten Anda ditampilkan. Anda juga harus memikirkan bagaimana halaman web Anda disajikan dalam konteks visual lain, seperti dalam hasil pencarian atau pembaca layar. Ini kemudian didorong oleh media sosial dan pratinjau tautan bersama yang disematkan. Pola pikir bergeser dari bagaimana konten seharusnya terlihat , menjadi apa artinya . Ini juga merupakan kunci untuk bekerja dengan konten terstruktur.

Dengan adopsi perangkat berukuran saku yang terhubung ke Internet, web tiba-tiba menjadi pesaing serius dalam aplikasi. Kompetisi, bagaimanapun, sebagian besar untuk bola mata pengguna akhir. Banyak organisasi masih perlu mendistribusikan informasi tentang produk dan layanan mereka di aplikasi dan keberadaan web mereka yang berbeda. Secara bersamaan, web menjadi matang, dan JavaScript serta AJAX memudahkan untuk menghubungkan berbagai sumber konten melalui API. Hari ini, kami memiliki GraphQL dan alat yang membuat pengambilan konten dan pengelolaan status menjadi lebih sederhana. Dan potongan-potongan teka-teki teknologi mulai jatuh ke tempatnya.

“Buat Sekali, Publikasikan Di Mana Saja”

Meskipun sebagian besar digambarkan sebagai "pergeseran teknologi", penyematan konten dalam muatan JSON (bepergian di sepanjang tabung HTTP) memiliki dampak yang sangat besar terhadap cara kita berpikir tentang konten digital dan alur kerja di sekitarnya. Dalam beberapa hal, itu sudah. Hampir sepuluh tahun yang lalu, tamu National Public Radio (NPR) Daniel Jacobson membuat blog di programmableweb.com tentang pendekatan mereka, diringkas dalam akronim COPE yang merupakan singkatan dari “Create Once, Publish Everywhere”. Dalam artikel tersebut, ia memperkenalkan sistem manajemen konten yang menyediakan konten ke beberapa antarmuka digital melalui API — bukan melalui mesin rendering HTML — seperti yang dilakukan kebanyakan CMS saat itu (dan bisa dibilang sekarang).

"Lapisan manajemen data" COPE NPR adalah apa yang akan menjadi gagasan "CMS tanpa kepala". Pada hari-hari awal COPE, itu dicapai dengan menyusun konten dalam XML. Saat ini, JSON telah menjadi format data yang dominan untuk mentransfer data melalui API, termasuk perangkat internet of things, dan sistem lain di luar web. Jika Anda ingin bertukar konten dengan chatbots, antarmuka suara, dan bahkan perangkat lunak untuk prototipe visual, Anda sangat sering berbicara HTTP dengan aksen JSON.

“Melepaskan” Istilah “CMS Tanpa Kepala”

Menurut Google Trends, pencarian untuk "CMS tanpa kepala" mendapatkan popularitas hingga akhir tahun 2015, yaitu enam tahun setelah artikel COPE NPR. Istilah "tanpa kepala" (setidaknya dalam kaitannya dengan teknologi digital dan bukan aristokrasi Prancis akhir abad ke-18), telah digunakan lebih lama untuk berbicara tentang sistem yang berjalan tanpa antarmuka pengguna grafis.

Catatan : Orang dapat berargumen bahwa antarmuka baris perintah memang "grafis" seperti perangkat lunak di server atau lingkungan pengujian (tapi mari kita simpan itu untuk artikel lain).

Saya berpikiran dua menyebut CMS baru ini "tanpa kepala". Kita juga bisa menyebut mereka "polycephalic" — yang memiliki banyak kepala. Mereka adalah Hydra dan Cerbeuses dari CMS. "Headless" juga mendefinisikan sistem ini berdasarkan kemampuan yang tidak dimiliki (yaitu, mesin template untuk merender halaman web), alih-alih mendefinisikannya berdasarkan kekuatan sebenarnya: memungkinkan untuk menyusun konten tanpa batasan web. Meskipun demikian, mulai hari ini, banyak solusi dalam kategori ini juga dapat disebut "Nick Hampir Tanpa Kepala". Karena antarmuka pengeditan masih terikat erat dengan sistem. "Tanpa kepala" mereka muncul dari kurangnya mesin templating, yaitu mesin yang menghasilkan markup dari konten.

Catatan : Saya hampir pasti akan menggunakan CMS yang disebut "Mimsy-Porpington" (dikenal dari dunia Harry Potter).

Sebaliknya, mereka membuat konten tersedia melalui API, sehingga memberi Anda lebih banyak fleksibilitas untuk bagaimana, apa, dan di mana Anda ingin menampilkan dan menggunakan konten ini. Ini menjadikan mereka teman yang sempurna untuk kerangka kerja frontend JavaScript populer seperti React, Angular, dan Vue. Dan meskipun klaim dapat mengirimkan konten ke “situs web, aplikasi, dan perangkat”, kebanyakan dari mereka masih dibatasi oleh cara kerja konten web. Ini paling terlihat dalam cara sebagian besar menangani teks kaya — menyimpannya sebagai HTML atau Penurunan harga.

CMS tradisional juga mulai menambahkan API yang agak generik selain sistem rendering template mereka dan menyebutnya "dipisahkan" sebagai cara untuk membedakan diri dari pesaing baru mereka. “Semua ini, dan juga API!”* adalah klaimnya. Beberapa CMS ini juga cukup agnostik dalam hal pemodelan konten. Misalnya, Craft CMS, hampir tidak membuat asumsi tentang model konten Anda saat pertama kali menginstalnya. Wordpress juga bergerak menuju penggunaan API untuk pengiriman konten. Saya menduga kesenjangan antara pemain lama di bidang CMS dan yang baru akan semakin sempit seiring berjalannya waktu.

Meskipun demikian, menempatkan manajemen konten di belakang API (bukan perender HTML) adalah langkah penting untuk cara kerja yang lebih canggih di zaman di mana teks, gambar, video, dan media organisasi didigitalkan dan diekspos ke pengguna dan pelanggan internal dan eksternal. Namun, inilah saatnya, untuk beralih dari mendefinisikan kemampuan rendering frontend mereka yang kurang, ke apa yang benar-benar dapat mereka lakukan untuk kami: beri kami cara untuk bekerja dengan konten terstruktur . Jadi, haruskah kita menyebutnya "Sistem Manajemen Konten Terstruktur"? Seperti dalam, “Tidak Bob, ini bukan CMS Anda yang biasa. Ini adalah SCMS, percayalah, ini akan menjadi sesuatu.”

Ini Bukan Tentang Kepala, Ini Tentang Konten Terstruktur

Perubahan paling radikal yang diterapkan oleh Sistem Manajemen Konten Terstruktur (SCMS) adalah beralih dari mengatur konten menurut hierarki halaman ke tempat Anda bebas menyusun konten untuk tujuan apa pun yang Anda inginkan. Menghindari duplikat konten jelas merupakan keuntungan karena meningkatkan keandalan dan mengurangi beban administratif (Anda tidak harus mengatasi konten duplikat di beberapa saluran). Dengan kata lain: Buat Sekali, Terbitkan Di Mana Saja . Jika Anda hanya perlu memperbarui deskripsi produk Anda sekali — dalam satu sistem — dan itu diperbarui di mana pun produk Anda ditampilkan kepada pengguna, itu jelas merupakan keuntungan.

Sementara vendor SCMS sering menggunakan "situs web dan aplikasi Anda" untuk membenarkan pemikiran yang berbeda tentang struktur halaman, Anda tidak perlu menyeberang sungai untuk mendapatkan manfaat dari struktur konten terstruktur. Dengan popularitas kerangka kerja JavaScript, semakin umum untuk membangun situs web sebagai komposisi komponen individual, yang dapat "diisi" dengan konten yang berbeda tergantung pada keadaan dan konteksnya. Anda mungkin memiliki kartu produk yang muncul dalam banyak konteks berbeda di seluruh aplikasi web Anda. Kami melihat bahwa pengembangan web modern beralih dari pengaturan dokumen dan halaman ke penyusunan komponen menurut campuran input pengguna, algoritme, dan penyesuaian.

Tren tentang bagaimana sistem desain dibuat, dan bagaimana kita didorong untuk bekerja dalam tim melalui proses pengujian, pembelajaran, dan iterasi, membuat bidang manajemen konten matang untuk beberapa cara berpikir baru. Beberapa pola telah muncul, tetapi kami masih memiliki banyak cara untuk ditempuh. Oleh karena itu, berdasarkan pengalaman saya dari bekerja dalam tim dan proyek yang telah menempatkan konten di depan dan di tengah, dan sebagai bagian dari tim yang membangun layanan untuk itu (dan saya mendorong Anda untuk mewaspadai bias apa pun di sini), saya ingin mengajukan beberapa strategi yang saya percaya dapat membantu dan menciptakan poin untuk diskusi lebih lanjut.

1. Pendekatan Konten Dalam Tim Multi-Disiplin

Saya percaya bahwa itu adalah masa lalu bahwa seorang desainer grafis dapat menyerahkan halaman basi, piksel-sempurna kepada pengembang frontend yang bertanggung jawab untuk "mengimplementasikan" desain. Kami sekarang membuat sistem desain yang terdiri dari komponen yang lebih kecil, ditata dalam komposisi yang datang dengan beberapa kemungkinan status di luar kotak. Lebih sering daripada tidak, komponen ini harus tahan terhadap input yang dibuat pengguna, yang berarti semakin cepat Anda memasukkan konten langsung ke dalam proses, semakin baik. Tanggung jawab pengembang frontend bukanlah untuk mereproduksi visi desainer grafis ; itu untuk mengarahkan bidang yang kompleks tentang bagaimana browser merender HTML, CSS, dan JavaScript, memastikan bahwa antarmuka pengguna responsif, dapat diakses, dan berkinerja.

Saat bekerja sebagai konsultan teknologi di Netlife (sebuah konsultan yang mengkhususkan diri dalam pengalaman pengguna), saya melihat langkah-langkah besar dibuat menuju kolaborasi antara pengembang, desainer, dan peneliti pengguna. Meskipun editor konten kami selalu terlibat dalam proyek sejak awal, kontribusi mereka tidak masuk ke alur kerja desain terutama karena gesekan teknis.

Hambatan sering kali merupakan CMS lama yang tidak dapat kami sentuh, atau perlu waktu untuk membangun struktur konten karena bergantung pada tata letak desain. Hal ini sering mengakibatkan pekerjaan menjadi berlipat ganda: Kami membuat prototipe HTML, sering kali didasarkan pada konten yang diurai dari file penurunan harga, yang harus diimplementasikan kembali dalam tumpukan CMS saat pengujian pengguna selesai, dan semua orang senang dengan piksel sempurna . Ini seringkali merupakan proses yang mahal karena keterbatasan dalam CMS ditemukan di akhir proses. Ini juga menciptakan tekanan pada semua bagian untuk "melakukannya dengan benar pertama kali" dan menyisakan lebih sedikit ruang untuk jenis eksperimen yang Anda inginkan dalam proyek desain.

Pekerjaan Multi-Disiplin Membutuhkan Sistem yang Cekatan

Pindah ke SCMS yang membutuhkan waktu beberapa menit untuk membuat kode model konten (di mana bidang dan API siap secara instan) membalikkan proses kami — dan menjadi lebih baik. Saya ingat duduk dengan editor konten u4.no baru di hari-hari pertama proyek. Berbicara tentang bagaimana mereka bekerja dan ingin bekerja dengan konten mereka. Agak cepat, kami menerjemahkan kesimpulan kami menjadi objek JavaScript sederhana yang langsung diubah menjadi lingkungan pengeditan di browser. Mencari tahu judul dan deskripsi yang bermanfaat untuk judul tersebut. Kami berbicara tentang bagaimana mereka menginginkan cuplikan teks yang dapat mereka gunakan kembali di berbagai halaman dan konteks, yang secara internal mereka sebut "nugget", yang kemudian kami buat saat itu juga.

Mengizinkan eksplorasi semacam ini di awal pengembangan proyek — editor konten dan pengembang berbicara bersama saat antarmuka dibuat di depan kami — terasa kuat. Mengetahui bahwa kami dapat terus mendesain frontend di React sementara dia dan rekan-rekannya mulai mengerjakan konten. Dan tidak perlu khawatir tentang mengecat diri kita ke sudut, seperti yang sering kita lakukan dengan CMS di mana strukturnya digabungkan dengan erat dengan bagaimana Anda harus mengkodekan bagian frontendnya.

Sistem Konten Harus Memungkinkan Eksperimen Dan Iterasi

Selain proyek desain ulang yang kreatif, sistem untuk konten terstruktur juga harus memungkinkan Anda untuk terus meningkatkan, menguji, dan mengulangi konten Anda sebagai bagian dari keseluruhan sistem desain Anda. Desainer UX harus dapat membuat prototipe dengan cepat dengan konten nyata menggunakan alat seperti Sketch atau Framer X. Anda harus dapat meningkatkan manajemen konten dengan pengukuran kuantitatif, baik itu skala keterbacaan atau bagaimana kinerja konten di tempat yang digunakan.

Catatan : Saya menggunakan istilah “desainer UX” di atas meskipun berpendapat bahwa kita semua harus — dalam beberapa hal — berhubungan dengan proses membuat pengalaman pengguna yang baik. Kita semua adalah desainer UX dalam untaian desain yang berbeda.

Bekerja dengan konten terstruktur memerlukan sedikit pembiasaan jika Anda terbiasa hanya dengan konten WYSIWYG langsung di tata letak halaman web Anda. Namun, itu cocok untuk percakapan yang lebih sejalan dengan bagaimana bidang desain digital bergerak. Konten terstruktur memungkinkan tim desainer, pengembang, editor konten, peneliti pengguna, dan manajer proyek secara kolektif berpikir tentang bagaimana sistem harus bekerja untuk mendukung kebutuhan pengguna dan tujuan strategis. Ini juga mengharuskan Anda untuk berpikir secara berbeda tentang bagaimana struktur konten, yang membawa kita ke strategi berikutnya.

2. Anda Mungkin Tidak Membutuhkan Pecking Order

Salah satu perubahan yang paling menonjol bagi banyak orang adalah bahwa sistem untuk konten terstruktur diarahkan pada koleksi dan daftar dokumen dan bukan hierarki seperti folder yang mencerminkan struktur navigasi situs web. Struktur ini berhenti masuk akal segera setelah beberapa konten digunakan dalam konteks lain — baik itu chatbot, media cetak, atau situs web lain. CMS tradisional telah mencoba untuk mengurangi ini dengan mengizinkan blok konten yang dapat digunakan kembali, tetapi mereka masih perlu ditempatkan pada tata letak halaman dan rumit untuk dipikirkan melalui API.

Setiap Halaman Untuk Sendiri

Seperti yang dijelaskan dalam The Core Model, ketika salah satu perujuk utama Anda adalah Google atau berbagi di media sosial, Anda harus menganggap setiap halaman sebagai halaman arahan. Dan jika Anda melihat distribusi tampilan halaman, Anda akan melihat bahwa beberapa halaman Anda jauh lebih populer daripada yang lain. Kecuali Anda adalah situs web berita, itu cenderung bukan berita, tetapi yang memungkinkan pengguna mencapai apa pun yang mereka harapkan untuk dicapai di situs web Anda. Mereka adalah tempat bisnis benar-benar terjadi.

Konten digital Anda harus melayani persimpangan tujuan strategis Anda sendiri dan tujuan individu pengguna Anda. Ketika agensi digital Bengler (pendahulu sanity.io) membuat situs web baru untuk oma.eu, mereka tidak menyusun konten setelah hierarki halaman yang rumit. Mereka membuat jenis konten yang mencerminkan realitas organisasi sehari-hari, yaitu setelah proyek , orang , dan publikasi . Faktanya, situs web OMA hampir sepenuhnya datar dalam hal hierarki konten, dan halaman depan dihasilkan dari campuran aturan algoritmik dan editorial.

Jadi, bagaimana cara melakukannya? Saya percaya campuran pemikiran tentang konten Anda sebagai cerminan dari bagaimana model mental organisasi Anda dan apa yang dibutuhkan agar berguna untuk apa pun yang dibutuhkan pengguna Anda.

Berikut ini contoh dasarnya: Saat membuat halaman karyawan, Anda mungkin harus memulai dengan tipe konten yang disebut person . Seseorang dapat memiliki nama, info kontak, gambar, peran organisasi yang berbeda, dan biografi singkat. Dokumen seseorang dapat digunakan kembali dalam daftar kontak, baris penulis artikel, antarmuka dukungan obrolan, dan lencana akses gedung. Mungkin Anda sudah memiliki sistem internal yang mengetahui siapa orang-orang ini dan yang dilengkapi dengan API? Bagus, lalu sinkronkan dengan itu.

Jangan Tersesat di Lubang Kelinci Ontologis

Ini berguna untuk kembali ke cara Google mengindeks halaman web dan bagaimana mereka mencoba mengindeks informasi dunia. Itu sebabnya mereka menghabiskan waktu dan tenaga untuk data yang ditautkan (RDFa, microformat, JSON-LD). Jika Anda membubuhi keterangan halaman web Anda dengan elemen JSON-LD, Anda akan tampil lebih menonjol di hasil pencarian. Ini juga relevan ketika informasi Anda harus diucapkan oleh asisten suara dan ditampilkan di UI asisten. Jika konten Anda sudah terstruktur dan mudah tersedia di API, Anda akan relatif mudah menerapkannya dalam format mikro ini.

Saya tidak yakin saya akan merekomendasikan untuk membahas semua ontologi schema.org dan berbagai sumber data yang ditautkan, setidaknya tidak untuk tujuan editor. Anda dapat dengan cepat tersesat dalam lubang kelinci mencoba membuat struktur platonis yang sempurna di mana semuanya cocok.

Newsflash : Tidak akan pernah, karena dunia adalah tempat yang berantakan, dan karena orang berpikir tentang sesuatu secara berbeda.

Lebih penting untuk menyusun konten Anda dalam sistem yang masuk akal secara intuitif dan cocok untuk diadaptasi saat kebutuhan berubah. Inilah mengapa penting untuk memulai dengan pemodelan konten sejak awal dalam proses desain dan pengembangan — Anda perlu mempelajari tentang bagaimana hal itu perlu digunakan.

Abstrak Dari Kenyataan, Bukan Dari Konvensi CMS

Anda mungkin tergoda untuk hanya mengikuti konvensi apa pun yang disertakan dengan CMS Anda. Ingat bagaimana Wordpress akan memberi Anda "Posting" dan "Halaman", dan tiba-tiba semuanya perlu dipasang ke dalam kotak itu? Bidang teks kaya WYSIWYG fleksibel karena memungkinkan Anda untuk memasukkan apa pun, tetapi kontennya tidak akan terstruktur dan mudah beradaptasi — itu hanya fleksibel sekali. Tetapi Anda memerlukan tempat untuk memulai pemetaan model konten Anda. Saran saya adalah mulai dengan berbicara dengan orang-orang, yaitu penulis dan pembaca.

Bagaimana orang membicarakan konten secara internal? Apa yang orang sebut hal yang berbeda? Anda bisa menjalankan latihan daftar bebas, metode yang digunakan oleh para etnografer untuk memetakan taksonomi rakyat. Misalnya, Anda dapat bertanya:

“Sebutkan berbagai jenis konten di organisasi kami.”

Atau, pada tingkat yang lebih spesifik:

“Bisakah Anda menyebutkan berbagai jenis laporan yang kami miliki di organisasi ini?”

Inti dari survei ini adalah untuk menghilangkan taksonomi yang diinternalisasikan orang, dan bukan pendapat atau perasaan mereka tentang sesuatu (sesuatu yang sering cenderung menggagalkan proses desain). Anda tidak perlu bertanya terlalu banyak sebelum memiliki daftar yang cukup lengkap yang dapat Anda gunakan. Anda mungkin akan menemukan bahwa bagian dari daftar Anda berasal dari konvensi di CMS Anda saat ini (itu bagus untuk mengetahui apakah Anda akan melakukan beberapa remodelling). Sekarang Anda harus berbicara dengan editor Anda dan mencoba untuk menentukan apa yang mereka butuhkan untuk konten tersebut .

Beberapa pertanyaan yang dapat Anda ajukan mungkin sebagai berikut:

• Apakah Anda perlu menggunakan konten ini di lebih dari satu tempat? Di mana?
• Apa perbedaan hubungan antara tipe konten?
• Di mana kita membutuhkan konten untuk ditampilkan hari ini, dan besok?
• Dengan cara apa kami membutuhkan konten untuk diurutkan? Apakah pemesanan bisa dilakukan secara algoritmik, oleh pengguna, atau harus manual?
• Apakah ada sistem atau database di sistem lain yang dapat kita sinkronkan untuk mencegah duplikasi?
• Di mana kita ingin konten kanonik ditayangkan? Haruskah SCMS menjadi sumbernya, atau hanya menambah konten yang ada, misalnya salinan pemasaran untuk produk yang hidup dalam sistem manajemen produk?

Ini tidak berarti bahwa Anda harus membuang arsitektur informasi tradisional dengan air mandi yang sekarang suam-suam kuku. Masih masuk akal untuk memiliki artikel sebagai tipe konten, jika artikel adalah bagian dari realitas konten organisasi Anda. Tetapi mungkin Anda tidak terlalu membutuhkan konvensi abstrak kategori , karena bagaimana artikel ini memiliki referensi ke jenis layanan atau produk di dalamnya. Dan hubungan ini memungkinkan untuk menanyakan artikel-artikel ini dalam keadaan yang masuk akal, tanpa mengharuskan seseorang untuk memiliki "manajemen kategori artikel" sebagai bagian dari deskripsi pekerjaan mereka.

Artikel ini juga yang membuat sulit untuk memisahkan konten sepenuhnya dari lapisan presentasi. Kami sangat terbiasa memikirkan tata letak dan gaya artikel, tetapi di zaman di mana Anda diharapkan untuk meng-host konten Anda sendiri di domain Anda sendiri, dan kemudian mensindikasikannya ke platform seperti medium.com, Anda sudah menyerah kontrol atas presentasi visual. Ini membawa kita ke strategi berikutnya.

3. Konteks Presentasi Juga Tipe Konten

Siap Desain Ulang

Anda ingin dapat beradaptasi dan dengan cepat mengubah struktur navigasi situs web Anda juga, tanpa harus membangun kembali seluruh arsitektur konten Anda atau melawan antarmuka seperti folder yang ketat. Anda juga ingin dapat memiliki beberapa hierarki konten, karena terkadang masuk akal, dan terkadang lebih dalam dari dua level, di mana sebagian besar antarmuka di departemen CMS pertama API gagal memberikan banyak bantuan.

Menariknya, sistem manajemen konten untuk chatbot cenderung menggunakan struktur hierarki yang serupa untuk mengatur pohon maksud dan alur dialog. Ini berarti bahwa hierarki konten memainkan peran yang berbeda di saluran yang berbeda, tetapi seringkali hierarki menyediakan cara untuk menavigasi konten. Cara untuk mendekati ini adalah dengan membuat tipe untuk navigasi, di mana Anda dapat mengatur konten dengan referensi, dan membangun rute untuk halaman web, menu, atau jalur untuk antarmuka percakapan.

Saran Hubungan

Referensi (atau hubungan) adalah apa yang membuat sistem untuk konten terstruktur menjadi mungkin, dan itu benar-benar inti dari semua yang kita hadapi ketika datang ke konten di web (itulah alasannya secara metaforis disebut web ). Untuk dapat membuat referensi antar bit konten adalah hal yang sangat kuat, tetapi juga bisa mahal dalam hal bagaimana backend dapat menulis dan mengambil data tersebut. Jadi Anda mungkin harus berpikir berbeda jika Anda memiliki banyak dokumen karena skala jarang datang secara gratis.

Perlu juga dipertimbangkan bahwa Anda tidak selalu memerlukan referensi eksplisit untuk menggabungkan data; paling sering dapat dilakukan dengan kriteria yang berkaitan dengan konten, misalnya "beri saya semua orang dan semua bangunan di dalam geolokasi ini". Bangunan dan orang tidak perlu memiliki referensi eksplisit satu sama lain, selama itu tersirat dalam bidang lokasi pada kedua tipe konten.

Referensi antara tipe presentasi dan tipe konten lainnya berguna saat Anda tidak dapat menyerahkannya pada algoritme di lapisan presentasi untuk menggabungkan data. Mungkin tampak agak rumit untuk secara eksplisit menggambar jenis presentasi ini dan membuat komposisi konten yang dirujuk, tetapi ini adalah solusi untuk masalah yang sering Anda temui dengan SCMS: Sulit untuk mengetahui di mana konten digunakan. Dengan menyertakan jenis navigasi, Anda akan secara eksplisit mengikat konten ke presentasi, tetapi tidak hanya satu. Ini memungkinkan alasan untuk bekerja dengan struktur navigasi secara independen dari konten yang mereka tuju.

Misalnya, di tangkapan layar kami telah mengikat Google Eksperimen ke jenis rute , memungkinkan untuk menambahkan beberapa halaman yang disusun oleh referensi ke konten, yang berarti bahwa kami dapat menjalankan pengujian A/B tanpa duplikasi konten. Karena kami juga mendapat peringatan jika kami mencoba menghapus konten yang direferensikan oleh dokumen lain, cara penataan ini akan mencegah kami menghapus sesuatu yang seharusnya tidak kami hapus.

Hubungan antar tipe konten adalah pedang bermata dua. Ini meningkatkan keberlanjutan dan merupakan kunci untuk menghindari duplikasi. Di sisi lain, Anda dapat dengan mudah memotong diri sendiri karena Anda membuat ketergantungan antar konten, yang (jika tidak dibuat transparan) dapat menyebabkan perubahan yang tidak diinginkan di seluruh saluran tempat data Anda ditampilkan. Misalnya, akan menjadi buruk jika kita dapat menghapus "halaman" yang digunakan oleh "rute" tanpa peringatan.

Ini membawa kita ke strategi berikutnya, yang (diberikan!) Sebagian di luar kekuatan pengguna normal pada hari ini karena berkaitan dengan bagaimana sistem yang berbeda dirancang. Tetap saja, itu layak untuk dipikirkan.

4. Jangan Letakkan Teks Kaya Di Pojok

Teks Kaya Lebih dari HTML

Saya bisa mengerti mengapa HTML diberikan prevalensi seperti itu dalam konten digital, tetapi tahu itu juga berasal dari sesuatu; ini adalah bagian dari SGML, cara umum untuk menyusun dokumen yang dapat dibaca mesin. Seperti yang ditunjukkan Claire L. Evans dalam buku yang luar biasa “Broad Band: Kisah Tak Terungkap dari Wanita yang Membuat Internet” (2018), sudah ada komunitas orang-orang yang berpikir tentang dokumen terkait ketika HTML diperkenalkan. Proposal Tim Berners-Lee jauh lebih sederhana daripada banyak sistem lain pada saat itu, tetapi mungkin itulah sebabnya mengapa hal itu berhasil dan memungkinkan — sampai sekarang — web yang terbuka dan gratis.

Saat Anda berada di browser di world wide web, HTML sangat bagus. Jika Anda seorang penulis yang ingin menerbitkan sesuatu yang berakhir dalam HTML sederhana, Penurunan harga sangat bagus. Jika Anda ingin konten teks kaya Anda dengan mudah diintegrasikan ke dalam sesuatu yang bukan browser, atau kerangka kerja JavaScript populer yang memungkinkan Anda menambahkan HTML dengan JavaScript dalam komponen kompleks (ya, kita berbicara tentang React dan Vue.js) , memiliki HTML dalam respons API Anda mulai sedikit merepotkan — terutama jika Anda perlu menguraikannya.

Hampir semua orang melakukannya, bahkan anak-anak baru di blok: Saya pergi ke semua vendor di headlesscms.org dan melihat-lihat dokumentasi, dan juga mendaftar untuk mereka yang tidak menyebutkannya. Dengan dua pengecualian, mereka semua menyimpan teks kaya baik sebagai HTML atau Penurunan harga. Tidak apa-apa jika yang Anda lakukan hanyalah menggunakan Jekyll untuk merender situs web, atau jika Anda menikmati menggunakan hazardlySetInnerHTML di React. Tetapi bagaimana jika Anda ingin menggunakan kembali konten Anda di antarmuka yang tidak ada di web? Atau jika Anda menginginkan lebih banyak kontrol dan fungsionalitas di editor teks kaya Anda? Atau hanya ingin lebih mudah merender teks kaya Anda di salah satu kerangka kerja frontend populer, dan meminta komponen Anda menangani berbagai bagian konten teks kaya Anda? Nah, Anda harus menemukan cara cerdas untuk menguraikan penurunan harga atau HTML itu ke dalam apa yang Anda butuhkan, atau, lebih mudahnya, simpan saja dulu dengan lebih masuk akal.

Misalnya, bagaimana jika Anda ingin menampilkan teks kaya Anda ke antarmuka suara? Kita tahu bahwa asisten suara semakin populer. Platform paling populer untuk asisten ini memiliki kemampuan untuk mendapatkan teks untuk konten lisan melalui API. Kemudian Anda ingin memanfaatkan sesuatu seperti Speech Synthesis Markup Language. Sistem untuk teks portabel mengambil pendekatan yang lebih agnostik untuk teks kaya, yang memungkinkan Anda mengadaptasi konten yang sama untuk berbagai jenis antarmuka.

Bacaan yang disarankan : Bereksperimen Dengan Antarmuka SpeechSynthesis

Teks Portabel Sebagai Model Teks Kaya Agnostik

Teks portabel juga berguna saat Anda melakukan konten untuk web. Bagaimana jika Anda ingin memiliki kemungkinan untuk menumpuk dan menambah teks Anda dengan struktur data, seperti catatan kaki teks kaya, atau komentar editorial sebaris? Atau frase atau kata-kata alternatif untuk kasus pengujian A/B? Penurunan harga dan HTML dengan cepat gagal, dan Anda harus bergantung pada penambahan sesuatu seperti tag kode pendek khusus, seperti yang telah diselesaikan oleh Wordpress. 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.