We were approached by Microsoft SA (Kath Roderick) to produce the UX design and interaction development for an interactive WPF application for Softline Pastel (accounting software provider).
One of the central objectives of the project was to showcase the advantages of working in blend, using Microsoft Surface and WPF SDK toolkits to create an intuitive and engaging Multi-touch application.
The application itself is a high level account reporting system which allows a company/user to view the history of their financial data on a highly interactive chart. The user can control the type of data and level of detail viewed as well as the time period across which the data will appear.
In my role as the designer/integrator/UX developer responsible for the interactions, I encountered various challenges and considerations undoubtedly different to those presented by “traditional” graphical user interfaces. My experience on similar projects has taught me that this role does not exclusively belong to a designer or a developer but rather someone who can bridge the gap between the two worlds.
Within our team of 2 backend devs (with minimal/no WPF experience), UX designer, Technical advisor (Microsoft), PM and myself (title still somewhat undefined) we set out to create a truly delightful multi-touch experience.
The visual design of the UI focused on interaction principles which would determine how comfortably and intuitively users would interact with the application. Touch interactions have to be executed in a way which anticipates user responses, without detracting from the user’s own sense of control.
One of the challenges when designing for a multi-touch experience was to give the UI a sense of depth, and of a tangible impression. This influenced how the intended touch gestures would work differently to traditional system interactions. How would the controls visually suggest their touch-functionality? Would the interaction with the graph involve gestures that are intuitive? How would compartmentalizing a group of controls in a module or placing them in a separate control influence the touch experience? Some of these considerations had to be revised during the integration of the design into Blend, and the implementation of XAML into the application.
Extending the Pastel brand to the application would itself pose challenges to the conceptual design of the UI, since the experience itself had to exemplify the brand essence, convenience and sophistication of the Pastel ‘My Business Online’ service had to be associated with the ease-of-use and overall experience of the application. An integral objective to this project was to demonstrate how the WPF touch technology could enhance the experience and encourage an overall positive brand impression.
With the design approved, it was time to start setting up resource dictionaries for the colours, brushes, controls and the chart itself in Blend. These assets would then be implemented into the main project file. Here the controls and their associated states would be assigned their functions. Why do we do it this way you may ask? Having dealt with many of the design and interaction issues mentioned previously, my involvement in the design phase lent an awareness of how to treat the assets appropriately. This proved to be invaluable process and starting block throughout the duration of the project.
As far as my work process is concerned, I found creating a WPF project in Blend that serves as a planning and “tidying-up” project which simplifies things as the project progresses. The Illustrator designs are imported into this “tidy-up” project, where I can then go through a refinement process where individual controls and components are consecutively grouped together, then placed in a main working project. Within the main project, colours of components are used to set up a colour dictionary, associated brush resources are created, and then component parts are converted to the relevant control templates (also referenced by a common control library). Much of the visual state behaviours of the controls are implemented in this project, as well as the parent-child relationships and structures of the controls.
Styling for the chart presented a new challenge – using the WPF Toolkit, a collection of WPF features and components made available outside of the standard .NET Framework development cycle. The purpose of the Toolkit (as with the Software Development Kits) is to allow for users to get interface functionality more conveniently. Relevant to our application, the Data Visualization control functions of the Toolkit provide a powerful means of easily creating flexible style-able charts. Not having had any experience in using the Toolkit before, I spent some time first getting acquainted with its Silverlight counterpart. Pete Brown’s Styling Charts with the Silverlight Toolkit provided a good introduction to going about styling charts. Although Brown’s focus is on the Pie Chart type, the fundamental concepts behind the styling is extendable to the other chart-types within both the Silverlight and WPF frameworks. Therefore applying these treatments to the WPF Chart went quite smoothly, at least initially…
The styling process so far had been done without visibility of the development work stream up to that point. Until then I had been styling the controls as standard WPF controls. Once we had sent the XAML over to the dev team, it was pointed out that for a multi-touch app the controls should belong to the Surface Toolkit to as great an extent as possible.
The solution to this quite simply was to create Surface templates of the relevant controls, copying the XAML from the existing styles into the new templates and changing the TargetTypes to the appropriate Surface control where needed. The “XAML” project was also structured to match that of the development teams. Whereas the Login window and Main window had each been assigned to a user control and subdivided to reference the ChartView (chart area with associated controls) and HeaderView. The layout of the controls was also defined in accordance with the designs using column and row definitions and grid controls.
Trying to get the chart to the point of being implementable now provided yet another challenge. After testing and updating their Toolkit, the dev team had started using the compatible:Series, rather than the default Toolkit, Column type, meaning that either the style I had done up to that point was no longer relevant to the new chart type, or more likely I simply couldn’t figure out how to apply my existing style to the new chart.
Furthermore, the new Toolkit seemed to require changes to the project namespaces. Admittedly, my understanding of how XAML namespaces actually work falls quite short of the mark. This is something I am yet to fully come to terms with. However, the dev team supplied me with a scratch project in which I could start styling the graph. This was more complicated than anticipated, and I think a fault on my part was instead of focusing more on the written XAML, I relied on the WYSIWYG offerings in Blend.
By trying to figure out the relationship between the Chart parent, it’s children and associated templates using the Objects & Properties panels instead of investigating the XAML more thoroughly, I suspect I may not have grasped things completely. For instance, instead of trying to set up and implement a style palette for the column series data points, I should have noted that such a palette already exists in the Data Visualization Toolkit, and I could have focused only on how the palette is referenced by the data points.
Ultimately, a substantial part of styling the graph was done by changing and adding to the existing XAML. Even though the solutions were often very simple, the XAML had to be specific. Obviously experience will help in being able to produce the appropriate XAML efficiently, but this does require a much deeper understanding of the WPF and .NET frameworks than I think Microsoft tend to acknowledge in promoting Blend as a design tool.
Supporting the dev team was one of the most central aspects of the project as a whole, and some of the greatest challenges revolved around this. Even though they were responsible for the implementation of the XAML, it was crucial to be communicating with them throughout this phase of the project. This ensured that the XAML we delivered was indeed implementable, done in accordance to the designs and resolved any issues which may have interfered with these objectives.
This is probably where my role as an integrator rather than designer became most obvious (at least in the case of this project). It was important to be able to communicate the needs of the design team to the development team, and in turn communicate back the limitations and constraints the developers may face. Even though the dev team were new to WPF themselves, I’m sure that as someone in the position of the integrator gains experience, he or she would be able to take more responsibility for the flow and efficiency of projects. I also think that one of the responsibilities of the integrator is to ask the right questions, in order to be able to establish the needs and responsibilities of the respective teams and members involved as soon as possible.
We have definitely learned a lot on this project and therefore fell confident in taking on more challenging project that influencess and improve users lives.
Please feel free to contact us regarding any questions you may have, I hope I’ve helped shed some light on an altogether new and undefined topic.