16 Answers
16

Yes, it's absolutely needed for non-technical audience. Google was experimenting with this on their homepage and they kept the button. People expect to click on something and user interface is always about matching people expectations.

This issue is being addressed in HTML5 spec. Once <input type="search" /> gets adopted, explicit search buttons will go to history.

WOW, that's nice to know. I always hit "Enter". Didn't even notice that Google has any buttons. Well, and I mostly just hit enter in a search field of Safari which in turn got no buttons.
–
user16878Aug 4 '12 at 1:16

3

What does <input type="search" /> do differently that addresses the issue of users expecting a button?
–
LukeNov 21 '14 at 19:13

An alternative is live/continuous search: Update the search results immediately on every button press. In addition to improved efficiency, it can also help to solve such usability problems as users typing more search parameters than are needed, users not noticing the find button, users making a typing mistake and not knowing why the search results were empty etc. 1

Of course, technically a continuous search is more complex to implement than a simple search form. In web environment, Ajax/Comet is needed, and also the server-side search must be fast. But the implementation complexity is easily justified with improved usability, if the search is a central feature.

Whatever you do, it's always a good idea to make a usability test to find out whether the users will know how to use the system, and then make improvements as necessary.

When Google reports how long it took to make a search, it's usually around 0.1-0.3 seconds. That's fast enough to implement a continuous search, so the amount of data to be searched is not a limiting factor even with full search results. It's just a matter of choosing the right algorithms and having enough servers to support the expected number of concurrent users. Where there is a will, there is a way.
–
Esko LuontolaAug 10 '10 at 18:45

I agree wholeheartedly with the above responses; I generally don’t see any advantages to not having a button, at least from a UX perspective. Having this button present meets the user’s expectations, and is often an absolute requirement to support individuals who aren’t tech-savvy.

But, I feel it's quite important to consider that the presence of a button can cause problems if it isn’t approached properly.

I ran usability testing project for an e-commerce site not too long ago, and the ‘search’ button was causing a rather nasty usability problem. As the button had been made very prominent in the design, particularly in contrast to the text entry field itself (which hadn't been well defined), many users were clicking the ‘search’ button under the assumption that it would open or display the site search, as oppose to initiate it.

As a result, many users ended up a “0 results found for (null)” page and became quite confused. We ended up rectifying this problem by making the text field more prominent, downplaying the button and changing the terminology to ‘go’ as opposed to 'search'. This rprevented and confusion or ambiguity as a result of the button.
The decision to include a button within your search field is probably the right one, just ensure that it’s fully considered in terms of design or it can end up doing more harm than good.

Before I start let me get this out of the way. The question as originally asked is not definitively answerable beyond some permutation of:

It depends, but inclusion has slightly more benefits than not.

Every answer provided thus far lays out great arguments that boil down to the same answer.

An up to date summary of the current situation:

In the 90's the search button was totally necessary.

All search functionality was executed with simple form posts. The Search button was necessary to submit the form. Results were returned on the based on the submit action of the form.
In fact, it wasn't a "search button" it was often a "go" or "enter" button. The common pattern was like this: Label/input/button

If there were alternatives, developers were rarely aware of them. Users understood the pattern quickly based on its obvious affordance.

Seeking simplicity, a new pattern emerged combining the label and the button into one element, and the search button was born:

It took three elements down to two. And the pattern became easier to understand and more entrenched in the user skill set.

Web 2.0 came around in the post bubble era. JavaScript emerged handling client side interactions and asynchronous calls.

The flurry of new search/form entry patterns we see today are the result.
Some, like auto-complete and filtering, don't require the button at all. Inline form entries are the "save/cancel" version of search. Most of these patterns employ the key command "enter" as the de-facto way of submitting search results without clicking search, go, enter, save, etc.

These new patterns take time for users to understand them in masse. But I think with two decades of internet use under peoples belts, the ubiquity of search and form submission, I think it's safe to say a large majority of people know about "enter". Take an informal survey and you will see the same. I did and everyone I spoke with knew about it.

Are search buttons still necessary in 2012?

YES. Take one look at the massive ongoing user-testing lab known as Facebook. They took away the enter button on comments and almost immediately returned it with that crazy checkbox to teach people to use enter when users complained. Even if it was only 10% of them, that means 90 million people.

I think the search button has little relevance in today's online environments but it is still and will always be necessary to some degree. So the final answer is:

This is the best summary so far, thanks. Just noting that I don't think the Facebook example is a good one, because I'm not sure the "hit enter to go to new line" is a paradigm that you find in search (which was the real problem with Facebook's change - that expectation, which is common to long-form text entry was being violated).
–
dhmstarkAug 8 '12 at 9:05

1

True, the facebook correlation is not exact. It's a text entry vs search but the spirit is the same. I should also mention the advent of placeholder text in the evolution of form design. The present state of affairs seems to be pointing to this rounded corner search input with placeholder text and a search icon in the field. It changes to an x to clear the form when text is entered. A friend got back to me on my questions. He called the search button "cheap insurance". I like that. It seems enter is always nice to have and the search button, necessary or not, will always be cheap insurance.
–
ItumacAug 8 '12 at 12:50

Fascinating question and answers. The development of UX/UI conventions is endlessly interesting... for me it is like watching the development of language before our eyes (:

I would argue that the use of a search button is something that is worth A/B testing within your particular context. Unlike some above I do think that such a tiny matter is worth investigating thoroughly. This is a key way that people access the information on your site.

Alternatively (or perhaps in addition) an unmoderated remote usability test (I am currrenly reading Nate Bolt's great book on such matters) could be done fairly cheaply. This might buy you more insights into why people find it confusing or not.

My general impression with regard to search is that the conventions surrounding it are definitely changing in 2012.

I just switched to a newer version of Safari and google search is now built into the address bar i.e. I can put search terms or URL's into the same place. This is definitely new for me and for the first couple of uses I kept searching for the google search box. But now after a few hours use it feels entirely intuitive.

Similarly the way the keyboard changes in mobile search depending on the type of data expected is a new way of supporting search which intially I found confusing... i.e. why can't I type text here (doh.. it is a telephone number search).

Equally in google search advanced users can use all sorts of search terms to focus the search.

It may well be that the conventions are changing dependent on where on a page the search box is placed. At the top of a page you might expect just to press enter whereas if the search is presented as part of a pages content then the expectation of the user is that there should be a button. But this is pure hypothesis on my part.

Test test test ... has to be the answer! We really have no other way to establish what is happening in this fast pacing techno world of ours (:

That's bad as it sends all your url to Google I guess.. I don't use Chrome, even given that it's the fastest and most advanced browser as of today because it sends all your data to G - all the urls, everything. I just don't want g to know where do I know my netbanking, where do I download my movies, etc. Nothing lawbreaking, it's just their updated privacy policy is literally "we do whatever we want with the data internally about you by using our services, including, but not limited to selling your soul, coercing you to do stuff or anything else". That's why I use safari. Up to this point.
–
AadaamAug 10 '12 at 15:58

I can't remember how long, but Opera had this feature built-in for ages, with the addition of a (user-defined) search key. I could type "g search term" into the URL bar to start a google search or "w search term" to look on wikipedia, etc. Similar thing in Firefox. In Safari, my search term is usually half typed before I remember to switch to the search box... So yes, I think this changes the way we search, but it's not necessarily new for non-IE/Safari users.
–
LouiseAug 28 '12 at 12:11

It doesn't send your URL to Google. The way it will work when something's typed into the bar is: (a) Does it start with http://? If so, go there. (Or ftp://, etc.) (b) Does it form a valid URL if I prefix http:// (and maybe )? If so, go there. (c) Give up and send it to Google.
–
AlexCNov 7 '12 at 10:39

To answer the bounty, situation in 2012 didn't change much, as there's nothing to change. However, there are special cases when a search button might be omitted:

on iOS applications, in case the action for the "Enter" key switches to "Search"

if the interface shows a list of all options by default, and the user just filters them out by typing in a searchnbox.

if your own study conducts that your users don't get frustrated by it missing on the long run.

It is important that your belief about how your users might think don't count, you have to actually conduct the studies and measuring frustration (usually, this is done by measuring their pupilla with an infrared webcam, blood pressure, pulse, or skin electricity... Please note that the way of measuring might actually make them frustrated alone). If you don't have access to such equipment, universities, larger UX shops, huge marketing companies do and they give access to it for a fee.

The reason behind is that searching is a single method which has a close down operation. This operation has to have affordance: the user should expect the interface to behave in certain ways, either by having a huge bunch of software working this way, or by having a visual clue (or visibility) on the interface.

It is not entirely impossible, that there are users out there, who expect that if an input box is completely rounded, and has "Search" written in it as a default placeholder, it works by hitting enter after the key, but how much are they representing the your demographics of your application, it can't be told for certain without extensive (and expensive) studies.

There are millions of people who have never ever used the search field in Safari or Firefox, and even more, who have never ever entered anything in a URL bar, and type in web addresses into a search engine like Google instead (which is on the default frontpage of every single browser), and if they didn't learn it until 2010, they aren't expected to have accustomed to it in the last two years.

A space-saving solution would be, to put a little magnifying glass at the left edge of the search input box, inside the box, making it clickable. This way, space isn't taken from more important functions, but users without expectations on the effectiveness of "Enter" or "Instant Search" have something to click on.

(While Instant Search might be a good idea, in practice, it didn't transform the way people search, and it can be debated, why it didn't. Personally, I still hit Enter out of reflex, so do my friends asked)

Edit (regarding to the conversation below)

This list of "assumptions" was based on the following background materials:

Normann's Design of Everyday Things, namely, his model about visibility mappings, learned behavior (to click "enter" after entering a search term is a learned behaviour, as nothing suggests it on the interface)

The GOMS model, for which a good approach could be found in Raskin's The Humane Interface

I'm sure I could quote Krug's Don't Make Me Think as well (never bothered to read it fully), or Nielsen.

However, all of this is old research. (Well, except for my Google Instant claim in the comments, which also had an English test)

So the question rephrased is: what would make these researches outdated between 2010-2012?

And to which the answer is a bit more complex.

I have only models mostly, but these models are pretty sound.

One question is, "how do people form habits" and "how do people remember usage patterns" for which the answers could be found in, for example, Weinschenk's 100 Things Every Desiner Needs To Know About People, where she explains the contemporary knowledge about such learnings.

And there, we can see it written plainly, that people learn new things if they need them to reach a goal, and they form habits if they have to do that frequently. For example, I've never learnt five-finger-typing as I'm typing fast enough this way as well)

So, our question is: was there any application gaining mainstream popularity in the target group which forced people to unlearn the habit of searching for a search button and clicking it, but using enter instead?

I don't know, I don't know the exact target group, but I guess the answer is no.

But our target group also moved. The target group of this question was people between 40-60, now they're between 42-62.

We know, that people's learning abilities degrade drastically between the age of 40-45. The researches I've read about these are originally in Russian, and were written in the 80s, when it wasn't a custom to translate them to English.

This is actually an S-shaped curve, but people who were already over 45 were unlikely to learn new "muscle reflex" habits, especially, if their knowledge on how to use a computer have served them well so far.

We shouldn't deal with people over 50 (based on the Russian research), so the question is, that at most 10% increase of people between 30-49 would account for habitual changes.

But I guess I should left this exercise for the reader. My basic assumption is, and this is an assumption, that if Norman's models are correct, and if all the quoted researches are correct, then people who didn't have to learn this enter thingy didn't learn it in 2 years, and that the target group didn't move that much in 2 years that a majority would've fallen out, then no significant changes would show up.

Honestly, I've seen things with poor visibility and mapping issues which UI developers of the 80s expected people to learn soon and that never ever happened. This includes confirm dialogs, keyboard shortcuts, modifier keys. The Norman and Raskin books are full with it, and I'm sure it wouldn't take too much to find a Nielsen rant about it either.

It's not that things didn't change in two years: humans didn't change.

To say that nothing has changed is a big assumption. I intend to test as much as I can, but do you have anything to back up the claim that you made?
–
dhmstarkAug 7 '12 at 7:56

It's like people getting used to hit ctrl for multiple selects in a selectbox: they won't learn it, ever. The power user generation didn't grow up in two years, baby boomers didn't die out. Was there any new widespread application that forced them to learn this mapping? It's just not worth the screen space to force it. Google Instant failed, there are multiple research on this, like: searchenginewatch.com/article/2128218/… - Change only happens if there is a force, where was it? How could I prove its absence?
–
AadaamAug 7 '12 at 11:24

1

Again, that's just assertion. You don't need to prove an absence, you can find sources which test for a significant change in behaviour. I've put the bounty on this in order to get sources, not your opinion.
–
dhmstarkAug 7 '12 at 11:26

That's a model-based assertion, namely, it's based on Norman's cognitive models. Past data shows visibility issues never expire. Our models are built on these researches. People didn't learn drag-n-drop, just certain demographics, we know that. Google had to add back the search button. Where is a research, which shows that users didn't get frustrated?
–
AadaamAug 7 '12 at 11:34

1

For the benefit of people here, can you please source your assertions, ideally using a link or a reference.
–
dhmstarkAug 7 '12 at 11:59

Answering based on the bounty in 2012. Already some good answers here, but I wanted to make a somewhat different point: the discussion has mostly been about whether users need to the button in order to successfully use the search. But I believe we should also think about what happens before the user takes that action.

How do they find your search? The search button can serve as an indicator. On a busy page or if your search element is non-standard place (ie, not in the top right) the visual scan to find that action may be difficult.

Of course, the importance of having that strong indicator depends on your site's intent, design and audience. Search is vital for Stackoverflow (or UX), but its audience is savvy and the design puts the search in a standard location and it's contrasted well with the background. If your audience is less savvy and/or the search is a critical path for site use, you might want to consider keeping it.

To pick on the super-awesome Stackexchange a bit, I was looking at their English Language site. Here's the search interface:

Easy for me to use, I'm very familiar with their suite of sites. But an older user who comes there looking for grammatical help? A search button could make it more clear. Though I'd argue that make the search background white would be most helpful.

Unless the question is more specific, a simple answer is not possible.
If the search yields a small number of results, then likely (but not necessarily) it would allow a live search and result interface. As you get results updated each keystroke, there's probably no need for a search button.

What is this searching for? Is it searching text in a database index (e.g. a web index), searching a library of images, etc? What the specific context is should be taken into serious consideration before a decision is made to exclude a search button. I have seen too many people of the old and new generation interface design fall into the same trap of going through the motions of design totally blinded by preconceptions.

On a separate note. When a search button is present, it helps users to connect mentally to the action of instigating a search. Besides the mind and action connection, the search button is a valueable interface element to provide cues about search progress. The button can be disabled showing that a search is underway, and the interface can show a progress bar if the search usually takes a few seconds or more. Without this clear and unambiguous time reference as pressing a search button these affordances aren't viable. Using the enter key by itself without a button in this way is nowhere near as effective.

On the purely visual side of things, the button is also a cue that the search field is not something else entirely. So the search button indirectly labels your text entry element as a search field. Some contraptions (e.g. image icons) can assist in providing such cue but the simple button does so unequivocally without having to devise other cues.

Chris.. i found this answer fairly unreadable. But I think you have some good points in there. Would you consider editing it into plain english... I did start to have a go but then was worried that I was changing your meaning. Cheers.
–
Lisa TweedieAug 9 '12 at 2:20

I would always error on the side of usability, even for technical audiences. For non-technical audiences, it can be even more vital to include it as they may not know you can simply hit enter to submit the form. The button can be styled to match the layout, so I would keep it.

The only way to know for sure, for your specific audience, is to run an A/B test - show half your users a text box with a search button and half a box without, see if there's any difference in behavior.

Be sure to read about how to conduct an effective A/B test before starting.

Or, if you don't care that much and don't want all the trouble of actually finding out, just leave the button there.

I find it hard to imagine that in any case there wouldn't be a difference for a statistically significant sample. And since the button is not an alternative but merely an addition enhancing functionality, wouldn't the effect have to be positive? I think an A/B test is going overboard for such a simple decision, in most cases.
–
Matthew ReadJul 10 '12 at 15:19

I disagree Matthew... clearly Google disagree with you too as they have done the tests (see first answer).
–
Lisa TweedieAug 9 '12 at 2:11

Semantically, a submit button is used to submit a form. Like Esko Luontola mentioned, you could skip the button if the search was continuously updated via comet server, since that's not really "submitting" the form.

But if performing a search requires that a form be submit and the page be redirected or reloaded then yes I think you should definitely have a search button since that is exactly what the submit button is intended to do.

But when you type the term, do something else and come back to the page (perhaps took a phone call or whatever) or clicked back in the browser, then you are left wondering how to action the search without a button.

If you know that you can press Enter in the field, you ought to know that you can go in the field again and press Enter.
–
Matthew ReadJul 10 '12 at 15:17

That is 2 actions rather than 1. Also how do I know to press enter if I've never done that? Yes they might work it out, but it is definately not clear UI.
–
JamesRyanJul 10 '12 at 16:17

We're talking about them pressing Enter at a later time, not about not knowing to press Enter in the first place. That's what your answer says, anyways.
–
Matthew ReadJul 10 '12 at 16:51

No we are talking about people who don't know what to do at all. Pressing enter after you type is natural so at that stage easy to guess, later you haven't just typed so it is no longer easy to guess.
–
JamesRyanJul 11 '12 at 10:36

1

It's "natural" because pressing Enter frequently performs an action and you become accustomed to it. If you don't know that Enter performs an action then you haven't become accustomed to it. I very much doubt that any real-world data would support this answer.
–
Matthew ReadJul 11 '12 at 19:21

I had a complex search form consisting mostly of drop-downs that auto-submitted whenever a form input's value changed (using jQuery). This worked well, but without an <input type="submit" /> button present, the form refused to submit when pressing enter in some browsers, until the input was blurred.

This was solved by putting a submit button hidden by CSS inside the form.
In this situation a usability problem was solved by including a submit button, even though it was hidden.

If you are intent on getting rid of the search button, make sure the search field is labelled clearly as 'Search', with a label (preferably inline, like SO) of some sort to guide the user.

I've never conducted an experiment on removing the submit button from a search field, but I have conducted one on a similarly structured form. The following should apply to search as well.

A long time ago on my website, I had a text field and button for submitting a comment. I removed the submit button because I thought that pointing and clicking at the button would waste the user's time. So I wanted to promote submission of comments by pressing the enter key. I collected stats on this change and did not see any decrease in the number of comments submitted. This seems to imply that if there is no button, people will naturally try the next best thing - hit the enter key - to submit the comment. What else are they supposed to do? Give up? No!

And do you have studies also on the demographics of your userbase? If it's a blog on UX or web design or programming, it's hardly a surprise that your users are accustomed to computers.
–
AadaamAug 5 '12 at 0:00

When you have a website which has less content to show when the user lands (e.g using a landing page to your product website), you have the liberty of using a search box as well as a search button to go along with it. But when you have got a website with loads of information spread across the page, you don't want it to add to the clutter using a search button.

Moreover, as everyone else pointed out, audience matters.

However, the thing to wonder here, are a few questions: Is a search button that necessary? Isn't it obvious? Can't it be avoided? Isn't it redundant?

I think mentioning the text "Search for stuff here" in the search box is a great way to go. You can dress it up with a magnifying glass in one side to give it the feel.