Infosys Microsoft Alliance and Solutions blog

« December 2009 | Main | February 2010 »

January 21, 2010

Percentage Fitment Anomaly - Gosh! Did I just over-sell/under-sell the product to my client?

Place: Could be anywhere in the world!

Actors: Consultant (Jerry) and Client (Tom)

The Conversation:

Tom: So now that you know my needs; can you tell me what is the percentage fitment for the product you are recommending?

Jerry: Well, this depends on how you see it; but I can assure you it’s a good fitment. Nothing will meet your needs out of the box.

Tom: Can you be more specific? What is the fitment in percentage terms – 40%, 60% or 80%

Jerry: Ok, let me get back to you on this by tomorrow

Jerry lists out all requirements and puts them in an excel sheet; gives a fitment of – ‘Out of Box’, ‘Customization’, ‘Not Applicable’ to each requirement line. And yes, here is the pivot with number of requirements in each bracket. Ready for next day

Jerry: Good Morning Tom; here is the analysis. As I had mentioned yesterday you have a 70% fitment; 20% will be met with customization and 10% are not possible with the product. Net-Net a good 70% fitment is what I see here.

Tom: Hmmn. Looks ok to me. Let’s discuss the statement of work.

Jerry: Sure, Drinks anyone??

Well, I would not like to spoil the party here; but guess there is an inherent anomaly in the above approach. And it is not only the consultants, but the clients also to be blamed for that.

Consultants for not bringing out the perspective to the client and the client for his hurriedness in getting a budget sign-off overlooks that this ‘percentage’ seen in isolation is like asking a question to a married couple – “What is the percentage compatibility between you?”. Can you get an honest answer or do the parties have a mechanism to simply tell this? I am married for 5 years and do not have an answer to that yet.

This small question – “What is the percentage fitment?” assumed a lot of things –

  1. All requirement lines are of equal importance
  2. All requirement lines are of equal impact (i.e. if they are not met)
  3. All requirement lines will require equal effort to achieve in the product
  4. All requirements lines are independent and have no cross-dependencies (parent-child relationships)
  5. All requirements lines define the universal set of business needs and there are no further changes foreseen
  6. All requirements lines have an equal risk profile


My personal approach is to consider all the above parameters and then come out with a fitment which is a true indicator of the amount of effort, time, resources and cost which the client would incur to achieve the envisaged business benefits.

There could be 90% of the lines available out of box but remaining 10% may need an effort which is 10 times the effort required for meeting 90% needs and the risk may be much higher as lot of ground-up customizations can lead to higher chances of failure as well.

On the other hand; another product may be meeting only 60% of the requirement lines, but the remaining 40% may be met with simpler customizations. This can be due to ‘framework’ nature of the product i.e. the product could have been developed in such a way that it provides the basic framework with all business functionalities leaving it to the service providers to customize it to the need of the client. It need not be over-engineered and boast of best-of-breed features which are never used.

I call this paradigm as “Total Benefits & Solution Fitment Framework”. This may take more time; but this gives a better insight into the ‘compatiblity aspect’ which is necessary for this marriage to last. Please feel free to express your views on this.

And before i take your leave-

Tom, Hope you have got the point. I am very much on your side!

Jerry, No offense, was just trying to help!

January 19, 2010

SketchFlow to Production

If you have been following SketchFlow, most likely you have also followed the debate on the ability to convert a SketchFlow prototype to production project. You can find step by step guidance on this in Expression Blend Help (here) and pick the right option as per your technology (WPF or Silverlight) and language choice (C# or VB.NET).

While I have my own beliefs on if this should be allowed or not and personally I am of the school of thought that say that prototype is best left alone. You may lift some concepts from it to take to your production (by age old and still very popular cut paste method), but you should not have a direct path to this conversion. A direct path in my view defeats the very purpose of prototype, which is to try things out and then throw them away (throw the various artifacts, not the learning). Added to that is the point that in UI prototyping you are more interested in getting the look and feel of the screens validated and are neither focusing on the application architecture in terms of layering nor following right coding standards like class naming, method naming etc. hence taking such a code directly to a production targeted project, will break some of the standards that such projects are meant to follow.

Anyway, getting into this debate wasn’t really the purpose of this blog, but that I did want to at least give this option a trial, not for the sake of actually taking anything to production, but to just get a handle on what steps need to be followed. Many people have also written about the 16 odd steps that one needs to do and that it is so painful and all that. Doing these manually, however, didn’t take me more than 5 min.

Most of the steps are pretty trivial and the only place where I have seen some of the people getting stuck a bit is on the final step, where the player is no longer set as root visual, but rather the first screen is set. The challenge here mostly is in figuring out the right name of the XAML file. Blend, by default, names this page as Screen 1.xaml and it is this blank space in the name that possibly ticks people off. The trend that developers are today used to is that the filename and the class name is the same and hence since the class name for this default screen is Screen_1, some people confuse this with file name as well and use that for the XAML file name as well. A related challenge is that while doing your screens, you most likely will rename them as you add them. While this renaming is shown in the SketchFlow map, it actually doesn’t rename the file below. Also the friendly names you see in Blend against the screen name, seem to be Blend specific. If you happen to open this project in Visual Studio (VS) you won’t see these names. In the figure below you can see this difference. The left part shows view in Blend and right shows the view in VS.


I think it will be a good idea for MS to fix these issues.

Further on, having successfully converted my project and I ran it and I could see my first screen load and there was no player, which is what was expected, but my excitement was short lived as my navigate to screen, active state and screen animations no longer worked and I started getting exceptions for the same. If I had some logic built into a control template like doing some animation via control's visual state manager (VSM), it works fine.

[Edited: Jan 20] I had earlier mentioned that navigations didn't work. But they actually do work. The steps to convert to production ask you to remove reference to Microsoft.Expression.Prototyping.Runtime.dll. I had done this, but for some strange reason, when I checked the solution again later, it was still there. Removing it, got the navigation working. The activate state behavior doesn't seem to work still and one solution is to handle appropriate events in code behind and make explicit calls to VSM's GoToState method.

Any comments/opinions? Do write back.

If you know the best way out, do write back.

January 14, 2010

Multitenancy and SharePoint 2010

Before starting this blog let me define multitenancy to ensure uniform understanding. Multitenancy in this context mean isolation of data (including backups), Isolation of usage (what data and services are exposed to the users), isolation of administration (administration of sites, services, customizations), etc. If we consider a hosted environments like SharePoint Online it offers customers 2 mode of hosting

1. Standard: This is a shared infrastructure where multiple customers will be hosting their web applications/site collections (what we call as multi-tenant mode)

2. Dedicated: This is a separate infrastructure of the customer

Some of the biggest challenges that existed in MOSS 2007 for multitenancy include:

1. Where do we host a tenant.. Should we create a separate Web Application or creating a separate site collection will suffice... Of course both have their own pros and cons

2. Services were part of SSP and the alacarte model did not exists and one cannot keep creating a separate Web Application and SSP for each and every tenant 

3. Other major challenge was around customizations as the 12 hive folder is a shared one

4. Ensuring the performance of customizations of one tenant does not affect others

So what is that SharePoint 2010 offers to overcome the above challenges

SharePoint 2010 has introduced a new concept called Site Subscriptions to group site collections based on the tenants even if all the site collections are part of the same Web Application. Site Subscriptions not only does externally separate out the Site collections but also the underlying data in the content database. This goes to the extent of one tenants data will not be seen as search result of other tenants data. The same subscription id also helps in grouping of features and services to the tenants.

The next of the problem is around customizations. SharePoint 2010 has introduced a new concept called Sandboxed solutions. What this means is that the tenant administrators (Site Collection admins) can now deploy features local to their site collections without affecting other site collections of other tenants in the same Web Application. This solves 2 purposes. Part of the administration is getting delegated to the tenants. However the central admin still has control and can ensure to big the feature down if it seen to show any performance degradation.

January 13, 2010

Win 7 - Difference between Touch and Gesture

In my earlier blogs (here and here), I have talked about Win 7 and the new touch experience it brings.

When talking about touch, there are essentially two aspects - touch and gestures and during a recent internal discussion, I felt that these aren't that well understood by people. What's really the difference between the two and what it means to be supporting either of these?

In this blog, I will try and explain them as I have understood them. If you have a different view do share.

The very first way I would like to describe the difference between touch and gesture is, treat gesture like out of box controls, like say for ASP.NET. They are available with basic functionality and allow one to get applications built quickly. Gestures are like that and allow some quick support to application to react to the touch inputs. Touch on other hand can be treated as custom controls, where you implement things on your own and hence get to handle the raw power of the platform. This is more tedious, but in terms of features, can provide lot more than what gesture may offer.

Touch in Win 7 is also related to manipulation events. I found this interesting comparison between gesture and manipulation. If you look at the figures, they very clearly show the difference between the two and also bring out another important point when working with touch on Win 7, a point that people tend to miss out - gesture and touch don't go hand in hand.

What is evident from the figure in that blog is that the system needs to wait till gesture is completed, then check its internal respository to figure out what the gesture was and what is mapped against and then eventually invoke that command. Touch or manipulation on the other hand are immediate and the object/application needs to react immediately to the inputs. This clearly means that gesture and touch are mutually exclusive and can't be handled together. MSDN article also states this - "By default, you receive WM_GESTURE messages instead of WM_TOUCH messages. If you call RegisterTouchWindow, you will stop receiving WM_GESTURE messages." See more details here.

People often wonder that if pan, zoom rotate are really gestures and I am handling touch messages, how do these still work, since we just said that geature and touch are mutually exclusive. These work because to enable legacy support, Win 7 converts the pan, zoom and rotate gestures to appropriate scroll and mouse events, which applications would anyway be handling. See some details on this here. While this legacy support will work, it may not give you the best of results. For that you may have to still look at handling WM_GESTURE specific messages (at the cost of WM_TOUCH). See more details here.

If you have any thoughts or comments on this, do share.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter