インターフェイス開発の世界では、共通の概念があります – 「ロッジに完璧なピクセル」。これは、デザインマシンの最小ピクセルへの最も正確な複製を意味します。長い間、それは、特に古典的なウェブデザインの時代において、ゴールドスタンダードでした。しかし、宣言的なマイルの到着とさまざまなデバイスの急速な成長により、「Pixel Perfect」の原則はより一時的になりつつあります。理由を把握してみましょう。
Imperial Wysiwyg vs.宣言コード:違いは何ですか? h2>
従来、多くのインターフェイス、特にデスクトップは、編集者の命令的なアプローチまたはwysiwyg(あなたが見るものです)を使用して作成されていました。このようなツールでは、デザイナーまたは開発者は要素を直接操作し、ピクセルに正確にキャンバスに配置します。それはグラフィックエディターとの作業に似ています – あなたはあなたの要素がどのように見えるかを見ることができ、あなたは間違いなくそれを配置することができます。この場合、「Pixel Perfect」の達成は非常に現実的な目標でした。
ただし、現代の開発は、宣言マイルにますます基づいています。これは、コンピューターに「このボタンをここに置く」ように指示するのではなく、取得したいものを説明することを意味します。たとえば、要素の特定の座標を示す代わりに、そのプロパティについて説明します。「このボタンは赤く、すべての側面から16pxのインデントを持ち、容器の中心にある必要があります。」 Freimvorkiは、React、Vue、Swiftui、Jetpackのようなものです。この原則を使用するだけです。
なぜ「Pixel Perfect」が多くのデバイスで宣言的なマイルで動作しない
iPhone 15 Pro Max、Samsung Galaxy Fold、iPad Pro、および4K解像度で等しく見栄えの良いアプリケーションを作成すると想像してください。これらの各デバイスには、画面解像度、ピクセル密度、パーティ、および物理サイズが異なります。
宣言的アプローチを使用する場合、システム自体は、すべてのパラメーターを考慮して、特定のデバイスに説明されたインターフェイスを表示する方法を決定します。厳しい座標ではなく、ルールと依存関係を設定します。
* 適応性と応答性:宣言マイルの主な目標は、適応的で応答性のあるインターフェイスを作成することです。これは、読みやすさを壊して維持せずに、インターフェイスが画面のサイズと方向に自動的に適応する必要があることを意味します。各デバイスで「Pixel Perfect」を試みた場合、同じインターフェイスの無数のオプションを作成する必要があります。
* ピクセル密度(DPI/PPI):デバイスのピクセル密度は異なります。スケーリングを考慮しない場合、高密度のデバイス上の100の「仮想」ピクセルのピクセルの同じ要素は、低密度デバイスよりもはるかに小さく見えます。宣言的なフレームワークは、物理的なピクセルによって抽象化され、論理ユニットを使用します。
* 動的コンテンツ:最新のアプリケーションのコンテンツは、しばしば動的です – その体積と構造は異なる場合があります。ピクセルに激しくぼろぼろにした場合、テキストや画像の変更はレイアウトの「崩壊」につながります。
* さまざまなプラットフォーム:さまざまなデバイスに加えて、異なるオペレーティングシステム(iOS、Android、Web、デスクトップ)があります。各プラットフォームには、独自の設計、標準コントロール、フォントがあります。すべてのプラットフォームで完全に同一のピクセル完璧なインターフェイスを作成しようとすると、不自然なタイプとユーザーエクスペリエンスの低下につながります。
古いアプローチは消えませんでしたが、進化しました h2>
インターフェイスへのアプローチは、「必須」と「宣言」の間のバイナリ選択ではないことを理解することが重要です。歴史的に、各プラットフォームには、インターフェイスの作成に対する独自のツールとアプローチがありました。
* ネイティブインターフェイスファイル: iOSの場合は、Android-XMLマーキングファイルのXIB/ストーリーボードでした。これらのファイルは、ピクセルに最適なWysiWygレイアウトであり、エディターと同様に無線に表示されます。このアプローチはどこにも消えておらず、開発を続けており、最新の宣言的なフレームと統合されています。たとえば、AppleとJetpackのSwiftuiはAndroidで構成され、純粋に宣言的なコードのパスで出発しましたが、同時に古典的なレイアウトを使用する機会を保持しました。
* ハイブリッドソリューション:多くの場合、実際のプロジェクトでは、アプローチの組み合わせが使用されます。たとえば、アプリケーションの基本構造は宣言的に実装できます。特定のために、要素の正確な位置決めを必要とするため、プラットフォームの詳細を考慮して、より低レベルの命令的な方法を使用するか、ネイティブコンポーネントを開発できます。
モノリスから適応性への
デジタルインターフェイスの世界は、過去数十年にわたって大きな変化を遂げてきました。固定許可を持つ固定コンピューターから、さまざまなユーザーデバイスの指数関数的な成長の時代になりました。今日、当社のアプリケーションは次のことで等しくうまく機能するはずです
* すべてのフォームファクターと画面サイズのスマートフォン。
* タブレット独自の方向モードと分離画面があります。
* ラップトップとデスクトップさまざまな許可証のモニター。
* テレビとメディアセンター、リモートで制御されています。テレビでさえ、最小限のボタンを備えたApple TVリモートのように単純なものになる可能性があることは注目に値します。インターフェイスは、特定のリモートコントロールと対話する「方法」を追加することなく、「まるでそれ自体のように」機能するはずです。
* ミニマルな画面を備えたスマートウォッチとウェアラブルデバイス。
* 仮想現実ヘルメット(VR)。空間インターフェイスに対するまったく新しいアプローチが必要です。
* 拡張現実デバイス(AR)、現実世界に関する情報を適用します。
* 自動車情報およびエンターテイメントシステム。
*そして、家電製品:感覚スクリーンを備えた冷蔵庫と、スマートオーブンとスマートハウスのシステムへのインタラクティブなディスプレイを備えた洗濯機から。
これらの各デバイスには、物理的寸法、パーティー比、ピクセル密度、入力方法(タッチスクリーン、マウス、コントローラー、ジェスチャー、ボーカルコマンド)、および重要なことに、ユーザー環境の微妙さ。たとえば、VR Shleshには深い浸漬が必要であり、外出先でのスマートフォンの高速で直感的な作業が必要ですが、冷蔵庫のインターフェイスは簡単で大きくて、迅速なナビゲーションを使用する必要があります。
古典的なアプローチ:個々のインターフェイスをサポートする負担 h2>
デスクトップの優位性と最初のモバイルデバイスの時代において、通常のビジネスは、個々のインターフェイスファイルのの作成とサポートでした。
*  iOS に基づく開発は、xcodeでストーリーボードまたはxibファイルを使用する必要があることが多く、Objective-cまたはswiftのコードを作成しました。
*  android  XMLマーキングファイルとJavaまたはKotlinのコードが作成されました。
* WebインターフェイスはHTML/CSS/JavaScriptをオンにしました。
*  c ++アプリケーションの場合さまざまなデスクトッププラットフォームで、特定のフレームワークとツールが使用されました。
* Windows では、これらはMFC(Microsoft Foundationクラス)、手動描画要素を備えたWin32 API、またはダイアログウィンドウとコントロール要素のリソースファイルを使用していました。
*グラフィックインターフェイスを直接制御するためのココア(Objective-C/Swift)または古いカーボンAPIが macos で使用されました。
*  linux/unixのようなシステムでは、GTK+やQTなどのライブラリがよく使用され、XMLのようなマーキングファイル(QTデザイナーの.UIファイルなど)または要素の直接ソフトウェアの作成を介して、インターフェイスを作成するためのウィジェットとメカニズムのセットを提供しました。
このアプローチにより、各プラットフォームを最大限に制御できるようになり、特定のすべての機能とネイティブ要素を考慮することができます。しかし、彼には大きな欠点がありました。努力の複製とサポートのための途方もないコスト。設計または機能のわずかな変更には、実際には独立したコードベースがいくつかの権利を導入する必要がありました。これは、開発者チームにとって本当の悪夢になり、新しい機能の出力を遅くし、エラーの可能性を高めました。
宣言マイル:多様性のための単一言語 h2>
宣言マイルが支配的なパラダイムとして登場したのは、この急速な複雑さに対応していました。 React、Vue、Swiftui、Jetpackのようなframwsはを構成します。
宣言的アプローチの主なアイデア:システムがすべての要素を描画する方法(命令)を「どのように」(命令したいか(宣言)」と説明する代わりに。インターフェイスのプロパティと条件を設定し、フレームワークは特定のデバイスに最適に表示する方法を決定します。
これは、次の重要な利点のおかげで可能になりました。
1。プラットフォームの詳細からの抽象化:宣言的なfraimvorkiは、各プラットフォームの低レベルの詳細を忘れるように特別に設計されています。開発者は、単一の転送されたコードを使用して、より高いレベルの抽象化でコンポーネントとその関係を説明します。
2。自動適応と応答性: freimvorki 自動スケーリング、要素のレイアウト、およびさまざまなサイズの画面、ピクセル密度、入力方法へのレイアウトと適応の変更について責任を負います。これは、FlexBoxやグリッドなどの柔軟なレイアウトシステムの使用、および「論理ピクセル」や「DP」に似た概念を使用して達成されます。
3。ユーザーエクスペリエンスの一貫性:外部の違いにもかかわらず、宣言的アプローチにより、デバイスのファミリー全体で行動と相互作用の単一のロジックを維持できます。これにより、テストプロセスが簡素化され、より予測可能なユーザーエクスペリエンスが提供されます。
4。開発とコスト削減の加速:多くのプラットフォームで作業できるのと同じコードを使用すると、開発とサポートの時間とコストによってが大幅に削減されます。チームは、同じインターフェイスを繰り返し書き直すことではなく、機能と設計に焦点を合わせることができます。
5。 Freimvorkiは新しいテクノロジーをサポートするために更新でき、すでに書かれたコードがこのサポートを受け取ることは比較的シームレスです。
結論 h2>
宣言的なマイルは、単なるファッションのトレンドではなく、モノのインターネット(IoT)やスマート世帯家電などのユーザーデバイスの急速な開発によって引き起こされる必要な進化ステップです。これにより、開発者と設計者は、各プラットフォームの無限の特定の実装にownれなくなることなく、複雑で適応的で均一なインターフェイスを作成できます。各ピクセルの命令制御から目的の状態の宣言的記述への遷移は、将来のインターフェイスの世界では、表示される画面に関係なく、柔軟で、転送され、直感的であるであるべきであるという認識です。
プログラマー、デザイナー、ユーザーは、この新しい世界で生きる方法を学ぶ必要があります。 特定のデバイスまたは解像度に合わせて設計されたPixel Perfectの追加の詳細は、開発とサポートのために不必要な時間コストにつながります。さらに、このような過酷なレイアウトは、限られた入力テレビ、VR、ARシフトなどの標準以外のインターフェイスを備えたデバイスや、将来の他のデバイスでも機能しない場合がありますが、今日でもわかりません。柔軟性と適応性 – これらは、現代世界で成功したインターフェイスを作成するための鍵です。

