incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <>
Subject Re: [BEP-0003] Multiproduct UI/UX
Date Fri, 07 Dec 2012 11:52:05 GMT

On 06/12/12 09:36, Jure Zitnik wrote:
> Hi,
> Reading BEP-0003 I realized that we have not yet discussed what the 
> user interface/experience for the multi-product should actually be. 
> What we currently have in the proposal are mostly 
> technical/implementation details.
> What I would propose for start is the following:
> 1. Introduction of global dashboard:

Effectively I consider this to be what we already have and that product 
pages are the equivalent of the project specific dashboard. The 
distinction is probably not too important of course and on 
<product-id>/dashboard links we probably want the product's dashboard 
style view.

> * default page/entry point for the user

I can see this working for users with access to multiple products. If a 
user only has access to a single product, wouldn't we want them to go 
directly to their product dashboard view?

> * layout could be very similar to the current dashboard with some 
> widgets missing (Versions, Milestones, Components for example)

It makes sense to me to defocus at this level as we do not want so much 
in the way of specifics of every single product. I would probably be 
keeping milestones but this would probably be a reduced list, showing 
the milestones that the user is likely to be working on.

> * Search is global, through all products
> * Wiki and Ticket quick links are not available

I am not sure that there is a particular reason to drop the global wiki 
- I would probably keep that unless there are some strong arguments for 
dropping it. As for the ticket raising links I can see sense in removing 
the ability to raise a ticket if there is no global (null? default?) 
product, as it might reduce the number of tickets that are raised within 
the wrong product. I guess the question is whether this is likely or if 
users are likely to remember to set the product when that choice is 
provided to them. Perhaps the choice of product should probably be the 
top item for prominence and only available when there is more than one 
product that a user is allowed edit access to (otherwise just stating 
the product the ticket will be raised in).

> * Custom query and Reports are available (scope is all products)
>   * this requires us to support both per-product and global reports
> * shows user's tickets - in all products (similar to My Tickets in the 
> current dashboard but globally)
> * shows active ticket's - in all products (as in the current dashboard 
> but globally)
> * 'My Products' - list of products user is member of, including quick 
> links to tickets&wiki for that specific product
>   *  this might for the time of being be list of all products at least 
> until we get the per-product permission schemes up
> * 'All Products' - list of all products

I wonder what the strict difference between those lists of products 
should be. I would probably avoid showing a list of all products if 
there is an inability to view them. I guess that My Products may be 
distinguished from others by the availability of edit/modification 
rights rather than just view rights. Either way, I think a list of all 
products would be redundant.

> * Activity tab shows global activity
> 2. Modification of existing tickets/wiki/custom query/reports pages to 
> support per product scope
> 3. Selecting a product/ticket/wiki/report should change the user 
> interface scope to the product of the selected ticket/wiki/report etc.
> 4. When in product scope, there should be an indicator in the 
> interface of the currently active product scope. A mechanism should be 
> put in place to change product scope easily.
> 5. Prerequisite for the above is that all user-created resources 
> (tickets, wiki, reports, etc.) have product associated. In turn that 
> means we'll need to modify the installation to create the default 
> product, modify the upgrade to migrate existing instances to default 
> product etc. ... but this is a subject of another discussion thread :)

Perhaps it should be a different thread.. I will just note that I do not 
see a strict need for this as we can consider the null product to be a 
product in its own right. There may be advantages to both approaches though.

> This is just to kick the conversation off, I'm aware there are lots of 
> things I missed (all of the settings section for example,...) ... what 
> I'd like after the discussion on the dev list is that we are on the 
> same page regarding UI/UX and that we're able to produce a set of user 
> interface mockups and update BEP-0003 accordingly...
> Best regards,
> Jure


View raw message