Project Milo

For this post, I decided to look into Anne Martin's Oct. 12th post on Project Milo, an extension of Microsoft's new Project Natal (pronounced nah-TAHL). The idea of Milo combines aspects of virtual worlds (e.g. Second Life or the SIMS) with the incredible capabilities of Natal, allowing users to interact with a virtual boy on their screen named Milo.

The demo (http://www.youtube.com/watch?v=yDvHlwNvXaM) aired at the GameTrailers.com conference in 2009, and features a woman, Claire, who introduces us to Milo and demonstrates how one can interact with him.

Although the demo is short, we get a glimpse of several key points throughout:

1. Milo can recognize and react to Claire in a natural, casual conversation. He recognizes the things she says and responds in very relevant ways.
2. He picks up on Claire's nervous emotion and tone and is able to spit off a few jokes throughout the demo. In addition, he shows emotion in his facial expressions and the way he talks. In other words, he is a very realistic and dynamic character.
3. Using Natal's capabilities, Claire is able to "hand" Milo a drawing she created (the camera scans the paper and it shows up in Milo's hand); she also spends a few minutes playing in the water, where she can see her reflection and play in the water.

Although it's difficult to imagine technology like this is available or even right around the corner, demo spokesman Peter Molyneux claims the demo isn't "acted" and that the technology is "here" and "now." Project Milo seems to effectively bridge the divide between real and virtual, immersing users in a new world that's somewhere between the two. Natal is expected to be released in late 2010.

Microsoft LucidTouch

With all the focus on touch-enabled devices and multitouch computer screens, there's one problem that continually pops up...people's fingers are not good mice. It's difficult to get near-pixel accuracy with a finger that's no less than thirty pixels wide at the tip. Perhaps more importantly, touching the screen requires that you block your view of a part of the screen, even if it is just a finger. As a result, software design for touch-enabled devices must always take into account the lack of precision their users will have when operating the device.

Microsoft tries to come up with answer to this problem (at least partially) with the LucidTouch.

The idea behind this device was that allowing users to touch the back of the screen, they could always see the entire screen, and hopefully improve their touch precision. The device superimposes a semi-transparent hand on the screen based on your hand behind the screen, so you can in effect see and aim the cursor without blocking any screen real estate.

Although an intriguing device, and arguably more effective than traditional touch devices, the LucidTouch does little to address the problem associated with the size of a human finger in comparison to a mouse cursor, and the question of whether users will readily adopt this "backwards" approach has yet to be seen.

For more information on the LucidTouch, visit http://research.microsoft.com/en-us/events/techfest2008/video_g.aspx.

A Dream Kitchen

A few years back, Microsoft was invited by Disneyland (Anaheim, CA) to design a "dream home" to showcase innovative product ideas and upcoming technology that could potentially make it into consumer's homes in the future. Microsoft also has a version of this Innoventions Dream Home at its campus in Redmond which I had the opportunity of exploring this summer while interning there.

One of the most intriguing ideas I saw was in the kitchen, where the countertop exhibited Surface-like qualities. The homeowner could look up (either by touch or by voice) a recipe and display it directly on the countertop, or could place a number of ingredients on the counter and have suggestions pop up for recipes that used them. In another example, the user placed a bottle of medicine on the counter and received an indication of whether the correct medicine had been chosen. The idea behind the display was that future light bulbs would behave more like projectors and would have sensors (either camera, infrared, or both) that could detect and recognize items beneath them.

While the idea seems somewhat farfetched, the notion of extending the Surface to be a kitchen counter sounds both exciting and practical. The number of applications are seemingly endless, from helping with cocktail recipes and keeping track of daily medicine doses, to helping with homework problems, or suggesting needed items from the grocery store.

Whether future technology uses these envisioned projector sensor bulbs or places them underneath the counter like a Surface, I have no doubt that such technology will make it into homes as it becomes cheaper and more reliable.

Accessible Interfaces

One of the things we often don't think about is how blind, deaf, and other disabled people sometimes need interact with interfaces differently than many people. This summer, I spent time working with software engineers in Microsoft's User Accessibility team to ensure that the software we created would be usable and meet certain accessibility requirements.

Out of curiosity, I wondered how blind people interact with computers. This is what I came across in my first search:It's a refreshable Braille display, which uses special characteristics of certain crystals to raise Braille dots on a flat surface. Voltage is applied to these crystals and they expand, creating a raised surface for a Braille character. It's coupled with software on the computer that reads the screen's display from the operating system and then converts it to Braille text.

Since these devices are rather expensive and can only display a limited number of characters, speech synthesizers and software like Window's speech recognition are often popular substitutes. Nonetheless, I thought it was an interesting interface that most people may never know about but is extremely useful for the few who use it.

Smarts vs. looks: the fine line between intelligence and interface.

Designing system interfaces is quite a challenge; a slew of factors (e.g. target audience, platform dependency, and natural layout to name a few) require consideration from developers. But a critical question for these developers is often this: what is more important, making my system smarter, or making its interface better?

Obviously, there's no black and white answer here. In general, it's best to avoid extremes: while a really smart system with a terrible interface will frustrate users to the point of giving up, they'll find no reason to spend any time using a 'dumb' system with a beautiful, intuitive interface. An example: back in my senior year in high school, the school decided to invest in a couple "smart" boards for the classrooms--white boards with special functionality like recording the notes from the board or allowing a teacher to project a Word document and "write" on it with a pen.

The problem was, the interface for the white board (i.e. the software that went along with it) was so clunky that most of the technologically illiterate instructors at St. Augustine pulled their hair out trying to get all the cool features to actually work.

Not surprisingly, though, most of my instructors learned how to use the boards, as 'complicated' as they were, because they saw the benefit in having these smart features enhance their teaching. While the clunky interface often frustrated rather than facilitate, at the end of the day most teachers preferred a smarter, occasionally frustrating board to a 'lifeless' old-fashioned chalk board.

In general, a good rule of thumb is that content is king. The same rule should apply to the intelligence of our systems. If you have a system that is 'smart' enough, users will be willing to put up with quirks in the interface (to an extent), so long as the system makes their life easier. Developers would be wise to focus more on making systems as useful and functional as possible (i.e. smart), while avoiding critical bugs, poor layout, and confusing behavior within the interface at all cost.

Microsoft's Ribbon

Microsoft’s ribbon interface is one of the most creative (and successful) interfaces I have worked with in Windows-based software. It was introduced several years ago by Microsoft in its Office suite as a replacement for the standard Windows toolbars. At its core, the ribbon replaces menus and toolbars with tabs, each with a list of commands.

Up through Word 2003, users were forced to hunt through tiny icons and tooltips in visible toolbars or search for more obscure commands hidden in menus.

The ribbon changes this by giving more estate to more popular commands. Since users are most likely to look in the left center of the toolbar below the tab, for example, any of the ‘most used’ commands reside there.

In addition to making these commands easier to find, some edits (like styling in Microsoft Word) include drop down galleries that allow you to even preview a style on your text by hovering over it---before you even apply it.

Many users responded to the change to the Ribbon very positively, praising Microsoft for adding all sorts of new functionality to Office; the truth is, most the functionality wasn’t new! The Ribbon just brought it out to the user. That’s the sign of a great interface.

More info about the Ribbon can be found at http://office.microsoft.com/en-us/help/HA100898951033.aspx.

This is my first blog post for System Interface Design, CSE 40416.

The blog will primarily focus on innovative interfaces such as Microsoft Surface, Nintendo Wii, and others. These sorts of interfaces creatively change the way we interact with technology to improve user experiences and make using software more intuitive.