What is meta? ×
Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 134 Stack Exchange communities.

After the performance problems we have run into with Lucene.NET we've decided to make a change, we're moving the network on to elasticsearch.

Here's where to get started: http://stackoverflow.com/search

What works:

  • All search operators should be in
  • Many changes below from the old search behavior

What's different:

  • The new search is AND, adding a search term will narrow your results, not expand them.
  • The look of search results is now more unified with the following differences between Q&A:
    • "Q:" or "A:" prefix
    • Answer counts and tags will be present in questions.
    • The answer count will be highlighted in green if it's accepted.
    • (We may index other things later, that's why the results are more generic/google-y now.)
  • It's faster, about 5-10x faster for almost all searches on large sites like Stack Overflow
  • Quoted phrases are exact matches except for case-sensitivity, for example, you can search for code or symbols.
  • If not in a quoted phrase, words will now be stemmed (example)
  • Snippets for context will now be more relevant
  • Excludes are now explicitly supported (like -term and -"my phrase")
  • We don't roll up to the question anymore, if you searched for something that matched an answer, we'll show you the answer directly in search results
  • The search per minute limit is effectively gone, it'll block a bot, but no one else should hit it... We'll be monitoring performance though
  • infavorites:mine is back, with infavorites:12345 (any user id) added

What needs work:

  • What you tell us is broken... Do your worst.

Testing, not yet final:

  • New range support, here are some examples:
    • answers:1..1 (exactly one answer)
    • answers:10..20 (10 to 20 answers)
    • created:2008..2009 (created between Jan 1st, 2008 and Dec 31, 2009)
    • created:2010-04..2010-05 (created between April 1st, 2010 and May 31st, 2010)
    • created:2011-01-05..2011-01-06 (to be clear: it goes to end-of-day)
    • This range syntax applies to a new advanced operator: lastactive: and the other numerical ranges, views:, and score: Additionally, the above syntax is a bit more flexible if you forget it exactly (e.g. score:20-30) in an effort to be intuitive as possible, give it a try - tell us what you think.

I'll try and improve the search as much as possible before it becomes default... At the very least we want it equivalent in relevance and functionality before the switch, but ideally much better. We won't switch until then.

Please give it a try, tell us what you think here, and we'll continually improve it over the holidays as time allows. Bear in mind you may get a search offline page during this test if a change we're making for results necessitates a reindex, and even that should only last about two minutes here on Meta Stack Overflow.

Give it your worst, compare results to the old search, tell us what's better and what's not. We look forward to the feedback.

Update The new search is now the default across the network - we'll be monitoring things over the next few days and would appreciate reports of any crazy behavior you see here.

share|improve this question
"What you tell us is broken...do your worst." - Evil grin. –  animuson Dec 23 '12 at 22:16
Any more info on the perf issues? Is there a blog post or similar? –  redsquare Dec 23 '12 at 23:02
@redsquare - I can detail it in a blog post on my blog if there's enough interest...basically I don't think anyone uses Lucene.net at our level of load, so no one's hit the performance bottlenecks on the file locks so hard yet. –  Nick Craver Dec 23 '12 at 23:06
So you're still using Lucene, you just put a sharded server on top of it. elasticsearch is a great product, I'm surprised this didn't happen sooner. –  casperOne Dec 24 '12 at 0:12
I hear you used the NEST Elastic search client for .NET that a colleague of mine wrote. That's awesome! Great work! –  Rahul Dec 24 '12 at 0:21
We're all thankful, but let's leave answers for feedback on the search (bugs, enhancements, etc), only as this is an area that needs a ton of attention if it's going to be moved to the main site and we need to make sure it gets all ironed out. –  casperOne Dec 24 '12 at 0:26
@Rahul - indeed, I've been working with the author to improve on some areas essential to us...I'm committing sections of the health API in the StackExchange fork currently but they'll hopefully be in the main repo soon. –  Nick Craver Dec 24 '12 at 0:33
@JollyOldSaintNicholas - it's by no means a trivial change, elastic is awesome but also lacked some features we'll be relying on such as bulk UDP (only added in October, etc.). More generally though, there's just no shortage of things to do on our team...search just got a priority boost after becoming a major problem on the Oregon servers for a while a week ago. Bringing something entirely based in Java into our stack (which has nothing else Java, and we have to run on a windows server...for now) isn't a clear win either, has to be well worth it...but in this case it is. –  Nick Craver Dec 24 '12 at 0:48
@NickCraver The server setup (whether or not it's something that is running on the same servers as the Redis setups, for example) would probably make for a good Server Fault blog post. Also, did you ever get that search analyst that you guys posted on Careers for, or was this done outside of that position (whether or not it was filled)? –  casperOne Dec 24 '12 at 0:58
We're still looking for a data scientist (for other reasons), this was me taking a week and fixing a performance problem really, new search is a side-effect. Server setup I'll detail in a post coming up...search isn't the only thing on these servers so considerations besides elastic are in play. –  Nick Craver Dec 24 '12 at 1:00
@NickCraver "we have to run on a windows server...for now" Hey now, you're supposed to wait a full year after Jeff left to start hinting at that. :) –  Adam Davis Dec 27 '12 at 15:47
@TravisJ - there is a stemmer in play unless you use quotes (around a word or phrase, either one) in which case we respect exactly what you were searching for. This is how google works as well...though we may play with the stemmer per-site in some cases - we'll adjust as we go to improve results. –  Nick Craver Jan 6 '13 at 23:23
I suppose it has limited utility, but ..# might be nice for all <= # too, if possible. Like score:..# or created:..2009, so I don't have to guess what the minimum value is (or be lazy for operators with minimum value 0) –  Tim Stone Jan 7 '13 at 22:32
I love the new advanced-search droplist on the right, so I don't get taken away to the advanced-search page for those operators I always forget the syntax of. –  Lance Roberts Jan 8 '13 at 1:10
@ShaWizDowArd hence the word "effectively." I think noting that it's still there and will block a bot is clear enough as-is. –  Nick Craver Dec 12 '13 at 11:05

24 Answers 24

The question result interface is much, much worse than the old one. Compare:

Question list interface


New search question list

Yes, the new interface is much more compact, but some of the most important information about a post - the number of votes, views, answers and whether it has an accepted answer are either missing (in the case of views) or relegated to secondary position that are difficult to see when scanning through a list rapidly. The difference between the new search list and every other question list on the site is jarring and takes some getting used to.

In short, the new interface looks as if it might have been Google's, or any other generic search engine. The reason why I'd use Stack Exchange's search at all is (other than the additional search options), the interface that's unique to questions - if I wanted to see my results as a list like I would on Google, I'd have used Google.

Separate from the interface issue, for many queries the engine now returns answers alongside questions. This is usually a good idea, except that most of the time I don't think it's necessary. Personally, I don't think it's useful for tag searches (e.g. [minecraft] crafting) to return answers, especially since searching for [minecraft] alone will only give you a question list. It also brings up a lot of unnecessary duplicates. Sure, I could add is:question, but I think the answers should not be displayed for these searches by default.

While this might be an issue of getting used to the new engine, there are others queries where it makes no sense at all to include answers. For instance, [minecraft] closed:0 shouldn't return answers, unless explicitly asked to.

Another suggestion, prompted by Jeff's comment: It might be better to group answers with their questions in search results. One of the biggest problem with the new search engine is that if I don't add is:question to my query I'd get a lot of repetition when a question, and multiple answers to the same question, show up in my search results. If I do add is:question though, now I might miss out on answers that may contain my query.

share|improve this answer
@NickCraver I think it's fine (preferable, even) for posts of different types to be styled (very) differently, assuming this is only an issue with the interface, not with the new search backend being unable to be more flexible in displaying different types of post. Views are useful since questions with large number of views (10k+) and low score can be indicative of problematic questions. Do you have any comments re: searches with tags? –  Yi Jiang Jan 5 '13 at 6:04
Particularly, I felt lost not being able to spot ratings and views at a first glance, which is a distinctive mark from the Stack. Makes all results look like the same. Really, just a block of equally formated paragraphs very difficult to be dynamically read (in a hypertext sense). –  brasofilo Jan 5 '13 at 7:40
I don't care so much about number of views but making the number of answers and votes more prominent would be useful. –  assylias Jan 5 '13 at 11:58
Please, please, please switch back to the old UI. It takes much effort to skim for vote count, answers, etc. That's information I used to determine whether or not a question might be worth looking at. –  Bryan Denny Jan 5 '13 at 23:34
I also find the new results UI very much inferior. Yes the old made SE distinct from any other site, now I even thought it's an 'dumb' google custom search. Yes the old design made it very easy to give info even by periferic sight about the questions. The old colored boxes made the page stand out and be more interesting visually, helping to focus. It was easy to spot those marked as 'useful' (high votes count) and those ones needing attention. Now all this is lost. I find this change a major feature loss both in character, usefulness and usability. –  naxa Jan 6 '13 at 16:24
The feedback I'm hearing again and again is very specific: the score and answer counts need to be more visible. We'll try and tweak the format tomorrow to make these easier to parse at a glance while still working well with the non question/answer result types coming up. –  Nick Craver Jan 6 '13 at 21:38
@NickCraver Although I like the new search features, I have to agree with this answer about the UI. Now instead of simply glancing through the search results to easily find the item I'm looking for, I have to actually read each search result to see if it's the one I want. Its far more time-consuming, particularly on days when my brain doesn't feel like it's working at 100%. It would be nice for the # of answers, votes, and if there's an accepted answer or not to visually stand out more, and if Questions and Answers could be separated visually by more than a Q or an A in the text. –  Rachel Jan 7 '13 at 16:58
You don't need to slightly change the format. Go back to what you had, it was great! Now I need to read lots of q and a to find what I was looking for. It's not very unappealing to me. Searching directly on Google provides me with more readable results. –  Valentin Despa Jan 8 '13 at 9:04
This change greatly reduces StackOverflow's usefulness to me. I have to read far more text at lower contrast to determine wether or not an answer is useful. As an aside, I created a meta.so account just so I could comment on this. It is very important to me. –  CornPuff Jan 10 '13 at 19:51
I also find it extremely hard to find something quickly now. The default mixing of questions and answers is just awful, and the layout of the results is cluttered compared to the old one. You just get hit by a brick of text. Please please reconsider the interface! –  atticae Jan 10 '13 at 23:30
I also agree the search result UI is getting much worse. It's not a habit problem, it's simply harder to find the useful information. –  Romulus Urakagi Ts'ai Jan 11 '13 at 2:57
I have to agree as well; still a few days into using the new search result interface and I find that I am not able to as quickly determine the relevance of the questions my search has presented me with, particularly when I'm looking for questions that might have answers. I find myself using StackOverflow LESS and relying first and foremost on a Google or Bing and THEN coming to StackOverflow begrudgingly to do the search on the site. The way the results are presented is just not as clear as it used to be. –  Sean Quinn Jan 11 '13 at 14:06
Check out the current results, we took a break from the NY migration for a bit yesterday and introduced quite a bit more consistency with how /questions appears. Let us know what you think. –  Nick Craver Jan 25 '13 at 18:13
@nick definitely a lot better. I kinda.. hated.. the old "new" elastic search results. Particularly mixing Qs and As together as different items in the list is really confusing, we had that early on in SO and users really disliked it. –  Jeff Atwood Feb 1 '13 at 0:35
@JeffAtwood I agree that mixing Qs and As isn't helpful. Not only does it reduce compactness by making a single thread take up more than one slot and giving me more to read, but if I determine a question to be irrelevant to my needs after reading it in the results list, I don't really care what answers that question has. The default should definitely be to only display questions. –  SpellingD Feb 1 '13 at 17:24

Thank you, Thank you, Thank you for giving us a default AND search. You've made it a very Merry Christmas indeed.

share|improve this answer
I'll upvote this answer since mine would have essentially been identical anyway. –  uɐɯsO uɐɥʇɐN Dec 23 '12 at 22:41
Indeed, this fixes the absolute #1 worst problem with the old search engine. –  Michael Hampton Dec 23 '12 at 23:03
No more plus key. We're free! WE'RE FREE –  Ben Brocka Dec 23 '12 at 23:13
@BenBrocka - note: the + no longer matters, though we do parse it on +[tag] for example so that it "just works" and doesn't complain...like -[tag] does, intuitive and such. –  Nick Craver Dec 24 '12 at 1:02

I just did a search for the Handling Calls to Remove a Moderator post.

Searching normally, with or without quotes, the question comes up first, as expected.

Using the new search without quotes, the question comes up third:

New search for "Handling Calls to Remove a Moderator" without quotes

Using the new search with quotes, the results are even worse, coming in at ninth:

New search for "Handling Calls to Remove a Moderator" with quotes

I think that there needs to be some tweaks added for when the title is an exact match, quotes or not. I assume that it involves giving the title some more weight, but whether or not that's the solution or how this impacts other searches is for you to sort out.

share|improve this answer
I think the answer here is to promote the question above its answers if in the results - will see the best way to go about this. –  Nick Craver Dec 24 '12 at 0:34
Give this search a try now, I've changed how multi-map fields relate to title, body and tags. Title is only searched for questions now, while body and tags are for all posts. I think you'll find the results for title searches in general much stronger...find examples to the contrary and I'll take another look at refining it further. –  Nick Craver Dec 24 '12 at 3:13
@NickCraver Looks good for now. A very nice touch about the exact title search is that you're searching in the rendered HTML, so I see the original post, as well as this answer in the search results (I used the raw link, not the exact title which was converted). I'll update with more as I find it. Thanks. –  casperOne Dec 24 '12 at 3:44

Chars such as +, - and underscores are no longer ignored in search terms which makes searches such as "_meta", "c++ books" and "c--" possible.

This is a welcome change. Many thanks! \o/

share|improve this answer

We need this (default AND, and faster search with effectively no rate limiting) in chat as well. I find myself searching TL a lot for relevant messages, and it takes quite a few searches to get there.

share|improve this answer
We had considered Lucene.net for searching chat earlier...this is far more likely. After the rollout on the main network I'll get with Ben and Marc to see what it would take to make this happen. Since we can use the same cluster, it's just code that needs writing. –  Nick Craver Dec 23 '12 at 23:08
We have some huge todo items this week in preparation for the move back to New York (in a shiny new datacenter! weee!) but we'll start planning this out today. It may take a week or two to find the time, but we'll get chat search working on elastic. –  Nick Craver Jan 7 '13 at 15:34
@NickCraver: Great to know you're looking in to this :) –  Manishearth Jan 7 '13 at 17:38

I saw reference to this in other places here, but please, PLEASE consider changing the behavior of the new search infrastructure to use the is:question search modifier by default. I think searching on questions that have answers is more useful than searching on answers that have questions. If I knew the answer for the problem I'm having, I wouldn't need to come here in the first place. I come to the Stack sites because I have a question on something and I want to know if other people had the same (or similar) question and what the responses were to it.

share|improve this answer
Yes please, its driving me mildly insane to have to always type "is:question" on all my queries. –  Rachel Jan 15 '13 at 18:44
Totally. This is irritating. Results from a single question should be -by default- coalesced. –  leonbloy Jan 16 '13 at 20:56
I disagree. When I'm searching for a solution to a problem, it's common that the asker hasn't reached the same point in his investigation, or isn't using the same terminology, so the keywords I'm searching for might appear in the answer but not in the question. I want to search both types of posts more often than questions alone. It would be nice to make questions and answers more visually distinct, and have a button on the search result page to restrict to questions or answers, but don't make questions only the default. –  Gilles Jan 25 '13 at 19:53
@Gilles I can get behind a better visual distinction between answers and questions. Looks like they may already be working on something to that end from what I've seen recently. –  Sean Quinn Jan 27 '13 at 17:43
I sure wish I could bounty an answer, I'm getting tired of typeing is:question also. –  Lance Roberts Jan 28 '13 at 14:07

Not sure if excluding terms was ever a feature of the Lucene.net search.

duplicate -duplicate

Was expecting the search to cancel itself out and return nothing.

share|improve this answer
We never did exclusions really, but I think with some parser adjustments we can do them well...I'll try and implement my ideas tomorrow. –  Nick Craver Dec 26 '12 at 23:11
A new build has been deployed, -term and -"quoted phrase" should both work well now...let me know if you find craziness with either. –  Nick Craver Dec 27 '12 at 12:00

Can we get comment search? An operator along the lines of is:comment would be perfect. Since we have direct links to comments, and obviously, the rendered comment text, it would be a very helpful tool.

Granted, it could expand the index a lot (and the indexing might have to work differently because we can hard delete comments from the system), but it would be really useful.

Case in point, this feature-request from this morning (at the time of this posting), as well as this feature request as well as the desire to have that from one of the founders of Stack Overflow.

share|improve this answer
Especially in meta, where are lot of the discussion takes place in comments, I think this'd be a useful addition. –  Matt Jan 7 '13 at 14:58
The search index literally grabs posts right out of the DB (we don't crawl the HTML)...so yes, it's a completely different indexing path. That being said, yes the new search was designed with more things like comments in mind and were on my TODO list. Unless there's reason for not doing so brought up in our weekly meeting today, I'll probably get to it after NY is back up and running. –  Nick Craver Jan 7 '13 at 15:18
@NickCraver Excellent! Great to hear, thank you. –  casperOne Jan 7 '13 at 15:24

I didn't think I'd miss the old "ninja" page, but turns out there was one thing I got so used to doing I didn't really even think about it anymore: using the handy custom search boxes there for Google, Bing, and DuckDuckGo.

(By which, of course, I mean Google)

It's not really that much more effort to type " site:stackoverflow.com", but it is somewhat more effort - and it fails to provide the visceral satisfaction that clearing out the search box and hammering the enter key to reach that ninja page did when results fail to meet my needs did.

share|improve this answer

I searched for "dont jsfiddle" on meta in an attempt to find this answer, however the only result I got was:

enter image description here

In comparison, Google showed many more results. Even searching for the exact phrase "don't just include a link to jsFiddle" still doesn't show the result.

The search term is included in a blockquote; not sure if that had anything to do with it?

share|improve this answer
Well, after this answer it now has two results! I will be taking a look though, thanks for the report. –  Nick Craver Jan 5 '13 at 12:43
I've found the issue, and it's the term split on this example between titles and bodies, with the and not traversing the two. I'll take a look at query construction and see what I can do, likely Monday. –  Nick Craver Jan 6 '13 at 1:21
@Nick: Was there a particular "Monday" you had in mind when posting the above comment, or are we talking generally here? ;) –  Matt Mar 7 '13 at 20:18
@Matt meta.stackoverflow.com/search?q=don%27t+jsfiddle and the phrase works as well –  Nick Craver Mar 7 '13 at 21:13
@NickCraver: Mmm, that teach me to check before being (lightheartedly) sarcastic ;). I definitely checked this a while ago, and it hadn't been fixed then :P. –  Matt Mar 7 '13 at 21:15

It's not good. Not good at all.

First of all, how can I use the old search engine? I tried search and search-old. I was of course looking to make a comparison for my answer, but I'm also contemplating of going back permanently. Heck, I'll even pay. At least Google offers a (near-permanent) choice when they change the Compose in GMail or the Developer Console in Google Play.

There's two parts to this sentiment:

Replacing the engine in the background:

I had no quibble with the old search engine whatsoever. No performance issues, no problem waiting or trying again, and I didn't really need any of the new features that were added.

The only problem I would expect with a new engine is that it does not bring up as many relevant search results. And indeed it doesn't. Searching for "android action bar custom box" gives only 5 results, 2 of which aren't tagged with android (this is a plus for the new engine perhaps, but is it not better to incorporate it into a bot that fixes posts?). None of the results are tagged with android-actionbar. Maybe they are on topic (actually not), but isn't a untagged question usually of less quality?

I have the feeling the old engine would at least give me many more results that were then only based on a part of my keywords. As a user, I would realize this and "recognize" a virtual line where the old engine gave up on my full relevant query and just added far-fetched stuff. This would actually help because sometimes browsing through this last bit would turn up useful insights or just weirdly keyworded questions that were still popular for exotic search queries. So it's a plus for the old engine.

The hard part of searching on SO for me has always been spearheading through to the really related questions. Android's APIs use a lot of common words as terminology. Take the words "action views" for instance. Both are incredibly common. Yet for Android they very specifically refer to Action Views, which all in all might only encompass 20 to 50 questions. Adding "android" wouldn't help because there are a gazillion Android questions that still contain common words. If the new engine allows a wider search, then this isn't helping at all.

Of course, SE might have had good reasons (server performance), and in that case it's a very valid point.

Changing the search UI:

But then it is completely incomprehensible why you, SE, would change your successful search interface. It sounds like Apple maps. Look at the screenshots in Tim Yi Jiang's answer.

Of the old engine I mostly remember that it was somewhat restricted in width, a bit greyish perhaps, but also that there were A LOT of color hints that subconsciously told me something about the question.

Same thing with the avatars. Isn't the point of having them instant recognizability? Then why not show them in search? I know some people that, when they ask a question, you can damn well be sure it was a question needing to be asked (to the point of being yet another bug in Android).

And then there is the issue of text blocks. All I see now is basically two blocks of text (one title, one garbled question with random bold words). Basically, I've found that I'm psychologically blind for the way they are represented now. I also have the feeling the question text part shown below the title is slightly longer than before. Not helping.

I think it was a mistake to abruptly change the search UI and combine it with the engine change.

Sorry, I realize this is not what you want to hear, but it's just my truth.

share|improve this answer
Am certainly not missing the gravatars at all when searching. Eyes can scan text faster without having that blocking –  random Jan 6 '13 at 22:17
Google lets you resist the pull of some UI changes for a long time, but there's no rolling back when they update their search algorithm. –  Shogging through the snow Jan 8 '13 at 3:09
Yeah, that's true. –  pjv Jan 8 '13 at 21:01

Search's stemming seems to be a bit wonky. I searched for "ads" on Arqade Meta (to find what we used to tag questions that were about the Community Promotion Ads but were not said threads), and while I did get results for ad and ads, I also got results for "added", "adding", and other permutations of addition that have nothing to do with advertisement. This... makes no sense, really.

share|improve this answer
I have seen "ad" misspelled as "add" so many times that this in fact makes a lot of sense to me (although that's of course not the reason; rather it's an alogrithmic stemmer that doesn't actually know these things). –  balpha Jan 9 '13 at 17:08

It seems new search can't handle can't:

enter image description here

enter image description here

Can't doesn't stem properly to "cant" which the search box seems to truncate it to.

share|improve this answer
However: quoting (as in "a sentence") works fine. Same for other single-quotes, like in "don't", it seems. –  Arjan Jan 10 '13 at 20:30
The can't case will be fixed in the next deploy, this was an error in the parsing layer I didn't notice at first...results are much better with all contractions after the next build (likely in the morning). –  Nick Craver Mar 1 '13 at 1:41

UPDATE: This feature has been implemented now :-)

Can we please add OR option in tag search box?

Let me explain: If I want to search questions tagged [sql] or [mysql] than I can search like this:

We can search for multiple tags (using AND method) like this [sql] [mysql] score:10. But we can't do it with OR operator: [sql] or [mysql] score:10

Is this feature exists? If yes: How can I achieve? If no: Can we implement this? PLEASE....

You can see the problem here.

share|improve this answer

Could it be that when using non-phrase searches, the stop word removal is quite aggressive?

Searching for what is a codec returns the relevant question only at a poor position 9—even out of the visible scroll area.

Why it should have been ranked better:

  • The title of the relevant question is "What is a Codec (e.g. DivX?), and how does it differ …". There's a literal match for "What is a codec" at the beginning.

  • It's the only question with a high score of 27, compared to the others. The combined score with all answers is 74.

  • The first result has a score of -2. Meh?

It seems the reason for the bad ranking is that the stop words "is" and "a" are removed, but shouldn't these be considered a little more important on Q&A sites than in a normal document-based search engine? I expect users to put a lot of actual questions into the search box.

At least I thought the question I was looking for would be ranked much better if there was a literal match.

Maybe the solution to this would also be to put more weight on the titles and score. But I don't know what consequences this would have.

share|improve this answer
Titles generally aren't good enough (overall) to weight them. The stop word piece is tricky, because it totally depends on the context as to whether they are useful, it's a 50/50 split on useful vs worse last time we dropped stop words. In the AND case it would often leave off results that didn't contain a stop word, when it wasn't specifically relevant...so an insignificant word caused the best result to not appear at all, rather than not being at the top. It's tricky no doubt, the current hope is it's an improvement over the old search...but we're by no means done making search better. –  Nick Craver Jan 4 '13 at 22:40
Thanks for the comment. In fact with the old search I couldn't even find the question if I hadn't used the title filter, so it's definitely an improvement in that regard. Good job nonetheless! –  slhck Jan 4 '13 at 22:55

I'm disappointed that the number of views for each question no longer shows up in the search results. Seeing how many other people had read the results for a particular query gave me an immediate sense of the size of the community that was interested in the related topics. Although number of votes obviously serves as a proxy for this kind of information, it is a much more indirect measure.

Perhaps more importantly, the display of question views did not make the old-style search results any more difficult to comprehend at a glance. Even if the use cases are not relevant to you personally, the more information that you can expose in the search results (without making them any more confusing or difficult to comprehend) the more useful they're going to be to the site's users. It was the collection and thoughtful exposure of this kind of information that really set Stack Overflow apart from the more generic coding forums in the first place.

share|improve this answer
If we showed views, they wouldn't be accurate for a variety of technical reasons. At the very least, they'd have to be accurate for them to be displayed (they could be wildly off right now). The second piece of that is they have to be useful, and the vast majority of the time they aren't. You're asking for information that clutters up the UI for all, for the few that use it...we have to weigh those trade-offs when deciding what to display. I'm not saying this is set in stone, but we have several technical hurdles in the way of this currently - with solutions coming as time allows. –  Nick Craver Jan 6 '13 at 1:11

In a post from last year (now deleted) when you had upgraded the search system you had got rid of the infavorites: search operator. There is still a feature-request out there for that marked .

Will you be able to re-implement that operator with the new elasticsearch engine?

share|improve this answer
It's actually in there now, I'll mark it as [status-completed]. It works as infavorites:mine and infavorites:<userid>. I just forgot to add it to the advanced search help...will get that in tomorrow. –  Nick Craver Jan 6 '13 at 22:17
You might want to change that to infavorites:me to match the existing self syntax. –  Lance Roberts Jan 6 '13 at 22:17
It just doesn't read well at all, so we went with "mine"...that being said we'll advertise "mine" but make "me" work as well. The same is true for booleans, "yes" and "no" also work in addition to 1/0. –  Nick Craver Jan 6 '13 at 22:19
So will mine work whereever me did before? –  Lance Roberts Jan 6 '13 at 22:19
Yeah sure, why not - no need in having them differ. –  Nick Craver Jan 6 '13 at 22:20
Great, I really like consistency in a user-interface. –  Lance Roberts Jan 6 '13 at 22:21
I see two separate requests in your question...what's in the engine is the old infavorites: which is your favorite questions, not tags. We may add tags later but that's not in at the moment (I'll have to performance test such a change, tags would be much more expensive by nature of how it'd have to work). –  Nick Craver Jan 6 '13 at 22:27
@Nick, You're right I got confused, let me know how the in mytags thing goes. –  Lance Roberts Jan 6 '13 at 22:28

Here's a weird one from UX: Bug in the search engine — Why does the search engine fail to find the page?

User was looking for Name or data on this error alert phenomenon? and was unable to find it with the search terms name alert (I can't find it either, out of only 17 results!). Not sure if it's because the words are in the title or what, but it seems like that Q should be a prime result for that Q

share|improve this answer

Possible bug:

I don't know if this was intentional or not, but I was searching for a question I had read earlier in the day with the title: How to debug System.StackOverflowException without link to source code?.

I tried a few searches and would sort by newest, since it had been created that morning and couldn't find it. The searches were StackOverflowException, StackOverflowException source code, and probably a few others.

The problem is that the analyzer is treating a . within words as part of the token, instead of treating it as a word boundary. A search for System.StackOverflowException makes it the top result when you sort by newest question.

Feature suggestion:

I found out that my first mistake was trying to only search for StackOverflow and not StackOverflowException, which made me think of this idea. It seems to be something that many search engines do when analyzing the text for indexing.

It could be nice to tokenize camelcased words both as the original word, (ie StackOverflowException) and each subword (stack, overflow and exception). To help even out searches, you could apply a fractional boost to the subwords so that those hits don't easily outscore documents that hit on the original, unaltered search term.

share|improve this answer
It seems you were quoting the search term, right? That meanwhile was also reported as a standalone post: Don't exclude results because of quoted punctuation. (So, not embedding it in quotes should not get you the above issue.) –  Arjan Jan 27 '13 at 7:19
@Arjan - I tried both. I'm quite familiar with how Lucene works, so it was sort of an instinct to try it both ways. -- same results. I'm unsure if the problem still happens now. Unfortunately, my example no longer works because the StackOverflowException term now his on the answer (unsure if it's hitting on the question at this point, yet) –  Christopher Currens Jan 27 '13 at 7:59
You might have run into the problem of the post itself also having quotes around the error message... (I added some examples to the bug report I linked above.) –  Arjan Jan 27 '13 at 9:00
@Arjan - Sadly, that is not the case either. Actually, in your picture you've linked on the left in your answer to that question, you can see the question I'm referring two, as the third result. Notice the title has no quotes, while the body does have the single quotes. –  Christopher Currens Jan 27 '13 at 9:56

Code searches are better.

The new way picks up things that have a different case (expected) and picks up things that the old way failed to pick things that it should have that were in code block like

And since it's not case sensitive it doesn't have this issue.

share|improve this answer
Thanks, code search will work properly in the next build - though I'll need to pull the indexes down to fix deleted owners showing up in results over the weekend. –  Nick Craver Dec 28 '12 at 23:15
The new build went out last night, the code:"GetType" search now finds 373 results, all inside code blocks. –  Nick Craver Dec 29 '12 at 9:57
Nice it looks good –  Some Helpful Commenter Dec 29 '12 at 17:16

Most likely by design, but just to be sure: search result summaries for preformatted code blocks are rendered without their newlines. That might look funny, but maybe only when code has been abused for formatting:

share|improve this answer

I was trying to find this post; How about a "Vote not to close" option to counter the "Vote to close"? by searching for "vote not to close".

However, the result does not show up anywhere on the first page; even though it was a direct phrase match.

Now of course, I could have searched for an exact phrase, but at the time of searching, I didn't know I was searching using an exact phrase.

Also, the "best" result (IMO) in the exact phrase search is superseeded by a shoddy 2 vote answer on an irrelevant question.

share|improve this answer
... is there any particular reason for the -1? –  Matt Mar 19 '13 at 11:52
Matt, I guess -1 was given by someone who didn't bother to read what was clearly stated in the question: "We look forward to the feedback." –  gnat Mar 19 '13 at 13:11

Let me show another example:

When I use the new search with the query "Theme.Holo.Dialog on DialogFragment" I get two very mediocre results.

When I use the same query on Google, I get many more results, including from SO. And what's more, the third result is almost what I was looking for, and IT'S FROM SO!

So how come I'm not getting these great search results anymore?

share|improve this answer
The Google result doesn't have "Theme.Holo.Dialog", but rather "Theme.Holo.Light.Dialog". Basically Google treats a search for x.y.z similarly to a search for x y z whereas here it's kept as one word (which makes sense to me but will indeed limit results). –  Matthew Read Jan 9 '13 at 17:35
Isn't that the basic idea of a good search? That it doesn't try to literally take your search query and match it, but also tries to find similar matches? Anyway, if anyone could show me what the old engine would've given me, maybe I could let this rest. –  pjv Jan 10 '13 at 17:29
@pjv - the old engine doesn't find it either. That's not say we don't care...I'm collecting these examples and seeing what we can do to improve the search all around. Search is by no means final, we'll continue to improve the results as time allows. I've been quiet here because we're about to move over half our servers and there's a lot of prep to do...we are listening though! –  Nick Craver Jan 11 '13 at 14:21
Thanks for the signal. –  pjv Jan 11 '13 at 21:58

It seems that there is inconsistency with how the questions and answers are displayed in the search results - sometimes you see the Q:, sometimes not. I don't see any reason why some of the results are missing the question text, which is the main thing I look for when scanning the results.

For example, searching SO for "C# automatic type inference" includes this selection of questions below - why is the question text only included on the first two?

enter image description here

share|improve this answer
The new search returns both answers and questions. The second two here matched on the answers, but not on the question –  random Jan 18 '13 at 22:10
@random - interesting, I didn't catch that it was strictly a Q: or an A: and never both. I'd still rather see the question text in the results, though, not just the answers... though I wonder if that's because that's what I'm used to with the old search results, or because I truly prefer looking at the original person's question when trying to determine if the matching result is similar to the issue I'm experiencing. I honestly don't know. –  Derek Jan 18 '13 at 22:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .