Workflow in the .NET Client Continuum – Part I

Author: Richard Griffin
Blog: http://blogs.conchango.com/richardgriffin

Expression Newsletter, subscribe now to get yours.

In my previous series, I introduced you to the Integrator and the differences between the ways in which designers, developers and integrators view the world when looking at a user interface. Rather than trying to come up with a demo project we thought that it would be more applicable to document a real project we completed recently that my colleague Felix and I worked on. The outline of the articles coming next attempts to help the different parties understand each other better by illustrating how they view the application. Over the course of these articles, I want to dig deeper into workflow and break down each role’s perspective of the UI. Although the newsletters are not essential reading, I would suggest taking a look, as I will assume that you already know some of the basics.

I have become rather fixated on the process of carving up the UI. There are a number of reasons for this. Good UI implementation requires a good design; good experience design which has to be understood by the people implementing the design and the experience into something with which users will have fun interacting. The aim of this series of articles is to help you understand the different skill sets of the team, how each member of that team perceives the UI, and how the team members work together. There are four parts in total; each one will focus on the same part of the application, but from the standpoint of the designer, user experience, developer and integrator.

• Part I – Activating the application
• Part II – Displaying search results
• Part III – Building custom controls
• Part IV –Lessons learned

Part I: Activating the Application—Integrator View

Before we dive in: for those readers who are not familiar with the application, you can go and check out the video online ( http://www.youtube.com/watch?v=7uspwwclsKY), which will help set the context of the application and provide a walkthrough of the user journey on which these articles are based. The vision is to provide an innovative experience for visual searching in the enterprise using FAST.

Design Brief

The application starts with the user placing his or her ID card on the Surface table; on the back of the card is a domino tag. The application recognizes who the person is and responds by displaying the tag information and the options available to the user. The domino tag is essentially a byte code that lets the system know which user has placed the card on the table, so you can say that there is a one-to-one relationship between the byte code and the user, a unique identifier. The designer wanted to have a visual representation of the business card when in contact with the surface, this need to mirror the physical object. The options that are placed around the ID card are made available to the user, which provides the starting point into the application. It is paramount that these options be presented in such a way to make interacting with them easy: the gestures need to be subtle and natural.

Through the Eyes of the Integrator: What Do They See?

In the annotated example above, we now know that there will be a Surface window, and into that we will put a grid so that the designer will be able to position animations and other assets in the window. The Surface API provides a Tag Visualization control that will recognise the domino tag and provides a UI Element where we can add other required visual elements. We know that there will be a number of options related to the tag, so this is prompting the use of an Items control. By changing the Item Panel Template to a custom panel, we can provide a custom layout of the items inside the Items control. As there will be a number of options that are potentially different for each user, these options will need to be data-bound, and therefore we will also need to know who has just activated the session. We also need an animation to be triggered when the card has been placed on the table, an animation to expand and shrink the option panels when being docked or undocked. The final part is that there needs to be some audible recognition to the users that they have placed their tags and they have docked or undocked the options panels.

What we end up with is a surface list box that is data-bound to a LoggedIn User View Model that will also provide the data for the person and will power the available options for that user. The Item Panel Template has a custom panel, which we’ll call a Fan Panel for now, that provides the animation and layout of the available options to the user. The animations and sounds can be triggered using triggers in the XAML. We may have to write some C Sharp code to fire off an animation, but it’s important to note that if this is the case, then these storyboards will be defined in XAML. The final step is to add the different definitions to the collection of supported domino tags. And that is pretty much the makeup of the Tag Visualizer. 

Having built the control, we realize there are a couple of problems with the interactions: none of the items in the fan panel can be undocked; in an undocked state, we need to enable the user to use different gestures, such a pinch gesture to increase the size of the options panel and also the ability to move these around the screen. In WPF this would require a custom control; however, in the Surface SDK there is a very useful control called a Scatter View. With WPF it’s all about Item controls, and that carries over into the Surface mindset but the most used Items control has to be the Scatter View which provides a rich out-of-box experience that provides a large number of the interactions required to provide a 360 degree NUI environment.

But Where Will the Scatter View Live?

In the main window, of course...if you are nodding now, then you thought the same as me; however this is not the case. Interestingly, the Scatter View lives within the Tag Visualization UI Element. When the tag is placed on the surface, the UI Element actually takes up the whole area of the main window—which, if you have a Scatter View control defined in the main window, you won’t get to see, as the Tag element is over the top of the Scatter View. The way I got around this was to place the Scatter View control inside the Tag control. So, we are now getting closer to our goal; the next step is to build some drag-and-drop helpers that will allow the user to undock and dock the options panels.

Drag and Drop—What Does That Have to Do with Anything?

Well, I am planning to drag and drop the options panels from the Tag control into the Scatter View and enable the user to interact with the options panels.

For a good example of drag-and-drop helper classes, take a look at the SDK Samples, which provide an approach to achieve drag-and-drop between an Items control–based control and a Scatter View. With the helper classes in place, we can provide an experience whereby the user can drag items from the tag control on to the Scatter View and manipulate the options just like another Scatter View Item. Cool, not so bad.

We did have a slight problem once this had been rolled in whereby the tag would not work outside of the Scatter View control—strange, huh? Well, this was all down to the tag control not having a background and set to Null. Changing this to transparent solved the problem.

However, drag and drop is such a common requirement, and especially with regards to a NUI. The next part that we need to complete is how to change the look and feel of the panel when it’s docked to being undocked, we could build in some sort of 3D flipping of the element, but this did not fit with the drag gesture that is used to undock the panels. So, a simple solution is to use a data template selector. As we know what type of object we are dragging onto the Scatter View control, we can change the look and feel by swapping the data template using the data template selector.

There also needs to be either a look-less or user control that we can put inside the data template. The control will then leverage the data context of the data template and feed data to the control. What we end up with is a user control used by the data template that contains a Surface List box that can easily be data-bound. Using the same drag-and-drop helper classes as before to enable the user with the ability to drag items from the list onto the Scatter View Control. Once the gesture has completed, the control is add to the Scatter View Items collection.

In the next article we will dive into the search rose.