Tag Archives: WPF/E

UI Smackdown: Session 3

XAML/MXML: Why both?

I'm always curious when we have competing standards emerging, and I wonder how that happens, and why.  So, since we had people who were knowledgeable about both Flex and WPF at the UI Smackdown, it seemed reasonable to explore this issue with respect to XAML (Microsoft's XML scripting language for use with WPF) and MXML (Adobe's XML scriptiong language for use with Flex).  How similar are they?  Do they strive to solve the same problem? Will one standard emerge?

MXML is Adobe's markup language. It's essentially a DSL (domain specific language) for ECMA script.  You write MXML and it compiles into Action Script.  It has a familiar feel to HTML.  Used for layout.

ActionScript is used for all procedural components.  In Apollo, ActionScript compiles to byte code on the server.

XAML is Microsoft's markup language.  You use it to write WPF applications.  Instead of ActionScript, procedural components are written in C# or VB.NET.  XAML is not just for WPF.  It's a serializable format that can be used to:

  • serialize event wireups
  • refer to other objects in serializing code
  • serialize property injections
  • add properties to a language

You can pull in more than just state with XAML.  WPF and WF use XAML (and other technologies will as well).

Thus, MXML is really more specific to layouts, while XAML manages serialized formats.  The general consensus from both vendors is that the technology needs to mature before it can be standardized.  It's hard to work with other primary vendors while trying to innovate (e.g., XUL, SVG).  It's better to give the technologies time to mature and then let them come together.

With that understanding, we moved on to what some described as the "real" question.  The tooling on top of XAML and MXML is really the key, not the underlying technologies that implement it.  So the real question is: WPF/E or Flex? 

In designing tools toward productivity in developers, Microsoft has the edge.  Adobe's process is more manual, but this will be addressed in Flex 3.

Microsoft's Expression UI writes to XAML source files in the same project as Visual Studio Developer.  On the other hand, pure designers feel more comfortable using Photoshop, so Adobe certainly has an edge there.

For now, the jury is out regarding which to use.  As they both mature, this will be interesting to watch.

MXML
Adobe's markup language, used to build Flex apps
XAML
Microsoft's markup language, used to build WPF apps

UI Smackdown: Session 2

How to Hook into an Existing App

The second session that I attended at the UI Smackdown discussed opportunities for hooking new technologies into an existing application.  In particular, one of the participants wanted to hook a WinForms app with a WPF app.  While we were there, Drew Robbins from Microsoft demonstrated how to do this, and gave references to some tutorials at msdn.microsoft.com.

One discussion that came out of this session was the idea that the goal in generating user interfaces is to be able to suspend the disbelief of the users that they are actually using software.  They need to feel like it's a natural progression toward getting their work done.  With WinForms, this is difficult, but WPF improves this experience. 

One objection that people face when moving away from winforms is that there is a lot of third party support for it.  However, looking at WPF, it's apparent that a lot of these things have been built into the framework, so third party support is not as critical.  Rather, the downside of WPF at this point is in documentation (or lack thereof).  Once you figure out what to look for, WPF is a lot easier than Winforms.

If you're looking for a mobility solution, for now, WPF isn't going to help.  It doesn't appear that there's any intention to have WPF/E (E=Everywhere except mobile?).  WPF/E builds true web apps using layout/vector graphics from WPF with XAML.  Javascript drives it.

An aside that came out of this session was the idea that we often look at migrating an application based on what it currently does.  Rather, we should consider what the USER is trying to accomplish.  This will offer us more of an opportunity to provide a rich web application experience, since we aren't stuck in the mode of what has been done.

WPF

WPF/E
Scott Guthrie's Blog Entry
Winforms with WPF
(Thanks, Drew, for the link!)