Are we far enough along in the development of WYSIWYG tools, specifically both the 
design surface in Visual Studio, and even more so, Expression Blend, that the right way to teach Silverlight and Windows Phone programming is without Xaml?
I hear your screams of protest already:
“That’s fine for some things but not for… “
What? What can’t you do in the UI designer?
“But… when you get in trouble you’ll need Xaml…”
This argument rings of the old standby “you can’t really program in foo unless you understand Assembler. When was the last time you needed assembler? Those days are over. Are the days of coding with underlying Xaml over?
Certainly at some point tools like Blend will create better Xaml than will be created by hand-coding, and with fewer errors. Are we there yet?
Obviously you want to go to Visual Studio for code, but that is not an alternative to Xaml. All I’m suggesting here is that new books and new tutorials on Silverlight or Windows Phone do not need to teach Xaml – that everything you can do in Xaml you can do as well or better in Blend (or using the Visual Studio design surface).
Hey very nice website!! Man .. Excellent .. Amazing .. I will bookmark your website and take the feeds also�I’m happy to find a lot of useful info here in the post, we need develop more strategies in this regard, thanks for sharing. . . . . .
XAML is a front end design language that Microsoft wants to be a programming language. Microsoft is pushing hard for to go where it shouldn’t. They are providing every example/tuturial in XAML first and often forcing developers to ask for code.
Personally, I hate XAML when it tries to be anything more than a screen design.
Personally I loathe Blend. I don’t mind the designer in Visual Studio; some of the associated automation is very handy, particularly the way you can drop an RIA table on the design surface and then press delete, to get all the imports and declaration with no fiddle or fuss. But the designer is an obstruction as often as it is a godsend, and the best thing about it is the fact that you can flip between the designer and the markup editor, and even have them both.
As for not needing to understand underpinning technologies… my sister complained once that her car was gutless. I happened to be driving it at the time. Down a gear, revs up and slammed back into the seat: “There’s nothing wrong with this car. You just don’t understand torque ratios. If you want more power, drop a gear and spin the engine faster.”
How a thing works and how it is normally used are two very different things. Understanding what goes on under the hood informs our decisions and and improves them. Well, it informs my decisions. No one can make you learn assembler.
On the other hand, understanding too well can make you see a screwdriver as a chisel or a lever, or a big ratchet as a hammer. An aesthetic is also required.
@Andrew I didn’t see the the [irony] tags around that… I do hope you are kidding. Hand-coding will throw us back to the dark ages or 80ties in coding…
To be more specific on my point of view
After reading most comments it’s obvious that you look at this fro a developer perspective, I think when it comes to the designer perspective it really makes sense to hide most of th XAML altogether.
Handling brushes, gradients, transforms and animation storyboards are brilliantly easy in blend and also for most other work. Moving resources from control to page or application level is a matter of drag and drop and you will instantly lessen the memory load for this. Attached properties could use some improvement as well as adding references but could be solved.
It’s not a beginner/advanced topic but designer/developer topic. If, for example, the performance takes a hit when I use to complex stacks/grids, making a too big visual tree it’s evident in the visual tree I’m creating. That has to be learned no matter what approach you use.
I think you should focus on the design perspective when it comes to the UI and only move to XAML when absolutely necessary.
And yes include blend in the VS package deal… 🙂
I came into development from a graphic design background so I’m one of those ‘middle-men’, although I’m a better coder than designer these days. I think the main problem is the assumption that MSFT make about the designer/developer split in organisations. In my whole career I’ve only worked for one company who have a separate design team,..and that was a web development company working with ASP.Net. Blend HAS to be included as part of your Visual Studio licence or else it’s never gonna pick up sales. It’s either that or throw out Cider and build Blend in.
Can we drop Xaml altogether,…in theory yes. There really isn’t much argument against it. Xaml is NOT HTML (of any flavour) and doesn’t require you to know the markup in the same way mostly because you’re not targeting different browsers and having to combine it with other technologies like JavaScript and CSS.
The complaints about ‘Blendability’ are sometimes fair but rarely showstopping and I wouldn’t call it “jumping through hoops” to get there. In my experience, properly designed applications are implicitly ‘Blendable’,…not always, but most of the time.
Yes Blend does some crazy stuff with margins. Yes the layout engine needs some work. Hell yes it needs to be included with VS and YES,..you will be a better designer and developer if you know the Xaml. Blend is another leaky abstraction too add to our toolbelt but consider that I’ve recently had to rework a VERY poorly written system with maybe 200+ very large screens. The initial redesign took about 1 and a half months using Blend. If I was writing the Xaml out by hand, I’d still be nowhere near done.
Jesse, you’re perfectly right.
Learning Xaml must not be a key to learn WPF or SL.
Expression Blend is a fantastic tool, If Blend was offering code debug I think I will use very few VS itself.
Blend is an “integrator” tool, a profile that is hard to find : people being good at design and good at coding at the same times. That’s the only problem. Designer are generaly very bad at coding and understanding code problems, and developers are very bad at design.
And a lot of people are very simple and straight : if they are not confortable with something, they say they don’t like this thing.. Simpler. No question to aks to oneself..
Blend allows to show how much a developer is bad as design, how to you want developers love Blend ?…
That’s the question !
POINT 1: XAML is based on one of worst
I’m a little surprised by the general response here, so I’d like to ask a question to better understand where everyone is coming from. Personally, I never use the designer when creating html. The designer just doesn’t help me create html better or faster. However, I almost always use the designer when creating .Net WinForms. I know how to do it by hand, and that’s helpful sometimes, but for the most part it’s just _so_ much easier to layout a form in the designer. Furthermore, I don’t think anyone would argue that WinForums tutorials should focus on laying out controls in code (not that anyone is making WinForms tutorials these days). So, the question is, why is the general feeling that Xaml falls more into the WebForms camp then the WinForms camp?
I personally think every MS demo that only uses drag/drop or WYSIWYG is doing beginners everywhere a huge disservice. The problem with that is XAML in and of itself is a pretty broad topic. You could write books on just XAML alone and find plenty of material to cover despite it being just another markup language(tm).
I think maybe there needs to be some well of knowledge that books or other media can point to and say “I’ll give you a 50,000 ft view but if you want street level go here and good luck because unfortunately you’ll need it.” You can’t be expected to include all of the nuances but I do think the main point of this discussion is going to be “How much XAML is enough for beginners and how to we address our pool of knowledge as a community going forward.”
I’m not trying to toot my own horn here but a year ago I knew almost 0 XAML and decided to join a team doing purely WPF/SL code. As I was thrown to the wolves with a couple of good books I used as reference material only, that I could become this proficient (in my own head) a year later is remarkable and not a testament to me as a person. There is a ton of great material online that without it I probably would’ve never accomplished even some of the simple tasks the XAML I have does. Often times some piece of XAML looks simple on the surface but some niche problem is usually why something may look more complex than it should. There may be multiple paths to certain outcomes but more often than not there are roads either us developers have carved by sharing or that really is the only way to produce a TreeView that does X versus Y. I’m really wishing I had a specific example of this right now but I don’t think I’m saying anything someone doesn’t run into on a daily basis.
I think my number 1 biggest problem with XAML is the lack of parity between WPF/E and WPF. I understand Silverlight solves a different problem but Width=”Auto” or Width=”*” should probably just work the same on both. I don’t care if person on team Y is having a pissing match with person on team X, it’s all Microsoft to me and the longer you promote this internal bitching the more customers suffer. I know this isn’t news to anyone but as a beginner this single-handedly is my kryptonite. If the XAML core was somehow its own team where no outside influence tried stirring the pot with their wang I think we’d all be in a lot better shape. I didn’t really want to bring up what I’m dubbing the political side of things but it seems I can’t have a thought without going back to “Well if I only didn’t have to do X in Silverlight for seemingly no legit reason…”
While blend helps in creating precise animations etc. I don’t think it is a replacement. There are lot of things that can be done faster directly editing XAML (keyboard vs. mouse). People who worked on real projects would know how many times VisualStudio/Blend will not be able to display the design view and have to manually correct the error in the XAML. These are the kind of Ideas that lead people to think they need to know MVVM before learning Silverlight/WPF. Which I think is totally wrong.
@John Stockton
John,
Well said. I totally agree. Now the only point of difference may be when you introduce Xaml to novice programmers.
@Pat Tormey
Pat, I can always count on you to add perspective! Thanks. -j
I would always want the option of hand-coding. My designer view for asp.net has cobwebs growing on it from lack of use. That said, I primarily start with the designer when doing Windows Forms apps, but then put it away once the main layout is done. I suppose the extent to which a XAML designer (VS or Blend) will depend on its ability to produce quality code. While I don’t think the tools are there just yet, I’m sure it’s not far off.
If you teach Xaml as a serialization format, then it becomes quite simple to understand the mapping from the WPF object model to XAML. I see no need to teach XAML as WPF specific thing.
I strongly believe that not only do we need XAML, but (View / UI) Silverlight developers need to understand it. First, I love Blend and Visual Studio and use them both daily. Also, I havne’t read each and every comment so if I am saying something already said I apologize.
Even assuming Blend produced flawless XAML with every possible element and attribute I believe it is essential for developers to understand what it is that they are creating. This lack of knowledge ends up with developers creating bloated object structures that do not behave as expected. When you know the underlying elements you can arrange them in a specific fashion to enable your particular scenario, this is incredibly difficult to do when you don’t know the underlying structure of the objects you are creating.
And that brings up another point: Performance. When you are unaware (and have less control) over the individual elements you will, without fail, end up with more objects declared than if you knew the underlying technology and it’s performance impact. With Silverlight/WPF in particular, since each object is in fact a CLR object in memory, the more bloated your layout is can have a dramatic impact on application performance.
This conversation reminds me of the days when ASP.NET came of age and many web developers didn’t understand HTML or the way the web worked and it was evident in the applications they produced.
Blend is not intuitive, while visual studio designer is too slow
Hand code your xaml !
turn off your designer !
Hi Jessie,
‘d like to offer some copies of our new Flash to Silverlight Blend Plug-in. It converts all the assets from Flash SWFs importing them directly into MS Blend. We’d love your feedback, so let me know?
In essence allows assets from Flash SWF files to be imported into MS Expression Blend by way of a plug-in (or it could be built into Blend), allowing direct importing of graphics, animations, fonts and audio clips into a Silverlight project, adding value to MS Silverlight tooling.
The converter enables developers/companies not just to re-use Flash assets in Silverlight, but also provides a mechanism to grow Silverlight development skills out from that conversion. The advantage is in
Back in the olden days we ‘script’ programmed to each printer.. Epsom, HP and the dreaded Postscript. We even did our word processing with KB to turn bold on. The mastery of the K functions was an essential part of geekitude, and a source of great pride.
All that scripting, markup and nonsense went away as the tools got better. ^BSo bring on the better tools.. ^B.. well, gotta run an pip some files to my 8″ 160 floppy.
Pat NH USA
While I would argue strongly against the drag and drop style development, and I prefer to hand write my XAML, I will admit that you do have a point. For most of the demoware applications that are used to promote Silverlight/WPF it is perfectly adequate.
I am currently developing an enterprise application and one of the requirements was a tree control with a grid layout. This in itself cannot be created merely by pulling some premade controls and styles together. Furthermore because it has to have the combined behavior of a grid and a tree control it is necessary to inject some custom values into the cell templates at runtime. To my knowledge there is no way that this can be done with XAML, much less drag and drop, so I had to resort to creating templates in code to render the cell content.
I see it as analogous to behaviors and triggers. They are indispensable once you have them, but someone has to code them first.
In a perfect world we could/should skip XAML but take a look at HTML.
After all these years, are we using designers or are we typing HTML?
I like XAML way more than HTML but productivity form is still using the keyboard, not using the mouse to drag-drop, right-click or click the Advanced Property mini-squares.
For starters designer-only might be fine but for experienced developers knowing XAML is manadatory; knowing XAML allows me to expect things from the designer. I like the analogy with assembler and I guess I like assembler.
I agree with the title but for totally different reasons. I like the way Charles Petzold approached it in Applications = Code + Markup. Teach them to build simple visual trees using old-fashioned code.
Initially I hated the fact that he didn’t even *touch* XAML until halfway through the massive book. But by then I had realized why. He wanted me to understand what the XAML parser was actually doing. That’s why eventually I was able to put together very clever XAML constructs like my SwitchConverter class, and why I am very comfortable creating controls that derive from Control instead of UserControl.
I get that beginners don’t need to worry about all that right away, but it does make a big difference later when you can’t do what you want with XAML alone.
As for relying on a designer tool, I think Blend is great for creating initial XAML. (particularly when in “draft” mode). But then it always needs to be cleaned up manually. Visual Studio’s designer is not even usable, in my opinion.
Let’s be honest with ourselves. Cider in particular is as fragile as fine crystal. You look at it funny and it crashes. It’s gone from bad (vs2008) to worse (vs2010). In fact I have one XAML file I was just working on that crashes Cider three times in a row before it even tries to display the designer view. It’s terrible. And what the others have said about the flagrant use of Margins on everything in Blend is so true. If you drop a button in a grid it should give you the same behavior as doing the same thing by hand in the XAML…. i.e. NO MARGINS! In fact unless you explicitly add them, Blend should NEVER put in margins! Until this is fixed I will continue to avoid Blend except in rare situations. And honestly once you get good with XAML, you can edit it by hand really fast. I also find it difficult to place controls in grids and stackpanels easily in Blend. In XAML it’s a quick grid.row attribute and I’m done, no futzing with the mouse (and I’m a mouse guy, so that’s saying something).
The point about MVVM was good as well. Cider won’t even render most of my datatemplates….
Let me add that if I were writing a book on Silverlight or on Windows Phone I certainly *would* include a full discussion on Xaml. My point was not that Xaml really isn’t needed, but rather to question where it fits in; how early to teach it, and how far we’ve come with WYSIWYG development.
@Fabian
Fabian,
We always leave things out. If we didn’t every book on Silverlight would be thousands of pages long. We know that a discussion of Silverlight internals is not needed in a beginning book on Silverlight. Nor is a discussion of many aspects of computer theory. For that matter a primer on Silverlight probably wouldn’t teach Linq or delegates or any number of other relevant but not required topics
The question is, do beginners need Xaml?
And let’s modify the question: if they do need Xaml, when do they need it? First chapter? Middle? End? Appendix?
I really like your idea of the future of Silverlight development. If a change makes development easier and faster without sacrificing correctness and performance, I’m all for it. I doubt we are there yet, though we are certainly close.
I just have a problem with one aspect of this post: the suggestion of intentional omission of background information in educational material.
“…new books and new tutorials on Silverlight or Windows Phone do not need to teach Xaml…”
Sure, I don’t use assembler on a daily basis (or monthly…), but understanding it and seeing the bigger picture certainly supports me in the way I approach software challenges.
Understanding the problem at hand will always be more important than just being able to solve it (also known as “just make the damn thing work”). Even IF Blend 5, 6 or 7 allows us to never look at a line of Xaml again, knowing what’s going on in the background will make us better developers.
Please, let’s not dumb down Silverlight!
Yeah, I would have to second that you don’t get a very re-sizable interface from authoring layout in Blend. It throws too many random margins into the picture. I think one of SL/WPFs strong suits is that if you are careful, you get an automatically resizing interface.
A strength that would be exceedingly important if you wanted a Silverlight app to run as well on the phone as in the browser, or whatever other devices WP7 ends up on. So resizability is extremely important.
What you get out of blend is similar to the html you get out of word when you do save as html. Useful, but, in the end, impractical if you need it to be truly flexible. I’m not saying Blend couldn’t be cajoled to provide output that is useful on multiple platforms, through proper usage, or smarter gen, but I’m not sure we are there yet…
I would really like to know why the default behavior is to use margins for everything, even if you are dropping things into a grid. This kind of default is just going to turn any RAD designed app into unmaintainable garbage from a UI perspective.
I create my xaml in Blend, but using the “split” view so I can see both the designer as well as the xaml at the same time. I find that 90% of what I want to do can be done _much_ faster using the WYSIWYG editor (once I learned the tool). However, there are a handful of things that you still need to do “by hand” (i.e. binding to attached properties). On the other hand, clicking “edit template”->”edit a copy” is a ton easier then finding the default xaml template for a control online. Also, hand coding storyboards/visual states is pretty painful. I’d much rather use Blend for that.
So, to answer the question, I think tutorials should use Blend, but in “split” mode. That way we see both how to use the WYSIWYG editor as well as the xaml it spits out. For my project http://scratchaudio.com, knowing how to use Blend has been invaluable. Teaching people how to use it will give them the tools they need to create a better user experience.
If Blend is free or as a part of Visual Studio, then sure, I would advocate coding without Xaml.
@Michael
Michael,
Actually, no one has ever told me which products to “push” or anything of the kind. For that matter, I’m actually not arguing that one should not use Xaml; I do a lot of my own coding in Xaml. What I’m questioning is the assumption, implicit or explicit in so many of the comments, that Xaml is required for new Silverlight programmers. Maybe, but I’m not convinced.
When I read the first paragraph, I thought you were going to advocate creating the whole object graph in code. I’d be fine with that 😉
But now I’ve finished reading, I’ve got a couple of observations. First, surely books and tutorials are exactly where you would want to teach people about XAML. If you’re going to shy away from XAML (presumably because it’s “too complex”), what on earth are you going to teach them? Even if they do never touch raw XAML again, knowing what’s going on under the covers is always of benefit. And are you sure it’s not worth knowing that you can just type Background=”Red” and not have to do it in Blend? (Personally, I find Blend complex and XAML easy …)
Second, how many designers do you know who haven’t learnt HTML because they’ve got a copy of Dreamweaver?
And finally, how many times have you groaned at demos that go “and then we just drop a data grid onto the design surface like this”?
lolz, did they tell you to specialize your evangelism to Blend and Cyder?
Fact is, most LOB applications need a simple, clear, self-adjusting (relative) layout composed of previously created UI components. I’m much quicker for that with 3 lines of XAML for a smart auto-arranging panel, than with fiddling around in a slow, inflexible designer where I always have to double-check if all elements scale correctly when resizing.
Then I’ll apply one of the generally available themes at the top of the application and everything is good. With a few good icons here and there, things will even look “individual” enough.
Whenever I see programmers playing around in Blend (let’s face it, most are mediocre at best in such things), the results remind me very much of early Geocities experiments or MySpace pages, sorry.
Maybe the time will come when the customers will come with concrete requirements for individual and fancy styles, effects, transitions, animations etc… Then we may talk again about firing up Blend or hiring a designer.
@Alex Cavnar
Alex, help me understand why MVVM requires Xaml? I don’t really see the connection – you can certainly set up all your binding through the properties windows in Blend.
@Owen Pellegrin
Owen,
TANSTAAFL. That said, there is a free version of Expression Blend 4 available for phone (http://create.msdn.com).
I’m not really sure. I think that if you’re really going to try and code in MVVM, you’ll want to use XAML. None of the tools produced by Microsoft ever seem to really have an emphasis on best practices or on reuse of resources/styles– those are things you’re going to wind up doing manually anyways.
So where do I download Expression Blend Express? That’s the reason I hand-code XAML at home for hobby projects. And I don’t mean an RC or beta. I mean a full-versioned tool that I won’t have to worry about paying to license.
I do think there’s a lot of value in understanding hand-coded XAML. The stuff Blend generates at work usually has to be massaged a bit to cut the visual count down. A more appropriate analogy may be “You don’t have to know anything about pointers to use .NET, but it sure makes explaining reference types and value types easier.”
An interesting idea, but I’ve found that Blend does a poor job of making well designed Xaml. You can often unintentionally end up with very strange margins and layering which could give you problems down the line. You can certainly get by with just Blend, but Xaml really isn’t that complicated and you have much finer control over how that Xaml is structured by doing it yourself.