incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <gary.mar...@wandisco.com>
Subject Re: [Apache Bloodhound] #324: Multiproducts UI: (Meta) navigation
Date Wed, 02 Jan 2013 13:24:32 GMT
On 2 January 2013 10:13, Peter Koželj <peter@digiverse.si> wrote:

> On 2 January 2013 11:03, Apache Bloodhound <
> bloodhound-dev@incubator.apache.org> wrote:
>
> > #324: Multiproducts UI: (Meta) navigation
> > ---------------------------+--------------------
> >   Reporter:  peter         |      Owner:  nobody
> >       Type:  enhancement   |     Status:  new
> >   Priority:  major         |  Milestone:
> >  Component:  multiproduct  |    Version:
> > Resolution:                |   Keywords:
> > ---------------------------+--------------------
> >
> > Comment (by jdreimann):
> >
> >  This belongs in the breadcrumb in my humble opinion, not in the meta or
> >  main nav. That's because the breadcrumb should be the one place where we
> >  display where inside the Bloodhound structure the user is.
> >  Dropdowns to select siblings are worthwhile at many (all?) levels ->
> >  components / milestones / versions.
> >
> >
> If we have visually appealing way to display dropdowns in breadcrumbs, I am
> all for it.
>

For ticket #324 itself, the product selection should work fine with a
dropdown - products are fundamentally container objects for all other
resources so I see no specific problem. The questions that may need to be
addressed are:

   1. Is this where a user would expect to change the product namespace?
   2. Can the selection be made to look reasonable?
   3. Do we specifically need other resources to support this kind of
   selection?

I am not sure I can answer question 1 but for question 2 I think that
adding a control to the left or right of the product link that would
display a dropdown list would probably be fine. As for question 3, I don't
think we need to make sense of selecting other resources from the
breadcrumb to do this work.


> However some artifacts do and some do not have their own pages to go
> to (versions vs. milestones). This will result in inconsistencies...
>

This seems a little more off-topic, particularly with my answer to my
question 3 above, but..

I can't see a specific reason why we should not have a dashboard-style page
for all resources and so a version link/selection should go to a version
page.

However, there are some interesting questions around how the breadcrumb
should be constructed for all of the resources. Given that we lack a strict
hierarchy as components, versions and milestones are effectively orthogonal
classifications, we probably cannot really think of the breadcrumb as being
a positional breadcrumb except in relation to products. For simplicity, we
could just use the following breadcrumbs:

   - Product page: <product>
   - Component page: <product>/<component>
   - Version page: <product>/<version>
   - Milestone page: <product>/<milestone>
   - Ticket page: <product>/<component>/<version>/<milestone>/<ticket>

The ticket page breadcrumb above would still be a bit inconsistent as it
implies a hierarchy so we may want to separate out the resource sets that
the ticket belongs to:

   - Ticket page: <product>/<ticket> - <component>|<version>|<milestone>

Any other ideas?

Cheers,

    Gary

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