So what I am looking for is a way to represent a wildcard or * delimiter for non technical users that possibly may not need an explanation.

i.e. If a user wants to search for EJ-205, EJ - 205, EJ 205, EJ_205, EJ.205, EJ . 205 is there a way where on the screen you might be able to represent that you could have a * or something between the terms that would filter out the alternate characters?

If I design based on convention the * for wildcards seems to be one way to go . However I doubt a user would see the star or randomly know to type the star if they never used it before.

I was thinking about saying the following terms occur within a phrase (but that also seemed poor).

I was also thinking of a check box that says disregard punctuation and other non-word characters in between search terms (I like this the best but maybe I am missing something).

Ideally I want a user to recognize what it does rather than learn it and have to recall that feature.

  • can someone add a delimiter or wildcard tag so this post can be found in the future for others Commented Oct 3, 2013 at 14:24
  • Those examples EJ-205, EJ 205, EJ_205, EJ.205 would be matched by EJ?205 on most systems from DOS, Windows batch, Linux bash, etc. Why misuse * where ? is standard for a single character wildcard?
    – Dan D.
    Commented Oct 3, 2013 at 18:32
  • actually because i should have said ej-205 ej - 205 ej . 205. etc we found the * is used way more than the ?. editing my post now. and most of our "non technical" hard to define what this means really dont use dos linux etc Commented Oct 3, 2013 at 19:25
  • I see. With those the use of * in EJ*205 which matches those new examples is consistent with the use of it in other systems.
    – Dan D.
    Commented Oct 3, 2013 at 21:00

3 Answers 3


I would do it potentially in the back-end of the UI and provide some contextual help to the user to advise them how to use the search appropriately.

  • so a ? help tip or scroll over thing. what do you mean back end of the ui . are you talking implementation details like server side vs clientside. Commented Oct 3, 2013 at 19:27
  • 1
    Yeah a ? icon with some details or even a little message box with an information icon to explain how to do a proper search. Sorry I didnt explain the back-end very well, What I meant was depending on how you search is implemented you could use the power of client side == removing "," from list and other unwanted characters to send individual queries to the server, or if the server can handle it an array of queries. What I am really suggesting is that you look at making the client side and server side do some work so the user doesn't really have to.
    – MeeMMeeM
    Commented Oct 3, 2013 at 21:20

Different tack, why bother at all? If the end users aren't skilled, why not do the heavy lifting on the backend? If i search for EJ-205. Then can you simply automatically search for *E*J*2*0*5* and then apply some intelligent sorting to the reslts from the database to put results in a sensible order, with most relevant at top of autocomplete or whatever. If you want to get super advanced, you can even do things like levenhstein distance searching.

This will take quite a bit more effort processing the results of the query from the database before sending to the end user ( to put them in a sensible order), but results can be much easier and cleaner to users. (zero config options)

Example. We let users search a catalog of around 80,000 products with about 25 different fields. We have search fields above each column which search just that column and use the classic */? Wildcards. We also added a single 'all search' entry field to search all columns using *e*J* method, and the users much prefer that, often always using that, even to search for static things like date.

Of course, this may be a performance drain doing what is presumably sql like commands, but there are plenty of ways to solve that, and it only hurts as volume to search gets large.

  • we are searching entire documents so that would be kind of rough. * also if we added * in there we would have way too many matches and then doing something like 3 ??? is a possibility though its hard to figure out how many spaces and punctuation markers we should put in between each character. Commented Oct 4, 2013 at 19:24
  • Yeah nah, wont be suitable for long search targets like documents, only really for shorter strings or systems where you have advanced searching engines
    – rlb
    Commented Oct 4, 2013 at 20:09

what i decided on after some thought was a check box, that said match "variations of term". with a tool tip describing it. I may change the wording but my motivation was trying to show users the difference between say a Bing search and a Bing search with " " double quotes

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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