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, 17 Dec 2012 13:07:30 GMT
On 17 December 2012 07:49, Peter Koželj <peter@digiverse.si> wrote:

> I like the proposed mockup for the new multiproduct aware
> dashboard. Actually this gave me idea that is in some way contrary to
> Andrej's suggestion and current state of implementation:
>
> I propose that global dashboard and product scoped dashboard (product view)
> is one and the same thing viewed in different context/scope. Widgets would
> be given that scope (global or product). When used globally widgets would
> display tickets, wikis, reports and products from all products that uses
> has rights to and when displayed in product scope all the same widgets
> apply with content reduced to single product.
>

Yes, this is what I had in mind.


> At some later stage we could allow for per-product configurations of
> "dashboard" allowing user different widgets globally (dashboard) and per
> products (product view) but it would still be the one and only
> implementation.
>

I think it would be more sensible to configure per scope, not per product:
For example change all milestone views in a certain way, not all milestone
views in different ways. Let's leave that for another day though :)

- Joe


>
> Peter
>
> On 10 December 2012 19:16, Joachim Dreimann
> <joachim.dreimann@wandisco.com>wrote:
>
> > 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> *
> >
>



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