How creating Surface apps is different, part 2

How creating Surface apps is different, part 2

Continuing the list from my previous post

Multiple simultaneous users

The Surface is all about multiple simultaneous users interacting with each other and the Surface. The typical PC is designed for a single user.

There are a lot of implications of having multiple people using your application at once. Global states should be avoided. You wouldn’t want one user to be able to delete all the photos from a photos application while another user is correcting redeye.

You can use per-user UI to give a user their own section of the screen (like where an individual player would keep their cards and chips in a poker game.) This can take a lot of screen space. It also assumes you know how many users are actually using the app.

Sometimes you can depend on social interaction to mitigate multi-user problems (like people agreeing on a color change in the paint app.) Other times you can’t. It’s probably a good thing to reduce the amount of negotiations between your users. As a parent I’ve had this made very clear whenever I ask my kids to share a single toy. There has been some interesting research on this.

Multiple user contexts

There may be trouble with multiple users using, say, an instant messaging application. The client side of the IM service may only allow a single logon per machine. The server may only allow one logon per IP address. If your application uses local OS security features, your application may have difficulty getting at restricted resources for different users simultaneously.

There aren’t any magic fixes for this other than to architect your system to support this end to end.

Multiple simultaneous drag-drop operations

On a desktop OS, drag and drop is a system modal operation. The APIs for this type of operation really only expect one drag and drop operation active at a time. On the Surface you can have many users dragging many different things from many “drag sources” to many “drop targets.”

System-wide we do not have any great solutions for this yet. Within a single application there are ways to accomplish this in a fairly clean manner (the Music demo has to deal with this.) The SDK team is producing samples to demonstrate one way to do this.

Traditional idea of keyboard focus and insertion carets will not work

On a desktop OS, only one edit control on the system will receive keyboard input at any time. There is also only one edit control that will have an insertion caret.

On the Surface, this is not such a big deal since there is no hardware keyboard anyway. However if you want to enter text in your app using an on-screen keyboard, you will have difficulties using the standard Windows/WPF controls.

 

For the best Surface user experience you want to design applications to not require text input. For the times where text input is absolutely required we are producing a soft keyboard and related components that will make it easy for application developers to do text input.

Comments

• Anonymous
  January 04, 2008
  ASP.NET Scaffolding in ASP.NET: Dynamic Data Support [Via: infoq.com ] Unit Testing ASP.NET Pages Using...

• Anonymous
  January 04, 2008
  Link Listing - January 4, 2008

• Anonymous
  September 09, 2008
  I am not sure if this in the developers mind, is there going to be voice integration into surface applications?

• Anonymous
  September 09, 2008
  AnandVVN, at this time, the hardware does not have voice input built in. At the same time, it is running on a Vista PC and I can imagine a scenario where a developer could add mic inputs to their environment and use them in their application. This is where it gets interesting. Once Microsoft Surface shipped to our customers and partners, they have come up with all sorts of creative applications. Harrah's uses networked cameras in their ceiling to allow guests to intereact with each other and see each other across a crowded bar. I think the limit with Surface is only the imagination. I guess that means it can be limitless.