Grav-plugin-admin: UX：モジュラーコンテンツの追加

モジュラーページ管理を改善する方法については、確かにいくつかの計画があります。 現在の状況は、コード側から見た単純さと一貫性の問題にすぎません。 これはまだ理想的な設定ではありませんが、機能し、いくつかのドキュメントも状況を改善するのに役立ちます。

アンディの返事をありがとう。 ページの作成に関しては、現在のプレゼンテーションのユーザーエクスペリエンスについてはまだかなり心配していますが、この時点で検討する変更の範囲はありますか？

簡単なフォローアップの考え-他に何もなければ、[モジュラーコンテンツの追加]ダイアログのテキストを[モジュラーコンテンツの追加]から[ページへのモジュラーコンテンツの追加]に変更すると、ここで役立つと思います。 長期的には、すでに計画を立てていることは承知していますが、親、子、またはモジュラーコンテンツページを作成する機能を備えた[ページの追加]ダイアログを1つ持つことは、探索するための実行可能なアプローチになると思います。

また、[ページの追加]と[モジュラーの追加]の両方の最初の項目として[親ページ]ドロップダウンを配置すると、ページに名前を付ける前に決定が下されるため、ユーザーにとっても役立つのではないかと思います。どう思いますか。

管理プラグイン内のモジュラーページの処理を改善するための+1

技術者以外のユーザーの観点からは、モジュラーサブページを親ページのユニオンに含める方が論理的だと思います。 したがって、おそらく内部（=モジュラーサブページ）はユーザーから隠されており、ユーザーは親ページ内のコンテンツの個別のブロックを表示して追加することができます。

@Jugiburに同意します

通常のクライアントは、「このページを編集したい」と考えるだけです。 彼らはおそらくページの名前をクリックして、これを見るでしょう：

コンテンツを追加する場合でも、そこにあるものを編集する場合でも、ここから何をすべきかわかりません。 うまくデザインするのは難しいですが、ページの各モジュールの編集可能なボックスを表示順にスクロールできる1つのページと、新しいモジュールを追加するためのボタンを想像しています。

前にも言ったように、これは私たちが再考したいことです。 理想的ではないことはわかっていますが、機能的です。 つまり、それは機能します。

現在、管理者のJS全体の書き直しに取り組んでいます。 これにより、最初から意図したモジュラーページUIを開発できますが、初期バージョンで適切に実装する時間がありませんでした。

現在の最大の問題はUIではなく、モジュラーページを手動で注文できないことだと思います。 モジュラーページの最も一般的なユースケースはコンテンツの行であるため、これはデフォルトである必要があると思います。 そして、日付や名前の順序を持​​っている人にとっては意味がありません。

また、役立つものはこのhttps://github.com/getgrav/grav-plugin-admin/issues/735に接続されています。 また、クライアントが編集できないページを定義できる必要があります。 これらを使用すると、クライアントがページを編集するのをかなり安全にすることができます。

このようなものは素晴らしいでしょう：
https://craftcms.com/docs/matrix-fields
https://github.com/benjamminf/craft-neo

＃1174の最近のマージに関して、管理者のUIがこの曖昧性解消をどのように処理するかについていくつかの議論がありました。 その号の終わりからポール・マッセンダリを引用するには：

「モジュールの追加」の名前を「モジュールの追加」に変更する必要がありますか？ https://github.com/getgrav/grav-plugin-admin/blob/develop/languages/en.yaml#L36

コンテンツを追加するための一般的なボタンは次のように表示されます。

これは、Gravが持つ3つの主要なタイプの構造（通常のページ、フォルダー、およびモジュラーページ）を考えると予想どおりです。 ただし、同じドロップダウンが他のコンテキストにも存在します。これにより、ページとモジュラーページが何であるかというあいまいさが持続します。 Slackから自分を引用するには：

概念的には、モジュラーページはコレクションを含む通常のページではなく、コンポーネント（モジュール）を保持する構造であり、それに従属する他のタイプのページを持つべきではありません。 したがって、モジュラーページは/ sample / pageに関して通常の子ページを持つことができますが、そのコンテンツはモジュールでのみ描画されるコレクションによって完全に定義され、これらのモジュールは他の場所では表示またはルーティングできません。 もちろん、構成要素としては、実際にはページのサブセットにすぎないため、コンポーネントの管理が容易になります。TwigとYAMLでも同じ効果が得られますが、概念レベルでは、通常のページに混在させるべきではありません。 そのため、Gravがページを定義する方法の観点から、[追加]ドロップダウンで関心の分離を行うことが望ましいでしょう。

その観点から、モジュラーには通常の子ページやモジュール以外の他の子アイテムを含めるべきではありませんが、現在のUIではこれらを非常に自由に組み合わせることができます。 Paul Massendariの例：

- home
- blog
  -_introtext
  -_latestarticles
  - _subscribe  
  - article1
  - article2

これ自体は意味的に完全に理にかなっていますが、通常のページとモジュラーの間のあいまいさは保持されます。 したがって、2つを分離するために（モジュラーはページのサブセットですが）、UIはコンテキストに適したものに選択肢を制限する必要があります。 / admin / pagesのドロップダウンは、ページ、フォルダー、またはモジュラーの追加を提供する必要があり、モジュラーページでは、モジュールの追加を提供する必要があり、ページとフォルダーの両方で、3つすべての追加も提供する必要があります。

コンテキスト分離の要約（8月28日更新）：
@paulhibbittsおよび@paulmassenとさらに議論し、この区別に到達しました。ただし、明確にするために、おそらく「子」は「子ページ」である必要があります。

+ページリストビューにメニュー項目を追加
ページを追加
リストページを追加
モジュラーページを追加
（フォルダーを追加）

+標準ページビューにメニュー項目を追加
子を追加
（フォルダーを追加）

+リスト（親）ページビューにメニュー項目を追加
子を追加
（フォルダーを追加）

+モジュラー（親）ページビューにメニュー項目を追加
モジュールの追加
子を追加
（フォルダーを追加）

フォルダは常に下部にある必要があるため角かっこで囲まれ、ページタイプではないことを示す薄い上部境界線などの視覚的なインジケータによって上記のページタイプから分離されていますが、上記のすべては状況に応じて適していますタイプ。 3つ; その場合、ページ、リスト、モジュラーがデフォルトの標準タイプであり、 https：//learn.getgrav.org/content/content-pagesはおそらくこれを反映するように更新する必要があります。

最も明確なロジックは次のように思われます。ページはGravがレンダリングする任意のマークダウンファイルであり、リストページはスタンドアロンの子ページを列挙するために使用されるページのサブセットですが、モジュラーページはその子ページに存在するページのサブセットです。それ自体の一部として。 したがって、Listingは個別の子アイテムへのリンクをリストし、Modularはそれらをそれ自体の中に表示します。 ページとリストには通常の子ページがあり、リストは主にそれらを順序付けられた方法でリストします。 モジュールのみがモジュールを備えています。

ただし、テーマが特定のページタイプをサポートしていることをブループリントを介して伝達する必要もあります。 すべてのテーマにデフォルトのテンプレートがあるわけではなく、リスト用またはモジュラー用のテンプレートもあります。 したがって、ダイアログ、モーダル、ボタン、またはページを追加する他の方法は、テーマがそのテンプレートを通じて本質的にサポートするものを反映する必要があります。