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 18:16:31 GMT
I've updated the Ui/Dashboard wiki article with a new mockup of what I
believe the Dashboard could look like:
https://issues.apache.org/bloodhound/wiki/Ui/Dashboard

Where we currently show the 'all tickets' section (which I haven't found
useful so far), my mockup shows an 'abandoned tickets' section.
While ticket search is improving, it's still difficult to discover tickets
I believe. This section is supposed to highlight abandoned tickets that are
relevant to the user so that they can either claim them, watch them or
dismiss them. Recording users decisions we can probably improve this over
time using an algorithm that predicts what a given user may be most likely
to be interested in.

Just FYI: I've not changed any of the text on that page yet. It may be
outdated.


On 10 December 2012 12:17, Joachim Dreimann
<joachim.dreimann@wandisco.com>wrote:

> 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> *
>
>


-- 
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