Entries Tagged 'user interface' ↓

I'm delighted to see that Infragistics have just released their NetAdvantage control set for WPF. It's a huge download: over 100MB, so either the controls are very big, the documentation is extremely verbose, or there are lots of samples included! This control set nicely fills the gaps in the capabilities currently provided by WPF, including a data grid, charting controls and an Office ribbon implementation that looks pixel-perfect to me.

Complex controls like an Office ribbon clearly benefit hugely from XAML. The ability to declaratively create nested collections really makes what would otherwise be a painstaking and error-prone task really easy. In the case of Infragistics' ribbon, you just declare a XamRibbon element that contains a RibbonTabItem that contains a ButtonGroup that contains the constituent buttons. It's almost self-documenting, because it so closely parallels the actual visual structure of the ribbon. Adjusting the visual theme of the ribbon is as easy as any other WPF project - just merge in a new resource dictionary containing the changes you want to make. We've recently released a ribbon ourselves as part of an MFC feature pack for C++ developers, but the difference in complexity ably demonstrates why WPF is such a powerful platform for building heavy-duty UI.

In the interest of fairness, I should also highlight some of the other great controls out there: Xceed have a great (free) data grid, ComponentOne also have a data grid and chart control, along with a bunch of calendaring components, DevComponents also have a very impressive Office ribbon and a Visual Studio-esque docking control, IdentityMine have a 3D carousel as part of their Blendables toolkit, and Actipro have yet another Office ribbon along with a wizard control.

Shamelessly stolen from the Infragistics product manager's blog, here's a screenshot that shows off the kind of application you can build very quickly with this control set:

Whenever we run a WPF or Silverlight training event or lab, the one question that is guaranteed to come up relates to the designer / developer workflow on a project team.

In the old days of Win32 or Windows Forms, the workflow was straightforward (albeit extremely limiting). A lot of desktop application development teams I've seen, particularly in the enterprise, don't even include a formal role for a user interface designer. Although the development team might include a business analyst or someone in a interface development role who would be doing some basic interaction design and application flow work, the actual interface would be mostly designed and implemented by the same programmer who was writing the underlying logic. On the other hand, for the projects where design was taken more seriously as a core element to the success of the application, the design and development teams were separated into different silos. The design team would often present their output in the form of a color printout of a screen designed with Photoshop in complete isolation from the actual tools or platform available, and the developer would then have to jump through hoops to painstakingly reproduce the design with tools that were never built for that purpose. The end-result was typically a disappointing compromise between the ideal that the designer had envisioned and what was practical with limited and stretched development resources.

WPF and Silverlight revolutionize that process by bringing the designer into the heart of the process. XAML becomes the shared substrate that can be used by both designers and developers to communicate their intent. Finally, the designer is not divorced from the development process: using a tool like Expression Blend to produce XAML, their artistry is no longer the inspiration for the final interface design, it is the final design. For the developer, they no longer have to waste time recreating controls that already exist in the toolbox simply because the designer has implemented a different visual representation; they can concentrate on the engineering challenges that will create the rich engine that powers the interface.

Such a transformation isn't without challenges, however: it requires new forms of collaboration, different project team structures, and an updated cookbook of best practices. We're keen to help you retool your workforce to take advantage of WPF and Silverlight, of course, and so Jaime Rodriguez and Karsten Januszewski have spent the last couple of months distilling their own experiences and interviewing early adopters into a new whitepaper that addresses many of these issues and opportunities in great depth. This is the first of a series of content on this and related topics; we hope to produce several more in the run-up to MIX08.

Read the whitepaper online or download a copy for offline reading or printing. What best practices would you suggest to a software house or enterprise embarking on a new WPF project? What else should we be covering with this series of whitepapers? Let us know what you think.