Of the many interesting MIX things that I learned, saw, and brought home, one is a copy of The New Iteration. Subtitled  How XML Transform the Collaboration Between Designers and Developers in Windows  Presentation Foundation, I've found this an interesting read. I'm not an XAML or WPF guru, so I'm reading up. As the titles point out, this book is all about how XAML not only exposes the WPF engine, but also is a fundamental part of our designer developer workflow story.

 

 

Table of Content

  • Introduction
  • XAML Revolution
    • Why Use a Markup Language?
    • Differentiating XAML
  • Roles / Workflow
  • The Tools
  • Best Practices for Designers
  • Best Practices for Developers

    • Some interesting tidbits that I learned and underlined in the hard copy that I received at MIX:

    • the Expression products themselves were built using WPF

    • the key to realizing frictionless developer/designer collaboration in WPF application is XAML. However, XAML alone does not engender this new collaboration; it is the underlying WPF platform, manifested through XAML, which allows for the efficiencies to be realized. As such, it is critically import to understand how XAML works, how WPF is manifested in XAML, and some of the architect of the system as a whole.

    • XAML not only provides much of the functionality of existing markup languages but adds new features and capabilities not available in other technologies. XAML excels in three key areas: expressivity, comprehensiveness, and extensibily. [The next part explains these key areas.]

     

    • Technically, XAML is not a language itself but a .NET serialization and initialization language. Therefore, XAML can represent more than the features in the WPF platform; it can represent any customer controls, new animations, etc., as well as any .NET object graph. In a way, one might conceive of XAML as code represented as XML. [I highlighted this one because I have several customers who believe that XAML is only about WPF. Also, this capability can also allow a designer to code (so to speak). ]

     

    • "Because XAML dissolves the barrier between designers and developers we are no longer forced to work with a hard design freeze"...

     

    • In the new collaboration model, the designers' prototypes can be actual functional prototypes. ..a designer does not need  a developer to help mock up a concept...

    • Prototypes can likely be used in the final product, instead of just being a byproduct of the design process ...

    • "Our prototypes in the initial states of project used to be between 100% and 50% throwaway. With WPF development, our prototypes are down to 20% throwaway". Robert Tuttle, Frog Design

    • The section on different team models is interesting, and was something new to me. The models were: 1) designer/integrator/developer, and 2) designer/developer. The designer/developer model had two approaches: 1) Harvest Model, and 2) Collaboration Model.

     

    • Clear understanding about who "owns" the XAML is critical. Another critical aspect is a packaging/hand-off strategy for these assets...

    • [WPF Styles and templates] are the pillars of the separation (UI from code) that helps make the new collaboration model workable;by taking advantage of control templates, data templates, styles, and resource dictionaries, it is possible for developer to focus on logic (behavior) and designers to focus on visuals (UI).

    • Take a Data-First Approach - If the data and schema is ready before the designer starts the layout of the user interface, this will save time for both the designer and the developer. This way, the designer is accomplishing more than layout of the user interface; the designer in binding the UI to the business object schema, saving the developer from having to do that later. Using the schema from the beginning also saves the designer the work of modifying the design later because of changes to the data model.

    • Choose Code-behind - Though WPF allows you to insert code inline with the XAML, this is not a recommended practice. Avoid it at all costs; placing code inside a XAML file breaks the separation between code and XAML, leading to a maintenance nightmare...

    • A good rule of thumb is “if you find yourself coding UI logic, you are likely not using enough of data binding, triggers, and templates.” As mentioned earlier, XAML is an incredibly expressive, comprehensive, and extensible UI language; this should be empowering the designer to create user interface and interactivity of the application, leaving the developer with tasks like business logic, componetization, creating custom controls, and exposing the data models.