6

match all search fields to logic used in Inbox

Andy Cochrane

February 25, 2014 18:45

None

Follow Updates

The Inbox search is the only search on the entire site that fully works. We've been complaining about this for almost a year now, can you guys PLEASE take the perfect search from the Inbox and use it on all other parts of the site? Your older search bars don't search every field in the DB, and in doing so are about 90% useless since there is no promise that they are displaying all of the desired search returns. Inbox on the other hand, works like a champ. See attached images for a very common (laughable, but f###ing annoying) fail in the old search bars.

getYourHeadRight.png
goHomeShotgun_YoureDrunk.png

• Facebook
• Twitter
• LinkedIn

6 comments

• 0
  
  Brandon Foster February 25, 2014 19:45

  Hi Andy,

  Thanks for writing in, and sorry for the confusion the quick search is causing here. There are definitely some queries being run that are not explained well visually (which is causing the consternation you've described). The quick search by default has a set of key words on which it will search (i.e. explicitly defined fields). See the attached screenshot. Using your Version search as an example, the search produced no results because the "Artist" field was not one of the fields being queried. By clicking the arrow next to the search box you can specify the fields on which your input text should search.

  The key words are currently limited in number, and data type (usually text) in order to help keep the search fast. Adding more fields, and data types, will produce a slower query. The Inbox search operates in much the same way, but since that is a much more controlled environment there are more fields included in the search (which are unfortunately not exposed to the users). That's the brief explanation for how the search works, and there's definitely room for improvement here.

  What sort of alterations would you want to see to the way the quick search functions? Would you want the default key words to be configurable on a per-page basis, or perhaps per-entity? Or should we go a simpler route and try to make some educated guesses on what fields users will find important (like Artist in the Version example), and make those fields default key words?

  Hopefully with this explanation you'll be able to make better use of the search as it exists now, and we'd love to hear your ideas on how we can make it better!

• 0
  
  Andy Cochrane February 25, 2014 20:01

  Hey Brandon!

  I would want the quicksearch to at least search all fields that I'm already viewing, by default. For this screenshot that would mean version name, link, artist, description, status, path to frame, path to movie, uploaded movie and date created. I am aware of the dropdown but am constantly annoyed by having to re-select these options, I'd rather have it search all fields always and be a little slower, than slowing me down by making me choose what to search before searching. If I had my druthers, I'd want a global setting for all search boxes and I'd personally turn everything on and just eat the incremental time loss on each search rather than the constant hassle of adjusting search criteria. It's just currently not a very "quick" quicksearch, no matter how you slice it.

• 0
  
  Brandon Foster February 25, 2014 23:05

  Good points Andy, thanks! In this instance we may have swung a little to far in the direction of performance at the expense of useful search results. We definitely want the quick search to function in the way the user would expect it to without a lot of extra fiddling with the underlying controls.

  While I don't have an ETA for implementation, I can say this is something we're interested in revisiting after the 5.3 release.

• 0
  
  Andy Cochrane February 26, 2014 02:58

  thank you!

• 0
  
  Kym Watts February 06, 2015 16:26

  At the moment when you do a search, especially on a page of results, you can either choose between the keywords that sg has already defined, or a different field, but not both.
  We would like a slightly different approach to this with how search is handled, to leverage what we can search vs performance.

  It would be great to be able to config the search key words either on a per page level or a per entity level.

  An example would be:

  For assets, if we know they are for shots that do not have shotgun entities yet, we tag them with the shot name, so that later we can auto link them. When the artists are in a rush, they some times forget to change the search to include the tags field. they end up with no results and end up making a new asset and tagging it.

   

• 0
  
  Jonathan Chavez February 01, 2018 00:23

  +1'ing this.  For List views, we can have many fields exposed and "hide" less relevant ones off-screen, but exposing all fields cannot work in Thumbnail view.

  I, too, would prefer to passively eat the extra time by searching all fields, than actively eating extra time by going in to manually pick keywords. Out of the box, I expect searches to find relevant data, and I do not expect them to be quick. The current implementation meets the opposite of both my expectations.

  Has any progress been made here?