On 7/1/12, Gary Martin <[email protected]> wrote: > On 01/07/12 16:13, Olemis Lang wrote: >> On 6/29/12, Gary Martin <[email protected]> wrote: >>> Although I believe it should follow the general principle of greater >>> focus as suggested by #94 >>> (https://issues.apache.org/bloodhound/ticket/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 >>> https://svn.apache.org/repos/asf/incubator/bloodhound/trunk/doc/html-templates/ticket.html). >>> >>> 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 ;) [...] -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article:
