Community Relations Archive

First of all, it's great to see a specific section for messages related to forum issues. Well done!

Now that we have the official place to put suggestions,here's alist ofsome changes and fixesto the Advanced Search feature thathave the potential to help us communicate more effectively.

1. DATE SELECTION

Thiswould return only messagespostedbetween twouser-specified dates.

The GUIwould consist of two datefields and the appropriate labels. If a date is entered into the first datefield (preferably from a calendar popup box, which would eliminate data entry errors), it is used as a starting date for returned messages --only those messagesposted on or after the given date would be returned by a search.If a date is entered into the second datefield, it is used as a final date for returned messages -- only messages between the two dates (inclusive) would be returned.

Appropriate error handling logicwoulddeal withthe case of a date entered into the second datefield but not the first, and the case ofa date entered into the second datefield being earlier thana date entered into the first datefield.

2. UNREAD MESSAGE SELECTION

This wouldreturn onlythose messages which the user has not yet read. By itself it wouldn't be very useful, but in combination with some other specifications it could help reduce the time spent searching for messagesthe user mightwant to reply to.

The GUI would consist of an "Unread messages only" checkbox. Checking this box would activate a test that checks whether a message hasbeen read by theuser who performed the search. If the check box is selected (checked), and the message has not been read by the requesting user, it is returned; otherwise it is not returned.

This checkboxwould be unchecked by default. A nice-to-have featurewould be for this checkbox to"remember" the user's preference between sessions.

Another nice touch would be touse theiconsdisplayed next tothread titles oneachforum's header page (the open/closed/arrowed "file folder" icons) in front of returned messages. This would be another effectively way to tell the user whether or notshe's read a messagereturned by a search.Currently you can tell whether a message has been read or not by the brightness of the returned message'stitle, but thiscan be hardto read. The thread icons would make this information much more obvious.

3. MULTI-WORD(PHRASE)SEARCHES

This feature wouldallow searching for multi-word phrases, rather than justconjunctions of individual words.

Currently if you enter multiple words into the "With all the words" text field on the Advanced Search page, you get every message that hasall of those words no matter where they occur in the message. Sometimes that's what you want... butusually it's not.

What I'm looking for is an addition to the Advanced SearchGUI that would bestructuredasthe label"With the exact phrase"and a text field. Anything you enter into this exact phrase textfield would be searched for within messages as (surprise!) a single phrase exactly as the user entered it, spaces and all.

Consider the current "With all the words" field.If you enter "smart bomb" into this field, a message that includes the following sentence would be found: "They made a movie fromGetSmartcalled 'The Nude Bomb'." The thread containing this sentencealmost certainly has nothing to do with what the person who entered "smart bomb" was really looking for because the text entered in the search field isnot being treated as an exact phrase. Any message that has those two words anywhere will be returned.

With an exact phrase search, the above sentence would not be found, but "They dropped a smart bomb down the chimney" would be found, which is probably part of a thread much more closely related to what the searcher really wanted to find. This whole-phrase searchcapabilitywould be a huge help in cutting down on the number of completelyirrelevant messages returned from a multiwordsearch.

4. IMPROVED RELEVANCE SCORE CALCULATION

Currently, the calculation for (or display of)relevance scores in search results is not working properly. Every single message returnedfor every search is scored at100% (or occasionally 99%).

Multi-word searchesshould have a much broader range of result scores. If I search on"vehicle speed" in the "With all the words" text field, messages that have the exact phrase "vehicle speed" ought to be scored at 100%, while messages with both the word "vehicle" and the word "speed" separated by other words ought to receive scores considerably lower than 100%. In an exact phrase search, only messages with the exact phrase "vehicle speed" somewhere in them would be returned at all, so every message returned should have a relevance score of 100%.

In a "With zero or more of the words" search, messagescontaining both ofthe submitted words exactlyas entered("vehicle speed")would be scored at 100%; messages with both the words separated by otherwords would be scoredbetween (say) 50% and 80%; messages witheither but notboth of the words would be scored at between 20% and 50%, and messages with neither of the words would be scored at 0% (and thus would not be returned at all).

This scoring calculation doesn't have to use fuzzy logic (although that would be effective). A simple distance calculation would be far superior to the completely dysfunctional scoring system we have now.

It also doesn't need to use Soundex codes, although that might be useful as well.

I would be happy if any of these suggestions were implemented by the good folks at Lithium. If SOE could help to encouragethis, I'd be grateful.

If anyone else has suggestions for ways to improve the Advanced Search feature, this is the place!

--Flatfingers

---

1. DATE SELECTION

Thiswould return only messagespostedbetween twouser-specified dates.

The GUIwould consist of two datefields and the appropriate labels. If a date is entered into the first datefield (preferably from a calendar popup box, which would eliminate data entry errors), it is used as a starting date for returned messages --only those messagesposted on or after the given date would be returned by a search.If a date is entered into the second datefield, it is used as a final date for returned messages -- only messages between the two dates (inclusive) would be returned.

Appropriate error handling logicwoulddeal withthe case of a date entered into the second datefield but not the first, and the case ofa date entered into the second datefield being earlier thana date entered into the first datefield.

---