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 <[email protected]> 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> *
