フォルダー構造とファイル命名規則の決定 folder-structure-filenaming

すべてのコンテンツをアップロードする前に、使用するフォルダー構造と、特にファイル命名規則を考慮することをお勧めします。そうすれば、時間を節約し、後でタスクをやり直す必要もなくなります。 これらの決定は、すべてのグループに適合させることをお勧めします。

フォルダー階層とファイル命名規則

ファイルの命名は、通常、Dynamic Media Classic の実装に関して行う最も重要な決定事項です。しかし、それが重要な理由を理解するために、まずフォルダー構造について説明します。

フォルダー階層

フォルダー階層は、組織的な目的でのみ重要です。Dynamic Media Classic の URL は、アセット名を参照するだけで、フォルダーやパスは参照しません。ファイルのアップロード先に関係なく、URL は同じです。 これは、多くの人が web 用の画像やコンテンツを整理する方法とはまったく異なりますが、Dynamic Media Classic では違いはありません。

もうひとつ重要な考慮事項は、各フォルダーに保存するアセットやフォルダーの数です。多数のアセットが 1 つのフォルダーに保存されている場合、Dynamic Media Classic でアセットを表示すると、パフォーマンスが低下します。何千ものアセットを 1 つのフォルダーに保存しないでください。代わりに、階層の特定のブランチ内に約 500 未満のアセットまたはフォルダーを持つ組織階層を作成します。これは厳密な要件ではありませんが、アセットの表示や検索を行う際に、許容できる応答時間を維持するのに役立ちます。実際には、レコメンデーションは、狭くて深い階層ではなく、広くて浅い階層を作成することです。

フォルダーを作成する最も簡単な方法は、FTP を使用してフォルダー構造全体をアップロードし、「サブフォルダーを含める」オプションを有効にすることです。このオプションを選択すると、Dynamic Media Classic は、Dynamic Media Classic の FTP サイトにフォルダー構造を再作成します。

すべてのファイルのアップロードを開始する前に、フォルダー構造を検討してください。Dynamic Media Classic 内にあるよりも、コンピューター上でローカルにファイルやフォルダーを整理および管理する方がはるかに簡単だからです。例えば、Dynamic Media Classic 内では、ファイルのみをドラッグ＆ドロップすることはできますが、フォルダー全体のドラッグ＆ドロップはできません。

フォルダー戦略

フォルダー戦略については、組織にとって何が理にかなっているのかを考えてみてください。一般的なフォルダーの命名シナリオを次に示します。

ファイル命名規則

ファイルにどのような名前を付けるかは、Dynamic Media Classic に関して初期段階で行う最も重要な決定です。これは、Dynamic Media Classic のすべてのアセットが、アカウント内のどこに保存されているかに関係なく、一意の名前を持つ必要があるためです。

Dynamic Media Classic のすべての URL とトランザクションは、アセット ID（データベース内のアセットの一意の識別子）によって制御されます。ファイルをアップロードすると、ファイル名を取得し、拡張子を削除することで、アセット ID が作成されます。例えば、896649.jpg は、アセット ID 896649 を取得します。

アセット ID に関するルール：

命名規則は、基本的には Dynamic Media Classic と統合する方法になります。バックオフィスシステムはクローズドシステムなので、通常、Dynamic Media Classic に統合することはありません。 これは、URL 形式の命令を待つ受動的なパートナーです。

ほとんどのユーザーは、内部の SKU や製品 ID に基づいて命名規則を使用しているため、web ページがその SKU に関する情報で呼び出されると、類似した名前を持つ画像をページで自動的に検索できます。ファイル名と SKU または ID の間につながりがない場合は、バックオフィスのシステムで各ファイル名を手動で追跡する必要があり、ユーザーは関連付けを維持する必要があります。つまり、IT チームとコンテンツチームの両方で大変な作業が発生します。

ファイル命名方法

命名方法は、将来の拡張に備えて柔軟に指定する必要があります。これにより、ローンチ後に名前を変更する必要をなくします。以下に、一般的な命名方法を示します。

代替イメージはありません。 このシナリオでは、製品ごとに 1 つの画像しかなく、代替ビューや色付きビューはありません。各画像には、一意の SKU または製品 ID 番号に従って厳密に名前を付けます。ページが読み込まれると、ページテンプレートから同じ SKU 番号を持つアセット ID が呼び出されます。

これは非常に単純なしくみなので、ニーズがあまり複雑でない場合に適しています。ただし、柔軟性には欠けます。今日、代替画像がないからといって、明日もその画像がないとは限りません。次のシナリオでは、より柔軟に対応できます。

画像、代替ビュー、カラーバージョン、スウォッチの使用 この方法では、代替ビューや色付きビューがある場合、それらを使用できます。SKU だけで画像に名前を付けるのではなく、代替ビューには「_1」や「_2」などの修飾子を付加し、色付きビューには「_RED」や「_BLU」のカラーコードを付加します。同じ製品のカラー画像と代替ビューの両方がある場合は、1 番目と 2 番目の赤いビューには「_RED_1」と「_RED_2」を付加します。スウォッチの名前には、SKU、カラーコードに加えて「_SW」拡張子を付けます。

画像セットやスウォッチセットなどのセットコレクションを処理する場合は、セット自体にも一意の名前を付ける必要があります。そのため、この場合、セットにはベース SKU を名前として付けるか、SKU に「_SET」拡張子を付けるとよいでしょう。

命名規則と自動処理

命名規則の重要性について最後に説明します。 画像セットやスウォッチセットなどのセットを使用する場合は、予測可能な命名規則を使用するとセットの作成を自動化できます。このチュートリアルの別の節で説明している、バッチセットプリセットなどのスクリプト化されたメソッドは、命名規則から切り離すことができます。

別の方法として、手動でセットを作成することもできます。200 枚の画像セットを手作業で作成するのは大した仕事ではないかもしれませんが、10 万枚を超える画像がある場合を想像してみてください。そこで重要になるのが、セット作成の自動化です。