*Request* Juniper.net search feedback

[Automate]

We are in the middle of a long-overdue evaluation of new search technology for our website. Among our goals are:

1. One-stop shop - search all content on the site, including for example J-Net
2. Robust filters - segment results by product, by source, etc
3. Better search relevance.
4. personalization - such as last n searches, etc
5. Speed and reliability - we know this is a big concern. 
6. Search part and model numbers
7. suggestions, hints, related concepts, etc

We'd love to hear from you! - the good the bad and the ugly - how our search is working (or not) biggest complaints or gripes you have - even compliments if you have them

Use this thread to comment and we'll reply in kind. The best possible feedback is specific examples - what you searched and where (main site search vs KB for example). The URL from the search results page would be ideal (that tells us all the parameters)

-Keith Redfield

eSupport

Juniper Networks

[spuluka]

I really only use search for the kb area.  In general the speed is the biggest problem.But this may be just the kb application itself because in general this just seems slow.

But I also find that the "natural language" question just doesn't work and casts way too wide a net.   So  I stick with the traditional key words.

I now pretty much use google with the site:kb.juniper.net restriction.  This is fast and produces good results.

What I really like on the technical support site is the organized links on the way in. The select a product that push out to a full  landing pages for each of the devices is well organized and I can usually find the standard information I'm looking for there.  This option should really be on the kb home page too.  I've found myself fumbling looking for it a few times before I remembered to go back to suppot home.

I also like the category and product browse functions on the kb.  These help locate general information pretty well.  A filter by product within catagory would be great.

I like that it keeps track of what I have read in the kb on the home page.  It would be nice if this also displayed in search results.  When looking around I am usually looking for either new information or finding an old note.  Having the reference of whether or not it as read before would help in both cases.

[Automate]

Thanks Steve, great feedback

re: Google - the only problem there is it can't pull up content which might have customer-restricted access. 

The KB is under constant tuning to avoid issues where it wanders too far - we just pushed another fairly comprehensive update out last week. This feature has it's good and it's bad points - it's really good at giving matched to say.."port forwarding" when much of our content only mentions "vip" (our command for it). But it does have a darkside - what really helps there is feedback on specific examples. 

Thanks for the other feedback as well - a couple of good ideas in there I think we can implement. 

Regards,

-Keith

[srigelsford]

Would it not be possible to have two KB databases, one with open content, and the other with restricted? It seems odd not to use google when it is already matured and proven.

One niggle I have with the KB is that it often duplicates results, for example, if I serch on a keyword my results are often the Concepts and Examples guides of 10 revisions of ScreenOS... Perhaps it could detect if it is displaying 'duplicate' results and limit them to the single best match. i realise the different revisions are not exact duplicates but you get the idea.

The other thing is that the KB is usually incredibly slow, often timing out altogether...

Sam.

[spuluka]

This is not exactly search but it is kb related.  Often when I search the kb I am working on fixing an issue encountered.

Is there a way to see a bug list that is active and the status of those bugs?

When a new version of ScreenOS is released the first place I go is to the list of resolved issues and see what is there.

It would be great when I go searching in the kb after having an problem is I could pull up a similar list of known issues and their current status. This would save tons of time beating a dead horse for those of us finding known issues.  Not knowing means I spend more time researching.  Then I call JTAC and they research again and find out it is already known.

This could

• link to the kb that has the work around
• note the os version where the fix was release
• note that the fix is pending for a release

[Automate]

@Sam

re: Duplicates - the system has a function for surpressing duplicates and at one time we had it enabled. Then people started asked for version specific results...so we're back to the drawing board on that.

re: Slow - we hear that. I'm playing on our new development box as we speak - once this new hardware gets deployed I think everyone will be pleased.

We can't mess with the current architecture - splitting into public and non-public. But I think this will all be moot with the new servers.

[Automate]

@Steve,

re: bug info - yes, we are working on that. What we have today is Junos only and frankly pretty crude (actually if you know the ID you can pull up WX bugs as well) https://www2.juniper.net/prsearch/simplesearch.jsp. There is quite a lot of work to do in terms of aligning processes and getting good clean data for automated systems. The good news is this has very high-level visibility inside the company and progress has already been made in improving internal systems to support the external tooling. ScreenOS, SSL, other products are probably a next-year item.

But..we are indexing the release notes as a discrete source now as a bit of  a beta test.  On the results page choose

Source - Documentation

           Release Notes

                 ScreenOS

(I notice some debugging filters got loose..pls ignore)

[stine]

Not to beat a dead horse, but I concur that the existing kb search is very slow.

One thing I'd like to see is the ability to search on a specific version, i.e. 9.6r4.1  because when I'm searching, like was sait above, I'm trying to fix a problem and don't need a match in every release since 1.0r1.0.     Does this already exist as in version=xx.xxRyy.yy ???

On the plus side, I want to thank you for fixing the search so that "VPN" was not a default, hidden search term.  It was so annoying having to remember to add "-VPN" to every query that wasn't for IVE products.

[Automate]

We're hoping to have the beta up in August so you'll be able to see the performance improvement. I have to confess I am tending to use our development system for my own searches since it's so much faster. 

You can already add a version string to your query - the KB will try to get the best match. But if there isn't a good match you might see some frustrating results as it will start matching on the individual terms like 9.6, R1, 4.1 etc

[Automate]

Well we missed August, but please give our new servers a try:

http://kb-beta.juniper.net/InfoCenter/index?page=home

(Note that this is a beta-test, so the KB content is from a snapshot taken on Aug 20, and we are still working through a few issues - see the README tab for a complete list)

We hope you notice the improvements, but please give us feedback (positive or negative) via the "KB Feedback" link you'll find on the home page of the new server.

This release is primarily focused on performance and reliability, but we have made enhancements to search relevance as well.

[Automate]

http://kb-beta.juniper.net/InfoCenter/index?page=home

(Note that this is a beta-test, so the KB content is from a snapshot taken on Aug 20, and we are still working through a few issues - see the README tab for a complete list)

We hope you notice the improvements, but please give us feedback (positive or negative) via the "KB Feedback" link you'll find on the home page of the new server.

This release is primarily focused on performance and reliability, but we have made enhancements to search relevance as well.