34

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

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

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

Scott Hanselman はポッドキャストでこのトピックについて話しましたが、彼はよりツールに焦点を当てていましたが、私はコミュニケーションの問題/側面にもっと興味があります。

4

12 に答える 12

23

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

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

  1. データ バインディングを利用できるコードを記述します。Model-View-ViewModel またはプレゼンテーション パターンは、これに適しています。

  2. サービスの依存関係の「設計時」スタブを提供します。バインドしているクラスが Web サービス呼び出しを行う場合は、Web サービス クライアントを、デザイナーがブレンド内で消費する「ダミー データ」を返すスタブ クラスに置き換えてください。これは、HtmlPage.IsEnabled == false の場合に 1 つの実装を注入する、IoC と依存性注入によって簡単に実行できます。

  3. データ バインディングを使用すると、XAML ファイル内の "名前付き要素" の数を制限できます。大量のコード ビハインドを作成すると、C# コードが txtName や txtAddress などの名前付き要素と結び付けられてしまい、デザイナーが簡単に「失敗」してしまいます。

  4. コード ビハインド クリック イベント ハンドラーの代わりに、コマンド パターンを使用します。ハンドラーからイベントの呼び出し元を緩やかに結合することで、要素の名前を減らすことができ、特定のコマンドを呼び出すためにボタンまたはメニュー項目を自由に選択できるようになります。

  5. Blend でコードをテストしましょう! 自分自身が純粋な開発者であると考えている場合でも、コードがツールによって消費可能であることをテストし、設計時に可能な限り最高のエクスペリエンスを得るために努力する必要があります。ツールがソフトウェア設計に影響を与えるべきではないと主張する人もいますが、これは、「テスト容易性のための設計」や、コードをよりテストしやすくするためだけにソフトウェア設計の決定を下すことについて不満を言う人がいるのと同じです。これは賢明なことであり、実際のデザイナーと開発者のワークフローを進める唯一の方法だと思います。

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

幸運を!

PS: 私はhttp://jonas.follesoe.noのブログで、パターンとデザイナーが使いやすいコードの作成について多くのことを書いています。また、Tech Ed の講演のビデオ録画へのリンクや、このトピックに関する詳しい情報へのリンクも多数あります。

于 2008-09-09T21:47:23.463 に答える
14

私はデザイナーと非常に緊密に連携するプロジェクトに 4 か月を費やしましたが、彼はまだ CVS の基本的な考え方を理解していません (私が選択したソース管理システムではありません)。ここでは、テンプレート ファイル、JavaScript、および CSS について説明します。彼は愚かではありません。それは彼の仕事を難しくするこれらのことの 1 つにすぎないため、彼はそれに完全にコミットすることに抵抗します。

私の場合、私の JavaScript のほとんどすべてがマークアップに依存していたこと、そして彼が純粋な CSS の DIV ベースのレイアウトをテーブルベースのレイアウトに変更したとき、私のすべての JS が機能していることを教えてくれなかったことを、私は本当に強調しなければなりませんでした。壊す。

プロジェクトの過程で、私とデザイナーは非常に仲が良く、仕事以外でもサッカーをしていますが、それぞれの責任について非常に熱くやり取りしていました。もし私が彼のことを十分に知らずにこれらのやりとりを乗り越えていなかったら、耐え難い職場環境を作っていたと思います。ですから、プロジェクト中に両当事者に期待されることを、あなたと何らかのマネージャーまたはプロジェクトスーパーバイザーとの間で正確に確立することが重要だと思います.

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

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

于 2008-09-09T11:36:51.013 に答える
10

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

于 2008-09-09T11:27:22.080 に答える
6

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

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

于 2008-09-09T11:33:09.803 に答える
6

当初、プロのデザイナーは Expression Blend で作業し、開発者は Visual Studio で作業して、単一の共有ソース ファイル セットに変更を加えることが想定されていました。それを行うことは確かに可能ですが (他の開発者や設計ツールが期待するものを壊していないことを定期的にチェックするように注意している限り)、開発者コミュニティの多くのメンバー (Microsoft 内部の一部を含む) が発見しました。 Blend と Visual Studio のプロジェクト アクティビティを分離しておくメリット - Blend で生成された Xaml の慎重にリファクタリングされたバージョンを手動でカット アンド ペーストして、デザイナーや開発者が単一の Xaml で直接操作できるようにするのではなく、「公式の」VStudio プロジェクト ソースに入れることさえできます。共有コードベース。マイクロソフト

Real_World_WPF_DesignersAndDevelopersWorkingTogether

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

于 2008-09-16T06:54:48.790 に答える
3

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

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

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

幸いなことに、私は単なるクリエイティブではなく、デザインに焦点を当てたインテグレーターになることを学びました。これは、プロジェクトに含める必要がある役割かもしれません。これは私たちの美とオタクのために私が作ったイラストです - Mix でのデザイナー/開発者セッション - あなたのどちらかが範囲の両端にあまりにも離れていると、他の人がどのように機能し、彼らの役割がどうあるべきかを理解するのが難しくなる可能性があります.

代替テキスト

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

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

于 2010-02-17T16:44:50.323 に答える
2

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

Laurent Bugnion は、これについて私が話していることを説明した投稿をしています。Robby Ingebretsenも、このアプローチを大いに支持しています。

しかし、基本的には、開発者の世界とデザイナーの世界の間に存在する「ギャップ」を誰かが埋めなければなりません。通常、この人物は開発者の世界またはデザイナーの世界の出身です。彼らが開発者の世界から来ている場合、彼らはおそらくデザイナーの傾向を持つ開発者です (彼らはルック アンド フィール、アプリケーションのビジュアル、画面のレイアウトなどに責任があります)。彼らがデザイナーの世界から来た場合、彼らはコードを恐れず、時々コードを掘り下げて、そのアニメーションやきらめくものを得るのを楽しんでいます.

しかし、彼らがどの世界から来たかに関係なく、彼らは通常、これまでにないスキルを構築する必要があります. 私の場合、私はユーザー インターフェイス レイヤーが大好きな開発者なので、デザイナー傾向の開発者だと言えます。そのギャップを埋め、グラフィック デザイナーと生産的な会話をするために、Expression Design や XAM 3D の使い方を学ぶなど、デザイナー タイプのスキルをたくさん習得する必要がありました。

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

于 2008-10-02T15:04:51.783 に答える
2

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

ソフトウェア開発業界が直面している業界の成熟度に関する最大の問題の 1 つは、デザイナー コミュニティで育ってきたある種の完全な専門化です。これは、より多くの再作業とより長いサイクル タイムを予想どおりに生み出す専門化の範囲です。

これは、インタラクションの設計と実装に無意識のうちに幸せになれるという開発者の権利意識にも当てはまります。

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

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

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

これは、TFS のスクラム テンプレートからは学べません。マイクロソフトは、最も初歩的な形でさえ、アジャイル思考を導入することにおいて何年も遅れをとっていました。そして今、私たちはリーン思考に進んでいます。マイクロソフトは、リーン思考を製品ラインに取り入れようとする試みからさらに 3 年から 5 年かかるでしょう。 . チームとワークフローを形作る方法を Microsoft が教えてくれるのを待つ必要はありません。マイクロソフトが数年後に最終的に注目するであろう人々から、今すぐ学ぶことができます。

于 2010-08-05T23:56:06.997 に答える
1

SLについて言及してから、RIAプロジェクトを参照していると仮定します。

私はアドビと一緒にかなりの数のRIAプロジェクトに取り組み、アプリケーションとサービスを設計および開発してきました。

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

あなたがお互いを理解しないことを受け入れます。

プログラマーはどの機能を実行する必要があるかを考え、設計者は機能がどのように動作するかを考えます。

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

ですから、あなたの責任は異なることを理解することを学びましょう。

開発者は、コードがどれほど一般的であるかを考える必要があり、すべてを一意でハードコードされた構成として扱う余裕はありません。それは、どういうわけかその独自性を自動化できない限りです。

設計者は、アプリケーションまたはサービスを何らかの形で独自のものとして考える必要があります。ボタンがボタンではないことを意味する場合があります。サイズや色が異なる場合や、その他の煩わしさがある場合があります。

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

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

あなたが彼またはあなた自身の時間を無駄にしないように、あなたがデザイナーがあなたにどのように届けるべきかについて非常に明確になることを確認してください。どのようなフォーマット、アセット?ネーミング?

あるパラダイムから別のパラダイムへの配信に関係するすべてのもの。

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

ほとんどの開発者は、命を救うためにカーニングする方法、未亡人とは何か、FireWorksを最適にレイヤー化する方法、写実的なアイコンを作成する方法、優れたタグラインを考え出す方法、または平均的なジョーに4語で理解できるものを作成する方法を知りません。あなたはグリッドや配置が何であるかを知らず、あなたは物事を黒地に緑と紫にする傾向があります。

また、設計者は、プログラミングを扱っているからといって、自分がロボットであるとは限らず、創造的なアイデアや解決策を持てないことを理解する必要があります。彼はまた、あなたのプロジェクトの作成に何が関係しているかを理解できるように、少なくとも疑似プログラムをプログラムする方法を学ぶように努めるべきです。

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

于 2010-01-21T12:43:57.827 に答える
1

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

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

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

于 2009-04-08T16:58:15.577 に答える
0

率直に言って、画像をソース管理に入れることができる、そうすべきである、「入れるつもりだ!」とデザイナーに伝えるべきです。:)

少し型にはまらないかもしれませんし、マージやその性質の何かを行うことはできませんが、リビジョンや履歴などがあります..画像は、ソース管理にも入るリソースファイルに埋め込むこともできます. .

XAML はソース管理に配置できます (そして配置する必要があります)。マークアップ ファイルとして、すべての機能を利用できます。

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

于 2008-09-09T11:43:58.483 に答える