Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
Looking for a tool to UI testing of a Windows (.NET WinForms) application. The idea is that the analysts will record the tests via some UI and it will be able to be played back over and over again.
Commercial tools are fine but bonus points for free ones.
Some others:
NUnitForms
Quail
I believe they're both free, and Quail looks really nice!
(I was going to just comment on an answer above, but ran out of room.)
We bought Ranorex, and I wouldn't do it again. Their licensing for 1.5 (what we're using) was unclear. Their written license was per user, their marketing said per machine. Still, enforcement was key-based, and not a big deal when a machine got wiped or a replacement tester came in.
For the 2.0 product, their licensing is now tied to the machine. Reimage a machine and you get to relicense it. I'm just not going to support that kind of hassle with my company's thousands of dollars, and we didn't upgrade.
For what they want for the product, a lot of the functionality could be easily written using the UI Automation Framework. Ranorex is a decent product, but I question its value for the money. We're moving a lot of our new tests to just coding to the UI Automation Framework, as we often end up modifying Ranorex-generated code anyway.
TestComplete.
You can definitely use capture-replay to capture and run the test script. But I would suggest that you must at least manually edit your scripts to make them
more readable
easier to maintain.
The good thing about TestComplete is that it is able to look into your form's properties, capture those properties so that you can refer to those properties by their name, not by just screen coordinates.
Like Tom E stated, do take caution while considering going down the record/playback path for test automation.
See Uncle Bob's article on Ruining your Test Automation Strategy.
The main problem is that the record/playback tools couple the tests to the GUI which makes them very fragile.
Uncle Bob's article does point out that some testing needs to occur on the GUI...but that he recommends stubbing out the business rule code.
Sorry I can't provide you with a specific UI test automation tool...but hopefully this caveat will help you make the best decision on how to employ the tool that you eventually use.
So far I have found:
Ranorex which looks really good.
Test Automation FX, also looks good and seems very well priced.
Microsoft's UI Automation Framework, which does not have the recorder but if I had to I could code one using this.
white which looks similar to the UI Automation Framework, but has an alpha quality recorder.
Comments please if you have used any of these.
At my company, we decided to go with http://www.sikuli.org/. We felt it was the perfect mix of cost (free), ease-of-use, functionality and extend-ability.
Sikuli is Python based (Jython, really) which is great and its open-source. There's a tiny bit of coding required, but it can be as easy as just calling functions. Their IDE makes it really easy to get started. It is not a record and playback tool. It functions based on computer vision algorithms - you give it screenshots of what to look for and it finds it on the screen and then performs the requested action (click, type, etc) on what it found. This is true independent testing since Sikuli knows nothing about the software its testing. It does not know about underlying APIs - it just does what a real human would do.
We have integrated Sikuli with Robot Framework, http://robotframework.org/, and have created lots of custom python code to build a robust testing platform. This may not be as easy as licensing a tool from a vendor but the time and talent investment in these two open source tools has been well worth it.
There are a bunch of similar questions on SO:
automate-interaction-with-a-gui-interface (Edit: no longer available)
automated-testing-of-windows-forms (Edit: no longer available)
automated-testing-of-gui
In my experience, there are a lot of good open source tools for the web, but not so much selection for open source thick client test automation tools. If you want good support with robust functionality, especially recording, you will need to look at the commercial tools (QTP, RFT, TestPartner, etc...)
You should have a look at http://opensourcetesting.org/functional.php A lot of tools are listed here and you should find something that meet your needs.
Visual Studio Team Test 2010 is coming with a tool for recording and playing back UI tests. You'll find some pointers at:
Introduction to Record and Playback Engine in VSTT 2010
Checkout Ranorex, commercial, quite expensive but powerful (not affiliated).
We were using Mercury TestDirector a few years ago and quite happy with it. (All the caveats as mentioned by others apply.)
Mercury was aquired by HP and the tools have been rebranded as HP QuickTest. Not sure how much has changed, but certainly worth a look.
I tried to include a link to the HP website, but the URL doesn't look too "stable". Not exactly a confidence builder ....
My proposal is QA Agent(http://qaagent.com/). It is free web based IDE for development of web automated tests. Basically you are using jQuery to develop your tests. You can run tests in your browser. It looks like a new projects, but I really like the idea to develop tests in the browser. You know how long it takes to set up your testing environment. With QA Agent it takes 10 seconds.
Related
My team is developing a Java web system using the Play framework and implementing Angular.js throughout. My question is, should I use Cucumber-java or Cucumber.js for automated BDD functional testing? What are the pros and cons of each when using them against this technology stack?
I've found very little online about which to use with this particular technology stack.
Firstly, the Cucumber is designed as a collaboration tool. If you're looking for a test automation tool, then you're probably best off choosing something that doesn't add the overhead of devising and maintaining a plain-English, ubiquitous language.
If you are collaborating with non-technical stakeholders, then Cucumber is a good choice. The whole team will collaborate writing the scenarios, but it will be the devs and testers that write the 'glue' that links the scenarios to the application you're building. If you choose Cucumber-JVM you'll write the glue code in Java/Groovy (or other JVM language); if you choose Cucumber-JS you'll write the glue code in Javascript. So, one of the questions to ask is "what language will my testers and devs be most comfortable using?"
You'll probably mostly drive your app through an interface that it exposes(e.g. the GUI or a published RESTful API). Whichever Cucumber you choose, your 'glue' code will use some other library to interact with your application (e.g. Selenium WebDriver), so another question to ask yourself is "are the libraries I need available for Java or Javascript?"
Sometimes you might want your 'glue' code to talk directly to your application code. Cucumber-JS 'glue' can easily call Javascript directly, Cucumber-JVM 'glue' can easily call Java directly - so that might affect your choice. Remember, though, that only a minority of your scenarios will normally bypass your application's interface, so if this is your major stumbling block, you should revisit your approach to BDD. Some of these tradeoffs are also discussed in these slides
Finally, my feeling is that Cucumber-JVM is currently more mature than Cucumber-JS. Aslak Helesøy and Julien Biezeman are founders of Cucumber Ltd (along with Matt Wynne), so I expect them to reach parity at some point. For more information about Cucumber take a look at their online videos or <personal_plug>buy The Cucumber for Java Book</personal_plug>.
Before signing a vendor-lock from the open source perspective I would compare:
number of open issues, the less the better, no serious issue should be left open for years
number of unapproved pull requests, the less the better, no request should be left pending for months
what the key developers say about their product
your estimated technology learning costs
...?
Cucumber-JVM
Issues: GitHub: /cucumber/cucumber-jvm/issues
Pull requests: GitHUb: /cucumber/cucumber-jvm/pulls
Heroes: GitHub: /cucumber/cucumber-jvm/graphs/contributors
→ Aslak’s view of BDD, Cucumber and automated testing, December 12, 2014
Cucumber.js
Issues: GitHub: /cucumber/cucumber-js/issues
Pull requests: GitHub: /cucumber/cucumber-js/pulls
Heroes: GitHub: /cucumber/cucumber-js/graphs/contributors
→ Cucumber.js for BDD in JavaScript: An Interview with Julien Biezemans, April 15, 2014
User's voice may be also a good indicator but that would fall into the site's off-topic category
primarily opinion-based
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I've been lurking around for several weeks and have been totally blown away by the amount of information and how the community quickly responds. I have noticed that questions like this typically receive sarcastic remarks and sometimes get down voted. Please bear with me as I attempt my first post :)
I little background..
I work at a tiny software company as the "QA department". Our application has a MS SQL back to store customer data and short term loan information for financial service companies. I started working here 6 years ago as a gernal technician to provide support for their call center, so I've been overly exposed to SQL and have become fairly familiar with working with it. You probably wouldn't pay me to develop a enterprise level database, but at this point I've become familiar enough to do most things in SQL.
Why I'm asking my question..
I want to develop an application to store and track our software issues and new dev. I've done research on this website along with asking around and I still feel sort of lost as to which direction I should take. I want the core of the application to be pretty basic at first, to provide various screens between my entities/modules and to create reports to show their various relationships. In the future I want it to be more complex, to provide a web portal of some sort and to start getting into various complex QA software concepts. I've read around and it sounds like I might want some variation of C/VB for the windows portion, but all of the topics have sort of overwhelmed me. Do I want to start with a more basic one that was created 20 or 30 years ago? (I think that's C and C++, right?) or a more recent one like C#? Will I be able to develop a web portal with both of these? (by web portal I'm thinking it would provide access to our database of defects and have username/password sign-in). I've seen that the various .NET languages lean more towards web development, should I start with one of these?
I am at the very beginning of this and I fully understand that I'm jumping into some deep waters here. I want to make sure I don't end up spinning my wheels and that I focus my energy on something that won't end up being a bad idea in 1 or 2 years after I start. So far I've found this website very helpful, if I can pick a direction I know I won't have any problems finding what the next step is. It might help to know that I have no formal or informal programming background (if it wasn't obvious). I'm a 27yo techie who is starting his first venture into programming, go easy on me! Thanks for taking the time to read this :)
I won't recommend that you go to C, C++, or VB. C and C++ are used mainly for developement of system software, compilers, etc. VB is deprecated by now; there is a .net version VB.NET, but my preference is C#.
Looks like you are a Microsoft shop. Steer youself towards using C#. Visual Studio provides great support for development of Web Applications with support for holding state in entities backed by MS SQL.
I would start with a simple example as given in MSDN http://msdn.microsoft.com/en-us/library/dd410597.aspx.
This example uses an Model View Controller based framework that is fairly easy to configure and use. They have great examples.
There is a free framework that also supports MS SQL Entity store http://www.coderun.com/ide/
Enjoy
Don't write a line of code. There are literally hundreds of open source and commercial software packages that already do what you want to do. You'd be better of spending time researching them and finding the package that most closely meets your requirements. A good solution will also be extensible enough that you'll be able to modify it to meet all of your requirements.
Since you work for a small company I can guarantee you that using your limited development hours "writing your own" will be counterproductive. You'd be better off adopting something off the shelf and becoming proficient at it. You'll learn more about developing systems like this once you've become intimately familiar with one of them.
Check out JIRA or
http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems for some other ideas.
For the benefit of your company I would recommend to use an existing
solution. But if you want to learn and build something of your own, I
would suggest that you check out some popular web application
frameworks, like:
Django
Ruby On Rails
Zend
Good Luck with your project!
Given that your intent is to learn and create something yourself I think you should consider a LAMP stack and PHP with one of the PHP frameworks on top (Cake PHP, code-igniter or the like).
The C++ route is a long hard way (C++ is my language of choice) to learn; as a learning experience I think you will get quicker and more satisfying results with PHP.
I also think that this is a realistic project for someone of your skills over a period of a 6 to 12 months - start with a simple requirement and then build it up to have all the features you need.
If you just want a bug tracking system obviously there are many options that won't demand any development.
How much experience do you have with things like installing Linux, Apache, Mysql, etc? If you are completely new to this, then this will be a much tougher task, because there are many layers you'll have to learn before you can even get to the point of writing an end-to-end application.
I would avoid C/C++/C# because there are a lot of things you would need to learn about basic programming before you even got to the stage where you could make database calls.
On the assumption that you don't have experience with LAMP (Linux/Apache/Mysql/(Perl/Python/PHP)), my suggestion would be to start simply, by using a scripting language like Python or Perl. You can very easily get a database connection, and start writing queries, and extracting data from there. If you are used to Windows, I would install ActivePerl or ActivePython, and start from there. You can start building a command line program that does what you want, and then from there, you can move on to creating a web application that can do something similar.
Building a web application would likely be much easier than writing a Windows application, so after you have gotten comfortable with the scripting language, that's the direction I would go afterwards.
Good luck!
I am planning to develop one website which should have following features
Database integration
online payment system
forum
I need suggestion for my following questions before I will proceed to develop my site.
Is there any any single development tool which can provide me one webserver + mysql database + user login + java-script support + webpage design + online payment system and forum and easy site maintenance ?
What best practice to start development of this type of project?
How much effort it need to maintain this type of project?
"database integration" isn't really a feature - it's the tool you use to deliver your features. A feature might be a shopping cart, or a product catalogue, or a structured navigation system, etc.
In order to talk to a database, you almost certainly need some back-end code to be running, and you need to be able to program.
Yes, there are frameworks/tools that accelerate this, but you do need to invest at least in the basics of learning how to code.
Alternatively, if what you really want is to build an online shop, sign up for a "software as a service" offering where all you have to do is configure the product.
Sounds like you could use a framework to do your project with. Take a look at http://www.drupal.org.
If you're including an online payment system then you need to ensure that it's high quality, developed by people who know how to properly secure such a system. You should also be looking for a solution that handles pretty much everything you need it to do or that allows you to plug in modules for additional functionality rather than modifying solid code. There are so many ways for a developer to foul up even the best designed system that it's best to just leave it alone unless you're fully up-to-speed on secure coding guidelines.
IF what you really need is a way to sell things, and content to manage, then what you're looking for is a shopping cart with content management capabilities. There are plenty of good ones out there, and you should Google them. We went with the AspDotnetStorefront because it suited our needs, and was PACB certified, but there are plenty of others out there. Shop around if this is the type of thing you're looking for.
That said, you can get a good framework that has shopping cart options, and also the ability to add/modify modules to provide functionality with DotNetNuke. There are a wide variety of pre-existing modules to choose from as well. And you certainly can't beat the price on the free version. Developing for it takes some getting used to (there's a learning code even for experienced .NET developers) but it's pretty flexible.
Edit - I realize I'm only offering .NET suggestions, but you didn't mention what development tools/language you are comfortable with, so I'm mentioning the ones I've worked with. There are good (some arguably better, some arguably worse) Java and PHP equivalents to the suggestions I'm offering as well.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
Are there any tools out there which uses Image Recognition(searching, comparing, validating images) as base for automating and testing GUI software.I know ranorex supports it. Are there any better tools?Are there any gotchas in using Image Recognition to drive test automation?
Ok, first of all, I DO understand the previous answers: testing apps using image recognition isn't the best way to test GUIs. But, at the same time, I don't understand why you aren't answering the question in first place. He's asking for tools that work that way, I'd think he's smart enough to understand where he's going into.
Ok, now the main subject, my choice would includes:
Sikuli, a MIT project under the GNU-like MIT license. It uses Python over Jython. Free.
TestPlant eggPlant, a tool that works through a VNC server, so you can test apps in any VNC compatible platform (including smartphones). It has some nice features like OCR, test schedule and so on. It uses SenseTalk. Not free, you could request a trial.
Routine Bot, I've never used it but it seems pretty useful.
I would also discourage using Image Recognition with SendKeys and Click at Coordinates or (Button Images) to do UI testing. I have been recently using UI Automation to automate the testing of a WPF application with success. By placing small breadcrumbs (Automation.AutomationID="OkButton") throughout our application's XAML I have been able to write some C# Unit Tests that exercise different aspects of the application. Even without the breadcrumbs UI Automation is still capable of exercising an application, but it is slightly more difficult when trying to identify the controls on the UI.
A decent article on Code Project is available as a starting point.
http://www.codeproject.com/KB/WPF/UIAutomation.aspx
You will also need UI Spy, a free tool from Microsoft, which helps you find controls and manually exercise the controls through UI Automation as guidance for writing the scripts. The tool is buried in the Windows Vista SDK, after installation search for UISpy.exe. The UI Spy tool can still run on a Windows XP machine by just copying the EXE to the target machine.
Consider AutoItScript for driving Windows-based GUIs in test scenarios - AND scraping off the UIs. Consider tesseract open source optical character recognition. Also OpenCV for machine vision.
Free AutoItScript works at the API level in that you can read states of various Widgets and Windows sections, send actions to these UI components too, wait for state changes etc. It's possible to produce highly robust automation code that will ensure focusing on Windows and resolution independence.
Let me suggestion another solution.
It's not a complete UI automation framework, but rather a specific tool just for the Image validation.
It will allow you to ignore the unstable part of your images as well (random data, etc.)
It will integrate with any other UI testing framework you choose:Selenium, Sikuli, etc.
http://visualci.com
thanks for your comment! please Take a look at RoutineBot – interface testing software based clicking on certain image patterns and see for yourself how this idea is implemented in an
automation tool!
Old question, but perhaps this answer may prove useful to someone. I currently am using two products,
Testing Anywhere, by Automation Anywhere (http://www.automationanywhere.com/Testing/)
and Quick Test Professional, by HP (http://www8.hp.com/us/en/software-solutions/software.html?compURI=1172957#.UhJBwpLW5-k)
Both of them do the job well enough, and both support the use of image recognition. I am not entirely convinced that image recognition is in itself a bad thing. As with all things, you have to tailor your approach to your particular needs and use the right tool for the job.
Just thought I'd add another entry to this thread. Things may have changed, not sure, but when I last saw the demo, this product offered Sikuli-like IDE/interface/capabilities while being a commercial product and supported actual devices beyond simulator. Don't know if the tool has improved to detect objects by identifiers beyond images now or not.
SeeTest from http://experitest.com
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.