Related
Way back when I built an internal site for a customer using silverlight 2. They've been happy with it and I've barely had to touch it. Is the expectation that this site will always work? What I'm afraid of is suddenly getting a call years from now that the users installed silverlight X and now it's broken and I'm going to have to convert it immediately past Y versions of Silverlight to get the site back up, and I don't even do Silverlight anymore.
I already went through this once when it went from 2 beta to 2 release and and scrambling to fix all the breaking changes and get the site back up. It wasn't as big a deal then as we were in beta anyway.
I could upgrade now but it would be really tough to go back to the customer and ask for money to do an upgrade when they are happy now and will see no noticeable benefit from staying current. Additionally there are some third party controls that would have to be licensed again.
So I guess what I'm asking is there a known end of life? Or do we just play it by ear?
Based on the Silverlight Support Lifecycle Policy, it looks like official support for Silverlight 2 has already ended (as of October 12, 2010). However, some other documents (mostly listed at this SO question) give the impression that Silverlight apps are binary backwards-compatible through a sort of Silverlight "quirks mode," so as long as you're not changing your Silverlight app and the policy doesn't change, the app should work indefinitely.
The folks at MS have so far done a reasonably good job of maintaining backwards compatibility between Silverlight releases. But there have been some significant changes, and depending on what your app does, what features it uses, and what bugs in the runtime that it takes advantage of, it may or may not continue to run cleanly on future versions of the runtime. MS gives some good examples of the breaking changes between Silverlight 3 and Silverlight 4 here.
One example of many: Silverlight 4 introduces a new "Watermark" property on the Textbox class. It's possible that a Silverlight 2 or Silverlight 3 application subclassed the Textbox class, and added their own Watermark property. References in XAML to that Watermark property could thus throw an AmbiguousMatchException when executed on a Silverlight 3 or Silverlight 4 runtime.
Presumably there will be more changes of this sort as MS moves to SL5 and then SL6, and so forth: and their dev team will stop worrying quite so much about breaking SL2 applications. A change that introduces a really cool feature but breaks some reasonable portion of SL2 applications would presumably be unacceptable in SL5, but maybe not in SL6 or SL7.
My recommendation in your specific situation would be to let your customer know about the possibility of future issues now, so that they have a chance to make a decision about it when it's not an emergency.
Take it easy :) It would allways work.. Silverlight have 100% backward compatibility for EVERY major version!
What are the pros/cons to using CTP technology for internal production softtware? By internal production I mean it's software we're not selling to anyone else but will be used by a large number of internal employees spread nationally.
I can see the obvious plusses (features and functionality that beats existing systems) and minuses (bugs, lack of support, changes in the interface, risk of discontinuation.) I'd like to hear from people with experience using preview tech in production software and the kinds of hurdles and things that we might not be considering.
The technology in question is the Silverlight Bing map control CTP.
Thanks,
It's a call that can be tough to make and really depends on your circumstances. A beta control from Microsoft, targeted at developers, that fills an immediate and important need, may be just the right fit if you are understanding the lack of support.
Especially given how quickly internal apps and even public sites go through revisions and quick improvement milestones.
The Silverlight Toolkit has been trying a new model for the last year; we've introduced special quality bands, to help customers make a call, and understand the investment and guarantees that the product team is making. I sort of hope we can get other teams to make a similar commitment.
The AutoCompleteBox control was essentially CTP a year ago, in the Preview quality band. Since then we invested and shipped it in the Silverlight 3 SDK as a mature, supported product.
Have a discussion with your management to define what risk you can take on while still enabling your internal users with quality value (scenarios that do work great, regardless of the released quality under the hood).
Consider source code!
One thing that you can also do is have a discussion around source and binaries. Although you won't always have an option to grab the source for many controls or frameworks, there are a lot of open source releases available today. Your control vendor may also be willing to offer a source license.
The cost for maintaining your own private branch of an open source control is high, but it is an avenue that can be explored if you need fixes earlier, want to add your own functionality, or feel that a developer day of work might just get an existing control customized for your scenario.
Updating with some more specific links:
Silverlight Toolkit
Here's more information on the Silverlight Toolkit's Quality Bands, for those that are interested. They are Experimental, Preview, Stable, and Mature; Preview is much like CTP, Preview - Beta, and Mature - Released and supported.
These are all just words, but they are "the word" of the team.
Microsoft Connect
WRT the Bing Maps control, I did see that there is a Microsoft Connect site out there. That's a great resource to have - although I am not in the program, typically Connect sites are there to help provide more frequent drops, a set of forums for discussing any issues, and a way to easily get in contact with the developers and testers on the product.
Other vendors
There are many other vendors out that that provide early releases, feel free to use the comments to add a non-Microsoft angle to this. I wanted to provide my opinion on these topics since I'm pretty familiar with a lot of the Silverlight-specific Microsoft frameworks that are out there.
Personally I don't think it's a good idea, as essentially your internal employees are your market, so this is essentially production software.
So things like licencing, compliance, support, SLA's may need to be thought through.
I know that would be frowned upon by my IT Director and Internal Audit people, to name two.
Are you reasonably sure it will work and not kill your employees' pets? Then it ought to be fine.
Seriously, just be sure it works for the target audience.
As always, IMHO.
Sometimes you just dont want to wait for a new feature, for instance we started using SQL Server 2008 in our new architecture just for the DateTimeOffset. We used this application internally, but this wasnt a major deployment. If its stable enough then why not. The Pros are you dont have to wait, you're testing new techniques, code and keeping up with technologies.
The cons are that some features will change, API arent finished or some things get renamed. These things present themselves pretty quickly and are normally easy to change. Also some things may not be documented, but there is always someone blogging about it.
With the tools available today like HockeyApp to manage betas for my apps I am less afraid to use preview APIs in beta versions of my apps. This way I can work out new functionality with real users who want to try out the bleeding edge.
When I have keep the new version limited to a small set of users this has been fine.
The times I have used preview technology in production I have been occasionally bitten by the bleeding edge. I have had to work around bugs or live with them while I waited for them to be fixed.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Has anybody any experience in using Gupta (formerly Centura) Team Developer?
If so, what do you think of it in terms of its capability to support the development of mature, scalable, maintainable applications?
Thanks
I have been using the CTD since version 1.1. Currently I'm still using 2.1 PTF4, mainly for doing rich client CRUDs under windows 98-Vista against Centura SQLBase, MS Sql Server or MS Access. I have not upgraded from 2.1 to the newer versions, so I can only talk about the relatively old 2.1 from 2001.(§)
Our applications typically have about 150 form windows, make heavy use of classes (still called "user defined variables" in 2.1) and integrate MS Office. We have no stability issues or memory leaks. The development environment is a bit long in the tooth, though: no intellisense, no smart debugging and practically unusable without a mouse. This may have changed with newer versions.
There is nothing in the nature of CTD that forces you to write un-maintainable code. Using classes and file-includes you can have a good degree of reusability in your code if you designed your code to be reusable, that is. A problem for maintainability may be that CTDs variables and classes do not have access modifiers like "private" or "protected". Also: no interfaces or abstract classes. On the other hand: multiple inheritance.
The "outline structure" of the code takes some getting used to, but I even sometimes miss the outline structure when I get lost in a sprawling C#-file with variable declarations and event handlers all over the place...
The controls for 2.1 where pretty complete but we still had to manually integrate "modern" things like toolbars, datepickers or tab-controls. OTOH it even has a numerical input field out of the box. One of the Unify-Newsletters stated that they added a lot of eye-candy, to let the apps look more up-to-date. The mtable-Extensions for table windows where very helpfull, available here: MTable by MICSTO . Integrating 3rd-party-DLLs (e.g. for integrating a smartcard-reader) is not really fun, especially when they use structs. Oh: and the "Centura Report Builder" is a royal pain in the derierre.
A big pro is the SDK that shipps with the CTD: this makes it very easy to integrate self written tools into the development environment, e.g. for code generation.
Bottom line: We used and still use CTD for scalable and maintainable apps. The learning curve can be a bit steep because of the unusual outline structure and can lead the unwary towards writing "ugly" code: e.g. lots of static functions, lots of code in the "Message Actions" and problems with variable scoping. I think your success with CTD will depend on the nature of the application you want to write: for a rich client CRUD you might almost certainly be better off than with .net, for a web app I honestly don't know.
Keep in mind that all this relates to the 8 year old 2.1 version of CTD. Things may be radically different now. If you can, get an evaluation version.
Edit: Aside from the pros and cons of the language alone, you might want to consider that CTD is a niche. There are not many free tools and I have yet to find a vibrant community (there was a newsgroup, but the server went down after the merger - maybe its still around somwhere). So, googling up help on specific Problems may no be easy.
(§) I did not continue the upgrade path from 2.1 to 5.1 because after the merge with Unify they wanted to make patches available only for subscribers to their support scheme (called GLS). Since I was not going to pay for bugfixes I deceided to continue using 2.1 for our legacy apps and switch to .net for new apps. I think they revised this later on.
I have been working with Team Developer (formerly Centura Builder, SQL Windows, etc.) for 9 years. IMO things have not changed too much from the version 2.1 which Stephan Keller described in his comprehensive answer.
The company I am working for is currently using TD version 5.1 and considering upgrade to TD 5.2 next year. We are developing a business software product, run against Oracle database. The application has more than 500 form windows and several hundred reports.
I think Team Developer scales well to both simple small applications, and larger enterprise application suites with big RDBMS and hundreds of users.
The code outline makes the IDE easy to approach and I think the learning curve will not be that steep. The code editing is possible even without mouse, since there is a number of handy keyboard shortcuts. Of course the window designer needs mouse. There is also a built-in Active Coding Assistant in the newer releases.
The newest releases (5.1 and 5.2) offer some new GUI controls, such as a date/time picker, a grid window (enhancement to the widely used table window) and Rich Text editor. There is also a new tab control. Menus can be shown ribbon-like, though this is not a "real" ribbon bar. Sample screenshots can be found on the Unify web site.
Also new GUI themes were introduced in the 5.x versions of TD, to provide a more modern look and feel for the applications.
There have been a number of stability issues, performance problems and problems with screen painting etc. with the 5.x versions of TD. The older 3.x and 4.x are known of very robust quality, having only a very limited number, if any, stability or other issues. These issues are discussed actively on the Unify Support Forum. Many of these issues are related to database routers (Oracle, MS SQL Server) or Windows API calls. The basic functionality of TD is usually working quite fine.
Also help on specific problems and questions can be reached on the Support Forum. The developer community is maybe small, but quite active.
My Company uses Team Developer for years successfully (most of our Applications are written in 2.0, with some in 5.2 as Web-Applications) and there are plans to change our development to version 6.0.
Coming from a C++ background I first had to find the way into the language (I still miss some features like encapsulation, well-structured error handling1 or scoping of variables2)
But after all, I learned to live with the limitation of the language and with some discipline our applications are relatively easy to maintain. (as a note: We have a set of base applications working together and use the same codebase with some customer-related variations to build individual versions for every customer - bugfixes appear at the common codebase (and is used afterwards for any other project), special modifications at the lokal project files). You just need to set up some basic guidelines for your projects and keep with them as the compiler wouldn't enforce them.
1 You could catch a sql error only at the point it occurs or globally for the whole program.
2 I still sometimes get cases where a mis-spelled variable compiles for something in a completely independent window - or compiler errors for semi-referenced handles sharing the same name but different data types
We used TD for several large apps but due to the lack of resources, the obsolete SAL language and aged runtime we have migrated millions of lines of SAL code and several thousand forms to C# and Visual Studio 2010 using ice tea group gupta/unify migration tool.
We were skeptical at first. But now we have brand new apps, fully integrated with our other .NET assetts with a small fraction of the time needed for a rewrite. And we didn't have to try to understand what all that all code was doing. :) the conversion was nearly perfect!
Forgot to mention that we automatically converted over 1200 report builder reports to crystal reports .NET saving probably a century of boring work.
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.
It seems that Silverlight/WPF are the long term future for user interface development with .NET. This is great because as I can see the advantage of reusing XAML skills on both the client and web development sides. But looking at WPF/XAML/Silverlight they seem very large technologies and so where is the best place to get start?
I would like to hear from anyone who has good knowledge of both and can recommend which is a better starting point and why.
Should you learn ASP.NET or Winforms first? ASP or MFC? HTML or VB? C# or VB?
Set aside the idea that there is a logical progression through what has become a highly complex interwoven set of technologies, and take a step back and ask yourself a series of questions:
What are your goals; how do you want to balance profit against enjoyment
Are you short term oriented or in for the long haul
Are you the type of person who likes to get good at something and do it a lot or do you get bored once you fully understand it?
The next and hardest step is to come to accept that any advice you are given is bound to be wrong; and the longer the time horizon the more likely it is to be incorrect. If the advice is for more than six to 12 months, the probability the advice is wildly incorrect approaches 1.
I can only tell you my story, quickly. In 2000 I was happy as a consultant working profitably in C++ on Windows applications, writing about ASP.NET and WinForms. then I saw C# and the world turned upside down. I never went back.
Two years ago I had the same kind of revelation, only an order of magnitude bigger, stronger and with more conviction about Silverlight. Yes, WPF is magnificent, and it may be that I'm all wet about this, but I believe in my gut that Silverlight changes everything. There was no doubt then and there is no doubt today that Silverlight is the most important development platform for Microsoft since .NET (certainly) and possibly since the switch to C++.
In a nutshell, here is why. I don't understand where its limitations are. With most platforms I do: you can do this, but you can't do that. WPF is a pretty good case in point, as was ASP.Net and WinForms and, well really everything until now.
With Silverlight, I don't see the boundaries yet. Silverlight has already leaped off the desktop onto phones, and I don't see any reason for it to stop there. Yes, it is true, it is bound by the browser, but I see that less as a jail cell than as a tank in which Silverlight will be riding over lots of terrain (it must be very late, I should go to bed).
In any case, for now, learning Silverlight is a gas, there is a lot of material on the Silverlight.net site, and what is the very best thing about learning Silverlight is that if you don't see what you need you can holler at me and I'll make sure you get it pretty quickly.
Enjoy, good luck and the dirty little secret is you'll be fine whichever you choose. It's all just software.
-jesse
Jesse Liberty
"Silverlight Geek"
I'd say go with Silverlight first!
I have programmed with WPF and Silverlight before.
But as Silverlight is a subset of WPF if you go in too deep and try to switch to writing Silverlight applications, you'll be scratching your heads looking for that "tag" you learned to love in WPF but is not available in Silverlight.
When you master the basic things in Silverlight first, the extra mechanism/trigger/whatever features in WPF will simply add to most of what you've already known.
Silverlight in WPF differs at the features level, not just some missing controls or animations. Take the WPF triggers mechanism for example, is not available fully in Silverlight.
So learning the smaller subset first, you can extend that knowledge to the full set later, but if you started at the full set and gets addicted to some of the niceties available, you'll have trouble down the line when someone asks you to port your designed-utilizing-WPF apps to Silverlight.
I'll go against the grain and say learn WPF first.
Here's my reasoning:
Much more resources are available for WPF than Silverlight, such as books, blogs, and msdn documentation
WPF Books
You're not dealing with a Beta, moving target
You don't have to deal with working with only asynchronous calls
Not limited by lack of features such as Merged Dictionaries, Triggers, TileBrushes, etc.
You don't have to worry about re-learning to do things correctly because of lacks of features in SL
Silverlight is a stripped down version of WPF so it should have fewer things to learn inside. On the other hand, the two platforms have different targets (web & rich client) so I guess it depends on what app you're going to build.
If you just want to learn for yourself (no app in the close future) I'd pick Silverlight because it would be less to assimilate. Still, Silverlight is pretty much a moving target, much more than WPF, so you'll have to keep up with some changes from time to time (the joys of being an early adopter :)).
WPF has lots more stuff that you will probably want to use at some point but I would wait for the needs to arise first.
Every industry expert I've heard on podcasts, blogs and interviews recommend learning Silverlight first and then gradually moving to WPF which is a huge UI framework.
Silverlight is light and allows you to work on smaller subset of controls and features such that you get your head around this new UI building paradigm based on,
Templating
DataBinding
Styles
Update: 07/2011
I hate to mention this, but in recent times Microsoft has put more focus on HTML5, Javascript and CSS by bringing forward powers of IE 9 and IE 10, as well as the upcoming Windows 8.
More and more developers and CTOs are skeptical about Silverlight as a LOB application platform as the time passes by, we are suspecting Silverlight will be limited to Windows Phone and niche, domain areas like healthcare of graphics related applications rather than a regular LOB app.
As it seems right now, as of summer 2011, the future might look fragmented with more opportunities for pure web technologies (HTML5, JS and CSS) as opposed to a plugin and OS-specific UI technology.
I would start by learning XAML, by reading a few tutorials and playing around with XAMLPad. This will give you a feel for the basics before actually building an app.
I would start with WPF and doing very simple control familiarizaton samples. You goal should be to learn XAML and Binding. So if you just create some basic WPF window apps will bootstrap your learning speed. Then eventually you can move to silverlight. Yeah as other mentioned here Silverlight is a subset of WPF.
Well, it depends on what you are going to be working on. If you are working on client/server, then I would go with WPF. If you are working in an environment where you can guarantee that .Net is installed on all of the machines, then I would go with WPF as well, because you can use what is called an XBAP, which is a WPF application that is run through the browser.
It's really up to you. However, I would state that silverlight is not RTM yet, and WPF is. WPF has a lot of books out on the subject, where silverlight does not. It may be easier to get the whole Zen of WPF by reading a few of those books, and then dive into which ever one you would like to play with.
Just keep in mind that silverlight has a subset of the controls of WPF, a paired down .Net framework, and does not do synchronous calls. As long as you know that up front, you can start learned the core of the whole foundation and tailor your practical experience later on to whichever technology is best for you.
Some tips at Getting started with Silverlight Development