On 21 Feb 2013, at 12:36, Andrej Golcov <[email protected]> wrote:

>> I think we can safely remove the tabs along the top (Ticket, Wiki,
>> Milestone) since that's filtering by type - and we can already to that via
>> the Facets.
> There is one thing that is stopping me from completely agree on this
> subject. If tabs is removed, current type should be reflected in
> search breadcrumbs similar to current facets drill-down breadcrumbs.
> That means that switch between search of different types is not so
> obvious and require more actions.

I agree that it should be displayed as part of the current facets selection - 
but I think the breadcrumb isn't the right place for that until users can 
change selects there too, which dilutes the purpose of it a bit.

I believe we should have a small section showing currently applied facet 
selections and an option to change them above or below the available facets.

This is key for the design I have in mind for custom queries (think Boolean 
facets), sorry for not sharing it yet. I will do that today.

> 
>> (I assume the search box will also disappear from the page when this is
>> search is set to be the default, since it's already available in the meta-
>> navigation.)
> Not necessarily.
> Let's name top search in meta-navigation as "quick search box" and
> search within search page as "advanced search".
> Advanced search form contains quite a lot of hidden fields like active
> search type,  sort, filters, etc. There are also idea to add product
> selector, may be fields selector, sorting selector etc. So I'm
> thinking about leaving these two search boxes (similar to how it is
> implemented in Trac and Jira) but advanced search should be visually
> different to avoid user confusing. Text posted from quick search box
> should resulted in advanced search box.
> What do you think?

I believe there should be only one search box, with optional advanced filters.
Both current search boxes (in their nature as an <input> fields) only allows 
for the same type of input (strings) anyway. Using a second search box to 
filter the set of results further doesn't seem intuitive to me, since common 
user behaviour in negotiating their query would be to just adjust their initial 
input. I would also encourage further filtering to happen in a structured way 
(like Facets) since that has more predictable results an draws attention to 
patterns that users may struggle to discover otherwise.

As for how they work, I would suggest that the quick search box can submit the 
same hidden fields when triggered on the search page.

> 
>> 
>> I will raise separate tickets to make the "View as Grid | Free text"
>> option more obvious, improve styling a bit and to enable the functionality
>> needed to achieve feature parity with the custom query tool.
> I imagine that such functionality can be represented as kind of
> toolbar just above search result , something similar to gmail toolbar
> above mails. Later we can introduce more pluggable actions, views,
> multi-select functionality with batch action support.

Sounds good.

> 
> Regards, Andrej

- Joe

Reply via email to