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".

 

 

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.

 

 

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...

https://video.msn.com/video.aspx?vid=1184a0e0-3865-4dfa-accc-ce01c65bcc5f

 

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

Comments

• Anonymous
  December 19, 2007
  Let's dive into some design. Obviously, there's way too much to cover so I'll start small