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

A better e-support interface

Regular Member

A better e-support interface

One of the nice features of Windchill is that you can get to the information different ways.  If I know some text, I ca search.  If I know the product and version, I can browse and find it.

 

We can search the KB now, and apply filters to narrow down the results, but we can't really browse.

 

I would like to see a tree structure like RockAuto.com.  Pick a product, pick a version, pick an area of functionality, drill down till you see something familiar.  The same problems could be cataloged under multiple categories.  Just make it easy to find visually.

 

One of the problems I have with searching is nomenclature.  I might call it LDAP and you call it Windchill DS. 

 

I can't count the number of tickets where I copied the text from the MS log file and no results were returned.  The support engineer can find an article because he already knew the solution.

 

Maybe the errors should all have a unique ID in the log file.  That would make finding the solution a breeze.

3 REPLIES 3

Re: A better e-support interface

"One of the problems I have with searching is nomenclature. I might call it LDAP and you call it Windchill DS."

 

That is up to the person who wrote the article or documentation primarily to ensure whatever tool they are using tags all possible instances of a likely search term.  The configuration of the search engine is always a black box.  Don't be shy about providing feedback on articles if they were hard to find, or for any other reason.

 

"I can't count the number of tickets where I copied the text from the MS log file and no results were returned. The support engineer can find an article because he already knew the solution."

 

Try to cut the log text down to the actual error, if you have one.  One trick I find helpful is to conduct several searches of each part of the log error individually.  Even better, search at google. That turns up stuff that the internal search does not, with a direct link to the PTC support portal.

 

The support engineers are supposed to link knowledge, or create new if it does not exist, at the point they provide a 'solution'.  Support engineers are often very busy, and can gloss this part over.  Point is, what you describe should not happen in a support org that is doing knowledge properly.  Ask them to properly document the solution, or do it yourself in the case closure note. That has saved me when I was able to look up my closed cases and confirm the fix. 

 

"Maybe the errors should all have a unique ID in the log file. That would make finding the solution a breeze."

Like the "ORA-XXXX" errors in Oracle database land.  This idea I really like!

 

"I would like to see a tree structure like RockAuto.com. Pick a product, pick a version, pick an area of functionality, drill down till you see something familiar. The same problems could be cataloged under multiple categories. Just make it easy to find visually."

 

I see your point.  I just don't think that is efficient with the thousands of articles and millions of things that show up as one thing, but caused by another. This works great for the Documentation portion of the site, and also the software downloads.

 

Re: A better e-support interface

Invisigoth,

I really struggle with PTC support and I sincerely want to help make it better.

 

Article feedback:

I used to provide feedback to articles whenever I had questions or thought they could be better.  Most of the time ( not every time ) the author is very defensive and reluctant to change the article or even add a link to a different related article.

 

My perception is that feedback is usually not welcome.   Maybe you can see my submissions and how they were handled.

 

Searching:

When I said I copied the text from the MS log file, I meant I would try the name of the method that threw the error, or the error message itself.  I find that putting in fewer search terms returns more results, so I try to be smart about what I put in. 

 

Browsing:

I think a tree structure has a lot of value.  I don't think scale is a problem.  RockAuto catalogs every part for every make and model car or truck ever produced. ( maybe not "every", but a comprehensive list for sure)  Once you get to the part, they show all the vendors that supply that part.  Must be tens of millions of parts with hundreds of millions of links.  The site is fast and efficient.  You can get to the same parts by following different paths.  The same thermostat might be under "engine" and "cooling".  I suspect RockAuto allows the suppliers to catalog their own parts.  

 

Maybe customers could suggest branches for the article, and someone at PTC approves the suggestion.  Maybe the customer could suggest the article gets copied, and updated for a specific version.

 

The process of cataloging the articles might help PTC identify duplicates, or contradictions.  I have examples where one document tells you to edit a file directly and another document tells you to never edit that file because it gets overwritten.

 

Sometimes one article tries to cover many versions of Windchill and that makes the article confusing.

 

Re: A better e-support interface

Plus, pretty please tag, the articles correctly - the number of times "Integrity" solutions come up when I'm search on "PTC Integrity Modeler" is unbelievable.

And yes I have commented on that and provided feedback to our PTC "manager" ...

I suspect I'm going to have the same problem with Windchill Process Director - but at least it seems to be tagged with "formerly known as ..."