コンテンツ管理
避けるべき8つのコンテンツモデリングの落とし穴
By Ilesh Mistry
コンテンツをモデル化するときに何を考慮する必要がありますか?この記事では、MVPのIlesh Mistryが彼の経験を共有し、彼のトップ8のコンテンツモデリングの「落とし穴」について話します。
ヘッドレスCMSでの作業は、特に開発者の観点からは、約束の地と見なされることがよくあります。開発玩具ボックスを開いて、最新かつ最高のフレームワークとパターンを活用する機会は、食欲をそそるものです。
ただし、ヘッドレスCMSの実装には、フレームワークとパターンだけではありません。コンテンツモデリングは、配信を成功させるための基本的なアクティビティです。これを間違えると、プロジェクトが発展するにつれて、コンテンツ編集者と開発チームの両方にとって大きな問題に遭遇することになります。さらに重要なことに、ヘッドレスCMSが期待したものを提供できないとクライアントに感じさせ、さらに悪いことに、ヘッドレスCMSを選択することは間違った決定であると感じさせる可能性があります。
CMSの機能と制約を認識し、クライアントにとって最適なエクスペリエンスを特定するために、思慮深く将来を見据えた方法でコンテンツモデリングに取り組むことが不可欠です。
コンテンツモデリングに不慣れな方は、Michael Kinkaidの電子書籍「ヘッドレスCMSでのコンテンツモデリング」を読んでください。また、現在の状況を念頭に置いて、同僚のRickMadiganによるリモートコンテンツモデリングのベストプラクティスも確認してください。
私のトップ8コンテンツモデリングの落とし穴
コンテンツモデリングを始めようとしている人のために、さまざまなアプローチがあり、これらには独自の落とし穴があります。コンテンツをモデル化するときに考慮する必要があるいくつかの事項について説明します。だから、これが私のトップ8のコンテンツモデリングの落とし穴です:
1.コミュニケーションなしでコンテンツモデルを構築しないでください
どのプロジェクトにも、エクスペリエンスデザイン、製品バックログ、技術アーキテクチャ、編集者など、いくつかの関係者がいます。調整の余地がなく、単独でコンテンツモデリングに直接課金すると、その時点での情報のみに基づいてモデルを作成する必要があります。しかし、誰もが知っているように、プロジェクトは生きており、変化と進化が当たり前のことを呼吸しています。作成するモデルは、製品所有者によって確立されたリーンMVP要件をカバーしていない可能性があり、改良セッションからの議論と調整を見逃す可能性があります。
推奨事項
チームのすべてのメンバーと緊密に連携し、要件の微妙な変化を認識しながら、常にコミュニケーションを取ります。コンテンツモデルを計画するだけでなく、開発に沿って実装するための主要な会議とタッチポイントを確立し、無駄な時間を回避します。
2.個々のコンテンツアイテムのコンテンツタイプを作成しないでください
コンテンツモデリング中に、純粋に単一のコンテンツアイテムに対してコンテンツタイプを作成する必要がある場合があります。この例としては、「ホーム」タイプがあります。この場合、そのコンテンツタイプを再利用できるインスタンスは他にありません。ただし、微妙な違いのために、新しいコンテンツタイプを作成する場合があります。これを全体像で考えると、これらの微妙な決定が渦巻くようになります。それを知る前に、単一のコンテンツアイテムのコンテンツタイプを作成し、管理が難しい広範なリストを作成しているため、開発が複雑になっています。 。
推奨事項
可能な限り再利用性について考え、さらに重要なことに、冷酷で、コンテンツタイプを統合する方法を積極的に模索します。
3.フィールドに制限を追加します
コンテンツをモデル化する場合、ターゲットオーディエンス(コンテンツエディター)を考慮せずに、夢中になってコンテンツタイプを作成するのは非常に簡単です。純粋にデザインに基づいて必要なフィールド/要素について考えることに巻き込まれる可能性があります。しかし、この配慮の欠如は破滅につながる可能性があります。それらに制限を追加しないと、長期的には壊滅的な問題が発生する可能性があります。
たとえば、ヒーローコンテンツタイプがあり、タイトル、概要テキスト、およびCTAをページに表示するためのスペースが限られている場合、フィールド/要素に制限を追加しないと、コンテンツタイプの出力がすぐに壊れます。前のポイントと同様に、全体像にスケールアウトすると、物事は急速にスパイラルする可能性があります。
推奨事項
各コンテンツタイプのさまざまなフィールド/要素を慎重に検討してください。必要な文字制限、必須フィールドである必要があるかどうか、特定の領域内で許可されるリンクアイテムの種類、およびコンテンツモデルの悪夢から開発チームが机の下でうずくまるのを避けるためのその他の制限を決定します。
4.コンテンツタイプを過度に複雑にしないでください
再利用性は良い習慣ですが、それを悪用してコンテンツモデリングを複雑にしすぎるのは簡単です。
たとえば、コンテンツタイプを作成してから、特定のデザインに一致するようにその中にサブコンテンツタイプを作成することを決定できます。もちろん、この動作には有効なシナリオがありますが、チェックを外して考慮せずに使用すると、不要な子レベルが多数含まれている親コンテンツタイプや、不要なリンクアイテムが多数含まれていることにすぐに気付くでしょう。コンテンツエディタは、過度に複雑なコンテンツタイプを処理するために、認知的負荷を2倍または3倍にすることを余儀なくされています。それだけでなく、コンテンツアイテムまたはコンテンツタイプの割り当てを超えた可能性もあります。これにより、コストが大幅に増加する可能性があります。
推奨事項
あなたのターゲットオーディエンスはあなたの主な考慮事項です。可能な場合は、より単純な構造化データコンテンツモデリングを選択し、紹介する潜在的なリンクアイテムを賢く使用してください。何よりも、煩雑でコストがかかる高速なコンテンツタイプ「渦潮」は避けてください。
5.リッチテキストフィールド/要素で固定コンポーネントを使用する前に、まず考えてください
コンテンツをモデル化する場合、単一のインスタンスでコンテンツタイプを使用する必要があるシナリオが存在する可能性があります。この例としては、コピーのブロックの間に配置されたツイートや、テキストの一部を「中断」する行動を促すフレーズがあります。これらはテキスト内の特定の位置に配置されていないため、モデル化するのは難しいです。基本的に、コンテンツエディタには権限があり、これをどこで使用するかを決定します。これはまったく問題ありませんが、コンポーネント(これらのシングルユースコンテンツアイテムの名前)は、再利用可能に変換されない限り、再利用できないことをコンテンツ編集者が理解することが重要です。
また、貧しい開発者のために考えを惜しまないでください。コンポーネント内の特定のフィールドをフィルターとして検索に含める必要がある場合、モジュラーコンテンツのリッチテキストフィールドをトロールして必要な情報を抽出するのは時間がかかり、複雑です。
推奨事項
リッチテキスト内のコンポーネントの使用を許可する場所と時期について慎重に検討し、もちろん、使用できるさまざまなタイプの数を制限するようにしてください。いつものように、全体像と、それが検索などの機能にどのように影響するかを考えてください。
6.提供する必要のあるさまざまなチャネルを考慮しない
ヘッドレスCMSの利点は、従来の編集エクスペリエンスから離れてコンテンツを構造化できることと、従来のCMSがもたらすすべての制限です。基本的に、コンテンツハブを作成し、1つの場所でコンテンツを管理し、さまざまなチャネルに提供します。
可能性は素晴らしいですが、正しい方法でアプローチしないと、簡単に大きな穴を掘り、価格プランの境界を超える可能性があります。
最も一般的な間違いは、コンテンツとチャネル変数の混合です。例としてホームページを見てみましょう。すべてのメタデータ、ページ情報、およびWeb固有の情報を、ホームページ固有のコンテンツと同じコンテンツタイプに追加すると、新しいチャネルの導入はすぐに問題になります。チャンネル情報をコンテンツから分離するという悪夢に直面しているだけでなく、さまざまなチャンネルに取り組んでいるコンテンツ編集者が倒れています。そのコンテンツタイプにレイアウト情報も導入している場合(もしそうなら恥ずかしいことです!)、その問題は急速に拡大します。
推奨事項
戦略がすべてです。トンネルビジョンでコンテンツモデリングにアプローチしないでください。はい、MVPを提供する必要があるかもしれませんが、少なくともこれが全体像のどこにあるかを考えてください。あなたのチャンネルについて前もって考えることはあなたの人生を長期的に楽にするでしょう。また、コンテンツタイプのレイアウトは絶対に避けてください。それが従来のCMSの目的です!
7.利用可能なプロジェクトとスペースを活用する
ヘッドレスCMSは、オープンソースとサービスとしてのソフトウェア(またはサービスとしてのコンテンツ)に分けることができます。後者の場合、すべてのベンダーがさまざまなサブスクリプションプランを提供しています。これらのプランで何が利用できるかを理解することは、CMSを最大限に活用できるようにするために重要です。たとえば、コンテンツタイプとコンテンツアイテムを作成できるプロジェクト/エリアの数に制限がない場合は、それらを使用してください。すべての卵を1つのバスケットに入れると、バスケットは非常に重くなり、管理が難しくなります。
プロジェクト内の複数の場所に表示されるコンテンツの管理可能なテキストについて考えてみます。 Kentico Xperienceでは、これをリソース文字列と呼びます。ここで、サイト全体のさまざまなページやコンポーネントを表すコンテンツアイテムがたくさんあると想像してください。これらの小さな断片はすぐに失われます。すべてを1つのプロジェクトに折りたたむことは、優れた検索とフィルターを使用している場合でも、必ずしも正しいことではありません。
推奨事項
コンテンツ構造について考え、さまざまなスペースを使用してより優れたコンテンツエクスペリエンスを提供する方法を検討してください。たとえば、「リソース文字列」用のプロジェクト/エリア、サイト1の純粋なコンテンツ用、サイトXの純粋なコンテンツ用(複数のWebサイトがある場合)、異なるサイト間で共有可能なコンテンツ用のプロジェクト/エリアなどです。このようにコンテンツモデリングとコンテンツを整理すると、長期的な管理が容易になります。
8.コンテンツハブが不要なときに他のハブを覆すことを避けます
さまざまなデータソースを扱っているときが来て、ヘッドレスCMSだけが複雑なアーキテクチャのジグソーパズルの一部ではありません。これは旧世界ではありません。 CMSはもはやすべての中央ストアではありません。コマースプラットフォームを使用していて製品情報がある場合は、その情報をCMSに複製する必要はありません。不必要な複製に伴う苦痛を回避するカスタム要素を操作するためのよりスマートな方法があります。これは、この新しいアーキテクチャのどのシステムでも同じです。
推奨事項
アーキテクチャを完全に計画し、コアコンテンツと接続データがどこにあるべきかを理解します。データセットごとにマスターソースを明確に特定し、データセット間のマッピングと関係について考えます。たとえば、PIMまたはeコマースのコア製品情報とCMSの製品に関連するリッチメディアです。
概要
だから、あなたはそれを持っています。これらは、コンテンツモデリングを行う際に知っておくべき私の上位8つのことでした。それは時間がかかり、やりがいがありますが、正しく行われると非常にやりがいがあります。お分かりのように、それを間違える方法はたくさんあり、明確に定義されたベストプラクティスはあなたをまっすぐにそして狭く保つことができます。これについてサポートが必要な場合は、メール( ilesh.m@mmtdigital.co.uk )で私に連絡してください。さらにサポートさせていただきます。