incubator-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: [BEP-0003] Multiproduct UI/UX
Date Mon, 10 Dec 2012 12:17:15 GMT
This is an important topic, so I felt I had to take some extra time to
reply. You'll see my replies to Jure's initial message below, but first let
me make clear where I stand:

   1. *Dashboard:* There is only one, and it's global. That's the way it
   was always intended too. As you drill down you'll find Product views,
   Version views, Milestone views etc, but I believe we should only call one
   the Dashboard for clarity.
   2. *Custom Query and Reports: *Should always have a global scope to
   start with. That helps users with their mental model of how these things
   work.
   3. *Wiki:* Gary has made strong arguments for keeping the global wiki in
   the past. That's fine with me. I do believe though that it should be much
   easier to associate Wiki articles with objects (such as Products, Version
   and the like), going as far as reserving a namespace in the wiki for each
   object (product/version/milestone), and linking to it automatically from
   the object's view.

Now to address some specific points:

*Andrej*:
> What I would expect from global dashboard as a user is quite different to
product dashboard:
I agree. The scope of what is displayed naturally decreases as the user
navigates to increasingly more specific objects.

*Gary*:
> 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?
In my view: No. To set expectations, make it easier to compare what they
see with colleagues and expand their set of objects (ie create a second
product) we should show them the same (global) Dashboard. Users can of
course always create browser bookmarks directly to the (sole) Product view
if they prefer.

*Jure:*
> * 'My Products' - list of products user is member of, including quick
links to tickets&wiki for that specific product
> [...]
> * 'All Products' - list of all products*
*

All Products are all products that I am allowed to view as that particular
user, making it also 'My Products'. I don't believe we should differentiate
between them. The only differentiation then should be based on:

   1. Criteria the user selects themselves (ie personal focus) that I don't
   believe we need to determine in Bloodhound itself, we should just let users
   have the ability to follow/favourite/pin products.
   2. Involvement in the product, especially 'current' involvement: Taking
   on tickets and completing them vs no tickets assigned to the user gives us
   a good indication which one may be more important to the user at any given
   time. This should be exposed in the UI.

I will update the Dashboard html mockup this afternoon to make a suggestion
and will report back then.

Cheers,
Joe

On 6 December 2012 09:36, Jure Zitnik <jure@digiverse.si> 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:
> * default page/entry point for the user
> * layout could be very similar to the current dashboard with some widgets
> missing (Versions, Milestones, Components for example)
> * Search is global, through all products
> * Wiki and Ticket quick links are not available
> * 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
> * 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 :)
>
> 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
>
>


-- 
Joe Dreimann
UX Designer | WANdisco <http://www.wandisco.com/>
*
*
*Transform your software development department. Register for a free SVN
HealthCheck <http://go.wandisco.com/HealthCheck-Sig.html> *

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