Learnings from VSIP TFS Dev Labs

Dev Labs (Developer Labs) are to meet our partners to answer their questions and to give presentations on various technology pieces. Today we had a devlab session and I had an opportunity to present how extensibity works for Project Creation Wizard, Team Explorer plugins, and how to create such extensibility plugins. I also got to answer various questions for partners on workitem tracking and it was actually an exciting learning experience for me to know how the product is used. I could see a significant number of product ideas from seeing partner's presentation of their products and their efforts to overcome or workaround some limitations in product.

Project creation extensibility:

I thought the scenarios for project creation and team explorer extensiblity is small and rarely used, but was amazed to see a partner show how they used this extensibility to build a product on new process and plan to release soon (am not revealing the person/company names since am not sure how much I am allowed to say). That product was pushing limits on PCW extensibility and I learned potential useful feature ideas, for example to provide ways to have multiple wizards for single plugin. 

I also saw few forum questions on "programatically creating projects" - which isn't quite possible, but on further digging I found that they could accomplish their needs using project creation extensibility. So looks like this piece of extensiblity will be widely used feature.

Work Item tracking:

I saw a demo from a partner on how they integrate their requirements/usecases etc with TFS and that I could see huge value in having both products work together. Users could take advantage of cool tools in their product to graphically design various artifacts, while workitem tracking and source control did a lot of data management for them. They were very happy to learn about "Custom controls" feature in SP1 and that would enable them to give a rich experience in work item form and just that one feature seem to overcome many limitations in current work item tracking model! Now, they could give rich graphic design features in work item form itself

Main feature asks:

One question I heard more than few times was about identifying a work item type without relying on localizable name. Unfortunately we do not have reference names for work item types and hence it becomes hard to reliably identify a workitemtype. A customer was trying to sync work items of specific types to their tool, and they had to do a bunch of mapping tricks which can be avoided with reference names. Also, a need for default refrence names was heard, while some of those needs can be addressed using "Actions" feature in work item tracking.

I could see people trying to place images in work item description, and they did it by storing those images in attachments and inline placing those images. A useful feature would be to give a way to paste images in HtmlControl, which could be internally stored as in work item db. Eventually it seems workitems will look like email threads with history and rules :) Also, giving a way for users to point HtmlControl to specific web page would be of great use, because they could give "custom control" like functionality in web apps without having the client assembly deployment problems. If you ever needed such features, pls raise them in forums because the more the asks the greater the chances of getting them in future releases.

 

Overall it was fun experience to answer customer questions and actually I felt like I learned much about the product itself by doing research to answer questions and on how the product gets used in the ways I never thought of.