Community
Participate
Working Groups
This bug is for suggestions on how to improve the UI for search scopes, criteria and filters. UI has just been added (today) to Eclipse to support filtering and criteria in the help webapp. Historically two of the major complaints about the webapp usability related to setting search scopes and the "Show all topics" button, both of which have been modified as a result of this work. We have time in Eclipse 3.6 to address some of these old issues and ensure that the new features are easy to use and understand.
Created attachment 159356 [details] Screenshots of new UI
I think the 4th dialog in the list (entitled 'New Search List') could use some work - though I am having some trouble thinking of an elegant solution. We need to clarify the relationship of the checkboxes on the right hand side. A label like 'Include help containing the following criteria' might be helpful above the tree view. We also want to make sure users understand what happens to 'Uncategorized' content. I am assuming that uncategorized means that a topic does not have a particular criteria name (like product) associated to it, and so if you are filtering by product, all topics without product would be included or excluded based on the 'Uncategorized' check box.
Here are some of my thoughts on changes which could improve the UI 1. There is a checkbox in the show filters dialog for "Hide topics for capabilities that are not enabled". This is the replacement for the "show all topics button" which has long been a source of confusion for customers and the new checkbox is I think slightly less confusing but it would be better to get rid of it completely. Usually all capabilities are enabled so the button does nothing. We could instead have the default search scope only include the books for enabled capabilities. 2. There is another checkbox in the show filters dialog for "Hide topics not in active search scope". This switch turns on and off filtering of the table of contents and index when the search scope is changed however I think it would be a better user experience if we removed this checkbox and always filtered the Toc and Index using the search scope, which would be renamed to "scope". If we do want to keep the checkbox it should be moved to the search scope dialog. 3. The new search list dialog does not seem intuitive - will users understand the relationship between the left hand side and the right. I also find it strange that in the left half selecting nothing excludes all topics, in the right half selecting nothing causes no filtering by criteria to be performed. 4. In some ways search scope is like a preference however it is harder to navigate the dialogs than a preference page because first you have to create a new search scope and then edit it. Allowing multiple search scopes is a useful feature for some users but we should see if there is a way to make it easier to set the search scope when you do not have multiple scopes. I don't have a good UI design in mind but this has historically been an area of confusion for users.
Comment 14 on Bug 223475 describes how to turn on criteria and there is also a test bundle attached to that bug report.
Susan, can you take a look over this and let us know what you think? We are working on the assumption that the UI will be reworked to some degree in M7 and we are looking for as much input as we can get before starting on that.
The tooltip for the button could read as "Filter Topics" or "Filter Contents" for clarity. I agree with Chris Goldthorpe regarding checkboxes, and the "Hide topics for capabilities that are not enabled" label could change to "Only show topics for available features" - as opposed to using the term "capabilities," which is straight-up strange. Also would this checkbox work better in the UI in the 4th image? Just an idea to save users another click in case they want to leave that option on. Regarding the 3rd UI, it is unclear to me whether you can select (1) only one topic at a time, (2) the whole set of topics or (3) some or all of the topics available on the list, so maybe for (1) say "Search only one of the following topics," (2) leave it as is, or (3) say "Search only the topics selected below" To ellaborate on both Chris' suggestions, both columns in the 4th picture are clearly related, but is it an AND or an OR relationship? If I select from one column, will the other one be considered too? Maybe the label on the second column could read "Search selected topics based on the following criteria: " - or something along those lines? Also, could "Uncategorized" read as "Other"?
We've had this UI run by some of our users and here are initial reactions: 1) In the Results view (TOC or search results or index), there needs to be clear indication whether it's currently filtered or not, along with a UI control to influence the filter. It's too easy to forget that some filter had been applied and then be surprised that some expected content is not there. Consider Google Picasa for instance: When I apply a filter like "Starred Photos only" then (1) that filter pushbutton remains pushed, and (2) I get a big green banner with a "Back to Show All" button in the search results view. The "Show All" metaphor is much more important than all other filtering capabilities. 2) Many users may want to FIRST search and only THEN filter if there are too many search results. Why should I take the effort of clicking together a complex filter when I don't even know whether it will work as expected? I could even imagine a workflow where I pick an item in the results view and choose "hide related". A dialog could show me criteria related to this particular entry. I could select those that I want to get rid of and have all "similar" entries removed from my search results. 3) When influencing the filter after the fact (ie after a search, or after drilling down a TOC just to see that an expected element may be filtered), the selection should be maintained if possible. Currently the entire TOC is rebuilt when changing a filter. I found this extremely disruptive. 4) It is confusing to have two filter controls (search scopes and filter). There should be only one filter control. In terms of the dialog, I could imagine a left hand side listing filter types ("Filter by") plus right hand side for editing details/attributes of selected filter. For instance, left hand side could have: (1) OS (2) Topic List and the right hand side for 1 could be AIX/linux while the right hand side for 2 would be the familiar 2-level topic tree. 5) The term "capabilities" is meaningless to most end users. I also noticed that in a standalone infocenter application, the capabilities filter is not there (which makes sense since there are no triggerpoints etc since there is no UI). The previous "some content filtered, click here to show all" metaphor was less explicit but also easier to grasp. With a UI selection dialog as described in (4) above, we could have left hand side "Capabilties" with right hand side listing each Capability just like in the Preference page.
Thanks for the great feedback Martin. We started addressing a few of these issues in M6, for example the "filter" dialog is now gone. We also always filter all the views together. Here's some more specific comments in response so your 5 recommendations. Item 1: Showing an indication that results are filtered. I agree 100%, I've made the mistake myself of forgetting what scope I was in. Adding show all next to the filtered view sounds useful. Item 2. This is a very common search scenario, you search and get 100 matches and don't know how to pick one so you set a filter. The problem is that the user probably does not know what the characteristics of a good filter would be. I have toyed with the idea of being able to show a table of contents which only contained the search hits for a specific search but can't quite figure out how it fits in. Using M6 is you change the scope it will refilter the results and show the same view that was showing before. Item 3. It would be preferable if refilter did not collapse all in the toc but collapse all make the implementation a lot easier. Refiltering the toc without collapsing the nodes would add a lot of extra work which there is not time for in 3.6. Item 4. Yes two filters controls is totally confusing so we decided to eliminate the filter dialog. As of M6 there is only a scope dialog. Right now criteria are exposed in the UI but filters are not. Filters can be used in scope parameters to an infocenter, with the idea that an infocenter with many products can present different views of itself by using scope parameters to filter by role or by product. This means that as of M6 there is no UI to turn filters on and off and we're trying to figure out if that is acceptable of whether we should reintroduce the UI to set filters in the scope dialog. From the users perspective if we can treat filter and criteria as being slight variants of the same idea and with the same name it will make the UI easier to understand. Item 5. Yes capabilities is meaningless. The show all topics button which it replaces was never very useful because most products already have all or nearly all capabilities enabled and it's not clear that the user does not want to see the documentation for those capabilities. The warning dialog when you pressed show all topics was totally confusing. I have removed the show all topics button and now there is no filters dialog there is essentially no replacement. I do not expect that users will be complaining about the loss of this button but I will be watching the bugzilla inbox for feedback.
(In reply to comment #8) Hi Chris, you are making very good points. Here's some more comments: > Item 2. Filter after the search. > I have toyed with the idea of being able to show a table of contents > which only contained the search hits for a specific search Nice idea! This would be exactly the same as Eclipse Search has with the "Flat List" vs "Show Hierarchy" button to switch presentation of search results. Having search results in hierarchy (plus ability to quickly switch presentation mode) might effectively make the need for post-filtering go away since I'd see search results nicely categorized. > Item 3. It would be preferable if refilter did not collapse all [...]toc but > collapsing the nodes would add a lot of extra work which there is not time > for in 3.6. You mean YOU don't have time, right? But there's more people in the Community :) Can you file a bug for this with some initial thoughts how and where this would need to be implemented, and we'll have a look whether we can contribute for 3.6. Essentially, when the UI for filters remains unexposed in 3.6 there will not be a need for this anyways; on the other hand, having the initial description tracked in bugzilla will not be lost work since it can be picked up in 3.7 if needed. We will consider whether we need the filter UI or not. > Item 4. As of M6 there is only a scope dialog. Right now criteria are > exposed in the UI but filters are not. Filters can be used in scope > parameters to an infocenter I will check whether this is sufficient for us or not. Given that we now have a dynamic CriteriaProvider, criteria might be sufficient for 3.6. I do assume there is API to enable/disable a filter in the IDE, even though there is no UI for it? Not having a UI for filters has the advantage that there is better chance to have the internal Search View get back to provide the same functionality as the infocenter (bug 303104). This inconsistency between the "internal" and "external" view was another thing that heavily bugged our users. I had not commented on this yet, because I did understand the lack of time and I do understand the need to polish the webapp first to do exactly what's needed and only then port the same to the internal view. > Item 5. Yes capabilities is meaningless. The show all topics button which > it replaces was never very useful If we get back an "is filtered / show all" as per item 1, it will also cover this comment but in a better fashion. I agree that a warning dialog is meaningless here.
(In reply to comment #9) > (In reply to comment #8) > Hi Chris, you are making very good points. Here's some more comments: > > > Item 2. Filter after the search. > > I have toyed with the idea of being able to show a table of contents > > which only contained the search hits for a specific search > > Nice idea! This would be exactly the same as Eclipse Search has with the "Flat > List" vs "Show Hierarchy" button to switch presentation of search results. > Having search results in hierarchy (plus ability to quickly switch presentation > mode) might effectively make the need for post-filtering go away since I'd see > search results nicely categorized. Your comment on item 3 may be applicable to item 2, i.e. if someone had time to do this it would be cool, but that person is probably not me. It seems to have some of the characteristics of something that could be contributed, i.e. not likely to break the rest of the code. > > > Item 3. It would be preferable if refilter did not collapse all [...]toc but > > collapsing the nodes would add a lot of extra work which there is not time > > for in 3.6. > > You mean YOU don't have time, right? But there's more people in the Community > :) Can you file a bug for this with some initial thoughts how and where this > would need to be implemented, and we'll have a look whether we can contribute > for 3.6. Essentially, when the UI for filters remains unexposed in 3.6 there > will not be a need for this anyways; on the other hand, having the initial > description tracked in bugzilla will not be lost work since it can be picked up > in 3.7 if needed. We will consider whether we need the filter UI or not. It's actually a non trivial piece of work because the DOM of the toc view contains only the nodes that are shown based on the active filter or were once shown and then collapsed. When you click on the expand button an Ajax call is made to the server. For everything you can do in the toc view there is a corresponding server side piece. Refiltering could cause any of the following to happen - new nodes to get added, nodes to get removed, leaf nodes to become branch nodes, branches to lose their leaves. One way to refilter would be to crawl the tree on the client side and for each node starting from the top ask the server what children that node has and whether each is a leaf or branch, fix up the children and keep working down until all the branches had been handled. Another way would be to have a list of nodes which were expanded before the filter operation and after reopening the tree expand the same set of children. A poor man's solution which would be better than nothing would be to remember the selected node and make sure that was selected after the rescope (if it was in scope).
(In reply to comment #10) > > > Item 2. Filter after the search. > > "Flat List" vs "Show Hierarchy" button to switch presentation > if someone had time to do this it would be cool, but that person is > probably not me. Unfortunately I don't have any web / ajax programmers available so we also won't be able to contribute in this area. I'd still hope that if a separate bugzilla item is filed with "helpwanted" which clearly explains what is needed along with some initial ideas how to get started, there might be people found to contribute. > A poor man's solution which would be better than nothing would be to remember > the selected node and make sure that was selected after the rescope (if it was > in scope). I think we could live with this poor man's solution.
I have got some more feedback from our techpubs and UA experts, and they have established the following must-have priorities: 1. The user must be able to see at a glance that a filter has been applied. 2. It must be obvious how to turn on, configure, and turn off the filter. 3. Bug 303104 The filters must function identically between the help view and help in a standalone browser. For items 1 and 2, I think we're already in basic agreement as per Item 1 in comment #8. Our users also suggested the following: "This could be analogous to the way shopping web sites are set up, where I can easily see how I have restricted my search results (for example, Cameras > $200-$300 > Canon) and I can easily broaden or remove that filter." For item 3 aka bug 303104, we could potentially contribute something, but it does not make sense for us starting to work on this until the filtering UI and concepts are clear in the webapp. So this opens two questions, (a) how fast can we come to a consensus on the webapp UI, and (b) how long will there be time to contribute filtering UI to the help view. The other issues I have mentioned before have either been addressed already (eg duplicate filter vs scope UI, capability filter), or they are perceived as nice valuable additions but not strictly must-have. I have created separate bugs to follow up on these two: 4. Bug 305828 When changing a filter, maintain selection if possible 5. Bug 305829 Switch search results between flat and hierarchical view
(In reply to comment #8) > eliminate the filter dialog. As of M6 there is only a scope dialog. Right now > criteria are exposed in the UI but filters are not. Filters can be used in > scope parameters to an infocenter When the infocenter is started with such a filter as scope parameter, the search scopes picklist must also be filtered. Otherwise there is a chance picking an item in the search scopes picklist which will never be available in results since it's filtered. Is this already done?
(In reply to comment #13) > (In reply to comment #8) > > eliminate the filter dialog. As of M6 there is only a scope dialog. Right now > > criteria are exposed in the UI but filters are not. Filters can be used in > > scope parameters to an infocenter > > When the infocenter is started with such a filter as scope parameter, the > search scopes picklist must also be filtered. Otherwise there is a chance > picking an item in the search scopes picklist which will never be available in > results since it's filtered. Is this already done? Good point, I have filed Bug 305893 to cover this.
(In reply to comment #7) > We've had this UI run by some of our users and here are initial reactions: > > 1) In the Results view (TOC or search results or index), there needs to be > clear indication whether it's currently filtered or not, along with a UI > control to influence the filter. It's too easy to forget that some filter > had been applied and then be surprised that some expected content is not > there. > Consider Google Picasa for instance: When I apply a filter like "Starred > Photos only" then (1) that filter pushbutton remains pushed, and (2) > I get a big green banner with a "Back to Show All" button in the search > results view. The "Show All" metaphor is much more important than all > other filtering capabilities. > I have created Bug 305895 - [Webapp] Need an indication that a filter has been applied to track this. At this stage I think all of the changes which we want to see in 3.6 have been split off into their own bug reports.
I'm closing this bug because the ideas which came out of the discussion have now been captured in five new bug reports: Bug 305895, Bug 305893, Bug 305829, Bug 305828 and Bug 303104. If there are other important issues not covered in those 5 bug reports we should create additional bug reports.
It should be mentioned that the filtering dialog, which much of this discussion has revolved about, has been removed again in Eclipse 3.6M7 through bug 304886 . Bug 291105 follows up on the work for help filtering UI in the Eclipse 3.7 time frame.
