Community
Participate
Working Groups
Description: I'm using Eclipse InfoCenter (web and standalone version) and need to allow our customers to scope their searches down to our book level. I can't scope the searches to the level I want - even on the stand-alone version, even when I break down the toc into several sub-tocs. And, of course, I can't scope below the first level on the web version. What I want to see in the advanced search panel (or the search scope panel) is: topic 1 (cooresponds to a plugin) topic 2 (cooresponds to a plugin) topic 2 category 1 (first topic level in the toc.xml) topic 2 category 2 (first topic level in the toc.xml book name 1 (second topic level in the toc.xml) book name 2 (second topic level in the toc.xml) I want to scope down to the "book name" level. On the web version, I get just topic 1 and topic 2. On the stand alone version I also get "topic 2 category 1" and "topic 2 category 2" but no deeper. As the Information Architect for my product, I would really like to be able to determine the level of scoping that would best suit my information, however, even just adding another level to the stand-alone search and 2 more to the web version, would be great. System and versions: AIX 5.1, Eclipse 2.1 I'm looking at this only from the Help system perspective (Information Center)- not the entire framework.
Yes, there is a limit on the level of scoping in the help system. Workbench and stand-alone help have limit of scoping first two levels of topics. The scope is persisted between searches. If help is running as an infocenter, the limit is a first level of topics, and the scope is not persisted. At the moment we are planning to implement persistence in the infocenter scenario and align how scoping works with the infocenter scenario, i.e. to implement two levels of scoping for the next release. To completely solve the problem, a user should be allowed to scope to an arbitrary level, but this will require a redesign or how scoping is selected, persisted, and applied. Our current solution is a special case for the first two levels and will not scale the arbitrary level. It may take a while before it is implemented. Implementing another special case for the third level of topics does not make much sense, since there always will be a need for one more level. To work around the limitation, you can structure you navigation such that your books are really the books and appear as the top level topics in the navigation, if you can. It seems you are porting an existing documentation structured for another system. In Eclipse, there is no need to have a top level TOC for a plugin. Plugin is an internal artifact, that does not need to be exposed to a user. A plugin can contribute many top level books, or contribute a book that is integrated into a book coming from another plugin. The 2nd level - categories, can be omitted as well. If all of your current third level topics are books, and you make them top level books, they can be ordered by a help preference such that it make sense to the user. You can probably indicate which category the books was belonging to by adding category name part of the book label.
-1 I think that search interface should be simple, and having the user scope down many levels in a tree is a bit odd. It means the user really knows the structure of the entire help and would know where the topics are. That's a bit too granular and not very helpful for large documentation sets (which is the reason you actually search instead of expanding topic nodes). Two levels of filtering should narrow search enough, and I would prefer a good search engine that can correctly find useful results, as well as a well organized documentation set that makes uses of meta tag keywords and is well structured at the top two levels.
Support for working sets in the infocenter has been released for 3.0 M1. It provides the same 2 level scoping capabilities (a book and a category) for all workbench, stand-alone and infocenter. There is no plan to provide deeper search filtering. If it seems that there is a need for more filtering, the documentation structure should be changed. More complicated scenarios should be addressed by a different mechanism - like user roles that should be designed and implemented in the platform and in the help system.
Control over search scoping is a big customer satisfaction issue with our users. In fact, after customizable printing, it was the most significant issue our users wanted more control over in an information center interface. In competetive analysis surveys we have done, we've determined that at the current level of user control, search on Eclipse is not competetive with our main competitors . In order to be competitive, we need more granular and orthogonal search capabilities. And as the information architect for our product I want and need the ability to scope searches to the level that makes sense for our information. That Eclipse would arbitrarily set this for me is not acceptable. It is not reasonable to expect a complex information set such as ours to reorganize its entire data set to fit the needs of a tool. The tool should fit the needs of its users. I would like to see this feature included in a future version of Eclipse (even if not 3.0).
Carol, you mention that your main competitors have better online help search than the Eclipse help system. What help system are your main competitors using and (if you know) what is the underlying search engine?
I concur with Carol entirely. My org is experiencing the pinch of the restriction to 2 levels for search refinement, even after implementing the IC work-around. To end users, this shallow limit could seem like a constraint based more on fiat than actual technical considerations.
Changing title from "Increase level of help search scoping for both stand- alone and InfoCenter", to "Increase level of help search scoping" as integrated help, standalone help, and infocenter support the same 2 level scoping.
*** Bug 71860 has been marked as a duplicate of this bug. ***
*** Bug 76017 has been marked as a duplicate of this bug. ***
As our company moves to deliver more online documentation content via Eclipse infocenter, the 2-level search scope limitation is more critical. To make search scoping truly scalable (as necessary for infocenters in particular, where the docs might cover many "products," each of which has many components and many subcomponents), there really should be no arbitrary tree-level limitation. Ironically, our previous delivery platform (the now-defunct, SGML-based DynaText/DynaWeb) provided much more sophisticated search scoping. Our users now expect that level of functionality. Without more levels of search scoping, the Eclipse infocenter will be viewed as a step backwards in terms of basic functionality. This enhancement request has been pending for a very long time. Any chance of seeing movement in the foreseeable future?
Probably won't have time for this in 3.3, unless Chris or Adam want to take this on.
This request essentially requires that we write a Web CheckboxTree implementation. Chris did work on the Ajax-based TOC tree implementation in 3.3 but the timing is not fortunate. With only one development milestone to go, the runaway for stabilization is shrinking.
Agree with Dejan and Curtis's comments, unfortunately there is not enough time for this in the schedule.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
