On Wed, Jun 1, 2016 at 6:54 PM, Guillaume Lerouge <guillaume@xwiki.com> wrote:

Hi Caty,

thanks for your proposal. Looking good overall!

My preference goes to Layout3 (a new one):

- Left panel set to "Large" - Navigation panel - Tips panel - Right panel set to "Small" - Applications panel

The right panel would need to accommodate also a Support panel. The screenshots is lacking this since I don't have a voting proposal yet, but this is an example: http://design.xwiki.org/xwiki/bin/download/Proposal/HomepageSketches/WebHome... The problem with the navigation panel is that because of its scalability it cannot be placed as first item, since it will overpower and push down any other panel (in your case Tips + Support). The pattern for AppBar is to be placed on the left. I haven't seen anywhere it being placed on the right. If we brake this 'standard'/'consistency' users will be affected.

And I would drop "My recent modifications".

Since now we want to have a wiki-content page I think is important to preserve the wiki-features like "Recent modifications". Anyway, thanks for your input. Waiting for more opinions. Caty

Thanks,

Guillaume

On Wed, Jun 1, 2016 at 5:49 PM, Ecaterina Moraru (Valica) < valicac@gmail.com

...

wrote:

...

Hi,

This is a follow up on the initial brainstorming done, see http://markmail.org/message/hbuhhkxcjodtfxwi

This proposal aims to replace the current Dashboard with a more simple wiki content page:

http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageSketches/HomepageLay...

...

I would like you to vote on the 2 versions of left panels: 1. AppBar + Pages 2. AppBar

Also provide feedback on the content. I've added the content on this

page:

...

http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageSketches/HomepagePro...

...

in order for you to see how it behaves with the editors. [1]

The objective was to have an easy to edit content, very close to what we have in view mode.

Let me know what you think. Thanks, Caty

[1] Since we don't have CKEditor installed on design wiki, see how it would looks like

http://design.xwiki.org/xwiki/bin/download/Proposal/HomepageSketches/WebHome...

...

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

I préfère layout 1.. all the navigation on the left In the right i find the récent changes useful for editors. Ludovic Le 2 juin 2016 10:31, "Guillaume Lerouge" <guillaume@xwiki.com> a écrit :

Hi Caty,

thanks for your feedback.

On Wed, Jun 1, 2016 at 6:02 PM, Ecaterina Moraru (Valica) < valicac@gmail.com

...

wrote:

...

On Wed, Jun 1, 2016 at 6:54 PM, Guillaume Lerouge <guillaume@xwiki.com> wrote:

...

Hi Caty,

thanks for your proposal. Looking good overall!

My preference goes to Layout3 (a new one):

- Left panel set to "Large" - Navigation panel - Tips panel - Right panel set to "Small" - Applications panel

The right panel would need to accommodate also a Support panel. The screenshots is lacking this since I don't have a voting proposal yet, but this is an example:

http://design.xwiki.org/xwiki/bin/download/Proposal/HomepageSketches/WebHome...

...

The problem with the navigation panel is that because of its scalability

it

...

cannot be placed as first item, since it will overpower and push down any other panel (in your case Tips + Support).

...

The pattern for AppBar is to be placed on the left. I haven't seen anywhere it being placed on the right. If we brake this 'standard'/'consistency' users will be affected.

I agree with this. However, what I've seen on several XWiki implementation is the following:

- Main wiki with wide left panel and navigation menu there which is a very, very common pattern. Some examples: - WikiTerritorial < http://www.wikiterritorial.cnfpt.fr/xwiki/wiki/econnaissances/view/Notions-C...

...

- Centre de ressources USH < http://ressourceshlm.union-habitat.org/ush/Dossiers/Dossier+Abattement+de+la...

...

- FOPH <http://www.foph.fr/oph/Ressources/> - It's also the standard menu on Google Sites for instance

- Appbar on the left for workspace subwikis (where it makes a lot of sense indeed)

...

And I would drop "My recent modifications".

Since now we want to have a wiki-content page I think is important to preserve the wiki-features like "Recent modifications".

What I know is that I never use this :-) Let's see what others say.

Guillaume

Anyway, thanks for your input. Waiting for more opinions.

...

Caty

...

Thanks,

Guillaume

On Wed, Jun 1, 2016 at 5:49 PM, Ecaterina Moraru (Valica) < valicac@gmail.com

...

wrote:

...

Hi,

This is a follow up on the initial brainstorming done, see http://markmail.org/message/hbuhhkxcjodtfxwi

This proposal aims to replace the current Dashboard with a more

simple

...

...

wiki

...

content page:

http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageSketches/HomepageLay...

...

...

...

I would like you to vote on the 2 versions of left panels: 1. AppBar + Pages 2. AppBar

Also provide feedback on the content. I've added the content on this

page:

...

http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageSketches/HomepagePro...

...

...

...

in order for you to see how it behaves with the editors. [1]

The objective was to have an easy to edit content, very close to what we have in view mode.

Let me know what you think. Thanks, Caty

[1] Since we don't have CKEditor installed on design wiki, see how it would looks like

http://design.xwiki.org/xwiki/bin/download/Proposal/HomepageSketches/WebHome...

...

...

...

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

+1 for layout 2 because I think it looks better. 2016-06-02 10:41 GMT+02:00 Ecaterina Moraru (Valica) <valicac@gmail.com>:

On Thu, Jun 2, 2016 at 11:31 AM, Guillaume Lerouge <guillaume@xwiki.com> wrote:

...

Hi Caty,

thanks for your feedback.

On Wed, Jun 1, 2016 at 6:02 PM, Ecaterina Moraru (Valica) < valicac@gmail.com

...

wrote:

...

On Wed, Jun 1, 2016 at 6:54 PM, Guillaume Lerouge <guillaume@xwiki.com

...

wrote:

...

Hi Caty,

thanks for your proposal. Looking good overall!

My preference goes to Layout3 (a new one):

- Left panel set to "Large" - Navigation panel - Tips panel - Right panel set to "Small" - Applications panel

The right panel would need to accommodate also a Support panel. The screenshots is lacking this since I don't have a voting proposal yet, but this is an example:

http://design.xwiki.org/xwiki/bin/download/Proposal/HomepageSketches/WebHome...

...

...

The problem with the navigation panel is that because of its

scalability it

...

cannot be placed as first item, since it will overpower and push down any other panel (in your case Tips + Support).

...

The pattern for AppBar is to be placed on the left. I haven't seen anywhere it being placed on the right. If we brake this 'standard'/'consistency' users will be affected.

I agree with this. However, what I've seen on several XWiki implementation is the following:

- Main wiki with wide left panel and navigation menu there which is a very, very common pattern. Some examples: - WikiTerritorial <

http://www.wikiterritorial.cnfpt.fr/xwiki/wiki/econnaissances/view/Notions-C...

...

...

- Centre de ressources USH <

http://ressourceshlm.union-habitat.org/ush/Dossiers/Dossier+Abattement+de+la...

...

...

- FOPH <http://www.foph.fr/oph/Ressources/> - It's also the standard menu on Google Sites for instance

Hi Guillaume,

Thanks very much for your examples. It depends very much on the wiki's flavor, if it's focused on content/hierarchy or on applications. On an empty wiki is a bit hard to have relevant content that can make sense for newcomers.

Layout 1 showcases that you can have a bit of both: apps + hierarchy. Unfortunately the admin would need to change this to suit his future needs + the AppBar is not displayed with the standard styling.

Layout 2 has the nice styling of AppBar, showcases the apps, has the breadcrumb as navigation (with some discoverability issues, but with an additional homepage text + tour). But the emphasis is lesser on content.

...

- Appbar on the left for workspace subwikis (where it makes a lot of sense indeed)

...

And I would drop "My recent modifications".

Since now we want to have a wiki-content page I think is important to preserve the wiki-features like "Recent modifications".

What I know is that I never use this :-) Let's see what others say.

Yes. Thanks, Caty

...

Guillaume

Anyway, thanks for your input. Waiting for more opinions.

...

Caty

...

Thanks,

Guillaume

On Wed, Jun 1, 2016 at 5:49 PM, Ecaterina Moraru (Valica) < valicac@gmail.com

...

wrote:

...

Hi,

This is a follow up on the initial brainstorming done, see http://markmail.org/message/hbuhhkxcjodtfxwi

This proposal aims to replace the current Dashboard with a more

simple

...

...

wiki

...

content page:

http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageSketches/HomepageLay...

...

...

...

...

I would like you to vote on the 2 versions of left panels: 1. AppBar + Pages 2. AppBar

Also provide feedback on the content. I've added the content on

this page:

...

http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageSketches/HomepagePro...

...

...

...

...

in order for you to see how it behaves with the editors. [1]

The objective was to have an easy to edit content, very close to what we have in view mode.

Let me know what you think. Thanks, Caty

[1] Since we don't have CKEditor installed on design wiki, see how it would looks like

http://design.xwiki.org/xwiki/bin/download/Proposal/HomepageSketches/WebHome...

...

...

...

...

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

-- Guillaume Delhumeau (guillaume.delhumeau@xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

On Tue, Jun 7, 2016 at 5:22 PM, Vincent Massol <vincent@massol.net> wrote:

Hi Caty,

...

On 01 Jun 2016, at 17:49, Ecaterina Moraru (Valica) <valicac@gmail.com> wrote:

Hi,

This is a follow up on the initial brainstorming done, see http://markmail.org/message/hbuhhkxcjodtfxwi

This proposal aims to replace the current Dashboard with a more simple wiki content page:

http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageSketches/HomepageLay...

...

I would like you to vote on the 2 versions of left panels: 1. AppBar + Pages 2. AppBar

Also provide feedback on the content. I've added the content on this

page:

...

http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageSketches/HomepagePro...

...

in order for you to see how it behaves with the editors. [1]

Regarding the content:

* FTR I had given some thoughts before in http://markmail.org/message/nqzkxfefty32qmjw Summary: I’m not fully convinced but I’m willing to give it a try * I think we need to handle the fact that XWiki should work without internet connection and the connection to youtube will only works when you have internet connection. Unless we think it’s ok and admins will edit this page to remove the video if they don’t have internet connection? * I was wondering if it was ok to use complex wiki syntax on this page (we use that for the table at the bottom), but maybe it’s ok and would serve as an example. Although I think users should probably use the {{container}} Macro instead ( http://extensions.xwiki.org/xwiki/bin/view/Extension/Container+Macro). The disadvantage is that when you edit in WYSIWYG you cannot change content without editing the macro ;) So taking everything into account maybe what is there is the least bad solution, especially if we favor WYSIWYG users by default.

I've used the table, as you said in order to make it as simple as possible for the user to edit the page content in a visual editor. The SSX is a bit problematic, but currently I don't see an alternative. The table and the video give the homepage a bit of layout and structure. Removing them would simplify the page very much, but I prefer it to be nicer.

* I see the content explains a lot how the wiki works but I thought that was the job of the tour and from what I’ve seen at http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageTour it looks very similar. Aren’t we not providing duplication and does it matter?

Initially I had the same feeling. Still we remind again the main actions an user can do: edit, add, navigate.

* Note that the home page will need to be re-translated in all languages (and we’ll need to add it on l10n) ;) * One nice pro is that the home page will load much faster (since the AS is not on it) ;)

All in all, +1 to try it and see what feedback we get.

You should also state the layout preference. Thanks, Caty

Thanks -Vincent

...

The objective was to have an easy to edit content, very close to what we have in view mode.

Let me know what you think. Thanks, Caty

[1] Since we don't have CKEditor installed on design wiki, see how it would looks like

http://design.xwiki.org/xwiki/bin/download/Proposal/HomepageSketches/WebHome...

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

On 08 Jun 2016, at 10:16, Caleb James DeLisle <cjd@cjdns.fr> wrote:

Vote layout 1, we absolutely need a tree, this is killing us.

Do you realize that we already have a tree? :) (hint: it’s in the breadcrumb). The Tour should make users find it more easily. The tree is good for a KB which is probably our main flavor but it’s taking space too which could be better used by other things (if you’re in workgroups flavor you're probably more interested by apps). It’s a pity that the breadcrumb is not more visible somehow. My hope is that the tour will help on that but it may be not enough potentially. Thanks -Vincent

One of the things which *made* MS Windows was the fact that you had a tree of folders in the explorer. Same thing (tree) is shown in Thunderbird mail and in google docs.

Thanks, Caleb

On 01/06/16 17:49, Ecaterina Moraru (Valica) wrote:

...

Hi,

This is a follow up on the initial brainstorming done, see http://markmail.org/message/hbuhhkxcjodtfxwi

This proposal aims to replace the current Dashboard with a more simple wiki content page: http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageSketches/HomepageLay...

I would like you to vote on the 2 versions of left panels: 1. AppBar + Pages 2. AppBar

Also provide feedback on the content. I've added the content on this page: http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageSketches/HomepagePro... in order for you to see how it behaves with the editors. [1]

The objective was to have an easy to edit content, very close to what we have in view mode.

Let me know what you think. Thanks, Caty

[1] Since we don't have CKEditor installed on design wiki, see how it would looks like http://design.xwiki.org/xwiki/bin/download/Proposal/HomepageSketches/WebHome... _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Correction: Google docs doesn't use a tree, they have a lefthand "menu" instead. Google docs is filling me with hate and rage right now, anything they do for UI, do the opposite. On 08/06/16 10:16, Caleb James DeLisle wrote:

Vote layout 1, we absolutely need a tree, this is killing us. One of the things which *made* MS Windows was the fact that you had a tree of folders in the explorer. Same thing (tree) is shown in Thunderbird mail and in google docs.

Thanks, Caleb

On 01/06/16 17:49, Ecaterina Moraru (Valica) wrote:

...

Hi,

This is a follow up on the initial brainstorming done, see http://markmail.org/message/hbuhhkxcjodtfxwi

This proposal aims to replace the current Dashboard with a more simple wiki content page: http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageSketches/HomepageLay...

I would like you to vote on the 2 versions of left panels: 1. AppBar + Pages 2. AppBar

Also provide feedback on the content. I've added the content on this page: http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageSketches/HomepagePro... in order for you to see how it behaves with the editors. [1]

The objective was to have an easy to edit content, very close to what we have in view mode.

Let me know what you think. Thanks, Caty

[1] Since we don't have CKEditor installed on design wiki, see how it would looks like http://design.xwiki.org/xwiki/bin/download/Proposal/HomepageSketches/WebHome... _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

On 08 Jun 2016, at 11:01, Marius Dumitru Florea <mariusdumitru.florea@xwiki.com> wrote:

On Wed, Jun 1, 2016 at 6:49 PM, Ecaterina Moraru (Valica) <valicac@gmail.com

...

wrote:

...

Hi,

This is a follow up on the initial brainstorming done, see http://markmail.org/message/hbuhhkxcjodtfxwi

This proposal aims to replace the current Dashboard with a more simple wiki content page:

http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageSketches/HomepageLay...

I would like you to vote on the 2 versions of left panels:

...

1. AppBar + Pages

The tree (Pages) looks good when you have a few top level nodes and only one level of hierarchy. It doesn't look that good when you have many nodes and a deep hierarchy because it needs more space than what is available in the panel. Vertically is kind of OK but you cannot add another panel below the tree because it will be shifted down when you expand the tree. We could limit the height of the tree (max-height) but we'll get a vertical scroll bar pretty soon. The horizontal space is a big problem. Wrapping the node labels on multiple lines might work if the hierarchy is not deep, but the horizontal scroll bar is inevitable in the end. Having scroll bars (especially horizontal) inside a web page is bad UIX. A solution is to allow the user to resize the panel width using some drag handle. The panel content will have to adapt to the panel size dynamically of course.

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.

I think the idea for the tree is to have something by default that helps the user initially. If for their future needs, it’s not perfect for their need like taking too much vertical space, they can always remove it. It’s more for users to understand that there’s a hierarchy of pages in their wiki I think. Thanks -Vincent

Thanks, Marius

...

2. AppBar

Also provide feedback on the content. I've added the content on this page:

http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageSketches/HomepagePro... in order for you to see how it behaves with the editors. [1]

The objective was to have an easy to edit content, very close to what we have in view mode.

Let me know what you think. Thanks, Caty

[1] Since we don't have CKEditor installed on design wiki, see how it would looks like

http://design.xwiki.org/xwiki/bin/download/Proposal/HomepageSketches/WebHome...

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.

Hi,

On 08 Jun 2016, at 13:50, Ecaterina Moraru (Valica) <valicac@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@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.

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) <valicac@gmail.com

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 <vincent@massol.net> wrote:

...

Hi,

...

On 08 Jun 2016, at 13:50, Ecaterina Moraru (Valica) <valicac@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@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@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

After confirming with Marius, I've updated: Votes so far: 1. 4 = +1 (Ludovic), +1 (Caleb), +1 (Marius), +1 (Vincent), +0 (Caty) 2. 2 = +1 (GD), +1 (Caty) Thanks, Caty On Mon, Jun 13, 2016 at 2:23 PM, Vincent Massol <vincent@massol.net> wrote:

Hi Caty,

I don’t understand why you count Marius for 2 when he said:

"In that case I'm OK with version (1).”

Thanks -Vincent

...

On 13 Jun 2016, at 13:17, Ecaterina Moraru (Valica) <valicac@gmail.com> wrote:

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) < valicac@gmail.com

...

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 <vincent@massol.net> wrote:

...

Hi,

...

On 08 Jun 2016, at 13:50, Ecaterina Moraru (Valica) < valicac@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@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@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs