HTML / CSSを直接​​作成するよりも、完全な画像のモックアップを行うことの利点はありますか？

過去には、多くの企業やWebデザイナーが、設計、マークアップ、バックエンドの2つまたは3つの部分からなるワークフローを使用していました。これらは一般化されており、線が少しぼやけているかもしれません...しかし、あなたは私の要点を理解していると確信しています。

多くの場合、Webデザイナーは「視覚のみ」で、PhotoshopやFireworksなどの画像編集ソフトウェアで非常に詳細なモックアップを作成するだけです。モックアップは、色やタイプの選択から、使用する背景、アイコン、写真、その他の画像まで、Webページのあらゆる面を表示します。しかし、「デザイナー」は、実際のライブの構築と実装に関心を持ちませんでした。外観のみに焦点を合わせていました。

（これらの画像ファイルをレビューすることにより）デザインが承認されると、ステージ2が実行されました-画像ファイルをライブHTML / CSSに移行します。

• シングルシートまたはフリーランス環境では、Webデザイナーはスライスを使用し、内部アプリケーションオプションを介してHTMLにエクスポートした可能性があります。まれな機会デザイナーは、基本的なHTML / CSSのページフレームを構築することができます。

• いくつかの企業環境では、これらのモックアップは、Webデザイナーやデザイナーのための（[花火のために] .pngを.PSD）層状の画像ファイルの形で残るでしょう決して実装を心配していない任意のマークアップやコードを。「デザイナー」は、作成したこの画像モックアップを実装するために、HTMLまたはCSSの構築方法に関心を持つ必要はありませんでした。画像ファイルは、画像ファイルに一致するHTML / CSSの作成を担当する「開発者」に引き渡されました。

このように動作するものがまだいくつかあると思います。ただし、マークアップ言語、つまりCSS3の進歩とブラウザーサポートの改善により、多くの場合、完全なWebページのラスター表現を慎重に構築するのに費やす時間は、ほとんどの場合役に立たなくなります。

現在のマークアップでは、多くのWebデザインのニーズをHTML / CSSを介して直接実装するのが非常に簡単であり、画像アプリケーションの使用は、必要な小さな画像アセットまたは写真の生成に限定されます。（ライブラリやBootstrapなどのテンプレートは、この概念をさらに推し進めています。）

私自身のワークフローでは、私は、特に移動しました離れて、彼らがされない限り、全ページのモックアップから特に要求されました。これは、デザインの速度を改善し、承認されるものが最終的にブラウザでレンダリングされるものに近づくようにするためです。実際、私は長年にわたってフルページのモックアップを作成していません。しかし、私はこの方法を使用するワークフローがまだあることを知っています。

デザイン構築のためにHTML / CSSに直接飛び込む前に、画像編集アプリケーションでフルページモックアップを構築することに本当の利点はありますか？

全ページモックアップを構築する利点は、分業です。

デザイナーと（フロントエンド）開発者の両方を持つ大企業では、デザイナーの仕事は設計することであり、開発者の仕事はコードを書くことです。

この部門を持つことにより、デザイナーはWebサイトの外観、操作感、インターフェイスに時間を費やし、作成方法について何も知る必要がなくなります。彼らは、より高品質のデザインを作成し、コードを必要なことを同時に実行させることに取り組んでいないため、決定をより長く正確に考えることができます。

また、小さな詳細やさまざまな状態を含め、どのように見えるかについて考える必要がないため、開発者はより多くのコードを書くことができます。与えられた時間内にできる限り最善の設計を実装し、別のプロジェクトに進むことができます。

デザイナーが開発者でもある場合、大体の人は多かれ少なかれ、より粗い製品を作成し、迅速に反復して物事をテストするという点であなたの味方になり始めていると思います。これにより、ピクセル完璧なPhotoshopドキュメントを作成するのではなく、アイデアをすばやくテストできます。

ただし、コードを使用しない大まかな反復設計も、特にレイアウトとワークフローで有効かつ非常に有用なアプローチです。マークアップ言語と新しいテクノロジーは、大まかなアイデアですぐに機能するようにはなりませんでした:)

この答えでGuffaを取り上げます。明確にするために、私はGuffaを排除しようとはしていませんが、箇条書きの点は私が聞く非常に一般的なものです。いくつかのカウンターポイントも提供したいと思います。Guffaが間違っていると言っているのではなく、私は正しい。私は単に対位法を提供しています。

1. HTMLとCSSでさまざまなことを行う方法を見つけるために時間を費やすと、設計プロセスの創造的な部分が損なわれます。

これは、コードをクリエイティブと同等に見なさない場合に当てはまります。PhotoshopとHTML / CSS / JSはどちらも、アーティストが作業するための媒体です。塗料が木炭と同じくらい創造的であるように、PhotoshopもHTML / CSS / JSと同じように媒体の創造的であることができます。

HTML / CSS / JSで直接作業することの大きな利点は、その多次元性です。Photoshopは、結局のところ、平らなキャンバスです。HTML / CSS / JSは、流動性、相互作用、アニメーションなどを備えた動的なキャンバスです。

結論として、この場合、コードはより創造的な媒体であると主張します。

2. デザイナーとコーダーが異なる人である場合、たとえデザイナーがHTMLとCSSがかなり得意であっても、コーディングが本当に得意なことはめったにありません。その結果、（さまざまな程度で）肥大化して保守が困難な非効率的なコードになります。

残念ながら、これに対する反論点は、私が頻繁に遭遇することです：専任の役割で働くほとんどの開発者は、より大きな組織（専任の役割がより一般的）で働いており、学際的な知識がないため（多くの場合、プレゼンテーションレイヤーコードが完全に不足しているため）、肥大化したもののいくつかを、これまで見たフロントエンドコードを維持するのが困難にします。

要するに、視覚的なデザインの能力はコーディング能力の指標とはみなされません。さらに一歩進んで、デザインとコーディングを知っている才能あるジェネラリストは、たとえ彼らが最高のデザイナーや最高のコーダーでなくても、単に事実のために、高度に分離されたチームよりも優れた全体的な製品を作成できることが多いと主張します彼らが作成するときに、より大きな画像を見ることができること。翻訳で失われるものはずっと少なくなります。

3. 設計がどのように見えるべきかを明確に把握する前にコードの記述を開始する場合、コードの構築方法に関する情報に基づいていない選択を行います。リスクは、コードを悪化させ、設計の可能性を制限することです。

しかし、コードで設計することは、それがあなたの製品コードであることを意味しません。私が作成したコードのほとんどが純粋に完全に設計のためのものであり、その後プロトタイプを作成するプロジェクトに取り組んできました。終了したら、クリーンリライトを実行します。これには、コーディングの最初のラウンドで多くの「落とし穴」を見つけることができるという追加の利点がありました。

4. HTMLとCSSのコードは、デザインを少し変更するだけでほとんど変更される可能性があり、デザインプロセスがより静的になります。コードで簡単に行える変更のみに制限される危険があります。

それに対する反論は、デザイナーがPhotoshopで簡単に行える変更のみに限定していることです。どちらにしても、それはあまり良い議論ではありません。

Photoshopのモックアップを最初に行わない唯一の理由は、デザイナーがコードの制限を理解していない場合です。クライアントがファイナルで持ち得ないもののコンプをクライアントに与えたくはありません。

PSDがCSS / HTMLで非常に厳密に複製できるものを表す限り（クロスブラウザーおよびクロスメディアの制限がある場合）、Photoshop（またはInDesign-私はそれを編集するデザイナーをいくつか知っています）でそれを行います。画像の操作がより速く、はるかに簡単になりました。CSSでモックアップを作成するのは、それが理にかなっている場合、コーディングする前にコーディングすることです。

設計要素をコード生成要素から分離する理由はいくつかあります。たとえば、次のとおりです。

• HTMLとCSSでさまざまなことを行う方法を見つけるために時間を費やすと、設計プロセスの創造的な部分が損なわれます。

• デザイナーとコーダーが異なる人である場合、たとえデザイナーがHTMLとCSSにかなり精通していても、コーディングが本当に得意なことはめったにありません。その結果、（程度はさまざまですが）肥大化して保守が困難な非効率的なコードになります。

• 設計がどのように見えるべきかを明確に把握する前にコードの記述を開始する場合、コードの構築方法に関する情報に基づいていない選択を行います。リスクは、コードを悪化させ、設計の可能性を制限することです。

• HTMLとCSSのコードは、デザインを少し変更するだけでほとんど変更される可能性があり、デザインプロセスがより静的になります。コードで簡単に行える変更のみに制限される危険があります。