How can you stop the "All" category from being enabled by default?

[rkg82]

Is there any way to prevent the search page from opening with the "All" category enabled by default? My users typically want to enable a specific category when they load the page, and currently they have to manually disable "All" before being able to restrict the search to a sub category.

[David]

If you link to the search page with the category number in the URL, then you can pick the default category.

Like this URL
http://www.passmark.com/search/zoomsearch.php?zoom_cat%5B%5D=1

[rkg82]

Thanks for the tip, I can see how it could come in handy. But in my case I can't predict which category a user would want to search first. I was hoping there was something that could be configured in the scripts: for my purposes, having the search form open without ANY category enabled would be ideal. If this is not currently possible, would you consider for a future release?

[David]

I am assuming you have the "Allow searching in multiple categories enabled"?
Do you need it enabled?.

I think it makes sense to force the user to search either 'everything' or 'something'. Allowing them to select 'nothing' doesn't make sense unless nothing means the same as everything. If nothing is everything, then maybe everything isn't required? But is the extra click really that onerous?

[rkg82]

Yes sorry, I forgot to mention that I have multiple categories enabled. Although our users often search in only one sub-category, they often need two.

While I agree that selecting nothing means searching everything, in our case, because of the range of distinct, unrelated content servers our sub-search categories point to, our users will basically never use the ALL filter, except for testing or playing around with the first time they use the search dialog.

The users are support engineers who typically run searches dozens of times an hour, all day long, as they field customer support queries, so the extra click to disable ALL has been reported by several as being a nuisance, which I think is understandable.

More fundamentally, based on my observations of how they use the dialog, I think the real issue for them is that when the page opens, they have the search category in mind already, and a customer waiting on the phone or in a chat session for an intelligent reply: that added stress instinctively pushes them to locate and enable the sub-search category, the result is that both ALL and the sub-search categories are enabled simultaneously, and the search interface appears to be in an illogical, incoherent state.

This makes the users hesitate a second before disabling ALL, or worse, they forget ALL is also enabled, and launch the search, and are flooded with tons of unrelated material, again with a customer waiting on line. So they start over, and sometimes make the same mistake again(!), because of the stress, I expect.

I haven't got access at the moment, but I think I recall that the default behavior in the Zoom search dialog is to automatically clear any enabled sub-search categories as soon as ALL is enabled, and my users expect the opposite to hold true as well. I think it's a fair point, don't you?

[Ray]

I haven't got access at the moment, but I think I recall that the default behavior in the Zoom search dialog is to automatically clear any enabled sub-search categories as soon as ALL is enabled, and my users expect the opposite to hold true as well.

At the moment, Zoom does not automatically clear any check boxes, regardless of which box is checked by the user. So it is up to the user to unselect any already selected check boxes, to make sure it doesn't conflict (e.g. selecting "All" AND a specific category would not make sense). Otherwise, "All" takes precedence in the query and the rest is ignored.

The reason for this behaviour (the lack of an auto unselect) is historic -- when we introduced the feature, Javascript was still considered an "optional" part of the web. There were still platforms, such as Internet Kiosks, and more security conscious browsers that would have Javascript disabled. By using Javascript unnecessarily, you not only risk incompatibility on platforms, but you also risk conflicting with other JS on the page. So as a method of good practice, web tool developers tends to avoid introducing unnecessary JS, to allow for the most wide reaching coverage and compatibility.

Now, it is safe to say that JS is as "required" a part of the web as CSS or HTML. And users in general are much more accepting/expecting to deal with JS conflicts should they occur.

So yes, we agree that it would be useful to have checkboxes that conflict with the user selection to automatically unselect and avoid the users making the mistake. So that checking a category will unselect "All", and clicking on "All" will unselect the other categories.

We've added this to our todo list, and it will probably be a few weeks before we finish off the other priority items we have and get this in a new release.

[rkg82]

Thank you very much for the detailed background and the decision to modify the behavior for a future release.