コンテンツウィジェット

リンクのリストをレスポンシブなグリッドに変換します。読者を別の場所へ誘導するインデックスページやハブページに最適です。

• 各見出しはグリッドの上に小さな大文字のラベルとして表示されます。見出しは省略可能です。
• - [Title](/href) — Description. は、タイトルと説明を備えたカードを作成します。
• {icon-name} で項目を終えると、アイコンを追加できます。例：{rocket}、{book-open}。名前は Lucide セットから選びます。不明な名前は何も表示されずに削除されます。波括弧がページに表示されることはありません。
• 項目に ![alt](https://raw.githubusercontent.com/docsbook-io/docs/main/content/features/url) 画像を配置すると、アイコンの代わりに実際の画像を使用できます。画像はアイコンが占めるのと同じ領域を埋めます。カードが画像のある特定の対象についてのものなら、アイコンよりも適しています。
• リンクのない項目は、クリックできないカードとして表示されます。

<!-- widget:cards -->
 
## Start here
 
- [Search](/docsbook-io/docs/content/features/search) — Let readers find a page by keyword {search}
- [Page feedback](/docsbook-io/docs/content/features/feedback) — Ask whether the page helped {thumbs-up}
 
<!-- /widget -->

カードに本文を追加します。 項目の後に空行を残し、その下にマークダウンを追加してインデントを深くします。段落、短いリスト、スニペットなどを記述できます。説明の下に表示されます。カードに説明すべき内容がある場合は有用ですが、行き先を示すだけのカードなら、1行で表示したほうが読みやすくなります。

カード独自のアクションを追加します。 最後のインデントされた行にリンク以外の内容がない場合、その行はカードのコールトゥアクション行になります。単にリンクを含むだけの文は、通常のテキストのままです。

レイアウトを選択します。 cols=1、cols=2、cols=3、または cols=4 で列数を固定できます。horizontal は、アイコンをテキストの上ではなく横に配置し、コンパクトな行にします。どちらも開始マーカーに記述でき、組み合わせて使用できます。cols がない場合、グリッドにはページ幅に収まる限り多くのカードが1行に配置されます。通常はこれが望ましい設定です。画面が狭い場合は、常に列数が少なくなります。

<!-- widget:cards cols=2 -->
 
- [Full-text search](/docsbook-io/docs/content/features/search) — Match a reader's keyword against your pages {search}
 
  Indexes every markdown file the site publishes and rebuilds itself when the
  repository changes. Nothing to reindex by hand.
 
  [Read the guide](/docsbook-io/docs/content/features/search)
 
- [Page feedback](/docsbook-io/docs/content/features/feedback) — Ask whether the page helped {thumbs-up}
 
  One click from the reader, no form and no email address. Results land per
  page, so you can sort by the pages rated worst.
 
  [Read the guide](/docsbook-io/docs/content/features/feedback)
 
<!-- /widget -->

見出し付きのセクションを、1つのパネルだけを表示するタブストリップに変換します。同じ手順が複数の並列バージョンに存在し、読者がそのうち1つだけを必要とする場合に使用します。たとえば、パッケージマネージャー、オペレーティングシステム、言語 SDK、ホスティング版とセルフホスティング版の手順などです。

• 各見出しが1つのタブになります。同じレベルの次の見出しまでの内容が、そのタブのパネルになります。
• 最初のタブが最初に開くため、最も多くの読者が必要とするバリエーションを先頭に置きます。
• 見出しは {icon-name} で終えることができます（例: ### macOS {apple}）。すべてのタブにアイコンを付けるか、どのタブにも付けないでください。一部のタブにだけアイコンがあるストリップは、壊れているように見えます。
• テーブルや構文ハイライト付きのコードブロックを含め、パネル内では任意の Markdown を使用できます。
• 最初の見出しより前の内容は、導入文としてストリップの上に表示されます。すべてのタブに当てはまる1文に使用します。
• ラベルは1語または2語にします。ストリップは折り返されず横方向にスクロールするため、文章のように長いラベルは他のタブを画面外に押し出します。
• 切り替え可能なタブは最大8個です。9番目以降のセクションは通常の見出しとしてストリップの下に表示されます。内容が失われることはありませんが、これほど長いセットには見出し一覧が適しています。
• パネルはすべてページソース内にあり、切り替えは CSS のみで行われるため、JavaScript が無効でもすべてのバリエーションを読め、クローラーからも見える状態になります。

読者がすべて読む必要のあるコンテンツを隠すためには使用しないでください。スキャンして参照する資料では accordion を使い、手順には通常の見出しを使用します。

見出し付きのセクションを、読者が展開する行に変換します。FAQ、トラブルシューティング、オプションごとの詳細など、読むよりもざっと確認する内容に最適です。

• 各見出しが1つの行になります。同じレベルの次の見出しまでの内容が、その行の本文になります。
• コードブロックやテーブルを含め、行内では任意の Markdown を使用できます。
• すべての行は折りたたまれた状態で始まるため、開かなくても選択できるだけの情報を見出しに含めます。
• 最初の見出しより前の内容は、導入文としてアコーディオンの上に表示されます。

見出し付きのセクションを、上から下へつながる一連の手順に変換します。インストール、セットアップ、複数段階のチュートリアルなど、順序が重要な場合に使用します。順序が重要でない場合は、代わりに accordion を使用します。

• 各見出しが1つのステップになり、文書内の順序に従って番号が付けられます。
• ステップを追加または削除すると、残りの番号が自動的に振り直されます。

プランを比較可能なカードの列に変換するか、プランの表を比較マトリクスに変換します。プランについて読むのではなく、ティア間で選択する必要がある場所で使用します。

ウィジェットは記述内容に応じて形状を選択します。見出しがある場合はプランごとに1枚のカードになり、代わりに領域全体が単純なテーブルの場合はマトリクスとして再表示されます。ページがすでに採用している形状に合わせて記述してください。

プラン形式。 各見出しがプラン名になります。

• 見出しの直後にある最初の段落が価格になり、大きく表示されます。**$20** / month は数字を強調し、単位をその横に保持します。数字がない場合も、同じように Free または Contact sales を記述します。
• 2番目の段落は、そのプランがどのような人向けかを1行で示します。価格とリストの間に配置され、カード内で最も幅が狭い部分になります。
• リストはプランに含まれる内容になり、各項目にチェックが付きます。取り消し線付きで記述した項目（~~Priority support~~）にはダッシュが付き、控えめに表示されます。これにより、2つ目のリストを用意せずに、安価なプランに含まれない内容を示せます。
• 見出しの直下に **bold text** だけを含む段落があると、そのプランのバッジになり、注目プランとして示されます。カードの周囲にリングが付き、塗りつぶしボタンになります。使用できるプランは最大1つです。
• プランの最後にあるリンクのみの段落が、cta とまったく同じようにボタンになります。注目プランの最初のボタンは塗りつぶしで、残りはゴーストボタンになります。これにより、ブロック内で目立つ要素が1つに絞られます。

マトリクス形式。 最初の列に機能名を記載し、それ以外の各列がプランになります。セル全体のテキストが yes、no、✓、—、included または none のいずれかである場合、チェックまたはダッシュになり、スクリーンリーダー向けにその単語はマークアップ内に保持されます。それ以外（3 seats、Unlimited、脚注など）が入ったセルは、記述どおりそのまま残ります。空のセルは空のままです。沈黙は「いいえ」を意味しません。

開始マーカーの cols=1|2|3|4 により、グリッドの列数をその数に固定できます。デフォルトでは、ページに収まる数のカードが表示されます。

ソースから読み取っていない価格、プラン名、上限、サービス提供条件をこのウィジェットに記述してはいけません。これは、内容自体が商業上の約束となる唯一のウィジェットです。

REST エンドポイントのセクションを、読者が自分のキーとパラメーターを使って実際のリクエストを送信できるフォームに変換します。

• メソッドとパスで構成された見出し（## POST /api/v1/chat）が、1つのエンドポイントブロックになります。
• その直下にある最初のテーブルで、Field（または Name / Parameter）列があるものがリクエストフォームになります。各行が1つの入力になります。Type、Required、Description 列がある場合は、それらも使用されます。
• /project/update/{projectId} のようなテンプレート化されたパスセグメントには、必ず専用の入力欄が設定されます。
• Authorization 入力は常に追加されます。読者のキーは読者自身のブラウザーから送信され、Docsbook に届くことはありません。
• Authorization をテーブルの行として記述しても問題ありません。その行は上部のヘッダー入力に割り当てられるため、説明は維持され、キーを URL に含めることになるフィールドとして二重に表示されることもありません。
• コードブロック（### Example、### Response）を含む ### サブセクションは、タイトルを保持したままフォーム横のサンプルペインに移動します。### Errors テーブルなど、それ以外のサブセクションは、文書の流れに沿って下に残ります。

読者が次に行うべき1つの行動を示してページを締めくくる、小さな枠付きブロックです。

• 最初の見出しがブロックのタイトルになります。実際の見出しではなくスタイル付きの行として表示されるため、ページのアウトラインには含まれません。
• **bold text** だけを含む先頭の段落は、小さな大文字の補助見出しになります。
• リンクだけを含む段落がボタンになります。最初のボタンは塗りつぶしで、残りはアウトライン付きです。単にリンクを含む文章は本文として残ります。
• 1ページにつき1つ、リンクは最大2つにします。2つ目のブロックは1つ目と競合し、どちらのコンバージョン率も低下します。

<!-- widget:cta -->
 
## Publish your docs from GitHub
 
Connect a repository and your markdown is live.
 
[Create a project](https://docsbook.io/start) · [See pricing](https://docsbook.io/pricing)
 
<!-- /widget -->

メインアクションを1項目のフォームとして表示する、同じブロックです。読者が入力した内容は遷移先URLに引き継がれるため、次のページで再入力せずに開始できます。

• 最初のリンクのURLがフォームの送信先になり、リンクテキストがボタンのラベルになります。
• 空のクエリパラメーターでフィールド名を指定します: ?email= で、読者が入力した内容が email として送信されます。クエリ文字列がない場合、フィールド名は email になります。
• すでに値が設定されているパラメーターは変更されずに引き継がれます — ?email=&ref=docs では、送信先URLに ref=docs が保持されます。これはアトリビューションに便利です。
• リンクのMarkdownタイトルでプレースホルダーを設定します: [Join](https://example.io/signup?email= "you@company.com")。
• キーボードはフィールド名に応じて決まります: email ではメール入力用キーボードが、url / site / domain ではURL入力用キーボードが表示されます。
• mailto: やページ内アンカーのようにフォームを受け付けられない遷移先は、通常のボタンにフォールバックします。

パラメーターを実際に読み取るURLにのみ指定してください。パラメーターを無視するページでは、読者が入力した内容が何も通知されずに破棄されるため、通常のボタンよりも悪い結果になります。

調査結果のリストをカードのグリッドに変換し、それぞれに重要度バッジと対応用リンクを付けます。自分のドキュメントに関する、監査結果やコンテンツの健全性に関する問題など、具体的で優先順位の付いた調査結果、つまり「修正すべき項目を優先順位順に示す」リストに使用します。移動先の単純なリストには、代わりに cards を使用してください。

• 各見出しは、リストの上に表示される小さな大文字のグループラベルになります。見出しは省略可能で、グループ分けしない単一のリストにする場合は省略します。
• 各リスト項目が1つの推奨事項になります。- [Title](/href) — Explanation. {severity}: リンクテキストが見出しになり、ダッシュ以降のテキストが重要な理由と実行すべき内容になります。
• すべての項目の末尾に重要度マーカーを付けます — {urgent}、{worth-doing}、または {later}。認識されるマーカーがない項目は、重要度を失うのではなく {worth-doing} として表示されます。
• リンクのない項目は、クリックできない推奨事項として表示されます。読者を誘導できる場所が本当にない場合にのみ記述してください。
• 見出しとそのリストの間にある段落は、通常の導入文としてそのまま表示されます。

<!-- widget:recommendations -->
 
- [You are paying to keep the same page twice](/docs/quickstart) — "Quickstart" and "Getting started" are 96% the same and neither links to the other. Keep one, merge the other into it. {urgent}
- [214 people found "Webhooks" the hard way](/docs/webhooks) — No page links to it, yet it still gets visits. Add a link from "Integrations". {worth-doing}
- [Nobody reads "Migration notes"](/docs/migration-notes) — Zero visits although 2 pages link to it. Reword the link text. {later}
 
<!-- /widget -->