bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: [Apache Bloodhound] #120: Context dependent activity
Date Mon, 02 Jul 2012 05:52:32 GMT
On 7/1/12, Gary Martin <> wrote:
> On 01/07/12 16:13, Olemis Lang wrote:
>> On 6/29/12, Gary Martin <> wrote:
>>> Although I believe it should follow the general principle of greater
>>> focus as suggested by #94
>>> (, focusing on an
>>> individual Ticket, it will certainly have to show more types of events
>>> than at other levels.
>>> There is also the question of distinguishing the roles of the activity
>>> area and the 'Change History' area which is probably worth clearing up.
>>> Effectively the design that Joe provided us with changes that Change
>>> History area into a Comments only area (see
>>> Taking that to a hopefully logical conclusion, the Activity area
>>> effectively replaces the role of the Change History, showing *all* the
>>> Ticket change history, except using truncated comments.
>> so far I'm -0 about this . IMO all details of change history should be
>> fully available in ticket view .
> I do not believe anyone wants to see any loss of details from the Ticket
> View.

this part agreed then

> This is effectively a rearrangement of the screen.

I c ... if you mean to render non-comment events at the right side
with activity appearance , then the situation improves ... but ...

> For this to
> provide a closer equivalence we should probably additionally specify
> that there is no limit on the number of events displayed in the Activity
> for a Ticket.

IMO , under the hood , that's something different to inserting the
activity widget , even if both approaches will make it look in a
similar way .

> Anyway, the point of the partial separation of comments from other
> events is that, while you might want to know how comments fit into the
> order of the other events (and I see us still providing the comments
> interleaved in the Activity albeit in the truncated form for compactness
> to meet this need), it is a streamlining of the process of understanding
> what a ticket is about rather than the way in which it has changed
> state.

My opinion about this is slightly different . IMO , most of the time
text in comments have a meaning in the context of ticket changes .
That relative references make sense if there's a chronological order
of ticket events .

For instance , consider #93 . Quite often in there comments make
reference to patchs , images ... previously attached at many different
time intervals . Some comments have real meaning when readers realise
it is related to a previous ticket change . IMO , if this is put apart
from main feed then readers will need to find a match between both
parts of the UI in order to figure out what's the comment about .
AFAICS this situation **might** get worst (... I need to imagine what
will happen in practice ...) if ticket is reopened a number of times .

> If you extract the comments all into one place then it is easier
> to read it through without all the other information getting in the way.

... comments above were just my initial thoughts about what **might**
happen . I'll try to simulate later such reading using #93 (... and
maybe some long thread @ t.e.o) as example . Let's c how it goes ;)




Blog ES:
Blog EN:

Featured article:

View raw message