デザイナーと開発者が協力して働く [終了]

https://stackoverflow.com/questions/51624

09-06-2019
|

質問

WPF と Silverlight の豊富なプレゼンテーション機能により、私のような開発者は、次のプロジェクトの場合のように、最近ではグラフィックデザイナーと緊密に連携して作業することが多くなるでしょう。

これをよりスムーズに進めるためのヒントや経験 (両方の観点から) を持っている人はいますか?

たとえば、最近デザイナーにソース管理について話したとき、グラフィックや画像などのソース管理はできないので時間の無駄だとすぐに言われました。そこで私はこう答えました。さて、WPF/Silverlight の XAML ファイルはどうなるでしょうか?

スコット・ハンセルマンはこの話題について次のように語っています。ポッドキャスト, 、しかし、彼はツールにもっと焦点を当てましたが、私はコミュニケーションの問題/側面にもっと興味があります。

解決

私はあるデザイナーと緊密に協力してプロジェクトに 4 か月を費やしましたが、彼はまだ CVS の基本的な考え方を理解していません (これは私がソース管理システムとして選択したものではありません)。ここではテンプレートファイル、JavaScript、CSS について話しています。彼は愚かではありません。それが彼の仕事を難しくしているだけなので、彼はそれに全力で取り組むことに抵抗しています。

私の場合、私の JavaScript のほとんどすべてがマークアップに依存しているという点をしっかりと認識する必要がありました。そして、彼が私に何も言わずに純粋な CSS の DIV ベースのレイアウトをテーブルベースのレイアウトに変更したとき、私の JS はすべて消えてしまったのです。壊れる。

プロジェクトの進行中、私とデザイナーは仕事以外でもとても仲が良く、一緒にサッカーをするので、お互いの責任について熱く議論することがよくありました。もし私が彼のことをよく知らなかったので、こうしたやり取りを乗り越えることができたとしたら、耐えられない労働環境になっていたと思います。したがって、プロジェクト中に両者に何が期待されているかを、あなたとマネージャーまたはプロジェクト監督者の間で正確に確立することが重要だと思います。

私の場合、CVS の状況が整理され、気が向いたときにマークアップを変更することはできないという考えが整理されたため、最近はほとんど問題がありません。デザイナーはテンプレートファイルを作成して直接作業するのではなく、静的ファイルに対してのみ作業を行い、静的ファイルをテンプレートファイルに挿入するのは私の責任です。

すべてはコミュニケーションと、双方の少しの妥協が大切です。

他のヒント

私が発見したことの 1 つは、開発者としてコードをどのようにデザインするかが、デザイナーがそのコードで何ができるかに大きな影響を与えるということです。Silverlight または WPF のサンプルアプリケーションを Web からダウンロードして Blend で開くと、デザイナー内でコードが適切に実行されずに Blend がクラッシュしてしまうことがよくあります。クラッシュしなければ、実行中のアプリケーションとまったく同じように見えることはほとんどありません。

私は最近、オーストラリアとニュージーランドの Tech Ed で、「デザイン性のためのデザイン」に適用できるテクニックについて講演しました。短い箇条書きリストが含まれています。

データバインディングを利用できるコードを作成します。これには、Model-View-ViewModel またはプレゼンテーションパターンが適しています。
サービスの依存関係に「設計時」のスタブを提供します。バインド対象のクラスが Web サービス呼び出しを行う場合は、Web サービスクライアントを、デザイナーが Blend 内で使用する「ダミーデータ」を返すスタブクラスに必ず置き換えてください。これは、IoC と依存関係の注入を通じて簡単に実行でき、HtmlPage.IsEnabled == false の場合に 1 つの実装を注入します。
データバインディングを使用すると、XAML ファイル内の「名前付き要素」の数を制限できます。大量のコードを背後で記述すると、C# コードを txtName や txtAddress などの名前付き要素と結合することになり、設計者が「失敗」しやすくなります。
クリックイベントハンドラーのコードビハインドの代わりにコマンドパターンを使用します。ハンドラーからイベントの呼び出し元を疎結合することで、名前付き要素を少なくすることができ、デザイナーは特定のコマンドを呼び出すためにボタンとメニュー項目のどちらかを自由に選択できるようになります。
Blend でコードをテストしてください。自分が純粋な開発者であると考えている場合でも、コードがツールで利用可能であることをテストし、設計時に可能な限り最高のエクスペリエンスを得るように努める必要があります。「テスト容易性のための設計」や、コードをよりテストしやすくするためだけにソフトウェア設計の決定を下すことに不満を言う人がいるのと同じように、ツールがソフトウェア設計に影響を与えるべきではないと主張する人もいるでしょう。これは賢いやり方だと思いますし、デザイナーと開発者の本当のワークフローを実現する唯一の方法です。

その他のヒントは、小さなことから始めることです。デザイナーが XAML、WPF、Silverlight を初めて使用する場合は、まずプロジェクトチームに紹介し、使い慣れたツールで基本的なデザインをいくつか作成してもらいます。Adobe Illustrator でいくつかのボタンやイラストを作成させ、それを XAML にエクスポートし、デザイン資産を直接活用する方法を示します。どんどん紹介していき、彼らが興味を持ち、Blend に切り替えたいと思ってくれることを願っています。かなりの学習曲線ですが、それだけの価値は確かにあります。

幸運を！

追伸：パターンとデザイナーに優しいコードの作成については、次のブログに書いています。 http://jonas.follesoe.no. 。また、私の Tech Ed 講演のビデオ録画へのリンクや、このトピックに関する詳細な資料へのリンクも多数あります。

これは少し話が逸れるかもしれませんが (私はソース管理とグラフィックスに関するあなたの質問に具体的に答えています)、 できる バイナリデータ (画像など) をソース管理に配置します (私の意見では、多くの場合そうすべきです) -- ディスク領域をさらに占有するだけで、何が変更されたのかを有意義な方法で分析するために diff ビューを使用することはできません。ただし、得られるのは、各リビジョンを文書化したコミットメッセージの履歴、ロールバック機能、および簡単にアーカイブできる機能です (リビジョンにタグを付ける SVN 用語で) 特定のリリース/バージョンに属するすべてのファイル (ビジュアルアセット、ドキュメント、ソースコードなど) が一緒に含まれます。また、ビルドシステムが、ソフトウェアの特定のバージョンをビルドするために必要なものをすべてソース管理からフェッチするだけでも簡単になります。

初期のデザインおよびアーキテクチャのセッションにグラフィックデザイナーを参加させます。

あなたは、彼らを巻き込んで、間違った仮定を明らかにし、壁を越えて物事を行ったり来たりするのではなく、協力して作業するパターンを確立したいと考えています。

当初、プロのデザイナーは Expression Blend で作業し、開発者は Visual Studio で作業して、単一の共有ソースファイルセットに変更を加えることが想定されていました。確かにそれを行うことは可能ですが、ただし、他の開発者が期待しているものを壊していないか定期的にチェックするように注意している限り。開発者コミュニティの多くのメンバー (Microsoft 社内のメンバーも含む) は、Blend と Visual Studio のプロジェクトアクティビティを分離しておくことの利点を発見しており、慎重にリファクタリングされたバージョンの Blend で生成された Xaml を手動で切り取って貼り付けることさえ可能です。デザイナーと開発者が単一の共有コードベースで直接操作できるようにするのではなく、「公式」VStudio プロジェクトソースを使用します。英国の Microsoft のユーザーエクスペリエンスチームは、実際のプロジェクトでデザイナーと開発者の取り組みを調整する際に遭遇した問題を説明するビデオを公開しました。

Real_World_WPF_DesignersAndDevelopersWorkingTogether

学んだ主な教訓の 1 つは、お互いの領域をまったく知らないデザイナーと開発者をプロジェクトに配置することはできないということです。開発者は、デザイナーが装飾するための便利な UI シェルや、デザイナーがインタラクティブ性を設計できる便利なデータ「スタブ」を提供できるように、Blend に十分精通している必要があります。また、デザイナーは、開発上の問題について十分に理解している必要があります。コントロールを削除してカスタムのビジュアル要素に置き換えるなどのことは行わないでください。元のコントロールに関連付けられているすべての機能が壊れていることに気づいていません。

デザイナーと開発者のワークフローの融合についての Microsoft のビジョンは、現実には明らかに崩壊しているようです。私は、2 つの専用設計リソースが関与するかなり大規模な WPF プロジェクトに約 4 か月間取り組んだ経験があります。Microsoft が忘れがちな事実をいくつか紹介します。

デザイナーは Mac を使用することを好むことがよくあります (私の会社のデザイナーは 100% Mac - 0% Windows)
Blend は Mac 上では動作しません (VM ソリューションに関しては、通常、設計者は外国の OS で奇妙なアプリケーションを実行するようなマニアックなソリューションを好みません)。
デザイナーは、Photoshop と Illustrator という専門ツールを使用します。期間。
今日のスケジュールの厳しさにより、通常、デザイナーがまったく新しいアプリケーション/デザイン環境 (Blend など) を学ぶのに十分な時間がありません。

上記のことを踏まえて、私が気づいたのは、これにより、非常に技術的なデザイナーか、グラフィックに精通したプログラマーという新しい職種が生まれるということです。基本的に、デザイン資産を生の形式 (通常は .psd またはイラストレーター形式) で取得し、必要に応じてアプリケーションプロセスに適用できる人です。

私はその男（グラフィックに啓発されたプログラマー）であることが判明しました。私は、Illustrator ファイルから XAML をエクスポートし、必要に応じて手動でクリーンアップし、これらのアセットを Blend または VS で簡単に使用できる表示オブジェクトにすることに多くの時間を費やしました。デザイン要素を取得して、ブレンドを使用して再描画することもありました (通常は、元のアセットがビットマップベースであり、それをベクターに変換する方が合理的である場合)。

私のアプリケーションは典型的なものではなかったかもしれません。グラフィックスが非常に豊富で、複数の解像度やアスペクト比で見栄えを良くする必要があるため、解像度の独立性が主な目的の 1 つだったためです (今日の状況でテレビ用にデザインすることの難しさを考えてください。低解像度 SD の両方で見栄えがよく、高解像度 HD まで十分に拡張できます)。

要約すると、WPF は素晴らしいテクノロジであり、Microsoft にとって間違いなく正しい方向への一歩であると思います。ただし、デザイナーの役割を再定義しない限り、これは開発プロセスにデザイナーを統合するための最終的なソリューションではありません。

私は Felix Corke、あなたが言及した hanselman ポッドキャストのデザイナーです。そこで、開発者ではなく本物のクリエイターからのポイントをいくつか紹介します。

開発者ツールに慣れるまでに長い時間がかかりました。数年前に初めて xaml の作業を始めたとき、Visual Studio、C#、またはその他の種類のソース管理について聞いたこともありませんでした。おそらくあなたにとって Illustrator や 3DsMax が異質であるのと同じくらい、それらは私にとって異質なものでした。

私の最大の唯一のポイントは、デザイナーが開発者の実践を知っているとは期待できないということです。多くの手を握ることを覚悟してください。新しいことを学ぶ必要はありませんが、デザイナーはアプリ開発のまったく新しい恐ろしい側面に取り組むことになります。私はいくつかのソリューションとチェックインを正しく混乱させました（そして今でもそうしています）。

幸いなことに、私は単なるクリエイティブではなく、デザインに重点を置いたインテグレーターになることを学びました。おそらく、これはプロジェクトに含める必要がある役割です。これは私たちの美しさとオタク、Mix でのデザイナー/開発者のセッションのために作成した図です。どちらかがスペクトルの両端に位置しすぎると、他方がどのように機能し、その役割が何であるべきかを理解するのが難しくなる可能性があります。

alt text

具体的なご質問に喜んでお答えいたします。

ps ソース管理に 100Mb 以上の .psd ファイルは必要ありません ;)

私はインテグレーターのアプローチを強く信じています。これが、WPF の取り組みを成功させるために実際に私が果たさなければならない役割なのです。

ローラン・バニオンは、役職これは私が話していることを説明しています。ロビー・インゲブレッツェンもこのアプローチを強く信じています。

しかし基本的には、開発者の世界とデザイナーの世界の間に存在する「ギャップ」を誰かがカバーしなければなりません。通常、この人物は開発者の世界かデザイナーの世界の出身であることがよくあります。彼らが開発者の世界の出身であれば、おそらくデザイナーの傾向を持つ開発者です (見た目や雰囲気、アプリケーションのビジュアル、画面のレイアウトなどを担当します)。彼らがデザイナーの世界の出身であれば、コードを恐れることはなく、アニメーションやその他のきらめくものを作成するために時々コードに飛び込むことを楽しんでいます。

しかし、どの世界から来たとしても、彼らは通常、これまでに持ったことのないスキルを構築する必要があります。私の場合、ユーザーインターフェイス層を愛する開発者であるため、デザイナーの傾向がある開発者であると言えます。そのギャップをカバーし、グラフィックデザイナーと生産的な会話をするには、次のようなデザイナー系のスキルを大量に習得する必要がありました。Expression Design、XAM 3D などの使用方法を学習します。

Shannon Braun は最近、地元の開発者カンファレンスで、開発者とデザイナーの関係と、コミュニティが発見しているワークフローについてプレゼンテーションを行いました。私は会議に出席しませんでしたが、彼の考えはこうだと思いました。スライドこの問題に関しては素晴らしい議論が交わされました。

デザイナーがソフトウェア製品の構築に関わる作業全体から距離を置く権利をどの程度感じるようになったのかは、解決すべきさらに大きな問題です。自分の作品が全体にどのように統合されるかを知る必要がないというデザイナーの表明された権利を迎合しないでください。

デザイナーコミュニティで成長したある種の明確な専門化は、ソフトウェア開発業界が直面している産業の成熟度に関する最大の問題の 1 つです。専門化が進むと、予想通り、より多くの手戻りとより長いサイクル時間が発生します。

これは、開発者がインタラクションの設計と実装を意識せずに過ごす権利があるという感覚にも当てはまります。

極端な専門化は常に生産性の問題を指数関数的に増大させます。学習文化を促進するプロセスを採用することで、組織的に問題を解決します。これは、他のほとんどの製造業界がすでに認識している成熟度レベルであり、ソフトウェアはひどく遅れをとっています。

過度の専門化の間でハンドオフが発生する開発ワークフローのあらゆる場所で、作業キューとバッファが形成されます。ソフトウェアは依然として、これが私たちが直面している最大の問題の 1 つであると認識していない数少ない業界の 1 つです。Microsoft がそのツールやガイダンスを通じて過剰専門化を永続させているため、過剰専門化がこれまで以上に常態化しているように見えるため、Microsoft コミュニティではこの状況がさらに悪化しています。Microsoft のように開発作業に多額の費用を浪費する余裕がない限り、フローと生産性の問題についてより詳しい情報を提供する方法論に目を向けるべきです。

したがって、テストできない開発者とコーディングできないテスターは、同じ産業の未熟さの症状です。

TFS のスクラムテンプレートからは、これらのことを学ぶことはできません。Microsoft は、最も初歩的な形式であってもアジャイル思考の導入において何年も遅れをとっていたが、現在はリーン思考に進んでおり、Microsoft がリーン思考を自社の製品ラインに組み込むまでにはあと 3 ～ 5 年かかるだろう。。Microsoft がチームとワークフローを形成する方法を教えてくれるのを待つ必要はありません。Microsoft が数年後に最終的に注目するであろう人材から、今すぐ学ぶことができます。

私の経験では、(小規模な) チームの全員がこの役割を実行できない限り、インテグレーターまたは「開発者」の役割がこのプロセスに実際に関与する必要があります。これは非常にまれな状況です。通常、開発者は開発には非常に優れていますが、デザインや使いやすさにはあまり優れておらず、デザイナーは美学や使いやすさには優れていますが、コーディングをしたくない、またはコーディングするのに十分な教育を受けていないことがわかります。両方の世界に行き来でき、「その言語を話す」ことができる人がいることは非常に重要です。

インテグレーターは、開発中のコントロールと、デザイナーが作成した設計資産を調整する必要があります。現在のプロジェクトには、6 人の現役開発者と 2 人の外部ショップのデザイナーがいます。私はこのプロジェクトのインテグレータであり、一日のほとんどを Expression Blend で過ごしています。開発者は主に VS で作業し、製品仕様を満たすコントロールを作成し、デザインショップが最終製品がどのようなものになるかを設計します。デザイナーはIllustratorで作業しています。私の仕事は、Illustrator ファイルを取得し、そこからコントロールスタイルを作成し、開発チームが開発したコントロールに適用することです。PSD および AI ファイルのネイティブサポートを備えた Blend 3 に移行するにつれて、このタスクははるかに簡単になります。

アプリケーションのメイントランクとは別のソリューションでアプリケーションの「外観」を作成し、後で ResourceDictionaries をメインアプリにマージすると非常に便利です。不完全なコントロールにとらわれすぎずに、正しいルックアンドフィールを得ることができます。

SL について言及しているため、RIA プロジェクトについて言及していると仮定します。

私は Adobe と協力して、アプリケーションやサービスの設計、開発を行う多数の RIA プロジェクトに携わってきました。

皆さんに比べると情けないですが、プログラミング経験もあり、UX およびビジュアルデザイナーとして 14 年間の経験に基づいて、私があなたに与えることができる最善のアドバイスです。

お互いを理解できないことを受け入れてください。

プログラマーはこう考える何機能は実現されるべきであり、デザイナーはそれを考慮して どうやって 機能は動作するはずです。

開発者にとってボタンはほとんど汎用的なものですが、デザイナーにとってはそうではありません。デザイナーは構成で考え、開発者はフレームワークで考えます。

したがって、自分の責任は異なることを理解するようにしてください。

開発者は、自分のコードがどの程度汎用的であるかを考慮する必要があり、すべてを一意でハードコードされた構成として扱う余裕はありません。それは、その独自性を何らかの方法で自動化できない限りです。

設計者は、アプリケーションやサービスが何らかのユニークなものであると考える必要があります。それは、ボタンがボタンではないことを意味するかもしれません。サイズや色が異なる、またはその他の不都合がある可能性があります。

したがって、あなたがデザイナーの責任を理解し、彼があなたの責任を理解していることを確認することで、デザイナーと良好な関係を築くようにしてください。

世界最高のアプリケーションを作ることに興味がないわけではありません。ただ、これらの設計上の決定にはかなりの時間がかかるものもあります。

あなた自身の時間を無駄にしないように、デザイナーがどのようにあなたに提供すべきかを明確に理解してください。どのような形式、アセットですか?ネーミング？

あるパラダイムから別のパラダイムへの伝達に関わるすべてのもの。

そして最も重要なのは、JavaScript の使い方や CVS の基本的な考え方を理解していないことを伝え、尊重することです。

ほとんどの開発者は、自分の命を救うためにカーニングする方法、未亡人とは何か、FireWorks をレイヤー化する方法やフォトリアルなアイコンを作成する方法、良いキャッチフレーズを考え出す方法、ジョーの平均を 4 語で理解できるものを作成する方法などを知りません。グリッドや配置が何なのかを知らず、黒地に緑や紫を作る傾向があります。

そして、デザイナーは、プログラミングを扱っているからといって、あなたがロボットであることを意味するわけではなく、創造的なアイデアやソリューションを持てないことを理解する必要があります。また、プロジェクトの作成に何が関係しているかを理解できるように、少なくとも疑似プログラムのプログラミング方法を学ぶように努めるべきです。

最も重要な。Mac vs. について議論を始めないでください。PC :) このため、プロジェクトはキャンセルされました。

率直に言って、デザイナーに、画像ができる、そして「ソースコントロールミスターに入れられるべきである」と伝えるべきです。 :)

これは少し型破りで、マージなどの性質のものは実行できませんが、改訂や履歴などが存在します。画像は、ソース管理に組み込まれるリソースファイルに埋め込むこともできます。

XAML はソース管理に含めることができ、マークアップファイルであるため、すべての機能の恩恵を受けることができます。

デザイナーと仕事をする上でのヒントに関して言えば、あなたが一緒に仕事をしているデザイナーは、そのコメントだけで私を怖がらせるので、すべてはあなたが一緒に仕事をしている人次第かもしれません。基本的なベストプラクティスを丁寧に説明し、そこから話を進めます。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow