Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of
 jim.callahan.hsqe@statefarm.com designates 205.242.229.166 as permitted
 sender)
From: Jim Callahan <jim.callahan.hsqe@statefarm.com>
To: "bloodhound-dev@incubator.apache.org"
	<bloodhound-dev@incubator.apache.org>
Subject: Re: Bloodhound thoughts
Thread-Topic: Bloodhound thoughts
Thread-Index: AQHM72BhMeQ8a1ffxEa+ApwKkw8VZJZFAAWAgAEyOICAAGyMgP//nnwA
Date: Mon, 20 Feb 2012 19:27:10 +0000
Message-ID: <CB67F90F.1663F%jim.callahan.hsqe@statefarm.com>
In-Reply-To: 
 <CAKoya90G3acgCyxfPU+CsGKmcQNfBTy_aO+LByeANRfAeOCKqQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.13.0.110805
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6B606999077AB04DBDB1C9B354A4A35D@statefarm.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


On 2/20/12 1:16 PM, "Joachim Dreimann" <joachim.dreimann@wandisco.com>
wrote:
>
>
>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.

That's a very succinct way to put that.

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

I'd be afraid of complicating the BC functionality. Is there an example
out there where this multi-level BC functionality is implemented
successfully. I'm not saying it's not, just that I can't think of one off
the top of my head.

My bread crumbs use case is more complicated than a simple click on a back
button. I am constantly managing work for multiple milestones and
enhancements in multiple different online apps. The BC plugin is key to me
being able to remember what I've done and go back just a little bit. I
won't necessarily even have a history tomorrow that isn't gummed up by
85,000 other links.

But, that may just be me.


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

That's a profound truth. I'd like to have a more contained (??)
implementation of that.
>

Jim