hari's WebLog

Please be careful with the "targeted" information... While I love the idea of not surfing through information I don't want, it's not much of a pain now.

I'm afraid of having to clear three filters and say "please" to find information on an item that the IDE doesn't think I need.

I love a lot of these ideas though -- there's a LOT of information out there, and its of no use to us if we can't find it. Can't wait to see previews.

Feel free to contact me if you need an experimental subject. I'm excitingly grumpy when things annoy me!

If you can seriously write an extensible framework that allows me to view my documents, while cross referencing what I'm viewing against my blog feeds, newsgroups, and possibly websites then I say bring it on.

However, I also realize the performance and bandwidth ramifications of having my SDK viewer doing a bunch of work in the background when it is possible I've already found what I needed. It will be hard to draw lines in the sand to say, "This is what I should do when a user pulls up some information." vs "This is what I should do after the user pulls up information and doesn't have what they need yet." The issue here is that the person might not know what they need, and the blog/newsgroup cross index might help them. Or it might just slow them down because the processes for the cross-index are taking up their time while they wait for everything to come back.

I think the concepts of hard information versus soft information is important here. I use the SDK viewer to bring up hard information about a class I'm working with. Additional I want samples and articles about the same things at times, but this is soft information. There is a possibility that soft information applies to my current search, while most of the time it won't.

Example: (always have to have one ;-)
Index the method ToString()

Immediately you get a huge sub-index of objects that implement ToString(). When you bring up this many results you are resorting to soft information. Programmatically you don't know what ToString() the user wants. However, you can better format the results, if not the first time the user does it, at least each additional time. Here is how:

1. The first time there isn't much you can do. Just return stuff.
2. As the user clicks on things to examine, associate those things with the keyword ToString() so they get brought up top the next time.
3. If the user is currently looking at DateTime, bring DateTime.ToString() up to the top first. DateTime.ToString() should also have meta-links to documents on formatting characters for using DateTime.ToString() and these should show up at the top.
4. If the list of results is large and there are a lot of *hard* links. Links to class library information for instance. Then in this case *soft* links should show up top of the list. Things talking about conceptual usage of ToString() or documents talking about override ToString() in derived classes.

You guys are thinking about all of this I'm sure, but it kind of goes along with your concepts of sub-indexing, cross-indexing, and only providing the user with feedback that is relevant to them at certain times. The concepts above describe one way that I might do this when I'm unsure as to what might be relavant to the user at the current time. The system is *smart* enough to provide them with results they think are actually customized to them even though you really have no clue what they are looking for.

At work I do unmanaged C++ stuff all day, and it's a huge pain when I go into MSDN and look up the doc for some Win32 API, and the help decides to bring up the WinCE version instead of the Win32 API version. If you guys can make it so that I don't have to install the WinCE docs, it would be a *huge* timesaver.

Milbertus : I hear you! In fact, that's the same example I use when explaining to folks why searching on "button" gives you umpteen types of buttons that you are not interested in. Being able to target content by filtering and other means in the "Longhorn" SDK should hopefully solve this issue

Justin : Perf is certainly something we're looking closely at. It's another area the SDK historically has not had to worry about (other than search returns speed and indexing speed), but it's one that we certainly have to consider with our new features. One option is that you get returns from the slow sites as you read the page, the page is rendered progressively, local content is immediate and as online content providers return the results of queries, the online "panes" are updated. Another option is to have the panes blank and minimised by default and the user can click on "more info on this topic", and the SDK queries the online resources at that time. We'll probably end up with a mix of the two by default, with the user empowered to turn the dial in either direction.
However, whatever we do come up with, the user should always be able to navigate away from the page at an time. The page should never wait for results to return, and the UI should (gasp!) never hang while waiting.
Philip: I see your point. Another reason not to "hide" the filters or restrict what you see is that sometimes I like "surfing" through the docs when learning a new technology. Getting targetted information is an opt-in filter and we will provide a way for you to easily clear any set filters, hopefully that will alliviate that issue.

or "a day in the life of an SDK dude"

I do not agree. Go to http://www.apartments.waw.pl

PingBack from http://besteyecreamsite.info/story.php?id=1598

話題の小向美奈子ストリップを隠し撮り！入念なボディチェックをすり抜けて超小型カメラで撮影した神動画がアップ中！期間限定配信の衝撃的映像を見逃すな