Related
Feel free to answer the question in the title as generally as I posed it, I offer some more details and specifics below.
Currently I develop and maintain a somewhat legacy business app (ASP/SQL) that is highly customizable allowing for moderate to full customization on: custom fields, forms, views, reports, actions, events, workflows, etc. This customization is necessary in the domain we develop for and has allowed us to build a niche.
I have been reading up on the inner-platform effect and ways of implementing high level user defined customization and have concluded that we do suffer from many of the inner-platform effect problems because essentially we have created a high level abstraction on top of the SQL. The organization of custom fields is implemented in a similar way to the approach found here
http://blog.springsource.com/arjen/archives/2008/01/24/storing-custom-fields-in-the-database/
We use something similar to the meta database method described in that article. All customization is built around this approach and in many ways we suffer from database on top of a database.
The end result is something that looks fantastic on paper yet the more features are added and custom coding is done for clients the more of a mess everything becomes. It seems that the more I read the more I realize this is somewhat of an anti-pattern. It also seems that the more I try to read the more I find so little has been written on the topic. Anyways, I am trying to learn modern approaches to this problem and trying to find more discussion/articles on the topic. Are Database systems such as CouchDB relevant to this type of application?
My question is clearly pretty general. It seems like there is a lot against this kind of application in favor of just "knowing and defining your domain better". Are there any good/better ways to implement this kind of application? I'm not looking for black and white answers, and any further readings on the subject would be fantastic. Thanks for any help.
My answer is be conscious and clear about what is for a plugin to do and what is a user setting. In that case, your platform and your settings are different. Your application provides basic services and is unabashedly a platform. It may also provide an application built on that platform.
So in that case you focus on programmer interfaces instead of implementation possibilities.
The standard advice in CS is to create another level of abstraction, not sure if that's not the problem here.
The only advice I could give is to push as much functionality onto the database, given it's the platform. SQL Server supports custom functions, fields and stored (SQL) procedures.
Either that or try to pull repeated functionality into separate functions in ASP.
From .NET Rocks! Show #488:
Richard Campbell: "In the GDI world we
got a document from Microsoft that
said you will build your apps in
battleship gray and here's now they
should look: File goes here and Help
goes here, and we all got that as
developers. There's no book like that
for WPF. There was this idea I've got
to find the guy in a black turtleneck
and here is his piece of software and
you guys go play nice now."
I think Microsoft now wants every Windows application to look like the ugly, difficult-to-use, hardware-bundled crapware we all hate!
Is there no such best-practices document?
There is a Windows User Experience Interaction Guidelines document that Microsoft makes available. It might be along the lines of what you are looking for, but it isn't specifically a WPF or Silverlight best practices guide.
Nobody has paid much attention to MS ui guidelines in a very, very long time (including MS). It is a big part of the reason why every app on windows looks and behaves different from every other app.
Depends on the guidance you're looking for. The primary reason everything was battleship grey in Winforms was less because the Microsoft guide said it should be (it didn't) and more because that was the default and it was a pain to write it differently. Even now, I would imagine that the bulk of the LOB apps written with Silverlight or WPF will use default colors and styles for exactly the same reasons.
But a lot of the other UI guidelines can still apply. If you want something the looks and feels familiar, there's no reason that you can't make a standard menu bar with File, Edit, View, Help, etc. You can still use the same hotkeys, same commands, same layout for buttons and controls.
Keep in mind though that these guidelines were written with assumptions about software and computers in general that are no longer true. The dominant paradigm has changed and people are far more used to websites with different UI layouts and richer visuals. As a result, visual style is a lot more diverse and people are less likely to be confused by some non-standard layouts and controls. Which doesn't mean that anything goes, just that we should feel less contrained to keeping things in the exact same order and position, lest our customers freak out because they can't find the save button.
In short, the style guide was there because there wasn't enough for a real designer to do but still enough that we developers could make things ugly. Now it's even easier to make really ugly stuff, but there's a lot that a real designer can do to make it nice. So hire one. It's worth it.
My company is doing a fair bit of WPF and Silverlight development recently and we are discovering that while we are darn good at slinging code, our UI design skills lack some "pizazz".
Where does one find a "devigner", as Microsoft calls them? Are there user groups (especially in the Dallas area) with these types of artists/usability experts?
I've had experience with web developers with these skill sets, but not so many with WPF/Silverlight experience and looking on the Internet for these people hasn't turned up much.
Edit: Made this a wiki so I can get a little more feedback without people thinking I'm fishing for points. So far the comments have been helpful.
In my experience, it's pretty tough to find these guys. Posting on job boards that are known to attract exceptional talent (such as 37signals and StackOverflow) is probably your best bet. You will probably end up finding someone who is a developer first and has a hobby-level passion for graphics design. These guys might not do the best work, but they will at least have both of the (mostly mutually exclusive) skills you are looking for.
A second option could be to hire a run-of-the-mill graphics designer and assign one of your developers to work with him and make all of the graphics stuff work in your application. This, of course, requires two people working on a project when you originally planned on having one but I think it's still a viable option.
EDIT: graphic design job postings/information
http://www.youthedesigner.com/graphic-design-jobs/
http://www.allgraphicdesign.com/jobs.html
http://www.coroflot.com/public/jobs_browse.asp
Even though it is getting easier to find these guys, it is still fairly hard as the skill sets are kind of mutually exclusive (as already noted) ... and because there is a training gap (most designers know only the Adobe suite of products (this is the part that is getting better).
I personally think you will find that you have to cultivate this blend of skills and that it may not be found in just one person.
One thing I would encourage you to watch is part 2 of the Hiking Mt. Avalon workshop. This part covers collaboration between the developer and the designer ... and also describes the developer/designer/integrator workflow ... which is a workflow that allows you to cultivate these types of people ... and to just deal with this difficult situation.
I personally think that it is easier to bring a developer closer to the designer world (in order to perform as your integrator/devigner ... because one of the main roles of this person is to understand the platform (i.e. WPF/Silverlight) and how to leverage it to make the designs into real live software ... without harming the design/artistic integrity.
In fact, I am an example of a developer with designer tendencies and often perform the role of integrator. I find myself spending a lot of time with our graphics artists/designers, trying to instill knowledge of the platform into them slowly but surely.
For example, showing them the slider isn't just a static graphic but a living, dynamic thing that can be restyled, retemplated, and have behavior. This is an example of trying to cultivate a designer so that he or she can perform more and more as an integrator/devigner ... and lessening the work the actual integrator has to do ... to the point where the role of the integrator may not even be needed anymore ... or looking at it another way ... having just cultivated a new integrator/devigner.
For the record, I can't stand the term 'devigner' either. I think integrator is a much better description of what the person finds themselves doing (i.e. crossing the chasm between development and design).
See these posts (1, 2, 3) for more info.
Hope that helps! You're not alone in your desire to find these types of people!
Why don't you ask on the MSDN WPF forum?
http://social.msdn.microsoft.com/Forums/en-US/wpf/threads/
What are the characteristics of a good UI designer? How much does one have to have graphical design abilities these days as opposed to interaction design abilities. I see this of growing importance with the advent of WPF and Silverlight.
I personally consider myself good at interaction design, but would like to strengthen my skills in the graphical design area. Is it even possible to learn these skills or are you born with them? Can anybody recommend any good books or resources that would help?
Thanks,
Craig
Try the Non-designer's design book.
In my experience, interface design is a skill all in itself. Graphic designers are good at making wonderfully beautiful but completely confusing and unusable interfaces.
I have a few tricks I use but they mostly involve stealing design elements from well designed apps and websites.
In my experience, the hallmark of a good UI designer isn't necessarily a snazzy, do-it-all, isn't-that-cool solution, but generally one that's almost invisible because it just works with very little help from the user:
Controls and information are laid out logically, intuitively, and consistently.
The ease of accessing a feature is proportional to its frequency of use.
The user finds it almost impossible not to use the product correctly.
It breaks the "rules" when doing so increases its usability.
It's attractive in a "girl (or guy) next door" sort of way. Pleasant to look at, but not distracting.
I would look at any of the edward tufte books.
Jakob Nielson is a good author also.
Most people can look at user interfaces (like they look at anything graphical) and say "that looks good" or "that doesn't look good". What usually makes a graphics person able to produce good-looking material is a willingness to change and tweak things near-endlessly, and even throw out entire lines of effort, until something that looks good emerges. Most programmers do not have the patience for this kind of thing, so their user interfaces look like they were designed by someone who didn't much care what they looked like.
On a deeper level, the concept of "talent" or "innate ability" is most often used as an excuse not to even try something (e.g. "I'm not musically talented, so I'm not even going to try playing the piano"). If you want to become good at something, you have to practice it a lot - there is no alternative.
In my experience, it's a lot easier to find someone to make pretty pages, than someone who can do really amazing, subtle, non-obvious use cases. Use cases that aren't fundamentally table maintenance input forms.
If you're there already, I'd suggest you might think about finding a gui artist to pair-program with.
On the opposite side, if I find something laid out poorly, boxes that don't line up, awkward usage, poor grammar, I assume that the programmer is just as sloppy in their internal code. I expect more bugs in applications with a poor UI.
It's somewhat dated, but I enjoyed "The Design of Everyday Things". Good UI makes the user feel good without them ever noticing.
It is definitely possible to learn these skills.
What a lot of people get confused with is the difference between Art and Design. In many ways the difference between Art and Design is that Art has no understated functionality. It looks good...because it does. With Design there is usually a reason for something to exist. To be a good designer one must understand what good design is and how to efficiently break the boundaries of logic to create something that works with as little cognitive-load as possible. If a new UI design allows me to perform a task twice as fast as the old one then it is better. If I enjoy the experience of using the new one then it is better.
Of course, there is an artistic side to design, and by using flair and creativity a designer can make better designs.
If you want to become better at designing then there are two things you can do:
Read everything you possibly can about design. Find the best design Blog's and stick them in your RSS feed. Read through everything you possibly can about design.
Design something, then design it again, and again, then stop! Now, design something else...
Learn as much as you can about HCI. There are some great HCI books out there, even past the obvious choices. Read as many books as you can find.
Join a design community and monitor the work people produce. If you get the chance, collaborate with someone better than you and see how they tick.
I don't know enough about Art to say if you can learn how to become an artist. All I do know is that everyone is naturally creative; you just have to learn how to let it out in your work, that means learning how to use your tools effectively. Once you can do that then you can experiment.
I like to think that many of the standing HCI concepts we use today haven't just come from calculated thinking; more an artistic vision come to life.
it's all about the end-user's mental model - the abstract structure they form in their minds that leads them to just 'know' what to try as they explore your UI design. As a UI developer you need to clearly understand and then create that mental model for them - and a lotta times it will have nearly nothing to do with the composition of the underlying software system. So don't be surprised if some UIs are difficult to develop.
Once a user begins to visualize and embrace this mental model, they will start to explore and try things based on logically filling in the missing pieces. Good UI design will reward them with expected results, a bad UI will stymy and confuse and they'll wanna hunt you down.
Great UI means:
All the tools/data you see are actionable
That is, everything on the screen has meaning. If it doesn't have meaning or doesn't affect what you're going to do next, it shouldn't be there.
Understanding and using conventions
This is most of the time. Occasionally a great UI designer invents a new interface model (tags were invented to better handle photo-sharing).
Making everything frictionless
If you want to do something, you want to do it in as few steps as possible.
Making everything clean and understandable to the eye
You can't diminish the need for good UI design to at least be palatable to the eye. If you can't digest something visually in a very short amount of time, it might not be a good example of good UI.
About Face is a nice book too.
Subtlety is always something good to watch out. Harsh gradients and some color combinations are just a pain.
As a resource for designing user interfaces in Windows, I'd say that the Windows Vista User Experience Guidelines offers great tips and examples on designing user interfaces.
It provides both good and bad examples of user interfaces from actual Microsoft products, so I'd say it's actually quite objective and a valuable guide to use as a reference when learning about user interface design.
As it is designed as a guide for Windows Vista applications, it would fit in well with UI design for WPF, but the tips offered are general enough that they can also be applied to user interfaces that aren't Windows-based as well.
I'll add a pointer to a related question: Java User Interface Specification
Joel Spolsky's got a simple, elegant idea in the "Hallway Usability Test," as well as a series of posts on UI design.
I suppose the first book I'd suggest is 'the inmates are running the asylum". It takes a bit to get into, but it turns out to be a great book.
Online...
the w3's got some great ideas about how to design web pages.
The zen of palm coding should be required reading for gui design for pda designers.
This can be debated until the end of time, personally I believe that interaction design and graphical design are two quite separate things.
But both of them van be learnt, at least to a satisfactory level. You'll probably never be4come truly great at it unless you have a "talent" for it.
A book that I myself havn't read but I have heard many people recommend is "Don't make me think" by Steve Krug.
The sites I recommend for UI and design specifically are:
Alert Box, about web design, in particular. Good examples, use cases, and studies there.
Humanized, design principles. Check the blog too, specifically this and it's setup article.
Aza Raskin's Blog. He's part of Humanized (and now Mozilla), and his personal blog is a mine of insightful commentary on interface design.
The interesting thing about these sites is that they don't just give examples of UI "do's and don'ts", but back these examples up with specific metrics and methods that you can actually use to measure how "good" your UI is. Aza's blog is particularly interesting because he goes through his design iteration on several projects he's been part of, and talks about the "whys" for a lot of the UI decisions that were made.
Lots of links here to good guides, but the initial question remains: "What are the characteristics of a good UI designer?"
The ability to view a process, system or practice, and design an interface that makes the greatest improvement to it.
It's not about pretty interfaces, it's about what works best in that exact situation. And my advice for becoming a better user interface designer is to get better at putting yourself in the user position. We could all improve on that.
You can find a lot of designers who are able to draw pretty pictures, but the best have a working knowledge of interface design. Inherent in that is the ability to anticipate how a user will interact with an application without being prejudiced by the knowledge of how that application is supposed to work.
Regarding your second question - in my opinion, the programming model of WPF and Silverlight allows for a clearer separation between designer and coder (i.e. Microsoft Expression Design is for designers, .NET 3.5 is for coders, and Microsoft Epxression Blend is somewhere in the middle). That being said it is always better to have a UI designer who can handle both the design and the code.
And just to throw a book in there that I like - Luke Wroblewski's Web Form Design - you can get a PDF version of the book for under $20 bucks.
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.