Many websites offer users a search bar to make it easy for to find content without browsing. This saves users time and effort. But it doesn’t do that when the search bar uses the ‘Go’ button for search. This creates a noisy, unnecessary mess that does more harm than good. There is a simple and clean way to do search that’ll make searching for content faster and easier.
By using a ‘Search’ instead of a ‘Go’ button, you remove the need for other labels. The ‘Go’ button doesn’t describe the user’s action clear enough, so it needs an extra ‘Search’ label. This clutters the search bar and makes it harder for users to process.
Also, the word “search” has more characters in it than the word “go”, which makes the button bigger and easier for users to click. Another advantage to using a ‘Search’ button is that it makes the search bar narrower. This allows you to place it in the top right corner without interfering with site content or logins.
When you include unnecessary elements in your search bar, it makes doing a search that much slower. Not only that, but having more elements decreases aesthetic appeal. It’s best to seek the simple approach that not only looks appealing, but enables users to find what they’re looking for fast.
Book
Affiliate
Why not just get ride of the button altogether?
Just hit enter and the search will happen.
There are potential usability issues with that, but that mostly depends on your users. If you have a tech and web savvy user base they’ll understand that hitting enter enables search, but not all users do. So, if you have a site with a range of different types of users then its best to include a button.
Why doesn’t UXMovement have a “search” button next to it’s search field then ?
I agree with Anthony. Many users don’t know that enter works instead of the click..
I agree that there should be some kind of visual clue next to the input field which shows the submit affordance. (btw this site does not have any button next to the search field)
“Potential” is the right word: it would be interesting to test a kindly feature (no search button) giving a placeholder text like “type and press enter” or a google-like instant search
Not all users with access to a keyboard know that you can hit Enter to submit a form.
Not all users have access to a keyboard (smartphone, tablet computer, etc.).
Yep, leave nothing to chance in the UX realm. I’d like to see some testing data on this but these are well made points. While “GO” is compact and common, “Search” better conveys the intented function. Thanks for sharing.
What about a search icon (magnifying glass)? Then it’s language independent.
See my previous comment to Alex. 🙂
Great tip. I have actually been looking around for tips or tutorials detailing how to create a custom simple search engine for a website. The google ‘custom search’ add on is very convenient, but is very generic. Would you be able to point me in any directions 🙂 ?
Apache Solr is a popular open-source, free choice for a site search engine. It offers a simple RESTful API and good performance. However, it doesn’t have the best documentation. Here’s a link:
http://lucene.apache.org/solr/
How about pre populating the search field with an indicator ie What are you looking for?
Well, if one is making a site for advanced computer users, the button is not needed at all. People can rather hit enter. To target a wider audience however, the ‘Search’ button is the best option.
You make a good point! It makes sense to label the button with what it does.
Any plans to do that with UX Movement? I see you have no visible submit button at all? Also from a technical point of view the label should still be present just positioned off the screen to satisfy accessibility requirements and ux for all users. May be also some place holder text in the input field box wouldn’t go a miss that disappears when the field it’s focused upon.
Seems reasonable. The only thing I’m wondering about is what happens with the text field label element. Since Accessibility guidelines require every text field to have a label right in front as far as I know, I’d like to know if you just hide it via CSS or maybe do something else? Or maybe you could provide a code snippet? That’d be great! Thanks
@xonic
For screen readers, at least, you can use a title attribute on the input itself. One place where titles tend to always be read out is in forms.
For the sighted, the button doubles as a label.
But, there’s still linear-browser-users who won’t get the title and run into the input before the button… so because those cases exist I’d possibly still have a label, pulled off-screen with CSS. Even in Lynx I don’t need the label, and even a screen magnifier user is likely to see the button at the same time as the input field.
You can match the Accessibility Guidelines with pre-filled prompt text in the input, but that has two issues: either you’re adding it with Javascript, which the user may not have, or you have it there and maybe remove it on-focus, which again means more work backspacing for users without Javascript. HTML5 has a “placeholder” attribute but that’s a ways off in cross-browser cross-UA implementation.
I am agree with this.. Shouldn’t use anymore
Good point!
I guess the modern way is to implement a nice ajaxy solution that eliminates “search” button altogether. I can see this won’t work without JS but if you don’t have JS related constraints imposed on your design, why not.
@Juho then it had better be one truly amazing web application… and as big and as popular as the broken sites people put up with like Facebook and ebay. Search is a fundamental function on websites who offer it… meaning you are taking away something important from those scriptless users.
Have a search form, let the JS remove it and replace with ajaxy stronger-than-dirt-ness. Everyone happy. : )
I totally agree with both @Alex and @Anthony. I personally would love to just get rid of the search/go button. Make some place holder text in the input box that says such.
But then I have to stop and ask myself, “Will anyone, like my mother, be able to know that enter means search?”
But I think I might be willing to get rid of the button, personally. 😀
Nice article!
Really great post. I feel a bit frustrated; wondering why I didn’t think about it before. Thanks for sharing! 😉
I agree that buttons/submit inputs with the text “go” are small and not very descriptive. But every form input should have a label in the HTML for accessibility reasons.
Non-sighted user prefer the label element because it reads the label to them in relation to the field first.
For example without a label:
User presses tab and is now focused on input.
Screenreader states “input”
Because there is no label user doesn’t know what the input is for so the user presses tab again
Screenreader states “Button, search”
User now has to press shift + tab to return to input now that they know what it is for.
With a label element and proper use of the for attribute:
User presses tab and is now focused on input.
Screenreader states “Label, Search”
User presses enter, and now there cursor is in the search field.
Label elements should almost always be used. But I do think we can do away with go as the call to action.
Note: Often I will use jQuery to take the text from the label and insert it into the value attribute of the input so that the interface is less cluttered and display the label off screen so it’s still available for non-sighted users. HTML5 has have some nice solutions for this, placeholder attribute.
I was considering “Go” for a non-search button. Specifically, the button submits a URL from the user which will result in a list of web pages related to the given URL. I could use something more descriptive, like “Find Related Web Pages”, but that’s too long. “Find Related” is also clunky. So I thought putting a 1-line description of what the button will do above, and just using “Go” as the button text would be good in this case. What do you think?
Awesome, esp if you keep the text outside the form (so screen readers in Forms Mode catch it as well). This is a good idea for any non-trivial form really: all instructions and necessary info come before the form and remain outside it. Then, GO is obviously a Submit button (heck, Submit would still be better for the reasons listed above in the article… more clickable area, has more meaning to more users) and needs little further explanation.
Simple and nice post. It’s like the “Click here” button issue 🙂
99.9% of all computer users I’ve met just hit “Enter” after typing something in a field. I am a supporter of getting rid of the “Go” and/or “Search” button altogether.
I recently worked on a project where the search box contained a nice magnifying glass image to the side, with the text “search” pre-populated in the field. You’re not gonna find anyone who doesn’t instinctively hit “Enter” when searching… unless it’s their very first time using a computer, which in that case, he/she would require a guide next to them.
Please remember that what you refer to as an ‘an ugly and noisy mess’ is one of the requirements for accessible and universal design:
WCAG 2.0 H44: Using label elements to associate text labels with form controls (HTML) http://www.w3.org/TR/2008/WD-WCAG20-TECHS-20080430/H44.html
However, skipping the label may indeed be a preferred solution in some cases, but that should be determined on a case by case basis rather than saying that we ‘should stop using’ it. 🙂
Form controls that don’t have labels will need title attribute so that the form control is not left without an identifying label:
H65: Using the title attribute to identify form controls when the label element cannot be used (HTML) http://www.w3.org/TR/2008/WD-WCAG20-TECHS-20080430/H65.html
The JavaScript jump menus and what @Alex suggested are not recommended for the same reason.
better explicit than implicit as they say, especially when a great percentage of users aren’t tech savvy
Often “Go” fits in places that “Search” will not.
It’s sometimes a toss up between a shorter text area or having the button say “Go” instead of the action.
Whatever is more important will win.
I think this is a matter of personal preference more than anything. Also, the amount of code added for the “wrong (in your opinion)” way of performing the search box is negligible which renders your “unnecessary elements to a design the result is always a decline in user efficiency and an increase in the likelihood of potential problems” emphasis moot.
Just my 2 cents…
Pretty simple, yet very effective! Nice article 🙂
In my opinion, the Search button is more applicable. Moreover, the word Search makes more sense.
Thanks for the post 🙂
It’s ironic that this website does not have a search button.
I absolutely agree with this post. As a basis, always tell your users the meaning of actions. “Submit”, “Ok”, “Validate” is to be banned instead always use “Send”, “Search”, “Publish” or “Leave comment”.
It is part of semantic web.
Well, the reason for a go button is . . . two characters!!!!
jdirt,
I’m not sure that 2 characters is a reason to use the term “Go”.
“Go where”?
Look at the author’s 2nd point regarding “Go”, it “makes a smaller click target”.
Not only is “Go” not big enough to click on, it’s a term that is not relevant to the user’s interactive conversation with the system.
There are no rules to design- only logical and intuitive best practices on a project by project basis.
Thank you for pointing this out! Using “GO” has always annoyed me. Even using submit seems arbitrary. I prefer the mag glass approach, but in truth, you should try to cater to the majority.
A very logical approach.
I never did like “Go” as it is a term that is completely out of context.
In my designs, I personally use the term “Find” to initiate a search process (along with a filter drop down menu as you have in your above pic).
Upon landing on the search results page, I use the term “Sort” to narrow down the “findings” if there is exhaustive findings.
Good short and right to the point article.
There are a lot of articles out there about this subject and it’s not always clear whether a UX recommendation is based on research, data, testing, or just intuition. Is this article based on research/testing?
I ask because companies who are known for usability testing often come to different conclusions. Amazon uses “Go.” Wikipedia, Sun Microsystems, and Microsoft both use a magnifying glass.
My company uses an arrow button (i.e., ->) instead of a ‘go’ or ‘search’ button. I believe that it was chosen because it’s not language dependent. I think conventions are needed for web sites that serve international audiences. Thoughts?
An arrow icon to me is pretty much the same as Go. If you want to use an icon that best represents Search use the magnifying glass icon.
Thanks to the windows and mac operating systems, the icon has already been established as a design convention.
Pingback: Don’t Listen to Designers // grundyhome.com
I think the point about the “can’t use the Go button without a search label” also apllies to the Search button as it should be added for accessibility and your document won’t validate. The main reason in my opinion would be clickable area.
With regards to the button stating ‘Go’ I feel this is perfectly acceptable, but not ideal. Again, for accessibility you could use alt text of “search” on the button.
unless it’s a search box on a map 😉
Much too long discussion for such a simple thing. Web developers get obsessed with stupid things, like accessibility, code purity, blah blah … Does google have a label next to their search box? No. Did apple cared much about accessibility when they designed iphone? No. Will that mindset help you get rich? Probably Not.
Jakob Nielsen’s user research findings recommend using a button labelled “Search” for keyword search, but not for parametric search.
http://www.useit.com/alertbox/20050509.html
From an accessibility perspective, the Search box needs to at least have a title that indicates what it is for. If you have a bare input element, without the visual context (i.e placement in the header), a screen reader user might not know what the box is for, until the button is passed. I use “Search Text” for the title.
ha, I will test my thought, your post give me some good ideas, it’s truly amazing, thanks.
– Murk
Interesting article and one which should be more widely known about in my view. Your level of detail is good and the clarity of writing is excellent. I have bookmarked it for you so that others will be able to see what you have to say.
This discussion is so 2005 …
Who needs ANY submit button when you have AJAX real time feedback?
And you can label the search box by putting a spyglass or similar background in the entry field.
Hi
expanding on what others have said, a label on the left (for RTL languages) is important for screen magnifier accessibility. Users start at the top left of the page and move right.
HTML5 placeholder type=search should also be considered.
Nick
We’ve just rolled out a similar concept on http://www.mendeley.com/ but using just a magnifying glass instead of the word “search”. Only been live a day, but looking forward to seeing how search frequency is effected by the changes 🙂
As a web developer and accessibility consultant who is “obsessed with stupid things, like accessibility…” I would agree that the input needs either a 1) label (hidden if you want) or 2) a title attribute. And a Search button too. These combined will make your Search facility usable by the widest audience. And if your site is any size at all the search facility is potentially one of the most useful navigation features.
Sure you can change things around with javascript if it’s available but many screenreaders have a real problem with AJAX functionality so relying on that alone may cause your site to become unusable by some people.
Agree with Justin – why not get rid of the button altogether and just hit ‘enter’ – which most users do anyhow?
Very good overview and argumentation. Changes could be so simple!
There are problems with other suggestions here:
Using AJAX:
The problem on being dependent on JavaScript is that when the user’s device doesn’t support JS or has been intentionally turned off, then the Search itself will be of no use.
‘Just Hit Enter’ approach:
Problem is that users ‘expect’ a button when submitting an input in any kinds of forms (be it search, registration, login, etc.). You’ll just be giving a Usability barrier. Even technical people themselves often doesn’t realize that hitting the Enter button would submit their inputs, how much more for non-technical ones?
‘Usability/Accessibility is stupid?’
If you are a User-centric developer, then the things that will help your users to easily access and accomplish tasks on your applications can never be stupid, be it be ‘simple’ or not.
ok, ok! that’s not a news… but you have a newer post that says that the best thing to do is having your search button right aligned. That’s confusing… On your site you don’t even have a search button! so what after all is the best option?