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.

  * 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

Reply via email to