The Portable Freeware Collection Forums

I have added a new "Keywords" field to help improve search results:

Put keywords here separated by spaces to improve search results. For example, if the title/description contains "Q-Dir", it will not appear in the results when the user searches for "qdir" or "q dir". This is due to strings shorter than 3 characters being ignored by the MySQL search engine. So in this example, putting "qdir" in the keywords field will help the entry appear in the results when the user searches for "qdir". The content of this field will not appear in the entry listing at all.

I have updated the entry for Q-Dir, so seaching for "qdir" now _will_ bring up the correct entry. This beats searching for "q-dir site:portablefreeware.com" in Google, I hope.

I have also moved the "Additional features" field to the "Optional fields" section. Hope it doesn't confuse anyone...

Great!

"findability = usability" in TPFC's case. Thanks for all your work and the generosity towards the community.

Andrew Lee wrote:I have just added two new search options:

- Search for private entries aka "[#]"
- Search for public + private entries aka "[@]"

Thanks for this update
Now a search for "Q-Dir" works again

Could the "Keywords:" values be displayed (in "Full view" mode) for each item Database entry, alongside "Categories:" and other item descriptors ?

__philippe

__philippe wrote:Could the "Keywords:" values be displayed (in "Full view" mode) for each item Database entry, alongside "Categories:" and other item descriptors ?

__philippe

The field is really only intended for improving search results. For example, "qdir" is the only keyword of Q-Dir.

SYSTEM wrote:The field is really only intended for improving search results. For example, "qdir" is the only keyword of Q-Dir.

Precisely, the more relevant keywords germane to the target program are included in the DB, the more likely searches will return appropriate matching hits.

For instance, in the Q-Dir specific case, including additional keywords such as "file search" , "file management", "folder search", "folder management" "favorites search"(...and so on) would increase the likelihood of matching results for the person seeking that particular kind of file management programs.

Searches criteria constrained exclusively to keywords derived from program names (Qdir,Q-dir...), or variations thereof, appear too restrictive, IMHO.

This latter narrowly defined kind of search implies one already knows the (approximate) program name sought after, and simply needs further detailed specifications about that very program, while the former variety of searches are about broader subject / categories queries, better served by pertinent keywords or tags labels.

__philippe

__philippe wrote: Precisely, the more relevant keywords germane to the target program are included in the DB, the more likely searches will return appropriate matching hits.

For instance, in the Q-Dir specific case, including additional keywords such as "file search" , "file management", "folder search", "folder management" "favorites search"(...and so on) would increase the likelihood of matching results for the person seeking that particular kind of file management programs.

Searches criteria constrained exclusively to keywords derived from program names (Qdir,Q-dir...), or variations thereof, appear much too narrowly stated, IMHO.

__philippe

First, database search searches within the description as well. Usually the description contains enough keywords already. (In the case of Q-Dir, the word "file" was mentioned in the description but the word "manager" wasn't. I added the word "manager" to keywords of Q-Dir: now Q-Dir will show up when you search for the phrase "file manager". )

Second, because keywords are separated by spaces, they can't currently contain spaces. (Of course, it's possible to use the keywords "file folder favorites search management", which would give mostly the same result as your example. [But in that case you wouldn't want keywords to be visible to anonymous visitors. ])

@system

Ah ! Thanks for the clarification, didn't realize the DB engine was already indexing every term (short of usual stop words, presumably) extracted from a program entry narrative.

But in that case, why bother with Keywords at all, a carefully worded description could include all index terms one would deem appropriate, no ?

About Keywords separators: (not really proposing to change the current search syntax, honest...)
but, theoretically, additional separators "might" be defined as "," (comma) , ";" (semi-colon) or what have you, in order to accommodate several multi-terms Keywords such as "file management".

Alternatively, compound Keywords, useful as they are, "might" be banned altogether, and restricted to multiple terms united by "_" (underscore) such as in "file_management", for instance.
(but again, this is just idle musings...)

And lastly, I must admit the intended irony of your last sentence is lost on me:
why should anonymous visitors be prevented to see pertinent Keywords values ?

__philippe

SYSTEM wrote:The field is really only intended for improving search results. For example, "qdir" is the only keyword of Q-Dir.

Yes
Or, for example, in case of µTorrent: utorrent youtorrent

__philippe wrote:For instance, in the Q-Dir specific case, including additional keywords such as "file search" , "file management", "folder search", "folder management" "favorites search"(...and so on) would increase the likelihood of matching results for the person seeking that particular kind of file management programs.

For this we have "Category:"

__philippe wrote: But in that case, why bother with Keywords at all, a carefully worded description could include all index terms one would deem appropriate, no ?

I think it would be additional work to try to include all relevant words in the description.

__philippe wrote: And lastly, I must admit the intended irony of your last sentence is lost on me:
why should anonymous visitors be prevented to see pertinent Keywords values ?

__philippe

IMHO,

Keywords: file folder favorites search management

would simply not look good.

Deferring to System's and Checker's authoritative answers, I gather the "Keywords:" field was initially introduced for the express purpose
of disambiguation (is there really such a word ? ) of variations in program names spelling , correct ?

If that was indeed the original intent, should this be enshrined once for all as an inflexible rule, or could the initial purpose be somewhat relaxed to allow new pertinent keywords to describe essential program functions, but not included in the primary description ?

And finally, provided the above "relaxed usage" is acceptable, why not also display the Keywords values themselves ?
(which was, BTW, the sole purpose of my inoffensive original query ...

Could the "Keywords:" values be displayed (in "Full view" mode) for each item Database entry ?

(As an aside, without even considering the relative performance merits of Full Text vs Keywords indexing / retrieval,
Keywords are supposed to improve retrieval precision, particularly if the keyword list includes a term missing from the search target full descriptive text.)

__philippe

__philippe wrote:Deferring to System's and Checker's authoritative answers, I gather the "Keywords:" field was initially introduced for the express purpose of disambiguation (is there really such a word ? ) of variations in program names spelling , correct ?

Correct, see:

Andrew Lee wrote:I have added a new "Keywords" field to help improve search results:

Put keywords here separated by spaces to improve search results. For example, if the title/description contains "Q-Dir", it will not appear in the results when the user searches for "qdir" or "q dir". This is due to strings shorter than 3 characters being ignored by the MySQL search engine. So in this example, putting "qdir" in the keywords field will help the entry appear in the results when the user searches for "qdir". The content of this field will not appear in the entry listing at all.

SYSTEM wrote:

Keywords: file folder favorites search management

would simply not look good.

Fully agree
And: For clearer specification of a software we have the subcategories (Additional features:).

__philippe wrote: If that was indeed the original intent, should this be enshrined once for all as an inflexible rule, or could the initial purpose be somewhat relaxed to allow new pertinent keywords to describe essential program functions, but not included in the primary description ?

Right now, because keywords are not displayed, improving search results is the only useful thing keywords can do. I have used not only variations of program names but also words people may search or even actually have searched.

@Checker

Checker wrote:

SYSTEM wrote:

Keywords: file folder favorites search management

would simply not look good.

Fully agree

Ahem...may I kindly point out that that the above comical loose suite of disparate keywords, taken out of their context,
is not quite what I first suggested as an exemple, but rather System's own free whimsical rendering of my original compound_keywords suggestion :

__philippe wrote:For instance, in the Q-Dir specific case, including additional keywords such as "file search" , "file management", "folder search", "folder management", "favorites search" (...and so on) would increase the likelihood of matching results for the person seeking that particular kind of file management programs.

Not trying to quibble for the sake of argument, mind you, just nitpicking about chronological order ...

__philippe

__philippe wrote: Ahem...may I kindly point out that that the above comical loose suite of disparate keywords, taken out of their context,
is not quite what I first suggested as an exemple, but rather System's own free whimsical rendering of my original compound_keywords suggestion :

What I tried to say is that if spaces in keywords won't be allowed (Remember: talk is cheap, but Andrew needs to do actual work if he'll implement any of this), each entry will have a "comical loose suite of disparate keywords" that you don't want visitors to see.