incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <ole...@gmail.com>
Subject Re: [Apache Bloodhound] #324: Multiproducts UI: (Meta) navigation
Date Wed, 02 Jan 2013 22:06:42 GMT
On 1/2/13, Gary Martin <gary.martin@wandisco.com> wrote:
> 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
>> >
[...]
>> >
>> > Comment (by jdreimann):
>> >
>> >  This belongs in the breadcrumb in my humble opinion, not in the meta
>> > or
>> >  main nav.
>> >
[...]
>> 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?

IMO , not quite . Besides there's another subject to discuss . What
products will be displayed in there ? All products ?

I've been reading recent comments and I'm under the impression that
suggestions are focused on deployments consisting of a few products
per environment . Maybe I'm wrong . OTOH every time I think about
products in my mind I consider large deployments e.g. similar to
sourceforge , google code , github , bitbucket , ... <add your own>

I don't think the drop down will fit well in one such scenario ...

>    2. Can the selection be made to look reasonable?

... unless a limited subset of products is added in there .

Indeed for large deployments maybe product search / index +
classifiers will be even more convenient than flat product lists .

>    3. Do we specifically need other resources to support this kind of
>    selection?
>

I'm not very sure .

[...]
> As for question 3, I don't
> think we need to make sense of selecting other resources from the
> breadcrumb to do this work.
>

+1

>
>> However some artifacts do and some do not have their own pages to go
>> to (versions vs. milestones). This will result in inconsistencies...
>>
>
[...]
>
> However, there are some interesting questions around how the breadcrumb
> should be constructed for all of the resources.
>
[...]
>
> For simplicity, we
> could just use the following breadcrumbs:
>
>    - Product page: <product>
>    - Component page: <product>/<component>
>    - Version page: <product>/<version>
>    - Milestone page: <product>/<milestone>

up to this point +1

>    - 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?
>

In this case I suggest to keep product / ticket in breadcrumbs path as
it is really the only strong relationship existing for tickets
(consider Joe's comment about breadcrumbs purpose as well ;) . The
rest are volatile .

Beyond that , if you ask me I'd rather add component , version and
milestone links in context navigation area to the right .

However we shall pay attention to the bar . It might be too cluttered
considering that more links will be in there (e.g. ← Previous Ticket ,
     Back to Query ,      Next Ticket → ,     Reports ) .

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

Mime
View raw message