Item361: Merge two search fields into one with two submit buttons

The problem

A possible solution

---

One field with 2 buttons requires javascript. But we could use the current situation of 2 fields as the non-javascript fallback. And create something as at the bottom of GoIsSearch.

I have removed the '15 min'.

-- ArthurClemens - 30 Nov 2008

I already commented on this in prior discussions, but most users are quite comfortable and familiar with the two different boxes and use each of them for different purposes. It's incredibly handy to be able to type something in one or the other and hit enter. Adding two buttons to a single box would mean the users would have to use their mouse to click on one button or the other, depending on their intention. I'm for keeping two separate boxes. -- DavidWolfe - 01 Dec 2008

Am I right in assuming this is only a skin change? So no functionality is being taken away, and we can keep the two boxes if we wish? If so the AppliesTo field should probably be PatternSkin.

• AndrewJones - 01 Dec 2008

Using two submit buttons for one input field is considered a common usability problem. They suggest to use a radio button instead to distinguish the two options. I don't necessarily agree.

IMHO, the box should redirect to a named page if the search string matches an existing topic name and fall back to a full-text search otherwise. Rationale: if a users manages to type in the exact name of a topic, he most probably just wants to go there.

-- MichaelDaum - 05 Dec 2008

I don't agree: a direct jump on a search leads to unexpected behaviour and moves me out of control. This has happened here on the website when I wanted to search on "IRC". The direct match lead me to the page "IRC" that contained a redirect to "InternetRelayChat".

A possible solution would be to always lead to a search results page, with the exact hit at the top.

But that leads to 1 extra step (bad?) and in some cases long waiting time for all search results to appear (bad!).

-- ArthurClemens - 05 Dec 2008

A valuable feature of the current jump box is that if I want to create a topic with a certain name, I can do it with one additional click by entering the desired topic name in the jump box. Our users create new topics every day with this method. It would be a pretty big step backward to make this a multi-step process all in the name of getting rid of a single, unobtrusive and clearly labeled text entry field. The top of the screen has all that horizontal space available in it. The two separate fields don't seem to be confusing anyone, so why would you want to get rid of it?

-- Main.David Wolfe - 05 Dec 2008

Without actual user studies, it's hard to really know if there is significant confusion with two boxes. (It always makes me pause to think about which box to use. Anecdotally, users on the TWiki installation I am involved with do not use the jump box to create new topics, but again, these tidbits aren't hard evidence.) Now Google does have essentially have one input box with a "Jump" and "Search" button, though the "Jump" button is seemingly hardly ever used. (I believe I read that Google did studies on removing the "I'm feeling lucky" button, but users were so used to it, Google kept it to avoid complaints.) Regarding keyboard accessibility for power users with one box, they can always use the tab key, or a keyboard accelerator can be provided.

-- IsaacLin - 19 Dec 2008

As I asked earlier, is this for the shipped skin or for foswiki.org? If its for the shipped skin, will the functionality still be available? Our wiki has had the Jump box for so long, we cannot get rid of it. Plus a lot of people use the wiki heavily and are used to the jump box. Ours uses autocomplete and is very useful. However, for the majority of sites I understand it might be more usable to just have a search.

As a thought for this site, maybe something like typing "go:Item361" into the search box would be better for power users than the two buttons and tabbing between them (sticking with the Google like ideas).

• AndrewJones - 19 Dec 2008

I am curious about the user research that Martin and Carlo referred to in the email discussion.

• ArthurClemens - 19 Dec 2008

I'm one of those people who like the idea of one box that combines jump and search. Consider Google Chrome's omnibox, a combined address bar (i.e. jump) and search box. It just assumes that anything that looks like a URL means JUMP and anything else means SEARCH.

For foswiki, it's not that simple. WikiWords are analogous to URLs, so one might assume that seeing a WikiWord means JUMP. The problem is forced wiki words, which can look like plain text. I might suggest that since forced wiki words are not supposed to be common, one might say: WikiWords will cause a JUMP, and other text will cause a search, UNLESS some magic syntax is given - like [[force a jump to a forced wikiword]].

In this case, there would be no need for 2 buttons.

-- FilSalustri - 21 Jan 2011

Jump in Foswiki context is very different from the examples that have been pulled forward.

Jump is not just a feature where you can write a topic name. You can also write part of a topic name, a prefix or a postfix and Foswiki then suggests topic names that match.

Jump is a great feature that help us users to find topic that we almost remember the name of but not exactly remember.

I use this regularly. And when I do it is nearly always a one word prefix or postfix which is not a wikiword. It is simply a false assumption that jump is always or even nearly always a wikiword thing. If Fil's proposal was implemented the jump feature would be so cripled that you might as well remove it.

If the jump field was to be removed then it would need a fully jump compatible syntax. Like jump:someword. But that is pretty geeky. Is it really such a great deal that there are two fields? It seems more religious than based on actual facts based on user feedback from a Foswiki which has been in production for a year or more.

If you absolutely do not want the jump field, then it takes 10 seconds to remove it from WebTopBar.

-- KennethLavrsen - 23 Jan 2011