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.