On 20 February 2012 12:47, Gary <[email protected]> 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.
+1 > * 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 Components. 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 - http://trac-hacks.org/wiki/TracWysiwygPlugin 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
