On 2 January 2013 10:13, Peter Koželj <[email protected]> wrote:
> On 2 January 2013 11:03, Apache Bloodhound <
> [email protected]> 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
