bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Dreimann <joachim.dreim...@wandisco.com>
Subject Re: First installation... my humble review
Date Thu, 07 Nov 2013 15:39:41 GMT
On 6 November 2013 18:15, Gary Martin <gary.martin@wandisco.com> wrote:

> Hi Olivier,
>
> Thanks for bringing all that up!
>
>
>
> On 06/11/13 15:06, Olivier Mauras wrote:
>
>> Hello,
>>
>> I met Gary Martin this morning on #trac and discussing quickly about the
>> look & feel of Bloodhound i ended up installing it on a test server.
>> Here's a compilation of the points that i find "lacking":
>>
>> 1/ Blocking points for a production adoption - indeed that's only my
>> opinion
>>
>>   * Product owner should automatically have admin rights to this product.
>>   I plan on using Bloodhound in a multi product / multi users setup.
>>   I can't imagine it working without delegating the product admin rights
>> to their owners
>>
>
> I am pretty happy with named owners of products, or more generally
> resources, being given rights associated with admin of the resource. It
> might be useful if the permissions admin settings for a product reflected
> that in some sense.
>
>
>
>>   * Products should be able to have their own source repo
>>   If rights are delegated, I don't see any valid reason for owners to not
>> be able to add their own repos
>>
>
> I think that there may be some good use-cases for this, particularly when
> combined with the rights to access the product's admin pages. For instance
> it could be that a repository for a product should never even be known
> about in another product. The current solution forcing repository
> definitions globally and allowing local links means that the admin pages
> would have to be restricted to those that are effectively allowed access to
> all. It could instead be delegated.
>
> In the end, there is still the current requirement that repositories have
> to be on disk and a trac-admin command has to be run by someone with
> appropriate access to the server but that doesn't fully justify the
> restrictions.
>
>
>
>> 2/ Confusing points
>>
>>   * Tickets tab being the dashboard
>>   Being a new user, I find it really confusing for the "Tickets" tab for
>> being the dashboard and consequently the only access to products list.
>>   It would be way more intuitive - and faster - to keep the products list
>> dropdown at the left of the breadcrumb.
>>
>
Tabs should remember the place you were last within the tab context, so
that you don't lose context every time to switch tabs. Currently tabs
always return you back to the landing page for that tab, which is a poor
experience in my opinion.

Thanks for your feedback!

Joe


>
>>   * Not knowing where you are
>>   This is indeed linked to the previous point, wiki and source pages
>> don't show the product in breadcrumb
>>
>
> I would definitely argue for extending the breadcrumb to go across all
> pages for this purpose.
>
>
>
>> 3/ Eye candy
>>
>>   * Source browser CSS may not be the easiest to read
>>   All lines to the same color make it difficult to catch things
>>   Age color highlight is too light and/or too close in colors
>>
>>   * There's place on the mainnav tabs
>>   As there's place available and that one can enable timeline and roadmap
>> from base.ini why not add them to mainnav() to not have then in "More" tab?
>>
>
> The timeline has the virtue that it crosses all aspects of the system.
> There is probably a case for having a link, particularly if there are pages
> that do not have activity areas.
>
>
>
>> 4/ Graphic glitch
>>
>>   https://bh-demo1.apache.org/products/%40/roadmap
>>   As you can see here milestone bars are not displaying correctly.
>>
>
> There is an argument for dashboards to be replacements for the roadmap.
> Dashboards will provide more information and they are not yet available in
> an equivalent style. This might be enough of an argument to get the roadmap
> up to scratch as, at least in a sense, it is a little more focused a view
> than the dashboard provides.
>
> Cheers,
>     Gary
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message