Why I Love UX (or How to Piss Off an Entire Department!)

Last Friday, I tweeted something which was badly worded, and managed to piss off much of our UX team (not to mention a few UX people far and wide):

Pissing off UX

Now I ask you, how could that post possibly offend anyone (note sarcasm)?

So, I would like to clarify what I was thinking when I posted that (and again ran into the problem that most of my thoughts do not fit into 140 characters).

First, I had been reading a number of posts and other articles by so-called UX experts, thought leaders, and others (all off whom shall go nameless, as I do not need anymore flames – well, actually I enjoy flames, but am full at the moment). Like many fanatics, they have (in my humble opinion) some fairly radical beliefs that are not well grounded in the real world. These are the “UX people” to whom I was referring in my post. Yes, my choice of words was bad.

Secondly, I have a great deal of respect for the UX process. I even have a lot of respect for most of the UX people I know (even the ones with whom I disagree). Frequently it is the UX department with whom I have an issue. I have the same issue with Marketing (the department) versus Marketing (the process), and with Architecture (the department) versus Architecture (the process).

The comparison with architecture is particularly relevant, as I have had many arguments over the years in software organizations as to whether “architect” is a role or a job title – should there be an “architecture group” separate from the development team. My belief is a resounding NO! I tend to believe that “architect” is a role which and individual with the appropriate skills and training assumes on a specific project. On another project, that same person may be a senior developer. My concern with architects in a group by them selves is that I have frequently seen these groups (a) become extremely elitist; and (b) become too far removed from the reality of implementation, leading to architectures which are elegant, beautiful, and difficult to impossible to build on-time and on-budget. Often, the 99% philosophically correct, current-best-practice architecture is not necessary, when the 80% solution can actually be implemented on-time and on-budget.

I find that UX groups is some organizations, and UX thought-leaders in the world at large, are falling victim to much the same challenges I described for architecture. Too much separation between UX and implementation creates certain challenges.  And, there is often little willingness to deviate from the “philosophically correct vision” in favour of practical reality.

And as a final thought, I definitely do not have all the answers in these areas – I just have some very definite questions about how we (in the global sense) do things.

About these ads

SharePoint Developer Survey: How do YOU do SharePoint development?

I am curious how many SharePoint Developers (individuals, IT groups, consultants, and ISVs) are making use of any or all of the Microsoft Patterns and Practices SharePoint Guidance.

Microsoft: Get Your Shit Together on Touch Development

Testing Samples from Microsoft Surface Toolkit...

Image by John Bristowe via Flickr

I have been playing with multi-touch development for a while, both on Windows 7 with my 2740p and on the Microsoft Surface table (version 1, not the new one).

I have consistently had challenges using WPF4 multi-touch events on the 2740p, or using the Microsoft Surface Toolkit for Windows Touch Beta, and now with the newly released Surface 2 SDK.

With any of these tools, I have challenges getting the software to recognize touch events, and even more trouble getting the software to recognize 2 simultaneous touch points (the 2740p supports 2 touch points). A second touch point always cancels the first touch point.

What is funny (to me, anyway) is that the samples included with the machine in the Microsoft Touch Pack for Windows 7 work just fine on the 2740p. This indicates that it is something in the managed drivers used with WPF that is not working.

I am fairly certain that this is a driver issue. I had it working at one point after a lot of hacking and installing drivers different from the default updates. I guess an update somewhere (Windows Update, or HP Tools) has overwritten the driver I had setup to make it work.

Can I fix the drivers to make this work again? Absolutely! But that is not the point here.

This should just work!

How am I as a software developer, or as an ISV, supposed to recommend this platform to my customers, or build applications for it, when even getting it to run on different machines requires significant hacking of drivers?

If Microsoft wants to stop being seen as a joke in the multi-touch and/or tablet market, they really better find a way to get their shit together on this.

Danger! Do not implement SharePoint in your Organization! REDUX

This is a re-post of a column I wrote over on Legal IT Professionals a couple of years ago. Just posting it here so that I have a local version.

This column I want to deliver a warning to all of you out there – do not implement SharePoint in your organization! If you ignore this warning, and implement SharePoint anyway, beware. You run the risk of any number of problems, including:

  • User dissatisfaction
  • Maintainability and support issues
  • Data silos, making information hard to find, hard to share, and hard to maintain
  • Lots of rework
  • General chaos
  • Projects that take 10 times longer than you had planned, if they finish at all.

I do a lot of work helping organizations build solutions using SharePoint – is that all a lie?

Not at all. The problem here is the way you think about your projects. If you are consistently talking about “implementing SharePoint” you are going in the wrong direction. If you are talking about implementing any platform, you are setting up for failure. Many of the problems we run into with SharePoint and other platforms arise from focusing on the technologies.

SharePoint is a technology. It is a platform. It is a pretty good platform, in my opinion. Not without its problems, but a pretty good platform.

So what should you be focused on? The answer is obvious, isn’t it? The focus should be on implementing solutions to real business problems, bringing real business value. That was obvious to everyone, wasn’t it? If this is obvious, then why do I still have conversations with potential clients who come to me saying “Help us implement SharePoint”, when they cannot clearly articulate why they want to implement it? Sure, they can spout a lot of vague statements about documents, collaboration, communication, workflow, etc. but where are the clear statements about how this is all going to help their firm?

I think there are a number of reasons this happens. Firstly, maybe I am just talking to the wrong people (too many techies!). However, I have these discussions with many business people as well. Microsoft’s marketing is also a problem (though it is not Microsoft’s fault). People see Microsoft’s SharePoint marketing information, but they typically only pay very superficial attention. They see all these demos of interesting solutions that seem like they must be useful in their world. Then they go to their IT department (or decision makers) and say “Hey we need to implement SharePoint!”

Even worse, they go rogue and implement SharePoint on a small scale within their groups or departments. Then the IT group has to manage all of these emergent SharePoint deployments, so there is a decision to “implement SharePoint” firm wide.

Finally, there are those firms (hopefully very few these days) who really do not understand that they should not be thinking in terms of the technology.

So when is SharePoint not dangerous? Well, that is driven by how you got to “SharePoint” in the first place. I am not going to go into much detail here, because most of this should be pretty well engrained process (if not, call me – I can help ), but here are the big steps:

  • Identify clear business objectives/problems to be solved
  • Is SharePoint the right technology choice to solve them?
  • Don’t try to do everything at once – build a foundation and grow from there
  • Pick initial projects with high impact/visibility
  • Determine specific ROI goals, success metrics, etc. so that you know if you are meeting your goals
  • Make sure to consider the “human” side of things – introducing a platform that touches business processes and how people work requires detailed planning as to how to introduce it.
  • Get help! Hire it, rent it, grow it – whatever you have to do, get help. SharePoint is a big platform that does a lot of things, and if you do not know the platform well, you will end up building things that already exist. Also, as with most platforms, there are 6 different ways to do almost anything – some of them are better than others.

The first step, though – change your thinking and your terminology – and stop talking about “implementing SharePoint”!

Make Your SharePoint 2010 Master Page Extensible with Delegate Controls

I have been playing a lot the last little while with SharePoint 2010 Delegate Controls. I have known about them for a ling time, but have never really delved into them all that much.

Most of the examples I have looked at, and the usage ideas I have seen, involve using the existing delegate controls in V4.master to do things like:

  • Modify the Welcome Menu
  • Customize the Global Navigation
  • Add useful code to the page header

Last week, I used a delegate control for something a little different.

For a project I am working on, the client wanted some functionality displayed just below the Quick Launch, on every page in the site collection. I know there are lots of ways to do this (put a user control on the master page, put a web part on the master page, or just put links on the master page, since that’s all the content was in this case).

But then I thought of a little bit more elegant (to me) solution. Rather than explicitly putting the content on the master page, I added a delegate control of my own to the page, and placed it just below the Quick Launch, as shown below.

image

Several things to note here:

  • I gave it a ControlID specific to my application;
  • I set AllowMultipleControls to true, which will be useful later
  • I included default content in the <Template_Controls> element, so that I could see it change when I activate a Feature with an appropriate control.
  • Next, I implemented a Feature in Visual Studio 2010, with a control to replace the default content. The details of how to do this are covered in other places (such as here), but to summarize:
  • I created an empty Visual Studio 2010 project;
  • I created a user control inside the project (this automatically mapped the ControlTemplates folder for me). It is a very simple user control, and simply displays “Hello, Delegate!”
  • I created an appropriate elements.xml file to map my control to the Delegate Control’s ControlID.

So, here we see the how the delegate looks before I deploy my feature:

image

After I deploy my Feature, we see that the default content is replaced with the Feature’s control’s output:

image

But wait, there’s more! Remember that I set AllowMultipleControls to true? That allows me to deploy multiple features with controls that map to my ControlId, and instead of only displaying the one with the lowest Sequence attribute, it will stack them all in order of Sequence number, as shown below.

image

This means that I can add any number of  things to the area under the Quick Launch without further customizing the the Master Page.

Maybe I am just easily amused, but I thought that was pretty neat!

The source for this, including the master page, is available here.

Validating User Passwords in SharePoint 2010

I recently wrote a user self-registration solution for SharePoint 2010. As part of this solution, I needed to validate the requested password to ensure that it met the requirements of the authentication provider (in this case, Active Directory).

The code, while hardly rocket science, is something I do not want to figure out again. So I thought I would post it here for my own benefit. If anyone else finds it useful, that’s cool, too!

I wanted to validate that the password met various requirements from the AD policy:

  1. 1. Length
  2. 2. Complexity (contains a combination of lower case, upper case, digits, and special characters.
  3. 3. Content (does not contain all or part of user name)

I did not need to check against old-passwords to prevent repetition, since this solution is creating new users.

Checking for length is blatantly obvious, so I won’t bother showing that.

For complexity, the default AD policy is as follows:

“Passwords must contain characters from three of the following four categories:

  1. English uppercase characters (A through Z).
  2. English lowercase characters (a through z).
  3. Base 10 digits (0 through 9).
  4. Non-alphabetic characters (for example, !, $, #, %).”

This is pretty simple to do. In fact there are several ways to do it, depending on whether you want to use regular expressions, built-in methods of the string class, etc.

  1. For digits and special symbols, I simply created character arrays for those two groups, and used the string class’ IndexOfAny method.
  2. I could have done the upper and lower case the same way, but I decided to take a different approach (just for variety). For a string S, if S==S.ToLowerCase(), then S contains no uppercase letters. Similarly for uppercase.
  3. Having determined the presence of the 4 classes of characters, I can then simply add up the number of character classes found.

So, code I have used for these conditions is:

The next interesting part was the content check. To check that no more than 2 consecutive letters of the user name or full name are used in the password, I iterate over the username, taking three-character substrings, and checking to see if the password contains them. This is then repeated for the full name. If any of the substrings is found, then the password fails:

   1: protected bool PasswordComplexityValidation(string UserName, string FullName, string Password)

   2: {

   3:     char[] digits = { '0', '1', '2', '3', '4', '5', '6', '7', '8', '9' };

   4:     char[] symbols = { '~', '!', '@', '#', '$', '%', '^', '&', '*', '_', '-', '+', '=', '`', '|', '\\', '(', ')', '{', '}', '[', ']', ':', ';', '"', '<', '>', ',', '.', '?', '/' };

   5:  

   6:     bool blnHasDigits = (Password.IndexOfAny(digits) != -1);

   7:     bool blnHasSymbols = (Password.IndexOfAny(symbols) != -1);

   8:     bool blnHasUpperCase = !(Password.Equals(Password.ToLower()));

   9:     bool blnHasLowerCase = !(Password.Equals(Password.ToUpper()));

  10:  

  11:     int conditionsMet = 0;

  12:  

  13:     if (blnHasDigits)

  14:         conditionsMet++;

  15:  

  16:     if (blnHasSymbols)

  17:         conditionsMet++;

  18:  

  19:     if (blnHasUpperCase)

  20:         conditionsMet++;

  21:  

  22:     if (blnHasLowerCase)

  23:         conditionsMet++;

  24:  

  25:     return (conditionsMet > 2);

  26: }

That is about it. I make no representations that this is the best way of validating passwords, or even the best. This is just what I thought up over the weekend!

   1: protected bool PasswordContentValidation(string UserName, string FullName, string Password)

   2: {

   3:     // Check that password does not contain a large part of the UserName or Full Name

   4:  

   5:     bool blnIsValid = true;

   6:  

   7:     // Check if password contains a 3 character substring from the username

   8:     for (int i = 0; i < (UserName.Length - 3); i++)

   9:     {

  10:         string substring = UserName.Substring(i, 3);

  11:         if (Password.Contains(substring))

  12:         {

  13:             blnIsValid = false;

  14:             break;

  15:         }

  16:     }

  17:  

  18:     // Do the same for 3-character substrings from the Full Name, but only if the password is not already invalid

  19:     if (blnIsValid)

  20:     {

  21:         for (int i = 0; i < (FullName.Length - 3); i++)

  22:         {

  23:             string substring = FullName.Substring(i, 3);

  24:             if (Password.Contains(substring))

  25:             {

  26:                 blnIsValid = false;

  27:                 break;

  28:             }

  29:         }

  30:     }

  31:     return blnIsValid;

  32: }

RE:Lean software development using Kanban

Nice post. Before I write anything critical about it, I want to make clear that I think the Kanban approach is very interesting.

I have a few thoughts though, as I always do when considering agile versus "heavy" processes for software development.

First, there seems to be a bit of confusion regarding "heavy processes" and "waterfall models". Heavy processes do not necessarily imply a waterfall approach to development. I was working 20 years ago on heavy (really heavy mil-spec projects) which were employing iterative, incremental development models with frequent releases and continuous integration, nightly builds and test-driven-development, before so-called agile approaches became popular.

My second thought is around development speed and quality. The post makes a significant claim regarding the performance improvement achievable without sacrificing quality. I would love to see real stats on this across a broad spectrum of projects. It also depends upon how you define "quality", and what level of quality is acceptable. Most applications developed today for the public (especially mobile apps and web content) have very low quality requirements, as the implications of a "glitch" are not that severe. On the other hand, banking and online payment software have significantly higher quality needs. Moving on to military, medical device, and other software upon which lives depend, definable, demonstrable quality objectives are required.

Over the years (over 25 years now – man I feel old suddenly) I have led or been involved with software projects following a large number of different processes, from no identifiable process at all, to heavy mil-spec processes, to modern agile processes.

Each approach had its own value, even the "no process" model, and each had its weaknesses. The challenge I have with many proponents of agile processes is that they promote agile as inherently superior to heavy processes (of course, heavy-process oriented folks do much the same towards agile folks).

In my experience, no model works for all situations. Much like selecting a technology or a programming language, it is important to select the right approach for the right job, without being too enamoured with any one approach. While a mil-spec approach is not appropriate for a small team in a start-up, an agile methodology is equally inappropriate for a 10 year, multi-billion dollar, life-critical military project employing hundreds to thousands of developers.

Recently (well, in the last 10 years), I have become a big fan of what I term "just enough process" (which I talked about in a previous post). Always use the right tools and processes for the right job.

Displaying an XPS Document on the Microsoft Surface

As a part of an application I am prototyping, I ran into the need recently to display a document inside a ScatterViewItem on the the Microsoft Surface. Since there is (intentionally) no built-in way to display HTML content on the Surface, and displaying a Word document did not seem feasible, I settled on using an XML document, and using the WPF DocumentViewer control.

This seems pretty easy, right? Just put a DocumentViewer inside your ScatterViewItem, load the document into the DocumentViewer, and you’re done. Couldn’t be easier.

Well, displaying the XML document was indeed that easy. Unfortunately, as I expected, the DocumentViewer would not respond to touch at all. I posted a question to the MSDN Surface forums about this, and did not receive any response for several weeks.   The response I finally did receive was that I would have to develop a User Control, and handle the touch events myself.

Not being one to take advice, I decided to try another approach – I decided to see if I could hack the ControlTemplate for the DocumentViewer in such a way as to have it support touch (keep in mind that I am a relative noob when it comes to all of this WPF/Styles/ControlTemplate stuff).

So I created a simple Surface project in VS2008, and modified the SurfaceWindow1.xaml file to have a ScatterView control, containing a single DocumentViewer control, as shown below:

<s:SurfaceWindow x:Class="SurfaceDocumentViewer.SurfaceWindow1"
    xmlns=http://schemas.microsoft.com/winfx/2006/xaml/presentation
    xmlns:x=http://schemas.microsoft.com/winfx/2006/xaml
    xmlns:s=http://schemas.microsoft.com/surface/2008
    Title="SurfaceDocumentViewer" Loaded="SurfaceWindow_Loaded">
  <s:SurfaceWindow.Resources>
    <ImageBrush x:Key="WindowBackground" Stretch="None" Opacity="0.6" ImageSource="pack://application:,,,/Resources/WindowBackground.jpg"/>
  </s:SurfaceWindow.Resources>
    <s:ScatterView Background="{StaticResource WindowBackground}" >
        <DocumentViewer Margin=”15” Height="Auto" Name="docViewer" Width="Auto" />
    </s:ScatterView>
</s:SurfaceWindow>

Note that I added a margin around the DocumentViewer so that there would be something to grab on to in order to resize the ScatterViewItem. 

I then opened the project in Expression Blend so that I could get a copy of the “default” style/template for the DocumentViewer control. Opening the project in Blend, right click on the DocumentViewer, and select Edit Template | Edit a Copy…, as shown

2

Name the style (I used SurfaceDocumentViewerStyle), and define a location for it (I left it in the SurfaceWindow1.xaml file), as shown below.

3

Click OK, then save your changes and close Expression Blend.

Returning to Visual Studio, you will get a message that the project has been changed outside of Visual Studio. Click Reload to load the changes into Visual Studio. Opening SurfaceWindow1.xaml in design view, you should now see a <Style> element under <s:SurfaceWindow.Resources>, and within that, a ControlTemplate for the DocumentViewer. There are several parts to the ControlTemplate:

  • A ContentControl for the toolbar, that loads from an external assembly.
  • A ScrollViewer named PART_ContentHost that is the container for the actual document display
  • A DockPanel that provides background for PART_ContentHost
  • Another ContentControl names PART_FindToolBarHost where the search box is hosted

The only part important to me was the ScrollViewer. I also wanted to get rig of the toolbar and the search box in order to keep things as clean as possible. So I deleted the other parts.

Here then is the key step to making the DocumentViewer touch aware: I replaced the ScrollViewer with s:SurfaceScrollViewer. My new ControlTemplate now looks as shown below:

<Style x:Key="SurfaceDocumentViewerStyle" BasedOn="{x:Null}" TargetType="{x:Type DocumentViewer}">
    <Setter Property="Foreground" Value="{DynamicResource {x:Static SystemColors.WindowTextBrushKey}}"/>
    <Setter Property="Background" Value="{DynamicResource {x:Static SystemColors.ControlBrushKey}}"/>
    <Setter Property="FocusVisualStyle" Value="{x:Null}"/>
    <Setter Property="ContextMenu" Value="{DynamicResource {ComponentResourceKey ResourceId=PUIDocumentViewerContextMenu, TypeInTargetAssembly={x:Type System_Windows_Documents:PresentationUIStyleResources}}}"/>
    <Setter Property="Template">
        <Setter.Value>
            <ControlTemplate TargetType="{x:Type DocumentViewer}">
                <Border Focusable="False" BorderBrush="{TemplateBinding BorderBrush}" BorderThickness="{TemplateBinding BorderThickness}" CornerRadius="5" >
                    <Grid Background="{TemplateBinding Background}" KeyboardNavigation.TabNavigation="Local">
                        <Grid.ColumnDefinitions>
                            <ColumnDefinition Width="*"/>
                        </Grid.ColumnDefinitions>
                        <Grid.RowDefinitions>
                            <RowDefinition Height="Auto"/>
                            <RowDefinition Height="*"/>
                            <RowDefinition Height="Auto"/>
                        </Grid.RowDefinitions>
                        <s:SurfaceScrollViewer HorizontalScrollBarVisibility="Hidden" VerticalScrollBarVisibility="Auto" x:Name="PART_ContentHost" IsTabStop="true" TabIndex="1" Focusable="{TemplateBinding Focusable}" Grid.Column="0" Grid.Row="1" CanContentScroll="true" />
                    </Grid>
                </Border>
            </ControlTemplate>
        </Setter.Value>
    </Setter>
</Style>

Now, to test this, add an XPS document to your project (mine is name test.xps). Add an assembly reference to ReachFramework (XPS package support), and add using statements to SurfaceWindow1.xaml.cs as shown:


using System.IO;
using System.Windows.Xps.Packaging;

Add the following code to the end of the SurfaceWindow1 constructor to load and display the XPS document:


XpsDocument doc = new XpsDocument("test.xps", FileAccess.Read);
docViewer.Document = doc.GetFixedDocumentSequence();
docViewer.FitToWidth();
doc.Close();

Finally, to make the XPS document resize when you resize the ScatterViewItem, Add an event handler to your DocumentViewer to handle the SizeChanged event, as shown below:


private void docViewer_SizeChanged(object sender, SizeChangedEventArgs e)
{
    docViewer.FitToWidth();
}

If everything went according to plan, you should now be able to run your code and you should get a ScatterViewItem displaying your XPS file which is resizable, and which supports touch to navigate around the document.

(I think this should also work with the Surface Toolkit for Windows Touch, but I haven’t tried it yet)

Some challenges with MS Surface Development

So I have been playing with the MS Surface for a couple of weeks, and have a pretty good handle on the basics of the development model. As I said previsouly, the nice thing (for me, anyway) is that it is pretty standard .NET stuff. You can do pretty much anything you need to using Windows Presentation Foundation (WPF). That being said, it is not without its challenges, and I would like to share some of what I have seen so far. 

1) The SDK only installs on 32-bit Windows Vista. This is a challenge for me, since my T4G laptop is running XP, and all of my other computers are running 64-bit Windows 7. The big value of the SDK is that it contains a “Surface Simulator” which allows you to experiment with Surface development without actually having a Surface. I tried setting up a 32-bit Vista VM to use for the SDK, but the simulator does not work in the VM. Now the good news, after a couple of weeks of messing around, I managed to hack the .msi file for the SDK, which then allowed me to install on 64-bit Win7. All seems to work great now.  

2) WPF experience is hard to come by. I can program in WPF, and understand how it works, but when it comes to the fancy styling and more creative aspects of what you can do with XAML, I am definitely no expert. Apparently, neither is anyone else I know!

3) Changing the way you think about the user interface. This is the biggy. The UI model for the Surface is different than anything else with which I have worked. yes, it is a multi-touch platform, which is cool, but hardly unique. If all you want to do is develope multi-touch apps, you can do it much more cheaply on a multi-touch PC (both WPF and Silverlight now support multi-touch development on Windows 7). The unique aspects of the Surface are that it is social, immersive, 360-degree, and supports interaction with physical objects. In order to make full use of the Surface platform, you have to think about all of these things. You also have to break old habits regarding how the user interacts with the platform. We are used to menus, text boxes, check boxes, drop downs and all the usual UI components we have lived with for so long in desktop applications. Or the content and navigation models we are used to on the web. The Surface requires us to forget all of that, and think of interaction in a new way. In this sense, it is more like iPhone development. However, even iPhone development gives you a fairly strict environment which defines how your app ahould look. The Surface on the other hand, is wide open. You can create almost any interaction model you can imagine, supporting multiple user working either independantly or collaboratively, working from any or all sides of the screen, with or without physical objects. This requires a whole new way of thinking, at least for me.

4) Ideas. This is another big challenge. I have lots of ideas for applications for the Surface. Some of them I am pretty sure are good. Some of those are even useful. Some of my other ideas are probably downright stupid. I would like to hear your ideas. I have always believed that, the more people you have coming up with ideas, and the more ideas you come up with, the better your chances of finding great ideas. So shoot me email with any or all ideas you might have – and don’t worry, they cannot be any more silly than some of mine!

Finally, I have added a little video showing just how far you can go with the Surface UI. Hopefully in the next couple of days, I will have a video of some of what I am working on to show.

DaVinci (Microsoft Surface Physics Illustrator) from Razorfish – Emerging Experiences on Vimeo.

First Thoughts on Microsoft Surface Development

A brand new Microsoft Surface development unit arrived this week in the Moncton T4G office. As I start to develop some prototypes, I will be doing some related posts, but I wanted to start by talking about the platform a little, and the development environment.

For anyone who has no idea what the surface is, it is a multi-user, multi-touch platform released by Microsoft a couple of years ago. Have a look at this video to see what it can do.

Other the last few weeks, before the unit arrived, I have learned quite a bit about the Surface. The first interesting thing I learned was the the surface is not a touch screen in the sense that your iPhone or multi-touch laptop are. The surface of the Surface is just glass – it is not a capacitative or pressure sensitive material at all. All of the touch behaviours and interactions are based instead on a computer vision system. Inside the box there is a fairly standard PC running Windows Vista, with an DLP projector pushing the image up to the table top. There are also 5 cameras inside the box which perform the actual "vision". These feed into a custom DSP board which analyses the camera feeds into something a little more manageable for the PC. The fact that it is a vision-based system leads to some interesting capabilities, as well as some idiosyncrasies.

When the Surface is running in user mode, the Windows Vista UI is completely suppressed. There are no menus, no windows, and no UAC dialogs – nothing that would indicate it is even running Windows. There is also an Administrator mode which shows a standard Vista UI for administrative functions or for development.   

As far as development goes, the good news is that it is all pretty standard stuff. There are two approaches to programming for the Surface. The first is to use the Microsoft XNA Studio platform, the other is to use Windows Presentation Foundation (WPF). Using XNA gives you a little bit more power, as well as access to more of the "lower level" information like raw images from the video feed. Using WPF is a higher-level programming model, and comes with a set of controls specific to the Surface UI model. The nice thing is that all you know about .NET and WPF programming applies to the surface. And from a larger architectural perspective, Surface can tie into any infrastructure accessible to any other .NET-based model. It is just a different .NET UI layer.

The bigger challenge in developing for the Surface is changing the way we think about the UI, and selecting the right solutions. First and foremost, Surface applications are not just a port of a standard Windows UI. Stop thinking about Windows, Icons, Menus and Pointers (WIMP). The surface calls for a completely different models, one that I am just learning. One of the interesting statement I have read describing the Surface model is "the content is the application."
The Surface is more than just a multi-touch platform. Sure, you could implement a multi-touch solution on the Surface exactly the same as a Windows 7 multi-touch solution, but that is only using a subset of the Surface capabilities. The key characteristics of Surface interaction are:

  • multi-user, multi-touch (up to 52 simultaneous touch points)

  • social interaction – multiple simultaneous users, collaborating or working independently

  • 360 degree user interface – users on all sides of Surface at the same time, with UI oriented to support all of them

  • Natural and immersive – like the physical world, only better

  • Support for physical objects integrated into the experience (tokens, cards, game pieces, merchandise)

When it comes to selecting a solution to deploy on the Surface, the two most important keywords are "social" and "immersive". Social, because the best Surface applications are those in which the computer is not replacing human interaction, it is enhancing it. Immersive, because you want the user(s) to forget that they are using a computer, and to only be thinking about what they want to accomplish. The how should be transparent.

Over the coming days and weeks, I will post more about the Surface and what we are doing with it. Hopefully next week I will be able to post a short video. If you have any thoughts or suggestions, I would love to hear them.