How would we like to format our keywords?

Question

For a long time, the EL&U community has had a problem. We have been unable to search for stop words (common words that are not searchable), which is "problematic since many of the questions on the site [are] about stop words."

Six months ago, the SE search engine introduced a feature that, if conscientiously implemented, would give us a workaround for not being able to search on stop words.

That feature is the ability to search for any text contained within code tags.

Theoretically, the code tags could therefore be used to enclose stop words that should not be ignored by the search engine.

Now, we have discouraged the use of code tags on the site, in part because they look ugly, and in part because blockquotes are really more suited to what we do here.

However, the argument has been made that keywords, i.e. the words we use to find the particular posts we are looking for, are essentially the "code" of our site. In other words, we could use code tags around words in the posts (particularly around relevant stop words) in order to improve the efficiency of searching because stop words enclosed in code tags would no longer be ignored.

For example, right now, you cannot easily find the question "What is the best way to explain how to choose between “its” and “it's”?" using the site search engine because "its" and "it's" are stopwords.

If we insert code tags in the body—What is the best way to explain how to choose between its and it's?—the question becomes much easier to find because we can look for "its" directly.

So if we consider marking keywords with code tags, currently keywords would be formatted thus. There exists the possibility that we can alter this formatting to something more appealing and site-specific. The question is

What is an acceptable, obvious, and standard method of marking keywords?

Some suggestions have been

• Italics
• Italics plus underline
• Italics plus bold
• Italics plus dotted underline
• Small caps
• Small cap bold italics plus dotted underline plus green plus blink
• Leave it like it already is (and perhaps stick them at the bottom)
• Make them look like regular text

Text would be tagged like it is now, by the poster or the community as we decide that it is needed for the purposes of making the site more searchable. It might have helped this user this morning, for instance.

What says the community?

Answer 1

If keywords will be listed at the bottom of a post, then as StoneyB said, who cares how they're formatted? The current behavior is fine.

If keywords will be embedded in running text -- that is, you're asking people to use <code> to flag keywords in the body of the post -- then you should not change the formatting at all. Keywords are meta-information; you don't need to present that meta-information to readers. Cluttering up a paragraph with monospaced text, over-formatted text, _{tiny text}, weirdly-colored text, etc makes it harder to read. (Yeah yeah, I couldn't exactly implement all those examples right given the limited markup permitted here.)

Answer 2

If I understand this correctly

• The SE search engine ignores a finite number of words—stop words—such as articles, particles, perhaps prepositions and copulae and so forth
• But in many cases these stop words themselves are the subject of our posts, and are precisely the key words an ELU user might employ in a search
• A cheap and easy workaround is to mark any stop words which would serve as appropriate key words for the post with code tags, which override the 'ignore' directive and include the marked stop words in the search
• There is no need to mark any word which is not a stop word
• There is no need to mark any stop word more than once in any post

If these are all true, then the issues before the community are

1. Where shall stop words be marked with code tags be entered?—in the body of the post, or at some place apart, such as at the end?
2. Who shall be responsible for marking appropriate stop words?
3. How shall marked stop words be displayed?—with the existing formatting or with some other formatting peculiar to ELU?

My votes on these issues:

1. To avoid confusing the reader, marked words should be entered at the end of the post, with the label Andrew Leach offers, as below (with or without the blockquoting)
2. The poster should take responsibility for entering appropriate Additional Keywords; but like any other part of the post, they may be added to or subtracted from by community editors.
3. If the marked words aren't in the body, who cares? Leave it as it is, and don't create work for anybody.

Additional Keyword: KISS

Answer 3

Why not treat anything already between quotes as 'searchable'? That is, in the tokenizer throw out stop words as usual except tokenize everything that is already quoted: single, double, italic, bold, code, whatever.

That way, there is no laborious editing that needs to be done by anybody by hand, no need to educate people (which will be long hard and won't benefit the writer), no annoying UI changes. There might need to be a retokenizing of all posts so far, but that is something for the developers to run once.

It seems that the OP is not about a theoretical, to-be-developed feature, but just describing an existing feature (no development at SE needed at all) that allows literal searching on text between backquotes.

My suggestion here is that when analyzing/tokenizing is done, in the character class of 'code delimiters' which currently is

[`],

the developers simply change it to

[`"'].

Answer 4

I'm one of those who never uses code markup on ELU because (1) frankly, it looks ugly, and (2) it's pretty well-ingrained on the web that "a bit of typewriter font in the middle of proportional-spaced text" is synonymous with computer code, and is thus not really appropriate on ELU. Apparently, this means that I've been unknowingly disabling the search functions every time I've used bold or italics or quotes to make a use-mention distinction.

So, if we are to start using code markup to highlight keywords, the formatting needs to not scream "I'm computer code", and the first step to that is to use a proportional font, not a monospaced one. It also needs to be differentiated from the existing bold and italic formatting, which pretty much means using color in some manner.

Another consideration is that there are people who have used the code markup on this site, and at least some of them doubtless used it because they wanted their text to look like typewriter-on-gray. So we don't want to totally change the appearance of this text; blinking green is Right Out^TM.

Thus, the best formatting option in my opinion would be to use exactly the same font as the rest of ELU, but with a gray background like the existing code formatting.

---

Edit: I took a look at the html that results from the two types of 'code' markup, and my concerns re:<pre> appear unfounded. Backticks (inline code) apply <code> tags only. Four-space indents (block-level code) apply both <pre> and <code>. This means that it should be easy to achieve the best of both worlds: use <code> to apply a background color only, without changing the font family, and use <pre> to apply the whitespace preservation as well as the monospaced font family. This would mean that people could continue to use code blocks for tabular data, while inline highlights would be much less ugly.

---

I think relegating keywords to only a section at the end of a post is bad idea. If people want to add a keyword section like that to the end of their posts, that's all well and good, but I don't like to work that much. The way I see it, this searching-in-code business would be most useful if it Just Worked, without any extra effort on anybody's part. And the way that can happen is if we switched to using backticks to mark words that we mention: instead of

Should the following use that or which?

we'd have

Should the following use that or which?

Both serve the purpose of highlighting the words that are important to the question, but only the latter is returned in search results.

(We'd still need to train people not to use code formatting in lieu of blockquotes; most of the results currently returned by "code:[stop word]" searches are irrelevant posts where somebody used code blocks instead of blockquotes.)

Answer 5

KitFox's question includes several issues that should be discussed in separate meta questions, as noted below; but first, let me suggest we say search-terms (or the gross searchable-terms, etc.) rather than keywords, as the latter is confusingly close to the question-tags concept.

Issues that deserve well-couched questions of their own:

• Whether code-formatting (backtick-delimited or four-space-indented) should be co-opted to mark search-terms
• Visual appearance of user-marked search-terms [which, if OP formatting is the guide, is the main thrust of OP]
• Whether user-marking of search-terms can succeed
• What long-term changes should be made in the SE search engine or search box to better deal with ELU-relevant searching

Regarding that fourth issue, what would be useful to me for searching ELU would be having the top-of-page search box do a Google search instead of an SE search. Conceivably, a user-selected formula could specify a search engine, SE, Google, Bing, etc., but for simplicity let's suppose the user's search text were tacked on at the end of site:english.stackexchange.com/questions and shipped to Google, as is done in the Google box on the search-tips-for-better-search-results webpage. I'd prefer to have -newest -recently also tacked on, as in the following three searches:

• for "“its” and “it's”", about 41 results
• for "“its” and “its”", about 2 results
• for "“it's” and “its”", about 4 results

Regarding that search-tips page, I should mention three problems:

• The [tag] [another-tag] apples oranges example is unclear.
• The code: prefix is not mentioned anywhere on the page.
• The “Advanced Super Ninja Search Options” section should instead be called “Ninja-in-Training Search Options”.