HTMLレイアウトに影響する要因（パート1：HTMLエンコーダーの動作）

この記事の対象者

HTMLコーダー -初心者コーダーが後押しするのに役立ちます
あなたの専門レベル; 現在の状況を評価する
プロジェクトで、プロジェクトのネガティブなコースを防ぐために。
もっと食べることが「あるかどうか」を決定しているだけです
HTMLエンコーダーの職業について。 長い間コーディングしてきた人
彼らは記事で自分自身のために何か新しいもの、そしていくつかのものを見つけるでしょう
注目に値しないようにさえ思えるかもしれません。 しかし価値がある
明らかなことは未知数であることを忘れないでください
別の人のための平和、そしてあなたの良い習慣の経験は
誰かにとって難しい状況から抜け出す方法。
リーダーシップ -開催する価値のある活動を見つける
社内でワークフローを改善し、増やす
従業員の経験、コストの削減（削減
計算されない設計時間と会計のコスト超過
以前の活動）と品質の改善。
プロジェクトマネージャー -お手伝いします
いくつかの特定のプロジェクトリスクを考慮する：について学ぶ
以前は不明であったプロジェクト時間吸収体
計画された活動。 実際の人件費について学ぶ
いくつかの活動のため; 現在のレベルを評価および改善する
プロジェクト管理。
Web開発の他の参加者 -より多くの支援
同僚の就業日について学びます。

当初、この記事は表形式でした。
マテリアルのセマンティクス。 ただし、LJで記事を公開し、
貴重な解説だけでなく、「非暴力」、「多くの
bukaff "）だけでなく、材料をやり直すための実用的なアドバイス
テーブルなしで私は彼に従うことにした。 エラー処理
done-記事はブログに掲載されます（どのような言葉
私たちの時間を生み出します）外観とhabrasocietyによって展示されています。
グループ化された要因

HTMLエンコーダー操作

1.レイアウトの初期データと素材。

1.1レイアウト

最悪の場合：
クライアントは、レイアウト用に低品質の素材を送信します。
pdf、ppt、jpg、またはpsd形式の素材が接着されている
レイヤー、ラスタライズされたフォント、アンチエイリアス付きのフォント。
Windows以外のフォント。 必要条件
口頭で説明します（「赤にする」、「ここでやります」）。
良い習慣：
レイアウト資料はPSD形式である必要があります（除外されません）
レイヤーをサポートする別の一般的な形式）。 PSDで
使用されるレイヤーは、その内容に応じて名前が付けられます。
標準のWindowsディストリビューションに含まれていないフォントが使用されます
写真のみ。
影響：
ソースマテリアルの接着層、ラスタライズされたテキスト、およびその他の満たされていない要件は、レイアウト時間の増加につながります。

例：デザインは、画像の形のボタンを使用します。 類似したものを類推する必要があります。 あるべき設計では、約10分かかります。 品質が悪いと、2時間かかる場合があります。

アクション：
1. PM：要件を明確にする段階で、クライアントに
グラフィック要件に関するドキュメントを読む
素材に。 （要件例を含む。できれば
各アイテムのスクリーンショットと説明付き）。
2. PM：コンプライアンスプロセスに顧客を関与させる
サードパーティのデザイナーによる承認の要件。 説明する
グラフィック素材の品質が主に影響すること
彼の将来の顧客（ユーザー）の信頼と態度について
サイト、およびHTMLエンコーダの品質。 （重要
質の高いデザインと美しいデザインを区別する：そうではない
同一のもの）。

1.2再設計

最悪の場合：
クライアントはリンクを（さらに悪いことに）送信または報告します
貧弱なデザインレイアウトのページ（なし
クロスブラウザの問題を含む典型的な要素、
無効なコード）。
良い習慣：
クライアントはコード化されたコードを送信します。 HTMLエンコーダー、PMなど
参加者はその品質と可用性を確認します
要素。
影響：
ページ品質が悪いという事実がクライアントに発表されていない場合
またはPM、結果として生じるすべてのバグに対して責任がシフトされます
HTMLエンコーダー。 これにより、予定外の時間が増加します
バグ修正。
インターネット上にあるページの場合、前に
レイアウトの開始方法、コーダーには再トレーニングフェーズが必要
サイトをローカルで作成します。 この時間を考慮する必要があります。
評価するとき。
例：すべてをローカルにサイトを再作成するには
画像はCSSで記述されているため、レイアウト設計者は追跡する必要があります
各パスは、コピーするためにアドレスバーに書き込みます
各画像をローカルディスクに保存します。 規定の数
CSSイメージは制限されていません。
アクション：
1. PM：明確化フェーズでは、要件に下線が引かれます。
入ってくる素材の品質と悪い結果の重要性：
技術的（バグ、設計時のオーバーラン、不良
拡張性）と信頼感への悪影響
将来の顧客（ユーザー）の態度。
2. PM：クライアントにコード化されたコードを送信するよう依頼する
サイトに投稿する代わりに（FTPアクセスがない場合）。 それは
HTMLエンコーダーがコードを「現状のまま」すぐに使用できるようにします。
再訓練なし。 これに注意することが重要です
また、クライアントによるサイレント追加を防ぐことができます
同じ作業計画を装った新しいアイテム。
3. HTMLエンコーダー：起こりうる問題についてPMに通知し、
エラーと素材の品質。 どのアイテムを書く
新しいデザインに欠けています。 比較を求める
新しいデザインと古いデザインの分析（何が変化しているかを調べる、
追加されたもの、削除されたものなど）。

2.レイアウトの要件（DIV、テーブル、混合）。

2.1ディーバのレイアウト

最悪の場合：
ブロックレイアウトを必要とするプロジェクト（セマンティックレイアウト
DIVを使用）を持たないエンコーダーによって実行されます
必要な経験、またはそこでブロックレイアウトを使用する
それが正当化されない場所。
良い習慣：
ブロックレイアウトは、
次の場合、申請は正当化されます（主観的意見）。
-標準への準拠が必要です。
-これが唯一の可能な実装方法です。
-これらは、クライアントまたはプラットフォームの要件です。
web-developer'ovのバグの数を減らす方法です
HTMLコードを使用する場合;
-クライアントの連絡先を簡素化する必要があります
コード
「ディーバで組版」する機能（および十分に編集する機能
自明でないバグ）で同様の経験が必要
HTMLエンコーダー。
エレガントではないが安定した表形式のレイアウトカバー
典型的なタスクの80％の主要な組版リクエスト。
混合レイアウト-妥協と最高の吸収方法
2つのオプション。
影響：
ブロックレイアウトは存在しない可能性をもたらします
次のようなバグの表形式のレイアウト：
-ブラウザによる不適切なレンダリング。
-誤った、または予測不可能なレイアウト動作
ウィンドウ、フォント、テキストサイズなどのサイズ変更。
-複雑なクロスブラウザのバグ。
そのようなバグは非常に困難で、多くの場合、
ハッキングと文書化されていない機能。 決定なし
常にクロスブラウザで、拡張性と信頼性があります。
アクション：
1. PMおよびHTMLエンコーダー：プロジェクトの開始時に問題について話し合い、
型レイアウトに関する。
午後2時とHTMLエンコーダー：コンサルタントを活用し、
同僚にアドバイスを求めてください。

2.2表形式のレイアウトが必要で、ソース素材は
ブロッキー

最悪の場合：
テーブルレイアウト上にあったプロジェクトの再設計用
クライアントがDIVで完全に実行されたバージョンを提供した
レイアウト。
良い習慣：
お客様から提供された資料がDIVで実行される場合、
既存の実装がテーブルにある場合、それは必要です
混合レイアウトを使用し、可能性も考慮する
一時的な評価中の適応の問題。
影響：
レイアウトのタイプが一致しない場合、そのリメイクを理解する必要があります
新しいタイプに-これは再設計ではなく、実際には作成です
すべてのデザインをゼロから作成します。実際には、
バグの数、矛盾、予期しない状況。

同じ結果（リワークではなく、ゼロから作成）
顧客が使用に適さないレイアウトを送信した場合
プラットフォーム。
アクション：
1. HTMLエンコーダー：混合レイアウトを使用（プロセス
ただし、2つのタイプのジョイントでの適応とバグは回避できません
これにより、作成に比べて時間の消費が最小限に抑えられます
最初から）。
2. PM：同様のことを評価する際に理解し、検討する
設計状況はそのままではありません。 最終結果
過去のソリューションとクライアントの共生を表します
オプション。 イノベーションにはバグが多く、増殖します
指数関数的に。

3.プロジェクトの知識（フォルダの構造、生成するアイテム
デザイン）。

最悪の場合：
HTMLエンコーダーはプロジェクトを認識しません。
良い習慣：
HTMLコーダーは設計を知っています。
影響：
プロジェクトの無知は、手続きが
システム実装の機能により、割り当てられた時間
タスク自体を完了します。 重要な次の記事
時間の無駄-無知が原因で発生したバグや欠陥
システム（非カウントページ、異なるディスプレイ
条件など）。
アクション：
1.ワークフロー：使用するプラットフォームの学習
プロジェクトからの自由時間。 に慣れるためのタスク
プロジェクトを開始する前のシステム。 必須
システムの知識の認定。
2.ワークフロー：プロジェクトでコンサルタントを使用する
タスクコンサルティング（このタスクの他に、彼はプロジェクトに参加しています）
参加できません）。
3. PMおよびHTMLエンコーダー：コンサルタントを活用し、
同僚にアドバイスを求めてください。

4.ソフトウェアおよびハードウェアへの依存度。

最悪の場合：
ハードウェアとソフトウェアへの依存度が高い。
良い習慣：
自律的な並行作業。
影響：
時間に影響する依存関係の例：
-PCハードウェアへの依存（Photoshop（複数
PSDを同時に開く）、Dreamweaver（2〜3ウィンドウ）、TopStyle
（2-3ファイルを開く）、Explorer（またはCommander）、2-3オープン
ブラウザ（FireFox、IE、Opera）および時には動作するプログラム
c PHP-これはワークスペースの非常に典型的な例です）。
-ハードウェアおよびインターネットHTMLエンコーダーへの依存
仕事では、あなたのインスタント結果を見る必要があります
アクション 時々レイアウトは仮定に基づいています
特定のデザインの動作の結果
変化する条件。 時々結果を待つ
作成する時間を超えています。 見るときでも
最小の変更の結果、待つ必要があります
ページ全体の長いリロード（およびページのリロード
プロジェクトごとにエンコーダを何度も使用します）。
-関連するプログラマーおよびプログラムのアクションへの依存
ワークフローで。 SVN（および他の
バージョン管理システム）は、保存するだけでなく
コードだけでなく、開発の並列化、時には
svnの更新と復元をいじって開発する代わりに
アップグレード後のホストの状態。 接続されています
並行開発者が急進的なものを変えるように、
影響する機能の一部を非表示または追加します
HTMLエンコーダーの仕事。
アクション：
1.ワークフロー（プロジェクトチーム）：話し合う
相互に影響を及ぼし、この提案順序から進む
タスク。
2.ワークフロー：許容可能なPCの電力と速度
インターネット。

5.プロジェクトへのエントリーの段階。

最悪の場合：
キー部分の準備ができていない場合、エンコーダーはプロジェクトに入ります
視覚的な表示に影響する機能または部品。
すでに開発されている可能性のある介入または改良
ページ。 サイトの終わりまで不明のままでした。
良い習慣：
プロジェクトは、エンコーダーと開発者が作業するような方法で実行されます
並列、または開発者の後のエンコーダー。
影響：
回帰には時間がかかります
最初に計算されます。
アクション：
1.ワークフロー（プロジェクトチーム）：話し合う
相互に影響を及ぼし、この提案順序から進む
タスク。
2.ワークフロー：効果的なコミュニケーション
プロジェクト中に、リグレッションを回避または削減
その数、バグを避けてください。
3. PM：中間段階でプロジェクトを監督します。
プロジェクト中のPM制御の欠如
最後にリグレッション、リメイク、および臨検で。 はじめに
開発、コーディング、ストレッチ、ストレッチの前に
コンプライアンスの開発結果を確認する必要があります
仕様の要件と認識。 示すように
練習すると、これがないと次のような状況になります。
-開発に費やした時間、そして方法はありません
改訂のためのリソースを集めます。 忙しい人をそらさなければならない
人々の別のプロジェクトで。
-通常のHTMLコーディングプロセスが壊れています。 欠陥のため
プロジェクトの各部分をやり直して終了する必要がある
これにより、作業が完了したようです。
-緊急作業、コスト超過、バグ。

6.進行中の新たな問題のコミュニケーションと明確化
プロジェクト参加者とのプロジェクト。

最悪の場合：
コミュニケーションが難しい（クライアントとPMまたは参加者の間）
チーム）。
良い習慣：
通信に問題はありません。
影響：
運用上の問題の困難な議論は混合につながります
要件を理解する。 質問があれば
自分で決定し、彼の決定はビジョンと一致しませんでした
クライアント、これはやり直しにつながります=>デザインの損失
時間。
チームのコミュニケーションもプロセスに影響します。 例えば
運用上の問題を頻繁に議論するときにIMを使用する
いくつかのことが非常に難しいため、通信が遅くなります
長い間説明し、すぐにそれをしなければなりません
複数のウィンドウに複数の人がいます。
アクション：
1.ワークフロー： 1つの暗黙的な改善の例
コミュニケーション-WikiのWork Slang Dictionary。 新入社員
使用される単語を難なく読み、理解できる
同僚の語彙から。 プロジェクトチームのメンバーは
コミュニケーションの改善に主導権を握る（使用
論理ツールとハードウェアの両方）。
2.ワークフロー：プロジェクトチームで使用することをお勧めします
すべてのプロジェクト参加者がディスカッションに気付く一般的なチャット
プロジェクト。

7.使用するプラットフォームまたはプロジェクトの条件と制限。

最悪の場合：
プロジェクトチームはシステムまたは作業の要件を知らない
設計を担当するコンポーネント。 やり直さなければならない
新しく認識された要件の下で。
良い習慣：
レイアウトでは、ストレッチするときにシステムの要件が考慮されます。
影響：
制限と条件の形で新たな要件が出現
システムは、変更と適応をもたらします。
予定外の時間の無駄。
例1：現在のファイルを常にダウンロードできるとは限りません
クライアントのサイトのバージョンなので、ローカルで作業する必要があります
一部を切り取り、ロケールに配置します。 より頻繁に
最初にローカルで実行する必要があります
クライアントで同じことを行います。 予定外
時間は、クライアントと時間に対する同じアクションの繰り返しであり、
違いを除去するために費やした（アップロード/ダウンロード/ s
顧客）。
例2：オープンソースは厳しく制限されています
および条件。 したがって、OsCommerceコンテンツカテゴリでは
商品はコード内でしっかりと生成されるため、
HTMLの変更だけでなく、PHPの変更も含まれます。
アクション：
1.ワークフロー（プロジェクトチーム）：話し合う
ボトルネックは、プロジェクトを開始する前にシステムを調べてください。
2. PMおよびHTMLエンコーダー：コンサルタントを活用し、
同僚にアドバイスを求めてください。
3.ワークフロー：問題解決の概要
または、Wiki内の問題自体、知識ベースの作成。

8.資格と経験。 問題を特定する機能
決定し、「概要」。

最悪の場合：
HTMLエンコーダーは不安定なソリューションを使用しますが、興味はありません
仕事の質の改善において、傾向に無関心で、
技術者。
良い習慣：
HTMLエンコーダーはテクノロジーを改善し、トレンドに興味があります。
彼は他の人の経験に精通し、彼自身の開発を作成します。
影響：
経験豊富なスペシャリストが問題を解決する鍵です。
アクション：
1.ワークフロー：ベースの利点を普及させる
知識。 素材を育成し、一元化します。 照らす
通信し、関与します。
2. HTMLエンコーダー：実際に読んだものを使用し、
実験を恐れず、結果を観察してください。 知る
関連する知識分野を研究し、蓄積し、統合する
知識。 慣らしおよび考慮されたオプションの実装を提供する。
3. HTMLエンコーダー：発生する問題の70％
その過程で、誰かがすでに決めました。 文書化
決定は、けいれん的に方法を思い出さないだけではありません
これは前回決定されましたが、そのような考えを取り除くことも
同僚。
続行するには...
出典： Web開発ブログ
そしてそれを改善する方法