manuel
2024 年 1 月 30 日午後 10:12
1
Discourse デザインシステムに沿ったカスタムテーマやコンポーネントを作成し、アプリに一貫性をもって調和させたいと考えています。
コアのコードやスタイルがどのように定義され適用されているかを見るだけでは、全体像やデザインシステムの意図された方向性を理解するのは難しいです。
これを3つの主要なトピック、すなわち「色」「タイポグラフィ」「スペーシング」に分解してみます。
2年前に一部の値に数値スケールが導入されました。これは、名前付きカラー変換を補完するためだけのものであると述べられていたと思います。三次色の値は現在このようになっています。
コアの新しいコードでは、両方のモデルが適用されているのを見かけます。長期的なアイデアは、これらを並行して使い続けることでしょうか、それとも別のビジョンがあるのでしょうか？
いずれにせよ、4つの主要な色の値すべてに数値スケールが必要ではないでしょうか？現在は一次色と三次色にしかありませんが、二次色と四次色にはありません。
現在、3種類のフォントサイズの進行が定義されています。
また、2年以上更新されていません。これらは新しいコードで使うべきでしょうか？正直なところ、実際のフォントサイズを定義するのが難しいため、乗数定義には触れたことがありません。しかし、ベースフォントの定義も理解できません。定義されたスケールは次のようになります。
13px - 14px - 15px - 17px - 19px
しかし、実際のフォントサイズを見ると、デフォルトのスケールは多かれ少なかれ次のようになっています。
13px - 15px - 17.25px - 22px - 26px
サイドバーのような新しい要素がスペーシングのルート変数（例：--sidebar-item-padding-vertical）を導入しているのを見かけます。
これにより、サイドバーのレイアウトを調整しやすくなることは間違いありません。しかし、他のレイアウト要素には反映されていません。一方で、アプリ全体でより一貫したレイアウト調整を可能にする基本的なスペーシング変数が導入されているようには見えません。これはロードマップにありますか？
より一貫性がありシンプルなデザインシステムへの移行計画があれば、ぜひ知りたいです。
現在、無関係で独立した定義が多すぎ、一貫性のあるリズミカルなレイアウトを容易に（そして楽しく
これは多くの異なる要素を持つ大きなアプリであることは理解しています。しかし、デフォルトの最新リストビューで簡単なテストを行いました。
これは、非常にシンプルな幾何級数（2px/4px/8px/16px/32px/64px）からすべての スペーシング値を選択して再構築したものです。フォントサイズはわずか4つの値から選択しました。
デザイン的には、現在アプリ全体に存在するユニークな定義の数ほど必要ないのではないでしょうか？
「いいね！」 14
これは私たちがやりたかったことで、少しずつ進めてきましたが、一度にすべてを行うことはできません。私たちが加えるすべての変更は、何千ものサイトにわたって潜在的なテーマの退行を引き起こす可能性があり（そして、お客様のためにこれらの多くを修正する必要があります）、そのため、小さな変更を加えるのに長い時間がかかります。
また、しばらくの間 Ember のモダナイゼーション作業を行っており、これも既存のテーマの退行修正やリファクタリングが必要です。これはまだ進行中であり、すべてを更新するには時間がかかります（例えば、ウィジェットシステムの置き換えには、簡単にさらに 6 か月かかる可能性があります）。バランスを取るべき優先事項がたくさんあります。
Manuel Kostka:
デザインシステムの想定される方向性
より一貫性があるという以外の、想定される方向性はありません。ベーススタイルを切り離すことを検討しましたが、デフォルトの「テーマなし」の Discourse は CSS を大幅に削減できるかもしれません（テーマの保守が容易になるかもしれません）…しかし、それは現時点では単なるアイデアです。
これらは「必要に応じて」追加されたのだと思いますが、追加のセカンダリ/クォータナリ スケールが必要になったことはありません。名前付きバージョンを削除する予定はないため、どちらも当面使用できます。
最小/小/大/最大のサイズは、テキスト サイズのユーザー設定用です。ほとんどの場合、これらを変更する必要はありません。
em スケールは、古典的なタイポグラフィ スケール（例: https://spencermortensen.com/articles/typographic-scale/）に大まかに基づいています。13-15-17-19 のような均等に配置されたスケールは、あまりコントラストを生み出さず、多くのステップがない限り、すべてが比較的小さなままになります。古典的なスケールでは、スケールの間のギャップは、より多くのコントラストを生み出すためにサイズとともに増加します。
em ベースのスケールの背後にある考え方は、アプリ内のすべてが比例してスケーリングでき、アプリの個々のセクションを比例してスケーリングできるということです。したがって、次のようなことができます。
.sidebar-wrapper {
font-size: 20px;
}
そして、その中のすべてが、個々のフォント サイズと関連するすべてのスペーシングを変更することなく、比例してスケールアップします。
内部的には、開発者はコンテキストに関係なく正確なフォント サイズを知りたいと考えており、これはシステムにとって欠点です。理想的には、正確なサイズを気にすることなく、「これを大きくしたいのでステップを上げるべきだ」と言うことができますが、そのメンタル モデルは自然には来ないようです。
rem ベースのシステムに移行したいという要望もありますが、前述のように…既存のサイトの多くに影響するため、変更には長い時間がかかるでしょう。ブラウザのデフォルトのベースである 16px ではなく 15px を好みますが、話は似ています（以前は 14px でした！なので、少なくとも 1 ステップ進みました）。
rem スケールは、調理済みの投稿コンテンツの見出しに使用されます。em を使用して見出しタグをネストすると、個人がテキストを無限にスケールアップしてレイアウトの問題を引き起こす可能性があったためです。
はい、数回話題になりました…（壊れたレコードのように聞こえますが…）既存のサイトの退行を避けるためには、非常に段階的な変更が必要になります。現時点では、更新する特定の領域内で共有変数を追加しており、これは正しい方向への一歩です。
この種のことが起こる速度は、理解できるほど少しイライラしますが、Discourse の歴史のほとんどにおいて、常駐のフルタイムデザイナーはいませんでした。デザインチームは過去数年間で 7 人に成長しました（ほとんどが公の場では見られない顧客プロジェクトに取り組む専任デザイナーも含む）ので、今後はより迅速に一貫性に向かって進むことができるようになるでしょう。
「いいね！」 12
manuel
2024 年 1 月 30 日午後 11:56
3
Kris、説明をありがとう！とても参考になります。
だから、私はごく小規模な問題しか抱えていません。しかし、製品に関する全体的な期待を変えることが役立つ場合があると思います。Discourseが急速に進歩していることを確立するために。
それは良いかもしれませんが、それでもより簡単なハンドルが必要だと思います。テンプレートが多すぎます。それらのそれぞれがよりシンプルなCSSを持っていても、私がそれらを協調的に変更できない場合、それはまだ多くの作業です。
それは美しいメンタルモデルです。正確なサイズは適用が非常に簡単なので、それらを好むかもしれません。たとえば、デザインシステムを持っている人がいれば、数字を適用して結果を確認するだけです。そうでなければ、2つのシステムを調整する必要があるように感じます。つまり、両方の文字を理解し、共通の調子を見つける必要があります。
「いいね！」 5
manuel
2024 年 2 月 1 日午前 4:16
4
これについてさらに考えてみると… Discourse デザインシステムにはいくつかのビジョンがあるかもしれません。
いくつかのハイレベルなコンポーネントを抽象化するシステム。Discourse の場合、これらはモデレーション、表彰、情報などに関するものかもしれません。
オンライン会話のための共通のパターンシステム。Material Design のようなシステムの基本的な範囲に似ています。
「いいね！」 2
）構築するのが非常に困難になっているようです。
