Re: [xwiki-users] [Proposal][UX] Feedback for Visible Save buttons

[Mahomed Hussein]

I don't really use small viewports but if I did, my vote would be for 
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/after.png

The design is clean, flows and is intuitive. (Unless I've misunderstood you, 
and you are saying this is the way it looks now :) )

I have noticed that you have lost "Preview" from the compacted bar. Maybe make 
the left button preview, the right button is "Save & View" with a drop down for 
"Save & Continue" (like you have with the Edit/Settings button.


Kind regards,




Mahomed Hussein
Custodian Data Centre
Email: maho...@custodiandc.com
http://www.CustodianDC.com

-Original Message-
From: users [mailto:users-boun...@xwiki.org] On Behalf Of Ecaterina Moraru 
(Valica)
Sent: 25 April 2017 18:22
To: XWiki Mailinglist 
Subject: [xwiki-users] [Proposal][UX] Feedback for Visible Save buttons

Hi,

We had some users complaining that the first time they edit a page they don't 
know how to save it. Depending on the screen resolution, the save buttons since 
they are at the bottom of the page are not visible and some users don't know 
they need to scroll in order to see them.

We want to make some changes to XWiki, that:
- Display the save buttons in a fixed bottom bar, when they are out of the 
viewport, see 
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/bottomBar.png
- When the user scroll, the buttons go into their position, see 
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/after.png
- We compacted the bottom functionalities (summary, minor, auto-save), see
before:
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/before.png
after:
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/smallViewPort.png

What do you think about this proposal? Would it improve the visibility of the 
buttons? Do you have other ideas? Is it something we should implement?

Thanks,
Caty

Re: [xwiki-users] [Proposal][UX] Feedback for Visible Save buttons

[Ecaterina Moraru (Valica)]

Hi,

The proposal it's just one version, but the image you vote for is how it
will look like, after the user scrolls. Yes, it is the new / proposed
version, so I'm glad you like it.

On Wed, Apr 26, 2017 at 1:04 PM, Mahomed Hussein 
wrote:

> I don't really use small viewports but if I did, my vote would be for
> http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaVisibleSave/after.png
>
> The design is clean, flows and is intuitive. (Unless I've misunderstood
> you, and you are saying this is the way it looks now :) )
>
> I have noticed that you have lost "Preview" from the compacted bar. Maybe
> make the left button preview, the right button is "Save & View" with a drop
> down for "Save & Continue" (like you have with the Edit/Settings button.
>

I've removed the Preview for the WYSIWYG mode, but it would be necessary
for the Wiki mode.

Regarding the dropdown with the options, initially I iterated it but I
don't quite like how it looked
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/5.png

Thanks for our feedback,
Caty


>
>
> Kind regards,
>
>
>
>
> Mahomed Hussein
> Custodian Data Centre
> Email: maho...@custodiandc.com
> http://www.CustodianDC.com
>
> -Original Message-
> From: users [mailto:users-boun...@xwiki.org] On Behalf Of Ecaterina
> Moraru (Valica)
> Sent: 25 April 2017 18:22
> To: XWiki Mailinglist 
> Subject: [xwiki-users] [Proposal][UX] Feedback for Visible Save buttons
>
> Hi,
>
> We had some users complaining that the first time they edit a page they
> don't know how to save it. Depending on the screen resolution, the save
> buttons since they are at the bottom of the page are not visible and some
> users don't know they need to scroll in order to see them.
>
> We want to make some changes to XWiki, that:
> - Display the save buttons in a fixed bottom bar, when they are out of the
> viewport, see http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaVisibleSave/bottomBar.png
> - When the user scroll, the buttons go into their position, see
> http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaVisibleSave/after.png
> - We compacted the bottom functionalities (summary, minor, auto-save), see
> before:
> http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaVisibleSave/before.png
> after:
> http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaVisibleSave/smallViewPort.png
>
> What do you think about this proposal? Would it improve the visibility of
> the buttons? Do you have other ideas? Is it something we should implement?
>
> Thanks,
> Caty
>

Re: [xwiki-users] [Proposal][UX] Feedback for Visible Save buttons

[Ecaterina Moraru (Valica)]

Hi,

On Wed, Apr 26, 2017 at 2:39 PM, Craig Wright  wrote:

> Overall I like these changes. A couple of suggestions:
>
> No one in my community understands “Save and Continue” versus “Save and
> View”. Dropping the “and Continue” is a great step, but I would go farther
> and give “Save and View” the emphasis color (blue, in this case). That is
> the more highly understood behavior. “Save” (and continue editing) is
> useful but not as generally useful as “Save and View”. Especially if you
> are dropping Preview.
>
> FWIW, I use Preview more often from WYSIWYG mode since there is not a 1:1
> translation of editor view to page view. Whereas, when I am editing source,
> I can predict how it will look most of the time. :)
>
> I would also move the Cancel button over next to the other buttons. If I
> had to rate which buttons I use the most frequently, “Cancel” would be at
> the top, followed by “Save and View,” followed very very distantly by “Save
> and Continue."
>
>
This is very interesting behavior. I would love to be able to have some
usage stats, but with XWiki being installable and independently hosted,
stats are always hard to get by.

Personally I use "Save" a lot (I like to save often in order to not lose
stuff), but I usually use the keyboard shortcut, not necessarily the
button. It is true that 'Preview' in WYSIWYG has its usages, especially
when using macros or nested macros, since the result is not accurate.

Regarding "Save & View" I always do it as a final step, while I never use
"Cancel" - i just navigate away or hit the browser's 'Back'.

Also in terms of functionality the "Autosave" can be used instead of the
"Save", so we can remove 'Save' (especially in case of advanced users).

So the only stats I have are from the http://playground.xwiki.org from the
past 2 months. These are the top 3 pages edited, see
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/UsageFebApr2017.png

Now let's see the heatmaps:
- Sandbox.WebHome:
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/Sandbox-Home.png
- Sandbox.TestPage1:
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/Sandbox-TestPage1.png
- Sandbox.Test.WebHome:
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/Sandbox-Test.png

>From these heatmaps we see that 'Preview' has the most usage and after is
"Save&View", with no usage for "Save & Continue" and "Cancel".
Not we need to take into account 2 aspects: Sandbox is used by first-time
users of XWiki and they usually are afraid to mess things up so the Preview
is comforting for them. Also in the current layout 'Preview' is the first
button from left-to-right, so it's assumed as the primary action.

So if the initial proposal was 'varA', what do you think about 'varB'?
- var A [Save; Save & View]:
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/varA.png
- var B [Save & View; Preview]:
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/varB.png
- var C [Save & View; Save]:
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/varC.png

Note: users that went to 'Preview', usually come back to the previous view,
see
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/Sandbox-Test-preview.png

I left 'Cancel' at the end, in order to be the last button and have
visibility (not get lost in all the other options). Users need to use it as
an 'escape' route, so it's better to find it fast and always have a static
position = last. For this usually the first and last positions are best.

My initial rationale to remove 'Preview' from the WYSIWYG editor was that
WYSIWYG does life preview, so I though not many users use it, since I never
used it. Seeing the stats for newcomers is impressive, still it would be
great if more advanced / long-term users of XWiki would summaries a bit
their button usage, so we could take a more informed decision. XWiki needs
to accommodate both newcomers, but also long term users.

Thanks,
Caty


> Nice work!
>
> Craig
>
>
> > On Apr 25, 2017, at 6:21 PM, Ecaterina Moraru (Valica) <
> vali...@gmail.com> wrote:
> >
> > Hi,
> >
> > We had some users complaining that the first time they edit a page they
> > don't know how to save it. Depending on the screen resolution, the save
> > buttons since they are at the bottom of the page are not visible and some
> > users don't know they need to scroll in order to see them.
> >
> > We want to make some changes to XWiki, that:
> > - Display the save buttons in a fixed bottom bar, when they are out of
> the
> > viewport, see
> > http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaVisibleSave/bottomBar.png
> > - When the user scroll, the buttons go into their position, see
> > http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaVisibleSave/after.png
> > - We compacted the bottom functionalities (summary, minor, auto-save),
> see
> > before:
> > http://design.xwiki.org/xwiki/bin/download/Proposal/
> Id

Re: [xwiki-users] [Proposal][UX] Feedback for Visible Save buttons

[Olivier Seres]

I'm +1 with what Craig and Mahomed said ie :

   - Save & View to be highlighted in blue
   - Preview to be useful

In order to incitate users to write add a summary of the modification, I
think it would help to place the box  it in the first position (like
Confluence did) with a strong hint like : "What did you modify?"

In my craziest dreams, I also saw a : "PDF preview" there so that I don't
feel obliged to go to the Kebab "More actions" menu and search for it :-)








--
  *Olivier Sérès*

*  VP Business Development*  ose...@xwiki.com
  skype: olivierseres
Linkedin 
  Mobile : +33 6 61 31 2001






On Wed, Apr 26, 2017 at 1:39 PM, Craig Wright  wrote:

> Overall I like these changes. A couple of suggestions:
>
> No one in my community understands “Save and Continue” versus “Save and
> View”. Dropping the “and Continue” is a great step, but I would go farther
> and give “Save and View” the emphasis color (blue, in this case). That is
> the more highly understood behavior. “Save” (and continue editing) is
> useful but not as generally useful as “Save and View”. Especially if you
> are dropping Preview.
>
> FWIW, I use Preview more often from WYSIWYG mode since there is not a 1:1
> translation of editor view to page view. Whereas, when I am editing source,
> I can predict how it will look most of the time. :)
>
> I would also move the Cancel button over next to the other buttons. If I
> had to rate which buttons I use the most frequently, “Cancel” would be at
> the top, followed by “Save and View,” followed very very distantly by “Save
> and Continue."
>
> Nice work!
>
> Craig
>
>
> > On Apr 25, 2017, at 6:21 PM, Ecaterina Moraru (Valica) <
> vali...@gmail.com> wrote:
> >
> > Hi,
> >
> > We had some users complaining that the first time they edit a page they
> > don't know how to save it. Depending on the screen resolution, the save
> > buttons since they are at the bottom of the page are not visible and some
> > users don't know they need to scroll in order to see them.
> >
> > We want to make some changes to XWiki, that:
> > - Display the save buttons in a fixed bottom bar, when they are out of
> the
> > viewport, see
> > http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaVisibleSave/bottomBar.png
> > - When the user scroll, the buttons go into their position, see
> > http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaVisibleSave/after.png
> > - We compacted the bottom functionalities (summary, minor, auto-save),
> see
> > before:
> > http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaVisibleSave/before.png
> > after:
> > http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaVisibleSave/smallViewPort.png
> >
> > What do you think about this proposal? Would it improve the visibility of
> > the buttons? Do you have other ideas? Is it something we should
> implement?
> >
> > Thanks,
> > Caty
>
>

Re: [xwiki-users] [Proposal][UX] Feedback for Visible Save buttons

[Craig Wright]

Hi Caty,

I am a fan of “B”. 

I like the idea of putting the changelog and autosave options above on a 
preceding row. I would argue that for most users, their eyes only see the 
leftmost buttons as the functionally useful area. Thus putting Cancel on the 
far right effectively “hides” the button. 

For the purposes of mobile, I think it is acceptable to hide the changelog and 
autosave options on small-screen resolutions. (Such as when I am editing from 
iPhone, I am highly unlikely to leave a changelog message anyway.)

FWIW, taborder should be the following:

1. Edit input
2. Changelog input
3. Save button
4. Preview button
5. Cancel button
6. Autosave option

My $0.02. :)

Thanks,
Craig

> On Apr 26, 2017, at 2:20 PM, Ecaterina Moraru (Valica)  
> wrote:
> 
> Hi,
> 
> On Wed, Apr 26, 2017 at 2:39 PM, Craig Wright  > wrote:
> 
>> Overall I like these changes. A couple of suggestions:
>> 
>> No one in my community understands “Save and Continue” versus “Save and
>> View”. Dropping the “and Continue” is a great step, but I would go farther
>> and give “Save and View” the emphasis color (blue, in this case). That is
>> the more highly understood behavior. “Save” (and continue editing) is
>> useful but not as generally useful as “Save and View”. Especially if you
>> are dropping Preview.
>> 
>> FWIW, I use Preview more often from WYSIWYG mode since there is not a 1:1
>> translation of editor view to page view. Whereas, when I am editing source,
>> I can predict how it will look most of the time. :)
>> 
>> I would also move the Cancel button over next to the other buttons. If I
>> had to rate which buttons I use the most frequently, “Cancel” would be at
>> the top, followed by “Save and View,” followed very very distantly by “Save
>> and Continue."
>> 
>> 
> This is very interesting behavior. I would love to be able to have some
> usage stats, but with XWiki being installable and independently hosted,
> stats are always hard to get by.
> 
> Personally I use "Save" a lot (I like to save often in order to not lose
> stuff), but I usually use the keyboard shortcut, not necessarily the
> button. It is true that 'Preview' in WYSIWYG has its usages, especially
> when using macros or nested macros, since the result is not accurate.
> 
> Regarding "Save & View" I always do it as a final step, while I never use
> "Cancel" - i just navigate away or hit the browser's 'Back'.
> 
> Also in terms of functionality the "Autosave" can be used instead of the
> "Save", so we can remove 'Save' (especially in case of advanced users).
> 
> So the only stats I have are from the http://playground.xwiki.org 
>  from the
> past 2 months. These are the top 3 pages edited, see
> http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/UsageFebApr2017.png
>  
> 
> 
> Now let's see the heatmaps:
> - Sandbox.WebHome:
> http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/Sandbox-Home.png
>  
> 
> - Sandbox.TestPage1:
> http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/Sandbox-TestPage1.png
>  
> 
> - Sandbox.Test.WebHome:
> http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/Sandbox-Test.png
>  
> 
> 
> From these heatmaps we see that 'Preview' has the most usage and after is
> "Save&View", with no usage for "Save & Continue" and "Cancel".
> Not we need to take into account 2 aspects: Sandbox is used by first-time
> users of XWiki and they usually are afraid to mess things up so the Preview
> is comforting for them. Also in the current layout 'Preview' is the first
> button from left-to-right, so it's assumed as the primary action.
> 
> So if the initial proposal was 'varA', what do you think about 'varB'?
> - var A [Save; Save & View]:
> http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/varA.png 
> 
> - var B [Save & View; Preview]:
> http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/varB.png 
> 
> - var C [Save & View; Save]:
> http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/varC.png 
> 
> 
> Note: users that went to 'Preview', usually come back to the previous view,
> see
> http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/Sandbox-Test-preview.png
>  
> 
> 
> I left 'Cancel' at the

Re: [xwiki-users] [Proposal][UX] Feedback for Visible Save buttons

[Ecaterina Moraru (Valica)]

On Wed, Apr 26, 2017 at 5:41 PM, Craig Wright  wrote:

> Hi Caty,
>
> I am a fan of “B”.
>
> I like the idea of putting the changelog and autosave options above on a
> preceding row. I would argue that for most users, their eyes only see the
> leftmost buttons as the functionally useful area. Thus putting Cancel on
> the far right effectively “hides” the button.
>

Yes, the most visible buttons are the ones on the left side and that's the
purpose. We need people to see the Save button :)
Now, 'summary' functionality is not mandatory when editing and can also be
disabled from Administration - Editing.
Having it on a separate line is not an option since we initial idea of the
thread is to provide a fixed bottom bar, when the viewport is small. So
there are all on a single bar in order to be compact.


>
> For the purposes of mobile, I think it is acceptable to hide the changelog
> and autosave options on small-screen resolutions. (Such as when I am
> editing from iPhone, I am highly unlikely to leave a changelog message
> anyway.)
>

I haven't iterated much on the mobile version, but the mockup I have is
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/mobile.png
It can be improved, and as you said we could decide that on mobile we can
hide some functionality, but again hard to have stats to justify what is
used/needed or not.

Thanks,
Caty


> FWIW, taborder should be the following:
>
> 1. Edit input
> 2. Changelog input
> 3. Save button
> 4. Preview button
> 5. Cancel button
> 6. Autosave option
>
> My $0.02. :)
>
> Thanks,
> Craig
>
> > On Apr 26, 2017, at 2:20 PM, Ecaterina Moraru (Valica) <
> vali...@gmail.com> wrote:
> >
> > Hi,
> >
> > On Wed, Apr 26, 2017 at 2:39 PM, Craig Wright  > wrote:
> >
> >> Overall I like these changes. A couple of suggestions:
> >>
> >> No one in my community understands “Save and Continue” versus “Save and
> >> View”. Dropping the “and Continue” is a great step, but I would go
> farther
> >> and give “Save and View” the emphasis color (blue, in this case). That
> is
> >> the more highly understood behavior. “Save” (and continue editing) is
> >> useful but not as generally useful as “Save and View”. Especially if you
> >> are dropping Preview.
> >>
> >> FWIW, I use Preview more often from WYSIWYG mode since there is not a
> 1:1
> >> translation of editor view to page view. Whereas, when I am editing
> source,
> >> I can predict how it will look most of the time. :)
> >>
> >> I would also move the Cancel button over next to the other buttons. If I
> >> had to rate which buttons I use the most frequently, “Cancel” would be
> at
> >> the top, followed by “Save and View,” followed very very distantly by
> “Save
> >> and Continue."
> >>
> >>
> > This is very interesting behavior. I would love to be able to have some
> > usage stats, but with XWiki being installable and independently hosted,
> > stats are always hard to get by.
> >
> > Personally I use "Save" a lot (I like to save often in order to not lose
> > stuff), but I usually use the keyboard shortcut, not necessarily the
> > button. It is true that 'Preview' in WYSIWYG has its usages, especially
> > when using macros or nested macros, since the result is not accurate.
> >
> > Regarding "Save & View" I always do it as a final step, while I never use
> > "Cancel" - i just navigate away or hit the browser's 'Back'.
> >
> > Also in terms of functionality the "Autosave" can be used instead of the
> > "Save", so we can remove 'Save' (especially in case of advanced users).
> >
> > So the only stats I have are from the http://playground.xwiki.org <
> http://playground.xwiki.org/> from the
> > past 2 months. These are the top 3 pages edited, see
> > http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/
> UsageFebApr2017.png  IdeaVisibleSave/UsageFebApr2017.png>
> >
> > Now let's see the heatmaps:
> > - Sandbox.WebHome:
> > http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaVisibleSave/Sandbox-Home.png  xwiki/bin/download/Proposal/IdeaVisibleSave/Sandbox-Home.png>
> > - Sandbox.TestPage1:
> > http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaVisibleSave/Sandbox-TestPage1.png  xwiki/bin/download/Proposal/IdeaVisibleSave/Sandbox-TestPage1.png>
> > - Sandbox.Test.WebHome:
> > http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaVisibleSave/Sandbox-Test.png  xwiki/bin/download/Proposal/IdeaVisibleSave/Sandbox-Test.png>
> >
> > From these heatmaps we see that 'Preview' has the most usage and after is
> > "Save&View", with no usage for "Save & Continue" and "Cancel".
> > Not we need to take into account 2 aspects: Sandbox is used by first-time
> > users of XWiki and they usually are afraid to mess things up so the
> Preview
> > is comforting for them. Also in the current layout 'Preview' is the first
> > button from left-to

Re: [xwiki-users] [Proposal][UX] Feedback for Visible Save buttons

[Denis GERMAIN]

Great proposition ! I like it.

I see that the subject has also diverted to the fact that you can "save and
continue" and "save and view". Some of our users are lost the first time as
they click "save and continue" and don't understand why they are still in
edit mode. Clarifying this would indeed be a good idea, even though they
usually get the distinction quickly after that.

Regards,
Denis

2017-04-26 17:01 GMT+02:00 Ecaterina Moraru (Valica) :

> On Wed, Apr 26, 2017 at 5:41 PM, Craig Wright  wrote:
>
> > Hi Caty,
> >
> > I am a fan of “B”.
> >
> > I like the idea of putting the changelog and autosave options above on a
> > preceding row. I would argue that for most users, their eyes only see the
> > leftmost buttons as the functionally useful area. Thus putting Cancel on
> > the far right effectively “hides” the button.
> >
>
> Yes, the most visible buttons are the ones on the left side and that's the
> purpose. We need people to see the Save button :)
> Now, 'summary' functionality is not mandatory when editing and can also be
> disabled from Administration - Editing.
> Having it on a separate line is not an option since we initial idea of the
> thread is to provide a fixed bottom bar, when the viewport is small. So
> there are all on a single bar in order to be compact.
>
>
> >
> > For the purposes of mobile, I think it is acceptable to hide the
> changelog
> > and autosave options on small-screen resolutions. (Such as when I am
> > editing from iPhone, I am highly unlikely to leave a changelog message
> > anyway.)
> >
>
> I haven't iterated much on the mobile version, but the mockup I have is
> http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaVisibleSave/mobile.png
> It can be improved, and as you said we could decide that on mobile we can
> hide some functionality, but again hard to have stats to justify what is
> used/needed or not.
>
> Thanks,
> Caty
>
>
> > FWIW, taborder should be the following:
> >
> > 1. Edit input
> > 2. Changelog input
> > 3. Save button
> > 4. Preview button
> > 5. Cancel button
> > 6. Autosave option
> >
> > My $0.02. :)
> >
> > Thanks,
> > Craig
> >
> > > On Apr 26, 2017, at 2:20 PM, Ecaterina Moraru (Valica) <
> > vali...@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > On Wed, Apr 26, 2017 at 2:39 PM, Craig Wright  > > wrote:
> > >
> > >> Overall I like these changes. A couple of suggestions:
> > >>
> > >> No one in my community understands “Save and Continue” versus “Save
> and
> > >> View”. Dropping the “and Continue” is a great step, but I would go
> > farther
> > >> and give “Save and View” the emphasis color (blue, in this case). That
> > is
> > >> the more highly understood behavior. “Save” (and continue editing) is
> > >> useful but not as generally useful as “Save and View”. Especially if
> you
> > >> are dropping Preview.
> > >>
> > >> FWIW, I use Preview more often from WYSIWYG mode since there is not a
> > 1:1
> > >> translation of editor view to page view. Whereas, when I am editing
> > source,
> > >> I can predict how it will look most of the time. :)
> > >>
> > >> I would also move the Cancel button over next to the other buttons.
> If I
> > >> had to rate which buttons I use the most frequently, “Cancel” would be
> > at
> > >> the top, followed by “Save and View,” followed very very distantly by
> > “Save
> > >> and Continue."
> > >>
> > >>
> > > This is very interesting behavior. I would love to be able to have some
> > > usage stats, but with XWiki being installable and independently hosted,
> > > stats are always hard to get by.
> > >
> > > Personally I use "Save" a lot (I like to save often in order to not
> lose
> > > stuff), but I usually use the keyboard shortcut, not necessarily the
> > > button. It is true that 'Preview' in WYSIWYG has its usages, especially
> > > when using macros or nested macros, since the result is not accurate.
> > >
> > > Regarding "Save & View" I always do it as a final step, while I never
> use
> > > "Cancel" - i just navigate away or hit the browser's 'Back'.
> > >
> > > Also in terms of functionality the "Autosave" can be used instead of
> the
> > > "Save", so we can remove 'Save' (especially in case of advanced users).
> > >
> > > So the only stats I have are from the http://playground.xwiki.org <
> > http://playground.xwiki.org/> from the
> > > past 2 months. These are the top 3 pages edited, see
> > > http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/
> > UsageFebApr2017.png  xwiki/bin/download/Proposal/
> > IdeaVisibleSave/UsageFebApr2017.png>
> > >
> > > Now let's see the heatmaps:
> > > - Sandbox.WebHome:
> > > http://design.xwiki.org/xwiki/bin/download/Proposal/
> > IdeaVisibleSave/Sandbox-Home.png  > xwiki/bin/download/Proposal/IdeaVisibleSave/Sandbox-Home.png>
> > > - Sandbox.TestPage1:
> > > http://design.xwiki.org/xwiki/bin/download/Proposal/
> > IdeaVisibleSave/Sandbox-TestPage1.png 

Re: [xwiki-users] [Proposal][UX] Feedback for Visible Save buttons

[Ecaterina Moraru (Valica)]

I've created this form to gather data about the buttons usage, in order to
make a proposal for the buttons location
https://docs.google.com/forms/d/e/1FAIpQLSeQwjxlFl321Ap97xKlYRcf-39wlG-cJXXqM1nududfjo3KHQ/viewanalytics

Hope everyone is comfortable with Google Forms.
Thanks,
Caty


On Thu, Apr 27, 2017 at 12:56 PM, Denis GERMAIN 
wrote:

> Great proposition ! I like it.
>
> I see that the subject has also diverted to the fact that you can "save and
> continue" and "save and view". Some of our users are lost the first time as
> they click "save and continue" and don't understand why they are still in
> edit mode. Clarifying this would indeed be a good idea, even though they
> usually get the distinction quickly after that.
>
> Regards,
> Denis
>
> 2017-04-26 17:01 GMT+02:00 Ecaterina Moraru (Valica) :
>
> > On Wed, Apr 26, 2017 at 5:41 PM, Craig Wright  wrote:
> >
> > > Hi Caty,
> > >
> > > I am a fan of “B”.
> > >
> > > I like the idea of putting the changelog and autosave options above on
> a
> > > preceding row. I would argue that for most users, their eyes only see
> the
> > > leftmost buttons as the functionally useful area. Thus putting Cancel
> on
> > > the far right effectively “hides” the button.
> > >
> >
> > Yes, the most visible buttons are the ones on the left side and that's
> the
> > purpose. We need people to see the Save button :)
> > Now, 'summary' functionality is not mandatory when editing and can also
> be
> > disabled from Administration - Editing.
> > Having it on a separate line is not an option since we initial idea of
> the
> > thread is to provide a fixed bottom bar, when the viewport is small. So
> > there are all on a single bar in order to be compact.
> >
> >
> > >
> > > For the purposes of mobile, I think it is acceptable to hide the
> > changelog
> > > and autosave options on small-screen resolutions. (Such as when I am
> > > editing from iPhone, I am highly unlikely to leave a changelog message
> > > anyway.)
> > >
> >
> > I haven't iterated much on the mobile version, but the mockup I have is
> > http://design.xwiki.org/xwiki/bin/download/Proposal/
> > IdeaVisibleSave/mobile.png
> > It can be improved, and as you said we could decide that on mobile we can
> > hide some functionality, but again hard to have stats to justify what is
> > used/needed or not.
> >
> > Thanks,
> > Caty
> >
> >
> > > FWIW, taborder should be the following:
> > >
> > > 1. Edit input
> > > 2. Changelog input
> > > 3. Save button
> > > 4. Preview button
> > > 5. Cancel button
> > > 6. Autosave option
> > >
> > > My $0.02. :)
> > >
> > > Thanks,
> > > Craig
> > >
> > > > On Apr 26, 2017, at 2:20 PM, Ecaterina Moraru (Valica) <
> > > vali...@gmail.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Wed, Apr 26, 2017 at 2:39 PM, Craig Wright  > > > wrote:
> > > >
> > > >> Overall I like these changes. A couple of suggestions:
> > > >>
> > > >> No one in my community understands “Save and Continue” versus “Save
> > and
> > > >> View”. Dropping the “and Continue” is a great step, but I would go
> > > farther
> > > >> and give “Save and View” the emphasis color (blue, in this case).
> That
> > > is
> > > >> the more highly understood behavior. “Save” (and continue editing)
> is
> > > >> useful but not as generally useful as “Save and View”. Especially if
> > you
> > > >> are dropping Preview.
> > > >>
> > > >> FWIW, I use Preview more often from WYSIWYG mode since there is not
> a
> > > 1:1
> > > >> translation of editor view to page view. Whereas, when I am editing
> > > source,
> > > >> I can predict how it will look most of the time. :)
> > > >>
> > > >> I would also move the Cancel button over next to the other buttons.
> > If I
> > > >> had to rate which buttons I use the most frequently, “Cancel” would
> be
> > > at
> > > >> the top, followed by “Save and View,” followed very very distantly
> by
> > > “Save
> > > >> and Continue."
> > > >>
> > > >>
> > > > This is very interesting behavior. I would love to be able to have
> some
> > > > usage stats, but with XWiki being installable and independently
> hosted,
> > > > stats are always hard to get by.
> > > >
> > > > Personally I use "Save" a lot (I like to save often in order to not
> > lose
> > > > stuff), but I usually use the keyboard shortcut, not necessarily the
> > > > button. It is true that 'Preview' in WYSIWYG has its usages,
> especially
> > > > when using macros or nested macros, since the result is not accurate.
> > > >
> > > > Regarding "Save & View" I always do it as a final step, while I never
> > use
> > > > "Cancel" - i just navigate away or hit the browser's 'Back'.
> > > >
> > > > Also in terms of functionality the "Autosave" can be used instead of
> > the
> > > > "Save", so we can remove 'Save' (especially in case of advanced
> users).
> > > >
> > > > So the only stats I have are from the http://playground.xwiki.org <
> > > http://playground.xwiki.org/> from the
> > > > past 2 months. These are the top 3 p

Re: [xwiki-users] [Proposal][UX] Feedback for Visible Save buttons

[Ecaterina Moraru (Valica)]

Sorry. The link was https://goo.gl/forms/QyG5eOM44rBkd3qk2

On Thu, Apr 27, 2017 at 4:23 PM, Ecaterina Moraru (Valica) <
vali...@gmail.com> wrote:

> I've created this form to gather data about the buttons usage, in order to
> make a proposal for the buttons location
> https://docs.google.com/forms/d/e/1FAIpQLSeQwjxlFl321Ap97xKlYRcf
> -39wlG-cJXXqM1nududfjo3KHQ/viewanalytics
>
> Hope everyone is comfortable with Google Forms.
> Thanks,
> Caty
>
>
> On Thu, Apr 27, 2017 at 12:56 PM, Denis GERMAIN 
> wrote:
>
>> Great proposition ! I like it.
>>
>> I see that the subject has also diverted to the fact that you can "save
>> and
>> continue" and "save and view". Some of our users are lost the first time
>> as
>> they click "save and continue" and don't understand why they are still in
>> edit mode. Clarifying this would indeed be a good idea, even though they
>> usually get the distinction quickly after that.
>>
>> Regards,
>> Denis
>>
>> 2017-04-26 17:01 GMT+02:00 Ecaterina Moraru (Valica) :
>>
>> > On Wed, Apr 26, 2017 at 5:41 PM, Craig Wright 
>> wrote:
>> >
>> > > Hi Caty,
>> > >
>> > > I am a fan of “B”.
>> > >
>> > > I like the idea of putting the changelog and autosave options above
>> on a
>> > > preceding row. I would argue that for most users, their eyes only see
>> the
>> > > leftmost buttons as the functionally useful area. Thus putting Cancel
>> on
>> > > the far right effectively “hides” the button.
>> > >
>> >
>> > Yes, the most visible buttons are the ones on the left side and that's
>> the
>> > purpose. We need people to see the Save button :)
>> > Now, 'summary' functionality is not mandatory when editing and can also
>> be
>> > disabled from Administration - Editing.
>> > Having it on a separate line is not an option since we initial idea of
>> the
>> > thread is to provide a fixed bottom bar, when the viewport is small. So
>> > there are all on a single bar in order to be compact.
>> >
>> >
>> > >
>> > > For the purposes of mobile, I think it is acceptable to hide the
>> > changelog
>> > > and autosave options on small-screen resolutions. (Such as when I am
>> > > editing from iPhone, I am highly unlikely to leave a changelog message
>> > > anyway.)
>> > >
>> >
>> > I haven't iterated much on the mobile version, but the mockup I have is
>> > http://design.xwiki.org/xwiki/bin/download/Proposal/
>> > IdeaVisibleSave/mobile.png
>> > It can be improved, and as you said we could decide that on mobile we
>> can
>> > hide some functionality, but again hard to have stats to justify what is
>> > used/needed or not.
>> >
>> > Thanks,
>> > Caty
>> >
>> >
>> > > FWIW, taborder should be the following:
>> > >
>> > > 1. Edit input
>> > > 2. Changelog input
>> > > 3. Save button
>> > > 4. Preview button
>> > > 5. Cancel button
>> > > 6. Autosave option
>> > >
>> > > My $0.02. :)
>> > >
>> > > Thanks,
>> > > Craig
>> > >
>> > > > On Apr 26, 2017, at 2:20 PM, Ecaterina Moraru (Valica) <
>> > > vali...@gmail.com> wrote:
>> > > >
>> > > > Hi,
>> > > >
>> > > > On Wed, Apr 26, 2017 at 2:39 PM, Craig Wright > > > > wrote:
>> > > >
>> > > >> Overall I like these changes. A couple of suggestions:
>> > > >>
>> > > >> No one in my community understands “Save and Continue” versus “Save
>> > and
>> > > >> View”. Dropping the “and Continue” is a great step, but I would go
>> > > farther
>> > > >> and give “Save and View” the emphasis color (blue, in this case).
>> That
>> > > is
>> > > >> the more highly understood behavior. “Save” (and continue editing)
>> is
>> > > >> useful but not as generally useful as “Save and View”. Especially
>> if
>> > you
>> > > >> are dropping Preview.
>> > > >>
>> > > >> FWIW, I use Preview more often from WYSIWYG mode since there is
>> not a
>> > > 1:1
>> > > >> translation of editor view to page view. Whereas, when I am editing
>> > > source,
>> > > >> I can predict how it will look most of the time. :)
>> > > >>
>> > > >> I would also move the Cancel button over next to the other buttons.
>> > If I
>> > > >> had to rate which buttons I use the most frequently, “Cancel”
>> would be
>> > > at
>> > > >> the top, followed by “Save and View,” followed very very distantly
>> by
>> > > “Save
>> > > >> and Continue."
>> > > >>
>> > > >>
>> > > > This is very interesting behavior. I would love to be able to have
>> some
>> > > > usage stats, but with XWiki being installable and independently
>> hosted,
>> > > > stats are always hard to get by.
>> > > >
>> > > > Personally I use "Save" a lot (I like to save often in order to not
>> > lose
>> > > > stuff), but I usually use the keyboard shortcut, not necessarily the
>> > > > button. It is true that 'Preview' in WYSIWYG has its usages,
>> especially
>> > > > when using macros or nested macros, since the result is not
>> accurate.
>> > > >
>> > > > Regarding "Save & View" I always do it as a final step, while I
>> never
>> > use
>> > > > "Cancel" - i just navigate away or hit the browser's 'Back'.
>> > > >
>> > > > Also in 

Re: [xwiki-users] [Proposal][UX] Feedback for Visible Save buttons

[Ecaterina Moraru (Valica)]

Hi,

The initial proposal was about the fixed bottom position. For that we will
have https://jira.xwiki.org/browse/XWIKI-14162 issue
In order to have a bottom bar, we compacted the save options, for that we
will have the https://jira.xwiki.org/browse/XWIKI-14267

Thanks to everyone who responded in the survey. The results are available
at
https://docs.google.com/forms/d/1DM74hlXQQ22WVdqhYbGWyITWXTH5qgmKSMIrS3eHDKE/viewanalytics

The proposal we will implement is
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/proposal9xCK.png

Initially I wanted to remove some buttons and reduce their number, but the
feedback was mixed, so this has been postponed, until we gather more usage
data or feedback.

Some conclusions:
- "Save & View" received 12 votes as used most often. Since it's also an
action that changes modes (takes the user to view) and is a final action,
it will be marked with primary state (blue).
- "Save" was also voted and voters were against remove it. Since it
received 12 votes and is related to save, it will be the next action. We
simplified the name from "Save&Continue" to "Save".
- "Preview" received just 4 votes, but we consider this action to be
directed towards newcomer users that need to be comfortable with their
changes and be able to preview them.
- "Cancel" was kept near the other actions in order to be consistent with
the other layout we have across XWiki. It will be displayed outside of the
button group.

Thanks,
Caty

On Thu, Apr 27, 2017 at 4:29 PM, Ecaterina Moraru (Valica) <
vali...@gmail.com> wrote:

> Sorry. The link was https://goo.gl/forms/QyG5eOM44rBkd3qk2
>
> On Thu, Apr 27, 2017 at 4:23 PM, Ecaterina Moraru (Valica) <
> vali...@gmail.com> wrote:
>
>> I've created this form to gather data about the buttons usage, in order
>> to make a proposal for the buttons location
>> https://docs.google.com/forms/d/e/1FAIpQLSeQwjxlFl321Ap97xKlYRcf-39wlG-
>> cJXXqM1nududfjo3KHQ/viewanalytics
>>
>> Hope everyone is comfortable with Google Forms.
>> Thanks,
>> Caty
>>
>>
>> On Thu, Apr 27, 2017 at 12:56 PM, Denis GERMAIN 
>> wrote:
>>
>>> Great proposition ! I like it.
>>>
>>> I see that the subject has also diverted to the fact that you can "save
>>> and
>>> continue" and "save and view". Some of our users are lost the first time
>>> as
>>> they click "save and continue" and don't understand why they are still in
>>> edit mode. Clarifying this would indeed be a good idea, even though they
>>> usually get the distinction quickly after that.
>>>
>>> Regards,
>>> Denis
>>>
>>> 2017-04-26 17:01 GMT+02:00 Ecaterina Moraru (Valica) >> >:
>>>
>>> > On Wed, Apr 26, 2017 at 5:41 PM, Craig Wright 
>>> wrote:
>>> >
>>> > > Hi Caty,
>>> > >
>>> > > I am a fan of “B”.
>>> > >
>>> > > I like the idea of putting the changelog and autosave options above
>>> on a
>>> > > preceding row. I would argue that for most users, their eyes only
>>> see the
>>> > > leftmost buttons as the functionally useful area. Thus putting
>>> Cancel on
>>> > > the far right effectively “hides” the button.
>>> > >
>>> >
>>> > Yes, the most visible buttons are the ones on the left side and that's
>>> the
>>> > purpose. We need people to see the Save button :)
>>> > Now, 'summary' functionality is not mandatory when editing and can
>>> also be
>>> > disabled from Administration - Editing.
>>> > Having it on a separate line is not an option since we initial idea of
>>> the
>>> > thread is to provide a fixed bottom bar, when the viewport is small. So
>>> > there are all on a single bar in order to be compact.
>>> >
>>> >
>>> > >
>>> > > For the purposes of mobile, I think it is acceptable to hide the
>>> > changelog
>>> > > and autosave options on small-screen resolutions. (Such as when I am
>>> > > editing from iPhone, I am highly unlikely to leave a changelog
>>> message
>>> > > anyway.)
>>> > >
>>> >
>>> > I haven't iterated much on the mobile version, but the mockup I have is
>>> > http://design.xwiki.org/xwiki/bin/download/Proposal/
>>> > IdeaVisibleSave/mobile.png
>>> > It can be improved, and as you said we could decide that on mobile we
>>> can
>>> > hide some functionality, but again hard to have stats to justify what
>>> is
>>> > used/needed or not.
>>> >
>>> > Thanks,
>>> > Caty
>>> >
>>> >
>>> > > FWIW, taborder should be the following:
>>> > >
>>> > > 1. Edit input
>>> > > 2. Changelog input
>>> > > 3. Save button
>>> > > 4. Preview button
>>> > > 5. Cancel button
>>> > > 6. Autosave option
>>> > >
>>> > > My $0.02. :)
>>> > >
>>> > > Thanks,
>>> > > Craig
>>> > >
>>> > > > On Apr 26, 2017, at 2:20 PM, Ecaterina Moraru (Valica) <
>>> > > vali...@gmail.com> wrote:
>>> > > >
>>> > > > Hi,
>>> > > >
>>> > > > On Wed, Apr 26, 2017 at 2:39 PM, Craig Wright >> > > > wrote:
>>> > > >
>>> > > >> Overall I like these changes. A couple of suggestions:
>>> > > >>
>>> > > >> No one in my community understands “Save and Continue” versus
>>> “Save
>>> > and
>>> > > >> View”. Dropping the “and 

Re: [xwiki-users] [Proposal][UX] Feedback for Visible Save buttons

[Ecaterina Moraru (Valica)]

On Tue, May 9, 2017 at 11:20 PM, Olivier Seres  wrote:

> Caty,
> Thanks for this work!
> We should also consider that there could be other options to be added in
> the future, like "Allow realtime" radio button, or introduced by some
> forecoming extensions
>

Ideal we could also remove options :) and make it more simpler :)
On mobile the options will go on 2 rows, so we currently have this problems.

Thanks,
Caty


> In order to avoid messing up the layout (in beeing be obliged to placing
> the option in some weird places - like underneath because there is no other
> options),  it might be wise to think to an elegant design solution within
> this bottom bar to take their growth into account.
> Currently thinking to an unfolding menu, but I'm sure there are many other
> ways.
>
>
>
> Olivier
>
>
> On Tue, May 9, 2017 at 6:13 PM, Ecaterina Moraru (Valica) <
> vali...@gmail.com> wrote:
>
>> Hi,
>>
>> The initial proposal was about the fixed bottom position. For that we will
>> have https://jira.xwiki.org/browse/XWIKI-14162 issue
>> In order to have a bottom bar, we compacted the save options, for that we
>> will have the https://jira.xwiki.org/browse/XWIKI-14267
>>
>> Thanks to everyone who responded in the survey. The results are available
>> at
>> https://docs.google.com/forms/d/1DM74hlXQQ22WVdqhYbGWyITWXTH
>> 5qgmKSMIrS3eHDKE/viewanalytics
>>
>> The proposal we will implement is
>> http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisi
>> bleSave/proposal9xCK.png
>>
>> Initially I wanted to remove some buttons and reduce their number, but the
>> feedback was mixed, so this has been postponed, until we gather more usage
>> data or feedback.
>>
>> Some conclusions:
>> - "Save & View" received 12 votes as used most often. Since it's also an
>> action that changes modes (takes the user to view) and is a final action,
>> it will be marked with primary state (blue).
>> - "Save" was also voted and voters were against remove it. Since it
>> received 12 votes and is related to save, it will be the next action. We
>> simplified the name from "Save&Continue" to "Save".
>> - "Preview" received just 4 votes, but we consider this action to be
>> directed towards newcomer users that need to be comfortable with their
>> changes and be able to preview them.
>> - "Cancel" was kept near the other actions in order to be consistent with
>> the other layout we have across XWiki. It will be displayed outside of the
>> button group.
>>
>> Thanks,
>> Caty
>>
>> On Thu, Apr 27, 2017 at 4:29 PM, Ecaterina Moraru (Valica) <
>> vali...@gmail.com> wrote:
>>
>> > Sorry. The link was https://goo.gl/forms/QyG5eOM44rBkd3qk2
>> >
>> > On Thu, Apr 27, 2017 at 4:23 PM, Ecaterina Moraru (Valica) <
>> > vali...@gmail.com> wrote:
>> >
>> >> I've created this form to gather data about the buttons usage, in order
>> >> to make a proposal for the buttons location
>> >> https://docs.google.com/forms/d/e/1FAIpQLSeQwjxlFl321Ap97xKlYRcf
>> -39wlG-
>> >> cJXXqM1nududfjo3KHQ/viewanalytics
>> >>
>> >> Hope everyone is comfortable with Google Forms.
>> >> Thanks,
>> >> Caty
>> >>
>> >>
>> >> On Thu, Apr 27, 2017 at 12:56 PM, Denis GERMAIN 
>> >> wrote:
>> >>
>> >>> Great proposition ! I like it.
>> >>>
>> >>> I see that the subject has also diverted to the fact that you can
>> "save
>> >>> and
>> >>> continue" and "save and view". Some of our users are lost the first
>> time
>> >>> as
>> >>> they click "save and continue" and don't understand why they are
>> still in
>> >>> edit mode. Clarifying this would indeed be a good idea, even though
>> they
>> >>> usually get the distinction quickly after that.
>> >>>
>> >>> Regards,
>> >>> Denis
>> >>>
>> >>> 2017-04-26 17:01 GMT+02:00 Ecaterina Moraru (Valica) <
>> vali...@gmail.com
>> >>> >:
>> >>>
>> >>> > On Wed, Apr 26, 2017 at 5:41 PM, Craig Wright 
>> >>> wrote:
>> >>> >
>> >>> > > Hi Caty,
>> >>> > >
>> >>> > > I am a fan of “B”.
>> >>> > >
>> >>> > > I like the idea of putting the changelog and autosave options
>> above
>> >>> on a
>> >>> > > preceding row. I would argue that for most users, their eyes only
>> >>> see the
>> >>> > > leftmost buttons as the functionally useful area. Thus putting
>> >>> Cancel on
>> >>> > > the far right effectively “hides” the button.
>> >>> > >
>> >>> >
>> >>> > Yes, the most visible buttons are the ones on the left side and
>> that's
>> >>> the
>> >>> > purpose. We need people to see the Save button :)
>> >>> > Now, 'summary' functionality is not mandatory when editing and can
>> >>> also be
>> >>> > disabled from Administration - Editing.
>> >>> > Having it on a separate line is not an option since we initial idea
>> of
>> >>> the
>> >>> > thread is to provide a fixed bottom bar, when the viewport is
>> small. So
>> >>> > there are all on a single bar in order to be compact.
>> >>> >
>> >>> >
>> >>> > >
>> >>> > > For the purposes of mobile, I think it is acceptable to hide the
>> >>> > changelog
>> >>> > > and autosave options on small-screen resolutions. (Such