Related
In your company, who does design and develop style, layout in xaml, Designers? or Developers?
Are there enough designers who are able to deal with xaml or blend?
Are they willing to touch Blend?
In my company, Developers do all those jobs except making images.
I am so confused nowadays if this is right direction.
Give me a advice.
I'm the developer and the designer too. I think developers love blend, because it is very simple, and it is easy to create attractive interfaces (the greatest programming/design IDE i've ever seen). But i never met a silverlight designer, who is not a developer too. I think it will be happens in the future, that completely separate design and coding, but not now. Maybe in a new programmer generation :). I think its very important for a silverlight/wpf designer, to know, how this new binding concept works. Programmers knows it already, so it is much easier to do coding and design for yourself, than ask a designer to learn blend and the silverlight/wpf things, because they think it's coding...but blend is simply clicking...but you must learn it, and you must understand xaml hierarchy and syntax and everything...
So i think they must go to a training class, with developers, and learn the new things together. Than they can separate things. Designers are much lazier than developers, but they need learn new things too.
I think i'm lucky, i love design & coding too.
A Coder's perspective:
Silverlight is certainly gaining momentum, but in the design industry it is a relative newcomer.
I personally know of only one UK company that actually uses specialist "XAML designers" side-by-side with their Silverlight coders (but the results there are not anything special). I'm sure there are more but it says something that I have not seen many.
At my current major client, there is a real need for GUI design work, but that will be done by traditional designers (e.g. in Photoshop) and although I am a hard-core coder by trade I will likely be the one that "Blends it". Luckily I really like working with Blend (and Sketchflow). I rate it highly for coders, as it does so much more than the VS 2010 editor, and I tend to do only XAML tweaks in VS 2010 (and all my code of course).
Designers are not lazier. They have a different skill set - one that I do not have myself and have come to admire. The really good ones can produce amazing results, but even the worst ones are much better at pure design than me. I do not expect non-coders to sit at a desk for 12 hours straight solving problems like we are prone to do (but non-coders usually have better social lives) :)
It is time to write the GUI for my project, and I am wondering what technology to use. I did most of my .NET GUI development in .NET 1 & 2, so I know Windows Forms reasonably well. I am vaguely aware of WPF, but not yet attempted to "get into it".
Are Windows Forms dead or dying? Is WPF a good technology to learn? Is it the future, just a phase, or a technology that can walk hand-in-hand alongside Windows Forms?
Also, any experiences will be good to hear, especially from people who have used both extensively. How did you find implementing a similar feature in both frameworks?
Are WinForms dead or dying?
No. It is not significantly developed further (i.e. no new major additions), but it is fully supported in .NET 4, for example.
Is WPF a good technology to learn?
Yes.
Is it the future, just a phase, or a technology that can walk hand-in-hand alongside WinForms?
It is intended that you eventually move over to WPF, but it is also understood that there are large existing codebases written in WinForms, and there's no business case for rewriting them in WPF. Hence WinForms remains supported.
Also, any experiences will be good to hear, especially from people who have used both extensively. How did you find implementing a similar feature in both frameworks?
Broadly speaking, WPF is much more expressive. If you look at frameworks as set of Lego bricks that can be put together in various ways, WinForms bricks are much larger - each one does a lot - and therefore there are fewer ways to put them all together. Quite often, when you need something-but-not-quite like what an existing brick does, you have to write your own from scratch. In WPF, the bricks are significantly smaller, and can be combined in many interesting and even surprising ways.
For a concrete example, consider how WPF Button is a container that can host arbitrary content - not just image+text as in WinForms, but absolutely any other WPF control or set of controls.
WPF is also much easier to write dynamic layouts in compared to WinForms. The latter has layouts, too, but the problem is that they're a royal PITA to work with in visual designer, and writing WinForms component initialization by code is very tedious. With WPF, you just write XAML markup by hand, and layouts (and control trees in general) are very naturally represented in XML.
Partially stemming from the above, I find that WPF is easier to localize. For one thing, it's because you really do need dynamic layouts for localizability (since you don't know in advance the length of the strings in all locales). WinForms solution to this is to consider not only text labels, but also control position and size, as "localizable property" - so the translator is supposed to rearrange controls on the form himself if he finds that strings don't fit. In WPF, dynamic layouts are the default approach, so localizer just deals with strings.
WPF binding framework is rather powerful (even if verbose, thanks to lack of inline converters), and heavily promotes MVP, and, in general, model/view separation. This is possible to achieve with WinForms in 2.0+, and I try to do that there as well, but it's more tedious, especially with respect to null handling, and sometimes can be rather buggy.
One particular pain point is the way WinForms designer interacts with source control. There are two similar problems here. First of all, designer serializes edited form as code, and sometimes very minor changes in layout can make the designer generate completely different code (this is particularly noticeable if you edit toolbars) because it shuffles the code lines around - i.e. in reality it changed a single property value on one line, but it also reordered everything. This leads to very much noise in history (it's nigh impossible to tell what exactly was changed when looking at diffs), but more importantly, it means that merging such files is a major headache. This usually happens when two people work with the same form at the same time, and then one commits his changes, and the other one tries to commit, finds out that the file was changed in the meantime, tries to merge, sees the diffs, and jumps out of the nearest window.
A very similar problem happens when you use WinForms localizable forms, which pushes some properties to a resource file. Again, the designer very much likes to reorder property values in resource file for any trivial change, with all the same problems as described earlier.
Now as to deficiencies in WPF. A major one is that it's quite a bit more complicated, and may feel unfamiliar to someone with experience only with WinForms, VCL, VB, or other similar "traditional" frameworks. Another problem is that documentation, in my opinion, is not perfect - it usually gives a decent overview, but rarely covers corner cases, some of which can be pretty important. This is the case for WinForms, too, but there are fewer possible combinations there, so fewer corner cases as well.
There's also the issue of third-party components. WinForms had been around for a long time now, and there are plenty of those available for it, and a lot of them are very mature. WPF is comparatively young and still going through growth pains, and so do most third-party solutions for it.
One particular pet peeve of mine in WPF is the way it antialiases text - which is perceived as being of much worse quality compared to plain Windows ClearType by most people, especially on small font sizes; see this bug report for more info. This is fixed in WPF 4, but that isn't released yet, and even when it will be, chances are that you'll want to stick with the tried and true 3.5 SP1 for some time; and the fix isn't backported.
WinForms aren't dead or dying...they just can't provide the same User Experience that WPF can (without A LOT of work). They're just older technology.
WPF is a good technology to learn. It provides the ability to provide a much richer User Experience with less work.
The model for working with WPF is definitely different than WinForms. I've used both (WinForms more heavily than WPF/Silverlight) and the most difficult transitions for me were:
XAML, which isn't as bad if you have experience with another markup language like MXML.
DataBinding
Interface Event Handling (MouseOver effects, Timelines, etc.)
WinForms is far from dead/dying. WPF is simply a newer way to tackling the UI as it promotes things that were more difficult in WinForms. Things like separating the model behind the UI from the actual UI so it can easily be tested is a big factor.
It's definitely worth learning, but make sure to learn "the WPF way" of creating the screens rather than just fitting your WinForms-way into it. It's a different way of coding.
Perspective from 2016:
I don't often advocate chiming in on a question this old, but thought an epilogue may be appropriate on this one. Why? Because even now (2016), I hear developers in corporate environments still asking this question.
Yes, seven years later, WinForms is still alive in corporate environments, and still supported by Microsoft. Google Trends shows a slow, steady decline in interest since mid-2005, with current interest about one-third of 2005's.
WPF made a splash about 2009, but never fully took over as the de facto standard for new UI development. Google Trends shows WPF interest peaking from 2009-2011, then declining faster than WinForms. Current search interest is about half of 2011's, but still nearly double WinForms' current search interest.
So what ARE developers using now? Web-based UIs have exploded in popularity, largely due to the rise of mobile browsing. You could argue over the best way to go about writing a web UI (AngularJS + WebAPI? ASP.NET MVC? React? All are trending upward on Google Trends). Whichever technology you use, it's hard to deny the appeal of writing a (responsive) UI once and having it work on just about all devices and platforms. Cloud hosting services furthered the push to the web by offering virtually instant/infinite scaling with low up-front infrastructure investment.
So today, I'd heartily recommend moving toward a web UI, as it may improve the shelf-life of your app--which often need to last very long in corporate environments. Alternately, if you're a Microsoft-based developer doing mobile development, Xamarin is worth a look.
WinForms will probably be around for a long time to come in corporate environments. They work well enough for many purposes. Many projects are based on WinForms, and many companies will stick with that technology for the duration of projects rather than mix and match.
Having said that, WPF is the future. It is a much more efficient, much more capable UI technology and well worth learning.
WinForms and WPF can coexist in a single application. That will probably be the most common way for them to be introduced to a company (that, and small proof-of-concept projects).
Certainly not.
Winforms are easier to use (Considering you don't know WPF yet) and WPF is quite a departure from the Winforms model.
If you want a simple GUI (standard form stuff) go with Winforms. If you want something a bit more flashy and have the time, go for WPF.
I'm sure there will come a point in the future where WPF is the defacto standard. But for now, I stick with Winforms if I want something quick and clean.
It's worth mentioning that a lot of applications are already using Winforms - meaning maintenance work will often crop up involving WinForms, so don't rite it off just yet.
WinForms is not dead. Google "winforms C# jobs" and you'll find plenty. WPF is the hot stuff but it's still relatively new. It won't be mainstream for another two to three years IMHO.
Here is a good blog post about WinForms and WPF. The overall idea is to choose wisely, meaning that there isn't one winning over the other. Each have a different subset of features.
Making the decision between WPF and WinForms however is a different story. Sure, WPF is the new hotness and WinForms is old and busted but is it the right choice? Obviously "it depends" on the situation and Microsoft is continuing to deliver and support WinForms so it won't be going away anytime soon. So what are the compelling factors to choose WPF over WinForms? Karl hints at choices of WPF over WinForms in his WPF Business Application series, but the reasons might be subtle for some.
I personally prefer WPF because I started as a Web Developer and find the markup XAML to be more natural.
I think it's definitely worth learning WPF before it becomes more mainstream, it's always good to improve your skillset and to have experience and knowledge of newer technologies is always a plus, especially if WPF is to be more widely used in future.
Also, whilst writing xaml mark-up is very different to creating forms, it's not a million miles away from writing html and will probably not be too much of a departure for you if you've done any web development.
Whilst WinForms is an older technology that doesn't mean it will ever disappear though, we still have applications where I work that are written in VB6. Only half of our development department work with .NET - we're split into 3 teams, one team is still using .NET 1.1, another team is using .NET 2 and the team I'm on is using .NET 3.5 (you could say we're the lucky ones!)
We started using WPF for a new project and frankly, it's hard to go back to WinForms. Lots of neat stuff that I can't go withouh anymore.
One word of advice though. Even though you can do much more complex layout with WPF (like it's mentionned, a button, or almost anything really, can host other stuff like image, textbox and even more), some other 'basics' stuff found within WinForm are hard to reproduce.
Example : Before the WPF toolkit came out, WPF didn't have datagrids and datetime picker, so you had to do it yourself. Also, it still doesn't have MaskTextBox, you have to do it yourself or download it from third parties. Last one I ran into which I actually find annoting is with Treeview : the lines between leaves and parents doesn't show.
That being said, still much better than WinForm on most aspects.
we start using wpf in a new project we have
the new application includes a lot of legacy code in winforms.
whenever we want to use old dialog of winforms it is possible.
when you getr use to WPF you don't realy want to go back to winforms. it is just much more easy to do GUI stuff that woul take you lot of time in winforms.
any way it take some time to learn the stuff and be able to use all it's abilities (not just UI but also data binding and commands pattens).
having somone experienced that can help with first architecture can be very helpful.
Is delving into Microsoft's WPF worth it for a programmer who does not have design inclinations and no designer on the team?
I think so. The knowledge you take away from building simple screens/controls will help when creating custom controls for use across your app if/when a designer is hired. The real beauty is, if you're following MVVM with your WPF app, your UI can later on be more easily tweaked/replaced since the VM layer is already there handling the data behaviors.
I think a distinction should be made between design and user-experience. You can design a good GUI experience for the user with no creative flair or design inclination, just common sense and the ability to get feedback from users.
Ensuring a consistent interface, good flow and sensible cues are not design decisions in the arty sense of the word. It is like an architect making sure that the front door of a property is obvious ... and letting a designer pick the ornate decoration of the door. Art-design (color, pattern) is a creative design because many combinations work whereas GUI design is user-centric and so it has to work with their expectations which (unless designing a new application) tend to follow fixed convention, expectation and visual cues.
Any type of GUI experience is good for a programmer ... just as the API is the interface to the library the GUI is the interface to the user (the bit of the chain that counts).
Even though I don't design windows GUIs I make it a priority to sample good design in the area to stay ontop of user-expectations of software's capability in dry areas such as text-input. If users have grown to expect predictive input in most fields ... it helps to know when programming non-GUI elements.
Bit long-winded, but good reasons I think :)
I don't think WPF is all about designing with development. It's true that it does provide a great separation but it's not the only thing it does. It was great support of Data Binding which itself can save you tons of lines we repeat over and over again. Plus in order to make a good looking GUI, you don't really need great skills. I work with designer here and I don't think that I"m getting something big out that I coudln't do myself. But there are some really good designers as well. Also if you browser around some wpf apps, you'll get a good sense of how to design good wpf apps.
For a developpeur who as to do a project with WPF or Silverlight (xaml code), is it trial to learn some design (basics) and to handle blend? Beacause in France there isn't much blend professional (compare to photoshop users) and the price/day of a blend designer is very high.
What I am sure is there i ain't no artist, but it could be interesting/fun to learn something that different then pure code. So my question is mainly for designer or developpers that had to learn some design, is it that hard for a custom design?
The principle of design are not difficult to learn but they're not always easy to put into practice and that's why it's considered an art rather than a skill. Certainly WPF/Silverlight is a designers dream as far as desktop UI is concerned since it's VERY flexible so you'll find few restrictions on what is possible when compared to other technologies. Blend works well with them too and it's not that tough to learn.
To start learning design as a developer, i'd suggest you take in as much material as possible and pratice,..a LOT. Read design blogs like the ones here and read plenty of books. Some good starter books are The Non Designers Design Book, The Design Of Everyday Things and Don't Make Me Think. I know they all really help when i started to look into UI and interaction design.
Hope that helps.
A great way to find your way in the design world is the Principles of Design Series on Microsoft Showcase. These videos explain things like Rythm and Unity.
There are a lot of other videos that should help to find your way around Expression Blend and Silverlight.
One thing that works for me all the time is to look what others do and use that for inspiration in you own design. Just google-image or bing-image for you are designing or see if it is in the Infragistics UX explorer.
I understand your question as I went through the same thing. I've done plenty of web sites over the years, but I never felt as though they had the "zing" a good graphic artist could provide. Because of this, I had concluded some time ago that to really take my skills to the next level I had to learn at least some graphic design, but I never did anything about it.
That changed when I started learning WPF. I quickly decided that I needed to learn some basics, especially when I started using Blend which was a whole new world after living in Visual Studio for so long.
To jump start my graphic artist education, I took an introductory course at our local community college. It was worth every penny: I was exposed to principles of design and some key software products like Adobe Photoshop and Illustrator. Understanding them made Blend finally "click" for me. The experience has proven invaluable to me as a WPF developer, and I would recommend it to anyone interested in UI work.
WPF Silverlight have a lot of power however even when mastered it takes a lot of time to design a simple form say using a tab control using lots of grids with rows and columns and stack panels than it would on a normal desktop. Also it can be quite sloppy looking back at the XAML code just from a design point of view unless your using lots of windows which i try to avoid, i would rather have a tab control with each tab acting a a window. Anyway from a design point of view it is much more time consuming than a desktop application. You will find a lot of developers will use it as they are not good in code behind. So it depends on the program you are writing. ?You can make your program look very good from default controls and the listview is always a great control. Many will disagree because they think they are great developers and most likely will talk the usual no one want's to hear!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
The rich presentational capabilities of WPF and Silverlight mean developers like me will be working closely with graphic designers more often these days, as is the case in my next project.
Does anyone out there have any tips and experience (from both points of view) on making this go more smoothly?
For example, when I mentioned source control to a designer recently, I was quickly told you can't source control graphics, images etc, so it is a waste of time. So I responded: ok but, what about XAML files in WPF/Silverlight?
Scott Hanselman spoke about this topic in a podcast, but he focused more on the tools, while I'm more interested in the communication issues/aspects.
One of the things I've discovered is that how you as a developer design your code greatly affects what the designer can do with it. Often you download a Silverlight or WPF sample application from the web and open it up in Blend, just to have Blend crash on you because the code doesn't run well inside the designer. If it doesn't crash, it seldom look anything like the running application.
I recently gave a talk at Tech Ed Australia and New Zealand about techniques you can apply to "design for designability". A short bulled list is included:
Write code that can take advantage of data binding. The Model-View-ViewModel or the presentation pattern is a good fit for this.
Supply "design time" stubs for your service dependencies. If the class you are binding against makes web service calls be sure to replace the web service client with a stub class that returns "dummy data" that the designer consumes inside blend. This can easily be done through IoC and Dependency Injection, injecting one implementation if HtmlPage.IsEnabled == false.
By using data binding you can limit the number of "named elements" you have in your XAML file. If you write allot of code behind you end up coupling your C# code against named elements such as txtName or txtAddress, making it easy for the designer to "screw up".
Use a command pattern instead of code behind click event handlers. By loosely couple the invoker of an event from the handler you can have less named elements, and you give the designer the freedom to choose between a Button or a Menu Item to invoke a specific command.
Test your code in Blend! Even if you consider your self a pure developer you should test that your code is consumable by a tool, and strive to get a best possible experience at design time. Some would argue that a tool shouldn't effect your software design, just as some one complains about "design for testability", and making software design decisions just to make the code more testable. I think it's a smart thing to do, and the only way you can get some real designer-developer work flow going.
Other tips would be to start small. If your designer is new to XAML, WPF and Silverlight, start by introducing them to the project team, and have them do some basic designs in the tools they know. Let them do some buttons and illustrations in Adobe Illustrator, and export it to XAML, and show them how you can leverage their design assets directly. Continue by introducing more and more, and hopefully they get interested and want to make the switch to Blend. It's quite a learning curve, but it sure is worth it!
Good luck!
PS: I have written allot about patterns and making designer friendly code on my blog at http://jonas.follesoe.no. You can also find links to a video recording of my Tech Ed talk, as well as lots of links to further reading on the topic.
I have spent 4 months on a project working extremely closely with a designer and he has still not picked up the basic idea of CVS (which is not my choice of source control system). I'm talking template files, JavaScript and CSS here. He's not stupid, it's just one of these things that makes his job harder so he resists fully commiting himself to it.
In my case I had to really hammer home the point that almost all of my JavaScript depended on the mark-up and when he changed his pure CSS, DIV-based layout into a table-based one without telling me then all my JS is going to break.
Often during the course of the project myself and the designer, who I get on with quite well and play soccer with outside of work, had very heated exchanges about our respective responsibilities. If I didn't know him well enough to just get past these exchanges then I think it would have created an unbearable working environment. So I think it's important you establish between you both and with some sort of manager or project supervisor exactly what is expected of both parties during the project.
In my case there have been very few problems lately, because the situation with CVS has been sorted out as well as the idea that he can't just go and change the mark-up whenever he feels like it. Rather than try and create template files and work on them directly, the designer only works on static files and its my responsibility to plug them into my template files.
It's all about communication and a little bit of compromise on both sides.
This may be a bit off topic (I'm replying specifically to your question about source control and graphics), but you can put binary data (images etc.) into source control (and in my opinion in a lot of cases should) -- they just take up more disk space and you can't use a diff view to analyze what has changed in any meaningful way, but what you do gain is a history of commit messages documenting each revision, rollback ability and the ability to easily archive (tagging a revision in SVN terms) all files (be they visual assets, documentation, source code, whatever) belonging to a specific release/version together. It's also easier for your build system to just fetch everything required for building a specific version of your software from the source control.
Involve the graphic designer in early design and architecture sessions.
You want to involve them to reveal misaligned assumptions and to establish a pattern of working together rather than throwing things back and forth over the wall.
Originally, it was envisioned that professional designers would work in Expression Blend, and developers would work in Visual Studio, making changes to a single shared set of source files. While it is certainly possible to do that (so long as you are careful to check regularly that you haven't broken something expected by the other dev. or design tool), many members of the developer community, including some inside Microsoft, have discovered benefits in keeping Blend and Visual Studio project activity SEPARATE -- even to the point of manually cutting and pasting carefully-refactored versions of Blend-generated Xaml into the "official" VStudio project source, rather than allowing designers and developers operate directly on a single shared code base. Microsoft's User Experience Team in the UK published a video describing the problems they ran into trying to coordinate designer and developer efforts on actual projects.
Real_World_WPF_DesignersAndDevelopersWorkingTogether
One of the main lessons learned is that you can't staff a project with designers and developers who are completely ignorant of each other's domains. Developers need to be familiar enough with Blend that they can provide designers with useful UI shells for the designer to decorate, and useful data "stubs" the designer can design interactivity against, and the designer needs to have enough understanding of development issues that they don't do things like delete controls and replace them with custom visual elements - not realizing that they broke all the functionality tied to the original control.
Microsoft's vision of the designer/developer workflow marriage definitely seems to break down in real life. I have experience working on a fairly large scale WPF project which involved 2 dedicated design resources for about 4 months. Here are some facts that Microsoft seems to often forget.
Designers often prefer to use Macs (designers at my company are 100% Mac - 0% Windows)
Blend doesn't run on a Mac (as far as VM solutions - designers typically don't like geeky solutions like running weird applications in a foreign OS).
Designers use their tools of the trade - Photoshop and Illustrator. Period.
The aggressiveness of today's schedules usually don't provide ample time for designers to learn a totally new application / design environment (like Blend).
So given the above, what I noticed was that this creates a new job type - either a very techy designer or a graphically enlightened programmer. Basically, someone who can take the design assets in raw form - usually .psd or illustrator format and apply these as needed to the application process.
I turned out to be that guy (graphically enlightened programmer). I spent a lot of time exporting XAML from Illustrator files, cleaning them up by hand when necessary, and making these assets easily usable display objects in Blend or VS. There were also times where I would take a a design element and re-draw it using blend ( usually when the original asset was bitmap based and it made more sense to convert it to vector).
My application may not have been typical - as it was extremely graphically rich and resolution independence was one of the main objectives as it needed to look good on multiple resolutions and aspect ratios (think of the difficulties in designing for TV in todays landscape - things have to look good in both low-res SD and scale well up to hi-res HD).
In summary, I think WPF is an awesome technology and absolutely a step in the right direction for Microsoft. It however is not the end-all be-all solution for integrating the designer in the development process - unless you redefine the role of designer.
I'm Felix Corke, the designer from the hanselman podcast you mentioned, so here are a couple of points from a genuine creative as opposed to a developer.
It took a long time to become used to developer tools - I'd never heard of Visual Studio, C# or any type of source control when I first started doing xaml work a few years ago. They were as alien to me as maybe Illustrator or 3DsMax would be to you.
My biggest single point is that the designer can't be expected to know developer practices - please be prepared to do a great deal of hand-holding. You won't have to learn anything new whereas the designer will be launched into a whole new scary side of app development. I made a right mess of a few solutions and checkins (and still do).
Happily, I've learned to become more of an design focussed integrator than a straight creative, and maybe this is a role you need to include in your project. This is the illustration I made for our beauty and the geek - designer/developer session at Mix - if either of you is at too far at either end of the spectrum it can be difficult understand how the other works and what their role should be.
Happy to answer any specific questions!
ps you do NOT want 100Mb+ .psd files in source control ;)
The extent to which designers have come to feel entitled to be distant from the whole of the work involved in building a software product is a much bigger problem that needs to be solved. Don't pander to any designer's expressed right to not have to know how their work gets integrated into the whole.
The kind of stark specialization that has grown up in the designer community is one of the biggest industrial maturity problems that faces the software development industry. It's an extent of specialization that predictably creates more rework and longer cycle times.
This is also true of developers' sense of entitlement to go blissfully unaware of interaction design and implementation.
Extreme specialization is always an exponential multiplier in productivity problems. Solve it organizationally by adopting processes that promote learning cultures. This is the level of maturity that most other production industries have already realized, and that software drags woefully behind.
At every place in a development workflow where handoffs occur between over-specialization, work queues and buffers form. Software remains one of the few industries that doesn't recognize this as one of the biggest problems we face. This is even more exacerbated in the Microsoft community as over-specialization seems ever-more normal due to Microsoft's perpetuation of over-specialization through its tools and guidance. Unless you can afford to waste as much money as Microsoft does in development efforts, you should look to methodologies that are much better informed on questions of flow and productivity.
Consequently, the developer who cannot test and the tester who cannot code is a symptom of the same industrial immaturity.
You won't learn any of this from the Scrum template for TFS. Microsoft was years behind the curve in getting agile thinking in-play even in its most rudimentary forms, and now that we're progressing into Lean thinking, Microsoft will be another three to five years away from trying to incorporate Lean thinking into its product lines. Don't wait for Microsoft to tell you how to shape a team and a workflow. You can learn right now from the people that Microsoft will ultimately pay attention to in a few years.
I'm a big believer in the Integrator approach which is really the role I have had to perform to make our WPF efforts successful.
Laurent Bugnion has a post on this that describes what I'm talking about. Robby Ingebretsen is also a big believer in this approach.
But basically, someone has to cover the 'gap' that exists between the developer world and designer world. What usually happens is that this person comes from either the developer world or the designer world. If they come from the developer world, then they are probably a developer with designer tendencies (they're responsible for look and feel, the visuals in the application, the layout of the screens, etc.). If they come from the designer world, then they aren't afraid of code and the enjoy diving down every now and then to code to get that animation or whatever sparkling.
However, regardless of what world they come from, they usually have to build skills that they never have had before. In my case, I am developer that loves the user interface layer and therefore I would say that I am a developer with designer tendencies. In order to cover that gap and have productive conversations with our graphics designer, I have had to pick up a whole bunch of designer type skills like: learning to use Expression Design, XAM 3D, etc.
Shannon Braun recently gave a presentation at a local developer conference about the developer/designer relationship and the workflows that the community is discovering works for them. I didn't attend the conference, but I thought his slides were a great discussion on the matter.
In my experience, the integrator or "devsigner" role really needs to be involved in this process unless everyone on the (small) team are able to perform this role. This is a very rare circumstance. Usually you will find that developers are very good at developing but aren't so great with design/usability and designers are great with aesthetics/usability but don't want to or are not educated enough to code. Having someone that can crossover into both worlds and "speak the language" is very important.
The integrator needs to coordinate the controls that are being developed with the design assets that are being created by the designers. In our current project, we have 6 active developers and 2 designers from an outside shop. I am the integrator for this project and I spend most of my day in Expression Blend. The developers work primarily in VS creating controls that meet our product spec and the design shop is designing what the end product will look like. The designers are working in Illustrator. My job is to take the Illustrator files and create control styles from them and then apply them to the controls developed by our development team. As we move towards Blend 3 with native support for PSD and AI files, this task becomes much easier.
It is very helpful to create the "look" for your application in a separate solution from the main trunk of the application and then merge your ResourceDictionaries into the main app later. You can get the look and feel correct without getting too caught up in what could still be incomplete controls.
I am going to assume that you refer to RIA projects since your mention of SL.
I have worked one quite a few RIA projects with Adobe designing and developing applications and services.
The best advice I can give you based on based on my 14 years experience as an UX and Visual designer with some programming experience although pathetic compared to you guys.
Accept that you wont understand each other.
The programmer thinks in what functionality should be done, the designer think in how the functionality should behave.
For the developer a button is mostly generic, for the designer it's not the case. Designers think in composition, developers think in frameworks.
So learn to understand that your responsibility is different.
You the developer DO need to think about how generic your code is and can't afford to treat everything as being unique and a hardcoded composition. That is unless you can automate that uniqueness somehow.
The designer DO need to think about the application or service as somehow unique. It might mean that a button is not a button. There might be different sizes or colors or other annoyances.
So make sure you develop a good relationship with the designer by acknowledging that you understand the designers responsibility and make sure he understands yours.
It's not that you are not interested in making the best application in the world. It's just that some of these design decisions takes quite a lot of time.
Make sure that you get very clear on how the designer should deliver to you so you don't waste his or your own time. What format, assets? Naming?
All things that are involved in delivery from one paradigme to another.
And most importantly communicate and respect that they don't know how to do JavaScript or how understand the basic ideas of CVS.
Most developers you wouldn't know how to kern to save their life, what a widow is, how to best layer FireWorks or create a photo-realistic icon, come up with a good tagline or make something understandable to average Joe in 4 words. You don't know what a grid or alignment is and you tend to make things green and purple on black.
And the designer should understand that just because you deal with programming does not mean you are a robot, that you can't have creative ideas and solutions. He should also try to learn how to program at least pseudo program so that he understands what's involved in making your project.
And most importantly. Don't start to debate Mac vs. PC :) Projects have been canceled because of this.
Quite frankly you should tell the designer that images can, should and "will be put in source control mister!" :)
It may be slightly non-conventional and you wont be able to do a merge or anything of that nature, but there will be revisions and a history, etc .. Images can also be embedded in a resource file which goes into source control as well.
XAML can (and should) be put in source control and as its a markup file it will benefit from all of the features.
As far as tips from working with a designer, the one you are working with scares the heck outta me just by that comment alone, so it may all boil down to WHO you are working with. I would explain basic best practices in a nice manner and proceed from there.