痛み

奇妙なことではありませんが、視覚的な部分を開発する過程で、私たちは少なくとも2〜3年遅れています。 まず、古典的で孤立した普遍的なモデル：デザイン-デザイン-レイアウト。 第二に、小さなアプローチ（スタブ）のページと、開発シナリオの予測が困難な場合などの大規模サービスの両方で、同じアプローチが残ります。 しかし、すべてを1つの櫛の下に置きます。 私は個人的に、プロセスと視覚開発システム自体を改善するために世界中で苦労しているキャラクターを知りません。 ほとんどの場合、タイミングについて巧みなフレーズが鳴り、時間管理のすべてのマスターがいるようです。 「Percentage of Time」などの過酷なフレーズの多くは、すべてのロジックを完全に無効にし、同じレベルで生産性を維持することに頼るのは単純です。 大規模なプロジェクトを開発している場合、他のタスクへの1日あたり5〜7回のグローバルな切り替えが完全に麻痺し、メインプロジェクトの開発プロセス全体がノックダウンされます。 さて、ところで、これは一方向の利益を伴う管理の魔法です。



ビジュアルパーツの開発プロセスは、設計とレイアウトの2つの独立した段階です。 アクションの小さなページ（キャップ​​）だけでなく、開発シナリオを予測することが困難な大規模サービスに対しても、まったく同じアプローチが残ります。



さて、この「痛み」の結果について…。 現在、次のような状況です。

設計

明示的な設計エラー

鉄筋コンクリート構造で、柔軟性がなく、構成がうまくできていませんが、変化はありません。 デザインは変化しています。 しかし、法律や規則がなければ（そしてそれらがなければ）、設計段階での基本的なエラーは、時々新しい要素ごとに悪化します。

味わうエクステリアのスタイリング

純粋に審美的には、非常にクールに見えるものもあることに同意します。 そして、ドリブルの多くのいいねが難なく収集されます。 しかし、それが彼らの究極の目標であるなら。 しかし、別のタスクがあります。



巨大企業の枠組みの中で、デザイナーには決定を下す顧客がいることは明らかです。 しかし、これはウェブの一般原則、偏った態度、個人的な「味」に反するものではありません。

レイアウト

この段階での作業は「砂糖」とは程遠いということはすでに理解されていると思います。 柔軟な構造ではなく、疑わしいフレームワーク、サイズ変更を伴わない美的効果のあるレイアウトを取得します。このようなレイアウトは、Webツールのフルスタック上でも実装が難しく、IE8のサポートを余儀なくされています。

グレースフル劣化

設計者は2014チップに導かれ、レイアウト設計者はこれを2009ブラウザーにはんだ付けする必要があります。 設計に近づいたら、2009年の最もクールなサイトを開いて実験することができます。 技術的にIE8に依存しているため、モダンなデザインとのタンデムについて話すのは馬鹿げています。

バグ開発

冗談です。「私たちは20％のコードを書き、80％は松葉杖とバグを書きます。」 スリルを愛する人のために、「開発バグ」という独自の新しいアプローチを考案しました。 しかし、このアプローチで10番目のプロジェクトを開始することは統合失調症に近いです。



時間管理の専門家に再度連絡します。 彼らが修正の時間的ギャップがあると言うとき。 しかし、効果的な作業の20％を考えると、このギャップは5倍にはほど遠いです。

テスト。 審判の日

私たちのテスターは、インターフェースのテストを作成する人ではなく、実際の実行でのみ行われる、MonkeyTestingの一種であるWebサイトレスポンダーです。 その後、すべてがうまくいかないというチケットの束が表示され、個人的な希望が補足されます。 そして、地元のドピルが始まります。 また、プロジェクトは最初の段階からこれらのタスクのために作成されたものではなく、テストの原則が考慮されていなかったことを理解しています。 カットは開発者の手でその場で始まります。 私たちはデザインの美学を忘れてしまい、ゲームから脱落してしまいました。 これはすべてプロジェクトからプロジェクトへとさまようものであり、それぞれの新しい絶望感が増していきます。

治療

診断を決定すると、明らかな決定が下されます。 視覚部分（設計、設計、レイアウト）を担当するチームのすべてのメンバー間で最大限の相互作用を確立する必要がありますが、誰もが共通のガイドラインとツールを必要とします。



ベストプラクティスに基づいて、機能を考慮してエコシステムの構築を開始します。

ガイド

新しいプロジェクトを開始する基本的なスタイルのアセンブリ。 必要に応じて、ファイナライズして、外部および内部の両方で常に最新の戦闘状態にすることができます（つまり、コード）。 構成はおよそ次のとおりです。

タイポグラフィ（フォント、サイズ）

-ヘッダー

-段落

-リンク

色

-基本的な花

-製品の色（同じ会社内にいくつかの異なる製品があります）。 10個のほぼ同一の色、視覚的には同じ、レイアウトには異なるコードを使用しないように、ガイドに可能な色を含めます...

ボタン

すべてのボタンの状態（デフォルト、ホバー、押された状態）

バリエーション（たとえば、アイコン付きまたはアイコンなし）またはサイズ（小、大）など

入力（Samsungは最適な形ではありません）

フォームの参照フォームを指定することは、私の最もマニアックな空想の1つです。 開発者は、夜中に目を覚まし続ける「気まぐれ」をどのように持っているか知っています。 私は間違いなくそれを持っています-フォーム。 彼らは文字通り私を狂気に駆り立てました。残念ながら、最高の意味ではありません。 レイアウトがどれだけうまく機能したかをすぐに確認できる詳細があります。 そして、フォームは明確な指標です。 私たちは彼らと完全に混乱していましたが、サムスンのような高度なサイトでも事態ははるかに悪いです。 トップAwwwardsでさえ、フォームのある状況が嘆かわしいプロジェクトがしばしば現れます。

現在、ガイドには、フォームの各要素の様式があり、これを標準として採用しています。 レイアウト設計者の生活を簡単にし、設計者の可能性を理解するだけです。

プリローダー

私たちにはそれらに対する重要なニーズがあります。 多くのアクションはリブートせずに動的に実行されるため、デザイナーによって常に提供されるとは限りません。

出所

今年、私の頭をひっくり返したのはSourceです。 最終的に、モジュール式のアプローチを構築し、開発者だけでなく設計者にも知覚に便利な方法で伝えることができました。 ここでは、基本的なスタイルを使用して、デザイン自体に焦点を当てます。 便宜上、基本スタイルを基本デザインから意図的に分離しました。

使用例：

登録フォームブロックを作成するタスクがあるとしましょう。

どの要素で構成されていますか：

-タイトル

-テキスト入力

-チェックボックス

-ボタン

-リンク

-アイコン



これらの要素はすべて基本クジラにあり、それらからブロックを収集するだけです。これをSourceに入れます。 ソースは、ブロックの共通ベースです（マークアップが表示されます）。 将来的には、再利用および変更できます。



このようなプロセスでの作業により、より多くの論理と理解が得られ、有用な作業（やり直す必要がない）の割合が大幅に増加し、作業成果物が共通基盤に蓄積され、新しいプロジェクトの力が蓄積されます。

フレーム

私たちのチームは、グリッドと適応性について共通の理解を持っています。 次のようになります。

完全適応

フラクチャポイント（メディアリザーブ）：

スマートフォン

ウィンドウ（デバイス）の幅<768px

コンテナ幅<768px



錠剤

ウィンドウ（デバイス）幅> 768px

コンテナの幅= 750px

デスクトップ

ウィンドウ（デバイス）幅> 992px

コンテナの幅= 970px

ワイドフォーマット

ウィンドウ（デバイス）幅> 1200ピクセル

コンテナの幅= 1170px

バージョニング

コンテンツが特定の場合、多くの機能があり、1つのマークアップを使用する可能性がない場合、2つのバージョンを作成します。

-タブレット/ワイドスクリーン +タブレットの再編成（12列）

- モバイル版 （個別版）+（6列の独自のグリッド）

アニメーション

無視できないデザインの不可避なコンポーネントであり、非常に重要です。 機能部分をぶら下げずに、これを慎重に実装する必要があります。 古いブラウザではすべてが許容できる方法で動作するはずです。 将来的には、 Sourceにも文書化される予定です。 Interaction Designerの形でロールを再配布することができます。 ここから、技術知識+動的設計（マイクロインタラクション）の形式のハイブリッドバンドルが必要になります。



私の意見では、それは単にシックなシステムであり、時には電力と速度を向上させます。 これは、大規模プロジェクトのプロセスの論理的な進化です。 これは、タイトなフレームワークにはなりませんが、ガイダンスを提供し、作業が技術的に正常に実装されることを保証します。



PS

これらの問題の大部分については、「 ブラウザーでの設計 」という記事で説明しました 。 しかし、「古い信者」とそのような飛躍の保守主義者は精神的にトラウマになる可能性があります。したがって、必要に応じて、根本的な対策なしでプロセスをコーミングし、避けられない「 ブラウザーでのデザイン 」の中間準備段階として使用できます。