Community
Participate
Working Groups
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; CIBA; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022) Build Identifier: Now, quick search support 'search this topic and all its subtopics', add enhancement of only 'search this selected topic'. Now, there are 3 solutions on UI design. You can view the mockup pic from the attachments. 1. List 'search this topic' and 'search this topic and all subtopics' in the menu of search. 2. List these two items in pop-up dialog. Enable user to choose 'search this topic' or 'search this topic and all subtopics'. 3. List only one item 'search all subtopics' in dialog. By default, it will only search this topic. If user select this check box, then it will search this topic and all subtopics. Reproducible: Always
Created attachment 150890 [details] Mockup pic for solution 1
Created attachment 150891 [details] Mockup pic for solution 2
Created attachment 150892 [details] Mockup pic for solution 3
Of the three solutions I like solution 2 the least, the text is likely to overflow if the font is larger. For solution 1 you should be aware of Bug 189728, which affects the dropdown for the print menu. I'm guessing that the main reason someone would use search topic but not subtopics is to turn on highlighting in that one page - is that correct? In any case I expect that most of the time users want to search the subtopics so I would suggest that in solution 3 the default should be to have "Search all subtopics" selected. My personal preference as someone who finds search selected topic and all subtopics more useful than search selected topic is that solution 3 with a default of search subtopics is the easiest to use, and one less mouse click compared to solution 1. I don't feel strongly about this and would eb interested in hearing more opinions.
(In reply to comment #4) > Of the three solutions I like solution 2 the least, the text is likely to > overflow if the font is larger. > > For solution 1 you should be aware of Bug 189728, which affects the dropdown > for the print menu. > > I'm guessing that the main reason someone would use search topic but not > subtopics is to turn on highlighting in that one page - is that correct? In any > case I expect that most of the time users want to search the subtopics so I > would suggest that in solution 3 the default should be to have "Search all > subtopics" selected. > > My personal preference as someone who finds search selected topic and all > subtopics more useful than search selected topic is that solution 3 with a > default of search subtopics is the easiest to use, and one less mouse click > compared to solution 1. I don't feel strongly about this and would eb > interested in hearing more opinions. I think that solution 1 is the clearest one. User can fully understand what the search scope is. Solution 3, do you mean that the item should be 'search all subtopics' in dialog, and it should be selected by default. So it will search selected topic and all subtopics by default. Then I wonder whether users could understand that it will only search this selected topic if they unselect the checkbox. I think that they will be confused about that.
I can see your point. I'm fine with whichever of those three options you choose.
My preference is solution 1, too.
Created attachment 153344 [details] Additional button image
Created attachment 153347 [details] Patch V1 This is patch V1. And I also submit a button image as the attachment above. Please place it in org.eclipse.help.webapp/advanced/images and do not modify it's name.
Now, function 'search the selected topic' is relealized. But topic which is automatically generated as '.../nav/..' is not supported. Cause search index of such page is never existed. And another question, I observe that there is a method called 'saveState', I wonder what its use is. So in the class AdaptableSelectedTopic and AdaptableSelectedToc, I leave this method blank. Can you give me an instruction?
The patch is good and I have committed the changes to HEAD. During testing I discovered a bug, which is not a regression but was present in Eclipse 3.5. I have opened Bug 296506 – [Webapp] Quick search of Toc only searches subtopics. I think that for the new classes you added saveState() will never be called, can you verify that by setting a breakpoint in that function and performing a quick search. Currently nav pages are not added to the search index and so when you perform "Search selected topic" on a "nav" page you will never see any results. One possible solution would be to show a warning dialog to the user to say that there will be no matches because this is a generated page, however I think that would be confusing to the user because they do not know that some pages are generated. The other option would be to add the nav pages to the search index.
Hi Chris, I've fixed Bug 296506. And after debugging, I've verified that function saveState() in the new class is never called. I also think users would be confused about the auto-generated topic. And I also wonder whether it's a good solution to add the nav pages to the search index.
I opened Bug 296648 for the failure to find search hits in nav topics.
