You Talkin' to Me

How to Manage Frequently Changed Prompts

mssblog — Fri, 27 Oct 2006 04:41:18 GMT

POSTED BY: JOHN CLARKSON, MSS Programmer Writer

In cases where prompts need to be changed frequently, it is not necessary to recompile and redeploy a .prompts file following every change. Since a .NET speech application can use more than one .prompts file simultaneously, it is possible to put the prompts that change frequently in separate, smaller databases. When a prompt changes, recompile and redeploy just the one file containing that prompt. Use the Manage Prompt Databases... link in the Properties window, or the Manage this application's prompt databases link on the Voice Output pane in the property builder to add additional prompt databases.

Alternatively, use the SALT content tag to set a frequently changed prompt to reference a single wave file, which can be updated as necessary. To do this, enter

<salt:content href='/MyWav.wav' \>

as the text of the inline prompt, where MyWav.wav references the audio file.

Stay On The Line...

mssblog — Tue, 10 Oct 2006 20:36:37 GMT

POSTED BY: RENAUD LECOEUCHE, MSS Software Dev Engineer

Some voice applications consider the user being silent as a valid answer. For example, an application could say: “Please choose one of the following products or stay on the line to speak to a sales representative” followed by a list of products that are available for phone order. If the user stays silent for a second or so, the call continues and a transfer is made.

As you probably know, the way to ask a question and get an answer in MSS 2007 Beta is to use a QuestionAnswerActivity. However the QuestionAnswerActivity will keep repeating until it gets a valid recognition. The question then is: How to model this kind of dialog with MSS?

The answer is easy. Here is how to proceed:

Create a QuestionAnswerActivity that recognizes the product names.
Create a SpeechSequenceActivity.
Add the QuestionAnswerActivity to the SpeechSequenceActivity.
Go to the SpeechEvents view of the SpeechSequenceActivity.
Add a ConsecutiveSilencesSpeechEventActivity and set its MaximumSilences property to 1.
Add a GotoActivity to the ConsecutiveSilencesSpeechEventActivity that redirects to the part of the dialog you want to run when the user remains silent.

You are done! Adding a ConsecutiveSilencesSpeechEventActivity allows you to take arbitrary actions when the user stays silent. Because SpeechEvents are associated with SpeechSequenceActivity activities, you can localize their actions to a single QuestionAnswerActivity or a group of related activities.

How speech events work
Speech events provide a powerful way of controlling your application flow. Let me clarify how they work. Speech events are scoped to a SpeechSequenceActivity activity. When the speech sequence is executing, its associated speech events track the changes in the workflow’s History property. This is how they know what is happening in the dialog and when they can execute.

For example, a ConsecutiveSilencesSpeechEventActivity activity increments its count when a SilenceHistoryItem is assign to the History property. SpeechEvents count the number of events globally. The ConsecutiveSilencesSpeechEventActivity activity increments its count when a SilenceHistoryItem from any activity is assigned to the History property. It does not matter whether the first silence and second silence come from the same or different activities. Similarly, it resets its count when a recognition from any activity is detected. The same is true for other speech events.

Activating speech events
Now that we know how a speech event tracks what happens in the dialog, we can look at how the speech events are activated. The workflow decides whether to run a speech event when a QuestionAnswerActivity activity completes a turn. This is the only point where a speech event can be started. If the speech event is active because its count matches the maximum allowed number of events, the workflow suspends the QuestionAnswerActivity activity and runs the speech event. Once the speech event completes, the QuestionAnswerActivity activity restarts, unless it was cancelled. I’d like to emphasize the point: you cannot force a speech event to execute only by changing the History property of the workflow. Changing the History property will change the speech events counts, but it won’t force activation. Activation is decided by the workflow.

Bail-out logic
Let’s go back to the solution presented above. There is a caveat worth mentioning. SpeechEvents are often used to trigger a bail-out: if the user stays silent three times in a row, the dialog is transferred or terminated.

In our example above, the silence that is used to move to another part of the dialog will count towards any bail-out limit you may have. If you have a SpeechEvent that triggers after three silences, the user can only stay silent twice now. This is due to the global nature of the speech event count: recall that it does not matter where silence comes from.

In this case, one comes from the initial question answer activity and the next ones come from the following question answer activity. In order to reset the count, you need to assign a RecognitionHistoryItem to the History property of the workflow. This makes sense: the first silence that was detected is not really a silence but a valid way for the user to interact with the system. By setting the history, you let the speech events know that. Setting the History is easy:

Workflow.History = new RecognitionHistoryItem(QAThatTriggeredTheSilence, false /*no bargein*/);

does the job. Changing the History property in this way will ensure that your bail-out logic works as expected.

MenuActivity in MSS

mssblog — Thu, 05 Oct 2006 20:03:11 GMT

POSTED BY: AHMED STEWART, MSS Software Dev Engineer

Today, I’m going to talk about the MenuActivity of MSS 2007 Beta.

The Menu, like the name implies, allows easy selection of an item from a menu. Under the covers the activity creates a grammar consisting of the items supplied to it.

Menu, like the other high level activities, supports confirmation, but since I’ve already talked about in the post about the GetAndConfirm Activity, I won’t go over it again here.

Now, let’s get into using the MenuActivity:

The code below creates a string array that contains the options that the user can choose from. The Executing handler then assigns the array to the DataSource of the MenuActivity and Binds the data to the activity. The binding process just creates the required grammars from the options.

     private string[] _choicesList = new string[] { "one", "two", "three", "four", "five" };
     private void menuActivity1_Executing(object sender, ActivityExecutionStatusChangedEventArgs e)
     {
          menuActivity1.DataSource = _choicesList;
          menuActivity1.DataBind();
     }

Below is the TurnStarting handler which is pretty self explanatory.

     private void menuActivity1_TurnStarting(object sender, TurnStartingEventArgs e)
     {
          //The actual text of the prompt
          string optionText = "This is option {0}. ";

//Clear the prompt
menuActivity1.MainPrompt.ClearContent();

          //For each option, add a bookmark and a prompt for it.
          foreach (string option in _choicesList)
          {

menuActivity1.MainPrompt.AppendBookmark(option);

menuActivity1.MainPrompt.AppendText(String.Format(optionText, option));
}
}

The code above that constructs the prompt text inserts a bookmark before text that is associated with an option. When the default grammar recognizes “that one”, the last encountered bookmark is set as the selected option. For the curious, the constructed SSML looks like this:

<speak version="1.0" xmlns="http://www.w3.org/2001/10/synthesis" xml:lang="en-US">This is option one. This is option two. This is option three. This is option four. This is option five. </speak>

Custom grammars can also be used for the “that one” recognition by adding them to the Grammars collection of the activity. If you decide to go this route, you’re going to have to set the selected option yourself. The function below is a sample grammar recognized handle that calls the appropriate method:

void customTimedRecoGrammar_Recognized(object sender, RecognizedEventArgs e)
{

menuActivity1.SetSelectedOptionToMostRecentBookmark(sender, e);
}

After the activity completes execution, the selection is available via the SelectedOption property.

Did you say blue? No, red.

mssblog — Tue, 19 Sep 2006 03:10:00 GMT

POSTED BY: AHMED STEWART, MSS Software Dev Engineer

Today I’d like to talk about one of the new activities that we’ve created in MSS 2007 Beta to handle common tasks, the Get and Confirm activity. Like the name suggests, this activity simple gets an utterance from the user and based on the confidence of the recognition, confirms it with the user or not.

The GetAndConfirmActivity, G&C for short, allows the developer to specify a grammar and based on the confidence of the recognition confirm the recognition. If the confirmation is successful, the activity exits, otherwise the get turn is started again to get a new recognition.

The control has default confirmation grammars that can recognize, yes and no as well as accept an updated reply. E.g.:

App: Did you say blue?

Caller: No, Red.

App: Did you say red?

The example below will walk through a very simple usage of the Activity and shows how to add and use a custom Dtmf grammar during the confirmation phase of the recognition. I prefer to give examples and describe what they do so hopefully everything is nice and easy to understand.

I like to use the Executing handler to do things that are not going to change for the duration of the control’s execution so in the handler below I assign the grammar and prompt for the “get” turn to the control. The next section of code generates and assignes the Dtmf grammar for the confirmation phase as well as specifying a handler for the Grammar’s recognized event where the determination is made as to accept or deny the recognition if Dtmf is entered. By default, the confirmation threshold is set to one so the recognition is always confirmed, to alter it simply change the value. The confirmation threshold is the starting point where confirmation will not occur.

     private void getAndConfirmActivity1_Executing(object sender, ActivityExecutionStatusChangedEventArgs e)
     {
          string[] grammarChoices = new string[] { "one", "two", "three", "four", "five" };

getAndConfirmActivity1.Grammars.Add(GenerateGrammar(SrgsGrammarMode.Voice,grammarChoices));
getAndConfirmActivity1.MainPrompt.ClearContent();
getAndConfirmActivity1.MainPrompt.AppendText("Say a number between one and five now.");

string[] grammarOptions = new string[] { "1", "2" };
 Grammar confirmationDtmfGrammar = GenerateGrammar(SrgsGrammarMode.Dtmf, grammarOptions);
 confirmationDtmfGrammar.Recognized += new EventHandler<RecognizedEventArgs>(confirmationDtmfGrammar_Recognized);

getAndConfirmActivity1.ConfirmationDtmfGrammars.Add(confirmationDtmfGrammar);

}

The Confirmation Turn starting handler is pretty basic, it just specifies the prompt that will be played during the confirmation turn.

private void getAndConfirmActivity1_ConfirmationTurnStarting(object sender, TurnStartingEventArgs e)
{

getAndConfirmActivity1.ConfirmationMainPrompt.ClearContent();

getAndConfirmActivity1.ConfirmationMainPrompt.AppendText("The last recognition result was, " + getAndConfirmActivity1.RecognitionResult.Text +
", if this is correct say yes or press 1. If not say no or press 2.");

}

The last piece of the puzzle is the handler for the confirmationDtmfGrammar_Recognized. It simply checks the value of the recognized Dtmf digits and either accepts the recognition or denies it.

     void confirmationDtmfGrammar_Recognized(object sender, RecognizedEventArgs e)
     {
          if (1 == int.Parse(e.Result.Text))
          {
               getAndConfirmActivity1.Accept(sender, e);
          }
          else
          {
               getAndConfirmActivity1.Deny(sender, e);
          }
     }

In this example the default grammars provided with the control are still active. To disable them, just set the value of getAndConfirmActivity1.UseDefaultGrammars to false.

Since I know some of you are curious about what it contains here’s the GenerateGrammar function.

/// <summary>
 /// This function generates a grammar with the members of the provided string array as choices.
 /// </summary>
 /// <param name="grammarMode">The mode of the grammar, either Dtmf or voice.</param>
 /// <param name="grammarChoices">The string array containing the choices in the grammar.</param>
 /// <returns>The constructed grammar object.</returns>
 public static Grammar GenerateGrammar(SrgsGrammarMode grammarMode, string[] grammarChoices)
 {
 if (0 >= grammarChoices.Length)
 {
 throw new ArgumentNullException(grammarChoices.ToString());
 }

SrgsDocument grammarDoc = new SrgsDocument();
grammarDoc.Mode = grammarMode;

          //The name of the rule that will be created
          SrgsRule rule = new SrgsRule("GrammarOptions");
          rule.Scope = SrgsRuleScope.Public;
          SrgsItem item = new SrgsItem();
          SrgsOneOf choice = new SrgsOneOf(grammarChoices);
          item.Add(choice);
          rule.Add(item);
          grammarDoc.Rules.Add(rule);
          grammarDoc.Root = rule;
          return new Grammar(grammarDoc);
     }

Local Accounts and MSS 2007 Beta

mssblog — Fri, 08 Sep 2006 20:30:00 GMT

POSTED BY: MARK PARKER, MSS Programmer Writer

If you are developing a Microsoft Speech Server 2007 Beta voice response application that writes data to a disk file, you will need to grant write access to the file (or the directory that contains the file) to either the ASPNET local account or the NETWORK SERVICE local account. MSS 2007 Beta uses one of these accounts whenever it creates or writes to a file.

If you are running MSS 2007 Beta on Microsoft Windows XP, grant write access to the ASPNET local account. If you are running MSS 2007 Beta on Microsoft Windows Server 2003, grant write acces to the NETWORK SERVICE local account.

To grant write access to the ASPNET local account in Windows XP:

In Windows Explorer, navigate to the directory that contains the file(s) you want to write to.
On the right-click menu, select Sharing and Security.
On the property page for the directory, select the Security tab.
Click Add…
On the Select Users, Computers, or Groups page, enter MachineName\ASPNET in the textbox, and then click OK. (For MachineName, use the name of the machine as found in the My Computer properties.) On the property page for the directory, an entry for ASP.NET Machine Account (MachineName\ASPNET) now appears in the Group or user names: pane.
In the Allow column in the lower half of the property page, check the Write box, then click Apply, and then click OK.

To grant write access to the NETWORK SERVICE local account in Windows Server 2003:

Perform steps 1 through 4 in the previous procedure.
For step 5, enter NETWORK SERVICE in the textbox. You do not need to prefix this with the machine name.
Perform step 6 in the previous procedure.

It's all good

mssblog — Fri, 18 Aug 2006 03:52:00 GMT

POSTED BY: KEN CIRCEO, MSS Lead Tech Writer

Now that I'm over the initial jolt of learning that Speech Server will be integrated with Office Communications Server (nee LCS), I thought I'd take a minute to write down my reaction and how I expect the integration to impact my work. (I'm just talkin' here. It's therapeutic. Bear with me.)

I don't mind change. If I did, I wouldn't last long in this industry. Making software isn't like making aluminum. Things don't just stay the same year after year, decade after decade. So when someone above me decides to integrate my product with another product, I accept it. In fact, at my pedestrian level, accepting the change is critical; understanding the reason behind it is far less important.

After last week's announcement, one of our partners said that adding MSS to OCS will give his company "a more extensive set of capabilities on which to build compelling unified communications solutions for our customers." Wow. It's hard to read that without marvelling at the jargon. I wonder if that was off the top of his head.

One of our VPs (I forget which one) calls it tipping over the siloes. I don't doubt that, but I also don't get it. I'm going to need Tillman to explain to me exactly what "tipping over the siloes" means. Maybe it has something to do with merging the API sets, or at least letting them hook into each other. Whatever it is, Tillman will straighten it out. He has a good bird's eye view on the software industry. I bet he can instantly see how integrating MSS with OCS will affect our customers, their companies, and the MSFT stock price. Also, he's more left-brained than I am, which is why he's got a far better shot at becoming a VP than I do. But, trust me, I can live with that. Both Tillman and I know that I'm not the brightest guy in the world (see picture).

So as far as the whole integration goes. Hey, if it's ok with Microsoft, it's ok with me. I'm still running the video project, doing the whole Community Lead thing, and cranking out Help docs and whitepapers. And I'm sure in the weeks ahead, even the technical details will start making more sense to me.

Really. It's all good.

Introducing Office Communication Server with Speech Platform Services

mssblog — Tue, 08 Aug 2006 18:12:00 GMT

POSTED BY: KEN CIRCEO, MSS Lead Tech Writer

Today from the SpeechTEK 2006 conference in New York, Microsoft Corp. announced that the full capabilities of Microsoft(R) Speech Server 2007 will be integrated into Microsoft Office Communications Server 2007, extending the company's commitment to unified communications and breaking down today's silos of instant messaging, Internet Protocol telephony, voice response, audioconferencing and videoconferencing. More...

Read the GotSpeech guy's response

SpeechTEK 2006: Grab me a T-shirt while you're there

mssblog — Fri, 04 Aug 2006 02:58:00 GMT

POSTED BY: KEN CIRCEO, MSS Lead Tech Writer

The year's biggest speech conference, SpeechTEK 2006, will be held next week at the Marriott Marquis in NYC. I wanted to go, but Microsoft turned me down. Probably with good cause. I just wanted the free T-shirts. It doesn't matter. I'm already over it. (Really.)

SpeechTEK is now in its twelfth year. It started in Boston in 1995, then moved to the Big Apple the next year and it's been there ever since. If you're one of the lucky ones who gets to go this year, look for Microsoft in Booth 502. You can hardly miss it. It's one of the large booths that hits you just as you walk into the Expo Hall.

Also, here's a list of MSS sessions and speakers. If you haven't heard these speakers before, I know most of them pretty well. They're all good speakers. (If they weren't, I'd tell you.) Rich Bray is giving the keynote on Tuesday at 8:30AM. Have a great time. And don't worry about me. I'm fine. (But if you get an extra T-shirt, you can send it to me at One Microsoft Way, Redmond, WA 98052. No obligation or anything.)

Mon, Aug 7

VOX 2006-Service Provider Edition: Expanding Your Reach in Real-Time: SOA or SOL: Leveraging Web Infrastructure Panel Discussion

ALBERT KOOIMAN, Senior Business Development Manager

1:30PM–2:15PM in the Astor Ballroom

Tue, Aug 8

KEYNOTE: Unified Communications - The Next Wave of Speech Technology Applications

RICHARD BRAY, General Manager in Unified Communications

8:30AM–9:45AM in the Broadway Ballroom

Advanced Speech Technology Symposium (AVIOS): Advanced Speech and NL Technology Panel Discussion

ALEX ACERO, Research Area Manager

11:00AM–12:30PM in the Plymouth/Royale Room

VUI Track (Authoring & Tuning): Tuning the VUI, Not Tuning The Parameters Panel Discussion

STEPHEN POTTER, Program Manager

4:00PM–5:00PM in the Gramercy/Olmstead Room

Consumer Electronics & MM Track: Devices Panel Discussion

ALEX ACERO, Research Area Manager

4:00PM–5:00PM in the Uris/Shubert Room

Wed, Aug 9

Developing and Tuning Applications with MSS 2007

DAVID OLLASON, Lead Program Manager

STEPHEN POTTER, Program Manager

10:00AM–12:30PM in the Wintergarden/Palace Room

Improving Customer Loyalty: Building An Effective Self-Service Strategy Panel Discussion

ABHIJIT SARKAR, Senior Business Development Manager

11:00AM–12:00PM in the Music Box/Majestic Room

Consumer Electronics & MM Track: Overcoming Barriers to Multimodal Application Development Panel Discussion

ALBERT KOOIMAN, Senior Business Development Manager

2:00PM–3:30PM in the Uris/Shubert Room

Strategic & Management Insights Track: Mobilizing Your Workforce Panel Discussion

CLINT PATTERSON, Director of Product Management

2:00PM–3:30PM in the Soho/Herald Room

Are These Technologies Ready for Primetime Track: You Decide – Unifying Your Communications Panel Discussion

CLINT PATTERSON, Director of Product Management

3:45PM–5:00PM in the Chelsea/Gotham Room

SALT in Skagit (Part 3)

mssblog — Wed, 12 Jul 2006 22:31:00 GMT

POSTED BY: GUNNAR KUDRJAVETS, MSS Software Design Engineer

ALAN TURNQUIST, MSS Software Design Engineer

Here are some recent FAQs about SALT:

Q: How do I debug a SALT application running inside a Windows Workflow Foundation (WWF) application?

A: You can use the debugger statement (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/script56/html/c6d2e193-c1f7-4fb3-8a4e-cc9823174ae4.asp) in the JScript portion of your application to break into the debugger. After you press F10 in Visual Studio the debugger attaches itself to the relevant W3WP.EXE process. If a debugger statement is executed, your application will encounter a breakpoint and you would be able to step through the JScript inside your SALT application and do all the usual debugging.

Q: What’s the window.applicationData property introduced in MSS 2007 and how can I benefit from it?

A: The window.applicationData property will persist across the lifetime of the SALT application. This means that for example you can do the following things:

In your workflow application code in C# you can add data to the dictionary.

this.saltInterpreterActivity1.ApplicationData["foo"] = "bar";
this.saltInterpreterActivity1.ApplicationData["AnswerToEverything"] = 42;
this.saltInterpreterActivity1.ApplicationData["SomeObjectIWishToUseInSalt"] = new MyObject();

In SALT you can later use window.applicationData to access all this information from any individual SALT page.

In one SALT page you can add some information and it’ll be available to all the other pages in your application. For example you might set something in your start page and later the error page will be able to access this data.

After the SALT application terminates, your workflow application will be able to access the data stored by the SALT application. For example if you want to log something in the error page, you can add it to the dictionary and then use C# code to write the error into NT Event Log, log file, etc.

Q: How do I close a SALT application which is running part of WWF application without terminating the telephony session?

A: If a SALT application is running from within a workflow, there are two choices to exit the SALT application:

The SALT application sends the ClearConnection CSTA message which will cause us to call TelephonySession.Close() which will terminate the call.
The SALT application calls window.close(). In this case, we’ll close the application and do all the required cleanup, but won’t close the telephony session. After that you can continue with your application from the workflow.

MSS partners win Most Innovative Solutions Awards!

mssblog — Wed, 05 Jul 2006 23:27:00 GMT

POSTED BY: CLINT PATTERSON, Director of Product Marketing, Microsoft Speech Server

CONGRATULATIONS!

Landstar and ParkingCarma, two Microsoft Speech Server partners, have been named 2006 Most Innovative Solutions winners in this year's Speech Technology Magazine competition.

Landstar System, Inc., a transportation service company, created a Speech Server solution that enables truck drivers to receive voice notification of suitable loads over their cell phones.

ParkingCarma is the creator of SmartParking technology, a Speech Server solution that lets drivers determine the availability of parking spaces from their cars, homes, or offices.

BUT WAIT...THERE'S MORE!

VOTE NOW for Microsoft Speech Server 2007!

Speech Server 2007 is a candidate for Best New Product in 2007. You can vote by visiting http://www.speechtechmag.com/SSAVote before July 10. Speech Server partners Persay and Cantata are also up for awards in the categories of Best Speaker Verification and Best Tool respectively.

VIDEO: What's Microsoft Speech Server (Beta)?

mssblog — Wed, 28 Jun 2006 18:31:00 GMT

POSTED BY: MITHUN DHAR, MSS Technical Product Manager

What's Microsoft Speech Server (Beta)?
Microsoft Speech Server 2007 (Beta) is Microsoft's state-of-the-art Interactive Voice Response (IVR) platform that allows developers to build, deploy, and maintain Voice Response applications using Touch Tone or speech recognition and synthesis.

That's the marketing pitch. In this Channel 9 video, Mithun Dhar, Albert Kooiman, and David Ollason explain what that actually means.

Click the graphic below to go to the video page.

Speech Server Q&A with Rich Bray

mssblog — Tue, 27 Jun 2006 19:17:00 GMT

POSTED BY: CLINT PATTERSON, Director of Product Marketing, Microsoft Speech Server

SAN FRANCISCO — To learn more about how enterprises are using Speech Server today and the role of speech-based technology in the overall unified communications vision and strategy, PressPass spoke with Rich Bray, general manager, Microsoft Speech Server.

Q&A: Microsoft Speech Server’s Growing Adoption in the Enterprise

ALL NEW Speech Newsgroups!

mssblog — Fri, 23 Jun 2006 00:24:00 GMT

POSTED BY: KEN CIRCEO, Lead Tech Writer

As the Speech Community continues to grow, so does the need for better channels of communication. To that end, we've created three new public newsgroups to handle different areas of speech:

   Speech Server
   microsoft.public.speech.server
   Description: General issues about Microsoft Speech Server (MSS), a
development and deployment platform for voice recognition applications.

   Speech Desktop
   microsoft.public.speech.desktop
   Description: General public newsgroup for Microsoft speech and natural
   language technologies that run on the desktop.

   Speech Mobile & Embedded
   microsoft.public.speech.mobile
   Description: General issues about Microsoft speech technologies and
   applications such as VoiceCommand that run on the Windows Mobile
   and Windows CE powered devices.

Feel free to check them out when you have the chance.

New to Newsgroups?
Traditionally, “newsgroup” refers to a discussion that is fed to USENET and accessed with a newsgroup reader such as Outlook Express. USENET is a global collection of servers that exchange articles in a hierarchical set of newsgroups. Conversations between these servers use Network News Transfer Protocol (NNTP). Most people access USENET through their Internet Service Provider (ISP). Like all Microsoft Public Newsgroups, the new Speech newsgroups are a part of the USENET hierarchy.

How do you access Microsoft Newsgroups?
There are two ways (that I know of) to access any Microsoft newsgroup: through Outlook Express and through the microsoft.com Web interface.

In Outlook Express, click Tools > Newsgroups. Select the newsgroups you want to subscribe to, and then click Subscribe.

On the Web, go to http://www.microsoft.com/communities/newsgroups/en-us/default.aspx, and locate the newsgroups in the tree:

English > Servers > Server Applications > Speech Server > Speech Server
English > Office and Desktop Applications > Speech Desktop > Speech Desktop
English > Mobile and Embedded > Speech

Creating a new API (Part 2 of 2)

mssblog — Thu, 15 Jun 2006 22:41:00 GMT

POSTED BY: RENAUD LECOEUCHE, MSS Software Dev Engineer

In this post, I’d like to go through two other sources of information and constraints when designing a new API:

· Existing API (internal and external)

· Usability

In Creating a new API (Part 1 of 2) posted on May 30th, I discussed making the API do what is needed. This post is about making it easy for you to use the API.

Existing API
The first way to make it easier to use an API is to make it more familiar. Most of you are already familiar with other .NET technologies such as ASP.NET. Therefore, before we add a feature in the API, we always look at these technologies and consider whether we can re-use them. The most obvious example is Windows Workflow Foundation (WWF). Rather than inventing our own dialog designer we decided to leverage the WWF team’s work. This enables you to learn how to design dialogs more quickly and makes sure that your investment in learning this technology can be used across several Microsoft products.

There are many smaller examples. In a previous post, Alan and Gunnar mentioned the AsyncCompletedEventArgs base class and the need to call RaiseExceptionIfNecessary if you derive a class from it. The purpose of this is to get a consistent behavior with other APIs in the .NET framework. All EventArgs that provide asynchronous results do so. If you are interested in the topic, I recommend reading Framework Design Guidelines by Krzysztof Cwalina and Brad Abrams. The book provides guidance on creating new classes in a manner consistent with existing .NET classes.

Usability
API usability is a vast topic. Here are some examples of what we consider:

· How much code are authors required to write? Common scenarios should require few lines of code. When we started designing the dialog API we actually wrote several applications in SALT and in managed code to make sure that the dialog API compared favorably with RunSpeech.

· How discoverable is the API? Can authors find all the features? We think about this topic a lot, especially since we have two ways of writing dialogs: via the designer and in code. Some features are still somewhat difficult to find. For example, each workflow has a History property that lets you know what happened last in the workflow execution, but many people don’t discover it without help. Your feedback can help us identify these features and make them more prominent.

· Does the API force authors to make choices that are difficult to change? For example, how difficult is it to change Statement into QuestionAnswer? This is helped by consistency in the API. For example changing a statement to a question answer requires changing the type and adding a grammar. The other properties have the same names and do not need to be updated.

I hope these posts gave you some idea of the work we do behind the scenes to deliver an API. As always, feel free to comment on the blog or via the Connect website.

Using the right WinFX version when installing MSS 2007 Beta

mssblog — Tue, 13 Jun 2006 02:14:00 GMT

POSTED BY: FEI CHUA, MSS Setup PM

We have seen a few email threads on the MSS Beta mailing list about installing the WinFX Prerequisite (Workflow Foundation RC0 Build). Some users had a version of WinFX from previous Microsoft Beta programs they participated in, some tried to download the latest WinFX components from download.microsoft.com. The issue is that those were NOT the right versions of WinFX for MSS Beta 2007.

For MSS 2007 Beta, you will need the WinFX component from the Connect site. It is a special version created just for MSS 2007 Beta. For your convenience, here are the steps for downloading the WinFX components.

WinFX version quick check

Go to Control Panel > Add Remove Programs. If you have the right version of WinFX, you should see the following Window Workflow Foundation item:

NOT THIS:

Downloading and installing the WinFX prerequisites

Uninstall all previous versions of WinFX you have downloaded elsewhere. If you have an older machine with previous Beta versions of Visual Studio or WinFX installed, your machine might not be clean. We strongly suggest that you start from a clean OS installation.
Go to the Connect site and click on "My Participation" to sign in. Select the "Speech Server 2007 Beta Program" and then click on the "Downloads" link.
Search for "workflow" and you will see the following item for download.
Click on "Workflow Foundation RC0 Build" and you'll see the following download page.
Click on "Download."
Install the WinFX components you have just downloaded.

Again, this is the ONLY WAY to get the correct version of the WinFX components needed to run MSS 2007 Beta.

By the time we ship the final MSS 2007 product, we’ll have better synchronization of the version of WinFX shipped. For now, please be sure to download your WinFX components from the Connect site as prescribed.

Sorry about the confusion.

Thank you.

Handling event arguments in MSS managed API

mssblog — Mon, 05 Jun 2006 18:46:00 GMT

POSTED BY: GUNNAR KUDRJAVETS, MSS Software Design Engineer
ALAN TURNQUIST, MSS Software Design Engineer

As most of the code I’ve written during last 1.5 years has been using our managed API, I’ve been starting to notice some general patterns which introduce defects. One of the common coding mistakes I’ve personally made multiple times while using our managed API was handling arguments from the various delegates incorrectly. The following applies to different types of arguments which inherit from AsyncCompletedEventArgs: RecognizeCompletedEventArgs, RecordCompletedEventArgs, SpeakCompletedEventArgs, etc. Let’s look at the typical example. Somewhere in your code you’ll subscribe to the event handler for RecognizeCompleted:

…
someObject.TelephonySession.SpeechRecognizer.RecognizeCompleted += OnRecognizeCompleted;
…

The usual event handler will look something like this:

The important thing to take into account is the fact that if the asynchronous operation was cancelled, i.e., args.Canceled is true, then accessing any other property except args.Error will throw InvalidOperationException. Asynchronous operation could have been cancelled because you explicitly requested it, e.g. by calling RecognizeAsyncStop(), or because some error occurred while performing the specific operation. Please note that this doesn’t mean that args.Error will always be non-null. It may or it may not.

After checking args.Canceled you’ll also need to check for args.Error. In case args.Error != null then accessing any properties except Canceled will throw Exception object describing the error that happened previously.

I typically made mistakes by trying to log (for debugging purposes) the various properties of RecognizeCompletedEventArgs object without checking the state of the object first, or by trying to access properties like Result without checking the state of the args. You will also need to be careful when trying to access properties like RecordingSize which will throw if audio wasn’t retained during speech recognition.

The obvious question to ask is: why does the API behave this way? Why can’t these properties just return null or 0 in case there’s no value to return? Our decision to implement these properties this way (throw in case of unexpected access) was based on the consistency with other .NET classes. Here’s the official documentation for RaiseExceptionIfNecessary from MSDN:

Notes to Inheritors
If you have derived your own class from the AsyncCompletedEventArgs class, your read-only properties should call the RaiseExceptionIfNecessary method before returning the property value. If the component's asynchronous worker code assigns an exception to the Error property or sets the Cancelled property to true, the property will raise an exception if a client tries to read its value. This prevents clients from accessing properties that are potentially not valid due to a failure in the asynchronous operation.

As a summary:

1) When handling different properties of the event arguments classes, always handle the cases with args.Canceled == true and args.Error != null first and then proceed to the normal code path. It might even be a good preventive measure to assert those invariants before your code handles the successful case.

2) Look carefully at all the properties for different event arguments classes to understand under what conditions they are accessible. Believe me, those extra minutes are worth your time and will prevent you from introducing bugs which will later take hours to fix ;-)

Here’s the code pattern you may wish to use:

private void OnRecognizeCompleted(object sender, RecognizeCompletedEventArgs args)
{
     Debug.Assert(null != sender, "null != sender");
     Debug.Assert(null != args, "null != args");

     if (args.Canceled)
     {
           ...
           // Operation was cancelled.
     }
     else if (null != args.Error)
     {
           ...
           // Something went wrong during the operation.
     }
     else
     {
           Debug.Assert(!args.Canceled, "!args.Canceled");
           Debug.Assert(null == args.Error, "null == args.Error");

           ...
           // Speech recognizer returned some kind of result.
     }

     ...
}

Webcasts Galore!

mssblog — Fri, 02 Jun 2006 18:51:00 GMT

POSTED BY: KEN CIRCEO, Lead Tech Writer

Just a head's up. Next week, we'll have three days of Speech Server webcasts available for you. Registration is free. Just go to Microsoft Contact Center Solutions Series to sign up.

Tue, Jun 6
9 AM - Trever Renquist, VP of Sales, Gold Systems
     "Speech Recognition Solutions – the Benefits & Best Practices"
11 AM - Mike Hentges, CTO, Digital DataVoice
     "Improving Agent Productivity with Speech and CTI"
1 PM - Mike Mastro, President, The Primas Group
     "Differentiating Your Contact Center by Providing a Qualified Customer Experience"

Wed, Jun 7
9 AM - Terry Gold, Founder, CTO & President, Gold Systems
     "Integrating Web and Telephony Self-Service for Maximum Results"
11 AM - B. Chandra Mouli, VP of Software Engineering, Versay Solutions
     "Delivering an Integrated Contact Center Solution with CTI"
1 PM - Ming Chao, Sr. Partner Manager, Customer Care Framework
     "Increase Contact Center Efficiency by Delivering Better Information Faster"

Thu, Jun 8
9 AM - Joe Carey, President, Versay Solutions
     "Strengthen Branding and Improve Customer Experience with Next Generation Speech and IP Telephony"
11 AM - Larry Rushing, Director of Vertical Solutions, Acclaim Telecom Services
     "Improving TCO While Reducing Operations & Maintenance Costs"
1 PM - Joe Parish, Director of Sales, Microsoft Speech Server, and Susan Schutte, Sr. Product Manager, Customer Care Framework
     "Introduction to Microsoft Contact Center Technologies"

Creating a new API (Part 1 of 2)

mssblog — Wed, 31 May 2006 01:19:00 GMT

POSTED BY: RENAUD LECOEUCHE, MSS Software Dev Engineer

We have been busy introducing new Application Programming Interfaces (API) in Microsoft Speech Server. I’d like to describe the process that goes into creating a new API. I can only skim the surface. Creating an API is a lengthy and complex issue. Still, I believe this will give you some insight about our work, and how you influence it.

I’ll focus on the Dialog Workflow API. This is the API I am most involved with, both from a historical point of view (having worked on it since Microsoft Speech Server 2004) and from a development point of view.

Some of the main sources of information when creating an API are the following:

User feedback and requests
Existing API (internal and external)
Usability

In this post, I'll discuss the first one.

User feedback and requests

By far the most valuable source of information is your feedback. Let me take an example: many users commented that Microsoft Speech Server 2004 was great but that RunSpeech (the algorithm that decides the execution order of the speech controls on the page) was sometimes a problem. If you don’t do form filling RunSpeech can get in the way. I believe that the problem was not with RunSpeech per se but with the fact that it was the only way to benefit from other classes in the API such QuestionAnswer. In Microsoft Speech Server 2007, we decided to make the API more modular. Specifically, turn management (starting the synthesizer and recognizers at the right time) is handled by one set of classes: Statement and QuestionAnswer among others. Dialog flow management is handled in another layer: by workflow activities such as IfElse or with FormFillingDialog. The big improvement is that you are free to use FormFillingDialog only when it makes sense in your application. If you don’t like it, you still get the full benefit of the turn management classes. Similarly, on the storage front, using SemanticItem objects is optional if you are not in a FormFillingDialog. The feedback we got led us to an improved design.

Feedback is not only important for high level design; it is also valuable for smaller aspects of the API. There are too many examples to cite them all, so let me just give one: many of you needed to be able to change the calling party on an outbound call. We added that capability in the MakeCall activity.

I encourage you to file suggestions on the Connect web site so we can continue to improve the API. Can we add all your suggestions into the API? No, because there are other constraints that limit what we can do. But many suggestions will shape the product.

In my next post, I will speak about existing API and usability.

Lights...Camera...Demo!

mssblog — Wed, 24 May 2006 02:17:00 GMT

POSTED BY: KEN CIRCEO, MSS Lead Tech Writer

Last fall, a co-writer mentioned that we ought to do some video demos for the next version of Speech Server.

"It could really help users learn how to use our tools. You know, like the Speech Log Analyzer. It took me awhile just to figure out what I was doing with that thing, and I even had a head start. With a video, we could just show it."

"Not bad, John," I said. "But we've got no time. There's just too much on our plates right now."

That wasn't true, of course. But any writer whose worth his weight in white out knows that you have to keep a healthy buffer in your schedule to absorb unexpected time-consumers such as feature creep, extra beta releases, and ungrateful self-absorbed tech writers who decide to leave the company in the middle of the production cycle even though they promised they'd be around — and I'm quoting now — "at least until RTM." (Sorry, do I sound bitter?)

Still, I told John it was an interesting idea and that we should think about it, which is Microsoft-talk for "this is never going to happen."

I'm glad to report that I was dead wrong.

Soon afterward, my manager Bob asked me if we'd done anything with the video idea. I went immediately into Costanza mode: "Well, I don't have anything to show you at the moment, but we're kicking around some ideas and I think we'll be storyboarding it very soon."

"Good," he said. "Keep me posted."

So just like that, I was on the video project. I pulled in a few people and we brainstormed for a week or so about the usual video stuff. There was no shortage of questions.

What should we shoot and how long should it be?
Should we use an actor or a real person?
Should we produce them ourselves or pay Microsoft Studios to do it?
Talking head or screen shots? Or both?
Is the customer going to download it or stream it?
Hasn't Office done something like this already? What's their story?
Who's going to bring the donuts?

This was a new world to most of us, certainly to me. The most videotaping I'd ever done was on a soccer field, and those didn't come out too good. No. That's charitable. They were really, really bad.

But I took ownership of the project and slowly started to believe that it had real value. I found a good screen-movement-capture program, bought a new video camera (w/built in hard disk...SWEET!), and — just about a month ago — John and I shot a prototype of him demonstrating the ins and outs of the Speech Log Analyzer. All in all, it went pretty well, except that we had over 30 minutes of footage — way too much.

So I spent a few days editing out screw-ups and unnecessary pauses. This brought it down to 15 minutes which I thought was still too long, but ok for a prototype. I showed it to Bob and the rest of the team. Nothing but positive comments, so it looks like a Go.

For starters, John and I will have to re-do the Speech Log Analyzer video. The name has been changed to Analytics & Tuning Studio, and we should really use better examples than we used in the prototype. Also, I'd like to try to get it down to 10 minutes, which is about as long as anyone should have to sit through an on-screen technical demo.

But danged if I didn't get the biggest kick out of putting it all together! On the strength of the proof-of-concept, our team compiled a list of more than 20 demo topics. Not sure how many we'll be able to knock out before RTM — probably just a few — but we'll give it our best shot.

SALT in Skagit (Part 2)

mssblog — Thu, 18 May 2006 02:18:00 GMT

POSTED BY: GUNNAR KUDRJAVETS, MSS Software Design Engineer

ALAN TURNQUIST, MSS Software Design Engineer

Migrating your SALT applications to MSS 2007

If you’re starting to use the Beta version of MSS 2007 then there are three different ways to deal with your existing SALT applications:

The simplest approach is to leave your SALT application as it is. Don’t change anything; don’t port your application to ASP.NET 2.0; just leave it be. You’ll need to make sure that your application is running inside an application pool which is running ASP.NET v1.*. To verify this you can use IIS Manager and after selecting “Properties” for your application check the “ASP.NET” tab. Also please note that it’s not possible to run different versions of ASP.NET in the same IIS process. We’ve done extensive performance and stress testing using this scenario as we expect that this will be the common migration path for MSS 2004 applications which won’t undergo any further development.
Migrate your application from ASP.NET 1.* to ASP.NET 2.0. This includes converting your Visual Studio solution, updating references to the Speech Controls version number, making any changes necessary (look at ASP.NET upgrade guide), recompiling, and redeploying your application.
Wrap your application into managed code. MSS 2007 provides a new managed API for developing speech applications and an even higher abstraction level to write speech applications using Workflow Designer. The API exposes SaltInterpreterActivity class which is designed to be a managed wrapper around the SALT applications. This option is beneficial if you want to reuse some components of your existing SALT applications in your existing managed applications. For example: you may have a significant portion of call flow written in SALT and for various reasons you don’t see any point in rewriting this using managed API.

This is just a short overview of the available options. The MSS 2007 Beta release includes a document called “Migrating Applications to MSS 2007” which describes all of these options and combinations between them in greater detail. Any feedback about this document is welcome and will be extremely helpful in making everyone’s experience while migrating SALT applications as smooth as possible.

Using the SaltInterpreterActivity class

A SaltInterpreterActivity is used to execute markup applications written in SALT. The usage pattern is to create the workflow that contains this class, set the start page and application data, if any, and then use SaltInterpreterActivity the same way as any other speech activity. There are two main purposes for using SaltInterpreterActivity class: using it as a managed wrapper for an existing SALT application and integrating existing SALT applications with the new managed speech and telephony applications.

Using SaltInterpreterActivity to wrap an existing SALT application is relatively trivial. In Visual Studio:

Create a new speech workflow application. Choose “File | New | Project | Speech | Speech Workflow Application”.
Fill in the necessary information and click “OK”.
Check or uncheck the options you need and click “OK”.
Make sure that Toolbox is visible by selecting “View | Toolbox”.
Select the “answerCallActivity1” workflow element and delete it. Do the same for the “disconnectCallActivity1” element.
Drag a “SaltInterpreter” element from the Toolbox to the canvas.
Click on “saltInterpreterActivity1” and specify the “StartPage” property to point to the URI of your existing SALT application.

Deleting the telephony activities generated by default was necessary to ensure that the TelephonySession.State will be TelephonySessionState.Incoming when SALT application is started up. In MSS 2004 the SALT application development model required that an application itself handle the telephony related operations (accept, decline, disconnect etc.) In the Beta version of MSS 2007 the default speech workflow application will accept the call by default, which is incompatible with the design of the existing SALT applications.

In case you want to integrate your existing SALT application into your new managed application (which already has accepted the call), some changes to the SALT application are required. The state of the TelephonySession won’t be TelephonySessionState.Incoming and therefore you need to change the part of your SALT application which in MSS 2004 was responsible for communicating with the TIM via CSTA messages. In MSS 2007 those messages are handled by MSS. Here is a typical CSTA message sequence (for the inbound case) between the SALT application and the TIM:

MonitorStart from SALT application; TIM responds with MonitorStartResponse.
SetAgentState from SALT application; TIM responds with SetAgentStateResponse.
DelieveredEvent from TIM, notifying the SALT application that an incoming call has arrived.
AnswerCall from SALT application; TIM responds with either CSTAErrorCode or EstablishedEvent.

After sending those messages and receiving the corresponding successful responses back from the TIM/MSS the call is considered to be answered/accepted/established and the application is ready to begin automated dialog interaction.

If you are integrating your existing SALT application into managed application then TelephonySession.State will be TelephonySessionState.Connected and you do not need to send all of those messages anymore. Your application can start the execution as if it received the EstablishedEvent which would be the indication that the call was established successfully in the common case.

Next time: Minor changes we’ve made to SALT, a list of common problems you may encounter while porting your SALT applications over. I planned to publish this information with the current entry, but I would rather take some time and double-check the facts once more. It’s time-consuming to be paranoid ;-)

Planning for Tuning and Reporting (Part 1)

mssblog — Wed, 10 May 2006 01:29:00 GMT

POSTED BY: PETER OKONSKI, MSS Test Lead

There are many different articles and white papers that address basic capacity planning for Microsoft Speech Server. One example is the MSS planning white paper: Estimating Capacity for Speech-enabled Interactive Voice Response Solutions. However, if you plan to use the reporting and tuning capabilities provided in MSS 2007, you need to plan for additional servers and related storage.

Call Workload Definitions

How do you plan? Start by gathering call workload definitions such as number of calls per hour, average call duration in seconds, and percentage of time the line can be busy.

Application Type

Categorize your application into one of the following MSS 2007 application types: Simple (e.g. DTMF, digits); Average (e.g. date, spelling, menu); or Complex (e.g. 50,000 name recognition, stock trade).

Language(s)

In addition, when you consider that different languages generate different log file sizes, the language(s) your application supports can affect your capacity needs, particularly if you plan to store those log files for a long period of time.

Worksheet

The following table contains the MSS customer application details that you should consider when enabling reporting and tuning in MSS 2007:

Description	Example	Customer Value
Number of calls per hr – peak	5,000 calls/hr
Number of calls per hr – off peak	100 calls/hr
Time of main calls load per day	10 hrs/day
Average call duration (e.g. 100 sec)	100 sec
Percent line can be busy	1%
Load characteristic Flat distribution over a day Bell curve Peak type of daily distribution Weekdays main load Weekends load Every day the same	2 4-
Language(s) of the application	US-en
Application type: Simple (such as DTMF, digits) Average (such as date, spelling, menu) Complex (such as a 50,000 name recognition, stock trade)	1
Other details on workload and customer behavior Number of grammars Grammar size Prompt database size	1 = 1 2 = 15,000 3 = 50,000

In addition, if you plan to use the following servers in your deployment, you should figure that into your capacity planning calculations as well.

MSS Server
TIS Server (optional)
Web Server (optional)
SQL Server for reporting and tuning (optional)
Data Warehouse (optional)

The Microsoft Speech Server may generate files on each MSS server, Web server, and TIS server, if applicable. Because of the significant impact of the storage needed for the ETL files or any of the MSS databases, it is critical to enter time for collecting data in the file or database format.

Data collection needs can be gathered by using the following table. For definitions on these terms, refer to MSS 2007 Beta Help.

Type of Machine	Description	Default value (1)	Customer data
MSS Server	Days to store of the ETL files for tuning	7
	Days to store of the ETL files for reporting	7
	Days to store of the ETL files for auditing	0
	Compression type	Non
	Recognition audio % of calls	10
	Include Prompt audio	No
	All audio for % of calls	0
SQL Server Tuning	Days to store of the ETL files	7
	Compression type for files drive (2)	Windows
	Days to store of data in the tuning database	30
	Percent of calls to collect the recognition audio	100
	Include prompt audio	Yes
SQL Server Reporting	Days to store of the ETL files	7
	Compression type for the files storage drive (2)	Windows
	Days to store of data in the database	180
SQL Server Auditing	Days to store of the ETL files	0
	Days to store of data in the database	0
	Recognition audio % of calls	0
	Include Prompt audio	No
	All audio for % of calls	0
SQL Server General	RAID type on the file storage drive	1
	RAID type on the SQL Server data drive	5
	RAID type on the SQL Server transaction log drive	5
Data Warehouse Reporting	Days to store of the ETL files	0 (no intention to store files on this machine)
	Days to store of data in the database using 5X max number of calls stored in SQL Server reporting	720
	RAID type on the SQL Server data drive	5
	RAID type on the SQL Server transaction log drive
Workstation	Data to collect on the development workstation	7 days

Notes

The default values are not the maximum supported number of days by the Microsoft Speech Server 2007.
You can use only one type of compression (e.g. Windows compression, ZIP, or Non) for the repository of the ETL files.

In my next posting, I’ll provide examples how to use this data and how to collect the runtime to predict the growth of Microsoft Speech Server systems.

SALT in Skagit (Part 1)

mssblog — Wed, 03 May 2006 01:21:00 GMT

POSTED BY: GUNNAR KUDRJAVETS, MSS Software Design Engineer

Welcome to the world of software backwards compatibility! When we started working on a Microsoft Speech Server (MSS) 2007 (code name “Skagit”) our goal from day one was to ensure that SALT applications developed for previous versions, MSS 2004 and MSS 2004 R2 (code names “Kokanee” and “Lynnwood”), will work with a minimum number of changes required or no changes at all.

There have been some interesting technical challenges to make all this happen. Internally we re-architected our product, removed some dependencies and acquired some new ones, changed a number of internal interfaces, introduced new programming models etc. The usual stuff software developers like to do ;-)

In cases like this there are usually two basic ways to approach the problem of making applications developed for the previous version of a product to work on a new version:

Start re-architecting and rewriting everything; there’s long period of time when nothing will work, and then you gradually start making things function again.
Go from working solution to working solution or in agile software development terms –continuously refactor (http://www.refactoring.com/) your code. Every step of the way you’ll know where you are and you’ll notice immediately if you’ve broken any features or fixed some bugs.

Well, as none of us in MSS Runtime development team are much into gambling with the product’s quality, we chose the second approach. During previous versions of MSS our test team has developed thousands of test cases which exercise different aspects of the SALT standard (http://www.saltforum.org/) and different speech controls (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sasdk_salt/html/ST_Programmers_Reference.asp). For performance and stress purposes we have also developed internally a number of complex speech applications utilizing SALT and speech controls.

Therefore from the software engineering point of view the problem becomes making sure that all the applications and test cases which worked at the end of the previous MSS release will work exactly the same way during the upcoming release, no new bugs are introduced, and performance and stress capabilities are the same or better than the previous release. Looking back at the last 1.5 years I would have to admit that it’s been quite a challenge, but as a developer I had kilotons and kilotons of fun doing it. All the cool refactoring techniques I always wanted to try, all the unit testing you may ever wish for, and of course the mock objects ;-) In addition to all that, there’s also the necessity of having to be intimately familiar with code from all the versions of MSS. Like a kid in a candy shop ;-)

Next time: Minor changes we’ve made to SALT, a list of common problems you may encounter while porting your SALT applications over, and an introduction to the new SaltInterpreterActivity class which blends SALT applications into our workflow-based approach for MSS 2007.

A whole new meaning to "Hello World!"

mssblog — Thu, 27 Apr 2006 19:16:00 GMT

POSTED BY: WALTER ISIDRO, MSS Developer

One of the first languages I learned as a programmer was C, and in learning that language, I encountered a string that became all too familiar to the programming community.

“Hello World!”

So common, that I’d see it everywhere when I started to learn other languages. And every time, I’d think, “Of course, what else could it possibly be?!” No introductory book in their right mind would ever think of using anything else, lest they break the old time-honored tradition, where NOT to do so is just taboo!

I’d become so familiar with it, I’d feel my eyes glaze over just seeing this piece of text, trying to ignore it – staring back at me so old and tiresome. I’d begrudgingly type it into my first sample program in whatever new computer language. Sometimes changing it to something different like, “Hello There.” or “Hello Cruel World!” Or if I was in a hurry a shorter “foo”, maybe just something my hand could spit out quickly like “asdfasdf.”

Until one day, I opened up the Speech SDK and there was a sample application I compiled, built and ran. Out of my computer she spoke.

“Hello World!”

Her voice so soft, calming and beautiful. She TALKED to me!

Almost singing her praises to my amateur speech application coding accomplishment! (It was so easy; all I did was comment out half a dozen lines!)

A new life breathed into an old weary phrase, announcing itself in this new world of speech applications development. I welcomed hearing the phase, playing it over again, listening in wonder. And, as anyone else would do, I changed the text to something more interesting.

“Hello, Walter!”

I laughed, thinking of the different possibilities that which a computer might address its owner (or a customer).

“What a nice voice she has” I thought to myself, now completely distracted from coding.

“I wonder what she looks like?”

Behind the Buzz

mssblog — Wed, 26 Apr 2006 00:11:00 GMT

POSTED BY: STEPHEN POTTER, MSS PM

Look, the buzz on Speech Server 2007 continues:

Rich Bray talks about the background in a Q&A with Speech Technology Magazine
Joe Calev discusses new tools and programming APIs
Richard Sprague finds a summary of analysts' reactions
the folks at gotspeech.net are all over the new features
Stephen Potter outlines the tuning and analytics tools

That last one, that's the best (disclaimer: I'm Stephen Potter and may not be fully impartial). But tuning and analytics as a topic always comes last on the agenda. So at our upcoming partner event I've got pretty much the last presentation slot on the last day. But tuning and reporting happens last in the cycle, right, so that's OK, isn't it?

Nope! Hell, nope! I'm not going to go so far as to say tuning should be first, but I am going to say that anyone who puts off analytical considerations any longer than day one is going to need to rewrite their app. Before you even sit down to design it, figuring out the goals of your application and how you will measure them will save you untold pain. For example: what are the tasks and subtasks of the application for which you want measure user success or failure? That needs business input because it typically reflects the return on investment of the system, and your manager will put you out of a job if you can't show how much money you are saving them with your fancy persona and slick dialog flow. (It's like web sites - the best ones are easy to use not because they have cool animations but because they are designed on the basis of common or personalized user interactions.) The same applies to spoken dialog - it's all about the data. With the tools in Speech Server 2007, we're trying make it easier to close the loop in the development cycle between design and tuning, with automated and simplified instrumentation in our design tools, and of course with the rich set of data analysis tools that I blogged about earlier and will blog ceaselessly about until Clint stops me.

And the buzz around the new release is partly blog-driven, which is great. One thing I like about communication in blogdom is not only the personal touch of bloggers, but also the dialogues with readers that can result. As a blogger on MSDN, I've learned a lot from the comments to my posts (both direct and offline) and I think I'm more in touch with customers and the industry as a result. And this model works both ways: blog readers (you, yes, you there, pay attention) have an opportunity to talk directly to the engineers and managers of products that affect you. Let me say now that every Speech Server blogger that I know takes great interest in the comments and feedback on their posts, and I encourage anyone out there with an interest to go ahead and make a feature request, ask a question, or just vent... What cool app have you deployed on Speech Server? What do you want to see in future versions? Are you having any technical issues? What do you like? What do you hate? What kind of topics do you want to see on this blog? Let us know. You Talkin' to Me really is all about you talkin'.

Finally, I can't leave 'the buzz' without an aside. It reminds me of a bug we recently found in the runtime where our audio recording beep was sounding more like an unwelcome bodily function. "Extremely unpleasant", as the tester who wrote the bug tactfully put it. Funny thing is, we can't fully fix it before Beta due to an upstream dependency. (Don't ask. And there is a workaround.) So sign up for the Beta now, and get a load of our beep!

You Mean the Docs Aren't "The Thing"?

mssblog — Mon, 17 Apr 2006 19:25:00 GMT

POSTED BY: KEN CIRCEO, MSS Lead Tech Writer

Ok, I'll admit it. As a tech writer, I sometimes forget that the docs play a supporting role in the overall product, and are probably not the main reason someone buys Microsoft Speech Server.

In my mind, I know this. But when you focus on documentation every day of the year like I do, you tend to think that the doc is the thing, and that the computer program itself is somewhat incidental.

Boss: "How's the new Speech Server release?"

Dev: "The product is fine, I guess. But the docs are fantastic! You've got to read this Prerequisites topic. I couldn't put it down!"

One thing I've appreciated about working for Microsoft is the freedom they give us to innovate. (I know from experience that this is not true with all software companies.) Here we can use audio, video, graphics, animation, Web stuff, pretty much anything we can think of that will get our point across.

So for MSS 2007, that's what we're doing. Not only will the docs be web-based (and therefore always updatable), we're working on some video demos, some LiveMeeting stuff, end-to-end solutions, as well as new samples and walkthroughs.

This is exciting stuff!

Ok, so it's not exciting. It's tech writing. But these days, tech writing is an umbrella that covers a lot more than just putting words down on paper. And if we can produce something — in whatever form — that helps you get more out of Speech Server, then we've done our job.

So keep checking here and on the website for new doc stuff. And feel free to let us know what you're looking for in terms of doc support. For even if the docs are not the thing, they're still what some of us work on day-in and day-out. And any feedback you can give us will help make them better.