Bugzilla – Full Text Bug Listing
| Summary: | [Help][Search] Help Contents UI enhancements (involving search scope) | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Jamie Liu <liuj1> |
| Component: | User Assistance | Assignee: | Chris Goldthorpe <cgold> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | cgold, ChrisAustin, gayle_thiel, kevin_macdonald, liuj1, mober.at+eclipse, raji, stevenma, zhhaohh |
| Version: | 4.0 | ||
| Target Milestone: | 3.7 M7 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | 303105, 332978, 340096 | ||
| Bug Blocks: | 326001 | ||
| Attachments: | |||
|
Description
Jamie Liu
Created attachment 177968 [details]
Proposed design for Help search scoping UI
When a user opens the help (either from Help > Help Contents or from the help menu of a plug-in), the help is automatically scoped to that product. If possible, this default scope should also include simultaneously searching appropriate IBM web sites on the search term the user enters. Eclipse Help already has the capability for an user to specify a web site as a scope--we would like to pre-specify one or more and have them be part of the default scope.
Created attachment 177969 [details]
Proposed dialog for user to create a new scope
If the user wants to change the scope, she can select the drop-down list next to the search box and select a different scope.
If the user wants to create a new scope, she can select the Create New Scope option at the bottom of the dropdown. That brings up the following dialog box:
"?" Help text: "Your scope can include more than one product area."
NOTE: This dialog already exists in the current help search , we just need to change the one label to "Scope name" and the dialog box name to "Create New Scope," and add a "?" for hover-help.
Created attachment 177970 [details]
Help search dropdown after user adds new scope
After the user creates a new scope, the search is scoped to that new scope, and the new scope appears in the drop down list.
SUMMARY OF PROPOSED CHANGES: -Detect the context Samantha is in when she clicks Help > Help contents (or selects Help from a sidebar plug-in), and automatically set the search scope and the landing page to that section of help -Remove "Search" from in front of the search box, and "Search scope: <scope>" from after the search box -Insert gray text "Search <product area>" into search text field. -Add a drop-down list next to or from the search box with a list of all the top-level help sections (populate this with all the help sections the user has, but that's it -- i.e. if Samantha has Designer, that will appear, but if she doesn't, it will not) -Add a last option to the drop-down list: "Create search scope" -Connect the correct dialog box up to that menu option. -When a user creates a new scope, add it to the search drop-down menu, and automatically scope the next search to that new scope. Question: Should we also have a "delete scope" option in the menu if the user creates too many new scopes? The user would only be able to delete scopes that she had created. PERTINENT EXCERPTS FROM NOTES USABILITY REPORT: 1) Users noticed the delay upon first use of Help Search -- both when they accessed help search through the big window and when they accessed it via Help > Search (the Help pane). The reaction was worse in the Help pane, because there is no message explaining that it is indexing and will do so only once. "The search is taking awhile..." (SD1, Help pane) "Search seems a little slow." (SD6, Help pane) "The user shouldn't have to wait for indexing..." (SD4, big window) "Indexing seems OK, didn't take too long" (SD3, big window) Recommendation: Pre-index the Notes doc plugin. Status: Rough scoping this dev task so we can include it in RET proposal 10/9 2) When using Help Search to locate a topic, users don't know (or don't like) that the topic they open is from a component other than Notes User is trying to create a section in Notes but is misled trying to follow a Symphony topic about sections (SD1) User searches on "widgets" -- he is disappointed that the first two hits involve Symphony. (SD5) Recommendation: Make the default search repository the component that the user launches the search from, with the ability to easily choose a different repository from a drop-down list. (Note: users were shown a mock up of this new search design at the end of the test...the reaction of all six users was strongly positive.) Status: Rough scoping this dev task so we can include it in RET proposal 10/9 3) Users don't understand what the "Search scope" text link is. User click on link but does not use it, says she was looking for an advanced search option (SD3) When asked what he thought "create new search scope" meant, he replied "a feature for saving a specific search." 4) Topic titles that did not match users' mental model caused users to skip over the correct topic in search results. Examples of titles that didn't match users' mental model were "Adding a group entry to your contacts" (users were looking for "create groups") and "Customizing a replica" (users looked for "preferred server," "mail replication," "replication options"). 5) Relevancy InfoCenter "gives him headache" -- the search is not that great, Google does a better job searching within the InfoCenter than the InfoCenter search does. (SD4) 6) One user went to the Search field in Notes expecting that it would search Help (SD2) 7)One user said "Have Help Search search Knowledgebase, too." (SD4) One thing which I notice is that the typein area for the search word is also used as a dropdown for the search scope. Am I understanding that correctly? If so it would be confusing to users because usually a typein with dropdown ( aka combo box ) is used for only one field. Jodi Rexford (UX), with guidance from Mary Beth Raven, was part of the group who came up with the design -- we did it that way because it was similar to the way Search in Notes itself now works (though Notes does it with both an icon and grayed out text, the drop-down arrow being associated with the icon, as in "Search all Mail," "Search Calendar", etc.). I'm sure usability data must exist for the feature in Notes -- let me know if you'd like me to look for it. Firstly, I think provide default scope is really necessary for end users. But I have the same concern with Chris. Cause now the input box is used for typing in search key words (If possible, we should list some similar words when user type in, just like google does, when user type 'a', maybe 'apple' will be shown in the drop down list). But scope slection is not proper to place here. User will be confused about that. And another reason is that, now scope selection will take effect on TOC/Index/Search. So it is not proper to place in search function. Maybe a seperate scope selection input box is a better way. Also one 'delete icon' is necessary to list behind scope items which are added by users themselves. So that user can have management with their scope setting. We wouldn't be able to use icons to represent sections of help (help plugins) because not all sections are very disinctive (for example, composite application catalog in Notes), and thus the icons would not mean anything to users... One other point: we should try to avoid using the word "scope" -- I remember hearing from Notes UX that many end users do not understand what that means. So, if we have to use 2 boxes, we could do something like: Search ______________________ Go (for entering search term) Search in [default plugin name]V(dropdown arrow) -- where default would be displayed and they could change it using dropdown list. On hover over the dropdown could say "Change which help to search" For adding their own scope, we could call that list item something like "Multiple items on this list" The Notes usability specialist also suggests, if we could use only one field, that adding a square border around the dropdown arrow, possibly with a different background color behind the arrow, and putting the "on hover" explanation over the arrow would help users understand what it does. Just FYI, this just in from Notes Usability specialist Sheri Branco: "I do have some data from a past test that indicates users didn't have a difficult time with the single search field or the scope drop down: From Notes 8.51 Beta Refresh testing at Raytheon: Users used the drop down/scope easily in the search field In the notes from the Notes 8.51 tests, it also indicates that we thought "scope" was going to be changed to something like "options". When we ran some tests on Search designs/prototypes at Lotusphere and SDR (both 2009), we did hear that "scope" was exactly intuitive." So, my info about "scope" above was not the latest. Gayle Gayle, can you look at Bug 325801 - [Help] Fast scope switching. It seems like a similar request, do you agree and if so do you like the design proposed on that bug report. Chris -- Yes, 325801 is same issue. We don't have a problem with the initial UI layout shown there, but we do think it needs to be more prominent and that the help plugins in the system should automatically populate the drop-down list (rather than users always having to create scopes), and that the default scope should be the plugin whose component user was in when help was called. Consider underlining scope only on hover with a popup explanation of what scope means. Also, if the backgound of the scope field were white, it would appear more prominent. Is the target milestone correct, ie is this really going into M4 ? This will probably not get completed in M4, changing milestone to M5. As a product builder, the following are my top requirements for improved help scoping UI:
1.) Being able to pre-define some scopes in my product for the user to choose.
In the proposal, TOC categories (1st level TOC entries) seem to be
implicitly used as predefined scopes, plus user can manually define some.
I would like to programmatically register some predefined scopes that go
beyond TOC categories - similar to the org.eclipse.base.help.scope extension
point in 3.6 [1].
2.) Being able to define a default scope in my product (plus ability for the
user to easily override and "show all"
3.) Ensure that the Help Webapp and Help View are consistent in terms of
functionality, ie provide the same scoping mechanism.
Plus, I agree with the notes from comment #4 - especially regarding relevancy of search hits, I'd very much hope that the newer Lucene improves the situation in Eclipse 3.7.
[1] http://help.eclipse.org/helios/topic/org.eclipse.platform.doc.isv/reference/extension-points/org_eclipse_help_base_scope.html
(In reply to comment #15) > As a product builder, the following are my top requirements for improved help > scoping UI: > > 1.) Being able to pre-define some scopes in my product for the user to choose. > In the proposal, TOC categories (1st level TOC entries) seem to be > implicitly used as predefined scopes, plus user can manually define some. > I would like to programmatically register some predefined scopes that go > beyond TOC categories - similar to the org.eclipse.base.help.scope > extension > point in 3.6 [1]. > Some thoughts (for what its worth) Although we don't currently have a filter UI in Eclipse, we have worked around this in Rational by creating our own ui (it can actually sit right inside its own help topic) to list the scopes we have programtically created using the filtering API. > 2.) Being able to define a default scope in my product (plus ability for the > user to easily override and "show all" Eclipse 3.7 will also have a mechanism to override the Help URL (Bug 300709) where theoretically you could choose to launch the help using a scope built with the filtering API. Interesting! For changing scopes, I had already thought about a similar approach, ie dynamically contributing TOC entries with a URL onClick handler in order to provide controls for scoping. But I refrained from further exploring this because it felt much like mis-using the TOC concept for sneaking in some controls... I'm thus much looking forward to the outcome of this request. Is there a plan / proposal already what might get implemented with 3.7M5 ? Regarding bug 300709, my concern is that when help gets opened with a ?scope=foo parameter, user would remain locked into that scope without a UI/Control to get out of it any more. To me, the "Show All" gesture is very important for any user who doesn't find in the limited scope what he's looking for. Also, it doesn't address the problem that webapp and help view really need to provide a consistent path into help. Today, the view supports activities but no scopes custom scopes, while the webapp supports custom scopes but no activities. What's the path forward getting these unified? (In reply to comment #15) > As a product builder, the following are my top requirements for improved help > scoping UI: > > 1.) Being able to pre-define some scopes in my product for the user to choose. > In the proposal, TOC categories (1st level TOC entries) seem to be > implicitly used as predefined scopes, plus user can manually define some. > I would like to programmatically register some predefined scopes that go > beyond TOC categories - similar to the org.eclipse.base.help.scope > extension > point in 3.6 [1]. > > 2.) Being able to define a default scope in my product (plus ability for the > user to easily override and "show all" > > 3.) Ensure that the Help Webapp and Help View are consistent in terms of > functionality, ie provide the same scoping mechanism. > > Plus, I agree with the notes from comment #4 - especially regarding relevancy > of search hits, I'd very much hope that the newer Lucene improves the situation > in Eclipse 3.7. > > [1] > http://help.eclipse.org/helios/topic/org.eclipse.platform.doc.isv/reference/extension-points/org_eclipse_help_base_scope.html About TOC categories being used as scopes, that's because the categories match up with Eclipse doc plugins. We had just assumed you could only scope by plugin. Created attachment 186445 [details]
Patch for display number of results found
I am starting to work on improving the search experience in the help webapp. This first patch addresses "Display number of results found" and has been committed to HEAD.
I've been examining the suggestions, have implemented one of them and would like to review the remaining suggestions. These are the 5 suggestions in the description A suggested solution could include: 1. have default scope options include the different top level TOC topics, and have the default scope be for the component from which you launch search 2. have a dropdown near the search field to allow the user to easily change the scope 3. continue to enable searching multiple components, but perhaps improve the Select Search Scope dialog 4. results when searching multiple components should be sorted by component by default (ie. the result of selecting "Show result categories" 5. Display number of results found, e.g., 1-10 of 35 (this is done in the help pane, but not the big help contents window) Item 5 has been implemented. Here are my thoughts on the other suggestions" Item 4. I don't believe that sorting by component should be the default because then the most relevant result may not be anywhere near the top of the results. If this is important to you then we could add a preference to allow a product to override the default. Perhaps the real problem is that users do not discover the two buttons above the search view and therefore do not use them. Item 2. I'm not sure a dropdown would work ( see previous comments ) because it does not allow a new scope to be defined. If defining a new scope is hard we need to think about how to make it easier. Item 3. Again anything which made it easier to change the scope would improve the user experience. Item 1. I wonder if creating an implicit scope might create more confusion as not all topics would be searched depending on what was selected. If the user did not realize this they would not find all the search results. I think that the problem we are looking to solve in this enhancement request is as follows: The user searches for a search term, a large number of results are returned and the user has no idea which one should be selected. The user wants an easy way to find the most relevant results. We have several mechanisms to help the user: sort results by category, show or hide descriptions, change search scope but the user either does not discover these mechanisms or finds them hard to use. I'm thinking that if we had some kind of a hyperlink or hyperlinks in the area above the search results this could help the user discover these mechanisms. The search scope dialogs do not make it easy on the user who just wants to change the scope. Currently to change the scope in a new workbench you have to set a radio button, click new and then edit the scope. If we could reduce the number of clicks required to create the initial scope this would also improve the user experience. What are your thoughts on all of this? This work will continue into M6, changing target milestone. I have fixed many but not all of the issues raised in this bug report so I am going to mark it as fixed. If you still feel that the other issues should be addressed please open new bug reports, one issue per bug report. Here is the status of the requests: - have default scope options include the different top level TOC topics, and have the default scope be for the component from which you launch search - have a dropdown near the search field to allow the user to easily change the scope For reasons explained in Comment 20 this will not be implemented. - continue to enable searching multiple components, but perhaps improve the Select Search Scope dialog Several improvements have been made to the search scope dialog, see Bug 332978 , Bug 333033. - results when searching multiple components should be sorted by component by default (ie. the result of selecting "Show result categories" There is now a preference which controls the default sorting algorithm. - Display number of results found, e.g., 1-10 of 35 (this is done in the help pane, but not the big help contents window) This is implemented. |