incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Dreimann <joachim.dreim...@wandisco.com>
Subject Re: Query Builder (Search / Custom Query)
Date Thu, 21 Mar 2013 17:14:13 GMT
On 21 March 2013 15:35, Olemis Lang <olemis@gmail.com> wrote:

> On 3/20/13, Joe Dreimann <joachim.dreimann@wandisco.com> wrote:
> > On 20 Mar 2013, at 20:53, Olemis Lang <olemis@gmail.com> wrote:
> >> On 3/20/13, Joachim Dreimann <joachim.dreimann@wandisco.com> wrote:
> >> [...]
> >>> On 14 March 2013 19:47, Andrej Golcov <andrej@digiverse.si> wrote:
> >> [...]
> >>>> We can set default product filter based on active product and use
> >>>> global search if user navigates directly to global search url - I
> >>>> think, Olemis suggested something like this.
> >>>
> >>> I believe search should always be global unless the user chooses
> >>> otherwise.
> >>
> >> what does this mean exactly ? Let's focus on the following situation .
> >> User reads let's say a wiki page in product P and searches for word W
> >> by using search input box in the header . In your opinion is there any
> >> value for getting results from other projects , even potentially not
> >> provide any result for the active project ?
> >
> > Yes.
> [...]
>
> My point is somehow similar to this :
>
> http://sourceforge.net/p/allura/tickets/?source=navbar
>
> In there you'll find focused product-specific Search Tickets box and
> broad Search box in body header . So user will choose search scope
> explicitly . The only difference being that our proposal for focused
> search (by default) should span over multiple resources (not just
> tickets).


There are other important differences.

For starters SF does not show the behaviour you propose on the many of
project pages: Search remains global [1], [2], [3], [4]. Even when the
local search boxes are offered, they are in addition to the main search
box, which still has global scope.

Although both boxes are called search, the local search you're referring to
is really a filter of information the user specifically sought out (like
ticket information contained in a product) and displayed in a local
context, unlike the global search box in the header.

To be clear: I have no objection in principle to us having a local search
box like this on our product pages, my objection is against changing the
scope of the search box in the header.

There are more meta reasons why this is a higher priority for SF than for
us though, I would argue:
- SF has a very very large collection of projects. Most deployments of BH
will probably end up with <10 products.
- SF projects are, for the most part, unrelated to one another in type and
developer group. That seems less likely for Bloodhound deployments in small
to medium sized organisations.

That means that I basically agree with you on user intents
> within product boundaries . OTOH I disagree on not to limit the
> (default) scope of search to active product . Systematically leading
> the user out of product boundaries is not a good practice afaict
>
> PS: I actually don't know whether the search box at the top is really
> part of Allura of a SF.net specific add-on .
>
> --
> Regards,
>
> Olemis.
>

[1] http://sourceforge.net/projects/allura/
[2] http://sourceforge.net/projects/allura/files/?source=navbar
[3] http://sourceforge.net/projects/allura/reviews/?source=navbar
[4] http://sourceforge.net/projects/allura/support?source=navbar

Cheers,
Joe

-- 
Joe Dreimann | *User Experience Designer* | WANdisco<http://www.wandisco.com/>

@jdreimann <https://twitter.com/jdreimann>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message