Bootstrapとマテリアルデザインフレームワークの比較
Bootstrap / Foundation 設計フレームワークのファミリーは、多くのレスポンシブなフロントエンドWeb開発プロジェクトの主な原動力となっています。 Googleマテリアルデザイン コンセプトもしばらくの間浮かんでおり、デザインフレームワークのマテリアルファミリ（例 Materialize ）が競合他社として浮上し始めているようです/代替。
そこにあるUXの達人のいずれかが両方の開発フレームワークの背後にある分析を行い、各フレームワークの長所と短所を調べたかどうかだけを考えています。表面的には、要素の視覚的なスタイルとUIコンポーネントの相互作用に多くの違いがあるように見えますが、各ファミリの下には、既存のフレームワークの採用/拡張とカスタマイズに関して重要な一連の設計哲学があります。あなた自身のプロジェクトとアプリケーションのために。
比較で対処する必要があるのは、おそらく次のことでしょう。
- 哲学/意図-マテリアルデザインは理論的にはデバイス/プラットフォーム/チャネルにとらわれないように見えますが、実際にそうであるかどうかはわかりません。 Bootstrapはモバイルデバイス専用であるように見えますが、おそらく半無知です。
- カバレッジ-おそらくUIデザインパターンの標準化の欠如とカスタマイズされたUIコンポーネントの必要性のため、Bootstrapの「ギャップ」について多くの質問があります。マテリアルデザインは、より多くのユースケースとシナリオをカバーする可能性があるようです。
- 柔軟性/拡張性-どちらもうまく設計されており、簡単にカスタマイズできます（少なくとも、BootstrapのCodePenのコード量から判断すると）。これは実際に問題を引き起こしますMicrosoftがMicrosoft Fluentデザインコンセプトの定義に直面していること。
どちらもUXフレームワークですが、意見は大きく異なります
マテリアルデザインはX要素の視覚的な動作と相互作用について非常に批判的です。それは、視覚要素（物理、光、空間、運動量）に関する一般的な原則から始まり、それらの原則を拡張して、特定の要素（ボタン、カード、トーストなど）の具体的な例と要件を提供します。
- マテリアルデザインは実装についてあまり考えられていません。ドキュメントでは、実装の可能性としてPolymerおよびAndroid開発フレームワークと述べていますが、Materializeのような指定されていないパッケージが他にもあります。他のプラットフォームにマテリアルデザインの実装を提供します。
Bootstrapは実装について意見が分かれています。 Bootstrapは、一連のHTMLクラスと事前に配線されたCSSスタイルと動作を使用してレスポンシブUXを構築するための特定のフレームワークを提供します。bootstrapドキュメントには、HTML要素とデフォルトのスタイルですが、bootstrapのコアセマンティクスはCSSクラスに取り込まれます。
- Bootstrapは、ビジュアルプレゼンテーション/スタイルについてあまり考えられていません。実際、CSSクラスを中心に設計されているため、ビジュアルプレゼンテーションは スタイルシートを使用して簡単にカスタマイズできます です。
Materialはフレームワークではないと思いますが、フレームワークの定義に依存することに同意します。 this を使用する場合：
コンピュータプログラミングでは、ソフトウェアフレームワークは、一般的な機能を提供するソフトウェアを追加のユーザー作成コードによって選択的に変更できる抽象化であり、それによってアプリケーション固有のソフトウェアを提供します。ソフトウェアフレームワークは、ソフトウェアアプリケーション、製品、およびソリューションの開発を容易にするために、より大きなソフトウェアプラットフォームの一部として特定の機能を提供する、ユニバーサルで再利用可能なソフトウェア環境です。ソフトウェアフレームワークには、サポートプログラム、コンパイラ、コードライブラリ、ツールセット、アプリケーションプログラミングインターフェイス（API）が含まれ、さまざまなコンポーネントをすべてまとめてプロジェクトまたはソリューションの開発を可能にします。
フレームワークには、それらを通常のライブラリから分離する主要な特徴的な機能が含まれています。
- 制御の反転：フレームワークでは、ライブラリや通常のユーザーアプリケーションとは異なり、プログラム全体の制御フローは呼び出し元ではなくフレームワークによって決定されます。
- デフォルトの動作：フレームワークにはデフォルトの動作があります。このデフォルトの動作は、一連のノーオペレーションではなく、いくつかの有用な動作でなければなりません。
- 拡張性：フレームワークは、特定の機能を提供するために、通常、選択的にオーバーライドすることによってユーザーによって拡張されるか、ユーザーコードによって特殊化されます。
- 変更不可能なフレームワークコード：一般に、フレームワークコードは、ユーザーが実装した拡張機能を受け入れながら変更することはできません。つまり、ユーザーはフレームワークを拡張できますが、そのコードを変更しないでください。
マテリアルはフレームワークではなく、フレームワークを構築するためのガイドラインです。たとえば、Materializeは、Materialガイドラインに基づいて構築されたフレームワークです。別の例は、私が私のチームのために構築するものです：Materialを使用するBootstrapの非常にカスタマイズされたバージョン（ http://fezvrasta.github.io/bootstrap- material-design / これは少し汚れていて、多くの不必要なものをロードします）、そして追加のbridgeto Polymer です。場合、フレームワークはBootstrapおよびPolymerですが、Materialはそれを構築するために使用したガイドラインです。
これが言われて、OPのポイントに行く：
- 哲学/意図-マテリアルデザインは理論的にはデバイス/プラットフォーム/チャネルにとらわれないように見えますが、これが実際に当てはまるかどうかはわかりません。 Bootstrapはモバイルデバイス専用であるように見えますが、おそらく半無知です。
フレームワークを使用するまで、マテリアルは不可知論です。また、マテリアルを使用して10個のサイトを構築すると、すべてが同じに見え始めます。反対に、Bootstrapは「mobile first」という哲学を持っていますが、最近デスクトップで最も使用されているフレームワークです
- カバレッジ-おそらくUIデザインパターンの標準化の欠如とカスタマイズされたUIコンポーネントの必要性が原因で、Bootstrapの「ギャップ」について多くの質問があります。マテリアルデザインは、より多くのユースケースとシナリオをカバーする可能性があるようです。
上記の私のコメントを参照してください。 Bootstrapはすべてのケースをカバーする可能性がありますが、ほとんどではなく、マテリアルが実行できない何かをカバーします
- 柔軟性/拡張性-どちらも適切に設計されており、簡単にカスタマイズできます（少なくとも、CodesPen for Bootstrapのコード量から判断すると）。これは、MicrosoftがMicrosoft Fluent設計コンセプトの定義で直面した問題に実際につながります。
上記で提供したフレームワークの定義を採用すると、はい、完全に同意します
結局、Bootstrapはコードを構築するためのフレームワークを提供し、Polymerでも同じことが起こりますが、MaterialはUXDと設計ガイドラインのセットを提供してUXDが結果を最大化するのに役立つので、私はしませんtは反対と見なしますが、完全に相補的です（したがって、自分が構築したものを構築した理由）
ブートストラップは主にレスポンシブグリッドシステムであり、デフォルトのUIルックアンドフィールの決定が行われます（簡単に上書きできます）。
Materializeは主に、UI要素とインタラクションのセットです（ただし、グリッドもあります）。
また、他にも約2,000のUI CSSフレームワークがあります。これらのフレームワークをそのまま使用することはめったにありません。そのため、UXに関して「最良」のものは、主観的なものです。通常、どちらのフレームワークを選択するかは、UI開発プロセスとチームの設定に関係があります。