Scott Hanselman

If you're not interested in babies or baby sign language or hearing me gush about baby sign language, move right along, nothing to see here! (You're so heartless!)

This is Baby #2, codenamed "Mimzy" (he's a boy, don't ask), signing 'cracker' in ASL. He's 13 months old in the video. He's signing up a storm, and is speaking faster than I thought possible for a little dude. He's currently signing hard words and speaking easy ones, just as our older boy did. I suspect he's moving faster because he wants to be like his big brother.

His signing is a bit of an approximation, because just as toddlers don't pronounce words or "slur" for a while, who sign tend to "slur" for a while. Here's the actual ASL sign for "cracker" but he's really close. Most importantly, he can be understood.

Now, this isn't a "my baby is awesome and smart" post. Nor am I trying to say "push" your kid to do something earlier than is appropriate. I figure they'll all even out by the time they are 20 years old. ;) Not many college students live the house not speaking and still wearing diapers, so I don't push my kids too hard.

However, I'm just so passionate about the extra year of communication per baby that Baby Sign Language (ASL) gives us, and the quality of that communication, that I'll just gush and talk to anyone who will listen.

Baby #2 is now 14 months old and he's been signing for about 3 months. We've been signing to him since he was 7 months, so there was a 4 month people were he'd just grunt and point and look at us. From what I here, that's par for the course when you introduce signing to your baby. Most people say 6 months is the perfect time, but you should expect nothing for months. Stick with it.

It'll click one day, as it did for Baby #2. Out of nowhere he asked for a cracker. Then grapes, then an apple. If you've got young children, you're no doubt familiar with tantrums. If a kid doesn't feel understood or get what they want, they freak out. I can't tell you how refreshing and freeing it is for a baby (not yet a toddler, we're talking, a little wobbly baby) to ask specifically for grapes rather than apples. The benefits of avoiding the little freak-outs that are caused by simple misunderstanding or confusion are just joyous. To look at their face while they are saying/signing something - expressing their intent - clear as day, is such a great feeling. It's nice to find out that an 11 month old can do more than just grunt and point.

I really recommend the Signing Time videos if you're interested in signing with your baby. I am not affiliated with them, I just think they are awesome. Rachel Coleman and her husband have a deaf daughter and started Signing Time in 1996. Rachel blogs here and twitters as well.

Here's some resources from a previous post:

What do you need to do to start signing to your baby?

• Check your local community center. They often offer Baby Sign Language classes. We took classes before #1 was born, and when he was 6 months old.
• If Baby Sign Language is unusual or unused in your country, either find some Deaf Folks and learn your country's specific Sign Language, or use ASL (American Sign Language). The trick is to be consistent and have an illustrated dictionary to refer to.
• Stick with it. Don't give up. We started when he was six months old and signed every day without a single clear response until he was a year old. We nearly quit a dozen times before that.
  • Then one day he signed "light" as clear as day in his bedroom. We turned on the light and our son lit up with a small as wide as his face. That's when we connected with him. I'm not talking about the standard Mom/Dad/Baby we-love-you connection. I'm talking about the baby's opinion matters kind of connection.
• Get picture books, lots of them, and learn the signs for the animals. I highly recommend the Priddy Books series of books for baby.
  • Learn the signs for animals and common objects and use them every time you see one out in the world. We went for a walk on the Portland Waterfront today and our son was signing bird and dog and plane and sharing those discoveries with us. It's great when he sees something interesting and points at it, but it's something different when he signs about something we didn't see.
• Pay Attention and prepare for the unexpected.
  • Example: The baby was frantically signing ball recently, gesturing wildly at a dog. We tried to correct him..."No no sweetie, that's a dog, not a ball." The dog lifted it's head and we saw that the dog was in fact playing with a ball that we hadn't seen.

I've blogged before (see below) at length about signing with your baby (or any non-speaking or slow-to-speak child) so I won't belabor the point, so here's some related posts.

If you've used Baby Sign Language, with or without success, I'd love to hear from you in the comments!

Related Posts

• Baby Sign Language
• Baby Sign Language - Update at 14 months
• Baby Sign Language - Update at 2 years
• Baby Sign Language 2.0 (Baby #2 at 9 months)

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

What do you need to get through the Great Depression 2.0? Why, a giant computing table, of course! Sadly, the Surface SDK isn't available to folks without a real Surface (which, I say, is a bummer) so I can only tell you that developing for it is awesome. Lame, yes, I know.

I can't get you the SDK (yet?) or a Surface (I'm broke) but I can tell you what developing for it was like.

Of course, if you DO have an extra US$15,000 lying around, why not let your baby sit on it? That's my thinking.

BabySmash (Code and DevCenter here) has been on hold over the holidays, although I have a lot of big plans once I get on the other side of the Mix conference.

One of the things I talked about at my PDC BabySmash talk (WMV) was porting BabySmash to the Surface. BabySmash is a simple WPF application that responds to keyboard and mouse input. Since there's no keyboard or mouse in the standard Surface configuration, I wanted to see how had it would be to port it.

I had to deal with these changes in thinking:

• Orientation matters. People might be sitting on opposite sides of the Surface
• No mouse or keyboard. Many people can touch it at once.
• Multifinger resizing. Folks expect to be able to multitouch a Surface and resize items, throw them around, etc.
• Different application launcher model. The Surface needs an XML manifest and special icons for its launcher.

Other than these changes, a Surface app is still .NET WPF app, so I wasn't too worried.

Surface Simulator

The first step was to install the Surface Simulator. It only works on 32-bit Vista, so I had to go make myself a 32-bit machine (I'm all 64-bitted up. FTW!) which was a tiny hassle. (Although there ARE some Vista 64 Surface Simulator hacks) The Simulator is exactly what it sounds like. It's not "emulating" however, as a Surface is still a Vista machine underneath. It's more of a frame and some mouse input management to handle multiple mice and make them look like multiple fingers. This works surprisingly well. In the PDC talk, about halfway in, I plugged in three mice, plus the built in touchpad and had multiple virtual "fingers" moving items around the screen.

You create your Surface app as you would a WPF app from File | New Project, hit START and it fires up the Simulator and frames up the WPF app.

Now in my case, I already had an existing WPF application, so I needed to change the type my main Window derived from from "Window" to "SurfaceWindow" and I added an assembly reference and a few namespaces:

using Microsoft.Surface;
using Microsoft.Surface.Presentation;
using Microsoft.Surface.Presentation.Controls;

This base class adds adds all the Surfacey goodness and events and properties that my Window will need.

"ContactDown rather than KeyDown and MouseDown

I added an event for "Contact_Down" rather than watching for keyboard events and mouse clicks that would never come.

private void SurfaceWindow_ContactDown(object sender, ContactEventArgs e)
{
    controller.AddFigure(this, " ", e.GetPosition(mainGrid).X, e.GetPosition(mainGrid).Y);
}

BabySmash uses an MVC model, so I'm taking the input from the View and immediately delegating to a main controller object that handles everything.

Orientation

Your app can let the system decide which side of the Surface table the user is sitting on when it starts up. This isn't a huge deal with BabySmash, since it's just shapes, but still there's some text on the screen so I wanted the app to be right-side-up when appropriate.

There are a bunch of new properties on a SurfaceWindow, and one is:

AutoOrientsOnStartup="True"

This changed the orientation of my entire application, basically turning it upside down when need-be. This did mean that I couldn't use any low-level X and Y APIs, otherwise the coords would be "lost in translation." As long as I stuck with high-level stuff like "GetPosition" to pull my X and Y's out, the Surface SDK would handle translation and everything just worked.

Application Launcher Manifest

I needed to create a few icons for my app to live in the Surface Launcher and a manifest. There's other options I didn't use, as well as ways to create animated icons, or to have your application run as an "attract mode" app, to get folks wandering by to stop and touch the Surface.

<?xml version="1.0" encoding="utf-8" ?>

<ss:ApplicationInfo
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:ss="http://schemas.microsoft.com/Surface/2007/ApplicationMetadata">
  <Application>
    <Title>BabySmash!</Title>
    <Description>BabySmash! for Surface</Description>
    <ExecutableFile>c:\BabySurface\BabySurface.exe</ExecutableFile>
    <Arguments></Arguments>
    <IconImageFile>c:\BabySurface\Resources\icon.png</IconImageFile>
    <Preview>
      <PreviewImageFile>c:\BabySurface\iconPreview.png</PreviewImageFile>
    </Preview>
  </Application>
</ss:ApplicationInfo>

ScatterView

In the original BabySmash app I had a canvas that would hold all the shapes and letters, but I wanted things to be more Surface-like in this (hacked-together) BabySurface version.

public void AddFigure(UserControl c, double x, double y)
{
    this.figuresCanvas.Children.Add(c);
}

Fortunately there's a control called a ScatterView that makes throwing stuff on the Surface insanely easy. For example:

<s:SurfaceWindow
      xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
      xmlns:s="http://schemas.microsoft.com/surface/presentation">
      <s:ScatterView>
            <Image Source="Toco Toucan.jpg"/>
            <Image Source="Green Sea Turtle.jpg"/>
            <Image Source="Desert Landscape.jpg"/>
      </s:ScatterView>
</s:SurfaceWindow>

From their blog (here's a video of the Surface SDK in action):

ScatterView is a custom ItemsControl in our SDK which apps can databind or populate with any type of content. Simply sticking some Image elements in it gives you a basic Photos-like app without writing any code. By baking common manipulations into WPF SDK controls like this, we’re able to free developers up to focus on things that are unique to their apps while designers use Blend to add some custom pizazz.

I changed my AddFigure method to put the new shapes in a ScatterView. I also hooked up a "ContactLeave" event to the new item so that the application would giggle when you lift your finger.

public void AddFigure(UserControl c, double x, double y)
{
    var s = new ScatterViewItem();
    s.Content = c; 
    s.ContactLeave += new ContactEventHandler(s_ContactLeave);
    this.figureScatterView.Items.Add(s);
}

This was cool, but it had a few issues. First, the ScatterView puts everything in a "Polaroid"  border by default:

The result was that my BabySmash shapes were inside a Photo Border. Easily removed with a custom style that marked a few properties as {x:Null}:

<Style x:Key="ScatterViewItemBabySmashStyle" TargetType="{x:Type s:ScatterViewItem}">
    <Setter Property="Background" Value="{x:Null}"/>
    <Setter Property="BorderBrush" Value="{x:Null}"/>
    <Setter Property="Foreground" Value="{x:Null}"/>
...

The second issue was that while my BabySmash shapes were draggable and scattered nicely, they weren't resizable. Well, they WERE, except when you resized them, you were resizing the container - that is, resizing the now-invisible Polaroid border. I needed a box to put the shapes in that would effectively lie to the inner control and scale/size them as the outside scaled and resized. Enter the ViewBox, including with WPF.

public void AddFigure(UserControl c, double x, double y)
{
    var s = new ScatterViewItem();
      s.Center = new Point(x, y);
      s.Style = this.Resources["ScatterViewItemBabySmashStyle"] as Style;
    
    Viewbox v = new Viewbox();
      v.Child = c;
    
    s.Content = v; 

    s.ContactLeave += new ContactEventHandler(s_ContactLeave);
    this.figureScatterView.Items.Add(s);
}

I put the Control in the ViewBox, and put the ViewBox+Control in a ScatterViewItem. Bam, resizable, scattered BabySmash shapes.

I also got dragging and inertia (physics) for free so you, ahem, the baby, can spin and throw shapes around as well.

This development was all done on the simulator. I never saw a real Surface until I got to PDC last year. The app ran exactly as should. I was a little worried that the real Surface was somehow different, but not so. That was a huge relief.

If you have a very visual, shape oriented application that could benefit from touch and a big screen, porting it to the Surface isn't rocket science.

Definitely check out the PC17 "Developing for Microsoft Surface" talk from PDC. There's a lot of good stuff in the PPT as well with insights into how Multitouch is going to work in .NET 4.0 and Windows 7 and how work on Surface now is driving that future.

And really, who WOULDN'T want a Big Ass Table? I, for one, would like one for the living room. ;)

Related Links

• PC17 "Developing for Microsoft Surface" talk from PDC
• PDC BabySmash talk
• BabySmash DevCenter or Install BabySmash
• Learn more about Surface

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

Scott talks to Doug Cook, Hal Saville, and Lee Brenner about their dramatic new Twitter client, called "blu" (formerly "chirp") with a jelly aesthetic you have to see to believe. How do they find developing in WPF? What's their workflow? What's coming for the next release of blu? Let's put the pressure on them to make it even better, eh?

Subscribe:

• Download: MP3 Full Show #149
• Play in your browser.

Do also remember the complete archives are always up and they have PDF Transcripts, a little known feature that show up a few weeks after each show.

Telerik is our sponsor for this show!

Building quality software is never easy. It requires skills and imagination. We cannot promise to improve your skills, but when it comes to User Interface, we can provide the building blocks to take your application a step closer to your imagination. Explore the leading UI suites for ASP.NET and Windows Forms. Enjoy the versatility of our new-generation Reporting Tool. Dive into our online community. Visit www.telerik.com.

As I've said before this show comes to you with the audio expertise and stewardship of Carl Franklin. The name comes from Travis Illig, but the goal of the show is simple. Avoid wasting the listener's time. (and make the commute less boring)

Enjoy. Who knows what'll happen in the next show?

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

There's been lots of talk about MEF lately, but what the heck is it? Is it an Open Source Project or is it part of the .NET Framework? Is it both? Is it an IOC Container or something new? Glenn Block sets Scott straight in this interview recorded on the Microsoft Campus.

Subscribe:

• Download: MP3 Full Show #148
• Play in your browser.

Do also remember the complete archives are always up and they have PDF Transcripts, a little known feature that show up a few weeks after each show.

Telerik is our sponsor for this show!

Building quality software is never easy. It requires skills and imagination. We cannot promise to improve your skills, but when it comes to User Interface, we can provide the building blocks to take your application a step closer to your imagination. Explore the leading UI suites for ASP.NET and Windows Forms. Enjoy the versatility of our new-generation Reporting Tool. Dive into our online community. Visit www.telerik.com.

As I've said before this show comes to you with the audio expertise and stewardship of Carl Franklin. The name comes from Travis Illig, but the goal of the show is simple. Avoid wasting the listener's time. (and make the commute less boring)

Enjoy. Who knows what'll happen in the next show?

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

Levi Broderick, a Senior Developer on ASP.NET MVC and all around smart dude, posted some details to an internal Microsoft mailing list today and I thought it was worth sharing. Levi agreed and I've expanded on it some. Phil blogged some about Model Binding to a List last October.

The default model binder will handle a number of collection types for you, if you play by the rules and make your HTML form elements follow a certain format.

If the method signature looks like this:

public ActionResult Blah(Person[] people) {
  // ...
}

And we are given this input in our HTML:

<input type="text" name="people[0].FirstName" value="George" />
<input type="text" name="people[0].LastName" value="Washington" />
<input type="text" name="people[1].FirstName" value="Abraham" />
<input type="text" name="people[1].LastName" value="Lincoln" />
<input type="text" name="people[3].FirstName" value="Thomas" />
<input type="text" name="people[3].LastName" value="Jefferson" />

Which turns into this as a HTTP POST:

people%5B0%5D.FirstName=George&people%5B0%5D.LastName=Washington&people%5B1%5D.FirstName=Abraham&people%5B1%5D.LastName=Lincoln&people%5B3%5D.FirstName=Thomas&people%5B3%5D.LastName=Jefferson

Which is basically:

people[0].FirstName = "George"
people[0].LastName = "Washington"
people[1].FirstName = "Abraham"
people[1].LastName = "Lincoln"
people[3].FirstName = "Thomas"
people[3].LastName = "Jefferson"

Then it will be just as if we had written this in code:

people = new Person[] {
  new Person() { FirstName = "George", LastName = "Washington" },
  new Person() { FirstName = "Abraham", LastName = "Lincoln" }
};

The way that we read in the properties is by looking for parameterName[index].PropertyName.  The index must be zero-based and unbroken.  In the above example, because there was no people[2], we stop after Abraham Lincoln and don’t continue to Thomas Jefferson. 

If the signature looks like this:

public ActionResult Blah(IDictionary<string, Company> stocks) {
  // ...
}

And we are given this in HTML:

<input type="text" name="stocks[0].Key" value="MSFT" />
<input type="text" name="stocks[0].Value.CompanyName" value="Microsoft Corporation" />
<input type="text" name="stocks[0].Value.Industry" value="Computer Software" />
<input type="text" name="stocks[1].Key" value="AAPL" />
<input type="text" name="stocks[1].Value.CompanyName" value="Apple, Inc." />
<input type="text" name="stocks[1].Value.Industry" value="Consumer Devices" />

Which like this:

stocks[0].Key = "MSFT"
stocks[0].Value.CompanyName = "Microsoft Corporation"
stocks[0].Value.Industry = "Computer Software"
stocks[1].Key = "AAPL"
stocks[1].Value.CompanyName = "Apple, Inc."
stocks[1].Value.Industry = "Consumer Devices"

Then it will be just as if we had written:

stocks = new Dictionary<string, Company>() {
  { "MSFT", new Company() { CompanyName = "Microsoft Corporation", Industry = "Computer Software" } },
  { "AAPL", new Company() { CompanyName = "Apple, Inc.", Industry = "Consumer Devices" } }
};

The way that we read in the keys is by looking for parameterName[index].Key, and the way that we read in the values is by looking for parameterName[index].Value.  If the key or value type is a complex type (like Company, in the above example), then we treat parameterName[index].Key or parameterName[index].Value as the entire field prefix and start appending the .PropertyName suffix to the end of it.  The index must also be zero-based and unbroken, as mentioned previously.

Parameters of type IEnumerable<T>, ICollection<T>, IList<T>, T[], Collection<T>, and List<T> are bound using the first syntax.  Parameters of type IDictionary<TKey, TValue> and Dictionary<TKey, TValue> are bound using the second syntax.

Of course, as with most of ASP.NET MVC, if you don't like this behavior you're welcome to change it by writing your own binders for specific types or by pulling the information from a FormCollection directly and doing your own thing.

Levi adds:

FWIW – you don’t need the bracket notation if you’re submitting simple types to the server.  That is, if your request contains key=foo&key=bar&key=baz, we’ll correctly bind that to an IEnumerable<T>, IList<T>, ICollection<T>, T[], Collection<T>, or List<T>.  In the first sentence in this paragraph, "simple type" means a type for which TypeDescriptor.GetConverter(typeof(T)).CanConvertFrom(typeof(string)) returns true.  This makes a handful of cases simpler.

Thanks to Levi for the nitty gritty!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By