Replace the Go box by a Search box

Do we need the Go box?

WikiPedia uses a combined search/go field, and uses 2 action buttons for that. This works confusing: "Go" is used on a lot of sites to perform the search action. And each time you need to make a decision.

In GoIsSearch is proposed to create a combined search/go field with one button (or perhaps with no button). Now the behaviour becomes unpredictable for the average user, and the decision making becomes even harder as he needs to memorize the gobox syntax.

Why do we need to go directly to another topic? How often does it happen that we have memorized the page name (correctly) and it is too much hassle to edit the url we're in? You have to take this into perspective regarding the increased complexity we are bringing with a combined box.

So I strongly propose to make our lives and that of TWiki users a lot simpler, and to just put 1 box on the page, the search box.

And because we are saving ourselves time we could start working on the presentation of the search results.

• We could offer the most relevant hit (topic match) at the top.
• Offer 'search within results'
• Offer 'save search set'
• Offer a RSS feed with this search
• The topic 'summary' could be smarter to give more hints (Google like?)
• When coming from a search, we could use search term highlighting when viewing the topic

-- ArthurClemens - 14 Oct 2005

I agree.

-- MartinCleaver - 14 Oct 2005

Yes, improving the search function would be a good step.

The 'When coming from a search, we could use search term highlighting when viewing the topic' is an interesting idea. It seems to be an enhancement to bin/view. Add a parameter with a string or series of strings to highlight. Once that is added it opens up a whole new set of opportunities. There is the possibity of a higlighted 'serach within page' type functions.

-- AntonAylward - 14 Oct 2005

I agree also.

The search term hilighting has been brought up before as a RefererTricks, i.e. don't restrict hilighting only to twiki derived searches.

-- MattWilkie - 15 Oct 2005

I do not fully agree with the core proposition of this topic. While I very much like some of the follow-up thoughts on search enhancements, I think they only confuse the discussion of the core proposition and should be presented in a separate topic.

So I would like to focus on the core proposition to drop the go box entire for a "pure" search box. I don't believe it needs to be such a black and white choice and I challenge that GoIsSearch is necessarily confusing to the "average user."

Perhaps the use case addressed by GoIsSearch would be clearer if we refered to it as BasicSearchPlusJump. When presented with a small text box (without further explanation) most users would:

1. Expect it to perform a simple search on terms entered in the box.
2. Would be pleasently surprised if, when entering a single WikiWord, they were taken directly to that topic, or were presented with a list of similarly-named topics.

I don't see why this is confusing at all. It's merely your basic search box with a little added intelligence.

In irc, Arthur presented the use case that one might want to search for topics that contained the Legacy.WikiWord as an arguement against GoIsSearch. That's true, however, I would argue that that is the exceptional rather than expected use case when someone enters a WikiWord into the box - and would reasonably require utilizing advanced search. So I don't see that as a very compelling arguement against including a jump feature in the basic search.

Finally, I do use the Jump feature on occasion when I know the name of the topic I want (or think I do) because it's less error-prone than editing the url.

So, in summary, I agree that the "Go" box should be re-christened a "basic search" box. However, I would still advocate including the "quick-jump" feature represented by GoIsSearch. Furthermore, I very much support further development of the other search enhancements presented here!

-- LynnwoodBrown - 15 Oct 2005

The example I've used is: I might want to search for topics with 'bugrejected' without wanting to go directly to Legacy.BugRejected. And I (user) don't want to learn to program the search box - I want it to produce constistent results. Not to make a difference between Bugrejected or bugrejected or Legacy.BugRejected (I might not remember how the topic is spelled).

• Actually, I think Will's patch works as you describe here. I.e. it only jumps if the entered term is a WikiWord. -- LB

-- ArthurClemens - 15 Oct 2005

Sorry, but we should not discard the jump functionality by switching the box to conventional search. Granted, most users expect search, and the box should behave that way by default.

However, the jump functionality is very essential if you want to move around quickly and navigate 100K topics. There are many corporate installations that reached this scale.

So, for Dakar I propose one of:

1. Keep as is (ship with existing jump functionality) since:
   • Full text search is available (two clicks instead of one)
   • Functionality is needed to create free floating topics
2. Implement a combined search/jump feature as described in GoIsSearch. That is, for an uninitiated user the box does a simple search in the current web; and power users can use some extra syntax to get the old jump functionality of Cairo (such as j/Web.partialname). Granted, the latter one is geekish, but it is essential for navigating large TWikis, and it is hidden well enough to stay out of the way.

Since we are so shortly before the release I suggest to keep the existing jump functionality. Unless someone jumps in and implements/documents the combined functionality, and the CCRB agrees to this last minute spec change.

In regards to Legacy.MediaWiki's approach, I agree that it is too confusing for users to have two boxes or one box with two buttons. A single button is most intuitive.

-- PeterThoeny - 15 Oct 2005

actually, you'll find that the CCRB guys pretty much decided to make TWiki's defaults sensible for the majority of users. if you have 100K topics in an organistion, you've proably got a skilled twiki person looking after it, and you also are not that likely to be running a stangard un-modified pattern skin.

-- SvenDowideit - 15 Oct 2005

Let's identify what's confusing and what is not. Think about the yes/no when its presented like this, side by side

One box with no buttons that ... will perform a (basic, one word) search if the word entered is all lowercase will perform a jump if the word entered is a %TWIKIWEB%.WikiWord That's all it does. No special TwikiGeek functions

One box with no buttons that can do just about everything ... ... but you have to put a command in from of the word to tell the software what you want to do ...but this isn't made clear at the box so its only of use to TWikiGeeks rather than casual or infrequent users

One box with two buttons [Jump] and [Search] Each button does just one thing.

Two separate boxes, one for each function Each box has a clear label understandable even by casual users Each box does, as Rob Pike onec said of well designed UNIX commands, one thing, only one thing, and does it well

What needs to be resolved separately:

• What does "basic search" mean in this context?
  The "Principle of Least Surprise" holds. A sophisticated or experienced user wanting to perform a non trivial search or even go to a topic the name of which he's not sure of will use the advanced search, which should be makde availabe in the left menu bar.
  So lets take it to mean a single word, ignore case, in the body or title.
• What does "jump" mean in this context?
  We've been assuming in typical TWiki-geek fashion that it means you know name of the topic and can enter it with correct spelling and case. (Is this ReplaceGoBoxBySearchBox or ReplaceGoBoxbySearchBox or ReplaceGoBoxWithSearchBox ?)
  Google and dictionary searches offer near hits + hyperlinks if the target is not found. That is a very usable solution.

Lets focus, please, on usability, something that can be used by a casual user or soemtone who uses it infrequently and doens't want to or need to keep looking up the syntax, and not something that can only be used by TWikiGeeks or is there purely for convenience since it was easy to programme and is so lame almost everyone ends up removing it.

I agree with Peter to a degree, that one box with two buttons can be confusing. I disagree with him about two boxes being confusing. If they are clearly labeled why should they be? Many screens at Twiki.org have two boxes, one for jump, one for search: Codev is one example.

-- AntonAylward - 15 Oct 2005

I like the Jump / Search two box-separation currently in SVN, it's nifty - any chance of an access key for the two of them? Alt-S / Alt-J, perhaps?

-- SteffenPoulsen - 17 Oct 2005

I like it too. Its small, neat and clear.

I'm not worried about access keys - too many keys already bound.

-- AntonAylward - 18 Oct 2005

Access key: ENTER!

But perhaps you mean to give the field focus? TAB!

-- ArthurClemens - 18 Oct 2005

Hmmm two tabs jump, four tabs search, works in ie, works in ff .. guess that's kind of OK - if you know your initial state ;-).

But if you are filling a form, or navigated other components that manipulate focus, and you need to perform a new search, search box is any no. of tabs away.

Well, my vote goes to access keys for the boxes, I know we'll be adding them promptly if they're not included in the dist We tend to use various search plugins for ff anyway (Ctrl-k! :-)), but now that there's finally a default search right in the GUI, shouldn't we seize the day and make the boxes "hot" ..?

-- SteffenPoulsen - 18 Oct 2005

Foswiki-Task: Merge two search fields into one with two submit buttons

-- MartinSeibert - 01 Dec 2008 - 19:02

Commenting is disabled while not logged in