Topics: Developer Forum
Aug 10, 2006 at 9:24 AM
I thought it would be worth discussing Joe's version 1.0 of the requirements.

As an initial set of requirements, I believe Joe has hit the nail on the head.

Some of my thoughts on the requirements:

"implemented using .NET 2.0...whenever possible". IE, as an unmanaged host, has no control on what version of the CLR that gets loaded for the process. Only one version of a CLR can be loaded for a given process at a time. If the moderator toolbar were written in .NET 2.0, if another toolbar, control, etc. written in .NET 1.x was loaded into IE first, the Moderator Toolbar would be dead in the water. Similarly, if the Moderator Toolbar were loaded into IE first, any .NET 1.x toolbars or controls would be dead in the water. ...then there's the case where IE loads a separate process, which may present itself as an issue. This type of issue is known with the CLR designers; but, I don't think we'll see a solution in the CLR for quite some time. This should not detract from the power that you get from an integrated toolbar add-in, though. We may be able to get around this CLR hosting issue by having an IE toolbar "shell", that isn't written for .NET, that communicates with a central application that is written for .NET; but, more thought would be required. The benefit of an architecture like this is the integration of the toolbar with the browser is abstracted from the meat of the tool. This would allow a Firefox toolbar to be written that focuses strictly on integration with Firefox only reducing duplication of logic. And, possibly, allow the two toolbars to communicate indirectly.

Common store of data. I'm sure Knowledge Navigator is a fine application; but, for the type of information we're looking at, a simple web site seems more appropriate. For example, I've already got a method of managing code snippets, reference documentation, and other information not specific to being an MSDN moderator. Having a separate application for "canned" text, authentication, etc. seems over the top.

"Canned" replies etc. One of the issues of a "canned" reply is the "duplicativity" of the resulting post. I think we can initially resolve this by simply putting the date/time in the body of the reply. But, eventually, I think moderators should not have "no duplicate posts" policies applied to them.

Question assignment. I'm assuming this will initially be implemented by means of a column in the SQL database? Which means only moderators can see whether a question is a assigned and to whom?

I think question assignment should be part of most tasks the toolset performs on posts. For example, if a moderator wants to reply to a most, the toolset should first try to assign that question to the moderator then proceed with the reply--this would help make moderators as productive as possible by avoiding two moderators doing the same thing at the same time.

Advanced Search on Meta-data. One thing I've pointed out before and have actually complained to Google about, is the lack of ability to define what "content" is. For any given website there is content and navigation. Almost all search engines don't distinguish content from navigation. MSN search is the same. Search results with MSN search will return false positives when searched text is actually in a page's navigation. This is especially true with the dynamic nature of the Forums with areas like "Can't find the answer" and the fact that content of list pages are real-time and the indexed data that MSN search is using to search will be horribly out of date in comparison. Eventually, I think it's important to be able to search only content (i.e. body and title/subject of posts) to make a search tool more useful. Getting any quantity of out-of-date "list pages" in search results means the search tool will less likely be used. In the short-term this may require the addition of "content" meta-tags. Long term, ideally this should be an inherent feature of MSN search. Some search engines have implemented things like this with "noindex" tags. Atomz is one that I know of.

Also, the list of forums that I embedded into the Forums Search Tool was created with a series of regular expressions on the html at While doing something like this will give us the final functionality we want; it would be better to have another page/service without all the html data to filter out.

Authentication. The user needs to log into in order to be able to perform most (all?) actions. I'm not sure what more, in terms of authentication, is required. Or, are we talking about authentication to a particular SQL Server/Web Service?

Escalation to Microsoft. As I understand it, there isn't one method of doing this (e.g. the C# team has a specific, distinct, private newsgroup for this purpose). So, this may require the mandate/expansion of some Microsoft internal process.

Proceeding forward. Many of the features that will make this tool shine will require changes to the dependant web sites and applications. It would be nice if we could outline what can't be done in a first cut, what we think are the required changes to these external sites/tools (a proposal) and assign a person (or persons) to be the liaison between the Toolset development effort and these external dependencies...

Looking forward to getting this off the gound.

-- Peter
Aug 11, 2006 at 8:50 PM
Will there be any changes in dependant websites and applications to support this project? If I get the requirements right this will not happen and we should use the available web (html) interface to add features.
Aug 11, 2006 at 11:35 PM
Regarding the knowledge navigator. I am not using that application at the moment but I miss its functionality. Whenever I answer I thread I know I have already answered I usually end up searching for the answer I gave in an earlier post.

I do not see Knowledge Navigator as a stand-alone tool that I use to lookup common answers in but something that should be integrated into the toolset/browser and allow me to add and retrieve common solutions. Most important is that this is shared among the forum moderators.
Aug 14, 2006 at 8:28 PM
I think that a SideBar Gadget would be a nice addition to the toolset (for those early adopters of us out there) ;)

Also, a logical integration point would be within the windows live toolbar for IE.
Aug 14, 2006 at 11:21 PM
Does the Windows Live Toolbar allow us to do anything of the interesting things we need to do though? I'm really on the fence between just a plain-ole IE toolbar (native code using COM), embedding a browser control in a WinForms app, or trying some sort of javascript-based "stuff" through another type of IE button.

I think I'm going to start a new thread about this...stay tuned.
Aug 14, 2006 at 11:22 PM
Oh, and in response to the previous question, I really don't expect that we are going to see any changes to the live forum site to support this app. Basically, I got tired of waiting for the "latest and greatest" tools, and just wanted to build something that would help the moderators sooner, rather than waiting for the "next version of the forums", which is something I'm not willing to wait for anymore.
Aug 15, 2006 at 4:59 PM
"I do not see Knowledge Navigator as a stand-alone tool that I use to lookup common answers in but something that should be integrated into the toolset/browser and allow me to add and retrieve common solutions. Most important is that this is shared among the forum moderators."

This is exactly what we anticipate. We are looking forward to KN2 being an internationally shared database among moderators.
Aug 15, 2006 at 5:41 PM
And there is no plan to integrate it with IE at the moment since it makes extensive use of the webBrowser contral.
Aug 15, 2006 at 5:58 PM
Agreed. I pictured KN as being launched and installed alongside the moderators toolbar, and using web services/SQL hosting on the same platform. It works well as a standalone app, and we don't want to change that.