Category: Windows Live
As promised, the public betas of the latest version of the Windows Live suite of PC applications are now available for download. Go to http://download.live.com/ and get the newest Messenger, Mail,Photo Gallery, Movie Maker, Writer, Toolbar, and Family Safety.
in Windows Live Wire
So far I’ve only tested Windows Live Messenger, generally I like the new look. I love the "Favorites List" feature, since I already had a favorites group in previous versions of Windows Live Messenger. Another feature that may become useful: creating groups of users as a single contact. This way in a single click you can begin a conversation with multiple contacts, almost like a mailing list or a chat room channel.
Something I would like to change is the size of the avatars in the conversation window. It is pretty cool that now you can get a minimalistic conversation window if you hide the toolbar in the top and the avatars.
Make sure you restart your operating system after installing, because I was getting some strange window behavior previous to that. One feature that is a "little" buggy is the theme customization. You can try to change your windows color to black, but even if you set it as your default color, after restarting Windows Live Messenger it will be reset to the default blue, even the main window will get the default color…
Next step: keep on testing and try the other applications also.
I’ve been writing about Windows Live Agents recently, as you recall. Finally I had the time to leave some more tips.
First Goal: Trigger a notification (procedure that is scheduled to run some time after it has been triggered and which generate messages to the current user) based on a timer event. The notification will be triggered by the current user.
How to achieve this goal?
The code bellow is contained in the Main.ddl file. First of all I declare a global variable to count the number of notifications that were made to a specific user (counter1). Then I declare a procedure that increments the counter, sends the counter value to the user as a friendly message (Notify), and then the magic happens! 
I declare a notification, which is composed by a time interval and the script that will be executed, in the example bellow the time interval is 10 seconds and the script to be executed is a call to the same procedure.
The usage of this recursive approach makes the notification to run every 10 seconds starting from the first call to the Notify procedure. The fist call is made when the user types “notify” and sends this message to our agent. Pretty simple.
Second Goal: Start a conversation with an user
If you want to start a conversation with a user, instead of reacting to the user input, BuddyScript allows you to achieve that objective. But be careful about the License Agreement and make sure you read it before you start developing a agent with this kind of behavior. In spite of this issue I’ll show an example for educational purposes only. 
How to achieve this goal?
While declaring a procedure you can add the startup keyword to run this procedure when the agent is loaded, and you can specify a time interval between calls to this procedure. In the example bellow we have a timer-based procedure running every one minute since the agent is loaded.
To start a conversation with a user you can use the initiate command, which receives a user id (e-mail) and a procedure name to be called (this command can be used for other purposes, check the documentation in MSDN). The engine will start a conversation with the requested user and call the procedure in that user’s context (this way only that user will receive the messages sent by this call). You can initiate conversations with several users, just add several lines like the last one in the example above.
About a week ago I read on Channel 10 that Live Mesh was available to everyone on the U.S. Sarah Perez even gave me a tip: I could try it too! I just had to change my Windows Regional Settings, to tell Live Mesh servers that I was from the U.S. Shame on me, lying in order to access Live Mesh. 
I wrote about Live Mesh some time ago. Now that I am using it I can say that is just as I was expecting. You can register your devices (just Windows-based computers, for now) in Live Mesh in order to sync files between devices and remotely control devices. The screenshot bellow shows the devices list page. It includes your registered devices, a special device called “Live Desktop” and an Add Device button.
That “special device” Live Desktop to which you can connect is a simple interface where you can access your shared folders, download stored files, create folders, upload files, etc. AJAX allows a kind of user experience that resembles to a real Windows desktop, so the name “Live Desktop” is appropriate. Since you can share files/folders with other people, in order to keep track on your Mesh you have access to a “News” panel where you can stay up to date with changes that have been made.
The client software that you download from Live Mesh and install in your computers has an interface that is identical to the panel that is available on Live Desktop. This application notifies you when any change happens, and takes charge of all the syncing-related tasks. Bellow you can see a “Programs” folder on my desktop. Folders that you have in Live Mesh are fully integrated with Windows Explorer, so you can browse them as any regular folder. You can even share a regular folder in Live Mesh just by right-clicking it and choose the context-menu option “Add folder to your Live Mesh…”.
I must confess that I haven’t used the folder sync functionalities. I just tried one time after I installed Live Mesh, but one great functionality that I have been using is Remote Desktop. Using Internet Explorer you can remotely control any of your Windows devices from anywhere in the world where you have an internet connections, without any particular software, just an ActiveX control that acts as an Internet Explorer plugin.
Remote Desktop works pretty well. I can even browse in the web, check e-mail, install software, etc, in the remote device using this functionality. You can only connect to a device that isn’t currently in use and has the Live Mesh application installed, so if you are like me, and what to control your home computer from work, don’t forget to leave if locked or logged off. I have been having some issues with connectivity. When I loose my connection to the web, I get a retry connection button from Live Mesh, but it almost never works… Another issue is related with copy/paste files between your local machine and your remote device. It is way too slow… And copying text from the local clipboard to the device doesn’t always work. Well… It is just a Tech Preview, not a final version.
The mobile version of Live Mesh has became available this week, it allows you to check the news on your Mesh and download files. It is available at the address https://m.mesh.com. A Mac version of Live Mesh is on development.
So far Live Mesh is a mashup and rebranding of several “old” Microsoft products like Folder Share for file sync, the Remote Desktop connections via web browser of Windows Server 2003, and since we have 5Gb of storage that can be used not only for sync but also for sharing with other people, has a little bit of Windows Live SkyDrive. But the kind of integration that Live Mesh brings is pretty great as an user experience improvement.
I’ll be expecting news from Live Mesh team.
After I wrote about getting started with Windows Live Agents, it’s time to go deeper into BuddyScript, the script language that is used in agents development.
To make your code easier to manage and even to make it reusable you can create package files. These are files that aggregate functions, procedures and data sources that are strongly connected. These packages can be referenced in your scripts using the package statement in the beginning of your script file. To create a new package right click you solution and add a new item based on the PKG File template. The name you give to your package file will be also the package name.
I’ve created a package named DataSources.pkg in which I will write sample code related to data sources usage. You can have several kinds of data sources which are listed in the official documentation. Today I’ll talk about 2 of them. First of all the HTTP data source. It Allows you to download data from the web to use in your scripts. When you declare a data source you must give it a name, return type and if you wish you can add parameters. The example bellow is called GetRSSFeedDataSource, has no parameters and the result type is composed by three fields: title, description and link of a RSS feed entry.
In the data source body I define the source file on the web, the timeout for the HTTP request and the expiration time (for caching purposes). You can even define HTTP headers like the user-agent in the example bellow. Now, lets take a look at the source code.
The data that is downloaded by this HTTP data source is parsed using a simple xml filter (there are other like script-based, XSLT, etc). This kind of filter allows you to filter and format your data source results. In this case you can dive into the returned XML and return particular parts of it. This data source only returns the first entry on my RSS feed, but as you can see in the commented code, you can iterate over the XML using loops.
Now lets see an example of usage of my data source.
I defined a procedure where I call the data source, extract the title and link, and send it to the default output device (which will be the Windows Live Messenger conversation window).
Another nice kind of data source that can be configured and used is based on SOAP web services. The example bellow uses a silly web service that I wrote in .NET that sums two numbers and return the result. This data source has 2 parameters (the operands) that are used as input to the web service. I had to define the proxy parameter (URL of the web service), the name of the operation to be performed (and the respective action) and also the namespace of the web service.
SendSum() is a simple procedure that outputs the sum of two parameters. I’ll use it later. The demo web service is packaged with the rest of the project that I made as an example for this post. Download project source code and take a look at it.
Now that we have defined these two data sources, I’ll show you how to use them during a conversation of an agent with an user. The next lines of code were added to the Main.ddl script file. First of all the the reference to the new package, adding the “package DataSources” line to the beginning of the file.
I have chosen to show the first entry of my blog when the user types “news” into the conversation window. When I recognize that pattern, I call the SendLatestRSSEntry procedure that I’ve defined before.
The second example is great to show how simple it is to recognize patterns and split them into variables. The second expression matches with messages that have the format sum <integer> and <integer>. And store the two integer in two variables: OP1 and OP2, which are used as parameters to the procedure SendSum. You can learn more about matching expressions in MSDN.
Feel free to download the project source code and change it at will.
Recently I’ve been exploring the Windows Live Agents SDK. This framework allows you to develop interactive Windows Live Messenger bots. You may already talked to a messenger bot like encarta@conversagent.com which allows you to search information from Encarta Encyclopedia or if you are Portuguese maybe you use info@destakes.com which gives you news about topics you choose, using data from several news websites.
To start developing your Agent/Bot/Buddy you must have Visual Studio 2005/2008 installed as well as .NET Framework 3.0. More details about requirements can be found in the Installation Requirements web page.
After fulfilling the requirements you can download the Windows Live Agents SDK and install it.
Now you are able to start developing your first agent! Open Visual Studio and open the “New Project” window. There will be a new project template under the “BuddyScript” project type. After choosing the “Windows Live Agent” project template, and typing your project name, you will be prompted for some project settings. You can choose several languages for your Agent and define if it will be able to do some default chatting with users. The only problem I found is that a project created this way is way too complex for a beginner, and if (like me) your target language is not supported or if you want your agent being able just to respond to specific messages, it is pretty difficult to use this template.
After hours trying to find out that was really relevant, I’ve created a Simple Project Template from which I removed a lot of files and settings from the original project. It has only some usage examples in Main.ddl (main BuddyScript file). This project is testable out of the box
The examples I left on the file are pretty simple. They cover how to set an expected input and how the bot is supposed to react. It also uses a package that makes available information about the current user, like his user name. I left some comments in the code. There are a lot of possibilities that can be explored. Something I tried already and that I will share in future posts is the usage of data sources like XML, Databases, RSS, etc. If you are curious about BuddyScript capabilities take a look at the BuddyScript Language Reference.
In order to test your agents you must have a license key, which is easy to obtain from within Visual Studio. Check out How to: Install the License Key.
You can test your agents directly in Visual Studio (Menu View > Other Windows > Conversation Window) with the interface showed bellow.
More information about this kind of testing can be found on the How to: Launch the Agent in the Windows Live Agents IDE article.
Another way of testing your Agent which is much more fun, since you can ask your friends to test it too, is deploying your Agent on the Windows Live Messenger network.
Read How to: Launch the Agent in IM Environment to learn how achieve it.
More detailed information can be found in the Windows Live Agents SDK documentation at MSDN.
Next time I will talk about using data sources, background procedure (code that runs detached from user conversations), notifications (scheduling messages) and how to create pro-active agents that starts conversations instead of responding to user requests.
In understand that to make Windows Live Messenger profitable and free to all of us to use it has to have some kind of advertisement system attached to it. Sometimes these ads are useful, since they are different for each country and there are several major brands that use Windows Live Messenger advertisement.
Nevertheless, recently I’ve not been pleased by Messenger advertising. It has been really annoying. Now there are a lot of ads that just pop up out of out our main Messenger window showing some sort of flash animation. Some of them are pretty big and annoying when I trying to reach a contact that is hidden beneath the ad… Most of them disappear when the mouse leave the ad area (it is the minimum that I expect…) but other ads are only disabled by clicking a close button.
I am starting to understand those people that use software that patches Windows Live Messenger to remove all the advertisement. It violates the terms of usage and it is wrong to do it, but this Messenger advertisement “feature” is becoming to invade the user space. Some day in the future maybe I will consider the hypothesis of moving to a IM software like Pidgin (which I like pretty much ) that is compatible with MSN protocol.
There is even a portable version just like I love in software).
