The following is a guest post by Brin Wilson of WinningWP. Brin wrote to me wanting to do a little advertising for his site. I of course would happily accept that, but even better, since Brin is a tech writer anyway, why not write a guest post. That’s always a win-win, and since he had a good idea anyway… take it away Brin!
If you’re reading this, my guess is you’re someone who cares about user experience. Like me, I’ll bet you’ve probably spent countless hours trying to perfect every last detail of your site: from ensuring everything looks as it should on numerous different devices to creating either an entertaining and/or a helpful 404 page! But have you ever considered what happens when people search your site using the search functionality you’ve provided (i.e. usually a simple search box located somewhere near top of the page) but inadvertently hit enter without having actually typed anything?
Looking around the web, there appears to be no real consensus on what should happen in this particular edge-case scenario. Indeed, even the vast majority of industry-leading web design blogs seem to give no real consensus on what should or shouldn’t happen!
Some Examples of Empty Searches
Reload / Redirect to Homepage
Familiar examples include: Web Designer Wall and the Team Treehouse Blog.
In these cases it’s likely a WordPress theme that is 1) using default WordPress search and 2) missing a search.php template file (or the template is essentially the same as the homepage). So, the default homepage will be loaded with no search filter, meaning no filter is applied and you’ll see whatever is normally on that page. It’s not very clear what is going on.
Do Nothing
Familiar examples include: Codrops and Sitepoint.
The search box simply does nothing and/or closes itself.
Nothing Searched For / Nothing Found
Familiar examples include this very site, i.e. CSS-Tricks and, in fact, currently my own site WinningWP.
A default result appears quoting whatever the user has searched for (in this case nothing), and no results are shown. Kind of the opposite of the first examples where because there is no search filter, everything is found. But you’re also on a clear search page so some action has happened.
Nothing Search For / Everything Found
Familiar examples include WebDesignerDepot and Code Tuts+.
A list of the most recent posts appears.
Completely Blank
Familiar examples include Smashing Magazine and Designmodo.
A completely blank list of search results appears.
Borked
Familiar examples include TheNextWeb and 1stWebdesigner.
The page just looks (or says) it’s broken.
A better result
So what should be made to happen? Well, using the attribute ‘required’ would arguably go along way towards improving the user-experience in browsers that support this part of HTML5.
<input required type="search" name="q" id="q">Thereby simply stopping the users with more-modern browsers from even being able to perform a blank search in the first place (as exemplified by the empty-search-box-behavior over on Speckboy Design Magazine). Here’s a complete form example:
<form id="search-form" action="/search-results/">
<div>
<label for="q" id="search-label">
Search
</label>
<input required aria-labelledby="search-label" id="q" type="search" name="q" class="search-field" value="">
<input type="submit" value="Search" class="screen-reader">
</div>
</form>
required because it seems like an easy/obvious improvement.But what about non-supporting browsers? Is this good enough? And more to the point: can we do better?
Personally, I’m of the opinion that these types of empty search-box searches could perhaps best serve the user by being made to return a result that tells the user they’ve conducted a search but somehow or other managed to leave the search box empty. Perhaps in a kind of humorous-404-page style. Although, that said, I realize this might be going overboard and would probably be a bit inappropriate for some websites.
Perhaps one of the nicest user-experiences (suggested by Chris after seeing the first draft of this post) could be provided by taking the user to a really well-designed full-page search experience: perhaps with the addition of some suggested popular search terms.
Or maybe the blank search is just too much of an edge case to worry about, especially on sites with relatively low traffic.
Any other suggestions for what best to return when a user leaves the search box empty? Is there some chance the user just clicked search on accident or had another assumption about what it would do? Thoughts?
“Here’s some of the most popluar search terms:” ought to be “Here are some of the most popluar search terms:”
“Here’s” or more fully “Here is” refers to a single item.
It ought not…
http://english.stackexchange.com/questions/54682/heres-plurality-question
I think you should check the link you posted and read it all the way to the bottom, minus the very last one which is just incorrect.
If you take the sentence-
-and truncate it to-
-it means, quite literally-
-and that is just wrong.
Former English teacher here. OP is correct.
The key parts of the sentence: “Here’s
some ofthemost popular searchterms”With “here’s” being a shortened “here is,” we have:
“Here is the terms.”
That’s incorrect.
So no one caught that Mnesikles had a typo in his grammar nazi post??! No offense, Mnesikles! :) When I re-read both sentences, the funny thing is that was the only thing I noticed! I didn’t even notice you changed
Here'stoHere are! Lolz.Do you guys(Brin & Chris) happen to have any numbers on that? I usually handle it some way or another but it does seem like an edge case scenario that’s probably tried out by someone who has no intention to do a real search.
Setting required makes a lot of sense to me. However, it could for example be improved by a simple scripted balloon that tells exactly why search won’t work and provide alternatives like a link to a sitemap.(<3 required but I often hear that people don't find it helpful/descriptive at all)
I don't really like providing popular search terms. I could be wrong but the 5 most popular search terms are probably still not even 5% of the total amount of searches done on most websites. Making the added text just noise on the page.
What if you just display a random article/subpage of the website?
(Just an idea I’ve got misinterpreting the first gif.)
That’s a cool result (in my opinion) as long as the user didn’t forget to insert a search term. But when he hits enter accidently it would be more user friendly if he just sees a friendly reminder to enter a search term…
So maybe you should really display this hint. But a random article button is no bad idea at all. ;D
I can definitely see that working as part of the full-page search experience. Along the lines of “You didn’t search for anything, here’s a big search box if you want to try again, or otherwise why not check out this randomly selected article?”
I’ve typically opted for the full-page search screen, but never considered the idea of intentionally giving a random bit of content. Seems like a smart way to use up that whitespace!
Nice post, Brin. I like the
requiredtechnique at least as an easy progressive enhancement way of handle this.As a side note, I’m not an accessibility expert, but I’m 90% sure that the
aria-labeledbyattribute in the code example is redundant. ARIA is meant to mimic the inherent accessibilty features of existing HTML elements. In this case, theelement provides all the accessibility you need. Its always best to just use the correct elements sans-ARIA when possible. `aria-labeledby` is useful for fields with multiple labels, non-labels, and some non-form use cases.Bah. Formatting got messed up. (It looks like using inline html elements, even when wrapped in ticks, doesn’t work.) That last section should read:
I saw that too. It looks like it fills the niche scenarios of a non-label label, or a one to many where the label is for multiple widgets. Mozilla says it’s for typical form elements but then gives an example of it being applied to a div.
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-labelledby_attribute#Notes.C2.A0
If a label is not associated with an input element, widget or group, it will not be read by a screen reader.
Relevant reading: “ARIA in HTML – there goes the neighborhood”:
My instinct (no numbers to back it up) is that pressing enter on an empty search field is nearly always a mistake, so the general rule should be not to navigate away from the current page. The only possible exception might be if you have a dedicated “Advanced Search” page, you might redirect to that.
The
requiredattribute achieves this, in supporting browsers. But a custom client-side validation script might be better, since then you could add a more meaningful pop-up message. This could be particularly helpful if you are using a very minimalist search box (like the current CSS-Tricks design), where there is a possibility that the user may not have caught on that it was a search box.If you have reason to believe that people are intentionally using a blank search to get a list of all posts, you could always add a direct link to that result in the warning message that displays after a blank search.
I’ve made empty searches before. I really truly appreciate “Nothing Search For / Everything Found” scenarios… perhaps I hit an empty search out of curiosity of what would show up, perhaps I did it to get away from whatever gaudy/distracting content was on the current page. It’s a great way to show promoted or popular content. Just off the top of my head, I kind of like the idea of showing previous searches done or pages viewed (like Amazon reminding me of things I’ve looked at and haven’t added to my cart yet).
What about disabling the search button/enter key with javascript so that it won’t even try to search if there’s not text in there?
This is what I was thinking.
My blog is hosted on Blogger (CMS) when I left my search engine blank, thw result came all the recent.
I think that when a visitor enters an empty search, the page should just… do nothing, because nothing has been entered.
The require technique is fine for that, providing a little extra help. For the other browsers, the submit event should just be cancelled with Javascript.
The home page should provide the results of an empty search. Of course, this may be different for a heavily stylized home page, but it’s rarely the case.
I guess it all depends on whether you consider ”“ to be a search term. (I don’t).
The article starts by supposing that you ”inadvertently“ search an empty string so, to me, you would want to provide the same experience that you would for users of other forms on your site. If you make a mistake with a form you would hope for client-side validation (preferably using
required) that alerts you to the error, rather than having a page reload.Happens to me from time to time. I consider myself pretty tech-savvy and it still happens. How?
Well, from what I remember, these sites feature a search function that consists of a search box and a button with the label “Search”, or similar. Oftenly there’s some kind of trickery that hides most of the search box or makes it smaller until focused. So then, I’m like “Hey, there’s the search, let’s go to the search thing”. And I click the button in hopes to get to a page where I can perform a search, having overlooked the presence of the first search box.
I blame bad UX.
In my opinion there is just one option.
When you enter to search with nothing in the search-box, then you accidentally started a search.
Then you apparently don’t expect a search result too.
So, in my opinion. Give nothing when you are not asked to give anything!
Ignore!
Yes, first validation must be in JavaScript and second in back-end (eg. php) before send request.
I do an empty search on purpose sometimes to learn more when the current page just doesn’t tell me enough useful information. When I use a new system for the first time, sometimes I just don’t know what to search for. Here are my suggestions for what I think would be most helpful.
I wouldn’t want to make the search box required. That’s just a dead end. I’d rather do something that allows the user to discover more information. If it’s a brochure site, I would display a landing page sporting the most popular products. If it’s a blog, I would list the most recent entries. For a webapp, I would display a directory of links pointing to help pages, common search terms, and a list of links that would be relevant for people in the user’s role(s). For anything else, if I knew the user’s previous search terms and it’s not too big-brother-like, I wouldn’t mind displaying the results of the last search they performed. When all else fails, a list of random search results can be surprisingly useful, so long as all of the links are to pages the user is allowed to access.
You didn’t enter any search terms
so here’s a bunny with a pancake on its head.
I usually make a javascript function for it. It covers two cases:
1) if a user just hits the button (without even focusing the search input) then I focus it for them and prevent the default behavior
2) if a user has focused but performed an empty search – same thing only the input remains focused
But I guess there is a room for the
requiredattribute or a special eastereggish search results page. Thanks for those.On this site it should bring up this article.
Clever, I like that.
A combination of your idea for the 404-like page and the first example. Return everything, but with additional notification that they’re seeing everything because they searched for nothing.
I wonder if some end users believe searching with no keywords in the search box will then return everything available on the site from which they can browse all the site has to offer.
Your text to link here… has chosen the humorous approach. :)
LOL, well that went well.. the link should say Google Play store.
If available show a site-index / tag-index with a comment on the performed empty search. Sitemap would be second choice.
I disagree with the single usecase, as search can also be looked at from a filtering perspective. Let’s say we show all the latest blog posts, so all blog posts in order of creation. If the user types something into the search field we can use AJAX to make a call to the backend and only show the blog posts that are relevant, in order of creation. If the user wants to see more posts it removes the text from the search field, which in effect removes the filter.
This interaction still allows the user to search the site and it provides a clear message as to what the function is of an empty or filled textfield.
Not a professional, but like many here, I’d expect nothing to happen.
Now, if the search didn’t require a redirect and wouldn’t affect the page too much (such as a list of posts in a sidebar or something), than I would expect search to behave like a filter, and that would show everything.
I’d like to see more sites do JavaScript modals for empty searches. I made a basic mockup here.
(No Codepen because there really isn’t any functionality.)
I’ve always liked the Google Play Store approach. It just searches for “unicorns” instead.
https://play.google.com/store/search?q
This is awesome, I really like using a funny 404 page for this. I’d say do it! There are so really funny ways you could portray it. Like, “Well, that was wicked embarrassing.” Not sure where your located, but using slang nearby would be funny. Wicked is definitely a New England thing.
I believe the search box text should disappear upon a user beginning to type into the box. It is really annoying to still see search boxes that one has to delete the “search here” text and then enter the search query.
According to me the best possible way would be not searching and instead display a small message bellow the search box just like the one provided by browsers which support html5. A little javascript and css would do the trick.
I prefer the “nothing found, try again” method, I find that some people click the icon, waiting for a search form. Also, I think is an organic and smooth way to guide the user in the ways of our website. Error/Warning messages make users feel dumb, I avoid them as far as I can.
I prefer having a blank search or an asterisk ( * ) return all the posts/content.