Acropolis: The Answer to the WPF Blues

Fri, 15 Jun 2007 16:01:23 GMT

Windows Presentation Foundation (WPF) is great, but I have always felt that something was missing. WPF is the graphical subsystem for .NET Framework 3.0 and XAML is a declarative XML notation for describing user interface elements, data binding, eventing and even the structure of an application as a whole. The problem is that the Visual Studio tools for XAML and WPF have always seemed to be lacking. For starters, Visual Studio.NET 2005 does not provide assistance for wiring events and writing code-behind WPF controls. Developers are on their own for integrating UI elements and business logic.

Acropolis appears to be the amazing next step in the evolution of application development and is likely the reason that development tools for WPF appear to be lacking today. "Acropolis" is the code name for new toolkit for creating modular, business-focused Windows client applications. Acropolis builds on the .NET Framework and includes a run-time framework, design-time tools and out-of-the-box functionality.

Acropolis is specifically designed to help developers encapsulate business logic into "parts" and "services". Acropolis forms communicate with parts via "connection points". Acropolis provides a new, rich environment for creating loosely coupled applications.

Even cooler, Acropolis has the concept of Navigation Managers and Navigators which help bind user interface controls to parts and manage the state of navigation (such as visibility and enabled states). This concept should greatly simplify and standardize the development of rich user interfaces. Acropolis provides several out-of-the-box navigational patterns including: single part navigation, tabbed-pane navigation and split-pane structures.

Application development is about to get a whole lot cooler with Acropolis! WPF appears to be just the first step along the path to rich, loosely-coupled application development!

WPF and Section 508: Not Ready Yet

Fri, 18 May 2007 20:08:38 GMT

I'm a strong supporter of creating accessible software. Not only is it "the right thing to do", but I believe that designing for Section 508-compliance often results in user experiences that are more obvious, well-organized and portable to alternate experiences such as mobile devices.

While working with WPF and Silverlight, I've noticed a lack of commentary on accessibility. I've also noticed that accessibility-specific API's do not seem to be present on the WPF controls.

While I have seen articles indicating that WPF supports "Microsoft UI Automation" (which will be helpful for screen-readers), I do not see an obvious solution for keyboard-accessibility. I've also seen post such as this one on the Silverlight forum that suggests that accessibility in Silverlight will not be addressed until final release. I hope this is true.

Recent trends such as AJAX provide incredibly rich user experiences, but I fear that we are making a tragic mistake when we create content that is only available to "some people". AJAX is currently an accessibility concern because it often modifies areas of the screen in a non-linear fashion which only servers to confuse screen-readers. While producing creative experiences, I fear we may also sacrifice intuitive interaction, content indexing and portability to alternate devices.

I dream of the day when we learn to express user experience in terms of an abstract dialogue between a human and a machine, and we employ a "interaction stylesheet" that separates the intention and communication technique as brilliantly as "cascading stylesheets" separate structure from presentation today. Then, hopefully, we will truly realize access to information and behavior through multiple natural access methods including keyboard, mouse, remote control, mobile device and speech recognition.

I periodically checking on the W3C's XForms standard and I'm pleased to see that it's a great step in the right direction.

Bill's Space: WPF

Acropolis: The Answer to the WPF Blues

WPF and Section 508: Not Ready Yet