Infosys Microsoft Alliance and Solutions blog

« July 2009 | Main | September 2009 »

August 28, 2009

Part 2: Why uploading PPTs is a good idea for live meetings?

In the first part, I talked about art of presentation. Moving on in this part I want to focus a bit on another important aspect for presentation.

Doing sessions over live meeting is becoming more and more common these days, but a very basic need of uploading the presentation to live meeting server and then running the presentation from it isn't followed by most speakers and thus impacting the user experience of the session.

User experience ! you probably are wondering, what's there about user experience in this. But anywhere where you are dealing with audience, there is some user experience that you should worry about.

When doing sessions with live meeting on Vista and sharing desktops, Vista typically switches to Vista basic theme and this can disrupt the feel of the presentation. This can be very irritating if you have used some interesting theme for the slides that works on true colors and since the session is now running on basic theme with only 256 colors, the slides as seen by others can be easily become unbearable. Uploading to live meeting server does away of this issue.

Depending on the flow/story line of your session, you may want to be aware of the upcoming slides. If you have done enough rehearsal, this should not be an issue, but otherwise it can impact the session delivery. The other day as part of our REST session in Virtual Tech Days, we had a dialog going on between me and Suds where the questions asked by me would lead into the next slide. Uploading to live meeting server and presenting from there, allows you to get a thumbnail view along with the current slide, just like you get when editing slides in power point and this then becomes very handy.

Another big irritant for audience is when there is resolution mismatch and given the varied sizes of monitors available these days, it is all the more prominent. See some details on resolution and its side effects in Shashikant's blog here. So while you would be happily getting to see the entire slide, the audience may most likely be worrying about scrolling left-right and up-down to view the entire slide.

And finally, sharing from desktop also means that your other applications also get shared. And I have in many sessions noticed some messenger popup or some email popup that is either distracting or even embarrassing for the speaker. You may also have a need to chat quickly with a colleague while doing the session, but sharing means that the audience will get to see what's going on. You can definitely selectively share applications instead of sharing the desktop, but the other issues will also exist.

So when doing your next session, think about some of these and try and make the session a pleasing experience for all. It isn't only the content that matters, but the over all experience does make a big difference.

The green colored ERP !

Recently while working on a solution for a client, I realized how important the Green house gas reporting has become for global organizations within a short span of time.  Typically, systems are put in place to increase efficiency/enhance ROI and eventually reduce cost.  With the legal and compliance requirements getting stringent post developments like Kyoto Protocol, global organizations have started noticing the financial costs green house gas reporting. Although this might be insignificant in comparison to any other cost, solutions addressing the Greenhouse reporting requirements are catching the attention of organizations.

Other than the important driver of meeting compliance, one key factor that appears to me as a very significant reason for organizations taking seriously into GHG reporting is the prospect of trading Carbon Credits which is possible only if there is adequate traceability into the data for the GHG emitted or for that matter not emitted by a particular organization.

Although there are solutions which enable companies to address the appropriate reporting of GHGs, a better option in my opinion is to have an extension to an existing Enterprise solution which actually captures the transactional data responsible for such emissions. This can vary right from the building level consumables such as Electricity/Fuel/water etc. to employee level transactions such as Travel/Paper usage etc.  Native ERPs would typically have data that can help compute this consumption.

Microsoft Dynamics AX 2009 has come out with the Environment Sustainability dashboard which facilitates organizations in defining processes to ensure better data capture and eventually enable them to report on the green house emissions.  Built on GHG protocols, this dashboard enables data modeling. It is designed to allow organizations to create a digital representation of its interactions with other organizations and the environment. Using this model, businesses can describe how materials and energy are used. More about this can be accessed at:

Although the solution features may not solve the enitre problem area of GHG reporting, it does give a starting point in delivering solutions in this space addressing varying customer needs globally.This is in line with the new set of business needs that are driving ERP solutions to encompass areas that had traditionally not been part of the ERP space!

August 26, 2009

Am on Windows 7 RTM

Windows 7 RTM is available on MSDN subcriber downloads is not a new news anymore. I also had downloaded the Enterpride edition few days back and just got around to installing it. The experience so far is good.

Some months back my colleague Naveen had installed Windows 7 RC and had faced some issues that he had written about here. I will talk about some of the issues he faced and how they behave on Windows 7 RTM.

Let's first look at some of the issues that Naveen had faced.

1. I also noticed the decktop flicker. The scenario that I noticed it with was when I was running a program that wasn't compatible with Windows 7 Aero and I had used a desktop theme that would flip through the background images. When the background image changed, it caused the program to behave eratically and that's when the UI flickered a whole lot.

2. Didn't face any issues with network connectivity of the messages. The icon used to display this has changed from what it used to be earlier. The good part is that wireless worked like a charm. With Vista I used to almost always have trouble detecting wireless and connecting to it. With Win 7 no issues at all.

3. I have installed the VPN Software but still need to test it. Will try and do it today evening from home and see how it behaves.
[Update: August 27] The VPN software worked like a breeze.

4. The anti-virus, turns out has some issues with UAC and application compatibility. Some specific EXEs need to be appropriately shimmed and their compatibility set correctly. The interesting part is that you can right click on a EXE and select "Troubleshoot compatibility" and that should pretty much get you going. However just to add on, the installation itself did prove a bit of a pain. It didn't work with my login, didn't work with setting UAC to minimum as well. Had to login into the machine as local admin and only was able to install it.

5. No issues faced with IE 8 and working with outlook web access. I know of cases where people have set the compatibility view setting as enabled for the page and OWA doesn't seem to work. Having removed it, it works without issues.

This pretty much covers the issues Naveen faced. In my next blog I will capture some of my own experiences. Keep a watch for the same.

August 25, 2009

How i explained REST to a SOAP pro

Through this dialogue based interaction I (Sudhanshu) Demystify REST based Architecture to a SOAP pro (Atul). You can additionally refer to slides and code samples posted on the following blog. Wherever i have referred to demos, the corresponding code samples are at following site
Let’s enjoy this ride together.

Atul: Let’s look at how distributed architectures evolved.

Distributed Architecture Evolution (Slide 3)

It all started with monolithic mainframe application with calls restricted to machine boundary. Enterprise Applications grew in complexity and needed more and more calls to be made across machine boundary, which was made possible with DCOM CORBA architectural styles.
Further on, there was a need to connect across enterprise boundaries to other domains, partner networks. The complexity and volume of calls across enterprise boundaries continued to grow rapidly and needed more pervasive, secured protocol to communicate with other applications and services over web. SOAP based services helped address these needs.

SOAP (Slide 4)
SOAP is transport neutral and supports multiple transports like Http, ftp, JMS, SMTP, TCP, MQ, etc. and is platform agnostic

They implement WS* specifications like WS-Atomic Transaction, WS-Security, WS-Interoperability, WS-Reliability, etc and hence are highly secure, reliable, and transactional.

To support adoption of SOAP based services, lot of vendors have used the specifications to implement technology and tools, like Microsoft SOAP toolkit, SOAP with Attachments API for Java, and IBM’s SOAP4J.

Sudhanshu: Atul, Atul, I understand that you are SOAP guy, but I would like to bring out another perspective on SOAP

SOAP has some Limitations (Slide 5)
I agree, it supports multiple protocols and it builds on this protocol stack by implementing WS* specifications. But this makes the stack complex. It completely hides the core underlying protocol.

The communicating parties need to agree on a specific SOAP contract. Hence you cannot start consuming the services without complying with the contract and this affects the interoperability.
As soap is rich and supports multiple standards like WSDL, WS*, XML , etc.., it increases the message size. This has impact on the validation, parsing and translation time and hence on application performance.

There is high entry barrier with SOAP as working with it requires one to follow the specifications, which requires investment in technology, tools and skills.

Atul: Hmm. Sudhanshu, what you say makes sense. But then if SOAP has these issues, what is the alternative?

SudhanshuAtul. Let me introduce you to REST.

Introducing REST (Slide 6)
REST stands for Representational State Transfer, and is an Architecture style for building services on World Wide Web (WWW) and was first introduced by Dr. Roy Fielding through his dissertation in year 2000.
REST based services relies on already built web infrastructure.

Atul:  That’s interesting. Sudhanshu, can you elaborate on your last point a bit more.

Sudhanshu:  Sure. 

REST leverages the already built web infrastructure like Web which is mainly built on http Programming model. REST is built completely on http and leverages all the attributes of http like Uri, http methods, caching, chunking, http error codes and so on.

Unlike SOAP, which only uses POST operation, REST uses all http operations like GET, POST, PUT, and DELETE. REST services are easily discoverable through Web URLs as against the Service Discovery in SOAP. It uses http error codes to communicate response messages to the user. All this together makes REST a good citizen of Web.

Let’s take a look at how typical Http call takes place.

Typical Http call (Slide 7)

A user initiates a request from his or her browser. The web server receives this URL, locates the resource requested and returns it to the client browser along with the status message. The resource is transferred over wire in the format specified.

Atul: a few aspects that I notice from this interaction. There is a specific URI, there is a GET operation, and there is a specific response with appropriate code.

Sudhanshu: You are right on target Atul. Also note that this entire operation is stateless. All this translates in to REST design principles

REST Design principle -1 (Slide 8)
Design principle 1 is - everything that needs to be identified on Web should be treated as a resource. Document, Order, Product, Customer, are all examples of valid resources. For example – The following url identifies order as a resource with order ID 1234. SOAP, it is more of operation/verb oriented design approach, while in case of REST it is resource oriented, resources are treated as Nouns.

REST Design principle-2 (Slide 9)

Design principle 2 is - Use standard http methods to operate on resources.
GET is for getting a resource and possibly cache it
POST is for Inserting or appending to a resource
PUT for updating a resource
DELETE is for deleting a resource

Atul: Sudhanshu, I understand SOAP, but am not able to relate to all this. Can you show how all these translate into URIs? 

Mapping SOAP methods to REST (Slide 10)

Here is the mapping of SOAP service operations to REST operations. For Insert and Update one will have to pass the xml as depicted here.

All URLS need to be unique and you will see that GET has TASKS/taskId while DELETE has TASK/taskID.

Atul: but if we go with the idea of unique URLs for each resource access, isn’t that like making too many chatty calls over the wire?

SudhanshuAtul that is a great question and REST’s third design principal is really about this aspect.

REST Design principle 3 (Slide 11)

Web is beautiful because we can navigate from one page to another page and there are links to do that. Imagine if there were no links? Web wouldn’t have been this beautiful. The design principle is - Connect lower order resources using links to form a higher order resource.  
The below example illustrates an Order with an Order id of 1234, having product with code 455 for customer id 20084 with billing amount as 15000

Let me quickly take you through principle 4 and 5.
REST Design principle 4 and 5 (Slide 12)

Design principle 4 - The resource should be presented to user or client in multiple formats as the client desires. The formats can be anything like Document, PDF, XML, JPG, JSON, Binary, HTML, ATOM, etc. and finally the fifth principle states that the interaction with resource should be stateless
Atul: Wow! SOAP has specifications and REST has principles.

haa haaa ! you are right Atul, but unlike specifications, principles are flexible and allows one to create high rest or low rest type architectures.

Hi-Rest Low-REST (Slide 13)

Hi-Rest applications strictly follows all the REST design principles we discussed so far. Low-REST application follows design principles but also look for practicality of the same and hence is called Pragmatist approach.
e.g. A Low REST application can make Ajax or POX(Plain Old XML) calls, can have URIs with query string params, can use only POST and invoke PUT and DELETE through it.
The above URL has .svc extension as part of it and hence can be called treated as LOW-REST. To translate this into Hi-REST one can use URL- Rewrite module from IIS 7 and translate this to more user friendly URL like the one as

Atul: OK! But with SOAP I have in-built .net framework support to implement SOAP services. What about REST?

Sudhanshu: There is good framework support for REST.
Framework support for REST
(Slide 14)

Built in support for REST exists in .Net 3.5 onwards through namespace System.ServiceModel.Web
It provides WCF specific APIs and behaviors, importantly it also provides WebHttpBinding to abstract Http protocol behavior through WebHttp, which helps in development of RESTful services. It does not use SOAP envelops. It supports http and https transports.
UriTemplate, WebGet, WebInvoke are the Web attributes.
UriTemplate binds WCF operation to unique URI.

WebGet and WebInvoke helps in mapping http GET/POST/PUT/DELETE to a resource. It also helps in defining the request and response formats, the formats can be XML, or JSON.
With this background, let me also quickly show you how all this stack up to create the architecture . 

REST architecture (Slide 15)


We have .Net framework as a lowest layer in stack. Apart from providing standard XML serialization and other capabilities, it provides System.ServiceModel.Web assembly for exposing REST based WCF Services.

IIS can be used to host the REST Services. Browser sends the request to IIS, IIS locates resource and sends the response to the client in desired format with appropriate response code.
IIS can be used to implement additional security like limit number of calls to specific URI. Lot of vendors allows only limited (say 100) calls from specific user to specific URI per day, this helps in avoiding any attacks on the site. Also you can secure pages using https, implement client certificates and so on.

If you don’t want to use IIS, REST Starter kit also provides a service host to host the services. ADO.Net data Services can be used to expose Database entities and data as REST services.

All theory and no play, makes Jack a dull boy.

haa haa.  I get what you are hinting towards. So let me quickly show you some working demos.
Demo 1
-Task Management REST Service Demo (RESTTaskManagementService project) (Slide 16 )
Let’s take a look at the Task Management REST service demo. This demo demonstrates various task management related operations like Create task, Update Task (AssignTask), Delete Task, Get all tasks.
.cs -
                The task has id, title, description, owner and create date. This is captured in the dataContract.

IManageTask.cs - Let’s take a look at Service Contract.
There are various operations to manipulate tasks like GetTasks, CreateTask, etc.  but if you remember REST Design principle 1, it said Resources should be identified uniquely using URI’s,  these operations are translated to URIs using WebGet () and WebInvoke attribute. WebGet is for Http Get and WebInvoke is for Post, Put and Delete.
Also we have defined the request and response message format as XML here. All this is possible because of the System.ServiceModel.Web assembly

Now let’s take a look at the TaskManagement.svc.cs which has implementation of the interface.
Here we have simple list which we are populating with tasks in constructor and then manipulating it in various respective methods.

TaskManagement.svc Markup
Let’s take a look at the mark up, we have not mentioned any service host class here.

Finally let’s take a look at the .config file System.ServiceModel section where we define the configuration for service.
If you observe the binding, we have defined explicitly webHttpBinding and behavior as webHttp, which makes accessing the service over http possible.
Now browse the service by rt.clicking the page
Let’s access operations in browser.

GetTasks http://localhost:38161/TaskManagement.svc/Tasks
GetTask for a specific owner. Since we defined the response format for this as Json we will get a javascript file…let’s save…open it and see…

What you showed me is the server side logic. How will the client make calls to such REST services? 

Sudhanshu: Sure. Let’s take a look at how we consume the REST Services in client applications using WebChannelFactory.

Demo 2 – Consuming REST in Asp.Net using WebChannelFactory (WebChannelFactoryClient project)

Add assembly System.ServiceModel.Web 

First I add the reference of System.ServiceModel.Web which makes the WebChannelFactory classes available then I have to add the web reference of TaskManagementService assembly so that I can have stub or contract of the service on the client side and can access operations.

WebChannelFactoryStyle.aspx.cs Page load
In the page load, I create the instance of WebChannelFactory by providing the URI of the service and then call the CreateChannel to get the channel reference.  Once I get the channel reference I can access all the methods of service.

Let’s set the WebChannelFactoryStyle.aspx as the start page and run it.
Run by browsing.

Let’s try Get, Insert, Delete operations from this application rendered in browser.

This is good, but to me this looks like the way I add reference and invoke SOAP based services. This doesn’t looks like pure REST to me?

Good catch, so you are paying attention haaaa haaa. This can be called low rest implementation. Let me quickly show you a high rest implementation.
Demo – HttpWebRequestStyle.aspx (HttpWebRequestClient project)
No reference of Task Management

We don’t need the reference to TaskManagementService here.
httpWebRequestStyle.aspx.cs, GetAllTasks
We use  httpWebRequest and HttpWebResponse objects from System.Net namespace
Let’s take a look at the GetAll Tasks method.
We create a HttpRequest object by passing the Uri , define the Request method as GET and then read the response stream and bind it to XML UI control.

Similarly for Insert, we use the POST method and write to request stream.
Browse the httpWebRequestStyle.aspx…..

Atul: So far so good. But with SOAP WSDL, I can easily obtain the invocation details of services. Is there any such support with REST?
: Yes. Let me introduce you to REST Starter kit.

REST Starter kit (Slide 17)
The rest starter kit is free and can be downloaded from codeplex site. It has some nice features which simplifies REST services development. It provides Service host which provides the automatic endpoint and one doesn’t need to specify address, binding and contract explicitly in .config file. It also provides attributes like WebCache for caching and WebHelp for help on services, which provides you the invocation details of services similar to WSDL.
For improving developer productivity it provides templates for singleton/collection, http/ POX, ATOM publishing and feed services.

Sudhanshu: Before you ask, let me show you a quick demo
Demo REST starter kit
(RSKT_RESTTaskManagementService project) (Slide 18)
First and foremost you add the assembly  for REST Starter kit, Microsoft.ServiceModel.Web and .extensions

IManageTasks.cs -WebHelp and WebCache
Let’s take a look at WebHelp and WebCache attributes defined in IManageTasks.cs
WebHelp provides help and WebCache help maintain the cache. The caching is defined through <caching> attribute in web.config file

TaskManagement.svc.cs  GetAllTaskByOwner  - Protocol exception
The protocol exception class is useful in translating any clr exceptions into HttpError codes and messages. Here I am checking for business condition as OwnerName equals ‘xxx’ and raising alarm by throwing exception. The Protocol exception helps translates that into Http Error codes.
The key thing to note here is ServiceHost in the TaskManagement.svc markup file. The Service host make it possible to not have any configuration related to endpoint or behavior defined in .config file.
Let’s run the TaskManagement.svc and see how it works


1)      WebHelp – it provides WSDL like information in the context of REST services…like which uri to use to access the resource, what does each Uri does, formats in which the information to send and receive.

2)      GetAll Tasks – Demonstrate it for caching….


if you keep refreshing the web page for above request, you will observe the page doesn’t refresh for 30 seconds. This is because of the WebCache attribute on the GetAllTask method and corresponding settings in .config section

3) By owner – obtain task by owner by accessing the following url

4)Protocol exception –  type ‘xxx’ as user name and it throws protocol exception which is similar to Http Get request.

Atul: Alright. That’s lot of insight that you have provided, but here’s another question for you. When I work on architecture of an application, I need to think about aspects like security, transaction, reliability etc.
Sudhanshu: Atul, I knew that was coming.. haa haa.

Security (Slide 19)
SOAP provides WS-Security. With REST same level of security can be achieved by using https and also by using user or developer tokens. “Access Id” (private key) and “Secret Access Key” (shared key) together is used to secure services.
Digest, basic, Hash message Authentication Code (HMAC ) can be used for authentication.
HMAC is recommended for enterprise application authentication.

Reliability and Transaction (Slide 20)
Reliability can be achieved using http Idempotent put operation and Transactions can be achieved by treating Transaction itself as a resource.
Create Transaction (use POST), Commit transaction using PUT and rollback using DELETE.
Retrieve transaction using GET.
Atul: Sudhanshu, we have had some interesting discussion so far but one thing that is still bugging me is, if this is being used anywhere or are we talking about a technology that looks good on paper or in books? Are there are any real world implementations?
Sudhanshu: oh god Atul. You have a never ending list of questions. Let me give you some real world scenarios
Let’s revisit the distributed architecture viewpoint.

Distributed architecture view point (Slide 20, 21)


From 2005 onwards with emergence of Web 2.0, social networking, software as a service and the more recent cloud based solutions, REST as an architectural style is actively considered as an option for such implementations.  This is primarily because REST. 
*      Is Simple and http based, which makes it highly interoperable.
*      Provides improved Response time and reduced Server load
*      Requires less client side vendor software
*      Easy to implement and consume and hence have relatively low entry barrier as against SOAP
With this, REST has become light alternative to SOAP J

Adoption, Commercial applications (Slide 22)
Amazon has both REST and SOAP interfaces, 85% of their usage is REST interface.
Amazon’s S3 (Simple Storage Service), Flexible Payment, Queue, Search Service exposes both REST and SOAP interfaces. All Microsoft Azure Cloud Services are REST based.
Google, Yahoo services, Flickr, Facebook, Twitter are built using REST services.

Atul: Are there any guidelines for selecting REST over SOAP?
: Yes, there are.

SOAP vs REST? When to use what? (Slide 23)
Use SOAP when you are developing mission critical applications which needs high security, reliability, needs multiple transports, and are highly transactional in nature.

Use REST when interoperability of the application is highly needed, performance is critical, apps. Need to be accessed from multiple devices, needs high scalability and faster time to market with moderate security, reliability and transaction requirements.

That’s great Sudhanshu. This checklist will come very handy and I should say that REST to me is now demystified.

Sudhanshu : Atul, I am glad that REST is Demystified to you.

Dear Readers, we hope it is Demystified to you too. Following are some of the references we have referred to. Appreciate if you log your comments on to the post.

*      Dr. Fielding’s Dissertation
*      WCF Screencast
*      REST Starter kit
*      ADO.Net data services


August 24, 2009

Part 1: Art of Presentation

In part 1 of the blogs on presentation skills, I will focus a bit on art of presentation, essentially factors that I believe play a significant role in making or breaking it.

When I think back a few years, I can’t fail to remember the time when I would be dead scared going in front of audience, words would fail me and I would go weak in knees. Knowing the job requirements where I would have to do many presentations internal facing (trainings, knowledge sharing etc) and external (client facing), I consciously decided to improve on the presentation skills and that I personally believe is the first step in doing good presentations.

Scope for Improvement: Unless you accept that there is something to improve, you won’t. You can only pour more into a cup if it not already full. Over the years I have read various articles, watched industry leaders talk and pick up from that. Extension to this is ability to except feedback that will help you improve further. In past few months, through various forums, I have tried to provide opportunities to others in team to do internal presentations so that they get a platform to try and build on their skills and I share what I felt as an audience listening to them.

Identify role model: Once you decide to tread on the improvement path, it would be a good idea to pick up a role model that you feel is really great in this skill and learn from him/her. The role model help you to have a focused goal in your mind that you want to be like that person and that helps you remain motivated and committed towards improvement.

Confidence and Passion: There are definitely tips on content, duration etc for the presentation, but another key aspect is confidence. The more confidence you shown the better people will like it. Those who come to listen, obviously are there with an aim to learn (unless off course forced by their manages to attend J) and if they don’t get a sense of confidence from the speaker, they will not like it. Two people I have as my role model and who also exhibit great confidence in their speaking are Mr. Nandan and Mr. MD Pai. It is just amazing to listen to them talk.

Knowledge: While confidence is important and there are people who can possibly still confidently say that the earth is flat and make you believe it as well, but knowledge depth also plays an important role. If you have good knowledge, the confidence pretty much comes automatically. Ensure that you do your ground work on the topic before the session so that you can handle the content and the questions with ease.

Rehearse: This is one aspect missing in most people. Rehearsal not only helps you get familiar with the slides so that you aren’t surprised when presenting (I have seen people staring at slides for couple of minutes trying to make out what it says), but also gives you an idea of the time it will take and helps boost your own confidence.

Stick to time limit: Nothing puts off people more than apathy of the speaker towards their time. No one has all the time in the world and most likely people have commitments following your session. If you can’t respect their time, they will not respect you. Hence starting on time and ending on time is critical. Ending way ahead of time is also not good. It may create a perception that you either didn’t have enough content, or have skipped some sections which you probably were not comfortable with. It essentially puts your knowledge at question.

Spilling over obviously creates unrest and people start looking more at their watches that listening to you. It would be really great if you can upfront tell the audience that you will take so much time for the session. This also means that if you allow questions in between the session, ensure that you still stick to the schedule or ask people to keep their questions on hold to the end.

Finally, if someone is keeping time and prompts you for time out, you need to be able to do a quick exit without disrupting too much, in technical terms, do a graceful exit.

Gauge the pulse of the audience: Doing a check on comfort of the audience upfront is a good idea. This helps fine tune your presentation. There are cases when speakers come with a deck where they get into too much technical depth and the audience may be folks who don’t have much interest in technical depth. There are cases when you put too much of introduction and audience already knows basics and feel irritated on being told all of that again. The other side can also create problems where you expect some minimum competency but most from audience are novice in that area. Finding these out earlier by asking few questions can help set the context for you. Even while presenting, keep a watchful eye on how many people are still awake, what’s their body language and try and modulate accordingly.

Voice Modulation: Along with confidence, this is also an important aspect. Many speakers I have heard will have good content and are really experts in their area, but since they deliver their content in a monotone, it creates discomfort with audience.  Varying the speed and the pitch can help keep the interest alive and create excitement in the audience. During one of our trainings, we were doing short presentations on our introduction and there was this person, who introduced himself in a low dull voice (as if he wasn’t interested in being there) and said that he has two patents in his name. Wow ! That is just amazing!!! But the way he spoke it, half the people didn’t even register this aspect at all. Needless to say, you should not go overboard to the extent that every sentence has too many variations.

Eye Contact: Some of us get nervous looking at the audience in the eye, but it is important and shows that you in a way you connect with the audience and are comfortable. Looking up at the ceiling or down at the floor etc only gives signals to the audience that you don’t like being there and so why should be they like your presentation. Many of us on the other hand find some comfort zone by identifying 1-2 people on audience whom we know and then we deliver the entire session by looking at them. Believe me, it puts this person in spot and very soon, you will see him/her unpleasantly twisting and turning in their chair. And the other audience will feel left out. You need to constantly shift your eye contact across the room and from front to back so that everyone gets to feel that you have noticed him/her and are addressing him/her as well.

Body language: The earlier aspect on confidence to a large extent is communicated to the audience via your body language. If you are standing at ease and have a pleasing smile on your face (where possible), people will like it, as against if they need to constantly turn their neck around since you are pacing up and down or you keep wriggling your hands often. Some people I have noticed have a habit of covering their mouth while speaking with the pretext of cleaning their mouth or rubbing their noise etc. These not only impact the voice and make it difficult for people to hear, but also send signals that you are afraid.

Jargon: While there will be technical jargon that you can’t avoid especially if it is a technology specific session, use simple words otherwise, to communicate. Audience isn’t going to like it if they need to dig their brains to capture word meanings. They are there to listen on the specific topic and not your mastery over English language. Fluency is important, but not complex jargon. Also too much of that can create a divide with the audience where they may start to feel you are too superior and then it is more of person comparison than paying any attention to the content.

Analogies: Many times there can be difficult concepts to explain. There could also be case that since the audience has limited experience they may find things difficult to understand. Being able to explain concepts in layman’s terms by using every day examples can go a long way in making your presentation a success.

Word repetitions or pauses: Again a favorite with many of us is a usage of specific words multiple times in a sentence. Typically words like “like”, “generally” and “and stuff” etc are common in our daily communication. When doing presentations, you should consciously avoid these as this creates an unpleasant experience for the audience. Also some of us take too long or frequent pauses with “aaa” or “umm” and this can also irritate the audience. It also sends signal that either you as speaker aren’t comfortable with the topic or have not prepared much.

Accept when you don’t know: We aren’t super humans and hence we can’t know it all. When you don’t know the answer, it is better to accept it, say so and tell that you will get back, rather than trying to beat around the bush. Nothing can be more embarrassing than someone in audience saying that what you just answered is incorrect and the right answer is so and so.

Differentiator: Think is there a way you can make the presentation exciting? What is it that you can do different? I am not suggesting that you make an entry like Akshay Kumar by maybe jumping in from roof or something like that, but technologically what can do you? When I recently did a presentation on Introduction to Silverlight, I created the presentation in Silverlight itself. It helped me do the presentations and demos without having to switch between PPT and the application and overall it was a pleasant experience for people. Most people appreciated and it turned out to be a very effective way in itself to show the features of Silverlight.

Humor: Like the monotone point earlier, making the session very serious can also impact the acceptance. Some element of humor in form of anecdotes etc can help lighten the atmosphere and the audience more receptible. Needless to say that it should be related to the talk in some manner.

These are some of the key principals that I keep in mind when doing presentations. Appreciate your comments or further suggestions that will help all of us become better presenters.

Presentation Skills

The other day over a cup of tea with a few colleagues we were discussing presentation skills. I got good comments about fluency in presentations, time management and overall how I was able to do a good job at it.

I have decided to take a deviation from the usual technical blogs that I have been writing these past years to write on presentation skills. There are many sites already out there that provide good material on this topic and I am not trying to be a presentation skills teacher here. Over the next few blogs, I will share things that I have found working for me.


Part 1: Art of Presentation

Part 2: Why uploading PPTs is a good idea for live meetings?

Part 3: Handling Virtual Sessions

Part 4: Which Presentation Tool to use?

Feel free to comment on these and share your own tips.

Time to REST

Finally it is done with! A couple of weeks preparation, of which it was mostly done by Sudhanshu, we finished with the presentation as part of Virtual Tech Days. This was my first experience in such public forum and ironically there was no public, I mean none physically present, since it was all virtual.

We presented from the MS office in Mumbai and with some minor initial glitches on getting our laptops connect to the MS network, rest all went off very well. We did debate on the fact that since this is virtual, next time around we should be presenting this directly from our Infosys office and need not even come to MS office.

I and Sudhanshu had lot of fun while presenting the session and hope those of you who attended it also enjoyed it. Any further commets, feedback, questions are most welcome and Sudhanshu has already posted the slides and the code samples here.

August 14, 2009

Speaking at Virtual TechDays

Virtual TechDays is back and is happening between August 19-21, 2009. There are loads of sessions to select from. I along with my colleague Sudhanshu Hate, will be presenting a session as part of the Solution Architecture Track on REST based Architectures.  

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter