8 Jun
2016
8 Jun
'16
2:33 p.m.
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 <vincent(a)massol.net> wrote:
Hi,
On 08 Jun 2016, at 13:50, Ecaterina Moraru
(Valica) <valicac(a)gmail.com>
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 <cjd(a)cjdns.fr>
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs