bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Dreimann <>
Subject Re: Bloodhound thoughts
Date Mon, 20 Feb 2012 19:16:07 GMT
On 20 February 2012 12:47, Gary <> wrote:

> It is very good to see this kind of interest. These contributions to the
> conversation are still coming at a very good time and it is great to hear
> things that you want to see.


>  * BreadCrumbsNav: I was not thinking of adding this before but it
>   seems worthy of investigation. By default it shows the last 6
>   visited pages, though only if their paths start with milestone, wiki
>   or ticket (each of those aspects are configurable). I hope that
>   Joachim can have a look at this and see whether it duplicates or
>   conflicts with our ideas on navigation.

As I understand it the BreadCrumbsNav plugin shows a history of
visited pages, rather than your actual location within Trac, because
it doesn't have any hierarchical structure. The key difference here is
that Bloodhound (unlike Trac) will have some structure, ie Products ->
Versions -> Milestones -> Tickets, with Projects and Components being
Tags more or less without structure.

In other words, when viewing a ticket inside a fully fleshed out
Product, it will _probably_ belong to a Milestone, which belongs to a
Version, which belongs to a Product. You can still have Projects that
cover multiple Products, Versions, Milestones or Tickets, as with

The breadcrumb should reflect this structure, which handily is also
existant in the Trac Wiki by default. As I understand it
BreadCrumbsNav doesn't do this currently. Also, pages last visited
should be returned to via the back button of the browser!

>  * Master/Child tickets: I was thinking of choosing the Master ticket
>   variety for this functionality. It provides the means to specify a
>   ticket as being blocked by another this seems a reasonable way of
>   describing the kind of relationships that are needed for ticket
>   management and we can investigate the use of graphviz for displaying
>   the dependencies.

What dependency other than one ticket blocking one or more others do
we need to display?

>  * TracWysiwyg -

To me it seems that this is doing too much. Providing half that
functionality would not just be sufficient, it would also make it
easier for users to find their way and reduce clutter. 6 Header sizes
+ bold + indentation = 8 ways to bring a structure into the text?
Seems like it's offering everything possible, not only what's useful..

> I suspect that this list is likely to grow a bit. It would be good to see
> more suggestions in this area so that we can see what people think are good.

Regarding a growing list, I believe we should keep it to a minimum as
all extra features set expectations and increase the workload. I think
it's important to only include those plugins that are really essential
to making Bloodhound great and have a solid process to
find/install/manage/remove additional plugins.

> I think converting the dashboard elements to macros would be an excellent
> idea too. I don't want to slow initial development so if that is not the way
> that Olemis has already gone we should continue along the existing route and
> we can factor out the functionality into macros a little further down the
> line.
> We are also interested in providing views of how milestones and products
> progress over time. It is probably worth discussing what people would want
> from that in more detail. Making use of the GoogleChartAPI plugin might well
> be one of the easier ways of doing that.

+1 for looking further into GoogleChartAPI, although doesn't it
require data to 'leave the premises' for Google to return the chart?
Some companies may not be comfortable with this, whether on reasonable
grounds or not.

- Joe

View raw message