Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

What are the pros and cons of having a label like "Search:" before vs. inside the searchbox? Here are examples of the messages/labels being inside the box:

http://blog.publicobject.com/2006/09/all-vista-search-fields.html

I came up with some pros:

  • uses less space
  • when the message inside changes, for example because of some other criteria ("search files" vs. "search pdf-documents") the ui-arrangement wouldn't have to change.

The only disadvantage i saw is that as soon as text is typed the message vanishes. Which in my opinion is fine for search-fields, since their location usually makes their meaning clear, also they often contain a search-logo.

Having the message inside the field in a input-form is less ideal, in my opinion. Classical Problem: 'Did i type in my name in the town field and vice-versa now?'.

share|improve this question
1  
Are you talking about search or input fields here? Your last point has lots of merit for input fields in a form but is almost irrelevant for search forms since there should only be one, clearly separate, search field on most pages. –  Ben Brocka Jul 8 '12 at 17:42
    
My question came up when designing (or rather coding) a (instant) search-field. –  Fabian Zeindl Jul 8 '12 at 19:21
add comment

3 Answers 3

up vote 9 down vote accepted

Baymard Institute published an article just a month ago (June 6, 2012) on what they call "false simplicity".

The first item on the list is called "loss of context", which means removing UI elements, such as hierarchy indicators, navigation history, labels, etc. And their main example is placing labels inside form fields, especially in e-commerce setting. They also mention their earlier study where they have observed users correcting mistakes in forms by clearing the entire field to see the label.

That being said, there's one key difference between a checkout form (or any other multi-field form) and a search box: the number of fields a user has to fill out. When there's just one field (the search query) and a clearly labeled action (search) associated with it, there's far less chance of losing context.

mockup

download bmml source – Wireframes created with Balsamiq Mockups

Moreover, not all search forms are created equal. Some search methods ("instant" in particular) don't need the dedicated action button, while other situations (e.g. extremely novice users) require the complete form.

share|improve this answer
add comment

The problem here is you're losing context. Make it really, really clear your search bar is a search bar and the slightly lower context afforded shouldn't be a big issue. See Twitter's search bar:

enter image description here

Since there's still the typical Search icon in there (which functions as the submit button), and it's in a separate, dedicated location, it's quite easy to tell this is the search field, even after you've put some text into it. Most of the time you're not going to lose context with a search field anyway; you enter the search term and you hit enter/click the search button.

Using placeholders as labels is much more dangerous for multi-field forms of course. But for a simple search field you can create some very strong context which makes it quite difficult to interpret your search field as anything else.

share|improve this answer
    
Though you make a valid point, this was already pointed out in the question. –  Koviko Jul 29 '12 at 12:53
add comment

It might be worth looking at this article for an alternative point.

Why Left Search Buttons Perform Faster Than Right Ones

The key take-out quote:

Users have to visually fixate longer and more times to carry out a search when the search button is on the right of the text field. This takes users more time and work to do a search. Placing the search button on the left of the text field, however, reduces visual fixations and the time it takes for users to do a search.

However a counterpoint is that the conventionally used pattern of having the button on the right hints at the order in which the action is meant to be performed. Enter a query then search. Techniques like live search and auto-complete sometimes disrupt this flow however.

share|improve this answer
1  
I really don't buy his argument - I would suggest that the counterpoint holds much stronger in this case, since the alternative confuses users for a theoretical gain that is at best less than a second and at worst actually slows the action down. –  dhmholley Jul 9 '12 at 9:50
    
@dhmholley My gut feeling tells me that many users perceive a search box and button as a whole. They recognise the shape and pattern first. Some users might read the label or button to verify however if it is designed in an expected way and places in an expected spot then analysing the perception of the elements separately might not be as valid. –  Jay Jul 9 '12 at 9:59
    
I have to agree with dhmholley here. When you look at it purely form a visual point of view it makes sense. But when you look at an interactivity point of view, it feels wrong. I have to add I never use the search button. I just slam the enter key. But even then, the search button must be to the right of the search box. –  Bart Gijssens Jul 9 '12 at 12:37
    
I share that opinion. Just putting forward a relevant alternative argument. –  Jay Jul 9 '12 at 12:42
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.