While coming to work today, I thought of something…
We have been using the term “Task Driven” UI for many years. But if a user sits at a computer and says “I want to Edit pictures, How do I do that?”. Most of the time end user have to navigate through start menu to find what they want. Vista Search UI also searches through the name. It does not find “Picasa” when I type in “Photo Editing”, it only finds it if I type in “pic…”. There is no way for user to know that what applications to use for certain tasks. So even though we talk about it, shell is not task driven at highest level. It is task driven if i got to explore and then i see tasks such as cut, paste depending on the context. There was a concept of categories at some point where there would be a store where app would register itself and shell can query to store to figure out something like this. Problem is to be able to provide information about app functionality in detail app authors would have to register for whole bunch of categories.
If application exposes some kind of interface (e.g. COM?) then shell can query on. This interface will expose the the description of all commands included in the application. Shell then can index all application installed on the machine through this channel and display user right application. So user can type in Start menu “Send email” and Outlook express, Outlook, Eudora could show up because they will have commands that say “send email”.
The problem is does this becomes a installer action that application will have to somehow tell shell about how to get handle to the interface. It could either through registry for MSI apps or Manifest for ClickOnce apps.