cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Windchill Core Search Improvements

Windchill Core Search Improvements

  • Keyword search is default for searching, would prefer to default to number.  Ability to change the default option for the search field at the top of the Windchill page

  • Saved searches - WC must load all the saved searches when the home page is loaded, which adds to network overhead when just loading the home page.

Updated to only include ideas related to the core search functionality...

33 Comments
Level 14

Can I vote 1000 times yes on this one?

Level 11

ERIC HORN‌,

I really like your idea of setting a preference or something for type of search (keyword as opposed to number or name).  I hope you don't mind me adding 1 more bullet point.

  • Ability to switch between normal search and index search from the search page (or the search input box in the top right corner).

I don't like the fact that a user has to navigate into their preferences and then try to remember where (to navigate there) or what the preference is called (to do a "find in tree") in order to flip the switch and do a keyword search.  I wish it was a much easier toggle.

Level 14

Yes, being able to toggle to index search with a check mark or radio button would be great.

Regarding the first point - can you clarify? The Keyword field searches against object numbers, so the appropriate result should be returned. Is it a performance thing (keyword searches take longer than searching against Criteria > Number)?

Level 14

PTC has done great things with search in general, but it the pendulum may have swung a bit too much toward searches like on shopping sites.  In Windchill, many times you absolutely, 100% have to return a specific single object (e.g. a specific drawing).  A person used to getting exactly one result suddenly gets hundreds of results using index search if the drawing number happens to be in other documents.  We have enabled / disabled index search in general multiple times because of this confusion, leaving those who want to use it having to go down a slightly more laborious path to set the preference each time.

Level 12

At least at my company it is split along CAD Creator / Document Creator lines.   The CAD guys all want to be able to just search by number / name and the Document Creators all want to do a keyword search (index).  There is some overlap, so there is also no way to make everyone happy. 

Ah, ok. In 11.0 the Criteria field is redesigned in such a way that selecting different criteria is a little easier, but Number has always been added by default. From a user experience perspective, it seems like a small inconvenience to enter a value into a field that's a little lower on the page.

But I do think the idea of being able to toggle index searching from the Advanced Search page is a great idea. Beyond the performance issue, if Solr is down or indexing is buggy, having any value in the Keyword field can result in inaccurate results. Using a keyword when searching for multiple criteria against a non-latest iteration can also mess you up. Same with special characters and spacing. (The Help Center outlines all of these scenarios.) 

Usually if I suspect that indexing is causing the problem, I just clear the Keyword field and use Criteria field values instead.  However, I can see how this would be confusing for casual users who don't understand the full effects of enabling index searches and might not even be aware of the preference.

Level 11

Caitlin Wheeless‌‌, I might not speak for everyone, but as far as I'm concerned I would like the top-right search box to be configured to use either Number (and/or Name) or Keyword.  I just wanted to clarify because your comment "enter a value into a field that's a little lower on the page" made it sound like you didn't get the scope of what I was trying to describe.

For example, I might wish to do a Number search from the top-right search input box.  That would be performing the number search without even needing to open the search page at all.

I'm not talking about opening the search page and needing to type part number into the Number field (bottom left corner of screen) as opposed to the Keyword field (top left corner of the screen).

Ok, so you're talking about the global search field:

Global.PNG

And you'd like to see a index search toggle switch there as well?

Level 14

Agree w/Ben.  99.5% of all our user searches are for Number, not Name.  Because we use manual Numbering (as many do), generally users input part of a Number with a wildcard and get multiple results (e.g .PRT and .DRW).  We would strongly vote for the global search that you point to above to be for Number only by default, with easy toggle to index.

Level 11

Yes.

A guy can dream, right?

  • An on/off toggle button for index search, for example.
  • 2 different magnifying glass icons for standard search versus index search, for example.
  • Maybe a preference for "type of global search", which can be set to "Keyword", "Number", "Name", "Number/Name", or whatever else.  And the ghost text that disappears (which now says "Search . . .") can instead say something reflective of the preference setting (such as "Keyword Search . . ." or "Number Search . . .").  Okay, now I'm pushing my luck, I suppose.  But don't you agree it would be slick?

No, I do honestly like this idea. When I'm working in our test servers I'm constantly flipping between indexed searches and non-indexed searches. I'd love a toggle option. The global search hasn't had much work done in a while, either.

I'll forward this thread along to our search product team.

Level 11

Hi Ben

Do you know that the Solr search has two different behavior? If you start with a *4711 then it searches only in name and number. But if you search 4711* then it searches all the indexed content.

Have a look at the case: Solr Indexing Behavior Differences Between Simple and Advanced Search in Windchill

Part of the case description:

1.    If leading wild card term is used for searching it will be searched ONLY against the attribute mapped for Keyword DB Search Out of the Box(OOTB), for most of the types, attributes configured are name and number. The mapping can be found in WT_HOME/codebase/com/ptc/windchill/enterprise/search/server/SearchableAttributesByType.properties.xconf

2.    All terms without leading wildcards are searched against meta data as well as content


3.    If combinations of the leading and trailing wild cards are used, these terms will be searched as per #1 and #2 respectively. The “AND” or “OR” operation between the terms will be controlled as per the selection against “Find” drop down

Example – Assume you have you have a part with name as “AXLE” (note the uppercase) and a document with name as “Manual” with attachment content containing a word as “axle”. The behaviour with different terms will be

Simple  Mode What will be in the result?
Terms usedPartDocument
*axleYN
*axle*YN
axleYY
axle*YY
operator - AND*axle manualNN
operator - OR*axle manualYY

Yes! Excellent point!

But that article isn't entirely correct.  A leading asterisk does indeed limit the search to Name and Number fields. BUT it should also search against indexed document content, while dropping the leading asterisk as a wildcard.

For example, you have the following:

  1. A part with number "0001234"
  2. A part with name "0001234"
  3. A part with weight ".01234"
  4. An indexed Word document with the string "1234" in its content
  5. An indexed Word document with the string "0001234" in its content

A search for *1234 should return the following objects: #1, #2, and #4.

#3 and #5 would be ignored.

This behavior is described under "Unique Wildcard Behavior in Indexed Keyword Searches":

http://support.ptc.com/cs/help/windchill_hc/wc102_hc/LclSrchCriteriaWildcard.html

Level 11

And that isn't our use case anyway.  Our use case is that we want to find everything in Windchill related to PART123.  So we put PART123* into global search textbox in the top right corner of the webpage.  We expect PART123 WTPart, PART123.PRT model, and PART123.DRW drawing to return in the search results.  Maybe PART123.PDF for an old legacy drawing if one exists.

That is the use case for the global search to only search through the Number attributes instead of acting like a keyword search.

Ok, so you're saying that it's not enough to just limit the global search to Name, Number, and indexed primary content - you need to further limit to either Name or Number on-the-fly?

Because *PART123* would limit the search to whichever fields are configured in SearchableAttributesByType.properties.xconf (Name and Number by default), while expanding it through the trailing asterisk to include PART123 WTPart, PART123.PRT model, PART123.DRW, etc.

Level 11

No - just Number is sufficient for us.  But my idea is that I shouldn't have to configure a Windchill property for it.  It should be user preference.  Windchill property requires restart and is the same setting for all users - in all organizations for multi-organization installations.

But I will offer this disclaimer.  Of course the intended way to obtain the models & drawings are through the WTParts.  So the user should search for PART123, and then go find the associated CAD and/or documents.  But old habits die hard.  They just use the PART123* search to find the CAD - whether it is related to the WTPart or not.

Also, I hear through the grapevine that some people (like Steve Galayda) don't use WTParts.  So a PART123* search will return the model and the drawing.

Level 11

Another thought about an interesting conceptual future state of search results...


Wouldn't it also be cool if the Search could be configured more like a collector instead of a search?  What I mean is that you search for PART123 and in the search results you also get some WTDocument called TESTREPORTXYZ.DOC.  And the only reason it appears in the results is because there is a reference link between the search result (PART123 WTPart) and the WTDocument.  Of course we'd need some type of "Rule" column in the search results to demonstrate why TESTREPORTXYZ.DOC was returned in the search results (because it has a reference link to the WTPart).  But that would be pretty great so that users don't need to navigate to the WTPart to pull up the objects that are related to whatever is being searched for.  I guess you could almost display the search results in a 2-level tree at that point.  Level 1: the first search result.  Level 2: the associated objects to the first search result.  Then the next line, Level 1: the second search result.  Level 2: the associated objects to the second search result.  I guess I should demonstrate this with a screenshot or mock-up image.

Level 1

I like the sound of role based views, would present a cleaner interface to a lot of users I think.

Also, for what it's worth, I created an idea for toggling index searching a while ago, give it a vote!

Toggle Index Searching in the Search Page

Level 11

I have created a mock-up of the 2-level search result that I described above.  You can see my terrible artwork! 

In the example, I have done a number of things:

  1. In the hypothetical world, there is preference for the behavior of the global search.  I have it set to a value of "Number Search" instead of OOTB "Keyword Search".
  2. I didn't show the differentiation between standard search or index search, but provide suggestions.  (Either different magnifying glass icons & keyboard shortcuts, or else a toggle button.)
  3. My search term is "PART123*" - with the asterisk.
  4. You can see the WTPart as the first search result.  And beneath that, 2 other objects
    1. An associated model which happens to have the same number (PART123.PRT).
      1. The collection rule is "Dependent".  Or maybe can be displayed as "Owner".
    2. An associated WTDocument which has a "References (Documents/Parts)" link to the WTPart.
      1. The collection rule is "Dependent".  Or maybe can be displayed as "Reference Document".

You can see PART123.PRT returned in the search results twice.  1) It is linked to the WTPart, thus shows on the 2nd level beneath the WTPart.  2) The number starts with PART123.  And that was the search criteria.  So it appears on level 1 since it is a search result.  There would need to be discussion if this is desired or not - duplicate results (one on the 2nd level and one on the 1st level).  Maybe if it appears on level 2 somewhere, then the object should not also appear as its own result, such as the 4th line in my example.

This example shows a potential data integrity issue.  If your business practices dictate that models/drawings should be associated to WTParts, then you can see from the search results here that PART123.DRW (drawing) is not associated to the WTPart.  Otherwise it would show beneath the WTPart.

2015-10-27_13-21-09.png

(MARIANO VELICOGNA & Marco Tosin‌ tagged because I see they liked my previous comment.)

Nice! Thanks! I like the idea about using different magnifying glass icons. Do you ever use Advanced Search mode (enabling Solr syntax)? I'm not sure how many users do, but it might become more relevant for some in 11.0....

Also - what about just adding the collector actions to the search results table toolbar? We've done a lot of work adding multi-object actions to the search results table, so I can see this making it an even more useful option.

For what it's worth, we will be providing some ability to search by related objects in 11.0. (Nothing nearly as comprehensive as you have outlined above, admittedly.) You'll essentially be able to use object relationships as a search constraint. For example, you can search for all parts that have a related document, or all documents that describe a part. You'll be able to specify criteria for each - for example, return all parts modified today that are described by a document created by user Ben Perry.

Level 11

I think it would be good if I describe my frame of mind when I suggest these ideas/improvements.

My frame of mind is the manufacturing floor who need an assembly drawing.  Or the Purchasing department who needs to get models/drawings to send to vendors.  Or the QA department who needs to pull open drawings to inspect purchased components coming into our manufacturing warehouse that need inspection.

Basically they have a part number, but don't know if the drawing is DRW, DWG, PDF, TIFF, or something else.  A lot of legacy data loaded into our Windchill instance.  So they do the asterisk search, and then choose the drawing that looks correct.

  • Same revision as the WTPart.  (WTPart and DRW are revision E ... but there is also PDF revision C ... DRW is the correct one.)
  • Same state as the WTPart.  (WTPart and DWG is PRODUCTION state ... but there is also PDF in OBSOLETE state ... DWG is the correct one.)

This could actually be perceived as a stepping stone to eventually guiding users to get their models/drawings from the WTPart associations, instead of just doing a search for the model/drawing.  I hope the user will always see that the model/drawing they need is "beneath" the WTPart.  And that they should always be pulling that model/drawing.  In the long term, it is still a way to see the associations right away in the search results - without needing to navigate to the information page of the WTPart.

About adding the collector actions to the toolbar - no, I don't think so.  I just like to see this by default.  I don't want to click another button to do it.  If you need to multi-rename, then yes, you can initiate the rename action and then start collecting from there.  But going back to my frame of mind where I'm looking for the drawing - I have a part number but don't know what format the drawing is in - I will do an asterisk global search to find the drawing.  It is the easiest.  No extra thought or clicks required.

Level 14

Well stated.

Ditto to all.

Thanks - that's all very informative and interesting! I'll forward along this entire thread and see what response we get.

Level 18

We have not yet reached a point where we have a need for WT Parts, but I can see how instantly seeing the relationships between WT Parts and their linked objects right from the search page would potentially make them much easier to implement.