Re: [OT] but funny - windows explorer can't search in html files

"Joe Schlobotnik" <schlobotnik.20.rj@xxxxxxxxxxxx> wrote in message
news:weCdnTrhXZBaXeXenZ2dnUVZ_tqdnZ2d@xxxxxxxxxxxxxxx
>>
>> It does exactly what it was designed to do. Poorly designed, perhaps,
>> but not broken.
>>
>
> Semantics. Fine, if you don't like the term "broken", smooth it over with
> "poorly designed". The fact is, people are frequently confused and misled
> by this "poorly designed" search tool. I have had numerous people ask me
> why Windows search doesn't find get hits on files they *know* contain the
> text they just searched for. Should I send them to the Windows design
> documentation? Or just point them at a tool that will do what they
> expect?

If a user asks you why Windows search doesn't get hits on files they
*know* contain the text they just search for, you should point them at a
tool that will do what they expect. It seems like you're implying that I
suggested that you should send them to the Windows design documentation. I
didn't.

If a user asked me how to make parts of the text bold and other parts
italics in Notepad, I wouldn't tell them to go read the design document of
Notepad; I'd point them to another tool (e.g. Wordpad) to use instead.

And if someone came on a newsgroup and complained about Notepad because
it can't handle bold and italic text, I'd point out to them that that is not
what Notepad was designed to do. That's not to say that the user should live
without the feature; what I'm saying is that if they want that feature, they
should use a tool other than Notepad.

>
>>
>>>I start up something like Google desktop search, Agent Ransack, etc. etc.
>>>and they all find the content I search for. Gee, they seem to work just
>>>fine. :-)
>>
>>
>> Never heard of Agent Ransack before, but I know Google also uses the
>> "filter" system discussed above. It just so happens that you've got an
>> HTML filter installed for Google but not for Microsoft Explorer.
>
> Interesting. I didn't install anything called a filter. Nonetheless, by
> default these tools find things that are there, Windows search doesn't.

Taken literaly, fine, you didn't install anything called a "filter".
Instead, you installed something called a "Google Desktop Search Plugin".
http://desktop.google.com/developer.html read the part, in particular, that
says "You can write a search plug-in to enable users to search: [...] Files
from iTunes, Wordperfect, StarOffice, or any other file format".

My point is that Google's Desktop Search system, just like Apple's and
Microsoft's, is based entirely around adding in modules that add support for
file format. In a previous thread, you complained "Don't dictate what is and
isn't considered content for the user", but this is the most reasonable
design when it comes to file system search so far.

Google's plugins index a different set of file formats than Window's.
They both have the same underlying architecture though.

Like I said, if you like Google Desktop Search better than Window's
search, then by all means, use Google's software. But if you think Google is
somehow magically able to parse all file types, then you're kidding
yourself. I just wanted to clear up that technical aspect. I personally
don't care what software you use, nor what software you recommend to your
friends.


>>
>>
>>>If you're description of how Windows search works is accurate, then it
>>>seems like this hinges on Windows making some decision about what
>>>qualifies as "content" in a given file type. Please don't tell me what
>>>qualifies as "content"...I'm the user, I'll decide what's "content" in my
>>>world.
>>>
>>>This need for a "filter" also implies that file types about which
>>>Microsoft has no knowledge (or interest) won't have a filter, and thus,
>>>by default, won't be searchable. Ridiculous. And broken.
>>
>>
>> This "filter" approach is also used by Apple and Google. If you've
>> got a better solution (scan every byte of every file?) then go ahead and
>> propose it. But without a better idea, this criticism isn't very
>> constructive.
>>
>
> I believe I did propose a better solution. I showed how to change the
> Windows search approach to something that more naturally fits a user's
> expectations. I also suggested a couple other tools that already work in
> the way users expect, without requiring the user to know about the
> existence of these "filters" about which the user is not told.

What is your change to the windows search approach to something that
more naturally fits a user's expectation? It wasn't clear to me. Is it to
scan every byte of every file?

As for your second suggestion, "use a differen tool", okay fine. I agree
that that is a possible solution, so I assume we need not discuss that issue
further.

>
>> Also, it's not only Microsoft who can write filters. Adobe, for
>> example, bundles a PDF filter with their Adobe Acrobat package. And
>> Microsoft publishes the API for the indexing service, so anyone with COM
>> programming skill can write a filter:
>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/indexsrv/html/ixufilt_9beb.asp
>
> Great...so if you're technical, you can fix this problem. I don't think
> that'll provide much solace to the average user who's simply looking for
> text in the files on his machine.
>
> Confused user: "I tried to search for a phrase that I'm fairly certain
> exists in at least one of my files but Windows said no files contained
> that phrase."
>
> Tech suport: "Yes, that's what it's supposed to do. You must not have an
> appropriate filter for the type of file you're interested in."
>
> Confused user: "Um, I don't know what a filter is, but I need it to find
> text in any of my files."
>
> Tech support: "Please turn to page 1 of your COM programming manual..."
>
> Confused user: >click<
>

You seem to be confusing two different issues here. One is "What should
a user do if they want to find contents in files for which they don't have
the appropriate filter installed?" The answer was, as we agreed, to use a
different tool (or alternatively, to download the filter).

The other issue, the one I was trying to address, was the statement
"This need for a 'filter' also implies that file types about which Microsoft
has no knowledge (or interest) won't have a filter, and thus, by default,
won't be searchable. Ridiculous. And broken."

Your inference was false. I was pointing that out. And rather than
expecting you to take my word for it, I gave evidence that it was false.
That's all. Nothing was implied about what a user should or should not do in
those paragraphs.

- Oliver


.

Relevant Pages

  • Re: I recommend this analysis of Dembskis "No Free Lunch"
    ... Dembski has written a number of books defending Intelligent Design. ... The best-known of his arguments is the "Explanatory Filter", which is, ...
    (talk.origins)
  • RE: Record Form
    ... NOT have the 'data entry' property set to yes, then it should display all the ... records displayed) is a filter. ... Look down at the navigation buttons and see how many ... form in design mode and, on the data tab of the properties window, check the ...
    (microsoft.public.access.gettingstarted)
  • RE: Record Form
    ... "Rhianne" wrote: ... records displayed) is a filter. ... Look down at the navigation buttons and see how many ... form in design mode and, on the data tab of the properties window, check the ...
    (microsoft.public.access.gettingstarted)
  • RE: Record Form
    ... "Rhianne" wrote: ... records displayed) is a filter. ... Look down at the navigation buttons and see how many ... form in design mode and, on the data tab of the properties window, check the ...
    (microsoft.public.access.gettingstarted)
  • Re: [OT] but funny - windows explorer cant search in html files
    ... If your "end-users" don't care about tags, then they won't search for them. ... He's not going to care to hear about filters, whose existence is not evident in your tool. ... If it doesn't have a filter for .HTML files, it simply doesn't know what .HTML files are. ... I have had numerous people ask me why Windows search doesn't find get hits on files they *know* contain the text they just searched for. ...
    (comp.lang.java.advocacy)