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 4 years ago.
Improve this question
Basically I'm going to go a bit broad here and ask a few questions to get a bit of a picture of how people are handling UI these days.
Lately I've found it pretty easy to do some fancy things with UI design and with WPF specifically we're finding new ways to do layouts that are better looking and more functional for the user, but in contrast one of the business focused guys at our local .NET User Group wouldn't even think of using WPF until it had a datagrid that he could use to make Excel like input forms.
So basically, have you rethought the design of your business apps as you move to Web/WPF/Silverlight designs, because for us at least - in winforms we kept things fairly functional and uniform, or are you trying to keep that "known" UI?
Would a dedicated design guy (for larger teams), or a dev with more design chops rank higher when looking at hiring these days? (Check out what a designer did for Scott Hanselman's BabySmash and Microsoft's Prism demo)
Are there any design hints/tips/guidelines you use for your UI - especially for WPF?
What sites would you recommend for design?
I recommend that you read Steve Krug's Don't Make Me Think first. The book has a great checklist of things that you have to take into consideration when designing your UIs. While it's focused on web usability, a lot of the lessons therein are valuable even to desktop application designers.
That being said, whether you use Windows forms or WPF or Flash or whatever new and shiny thing that comes around is, it is of utmost importance to hire either a) a real designer, or b) a development guy with a lot of UI design experience, either of which who can provide you a serious URL for their design portfolio. It will help a lot not only in improving the design of your application but also unburdening your developers from thinking about UI design, and allow them to focus on the back-end code.
As for "business focused" guys -- it would be really great if you would get the opinion of actual customers and stake holders, and have them do some usability testing for your application. It's their opinion that would matter most.
I think it would not be difficult to get a good designer up to speed on Microsoft Expression Blend to whip up some good XAML designs that your team could use to come up with a really good product.
Here's a great screen cast where Billy Hollis goes into many of these issues:
http://www.dnrtv.com/default.aspx?showNum=115
I think WPF can greatly improve user experience.
However there are not much business oriented controls out there which means you need to do a lot by yourself.
As for designers I think it's really hard to find WPF designer now days, it still would be a dedicated programmer rather then design-only guy.
I hope that this situation will change in nearest feature.
I think it's worth at least start experimenting with WPF to be able to compete with upcoming solutions.
The whole concept of re-thinking a UI of an existing application is dependent on the target audience. For a boring business application, like accounting or budgeting, it may even be counter-productive. For one, users of those kinds of apps may have used a similar looking and feeling UI for years and years, and second, looking too "cute" and colorful can even bring a perception of toy-ishness (is that a word?) with it.
We have done several new projects with the latest & greatest UI gadgets, and for the most part for new applications it seems to be a good chance to get some feedback from a live audience. Then it gets easier to translate that feedback into existing applications.
We also have some apps which are still actively developed (and used obviously), where the UI looks almost like in Windows 3.1. They're awful, gray, clunky, and our only real designer is always trying to get a permission to bring it to the current centrury - but the biggest customer actively refuses this. They say it's just fine, people know how to use it, and it works even in their oldest computers.
#aku "I think WPF can greatly improve user experience."
I believe that WPF has amazing potential as a tool to make UIs more creative and better suited to the actual data that is being displayed, BUT..............
Just the mere act of using WPF isn't going to make great UIs appear out of nowhere.
A great carpenter may use the best wood working tools, but that doesn't mean that if you picked up his tools you'd all of a sudden be popping out fine furniture.
Using WPF over HTML/Flash/WinForms/etc just increases your potential .
If that's potential for ugliness or potential for beauty is up to you.
#David H Aust That's part of the reason for asking the question - with these newer tools like WPF that lend themselves to providing newer, more intricate, and at the same time simpler for the user, interfaces that we might need to adapt to new ways of doing things.
And trying to find out who else is adapting/interested and what they are doing, and where they get some inspiration, knowledge or help :)
IE: This is me being proactive about change in possibly the slackest manner ever, short of actively googling :)
^ That was a joke, to make it clear, I'm actually pretty active about learning new stuff, I'm just finding some of the crowdsourcing stackoverflow vs googling pretty interesting :)
Microsoft is building a DataGrid for WPF. A CTP can be found here.
#Lars Truijens - Thanks, but I think for 99% of cases that's a horrible idea, and sure, there are uses - but I've found that with WPF there's typically a much better way to do it.
Plus you can use textboxes, and use an Enter as Tab override to move through them easily and swiftly.
Related
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 12 years ago.
This is a question I have had rattling around in my head for some time. I had a chat with a guy the other night who told me he would not be using the navigational framework because he could not figure out how it works with MVVM. As much as I tried to explain that patterns should be taken with a pinch of salt he would not listen.
My point is this, patterns are great when they solve some problem. Sometimes only part of the pattern solves a particular problem while the other parts of it cause different problems. The goal of any developer is to build a solid application using a combination of patterns know how and foresight.
I feel MVVM is becoming the one pattern to rule them all. As it is not directly supported by .Net some fancy business is needed to make it work. I feel that people are missing the point of the pattern, which is loosely coupled, testable code and instead jumping through hoops and missing out on great experiences trying to follow MVVM to the letter.
MVVM is great but I wish it came with a warning or disclaimer for newbies as my fear is people will shy away from silverlight development for fear of being smacked with the mvvm stick.
EDIT:
Can I just add as an edit, I use and agree with MVVM as a pattern I know when it is and isn't feasible in my projects. My issue is with the encompassing nature it is taking, as if it HAS to be used as part of development. It is being used as an integral feature and not a pattern, which it is.
EDIT 2: Thanks for all the comments so far, one issue that is surfacing from this is something I have not thought about until now. Is the introduction of richer more advanced frameworks for GUI/RIA development showing a weakness in RAD development for this generation. That is, is there a lack of code design and pattern knowledge being taught along with these frameworks? I once asked for a book on just C# (Before Pro C# & the .Net framework was popular) and was told why would I want to know C# minus winforms/asp.
Sure there are plenty of books/KB on these subjects but are people using them, beyond the superstars and very good programmers?
So, here's something that I think a lot of new MVVM developers forget - the pattern is there to help you, not the other way around. Building software in this manner tends to make your life easier as your project gets larger, but if it's completely getting in your way for a specific task, take a step back and ask, "In this specific scenario, is MVVM helping me here?" You're allowed to "cheat" a bit from time to time if it makes your life easier.
Actually I've used MVVM quite effectively with Navigation Applications with the Windows Phone 7 framework using commands and messaging. But if someone tells you that you can use every feature of Silverlight without adding some code to the code-behind, then they are fooling themselves. Use the pattern where it helps and make sense, and go "off-pattern" when a particular feature requires something custom.
Assuming your question applies to WPF as well, I sort of wonder if the problem isn't just the massive learning curve of WPF/Silverlight, before it even occurs to you to try out MVVM. Think about all the new things that need to be learned with WPF (and I assume Silverlight): XAML, dependency properties, attached properties, routed events, routed commands, static resources, dynamic resources, styles, data templates, control templates, databinding, etc., etc. etc. Then take the fact that Microsoft released this technology with an incomplete set of, at least with WPF, badly skinned controls, and you have a recipe for frustration and the inescapable feeling that you are dealing with a technology that is "not ready for prime time". I mean, before the WPF Toolkit came out, there wasn't even a proper DataGrid control.
Once you understand all these things, MVVM is yet another hurdle, but I don't think it's the main impediment to people jumping on the WPF/Silverlight bandwagon. That said, it would be nice if Microsoft would get behind it the way it has gotten behind ASP.NET MVC. As it stands today, you have to download and use third-party tools, like MVVM Foundation and MVVM Toolkit (which, incidentally, have a lot of overlap and should be combined into a single project).
So, I agree with you to a point, but I think most of the challenges involved with MVVM are probably due to the lack of support from Microsoft, and the inherent complexity of WPF/Silverlight, not due to any flaw in the MVVM pattern itself.
Great answers here, by the way. Good discussion and an important one to have. There is no doubt that learning Silverlight can be intimidating for new developers, and the MVVM framework will no doubt compound that.
However, I do agree that someone not understanding it isn't a dig against the framework. I still have developers who tell me that inversion of control/dependency injection is too confusing to learn, but does that make these invalid patterns? The fact the so much proven, "in the field" software relies on those concepts tells me they are sound even if complicated to grasp at first or understand.
Then again, learning a foreign was tough when I started, but once I pushed through, now I can speak it comfortable and wonder why it was so hard to begin with.
I guess the trend that scares me the most is this notion that for some reason complicated, enterprise applications should be easily built by beginner developers who either can't or won't grasp complex concepts. That's what it really boils down to. You don't have doctors saying, "Help, make this brain surgery easier so any one can do it." It's specialized. Building great software is also specialized, that's why consultants command good payment for their services: it's the value they provide in understanding the right way to architect and develop solutions.
If you are making an asteroids game, a fantasy game, a media site, a YouTube knock-off, etc, then you probably don't need MVVM and it is overkill. If you are building a small site with a few forms and graphs then build it how you are comfortable and be done with it.
If you are building a large, complex site that is composed of multiple, dynamic modules, moves thousands or millions of records and requires scaling to massive concurrent users, then you can't expect the design to just pop out after thumbing a few pages of a book or skimming a few sites. Software like that is complicated, with a lot of moving parts, and rqeuires a firm grasp of architecture.
What amazes me is people presumably building these more complex applications who still don't get building these more complex applications. Is there someone experienced on the team? Do you have an architect to stub out the framework that you can consume?
I mean really, the example just tells me the problem isn't MVVM, it's the developer. "Avoiding Navigation because of MVVM?" REALLY? What's MVVM got to do with it? Write the navigation pieces, and let the view models live inside the pages. Why does my navigation have to drive from a view model?
Come one. If it's that complicated I think it has nothing to do with the pattern, and everything to do with the developer just not understanding development. Don't blame the pattern. Maybe they need to stick to simpler applications. In my experience, people who come to understand the pattern understand software well enough that they know when and when not to use the pattern.
I know there are many movements to boil it down and make it simple for the "average consumer" but I think this is like trying to say, "Calculus is the wrong way to find the area under a curve because it's too tough to learn." While MVVM isn't as complex as Calculus, building complex software is a complex endeavor and I don't think you are ever going to simplify it or boil it down to a simple formula (nor should you). If you struggle with MVVM, please, don't use it - find something simpler and easier. If your project is complex enough to use it and you still don't grasp it, please hire someone who does, have them plumb it out and learn from them.
No, I don't want Microsoft telling me what pattern to use nor do I feel it is their responsibility. I'm a professional and it's on my shoulders to invest the time to learn and understand what I'm building so I can build it the best way for the customer. Microsoft doesn't necessarily know what my customer does or needs, so how can they possibly tell me what pattern to use? Projects like Prism are great because they are a compromise: they provide guidance and share "best practices" of how something can be done, without forcing that implementation on the developer.
I'm using MVVM for a Windows Phone 7 app. I really like the idea of it but there's too many hacks, wordarounds and 3rd party tools needed to get it running.
Things are getting better with every release of Silverlight but I still think the technology is "bleeding edge".
Why can't you?
And no, MVVM is just one of many patterns and frankly, not even amongst the most popular ones. What is hurting Silverlight's development is a) Flash b) not being Flash c) being Microsoft centric d) learning curve.
Plus the fact WPF doesn't really seem to have caught on doesn't much help.
Someone has problems figuring out how to use navigational framework with MVVM => Someone doesn't use navigational framework => MVVM is killing navigational framework => MVVM is killing Silverlight development.
Would you say there are few flaws with this chain of reasoning?
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
At my company we are undertaking a large task of creating a new software architecture for our products. Our current architecture has been in use for many product iterations and lasted a long life and it is time for it to retire. The UI architecture is currently implemented in WTL/ATL 3.0 and COM.
We have just completed the design of the back end architecture, one that will stand the test of time as its predecessor has. However UI technologies move so fast that no one on our team has the expertise that I would consider required to lay a foundation that should last many years. We are currently targeting WPF for this architecture and considering various alternative strategies to help our lack of expertise with this technology.
Some approaches we are considering:
Have our experienced staff ramp up on WPF and work through an architecture -
Concern with this approach is that the areas we need our UI layer to last and likely all of the learning’s required will not be gained until after many products have been implemented using this architecture.
Bring in temporary expertise from a consulting firm to assist with the architecture and development - This approach is looking promising; suggestions on firms with expertise? Microsoft does not provide application and architecture consultants, so finding someone with the necessary expertise may prove challenging.
Bring in a consulting firm for an architecture study and guidance session - Seems to be compelling as would provide our experience staff guidance while still allowing our domain knowledge to steer the direction of the architecture. May be difficult to find firms qualified for this type of service.
My question then to you is how have you resolved a similar situation where you must create a robust, rich, long stay architecture utilizing new technologies that your team does not presently have architect level knowledge of? Have you had success with any of the previously mentioned strategies, or are there other approaches I have missed completely?
In general I am not an advocate for working in this capacity with technologies that are unfamiliar to you. With that in mind, the user experience we believe WPF may provide will give us the capabilities we want to utilize for many years. At any rate you have to start somewhere. ;-)
You have to learn your chosen GUI eventually.
As one of those outside consultants that comes in for these kinds of projects, I suggest a variation on option #2.
Engage one or two outside consultants.
Have them guide you through something like your option 2. You actually learn WPF and then (with their help) develop the architecture and implement it.
Your follow-on question ("suggestions on firms with expertise") is disturbing. If you don't have trusted technology partners, now is the time to start cultivating them. It will take a while to locate folks you can trust.
The only way to locate them is to pay them to do some work and see if you like them and the work. This process can take a long time.
Problems with doing #1 by yourself are the obvious ones. If you try to do this on a deadline without experts, you'll make mistakes. You'll cast those mistakes into concrete. You'll try to live with them forever. When learning something new, the calendar is the most dangerous thing imaginable.
Option #1 works when there's no time pressure.
You build something disposable while you're learning. Then build something which you know that you will have to throw away. Then build the real thing.
Problem with doing #3 is that you may be asking consultants to do too much. If they plan your architecture, you probably won't completely understand it. You'll cut corners and bad things can happen. If -- on the other hand -- you do it yourself, you'll understand why those corners shouldn't be cut.
Also, #3 is an opportunity for piling in every feature you think might be cool. Until you understand the technology, you don't really understand what's essential, what's easy and what's hard. You're very likely to demand something that's expensive and risky because it's difficult to understand exactly how expensive and risky it is.
First off, WPF is probably a good choice. This is being embraced by Microsoft, and really seems to be the direction things are going for long term development. I recently made a very similar decision to this, and decided to go with WPF. After the initial pain that comes with a new tech., it's proving a very good decision.
That being said, I'd highly recommend a mixture of 2 & 3.
If you can find a good consultant to help with the design, you should be able to bring them in to help you with the design and architecture phase, some initial construction of the project, and they can potentially also help your developers get up to speed. Having help in house (or at least on-call) will be tremendously helpful in getting the through initial phases of trying to develop with WPF.
It also helps to bring in a developer and/or designer who has experience working with WPF.
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 6 years ago.
Improve this question
At company I'm working, new project will be started soon. I'd like to use Silverlight 2.0 but I need to convince my CEO and Photoshop/AfterEffects guy for using Silverligt for upcoming project. These persons are - let's say - rather Flash / Apple oriented, but for me as a .NET developer Silverlight seems to be proper solution :-)
I have a list of advantages from developer's point of view but I need to show for these non-technical persons any working demos .
These applications could be business applications, but the most important features are:
fancy graphics - not a developer manufacture,
comfortable and interesting UI,
functionalities which are difficult to implement in Flash
Thanks.
I find that folks really like Quince:
(source: sparklingclient.com)
One of my favorites is Centre des Usages:
(source: sparklingclient.com)
Telerik have a couple of nice looking demos of their controls
This silverlight showcase will probably have something you can use
There are some killer visual effects in SL3:
http://blogs.msdn.com/henryh/archive/2009/03/20/mix09-the-gratuitous-graphics-demo.aspx
That demo is pretty awesome. Be sure to mention out of browser support, which you can't do in flash (though I understand other adobe technologies support OOB). Other posts on stack overflow have pointed to there being more 3rd party controls for SL than Flash but I don't have any stats to back it up.
Surely you don't need Demo's of fancy graphics or comfortable and interesting UI's. Since this would be by design and would be implementable in Flash or Silverlight.
Surely things like the fact that existing programmer knowledge can be extended into the rich UI because you can reuse your .Net skills would be the key thing. Being able to deliver functionality rather that just "flash"....
The showcase above is quite good, but the argument is still going to come back from the people who are used to using flash by saying "Yea, but we could do that in flash".
You need to show them what additional functionality Silverlight would allow for which you are battling to implement using flash. The down side is that if you can not do that, and you have a company with resources that is already trained in building things in Flash, you may be better off staying with Flash.
Becoming more familier with Silverlight yourself would help you to explain the strengths of SilverLight and all the good things. Time for that Hello World Silverlight app to be created.
Most of the things that you can do in Flash/Air can be done in Silverlight and vice versa. even if they are some things you can do in one but not the other, they might not be applicable to your scenario. picking the tool is one task. Assuming you have picked Silverlight then comes the difficult task do you use Code Behind, MVP, MVC, MVVM, Prism, Caliburn, SLExtensions. and once you pick the pattern you use, you will soon find there are n-variations of each with no definitive guidance
I would say if dev's are familiar with .net go with Silverlight
I met the CEO of this company on Tuesday, so I have no prior affiliation or vested interest. (But, he was a nice enough guy, so I'll give him this free plug.) Both the apps you see on this page are pretty cool, and the first is a Silverlight app.
http://www.atamagroup.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.
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 9 years ago.
Improve this question
I had a discussion with some colleagues mentioning that there are not too many projects that we do which make use of WPF for creating UI for a windows application (we almost always use Windows Forms instead).
Are your experiences the same - i.e. there is not too much adoption of this technology?
Why do you think that is? And will we have a time when we see much more of WPF?
Have a look at this survey it was done by a Windows Forms Contol Vendor in Australia.
Personally I have worked on two commercial projects in the last year that were using WPF to varying degrees.
The adoption of WPF is on the rise. Microsoft I believe is putting all their eggs into the WPF basket.
WPF Rocks in terms of what the technology can do. It's simply the best UI building technology on the planet (my opinion). But, but there is a huge initial and long term investment in learning and getting your head around it. Also from tooling perspective it has barriers like unusable Cider designer, you've to get blend to do styling etc.
I am sure it will become popular, but would take time. But right now it's not so popular.
Check this thread on WPF
Check this conversation on msdn forums about WPF for LOB apps
Absolutely - the adoption is tiny. There was lots of hype but it does not seem to have materialized.
I used WPF for one project and I can certainly say it left a very unfinished taste in my mouth. It was far too difficult to acheive simple things and the whole thing had very many rough edges - the reasons behind them certainly existed but were not obvious or even visible at all. The Visual Studio designer completely bugged out for most of my pages and I never did figure out why...
All in all, I'd say WPF is barely beta-quality from a developer friendliness standpoint.
WPF has a steep learning curve, and the development tools for it (expression studio/web) are expensive, so, I'm not surprised that the industry has not jumped on it. However, in terms of Windows programming, it is much more robust and powerful than Windows Forms, so I would like to see its popularity grow over the next few years as Microsoft makes improvements to WPF, WCF, and .NET in general. If MS would decrease the price of its Expression products, I would expect to see the framework's popularity grow much faster.
Another troubling thing about WPF is the total lack of good online tutorials for the framework. I'm trying to learn WPF at home, and I have found it to be a pain in the neck. I had to fork over a ton of cash for the development tools, and then I had to pay more money for a good book because there just isn't enough online to really get me into the framework and its languages. I can learn quite a bit about Java for free just by visiting the Sun website, but for WPF, I have to get a book. There is also a terrible lack of reference materials, in my experience, for WPF. To me, it reminded me of programming in VB6. Unless these things are remedied, I wouldn't expect to see any rapid growth in the framework. I do believe the main driving force behind the industry's adoption of the WPF and WCF technologies is MS support.
Though WPF was introduced few years ago it was too raw to use it in the real world apps. Major problem that stops WPF from wide adoption is a lack of RAD tools and out-of-box components. Currently we have Blend, more or less working Cider, but usable versions of these tools came not so long ago. Another reason is a completely different architecture which leads to longer development time as compared with WinForms due to prolonged learning\adoption period for developers.
I think we will see rising of WPF in the next few years.
People usually jump the technology bandwagon when there is a a real productivity to gain. Something to compensate for all the productivity loss that normally occurs when you adopt a new platform. WPF is just not there yet. It still takes more effort and more time to build a WPF app than a Forms app, and by a long shot.
Combine this with less documentation on the net about WPF than Windows Forms, less people with WPF experience, less blogs on WPF, less books on WPF, less tips/tricks,etc.
And don't get me started on XAML. Is it XML? is it a script? is it a code? Why did they decide that a hyperlink is just a label property? A lot of things still need to be ironed out there.
I cannot afford to build my next project in WPF, it will cost me a lot more to do it (in manpower and time), with nothing to show for in return. At the moment all we do in WPF is pure-research-inhouse-hobby projects.
I'm currently working on a WPF project - my first one. The learning curve has been incredibly steep, but in the end I think WPF is a great technology. The potential is fantastic, especially for advancing the state of data visualisation. I really like the data binding features, and the potential of styling. But it really does take a while to get your head around this.
I think that Silverlight adoption will eventually drive WPF adoption back on the desktop - or maybe there won't be a desktop as much of what can be accomplished with Silverlight will replace many previously desktop applications.
I am playing around with WPF and I must say I am not impressed. I seek a technology which will help me be productive in creating business applications. I remember building my first classic ASP website and being disgusted at the spaghetti code required to build a simple app. Viewing a single page I found HTML and java script mixed with vbscript with include files and calls to com objects--in short, a bloody illogical mess. In my view, it is important to have a simple and VISUAL development model with standards. I built many VB6 and .Net windows apps and they have a simple metaphor for development, making them easy to debug and modify by developers who did not write the original app. Forms encapsulate presentation logic, modules and classes in referenced assemblies encapsulate business logic and data logic. ADO.Net and other tools make data access robust, scalable, dynamic and customizable. Resizing windows controls and graphics to suit monitor resolution or client preference is easily done with Win Forms.
It may be that WPF has many advanced features in graphics, but for most business apps, form should follow function--in other words, I am not putting goofy animated graphics on my banking windows app.
One of the reasons I have not liked web development is because of the wide variety of ever-changing and complex technologies required for relatively simple applications which don't deliver enough significant change in actual functional results.
Oh well, that's my two cents.
' )
We deployed a pretty major WPF application for a large investment bank I worked for. It turned out extremely successful, involving 3d visualization of OLAP data that allowed quicker trend analysis. It's being used extensively.