asp.netWebフォーム開発および設計部門でどのワークフローを使用していますか
私はデザイナーと開発者が明確に分かれている場所で働いています。私たちはかなり新しい新興企業であり、私たちのチームにとって最良のワークフローとなるものを見つけようとしています。私たちは合計約11人の従業員を抱える小さな会社で、そのうち3人はデザイナー（HTML、CSS、一部のjQueryを扱っています）、3人の開発者は主にASP.NETWebフォームを使用しています。私は開発者の1人であり、設計のコツはありませんが、CSSとjquery/Javascriptに慣れているので、メカニズムなどを理解できます。
そのため、現在、デザイナーがサーバーサイドインクルード、js、jquery、cssなどと一緒にクローバーされたHTML構造を提供するのを待っています。
通常、私たちは彼らのものを回避しようとし、彼らの構造をほぼ同じに保つように惜しみなく試みます。その結果、それを扱うために多くのハックを強制することになります。はい、これは、サーバーサイドインクルードを.aspxページと組み合わせて使用することを意味します。特に、一般的なasp.netWebフォームフローに反するようです。
インクルードをユーザーコントロールに変更し、マスターページなどに共通のHTMLを出力することがありました。その結果、設計チームから多くの吠え声が聞こえました。彼らの主な不満は、マスターページとユーザーコントロールがサイトのメンテナンスをより困難にしているということです。
私は彼らの視点を見ることができます、そして人々が私のワークフローを台無しにしたとしてもそれは好きではありません、私は彼らとそうしていると思います。
プログラマーが作業しているasp.netWebフォーム環境を補完するサイト構造の移動について何度かアプローチしようとしましたが、マスターページの操作の主題が浮かび上がるたびに、設計チームは癇癪を起こします。
私たちの現在のアプローチは、単に多くのハックと回避策をまとめることを余儀なくされているため、設計に溶け込み、率直に言って、プロジェクトに不要な技術部門を追加するだけでイライラします。
私の質問は単純にこれです：あなたとあなたのデザインチームにとってどのワークフローが最も効果的ですか？
デザイナーはマスターページなどの使い方を知っていますか？.
マスターページとユーザーコントロールがどのように機能するか、そして一般的にASP.NETがページをどのようにまとめるかの仕組みをデザイナーに理解させるのは不合理ですか？ （これが彼らの不合理な期待だとは思わない...）
それで、皆さんはどう思いますか？
うわあ。あなたはインテリアデコレーターでそれをより簡単にするためにあなたの家を建てる方法を変えていますか？デザイナーを開発ワークフローから抜け出し、ownワークフローに入れる必要があります。
設計は開発ではありません
デザイナーに彼らが最も得意とすること、つまりデザインを任せましょう。アプリケーションを内部でどのように構成するかを設計者が指示している場合は、深刻な問題があります。マスターページとユーザーコントロールは、ASP.NET Webサイトを構築するときに必需品の近くにあります。HTMLとCSSペイントブラシを使用して、すべてがどうなるかを教えてくれる人は絶対にいないはずです。作業。彼らには、対処するのが非常に難しい独自の世界があります。
デザイナーを押しのけて、彼らに独自の球技をさせましょう。彼らはVisualStudioで働きたいですか？いいでしょう、それらを別のリポジトリに接続してください必要なページをプルダウンしてください必要なときに。
実際のアプリケーションに触れさせないので、フィラーデータがありますか？置き換える実際のデータが得られるまで、そのままにしておきます。それは何も傷つけていません、そして彼らはおそらくあなたにフィラーデータをとにかく渡していたでしょう。
彼らはサーバーサイドインクルードを使用していますか？これは珍しいことではありません。多くのWebデザイナーがこれを行っています。アプリケーションのその部分を実装するときに、HTMLを調べて、ユーザーコントロールに置き換えるだけです。 一度。完了しました。このサイトは必要な方法で機能し、設計者はSSIを使用して独自のリポジトリを保持しているため、独自の作業を行うことができます。
私が働いている場所では、デザイナーがレイアウトを作成し（通常はPhotoshopで）、サイトの一部のページがどのように見えるかを示す写真を渡してくれます。その写真をウェブサイトに翻訳するのが私たちの仕事です。
利点（少なくとも私の観点から）：
- 私たちは関心の分離を維持することができます（デザイナーはそれをきれいに見せます、私はそれを技術的に機能させます）
- デザイナーはhtml/cssをそれほど知る必要はありません
- 私は他の誰かから「特別な」html/css/javascriptを継承しません。 「特別な」コードが必要な場合は、自分で作成できます（デザイナーが必ずしも優れたHTMLなどを記述できないとは限りません。一般的に、同じ視点と目標で問題に取り組むわけではありません。プログラマー。）
デメリット/開発者の作業が増える
- これにより、開発者は、設計者が発明したことを実行するために、興味深い（良いものもあればそうでないものもある）ソリューションを考え出す必要がある場合があります。
- 時々、私たちはデザイナーに彼らのアイデアが実現しないことを伝えなければならないことがあります。これは、なぜそれが機能しないのかを説明し、代替案を提案するために私たちに負担をかけます。
- デザイナーをクライアントのように扱い、彼らと協力して、ウェブサイトのビジョンと私たちが作成するものが同じか十分に近いことを確認する必要があります（つまり、マウスホバーでの色の変更などのUI機能）。
良い/きれいなデザインを思いつく必要がないので、私はこのアプローチが好きです。私は素敵なデザインを採用し、それを開発者が維持するための技術的な災害にはならないものに変換することができます。
TL/DR：開発者は技術的なことをし、デザイナーはきれいな写真を作ります
マスターページとユーザーコントロールがどのように機能するか、そして一般的にASP.NETがページをどのようにまとめるかの仕組みをデザイナーに理解させるのは不合理ですか？
はい、それは一般的な概念を超えています。
上品で効果的なデザインを作成するために、デザイナーがWebサイトの動作方法（基礎となるメカニズム）について考える必要がないように、アプリケーションには十分な 関心の分離 が必要です。彼らはあなたが何を望んでいるのかを（ストーリーボードまたは同様の通信デバイスを介して）知る必要があり、CSSとHTMLを知っていれば非常に良いですが、実際のWebサイトの仕組みは開発者の責任です。
当然のことながら、設計作業は設計者に任せるべきです。グラフィックデザインとレイアウトは、プログラミングとはまったく異なるスキルセットです。プログラマーとして、ヒューマンファクター（つまり、効果的なユーザーインターフェイスを構成するもの）について何かを知っている必要がありますが、一般に、色、スタイルなどの使用はデザイナーに任せるべきです。
注：ASP.NETの代わりにASP.NET MVCを使用している場合、統合作業ははるかに簡単になります。必要な靴の角が少なくなり、ハッキングを大幅に減らして、デザイナーのテンプレートをそのまま使用できます。 ASP.NET MVCは、テンプレートをASP.NETのワールドビューに合わせる必要がないため、この種の作業に適しています。