December, 2007 - Microsoft PixelSense Blog - Site Home - MSDN Blogs
Blog Entries
  • Microsoft PixelSense Blog

    CES...Here We Come!!


    CES is right around the corner and the Surface team is getting ready to show off some new demo experiences. Over the past few weeks (and nights, and weekends, and mornings...ugh) we've been dogfooding these demos and making sure everything is tip-top. So, the Super Friends had their Hall of Justice...well, we have the Hall of Surface...

    Dogfood session

    We are excited to share more potential applications for Surface, a few new scenarios where you might encounter Surface and even a potential integration opportunity with one of the other Microsoft teams.

    Dogfood session2

    That's all I'm saying'll just have to wait until CES to learn more. We'll have three Surface units in the Microsoft booth and I'll be giving daily demos in the presentation theater. I'll also be doing a daily blog from the show floor (well maybe from the hotel). Swing on by and say HI.


    K Robert Warnick

  • Microsoft PixelSense Blog

    Access Points


    Let's dive into some design.  Obviously, there's way too much to cover so I'll start small and specific and we'll gradually cover more ground over time.  So, I'll start with general navigation and a key navigational element we call "Access Points".


    In creating a navigation model for any system, you generally take stock of all the places users will go and things they will do and see (information architecture).  How much of anything exists, how it's grouped, relationships, tasks, etc. all impose requirements on the navigation model you create.  Fortunately for us, we're currently dealing with a fairly simple model:  provide a place (our Lobby) for users to find and select an app, launch it, enjoy it, and then return to the Lobby to launch a different app.


    We made a decision very early on that every app runs full-screen (perhaps a topic for another blog posting).  Once again, keeping it simple.  Because apps run full-screen, the Lobby would not be visible so we provide users with a mechanism to navigate back to the Lobby:  our "Access Points".


    access pts simple nav diagram


    These Access Points should be available to users in a consistent manner regardless of which app is running or the state of that app.  However, how many should we have and where to put them?  Given the state of our project at the time such decisions were necessary, we were constrained to a software solution.  Now, we know as well as anyone how valuable screen real-estate is, so of course we explored solutions in which our Access Points could live off-screen and appear on-screen only when called upon.  We did come up with various clever solutions, but in the end we knew our product was destined for commercial venues.  This meant we needed walk-up -and-use simple solutions requiring zero instruction or learning.  We landed on the inevitable conclusion that we had to have something continually visible and available, which meant consuming some valuable app screen real-estate!


    So, Access Points on the screen, but how many and where?  Well, we looked at scenarios in which four people were sitting around the table, one at each edge, to ensure each person had easy access.  We also looked at it from an app designer / developer perspective.  We researched all of our own prototype apps, demos, etc. and found that in most cases information and controls for a particular user sitting at one edge of the table were positioned toward the center of that table edge (or display edge).  For example, imagine a card game wherein each player's cards are centered in front of him/her  at his/her edge of the display.  Accordingly, we narrowed our possible screen regions to the four corners.  Every user has easy access to at least one and we leave all the central screen areas open for the apps.


    Access Points


    Today, the Access Points are buttons residing in each corner of the screen, and designed to be semi-transparent so as not to compete with the app for the user's attention.  To see them in action, check out this video.  Side note:  In the early Surface demos and videos, you won't see these access points.  However, you'll know you're looking at something new and closer to our finished designs when you see them in our latest videos and demos.


    Here's a video showing the access points in action...


    Already looking beyond our version 1 launch, we're exploring additional functions and capabilities for these Access Points , but I can't talk about that just yet :-)


    Happy holidays everyone,

    Ali Vassigh

  • Microsoft PixelSense Blog

    Why 52?


    As I mentioned a while back, there is theoretically no limit to how many contacts an app can get simultaneous input for.  The official number is "dozens and dozens", but internally we use 52 to set performance goals for the platform.  In choosing the number to set as our arbitrary v1 benchmark, the team evaluated a number of application scenarios and determined that games were the category of apps most likely to need the highest number of simultaneous contacts.  After looking into a number of game concepts, it was decided that supporting a game involving 4 people simultaneously using  10 fingers + 3 game pieces (4*(10+3)=52) would go far beyond the needs of most applications we foresee for v1.  Over time, as Surface takes on new form factors and new app concepts are dreamed up, this benchmark will surely increase.



Page 1 of 2 (5 items) 12

December, 2007