bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Dreimann <>
Subject Re: [Apache Bloodhound] #316: UI mockup for improved search prototype
Date Thu, 21 Feb 2013 14:25:52 GMT
On 21 Feb 2013, at 12:36, Andrej Golcov <> 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
View raw message