Votes so far: 1. 3 = +1 (Ludovic), +1 (Caleb), +0 (Marius), +1 (Vincent), +0 (Caty) 2. 3 = +1 (GD), +1 (Marius), +1 (Caty)
Thanks, Caty On Wed, Jun 8, 2016 at 3:33 PM, Ecaterina Moraru (Valica) <[email protected] > wrote: > Vincent, my understanding was that you had a certain preference, but it's > true that you didn't explicitly voted. In this case I will try to count > just the explicit (+/- 0,1) votes. > > Still (after going on the mails) I will consider formulations like "vote", > "preferred", "favor", "OK" - although I might be wrong, since otherwise is > hard to translate the feedback received in votes. Would be ideal if people > would vote explicitly. > > So, votes so far: > 1. +1 (Ludovic), +1 (Caleb), +0 (Marius), +1 (Vincent), +0 (Caty) > 2. +1 (GD), +1 (Marius), +1 (Caty) > 3. +1 (GL), -1 (Caty) > > Hope I didn't do mistakes, otherwise state them and we will correct the > vote. > > Thanks, > Caty > > On Wed, Jun 8, 2016 at 3:25 PM, Vincent Massol <[email protected]> wrote: > >> Hi, >> >> > On 08 Jun 2016, at 13:50, Ecaterina Moraru (Valica) <[email protected]> >> wrote: >> > >> > Votes so far on layout: >> > 1. +1 (Ludovic), +1 (Caleb) >> > 2. +1 (GD), +1 (Marius), +1 (Vincent) >> >> That’s not correct. I haven’t voted yet and I never said that the tree >> shouldn’t be there. >> >> I just highlighted pros and cons of each :) >> >> +1 to 1 because: >> - This is the option that shows clearly the concept of page hierarchy to >> users >> - Admins can then choose to keep it, only keep the AppBar (workgroup >> flavor-style) or only keep the Tree (documentation flavor-style) >> - This is about the default flavor which is generic. When we introduce >> more flavors in the future, those flavors can favor a different panel >> organization depending what’s best for them >> >> Thanks >> -Vincent >> >> > 3. +1 (GL) >> > >> > After more discussions the vote swifted towards: >> > 1. +1 (Ludovic), +1 (Caleb), +0 (Marius), +0 (Vincent) >> > 2. +1 (GD), +1 (Marius), +1 (Vincent) >> > 3. +1 (GL) >> > >> > My preference goes to 2. >> > >> > I vote for 2 since I believe that the Tree is already in the Breadcrumb, >> > and the breadcrumb is introduced by the Tour. >> > I vote for 2 since we have scalability issues that I believe they will >> pose >> > some problems on the long run for the users. >> > >> > The only advantage var 1 has is that it displays the tree from the >> start to >> > the user. But after a time the user will be 'forced' to configure its >> wiki >> > and remove it. >> > Each time the user will install a new app, both the Appbar and the Tree >> > will increase in size. >> > >> > I like much more the classic AppBar navigation pattern and I think >> XWiki's >> > greater strength is in applications. >> > >> > We are lacking now multiple flavors that could showcase both the KB and >> > Groupware cases, but if I were to choose a default, that would be >> > Groupware. >> > >> > So on V1 I will be +0, but definitely -1 on V3. >> > >> > Votes so far: >> > 1. +1 (Ludovic), +1 (Caleb), +0 (Marius), +0 (Vincent), +0 (Caty) >> > 2. +1 (GD), +1 (Marius), +1 (Vincent), +1 (Caty) >> > 3. +1 (GL), -1 (Caty) >> > >> > Thanks, >> > Caty >> > >> > On Wed, Jun 8, 2016 at 12:09 PM, Caleb James DeLisle <[email protected]> >> wrote: >> > >> >> I disagree with this point, as a user of web interfaces I don't care if >> >> they look completely busted as long as I can make use of them, even if >> they >> >> become unusable in 5% of the situations, that's 95% where I can use >> them. >> >> >> >> Granted if we ship something that looks broken it's an embarassement >> but >> >> if we ship something that a person cannot navigate then we don't even >> have >> >> them complaining at us, they just become another silent non-adopter. >> >> >> >> >> >> On 08/06/16 11:01, Marius Dumitru Florea wrote: >> >> >> >>> So I think version (1) looks good but it doesn't scale with what we >> have >> >>> right now. Thus I'm more in favour of solution (2), at least until we >> can >> >>> resize the panel width. >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
