On that note: The funny/sad thing to realise is that we are basing all this discussion on the fact that some users did not find the "Add" button *only the first time* they tried to do something. The realization is that this is one of those things (idioms[1][2]) that you learn once and know how to easily do the next 1000x times (like riding a bike). The real problem appears when you are in those "next 1000x time" and you find it cumbersome to use (like riding a bike with no saddle, or with the saddle on backwards :) ). So in both cases (top or middle of the page) once you find it once, you will find it again, however in the middle of the page it conflicts too often with the Edit button and other page related actions, that it becomes cumbersome to use. Thanks, Eduard ---------- [1] http://thor.info.uaic.ro/~evalica/hci/L2/ [2] https://www.englishforums.com/English/IdiomsVsMetaphors/cqwl/post.htm On Thu, Oct 2, 2014 at 12:47 PM, [email protected] <[email protected]> wrote:

On 2 Oct 2014 at 11:06:00, Guillaume Louis-Marie Delhumeau ( [email protected](mailto:[email protected])) wrote:

...

Hi.

I have done the "test-on-my-wife" thing :)

She finds it more intuitive to add a page from the current page, so in the current location, instead of the "black bar that gives the impression of not beeing a part of that page" (that she did not manage to find by herself).

I then explained that the buttons inside the page only concern the actions that you can do on that page, meanwhile adding a new page should be put in an other location. She did not like this logic :)

So with this logic we should remove the top bar completely and move all actions inside the page, i.e. have only 1 menu inside the page. Because if she couldn’t find the Add button there she also wouldn’t be able to find all wiki-related actions, space-related actions and more importantly **page-related** actions like copy page, rename page or delete page…

Also would be fun to ask your wife to try using Confluence and see if she fails to create a page there too.

Thanks -Vincent

...

Users' logic and developer's logic are not the same. I like the current location too, except that we should propose "create page" before "create wiki".

I really would like to have some feedback of normal users, with the 2 proposals. We, as developers, are not good at making things that look simple for other people, so we should not take this decision alone.

Thanks,

-- Guillaume Delhumeau

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi, actually one thing we could try is this: - *Keep the "Add" button where it is and use it for page-related actions:* - "Add child page" - "Add comment" (as suggested by Denis) - "Add attachment" (as suggested by Denis) - *Add a "Create" button in the top bar, with 2/3 options:* - "Create page" (TBD) - "Create space" - "Create wiki" - In this case, after clicking "Create" the user would be presented with a page / modal box listing existing instances as well as available templates I think this would solve both my issues (having less-frequent actions in the same location as a more-frequent one, not being in the right place on the page) and GuillaumeD's wife issue (the "Add" button is easy to find where it is right now, why move it?). WDYT? Guillaume ᐧ On Thu, Oct 2, 2014 at 1:48 PM, [email protected] <[email protected]> wrote:

On 2 Oct 2014 at 13:31:56, Eduard Moraru ([email protected](mailto: [email protected])) wrote:

...

On that note: The funny/sad thing to realise is that we are basing all this discussion on the fact that some users did not find the "Add" button *only the first time* they tried to do something. The realization is that this is one of those things (idioms[1][2]) that you learn once and know how to easily do the next 1000x times (like riding a bike).

The real problem appears when you are in those "next 1000x time" and you find it cumbersome to use (like riding a bike with no saddle, or with the saddle on backwards :) ). So in both cases (top or middle of the page) once you find it once, you will find it again, however in the middle of the page it conflicts too often with the Edit button and other page related actions, that it becomes cumbersome to use.

Indeed that’s something I had in mind too. If you just ask to add a page and that’s all then you’re not doing a full test. You’d need to ask the user to: - add a page - delete a page - move a page - create a space - etc

And then only you can draw some conclusion IMO.

Thanks -Vincent

...

Thanks, Eduard

---------- [1] http://thor.info.uaic.ro/~evalica/hci/L2/ [2] https://www.englishforums.com/English/IdiomsVsMetaphors/cqwl/post.htm

On Thu, Oct 2, 2014 at 12:47 PM, [email protected] wrote:

...

On 2 Oct 2014 at 11:06:00, Guillaume Louis-Marie Delhumeau ( [email protected](mailto:[email protected])) wrote:

...

Hi.

I have done the "test-on-my-wife" thing :)

She finds it more intuitive to add a page from the current page, so

in

...

the

...

current location, instead of the "black bar that gives the impression of not beeing a part of that page" (that she did not manage to find by herself).

I then explained that the buttons inside the page only concern the actions that you can do on that page, meanwhile adding a new page should be put in an other location. She did not like this logic :)

So with this logic we should remove the top bar completely and move all actions inside the page, i.e. have only 1 menu inside the page. Because if she couldn’t find the Add button there she also wouldn’t be able to find all wiki-related actions, space-related actions and more importantly **page-related** actions like copy page, rename page or delete page…

Also would be fun to ask your wife to try using Confluence and see if she fails to create a page there too.

Thanks -Vincent

...

Users' logic and developer's logic are not the same. I like the current location too, except that we should propose "create page" before "create wiki".

I really would like to have some feedback of normal users, with the 2 proposals. We, as developers, are not good at making things that look simple for other people, so we should not take this decision alone.

Thanks,

-- Guillaume Delhumeau

Hi Caty,  On 2 Oct 2014 at 19:10:24, Ecaterina Moraru (Valica) ([email protected](mailto:[email protected])) wrote:

Hi,

I've created this proposal http://design.xwiki.org/xwiki/bin/view/Proposal/FlamingoAddMenuLocation Please read it and give your opinion on it. The proposal is based on discussed solution, but improves a bit the styling.

Thanks for working on this!  * I like your idea in Var 3 for the search bar and making it a bit less visible * I find the Add button not visible enough in the the top bar with var 3 and I prefer the var 2 for it. Specifically I prefer the full text “Add” (or “Create”) and the different color to make it more visible since it’s important for the user to find easily how to add new content in a wiki. Thanks -Vincent

If you are curious how I reached some of the proposal's conclusions, you can see it's iterations http://design.xwiki.org/xwiki/bin/view/Proposal/FlamingoAddMenuLocationItera...

Thanks, Caty

On Thu, Oct 2, 2014 at 7:59 PM, Guillaume Lerouge wrote:

...

Hi,

actually one thing we could try is this:

- *Keep the "Add" button where it is and use it for page-related actions:* - "Add child page" - "Add comment" (as suggested by Denis) - "Add attachment" (as suggested by Denis)

- *Add a "Create" button in the top bar, with 2/3 options:* - "Create page" (TBD) - "Create space" - "Create wiki" - In this case, after clicking "Create" the user would be presented with a page / modal box listing existing instances as well as available templates

I think this would solve both my issues (having less-frequent actions in the same location as a more-frequent one, not being in the right place on the page) and GuillaumeD's wife issue (the "Add" button is easy to find where it is right now, why move it?).

WDYT?

Guillaume ᐧ

On Thu, Oct 2, 2014 at 1:48 PM, [email protected] wrote:

...

On 2 Oct 2014 at 13:31:56, Eduard Moraru ([email protected](mailto: [email protected])) wrote:

...

On that note: The funny/sad thing to realise is that we are basing all this

discussion

...

on

...

the fact that some users did not find the "Add" button *only the first time* they tried to do something. The realization is that this is one of those things (idioms[1][2]) that you learn once and know how to easily do the next 1000x times (like riding a bike).

The real problem appears when you are in those "next 1000x time" and you find it cumbersome to use (like riding a bike with no saddle, or with the saddle on backwards :) ). So in both cases (top or middle of the page) once you find it once, you will find it again, however in the middle of the page it conflicts too often with the Edit button and other page related actions, that it becomes cumbersome to use.

Indeed that’s something I had in mind too. If you just ask to add a page and that’s all then you’re not doing a full test. You’d need to ask the user to: - add a page - delete a page - move a page - create a space - etc

And then only you can draw some conclusion IMO.

Thanks -Vincent

...

Thanks, Eduard

---------- [1] http://thor.info.uaic.ro/~evalica/hci/L2/ [2] https://www.englishforums.com/English/IdiomsVsMetaphors/cqwl/post.htm

On Thu, Oct 2, 2014 at 12:47 PM, [email protected] wrote:

...

On 2 Oct 2014 at 11:06:00, Guillaume Louis-Marie Delhumeau ( [email protected](mailto:[email protected])) wrote:

...

Hi.

I have done the "test-on-my-wife" thing :)

She finds it more intuitive to add a page from the current page, so

in

...

the

...

current location, instead of the "black bar that gives the impression of not beeing a part of that page" (that she did not manage to find by herself).

I then explained that the buttons inside the page only concern the actions that you can do on that page, meanwhile adding a new page should be put in an other location. She did not like this logic :)

So with this logic we should remove the top bar completely and move all actions inside the page, i.e. have only 1 menu inside the page. Because if she couldn’t find the Add button there she also wouldn’t be able to find all wiki-related actions, space-related actions and more importantly **page-related** actions like copy page, rename page or delete page…

Also would be fun to ask your wife to try using Confluence and see if she fails to create a page there too.

Thanks -Vincent

...

Users' logic and developer's logic are not the same. I like the current location too, except that we should propose "create page" before "create wiki".

I really would like to have some feedback of normal users, with the 2 proposals. We, as developers, are not good at making things that look simple for other people, so we should not take this decision alone.

Thanks,

-- Guillaume Delhumeau

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Big +1 for Var3 for the simple fact that it looks like a "holistic"/global approach that does not only focus on a specific element, like the "Add" button and currently falls into the mistake of making it a bright shiny beacon to misguided users, resulting in something that is overall disturbing to the eye. Same can be said about the "Search" element, since it now reduces the heavy contrast of both the search input (bright white on dark background) and its search button (bright colored blue on dark background). About the Search button (re: Jeremie): Because it is the first element in its group, it will show to the left and no other elements will be disturbed, so the transition will be nice for users. Basically the expand search button (the magnifying glass) becomes a button once you expand it, so there should be no flicker or anything like that. - As an alternative, if we really are against transitions/animations/expandable elements/etc, we could just present the search as directly expanded (classic way), but still keep the darker input color to avoid the "kitch" effect described above due to high contrasts. About the + (Add) button, IMO, the only thing we could do more if we really want to emphasize it in an *elegant* fashion, would be to make the + sign itself green, or with some green border, whatever. Whatever we do, we should try to consider Caty's opinion on style here since she might have a better eye and this proposal here seems to be towards that direction. IMO, one very interesting thing to note is the extended (3.4) version and long term view that we also need to take into account and, at least to me, that looks really slick. I think we should stick to the original intent of this Flamingo skin, with the addition of Bootstrap's style, and keep it slick, minimalistic and to the point. The users should focus more on the content instead of the UI, don`t u think? ------ On a related note, If you ask me, I would be in favor of also removing the labels from "Edit" and "More actions" and just go with the *all too obvious* "pencil" and "cog" icons. GMail uses the "cog" icon with 0 problems and I kind of trust that their UX army did their research and impact studies for that :) Also, on matters of "consistency" we would achieve the following statement: "Actions have only icons, while entities have an icon and a label that displays the entity's name". - Actions: add, edit, search, more actions, etc. - Entities (with dropdown menu for actions on the entries): wiki, space, page, user. ------ Let's keep this skin clean and a pleasure to work on/with, WDYT? Thanks, Eduard On Thu, Oct 2, 2014 at 8:09 PM, Ecaterina Moraru (Valica) <[email protected]

wrote:

Hi,

I've created this proposal http://design.xwiki.org/xwiki/bin/view/Proposal/FlamingoAddMenuLocation Please read it and give your opinion on it. The proposal is based on discussed solution, but improves a bit the styling.

If you are curious how I reached some of the proposal's conclusions, you can see it's iterations

http://design.xwiki.org/xwiki/bin/view/Proposal/FlamingoAddMenuLocationItera...

Thanks, Caty

On Thu, Oct 2, 2014 at 7:59 PM, Guillaume Lerouge <[email protected]> wrote:

...

Hi,

actually one thing we could try is this:

- *Keep the "Add" button where it is and use it for page-related actions:* - "Add child page" - "Add comment" (as suggested by Denis) - "Add attachment" (as suggested by Denis)

- *Add a "Create" button in the top bar, with 2/3 options:* - "Create page" (TBD) - "Create space" - "Create wiki" - In this case, after clicking "Create" the user would be presented with a page / modal box listing existing instances as well as available templates

I think this would solve both my issues (having less-frequent actions in the same location as a more-frequent one, not being in the right place on the page) and GuillaumeD's wife issue (the "Add" button is easy to find where it is right now, why move it?).

WDYT?

Guillaume ᐧ

On Thu, Oct 2, 2014 at 1:48 PM, [email protected] <[email protected]> wrote:

...

On 2 Oct 2014 at 13:31:56, Eduard Moraru ([email protected](mailto: [email protected])) wrote:

...

On that note: The funny/sad thing to realise is that we are basing all this

discussion

...

on

...

the fact that some users did not find the "Add" button *only the first time* they tried to do something. The realization is that this is one of those things (idioms[1][2]) that you learn once and know how to easily do the next 1000x times (like riding a bike).

The real problem appears when you are in those "next 1000x time" and you find it cumbersome to use (like riding a bike with no saddle, or with the saddle on backwards :) ). So in both cases (top or middle of the page) once you find it once, you will find it again, however in the middle of the page it conflicts too often with the Edit button and other page related actions, that it becomes cumbersome to use.

Indeed that’s something I had in mind too. If you just ask to add a page and that’s all then you’re not doing a full test. You’d need to ask the user to: - add a page - delete a page - move a page - create a space - etc

And then only you can draw some conclusion IMO.

Thanks -Vincent

...

Thanks, Eduard

---------- [1] http://thor.info.uaic.ro/~evalica/hci/L2/ [2] https://www.englishforums.com/English/IdiomsVsMetaphors/cqwl/post.htm

On Thu, Oct 2, 2014 at 12:47 PM, [email protected] wrote:

...

On 2 Oct 2014 at 11:06:00, Guillaume Louis-Marie Delhumeau ( [email protected](mailto:[email protected])) wrote:

...

Hi.

I have done the "test-on-my-wife" thing :)

She finds it more intuitive to add a page from the current page,

so in

...

the

...

current location, instead of the "black bar that gives the impression of not beeing a part of that page" (that she did not manage to find by herself).

I then explained that the buttons inside the page only concern the actions that you can do on that page, meanwhile adding a new page should be put in an other location. She did not like this logic :)

So with this logic we should remove the top bar completely and move all actions inside the page, i.e. have only 1 menu inside the page. Because if she couldn’t find the Add button there she also wouldn’t be able to find all wiki-related actions, space-related actions and more importantly **page-related** actions like copy page, rename page or delete page…

Also would be fun to ask your wife to try using Confluence and see if she fails to create a page there too.

Thanks -Vincent

...

Users' logic and developer's logic are not the same. I like the current location too, except that we should propose "create page" before "create wiki".

I really would like to have some feedback of normal users, with the 2 proposals. We, as developers, are not good at making things that look simple for other people, so we should not take this decision alone.

Thanks,

-- Guillaume Delhumeau

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

  On 3 Oct 2014 at 13:05:08, Ecaterina Moraru (Valica) ([email protected](mailto:[email protected])) wrote:

Hi,

Some notes about the proposal:

- I like the 'Add' represented as '+' and after the Wiki/Space/Page breadcrumb, because is somehow consistent with the '+' (More applications) from the AppBar. Provides a way to create elements of a particular type in the near vicinity where the elements are displayed.

What I don’t like is that it’s the only menu entry at the top that wouldn’t have any text (just an icon) and it’s one of the most important one. I’d use a color (the green one looks fine to me to make it visible) for now for 6.2.2 and maybe do some usability testing on various variations as you did for the other usability tests, in order to gather more feedback and have more time to gather it.

- Although I know there will be some initial findability issues for the 'Add', after the user founds it I don't think it will have problems finding it again. We can improve the findability by finally providing an Introductory Wizard. Except for the initial moments when you learn XWiki, I don't see the point of having a very distinctive style for 'Add' and I would prefer to go on the consistent/integrated with the other navbar elements direction.

- The same comment about a distinctive style for 'Search'. IMO 'Search' should look integrated in the .navbar.

- I dislike the idea of having multiple 'Add' buttons. Also the 'Add - Comment to page' and 'Add - Attachment to page' are part of the Colibri skin, but IMO were 'close to never' used. I remember a bug on them that made them unusable and we discovered it after some years or something. Also I don't think we should provide buttons for all the functionality we can think of, but leave them be created from their context. I prefer having buttons just for the generic and base concepts of XWiki (in the try of keeping it minimal and simple).

- We are kind of going a bit too crazy about brainstorming and ideas. The only conclusion we need to reach is if for Flamingo we move the button back top.

Yes I agree completely with this. We shouldn’t mix everything right now or we won’t progress. The only other thing that we may want to have in 6.2.2 too is the removal of the 2 part-buttons at the top and the introduction of the “Go to…” for navigation. The rest is fine to discuss and tune for 6.3+ IMO. Thanks -Vincent

Thanks, Caty

On Fri, Oct 3, 2014 at 1:43 PM, Eduard Moraru wrote:

...

Big +1 for Var3 for the simple fact that it looks like a "holistic"/global approach that does not only focus on a specific element, like the "Add" button and currently falls into the mistake of making it a bright shiny beacon to misguided users, resulting in something that is overall disturbing to the eye. Same can be said about the "Search" element, since it now reduces the heavy contrast of both the search input (bright white on dark background) and its search button (bright colored blue on dark background).

About the Search button (re: Jeremie): Because it is the first element in its group, it will show to the left and no other elements will be disturbed, so the transition will be nice for users. Basically the expand search button (the magnifying glass) becomes a button once you expand it, so there should be no flicker or anything like that. - As an alternative, if we really are against transitions/animations/expandable elements/etc, we could just present the search as directly expanded (classic way), but still keep the darker input color to avoid the "kitch" effect described above due to high contrasts.

About the + (Add) button, IMO, the only thing we could do more if we really want to emphasize it in an *elegant* fashion, would be to make the + sign itself green, or with some green border, whatever. Whatever we do, we should try to consider Caty's opinion on style here since she might have a better eye and this proposal here seems to be towards that direction.

IMO, one very interesting thing to note is the extended (3.4) version and long term view that we also need to take into account and, at least to me, that looks really slick.

I think we should stick to the original intent of this Flamingo skin, with the addition of Bootstrap's style, and keep it slick, minimalistic and to the point. The users should focus more on the content instead of the UI, don`t u think?

------ On a related note, If you ask me, I would be in favor of also removing the labels from "Edit" and "More actions" and just go with the *all too obvious* "pencil" and "cog" icons. GMail uses the "cog" icon with 0 problems and I kind of trust that their UX army did their research and impact studies for that :)

Also, on matters of "consistency" we would achieve the following statement: "Actions have only icons, while entities have an icon and a label that displays the entity's name". - Actions: add, edit, search, more actions, etc. - Entities (with dropdown menu for actions on the entries): wiki, space, page, user. ------

Let's keep this skin clean and a pleasure to work on/with, WDYT?

Thanks, Eduard

On Thu, Oct 2, 2014 at 8:09 PM, Ecaterina Moraru (Valica) < [email protected]

...

wrote:

...

Hi,

I've created this proposal http://design.xwiki.org/xwiki/bin/view/Proposal/FlamingoAddMenuLocation Please read it and give your opinion on it. The proposal is based on discussed solution, but improves a bit the styling.

If you are curious how I reached some of the proposal's conclusions, you can see it's iterations

http://design.xwiki.org/xwiki/bin/view/Proposal/FlamingoAddMenuLocationItera...

...

Thanks, Caty

On Thu, Oct 2, 2014 at 7:59 PM, Guillaume Lerouge wrote:

...

Hi,

actually one thing we could try is this:

- *Keep the "Add" button where it is and use it for page-related actions:* - "Add child page" - "Add comment" (as suggested by Denis) - "Add attachment" (as suggested by Denis)

- *Add a "Create" button in the top bar, with 2/3 options:* - "Create page" (TBD) - "Create space" - "Create wiki" - In this case, after clicking "Create" the user would be presented with a page / modal box listing existing instances as well as available templates

I think this would solve both my issues (having less-frequent actions

in

...

...

the same location as a more-frequent one, not being in the right place on the page) and GuillaumeD's wife issue (the "Add" button is easy to find where it is right now, why move it?).

WDYT?

Guillaume ᐧ

On Thu, Oct 2, 2014 at 1:48 PM, [email protected] > > > wrote:

...

On 2 Oct 2014 at 13:31:56, Eduard Moraru ([email protected]

(mailto:

...

[email protected])) wrote:

...

On that note: The funny/sad thing to realise is that we are basing all this discussion on the fact that some users did not find the "Add" button *only the first time* they tried to do something. The realization is that this is one of those things (idioms[1][2]) that you learn once and know how to easily do the next 1000x times (like riding a bike).

The real problem appears when you are in those "next 1000x time" and you find it cumbersome to use (like riding a bike with no saddle, or with the saddle on backwards :) ). So in both cases (top or middle of the page) once you find it once, you will find it again, however in the middle of the page it conflicts too often with the Edit button and other page related actions, that it becomes cumbersome to use.

Indeed that’s something I had in mind too. If you just ask to add a page and that’s all then you’re not doing a full test. You’d need to ask the user to: - add a page - delete a page - move a page - create a space - etc

And then only you can draw some conclusion IMO.

Thanks -Vincent

...

Thanks, Eduard

---------- [1] http://thor.info.uaic.ro/~evalica/hci/L2/ [2]

https://www.englishforums.com/English/IdiomsVsMetaphors/cqwl/post.htm

...

...

On Thu, Oct 2, 2014 at 12:47 PM, [email protected] wrote:

> > > On 2 Oct 2014 at 11:06:00, Guillaume Louis-Marie Delhumeau ( > [email protected](mailto:[email protected])) wrote: > > > Hi. > > > > I have done the "test-on-my-wife" thing :) > > > > She finds it more intuitive to add a page from the current

page, so in

...

> the > > current location, instead of the "black bar that gives the impression of > > not beeing a part of that page" (that she did not manage to find by > > herself). > > > > I then explained that the buttons inside the page only concern the > actions > > that you can do on that page, meanwhile adding a new page should be put > in > > an other location. She did not like this logic :) > > So with this logic we should remove the top bar completely and move all > actions inside the page, i.e. have only 1 menu inside the page. Because if > she couldn’t find the Add button there she also wouldn’t be able to find > all wiki-related actions, space-related actions and more importantly > **page-related** actions like copy page, rename page or delete page… > > Also would be fun to ask your wife to try using Confluence and see if she > fails to create a page there too. > > Thanks > -Vincent > > > Users' logic and developer's logic are not the same. I like the current > > location too, except that we should propose "create page" before "create > > wiki". > > > > I really would like to have some feedback of normal users, with the 2 > > proposals. We, as developers, are not good at making things that look > > simple for other people, so we should not take this decision alone. > > > > Thanks, > > > > -- > > Guillaume Delhumeau

On Fri, Oct 3, 2014 at 3:28 PM, [email protected] <[email protected]> wrote:

On 3 Oct 2014 at 13:05:08, Ecaterina Moraru (Valica) ([email protected] (mailto:[email protected])) wrote:

...

Hi,

Some notes about the proposal:

- I like the 'Add' represented as '+' and after the Wiki/Space/Page breadcrumb, because is somehow consistent with the '+' (More applications) from the AppBar. Provides a way to create elements of a particular type in the near vicinity where the elements are displayed.

What I don’t like is that it’s the only menu entry at the top that wouldn’t have any text (just an icon) and it’s one of the most important one.

As I said in the proposal "Well known actions are represented with icons, while we provide text only for user generated entities (Wiki/Space/Page/User names)".

I’d use a color (the green one looks fine to me to make it visible) for now for 6.2.2 and maybe do some usability testing on various variations as you did for the other usability tests, in order to gather more feedback and have more time to gather it.

I've also iterated on the 'green color' idea, see http://design.xwiki.org/xwiki/bin/download/Proposal/FlamingoAddMenuLocationI... http://design.xwiki.org/xwiki/bin/download/Proposal/FlamingoAddMenuLocationI... but I prefer the initial proposal (with white) since I think the contrast is better and also we keep consistency between elements.

...

- Although I know there will be some initial findability issues for the 'Add', after the user founds it I don't think it will have problems finding it again. We can improve the findability by finally providing an Introductory Wizard. Except for the initial moments when you learn XWiki, I don't see the point of having a very distinctive style for 'Add' and I would prefer to go on the consistent/integrated with the other navbar elements direction.

- The same comment about a distinctive style for 'Search'. IMO 'Search' should look integrated in the .navbar.

- I dislike the idea of having multiple 'Add' buttons. Also the 'Add - Comment to page' and 'Add - Attachment to page' are part of the Colibri skin, but IMO were 'close to never' used. I remember a bug on them that made them unusable and we discovered it after some years or something. Also I don't think we should provide buttons for all the functionality we can think of, but leave them be created from their context. I prefer having buttons just for the generic and base concepts of XWiki (in the try of keeping it minimal and simple).

- We are kind of going a bit too crazy about brainstorming and ideas. The only conclusion we need to reach is if for Flamingo we move the button back top.

Yes I agree completely with this. We shouldn’t mix everything right now or we won’t progress.

The only other thing that we may want to have in 6.2.2 too is the removal of the 2 part-buttons at the top and the introduction of the “Go to…” for navigation.

I've created http://jira.xwiki.org/browse/XWIKI-11166 and http://jira.xwiki.org/browse/XWIKI-11167 Thanks, Caty

The rest is fine to discuss and tune for 6.3+ IMO.

Thanks -Vincent

...

Thanks, Caty

...

On Fri, Oct 3, 2014 at 1:43 PM, Eduard Moraru wrote:

...

Big +1 for Var3 for the simple fact that it looks like a

"holistic"/global

...

...

approach that does not only focus on a specific element, like the "Add" button and currently falls into the mistake of making it a bright shiny beacon to misguided users, resulting in something that is overall disturbing to the eye. Same can be said about the "Search" element, since it now reduces the heavy contrast of both the search input (bright white on dark background) and its search button (bright colored blue on dark background).

About the Search button (re: Jeremie): Because it is the first element in its group, it will show to the left and no other elements will be disturbed, so the transition will be nice for users. Basically the expand search button (the magnifying glass) becomes a button once you expand it, so there should be no flicker or anything like that. - As an alternative, if we really are against transitions/animations/expandable elements/etc, we could just present the search as directly expanded (classic way), but still keep the darker input color to avoid the "kitch" effect described above due to high contrasts.

About the + (Add) button, IMO, the only thing we could do more if we really want to emphasize it in an *elegant* fashion, would be to make the + sign itself green, or with some green border, whatever. Whatever we do, we should try to consider Caty's opinion on style here since she might have a better eye and this proposal here seems to be towards that direction.

IMO, one very interesting thing to note is the extended (3.4) version and long term view that we also need to take into account and, at least to me, that looks really slick.

I think we should stick to the original intent of this Flamingo skin, with the addition of Bootstrap's style, and keep it slick, minimalistic and to the point. The users should focus more on the content instead of the UI, don`t u think?

------ On a related note, If you ask me, I would be in favor of also removing the labels from "Edit" and "More actions" and just go with the *all too obvious* "pencil" and "cog" icons. GMail uses the "cog" icon with 0 problems and I kind of trust that their UX army did their research and impact studies for that :)

Also, on matters of "consistency" we would achieve the following statement: "Actions have only icons, while entities have an icon and a label that displays the entity's name". - Actions: add, edit, search, more actions, etc. - Entities (with dropdown menu for actions on the entries): wiki, space, page, user. ------

Let's keep this skin clean and a pleasure to work on/with, WDYT?

Thanks, Eduard

On Thu, Oct 2, 2014 at 8:09 PM, Ecaterina Moraru (Valica) < [email protected]

...

wrote:

...

Hi,

I've created this proposal

http://design.xwiki.org/xwiki/bin/view/Proposal/FlamingoAddMenuLocation

...

Please read it and give your opinion on it. The proposal is based on discussed solution, but improves a bit the styling.

If you are curious how I reached some of the proposal's conclusions, you can see it's iterations

http://design.xwiki.org/xwiki/bin/view/Proposal/FlamingoAddMenuLocationItera...

...

...

Thanks, Caty

On Thu, Oct 2, 2014 at 7:59 PM, Guillaume Lerouge wrote:

...

Hi,

actually one thing we could try is this:

- *Keep the "Add" button where it is and use it for page-related actions:* - "Add child page" - "Add comment" (as suggested by Denis) - "Add attachment" (as suggested by Denis)

- *Add a "Create" button in the top bar, with 2/3 options:* - "Create page" (TBD) - "Create space" - "Create wiki" - In this case, after clicking "Create" the user would be presented with a page / modal box listing existing instances as well as available templates

I think this would solve both my issues (having less-frequent

actions in

...

...

the same location as a more-frequent one, not being in the right place on the page) and GuillaumeD's wife issue (the "Add" button is easy to find where it is right now, why move it?).

WDYT?

Guillaume ᐧ

On Thu, Oct 2, 2014 at 1:48 PM, [email protected] > > > wrote:

...

On 2 Oct 2014 at 13:31:56, Eduard Moraru ([email protected]

(mailto:

...

[email protected])) wrote:

> On that note: > The funny/sad thing to realise is that we are basing all this discussion on > the fact that some users did not find the "Add" button *only the first > time* they tried to do something. The realization is that this is one of > those things (idioms[1][2]) that you learn once and know how to easily do > the next 1000x times (like riding a bike). > > The real problem appears when you are in those "next 1000x time" and you > find it cumbersome to use (like riding a bike with no saddle, or with the > saddle on backwards :) ). So in both cases (top or middle of the page) once > you find it once, you will find it again, however in the middle of the page > it conflicts too often with the Edit button and other page related actions, > that it becomes cumbersome to use.

Indeed that’s something I had in mind too. If you just ask to add a page and that’s all then you’re not doing a full test. You’d need to ask the user to: - add a page - delete a page - move a page - create a space - etc

And then only you can draw some conclusion IMO.

Thanks -Vincent

> Thanks, > Eduard > > ---------- > [1] http://thor.info.uaic.ro/~evalica/hci/L2/ > [2]

https://www.englishforums.com/English/IdiomsVsMetaphors/cqwl/post.htm

...

> > On Thu, Oct 2, 2014 at 12:47 PM, [email protected] > wrote: > > > > > > > On 2 Oct 2014 at 11:06:00, Guillaume Louis-Marie Delhumeau ( > > [email protected](mailto:[email protected])) wrote: > > > > > Hi. > > > > > > I have done the "test-on-my-wife" thing :) > > > > > > She finds it more intuitive to add a page from the current page, so in > > the > > > current location, instead of the "black bar that gives the impression of > > > not beeing a part of that page" (that she did not manage to find by > > > herself). > > > > > > I then explained that the buttons inside the page only concern the > > actions > > > that you can do on that page, meanwhile adding a new page should be put > > in > > > an other location. She did not like this logic :) > > > > So with this logic we should remove the top bar completely and move all > > actions inside the page, i.e. have only 1 menu inside the page. Because if > > she couldn’t find the Add button there she also wouldn’t be able to find > > all wiki-related actions, space-related actions and more importantly > > **page-related** actions like copy page, rename page or delete page… > > > > Also would be fun to ask your wife to try using Confluence and see if she > > fails to create a page there too. > > > > Thanks > > -Vincent > > > > > Users' logic and developer's logic are not the same. I like the current > > > location too, except that we should propose "create page" before "create > > > wiki". > > > > > > I really would like to have some feedback of normal users, with the 2 > > > proposals. We, as developers, are not good at making things that look > > > simple for other people, so we should not take this decision alone. > > > > > > Thanks, > > > > > > -- > > > Guillaume Delhumeau

On Fri, Oct 3, 2014 at 4:50 PM, [email protected] <[email protected]> wrote:

On 3 Oct 2014 at 15:33:53, Ecaterina Moraru (Valica) ([email protected] (mailto:[email protected])) wrote:

...

On Fri, Oct 3, 2014 at 3:28 PM, [email protected] wrote:

...

On 3 Oct 2014 at 13:05:08, Ecaterina Moraru (Valica) (

[email protected]

...

(mailto:[email protected])) wrote:

...

Hi,

Some notes about the proposal:

- I like the 'Add' represented as '+' and after the Wiki/Space/Page breadcrumb, because is somehow consistent with the '+' (More applications) from the AppBar. Provides a way to create elements of a particular type in the near vicinity where the elements are displayed.

What I don’t like is that it’s the only menu entry at the top that wouldn’t have any text (just an icon) and it’s one of the most important one.

As I said in the proposal "Well known actions are represented with icons, while we provide text only for user generated entities (Wiki/Space/Page/User names)”.

But I don’t see this anywhere in the current UI: we have “Edit”, “Add”, “More Actions..” which are all well known actions...

Is that a new rule you’d like to have?

If it is, it makes more sense to me to move all to this new rule at once instead of doing an exception just for the Add button, don’t you think so?

So yes, is not something existing, it was more of a premise I based my design when I did iterations (in order to assure consistency). For example, one of the iterations looks like this http://design.xwiki.org/xwiki/bin/download/Proposal/FlamingoAddMenuLocationI... (where even Edit and More actions are replaced with only icons) ... but again these are design ideas, iterations and proposals.

...

...

I’d use a color (the green one looks fine to me to make it visible) for now for 6.2.2 and maybe do some usability testing on various variations as you did for the other usability tests, in order to gather more feedback and have more time to gather it.

I've also iterated on the 'green color' idea, see

http://design.xwiki.org/xwiki/bin/download/Proposal/FlamingoAddMenuLocationI...

...

http://design.xwiki.org/xwiki/bin/download/Proposal/FlamingoAddMenuLocationI...

...

but I prefer the initial proposal (with white) since I think the contrast is better and also we keep consistency between elements.

I don’t think there needs to be a consistency because we want to draw attention to it which is not the case for the other elements. That said, using a “+” without text would be a consistency issue since it’s the only one like this...

Anyway, I don’t want to fight too long on this because I’d like us to move forward so if others are ok to use just a “+” with the same color as the other menus, then I’m fine (even though I don’t like it). BTW I hope it’s not too small and can be clicked on a mobile ;)

Actually I would need to make a proposal also for the mobile version, since there things are a bit messed up (because of the Search change) and we might need to provide a custom order. Thanks, Caty

Thanks -Vincent

...

...

sign

...

...

itself green, or with some green border, whatever. Whatever we do, we should try to consider Caty's opinion on style here since she might have a better eye and this proposal here seems to be towards that direction.

IMO, one very interesting thing to note is the extended (3.4) version and long term view that we also need to take into account and, at least to me, that looks really slick.

I think we should stick to the original intent of this Flamingo skin, with the addition of Bootstrap's style, and keep it slick, minimalistic and to the point. The users should focus more on the content instead of the UI, don`t u think?

------ On a related note, If you ask me, I would be in favor of also removing the labels from "Edit" and "More actions" and just go with the *all too obvious* "pencil" and "cog" icons. GMail uses the "cog" icon with 0 problems and I kind of trust that their UX army did their research and impact studies for that :)

Also, on matters of "consistency" we would achieve the following statement: "Actions have only icons, while entities have an icon and a label that displays the entity's name". - Actions: add, edit, search, more actions, etc. - Entities (with dropdown menu for actions on the entries): wiki, space, page, user. ------

Let's keep this skin clean and a pleasure to work on/with, WDYT?

Thanks, Eduard

On Thu, Oct 2, 2014 at 8:09 PM, Ecaterina Moraru (Valica) < [email protected]

...

wrote:

...

Hi,

I've created this proposal

http://design.xwiki.org/xwiki/bin/view/Proposal/FlamingoAddMenuLocation

...

...

...

...

Please read it and give your opinion on it. The proposal is based on discussed solution, but improves a bit the styling.

If you are curious how I reached some of the proposal's conclusions, you can see it's iterations

http://design.xwiki.org/xwiki/bin/view/Proposal/FlamingoAddMenuLocationItera...

...

...

...

...

Thanks, Caty

On Thu, Oct 2, 2014 at 7:59 PM, Guillaume Lerouge wrote:

> Hi, > > actually one thing we could try is this: > > - *Keep the "Add" button where it is and use it for

page-related

...

> actions:* > - "Add child page" > - "Add comment" (as suggested by Denis) > - "Add attachment" (as suggested by Denis) > > > - *Add a "Create" button in the top bar, with 2/3 options:* > - "Create page" (TBD) > - "Create space" > - "Create wiki" > - In this case, after clicking "Create" the user would be presented with > a page / modal box listing existing instances as well as available > templates > > I think this would solve both my issues (having less-frequent actions in > the same location as a more-frequent one, not being in the right place on > the page) and GuillaumeD's wife issue (the "Add" button is easy to find > where it is right now, why move it?). > > WDYT? > > Guillaume > ᐧ > > On Thu, Oct 2, 2014 at 1:48 PM, [email protected] > > > > wrote: > > > > > > On 2 Oct 2014 at 13:31:56, Eduard Moraru ( [email protected] (mailto: > > [email protected])) wrote: > > > > > On that note: > > > The funny/sad thing to realise is that we are basing all this > discussion > > on > > > the fact that some users did not find the "Add" button *only the first > > > time* they tried to do something. The realization is that this is one > of > > > those things (idioms[1][2]) that you learn once and know how to easily > do > > > the next 1000x times (like riding a bike). > > > > > > The real problem appears when you are in those "next 1000x time" and > you > > > find it cumbersome to use (like riding a bike with no saddle, or with > the > > > saddle on backwards :) ). So in both cases (top or middle of the page) > > once > > > you find it once, you will find it again, however in the middle of the > > page > > > it conflicts too often with the Edit button and other page related > > actions, > > > that it becomes cumbersome to use. > > > > Indeed that’s something I had in mind too. If you just ask to add a page > > and that’s all then you’re not doing a full test. You’d need to ask the > > user to: > > - add a page > > - delete a page > > - move a page > > - create a space > > - etc > > > > And then only you can draw some conclusion IMO. > > > > Thanks > > -Vincent > > > > > Thanks, > > > Eduard > > > > > > ---------- > > > [1] http://thor.info.uaic.ro/~evalica/hci/L2/ > > > [2] > >

https://www.englishforums.com/English/IdiomsVsMetaphors/cqwl/post.htm

...

...

> > > > > > On Thu, Oct 2, 2014 at 12:47 PM, [email protected] > > > wrote: > > > > > > > > > > > > > > > On 2 Oct 2014 at 11:06:00, Guillaume Louis-Marie Delhumeau ( > > > > [email protected](mailto:[email protected])) wrote: > > > > > > > > > Hi. > > > > > > > > > > I have done the "test-on-my-wife" thing :) > > > > > > > > > > She finds it more intuitive to add a page from the current page, so > > in > > > > the > > > > > current location, instead of the "black bar that gives the > > impression of > > > > > not beeing a part of that page" (that she did not manage to find by > > > > > herself). > > > > > > > > > > I then explained that the buttons inside the page only concern the > > > > actions > > > > > that you can do on that page, meanwhile adding a new page should be > > put > > > > in > > > > > an other location. She did not like this logic :) > > > > > > > > So with this logic we should remove the top bar completely and move > all > > > > actions inside the page, i.e. have only 1 menu inside the page. > > Because if > > > > she couldn’t find the Add button there she also wouldn’t be able to > > find > > > > all wiki-related actions, space-related actions and more importantly > > > > **page-related** actions like copy page, rename page or delete page… > > > > > > > > Also would be fun to ask your wife to try using Confluence and see if > > she > > > > fails to create a page there too. > > > > > > > > Thanks > > > > -Vincent > > > > > > > > > Users' logic and developer's logic are not the same. I like the > > current > > > > > location too, except that we should propose "create page" before > > "create > > > > > wiki". > > > > > > > > > > I really would like to have some feedback of normal users, with > the 2 > > > > > proposals. We, as developers, are not good at making things that > look > > > > > simple for other people, so we should not take this decision alone. > > > > > > > > > > Thanks, > > > > > > > > > > -- > > > > > Guillaume Delhumeau

...

...

...

Comment to page' and 'Add - Attachment to page' are part of the Colibri skin, but IMO were 'close to never' used. I remember a bug on them that made them unusable and we discovered it after some years or something. Also I don't think we should provide buttons for all the functionality we can think of, but leave them be created from their context. I prefer having buttons just for the generic and base concepts of XWiki (in the try of keeping it minimal and simple).

- We are kind of going a bit too crazy about brainstorming and ideas. The only conclusion we need to reach is if for Flamingo we move the button back top.

Yes I agree completely with this. We shouldn’t mix everything right now or we won’t progress.

The only other thing that we may want to have in 6.2.2 too is the removal of the 2 part-buttons at the top and the introduction of the “Go to…” for navigation.

I've created http://jira.xwiki.org/browse/XWIKI-11166 and http://jira.xwiki.org/browse/XWIKI-11167

Thanks, Caty

...

The rest is fine to discuss and tune for 6.3+ IMO.

Thanks -Vincent

...

Thanks, Caty

...

On Fri, Oct 3, 2014 at 1:43 PM, Eduard Moraru wrote:

...

Big +1 for Var3 for the simple fact that it looks like a

"holistic"/global

...

...

approach that does not only focus on a specific element, like the

"Add"

...

...

...

button and currently falls into the mistake of making it a bright shiny beacon to misguided users, resulting in something that is overall disturbing to the eye. Same can be said about the "Search" element, since it now reduces the heavy contrast of both the search input (bright white on dark background) and its search button (bright colored blue on dark background).

About the Search button (re: Jeremie): Because it is the first element in its group, it will show to the left and no other elements will be disturbed, so the transition will be nice for users. Basically the expand search button (the magnifying glass) becomes a button once you expand it, so there should be no flicker or anything like that. - As an alternative, if we really are against transitions/animations/expandable elements/etc, we could just present the search as directly expanded (classic way), but still keep the darker input color to avoid the "kitch" effect described above due to high contrasts.

About the + (Add) button, IMO, the only thing we could do more if we really want to emphasize it in an *elegant* fashion, would be to make the

...

...

...

- Although I know there will be some initial findability issues for the 'Add', after the user founds it I don't think it will have problems finding it again. We can improve the findability by finally providing an Introductory Wizard. Except for the initial moments when you learn XWiki, I don't see the point of having a very distinctive style for 'Add' and I would prefer to go on the consistent/integrated with the other navbar elements direction.

- The same comment about a distinctive style for 'Search'. IMO 'Search' should look integrated in the .navbar.

- I dislike the idea of having multiple 'Add' buttons. Also the 'Add

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

2014-10-03 15:57 GMT+02:00 Ecaterina Moraru (Valica) <[email protected]>:

On Fri, Oct 3, 2014 at 4:50 PM, [email protected] <[email protected]> wrote:

...

On 3 Oct 2014 at 15:33:53, Ecaterina Moraru (Valica) ([email protected] (mailto:[email protected])) wrote:

...

On Fri, Oct 3, 2014 at 3:28 PM, [email protected] wrote:

...

On 3 Oct 2014 at 13:05:08, Ecaterina Moraru (Valica) (

[email protected]

...

(mailto:[email protected])) wrote:

...

Hi,

Some notes about the proposal:

- I like the 'Add' represented as '+' and after the Wiki/Space/Page breadcrumb, because is somehow consistent with the '+' (More applications) from the AppBar. Provides a way to create elements of a particular type in the near vicinity where the elements are displayed.

What I don’t like is that it’s the only menu entry at the top that wouldn’t have any text (just an icon) and it’s one of the most important one.

As I said in the proposal "Well known actions are represented with

icons,

...

...

while we provide text only for user generated entities (Wiki/Space/Page/User names)”.

But I don’t see this anywhere in the current UI: we have “Edit”, “Add”, “More Actions..” which are all well known actions...

Is that a new rule you’d like to have?

If it is, it makes more sense to me to move all to this new rule at once instead of doing an exception just for the Add button, don’t you think so?

So yes, is not something existing, it was more of a premise I based my design when I did iterations (in order to assure consistency). For example, one of the iterations looks like this

http://design.xwiki.org/xwiki/bin/download/Proposal/FlamingoAddMenuLocationI... (where even Edit and More actions are replaced with only icons) ... but again these are design ideas, iterations and proposals.

I really like this one, as it's consistent with your premise and not "half consistent". I understand Vincent's point, but my "issue" is that the "+" in top menu doesn't look like an icon, it looks like a '+' character, and could use same font as the other text on left side (except that it's a bit thicker). So it seems half-way between an entity (as it's almost text) and a well known action (as it's an icon). This is not the case for the icons on the right side of top bar, as they clearly don't look like any character you usually produce with a keyboard (bell, message, magnifying glass). I don't really like the cog icon (and I never did), because if you don't know it yet you have no idea what to expect inside (I would except some administration or configuration stuff, which is not the case). Of course there are habits, but as a first time user, if I tell you "please administrate rights of this page", would you click on the pencil or on the cog ? ;-)

...

...

...

I’d use a color (the green one looks fine to me to make it visible)

for

...

...

...

now for 6.2.2 and maybe do some usability testing on various variations as you did for the other usability tests, in order to gather more feedback and have more time to gather it.

I've also iterated on the 'green color' idea, see

http://design.xwiki.org/xwiki/bin/download/Proposal/FlamingoAddMenuLocationI...

...

...

http://design.xwiki.org/xwiki/bin/download/Proposal/FlamingoAddMenuLocationI...

...

...

but I prefer the initial proposal (with white) since I think the contrast is better and also we keep consistency between elements.

I don’t think there needs to be a consistency because we want to draw attention to it which is not the case for the other elements. That said, using a “+” without text would be a consistency issue since it’s the only one like this...

Anyway, I don’t want to fight too long on this because I’d like us to move forward so if others are ok to use just a “+” with the same color as the other menus, then I’m fine (even though I don’t like it). BTW I hope it’s not too small and can be clicked on a mobile ;)

Actually I would need to make a proposal also for the mobile version, since there things are a bit messed up (because of the Search change) and we might need to provide a custom order.

Thanks, Caty

...

Thanks -Vincent

...

...

sign

...

...

itself green, or with some green border, whatever. Whatever we do, we should try to consider Caty's opinion on style here since she might have a better eye and this proposal here seems to be towards that direction.

IMO, one very interesting thing to note is the extended (3.4) version and long term view that we also need to take into account and, at least to me, that looks really slick.

I think we should stick to the original intent of this Flamingo skin, with the addition of Bootstrap's style, and keep it slick, minimalistic and to the point. The users should focus more on the content instead of the UI, don`t u think?

------ On a related note, If you ask me, I would be in favor of also removing the labels from "Edit" and "More actions" and just go with the *all too obvious* "pencil" and "cog" icons. GMail uses the "cog" icon with 0 problems and I kind of trust that their UX army did their research and impact studies for that :)

Also, on matters of "consistency" we would achieve the following statement: "Actions have only icons, while entities have an icon and a label that displays the entity's name". - Actions: add, edit, search, more actions, etc. - Entities (with dropdown menu for actions on the entries): wiki, space, page, user. ------

Let's keep this skin clean and a pleasure to work on/with, WDYT?

Thanks, Eduard

On Thu, Oct 2, 2014 at 8:09 PM, Ecaterina Moraru (Valica) < [email protected] > wrote:

> Hi, > > I've created this proposal >

http://design.xwiki.org/xwiki/bin/view/Proposal/FlamingoAddMenuLocation

...

...

...

> Please read it and give your opinion on it. The proposal is based on > discussed solution, but improves a bit the styling. > > If you are curious how I reached some of the proposal's conclusions, you > can see it's iterations > >

...

...

...

Comment to page' and 'Add - Attachment to page' are part of the Colibri skin, but IMO were 'close to never' used. I remember a bug on them that made them unusable and we discovered it after some years or something. Also I don't think we should provide buttons for all the functionality we can think of, but leave them be created from their context. I prefer having buttons just for the generic and base concepts of XWiki (in the try of keeping it minimal and simple).

- We are kind of going a bit too crazy about brainstorming and ideas. The only conclusion we need to reach is if for Flamingo we move the button back top.

Yes I agree completely with this. We shouldn’t mix everything right now or we won’t progress.

The only other thing that we may want to have in 6.2.2 too is the removal of the 2 part-buttons at the top and the introduction of the “Go to…” for navigation.

I've created http://jira.xwiki.org/browse/XWIKI-11166 and http://jira.xwiki.org/browse/XWIKI-11167

Thanks, Caty

...

The rest is fine to discuss and tune for 6.3+ IMO.

Thanks -Vincent

...

Thanks, Caty

...

On Fri, Oct 3, 2014 at 1:43 PM, Eduard Moraru wrote:

...

Big +1 for Var3 for the simple fact that it looks like a

"holistic"/global

...

...

approach that does not only focus on a specific element, like the

"Add"

...

...

...

button and currently falls into the mistake of making it a bright shiny beacon to misguided users, resulting in something that is overall disturbing to the eye. Same can be said about the "Search" element, since it now reduces the heavy contrast of both the search input (bright white on dark background) and its search button (bright colored blue on dark background).

About the Search button (re: Jeremie): Because it is the first element in its group, it will show to the left and no other elements will be disturbed, so the transition will be nice for users. Basically the expand search button (the magnifying glass) becomes a button once you expand it, so there should be no flicker or anything like that. - As an alternative, if we really are against transitions/animations/expandable elements/etc, we could just present the search as directly expanded (classic way), but still keep the darker input color to avoid the "kitch" effect described above due to high contrasts.

About the + (Add) button, IMO, the only thing we could do more if we really want to emphasize it in an *elegant* fashion, would be to make the

...

...

...

- Although I know there will be some initial findability issues for the 'Add', after the user founds it I don't think it will have problems finding it again. We can improve the findability by finally providing an Introductory Wizard. Except for the initial moments when you learn XWiki, I don't see the point of having a very distinctive style for 'Add' and I would prefer to go on the consistent/integrated with the other navbar elements direction.

- The same comment about a distinctive style for 'Search'. IMO 'Search' should look integrated in the .navbar.

- I dislike the idea of having multiple 'Add' buttons. Also the 'Add

http://design.xwiki.org/xwiki/bin/view/Proposal/FlamingoAddMenuLocationItera...

...

...

...

...

...

> > Thanks, > Caty > > > > On Thu, Oct 2, 2014 at 7:59 PM, Guillaume Lerouge > wrote: > > > Hi, > > > > actually one thing we could try is this: > > > > - *Keep the "Add" button where it is and use it for page-related > > actions:* > > - "Add child page" > > - "Add comment" (as suggested by Denis) > > - "Add attachment" (as suggested by Denis) > > > > > > - *Add a "Create" button in the top bar, with 2/3 options:* > > - "Create page" (TBD) > > - "Create space" > > - "Create wiki" > > - In this case, after clicking "Create" the user would be presented > with > > a page / modal box listing existing instances as well as available > > templates > > > > I think this would solve both my issues (having less-frequent actions in > > the same location as a more-frequent one, not being in the right place on > > the page) and GuillaumeD's wife issue (the "Add" button is easy to find > > where it is right now, why move it?). > > > > WDYT? > > > > Guillaume > > ᐧ > > > > On Thu, Oct 2, 2014 at 1:48 PM, [email protected] > > > > > wrote: > > > > > > > > > On 2 Oct 2014 at 13:31:56, Eduard Moraru ( [email protected] (mailto: > > > [email protected])) wrote: > > > > > > > On that note: > > > > The funny/sad thing to realise is that we are basing all this > > discussion > > > on > > > > the fact that some users did not find the "Add" button *only the > first > > > > time* they tried to do something. The realization is that this is one > > of > > > > those things (idioms[1][2]) that you learn once and know how to > easily > > do > > > > the next 1000x times (like riding a bike). > > > > > > > > The real problem appears when you are in those "next 1000x time" and > > you > > > > find it cumbersome to use (like riding a bike with no saddle, or with > > the > > > > saddle on backwards :) ). So in both cases (top or middle of the > page) > > > once > > > > you find it once, you will find it again, however in the middle of > the > > > page > > > > it conflicts too often with the Edit button and other page related > > > actions, > > > > that it becomes cumbersome to use. > > > > > > Indeed that’s something I had in mind too. If you just ask to add a > page > > > and that’s all then you’re not doing a full test. You’d need to ask the > > > user to: > > > - add a page > > > - delete a page > > > - move a page > > > - create a space > > > - etc > > > > > > And then only you can draw some conclusion IMO. > > > > > > Thanks > > > -Vincent > > > > > > > Thanks, > > > > Eduard > > > > > > > > ---------- > > > > [1] http://thor.info.uaic.ro/~evalica/hci/L2/ > > > > [2] > > >

https://www.englishforums.com/English/IdiomsVsMetaphors/cqwl/post.htm

...

> > > > > > > > On Thu, Oct 2, 2014 at 12:47 PM, [email protected] > > > > wrote: > > > > > > > > > > > > > > > > > > > On 2 Oct 2014 at 11:06:00, Guillaume Louis-Marie Delhumeau ( > > > > > [email protected](mailto:[email protected])) wrote: > > > > > > > > > > > Hi. > > > > > > > > > > > > I have done the "test-on-my-wife" thing :) > > > > > > > > > > > > She finds it more intuitive to add a page from the current page, > so > > > in > > > > > the > > > > > > current location, instead of the "black bar that gives the > > > impression of > > > > > > not beeing a part of that page" (that she did not manage to find > by > > > > > > herself). > > > > > > > > > > > > I then explained that the buttons inside the page only concern > the > > > > > actions > > > > > > that you can do on that page, meanwhile adding a new page should > be > > > put > > > > > in > > > > > > an other location. She did not like this logic :) > > > > > > > > > > So with this logic we should remove the top bar completely and move > > all > > > > > actions inside the page, i.e. have only 1 menu inside the page. > > > Because if > > > > > she couldn’t find the Add button there she also wouldn’t be able to > > > find > > > > > all wiki-related actions, space-related actions and more > importantly > > > > > **page-related** actions like copy page, rename page or delete > page… > > > > > > > > > > Also would be fun to ask your wife to try using Confluence and see > if > > > she > > > > > fails to create a page there too. > > > > > > > > > > Thanks > > > > > -Vincent > > > > > > > > > > > Users' logic and developer's logic are not the same. I like the > > > current > > > > > > location too, except that we should propose "create page" before > > > "create > > > > > > wiki". > > > > > > > > > > > > I really would like to have some feedback of normal users, with > > the 2 > > > > > > proposals. We, as developers, are not good at making things that > > look > > > > > > simple for other people, so we should not take this decision > alone. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > -- > > > > > > Guillaume Delhumeau

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hello all, Guillaume D tallked to me about this so, as any visual issue, I have an opinion about it too. I think thhe button should be, at least for now, in the top menu (see under for the explanation if you want). Hoewver, var 3 has 2 problems for me: 1. the + button for the add in the top menu is 1/ not consistent with other menus which have labels and 2/ can be interpreted as a "more menus", like you'd click on the + to get "hidden" menu items 2. If I have a 1920px screen, what reason in the world would I have to not want to see the full search input directly? I think a full search input is better, greyed as proposed in 3.2 I would like something like Var 2, with Add button controlled by color theme with the possibility to choose for it the same color as the menu, to "melt" it in the menu (so that it would be less visibile). And a grayed search box, or responsive so that if the screen is small, it's reduced to an icon (like in Var 3). Now, on the placement of the button: I think it's hard to understand how can Add Space or Add Wiki be next to editing the current page. Indeed, you can consider that, since the created page is a child page of the current page, it makes sense to Add a page in the context of the current page BUT, until rights are inherited on the parent-child relation, this is a very dangerous logic to highlight to users. Also, you can choose the space of the new page upon creation, thus creating it "elsewhere" but the "current context", so it can be considered as a non-context related action. Sorry I didn't feedback earlier about this, it seems it's indeed easier when you see it (or show it to other people). Also it was probably always surrounded a bit by the whole confusion created for me by the placement of the edit buttons to the right (I am used to going to the left so it's always puzzling for me; I'll just get used to it, this is a change I like). Thanks, Anca On Fri, Oct 3, 2014 at 6:53 PM, [email protected] <[email protected]> wrote:

On 3 Oct 2014 at 18:40:50, Jeremie BOUSQUET ([email protected] (mailto:[email protected])) wrote:

...

2014-10-03 15:57 GMT+02:00 Ecaterina Moraru (Valica) :

...

On Fri, Oct 3, 2014 at 4:50 PM, [email protected] wrote:

...

On 3 Oct 2014 at 15:33:53, Ecaterina Moraru (Valica) (

[email protected]

...

(mailto:[email protected])) wrote:

...

On Fri, Oct 3, 2014 at 3:28 PM, [email protected] wrote:

...

On 3 Oct 2014 at 13:05:08, Ecaterina Moraru (Valica) (

[email protected]

...

(mailto:[email protected])) wrote:

> Hi, > > Some notes about the proposal: > > - I like the 'Add' represented as '+' and after the Wiki/Space/Page > breadcrumb, because is somehow consistent with the '+' (More applications) > from the AppBar. Provides a way to create elements of a particular type in > the near vicinity where the elements are displayed.

What I don’t like is that it’s the only menu entry at the top that wouldn’t have any text (just an icon) and it’s one of the most important one.

As I said in the proposal "Well known actions are represented with icons, while we provide text only for user generated entities (Wiki/Space/Page/User names)”.

But I don’t see this anywhere in the current UI: we have “Edit”, “Add”, “More Actions..” which are all well known actions...

Is that a new rule you’d like to have?

If it is, it makes more sense to me to move all to this new rule at once instead of doing an exception just for the Add button, don’t you think so?

So yes, is not something existing, it was more of a premise I based my design when I did iterations (in order to assure consistency). For example, one of the iterations looks like this

http://design.xwiki.org/xwiki/bin/download/Proposal/FlamingoAddMenuLocationI...

...

(where even Edit and More actions are replaced with only icons) ... but again these are design ideas, iterations and proposals.

I really like this one, as it's consistent with your premise and not "half consistent”.

Yes I also like it because it makes the UI a bit less cluttered. What I don’t like is “half consistent”, i.e. just the “+” without the rest using long names.

Now I’m not sure if at this stage we’re prepared to make such a larger jump/change for 6.2.2. This is why I was proposing to move the Add feature at the top while keeping the “Add” text for now and do what Caty proposes as the next step. OTOH if everyone agrees with this change right now, I’m fine with going ahead with it right now too...

Thanks -Vincent

...

I understand Vincent's point, but my "issue" is that the "+" in top menu doesn't look like an icon, it looks like a '+' character, and could use same font as the other text on left side (except that it's a bit thicker). So it seems half-way between an entity (as it's almost text) and a well known action (as it's an icon). This is not the case for the icons on the right side of top bar, as they clearly don't look like any character you usually produce with a keyboard (bell, message, magnifying glass).

I don't really like the cog icon (and I never did), because if you don't know it yet you have no idea what to expect inside (I would except some administration or configuration stuff, which is not the case). Of course there are habits, but as a first time user, if I tell you "please administrate rights of this page", would you click on the pencil or on the cog ? ;-)

...

...

...

...

I’d use a color (the green one looks fine to me to make it

visible)

...

for

...

...

...

now for 6.2.2 and maybe do some usability testing on various variations as you did for the other usability tests, in order to gather more feedback and have more time to gather it.

I've also iterated on the 'green color' idea, see

http://design.xwiki.org/xwiki/bin/download/Proposal/FlamingoAddMenuLocationI...

...

...

...

http://design.xwiki.org/xwiki/bin/download/Proposal/FlamingoAddMenuLocationI...

...

...

...

but I prefer the initial proposal (with white) since I think the contrast is better and also we keep consistency between elements.

I don’t think there needs to be a consistency because we want to draw attention to it which is not the case for the other elements. That said, using a “+” without text would be a consistency issue since it’s the only one like this...

Anyway, I don’t want to fight too long on this because I’d like us to move forward so if others are ok to use just a “+” with the same color as the other menus, then I’m fine (even though I don’t like it). BTW I hope it’s not too small and can be clicked on a mobile ;)

Actually I would need to make a proposal also for the mobile version, since there things are a bit messed up (because of the Search change) and we might need to provide a custom order.

Thanks, Caty

...

Thanks -Vincent

...

...

sign > > itself green, or with some green border, whatever. Whatever we do, we > > should try to consider Caty's opinion on style here since she might have a > > better eye and this proposal here seems to be towards that direction. > > > > IMO, one very interesting thing to note is the extended (3.4) version and > > long term view that we also need to take into account and, at least to me, > > that looks really slick. > > > > I think we should stick to the original intent of this Flamingo skin, with > > the addition of Bootstrap's style, and keep it slick, minimalistic and to > > the point. The users should focus more on the content instead of the UI, > > don`t u think? > > > > ------ > > On a related note, If you ask me, I would be in favor of also removing the > > labels from "Edit" and "More actions" and just go with the *all too > > obvious* "pencil" and "cog" icons. GMail uses the "cog" icon with 0 > > problems and I kind of trust that their UX army did their research and > > impact studies for that :) > > > > Also, on matters of "consistency" we would achieve the following statement: > > "Actions have only icons, while entities have an icon and a label that > > displays the entity's name". > > - Actions: add, edit, search, more actions, etc. > > - Entities (with dropdown menu for actions on the entries): wiki, space, > > page, user. > > ------ > > > > Let's keep this skin clean and a pleasure to work on/with, WDYT? > > > > Thanks, > > Eduard > > > > On Thu, Oct 2, 2014 at 8:09 PM, Ecaterina Moraru (Valica) < > > [email protected] > > > wrote: > > > > > Hi, > > > > > > I've created this proposal > > >

...

...

> Comment to page' and 'Add - Attachment to page' are part of the Colibri > skin, but IMO were 'close to never' used. I remember a bug on them that > made them unusable and we discovered it after some years or something. Also > I don't think we should provide buttons for all the functionality we can > think of, but leave them be created from their context. I prefer having > buttons just for the generic and base concepts of XWiki (in the try of > keeping it minimal and simple). > > - We are kind of going a bit too crazy about brainstorming and ideas. The > only conclusion we need to reach is if for Flamingo we move the button back > top.

Yes I agree completely with this. We shouldn’t mix everything right now or we won’t progress.

The only other thing that we may want to have in 6.2.2 too is the removal of the 2 part-buttons at the top and the introduction of the “Go to…” for navigation.

I've created http://jira.xwiki.org/browse/XWIKI-11166 and http://jira.xwiki.org/browse/XWIKI-11167

Thanks, Caty

...

The rest is fine to discuss and tune for 6.3+ IMO.

Thanks -Vincent

> Thanks, > Caty

> > On Fri, Oct 3, 2014 at 1:43 PM, Eduard Moraru wrote: > > > Big +1 for Var3 for the simple fact that it looks like a "holistic"/global > > approach that does not only focus on a specific element,

like the "Add"

...

> > button and currently falls into the mistake of making it a bright shiny > > beacon to misguided users, resulting in something that is overall > > disturbing to the eye. Same can be said about the "Search" element, since > > it now reduces the heavy contrast of both the search input (bright white on > > dark background) and its search button (bright colored blue on dark > > background). > > > > About the Search button (re: Jeremie): Because it is the first element in > > its group, it will show to the left and no other elements will be > > disturbed, so the transition will be nice for users. Basically the expand > > search button (the magnifying glass) becomes a button once you expand it, > > so there should be no flicker or anything like that. > > - As an alternative, if we really are against > > transitions/animations/expandable elements/etc, we could just present the > > search as directly expanded (classic way), but still keep the darker input > > color to avoid the "kitch" effect described above due to high contrasts. > > > > About the + (Add) button, IMO, the only thing we could do more if we really > > want to emphasize it in an *elegant* fashion, would be to make the

...

...

> - Although I know there will be some initial findability issues for the > 'Add', after the user founds it I don't think it will have problems finding > it again. We can improve the findability by finally providing an > Introductory Wizard. Except for the initial moments when you learn XWiki, I > don't see the point of having a very distinctive style for 'Add' and I > would prefer to go on the consistent/integrated with the other navbar > elements direction. > > - The same comment about a distinctive style for 'Search'. IMO 'Search' > should look integrated in the .navbar. > > - I dislike the idea of having multiple 'Add' buttons. Also the 'Add

http://design.xwiki.org/xwiki/bin/view/Proposal/FlamingoAddMenuLocation

...

...

...

> > > Please read it and give your opinion on it. The proposal is based on > > > discussed solution, but improves a bit the styling. > > > > > > If you are curious how I reached some of the proposal's conclusions, you > > > can see it's iterations > > > > > > > >

http://design.xwiki.org/xwiki/bin/view/Proposal/FlamingoAddMenuLocationItera...

...

...

...

...

> > > > > > Thanks, > > > Caty > > > > > > > > > > > > On Thu, Oct 2, 2014 at 7:59 PM, Guillaume Lerouge > > > wrote: > > > > > > > Hi, > > > > > > > > actually one thing we could try is this: > > > > > > > > - *Keep the "Add" button where it is and use it for page-related > > > > actions:* > > > > - "Add child page" > > > > - "Add comment" (as suggested by Denis) > > > > - "Add attachment" (as suggested by Denis) > > > > > > > > > > > > - *Add a "Create" button in the top bar, with 2/3 options:* > > > > - "Create page" (TBD) > > > > - "Create space" > > > > - "Create wiki" > > > > - In this case, after clicking "Create" the user would be presented > > > with > > > > a page / modal box listing existing instances as well as available > > > > templates > > > > > > > > I think this would solve both my issues (having less-frequent actions > > in > > > > the same location as a more-frequent one, not being in the right place > > on > > > > the page) and GuillaumeD's wife issue (the "Add" button is easy to find > > > > where it is right now, why move it?). > > > > > > > > WDYT? > > > > > > > > Guillaume > > > > ᐧ > > > > > > > > On Thu, Oct 2, 2014 at 1:48 PM, [email protected] > > > > > > > wrote: > > > > > > > > > > > > > > > On 2 Oct 2014 at 13:31:56, Eduard Moraru ( [email protected] > > (mailto: > > > > > [email protected])) wrote: > > > > > > > > > > > On that note: > > > > > > The funny/sad thing to realise is that we are basing all this > > > > discussion > > > > > on > > > > > > the fact that some users did not find the "Add" button *only the > > > first > > > > > > time* they tried to do something. The realization is that this is > > one > > > > of > > > > > > those things (idioms[1][2]) that you learn once and know how to > > > easily > > > > do > > > > > > the next 1000x times (like riding a bike). > > > > > > > > > > > > The real problem appears when you are in those "next 1000x time" > > and > > > > you > > > > > > find it cumbersome to use (like riding a bike with no saddle, or > > with > > > > the > > > > > > saddle on backwards :) ). So in both cases (top or middle of the > > > page) > > > > > once > > > > > > you find it once, you will find it again, however in the middle of > > > the > > > > > page > > > > > > it conflicts too often with the Edit button and other page related > > > > > actions, > > > > > > that it becomes cumbersome to use. > > > > > > > > > > Indeed that’s something I had in mind too. If you just ask to add a > > > page > > > > > and that’s all then you’re not doing a full test. You’d need to ask > > the > > > > > user to: > > > > > - add a page > > > > > - delete a page > > > > > - move a page > > > > > - create a space > > > > > - etc > > > > > > > > > > And then only you can draw some conclusion IMO. > > > > > > > > > > Thanks > > > > > -Vincent > > > > > > > > > > > Thanks, > > > > > > Eduard > > > > > > > > > > > > ---------- > > > > > > [1] http://thor.info.uaic.ro/~evalica/hci/L2/ > > > > > > [2] > > > > > > >

https://www.englishforums.com/English/IdiomsVsMetaphors/cqwl/post.htm

...

...

...

> > > > > > > > > > > > On Thu, Oct 2, 2014 at 12:47 PM, [email protected] > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2 Oct 2014 at 11:06:00, Guillaume Louis-Marie Delhumeau ( > > > > > > > [email protected](mailto:[email protected])) wrote: > > > > > > > > > > > > > > > Hi. > > > > > > > > > > > > > > > > I have done the "test-on-my-wife" thing :) > > > > > > > > > > > > > > > > She finds it more intuitive to add a page from the current > > page, > > > so > > > > > in > > > > > > > the > > > > > > > > current location, instead of the "black bar that gives the > > > > > impression of > > > > > > > > not beeing a part of that page" (that she did not manage to > > find > > > by > > > > > > > > herself). > > > > > > > > > > > > > > > > I then explained that the buttons inside the page only concern > > > the > > > > > > > actions > > > > > > > > that you can do on that page, meanwhile adding a new page > > should > > > be > > > > > put > > > > > > > in > > > > > > > > an other location. She did not like this logic :) > > > > > > > > > > > > > > So with this logic we should remove the top bar completely and > > move > > > > all > > > > > > > actions inside the page, i.e. have only 1 menu inside the page. > > > > > Because if > > > > > > > she couldn’t find the Add button there she also wouldn’t be able > > to > > > > > find > > > > > > > all wiki-related actions, space-related actions and more > > > importantly > > > > > > > **page-related** actions like copy page, rename page or delete > > > page… > > > > > > > > > > > > > > Also would be fun to ask your wife to try using Confluence and > > see > > > if > > > > > she > > > > > > > fails to create a page there too. > > > > > > > > > > > > > > Thanks > > > > > > > -Vincent > > > > > > > > > > > > > > > Users' logic and developer's logic are not the same. I like the > > > > > current > > > > > > > > location too, except that we should propose "create page" > > before > > > > > "create > > > > > > > > wiki". > > > > > > > > > > > > > > > > I really would like to have some feedback of normal users, with > > > > the 2 > > > > > > > > proposals. We, as developers, are not good at making things > > that > > > > look > > > > > > > > simple for other people, so we should not take this decision > > > alone. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > -- > > > > > > > > Guillaume Delhumeau

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On Thu, Oct 2, 2014 at 6:59 PM, Guillaume Lerouge <[email protected]> wrote:

Hi,

actually one thing we could try is this:

- *Keep the "Add" button where it is and use it for page-related actions:* - "Add child page" - "Add comment" (as suggested by Denis) - "Add attachment" (as suggested by Denis)

- *Add a "Create" button in the top bar, with 2/3 options:* - "Create page" (TBD) - "Create space" - "Create wiki" - In this case, after clicking "Create" the user would be presented with a page / modal box listing existing instances as well as available templates

I think this would solve both my issues (having less-frequent actions in the same location as a more-frequent one, not being in the right place on the page) and GuillaumeD's wife issue (the "Add" button is easy to find where it is right now, why move it?).

WDYT?

Big +1 for me. I am convince we need "in context" and "out of context" operation to be separated.

Guillaume ᐧ

On Thu, Oct 2, 2014 at 1:48 PM, [email protected] <[email protected]> wrote:

...

On 2 Oct 2014 at 13:31:56, Eduard Moraru ([email protected](mailto: [email protected])) wrote:

...

On that note: The funny/sad thing to realise is that we are basing all this

discussion

...

on

...

the fact that some users did not find the "Add" button *only the first time* they tried to do something. The realization is that this is one of those things (idioms[1][2]) that you learn once and know how to easily do the next 1000x times (like riding a bike).

The real problem appears when you are in those "next 1000x time" and you find it cumbersome to use (like riding a bike with no saddle, or with the saddle on backwards :) ). So in both cases (top or middle of the page) once you find it once, you will find it again, however in the middle of the page it conflicts too often with the Edit button and other page related actions, that it becomes cumbersome to use.

Indeed that’s something I had in mind too. If you just ask to add a page and that’s all then you’re not doing a full test. You’d need to ask the user to: - add a page - delete a page - move a page - create a space - etc

And then only you can draw some conclusion IMO.

Thanks -Vincent

...

Thanks, Eduard

---------- [1] http://thor.info.uaic.ro/~evalica/hci/L2/ [2] https://www.englishforums.com/English/IdiomsVsMetaphors/cqwl/post.htm

On Thu, Oct 2, 2014 at 12:47 PM, [email protected] wrote:

...

On 2 Oct 2014 at 11:06:00, Guillaume Louis-Marie Delhumeau ( [email protected](mailto:[email protected])) wrote:

...

Hi.

I have done the "test-on-my-wife" thing :)

She finds it more intuitive to add a page from the current page, so

in

...

the

...

current location, instead of the "black bar that gives the impression of not beeing a part of that page" (that she did not manage to find by herself).

I then explained that the buttons inside the page only concern the actions that you can do on that page, meanwhile adding a new page should be put in an other location. She did not like this logic :)

So with this logic we should remove the top bar completely and move all actions inside the page, i.e. have only 1 menu inside the page. Because if she couldn’t find the Add button there she also wouldn’t be able to find all wiki-related actions, space-related actions and more importantly **page-related** actions like copy page, rename page or delete page…

Also would be fun to ask your wife to try using Confluence and see if she fails to create a page there too.

Thanks -Vincent

...

Users' logic and developer's logic are not the same. I like the current location too, except that we should propose "create page" before "create wiki".

I really would like to have some feedback of normal users, with the 2 proposals. We, as developers, are not good at making things that look simple for other people, so we should not take this decision alone.

Thanks,

-- Guillaume Delhumeau

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Denis Gervalle SOFTEC sa - CEO

On Fri, Oct 3, 2014 at 1:19 AM, [email protected] <[email protected]> wrote:

On 2 Oct 2014 at 21:11:11, Denis Gervalle ([email protected](mailto: [email protected])) wrote:

...

On Thu, Oct 2, 2014 at 6:59 PM, Guillaume Lerouge wrote:

...

Hi,

actually one thing we could try is this:

- *Keep the "Add" button where it is and use it for page-related actions:*

This is not fully true. It’s NOT about page-related actions at all. It’s about page **content** actions.

Page-related actions are in the top level menus with “Delete page”, “rename page”, “move page”. So it makes sense to have “Create child page” in there too.

This is true, but not necessarily an issue here, it could be discussed. Basically, it is about adding more content to that content. It does not prevent the Page menu to contains the same option BTW. Giving user multiple path to the same action is not necessarily bad, it allow each user to use the tool with its own way of thinking.

...

...

- "Add child page”

How would it look differently than the one at the top since both have the current page as the default parent?

By not implicitly choose a parent, but proposing to choose one in addition to the name. So this the create feature, no matter where I am, I want something new.

...

...

- "Add comment" (as suggested by Denis) - "Add attachment" (as suggested by Denis)

The show links in the More actions menu also allow to add comments/attachments and so does the extradoc tabs at the bottom of the page. I’m wondering if it’s not confusing to have so many ways of doing the same thing.

What I propose is different Vincent, it allow quickly adding comments, attachment and more if affinity, using a modal without scrolling (BTW, I also find annoying these buttons gets out of sight when scrolling) and without showing other object of the same nature (this is only an add feature). In regards to proposing the same feature from many different places, if we stay consistent in naming those function, the user will see more benefit than confusion. Actually, the duplication of the extradoc and the independent pages for the same feature is more confusing. The link you mention are also not very easy, because they load a new page (BTW, on those pages the link to go back to content is buried into the more option menu, not very intuitive).

...

...

- *Add a "Create" button in the top bar, with 2/3 options:* - "Create page" (TBD) - "Create space" - "Create wiki" - In this case, after clicking "Create" the user would be presented with a page / modal box listing existing instances as well as available templates

I think this would solve both my issues (having less-frequent actions in the same location as a more-frequent one, not being in the right place on the page) and GuillaumeD's wife issue (the "Add" button is easy to find where it is right now, why move it?).

WDYT?

Big +1 for me. I am convince we need "in context" and "out of context" operation to be separated.

I’m a bit less convinced than you Denis that have 2 “Add” actions is a good thing. Don’t you think it could be confusing for the user and I don’t think it’s very clear when to use one or another. And even more so since the page that appears when you click them is the same one in both cases…

ATM I still prefer having a single Add/Create button at the top by far

Actually this will not be the case, but if the feeling is that adding a page from the content is confusing, we will removed it. This does remove the need for a button to add stuff to content. As said earlier, we will also need to allow applications to hook on these buttons. On the top bar one to add more options for creating content out of context, and on the content one to add new objects to the current page. So even if you get rid of the content Add, my felling is that it will come back soon for application purposes anyway.

Thanks -Vincent

...

...

Guillaume ᐧ

On Thu, Oct 2, 2014 at 1:48 PM, [email protected] wrote:

...

On 2 Oct 2014 at 13:31:56, Eduard Moraru ([email protected]

(mailto:

...

[email protected])) wrote:

...

On that note: The funny/sad thing to realise is that we are basing all this discussion on the fact that some users did not find the "Add" button *only the first time* they tried to do something. The realization is that this is one of those things (idioms[1][2]) that you learn once and know how to easily do the next 1000x times (like riding a bike).

The real problem appears when you are in those "next 1000x time" and you find it cumbersome to use (like riding a bike with no saddle, or with the saddle on backwards :) ). So in both cases (top or middle of the page) once you find it once, you will find it again, however in the middle of the page it conflicts too often with the Edit button and other page related actions, that it becomes cumbersome to use.

Indeed that’s something I had in mind too. If you just ask to add a page and that’s all then you’re not doing a full test. You’d need to ask the user to: - add a page - delete a page - move a page - create a space - etc

And then only you can draw some conclusion IMO.

Thanks -Vincent

...

Thanks, Eduard

---------- [1] http://thor.info.uaic.ro/~evalica/hci/L2/ [2]

https://www.englishforums.com/English/IdiomsVsMetaphors/cqwl/post.htm

...

...

On Thu, Oct 2, 2014 at 12:47 PM, [email protected] wrote:

...

On 2 Oct 2014 at 11:06:00, Guillaume Louis-Marie Delhumeau ( [email protected](mailto:[email protected])) wrote:

> Hi. > > I have done the "test-on-my-wife" thing :) > > She finds it more intuitive to add a page from the current

page, so in

...

...

the > current location, instead of the "black bar that gives the impression of > not beeing a part of that page" (that she did not manage to find by > herself). > > I then explained that the buttons inside the page only concern the actions > that you can do on that page, meanwhile adding a new page should be put in > an other location. She did not like this logic :)

So with this logic we should remove the top bar completely and move all actions inside the page, i.e. have only 1 menu inside the page. Because if she couldn’t find the Add button there she also wouldn’t be able to find all wiki-related actions, space-related actions and more importantly **page-related** actions like copy page, rename page or delete page…

Also would be fun to ask your wife to try using Confluence and see if she fails to create a page there too.

Thanks -Vincent

> Users' logic and developer's logic are not the same. I like the current > location too, except that we should propose "create page" before "create > wiki". > > I really would like to have some feedback of normal users, with the 2 > proposals. We, as developers, are not good at making things that look > simple for other people, so we should not take this decision alone. > > Thanks, > > -- > Guillaume Delhumeau

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Denis Gervalle SOFTEC sa - CEO