あなたの入力が入り、公開されたウェブサイトが出て、運用はすべてその横に並びます。

あなたが所有する入力

流れの左側にあるものはあなたのもので、そうであり続けます。そこにプラットフォームのコードはありません。

• 設定

  身元、言語、ナビゲーション、機能のスイッチ、UI の判断 — 散在する定数ではなく検証された設定です。

• コンテンツ

  ページとコレクションはリポジトリ内のファイルで、それぞれに独自のタイトルと本文があります。

• 翻訳

  言語ごとの UI 辞書と、その言語のコンテンツディレクトリです。

• ブランドとアセット

  ロゴ、favicon、SNS プレビュー、任意のビジュアルを、それぞれ名前付きの役割で扱います。

これらはどれも、基盤のアーキテクチャに触れずに変更できます。

Foundation がそれらに対して行うこと

Foundation は入力を読み、サイトを生成します。ここがあなたが作らずに済む部分で、ビルドとデプロイの時に動き、訪問者を待たせません。

1. 1

   検証

   設定と辞書がスキーマに対して検査されるため、誤った設定は訪問者に届かずビルドが失敗します。

2. 2

   コンテンツとルーティング

   ページはコンテンツインターフェース経由で読み込まれ、安定したアドレスを受け取り、翻訳がない場合はページ単位で既定言語に戻ります。

3. 3

   表現

   コンテンツと身元は共有のトークンシステムによって、ライトまたはダークで、すべての画面幅で構成されます。

4. 4

   可視性とメタデータ

   タイトル、正規アドレス、言語注釈、構造化データ、サイトマップと robots の出力が、あなたの設定から生成されます。

5. 5

   連携点

   機能を有効にした場所で、Foundation が接続を描画し、訪問者の意図をあなたの事業者へ渡します。

6. 6

   出力

   静的なウェブサイトとしてビルドされ、自分のアカウントとドメインへ公開されます。

ここに借りるサービスはありません。同じリポジトリを、実行できる場所ならどこでもビルドできます。

Foundation の横で動くもの、中ではないもの

Foundation は意図 — 予約する、経路を知る、メッセージを送る — を表現し、その先の接続先はあなたが決めます。Foundation 自体がそれらのシステムになることはありません。

外部サービスは連携点を通じて接続します。サービスは自分のデータ、ルール、アカウントを保持します。

Foundation の入手から、自分で維持するサイトまで

10 の実践的な手順です。詳細はリポジトリの手引きにあり、このページは作業の形を示します。

1. 1

   入手する

   公開リポジトリを自分のアカウントへ clone または fork します。

2. 2

   実行する

   インストールして起動し、変更前に動くサイトを確認します。

3. 3

   設定する

   身元、言語、ナビゲーション、機能のスイッチを設定で定義します。

4. 4

   身元を差し替える

   名前付きのビジュアルの役割を、自社のロゴ、favicon、プレビューに置き換えます。

5. 5

   コンテンツを書く

   ページとコレクションをリポジトリ内のファイルとして書きます。

6. 6

   機能を選ぶ

   必要なものだけを有効にします。使わない機能はルートやプレースホルダーを追加しません。

7. 7

   事業者を接続する

   有効にした各連携点を、すでに使っている事業者へ向けます。

8. 8

   検証する

   品質ゲートとブラウザ検証を実行し、問題を訪問者より先に見つけます。

9. 9

   デプロイする

   自分のアカウントとドメインへビルドして公開します。

10. 10

    維持する

    コンテンツと設定を自分のものとして保ち、上流の改善は自分で選んだ時点で取り込みます。

手引き

このサイトは GitHub の手引きの二つ目の写しにはなりません。

誰が何を所有するか

Foundation は借りるサービスではなく、あなたが保持するインフラです。分担は意図的に単純です。

離れることもできます。あなたが所有するものはすべて付いてきます。リポジトリがあなたの情報源です。

何かを変更するとどうなるか

2 つの意図的なルールがこれを予測可能にします。存在を決めるのはコンテンツ、表現を決めるのは設定であり、どちらかが他方を黙って作ることはありません。

• サイト名、スローガン、説明

  ヘッダー、フッター、ページタイトル、SNS メタデータ、構造化データ。

• ページ自身のファイル

  そのページのコンテンツと、生成されるサイトマップ。

• 辞書ファイル

  その言語の UI 文言。

• アクセントカラーのトークン

  サイト全体のブランド要素と強調要素。

• ロゴ、favicon、プレビューのアセット

  該当するビジュアルの役割のみ。

• ナビゲーション設定

  メニューの順序とラベル。ページの存在そのものは変わりません。

• 機能のスイッチ

  その機能のルートと面が存在するかどうか。

• 事業所

  その事業所の営業状況、住所、経路、構造化データ。

任意のものがなければ何も描画されません。埋め合わせのページも、借り物のビジュアルも、空の枠もありません。

誤った変更が早く失敗する理由

設定は訪問者が来た時ではなくサイトをビルドする時に検査されるため、誤りはすぐに現れます。

• 未知の設定や誤った綴りは無視されず、拒否されます
• 構造的に無効な値は、その設定を名指ししてビルドを失敗させます
• 設定されたが不完全な機能は、黙って何も描画せず失敗します
• 辞書のない言語は、黙って別の言語を表示せず失敗します

だからこそサイクルは「ファイルを変更し、ビルドし、真実を見る」であり、本番で発見することではありません。

作業を失わずに改善を取り込む

設定、コンテンツ、辞書、アセットはそれぞれの領域にあり、それによってサイトを書き直さずに後の改善を取り込めます。

• 更新してもサイト固有の領域はあなたのものです
• 改善を取り込む時期は自分で決められ、押し付けられません
• 何がなぜ変わったかをリポジトリが記録するため、判断は情報に基づきます

更新の手引きを読む

これは文書化されたモデルです。自動更新サービスではなく、プロジェクトはそれを主張しません。

動く基盤から始める

機能を読み、すでにその上で動く 2 つの企業を見て、すでに動いているものから始めてください。

• デモを見る
• GitHub で見る