Quantcast

[Proposal][UX] Visible Save buttons

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Proposal][UX] Visible Save buttons

Ecaterina Moraru (Valica)
Hi devs,

Some users have complained that when editing they don't know that they need
to scroll in order to see the Save buttons.

This is a proposal that tackles:
- Displaying the save buttons in a bottom area, when they are out of the
viewport, see
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/bottomBar.png
- Reorganizing the bottom zone in order to compact all the save functions
into a single bar
- When the user scrolls, the buttons go into their position, see
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/after.png

For the whole proposal and more screenshots, see
http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaVisibleSave

WDYT?

Thanks,
Caty
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal][UX] Visible Save buttons

Denis Gervalle-2
Hi Caty,
Very happy to see progress in this area, this is a real pain to scroll to the bottom of the document to save it, and there is a long time it is affecting us.
However, I am not really happy with your current proposal. I found the text area for the version summary way too small for the purpose. It should IMO stay on a separate line in order to be large enough. Since this not always useful, it might, however, be collapsed somehow in certain circumstances.
I also wonder if just having some buttons on the top in addition to the bottom, wouldn’t be simpler and as efficient, even if the top feature is limited (just save / save&view). It might also work with your fixed bottom UI, that might also be more limited than what you can do by scrolling.
I hope these are useful comments. I am also curious to see other opinions on this important feature.
--
Denis Gervalle
SOFTEC sa - CEO
On Tue, Apr 11, 2017 at 17:59, Ecaterina Moraru (Valica) <[hidden email]> wrote:
Hi devs,

Some users have complained that when editing they don't know that they need
to scroll in order to see the Save buttons.

This is a proposal that tackles:
- Displaying the save buttons in a bottom area, when they are out of the
viewport, see
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/bottomBar.png
- Reorganizing the bottom zone in order to compact all the save functions
into a single bar
- When the user scrolls, the buttons go into their position, see
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/after.png

For the whole proposal and more screenshots, see
http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaVisibleSave

WDYT?

Thanks,
Caty
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal][UX] Visible Save buttons

vmassol
Administrator
Hi,

> On 11 Apr 2017, at 21:25, Denis Gervalle <[hidden email]> wrote:
>
> Hi Caty,
> Very happy to see progress in this area, this is a real pain to scroll to the bottom of the document to save it, and there is a long time it is affecting us.
> However, I am not really happy with your current proposal. I found the text area for the version summary way too small for the purpose. It should IMO stay on a separate line in order to be large enough. Since this not always useful, it might, however, be collapsed somehow in certain circumstances.
> I also wonder if just having some buttons on the top in addition to the bottom, wouldn’t be simpler and as efficient, even if the top feature is limited (just save / save&view). It might also work with your fixed bottom UI, that might also be more limited than what you can do by scrolling.
> I hope these are useful comments. I am also curious to see other opinions on this important feature.

For me, the issue with the always-on-bar is that it takes up space and thus reduces the available vertical space for editing content. Thus I find it interesting to have it on only one line and also to only have it at the bottom and not repeat it at the top. I’d really not like to see it at the top.

Thanks
-Vincent

> --
> Denis Gervalle
> SOFTEC sa - CEO
> On Tue, Apr 11, 2017 at 17:59, Ecaterina Moraru (Valica) <[hidden email]> wrote:
> Hi devs,
>
> Some users have complained that when editing they don't know that they need
> to scroll in order to see the Save buttons.
>
> This is a proposal that tackles:
> - Displaying the save buttons in a bottom area, when they are out of the
> viewport, see
> http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/bottomBar.png
> - Reorganizing the bottom zone in order to compact all the save functions
> into a single bar
> - When the user scrolls, the buttons go into their position, see
> http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/after.png
>
> For the whole proposal and more screenshots, see
> http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaVisibleSave
>
> WDYT?
>
> Thanks,
> Caty

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal][UX] Visible Save buttons

Guillaume Delhumeau
+1 for the solution 3:
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/smallViewPort.png

2017-04-11 21:58 GMT+02:00 Vincent Massol <[hidden email]>:

> Hi,
>
> > On 11 Apr 2017, at 21:25, Denis Gervalle <[hidden email]> wrote:
> >
> > Hi Caty,
> > Very happy to see progress in this area, this is a real pain to scroll
> to the bottom of the document to save it, and there is a long time it is
> affecting us.
> > However, I am not really happy with your current proposal. I found the
> text area for the version summary way too small for the purpose. It should
> IMO stay on a separate line in order to be large enough. Since this not
> always useful, it might, however, be collapsed somehow in certain
> circumstances.
> > I also wonder if just having some buttons on the top in addition to the
> bottom, wouldn’t be simpler and as efficient, even if the top feature is
> limited (just save / save&view). It might also work with your fixed bottom
> UI, that might also be more limited than what you can do by scrolling.
> > I hope these are useful comments. I am also curious to see other
> opinions on this important feature.
>
> For me, the issue with the always-on-bar is that it takes up space and
> thus reduces the available vertical space for editing content. Thus I find
> it interesting to have it on only one line and also to only have it at the
> bottom and not repeat it at the top. I’d really not like to see it at the
> top.
>
> Thanks
> -Vincent
>
> > --
> > Denis Gervalle
> > SOFTEC sa - CEO
> > On Tue, Apr 11, 2017 at 17:59, Ecaterina Moraru (Valica) <
> [hidden email]> wrote:
> > Hi devs,
> >
> > Some users have complained that when editing they don't know that they
> need
> > to scroll in order to see the Save buttons.
> >
> > This is a proposal that tackles:
> > - Displaying the save buttons in a bottom area, when they are out of the
> > viewport, see
> > http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaVisibleSave/bottomBar.png
> > - Reorganizing the bottom zone in order to compact all the save functions
> > into a single bar
> > - When the user scrolls, the buttons go into their position, see
> > http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaVisibleSave/after.png
> >
> > For the whole proposal and more screenshots, see
> > http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaVisibleSave
> >
> > WDYT?
> >
> > Thanks,
> > Caty
>
>


--
Guillaume Delhumeau ([hidden email])
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal][UX] Visible Save buttons

Ecaterina Moraru (Valica)
On Wed, Apr 12, 2017 at 11:53 AM, Guillaume Delhumeau <
[hidden email]> wrote:

> +1 for the solution 3:
> http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaVisibleSave/smallViewPort.png


Hi Guillaume,

They are not separate proposals, just one, but it looks a bit different
when it's fixed at bottom, versus in its position. Just wanted to make that
clear.


>
>
> 2017-04-11 21:58 GMT+02:00 Vincent Massol <[hidden email]>:
>
> > Hi,
> >
> > > On 11 Apr 2017, at 21:25, Denis Gervalle <[hidden email]> wrote:
> > >
> > > Hi Caty,
> > > Very happy to see progress in this area, this is a real pain to scroll
> > to the bottom of the document to save it, and there is a long time it is
> > affecting us.
> > > However, I am not really happy with your current proposal. I found the
> > text area for the version summary way too small for the purpose.
>

Beginner users sometimes don't know what that is for. Somebody asked me to
remove it all together :) you think it's too small :P


> It should
> > IMO stay on a separate line in order to be large enough. Since this not
> > always useful, it might, however, be collapsed somehow in certain
> > circumstances.
>

Currently it is on a separate line. I tried to integrate everything in a
single line, that will be always visible, although I agree we have many
functionalities (autosave, summary, minor, preview, etc.) and they look a
bit crowded.


> > > I also wonder if just having some buttons on the top in addition to the
> > bottom, wouldn’t be simpler and as efficient, even if the top feature is
> > limited (just save / save&view).
>

Usually save is a the bottom. Still the same view will be also in Full
Screen and the top area is already taken by the CkEditor controls, see
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/fullScreen.png

Thanks,
Caty


> It might also work with your fixed bottom
> > UI, that might also be more limited than what you can do by scrolling.
> > > I hope these are useful comments. I am also curious to see other
> > opinions on this important feature.
> >
> > For me, the issue with the always-on-bar is that it takes up space and
> > thus reduces the available vertical space for editing content. Thus I
> find
> > it interesting to have it on only one line and also to only have it at
> the
> > bottom and not repeat it at the top. I’d really not like to see it at the
> > top.
> >
> > Thanks
> > -Vincent
> >
> > > --
> > > Denis Gervalle
> > > SOFTEC sa - CEO
> > > On Tue, Apr 11, 2017 at 17:59, Ecaterina Moraru (Valica) <
> > [hidden email]> wrote:
> > > Hi devs,
> > >
> > > Some users have complained that when editing they don't know that they
> > need
> > > to scroll in order to see the Save buttons.
> > >
> > > This is a proposal that tackles:
> > > - Displaying the save buttons in a bottom area, when they are out of
> the
> > > viewport, see
> > > http://design.xwiki.org/xwiki/bin/download/Proposal/
> > IdeaVisibleSave/bottomBar.png
> > > - Reorganizing the bottom zone in order to compact all the save
> functions
> > > into a single bar
> > > - When the user scrolls, the buttons go into their position, see
> > > http://design.xwiki.org/xwiki/bin/download/Proposal/
> > IdeaVisibleSave/after.png
> > >
> > > For the whole proposal and more screenshots, see
> > > http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaVisibleSave
> > >
> > > WDYT?
> > >
> > > Thanks,
> > > Caty
> >
> >
>
>
> --
> Guillaume Delhumeau ([hidden email])
> Research & Development Engineer at XWiki SAS
> Committer on the XWiki.org project
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal][UX] Visible Save buttons

Eduard Moraru
Generally, I like the proposal. A sticky save button is clearly the
solution.

However, the mobile view is a mess:
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/mobile.png

Side note: I think it`s a good time to address the "Save & Continue" +
"Save & View" duality that I found deeply confusing when I first started
with XWiki. If we take it down to only 2 buttons (Save + Cancel), it will
improve the mobile view as well.

My last note about the proposal is related to the sticky state visible in
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/bottomBar.png
... I`m not sure on the technical aspects, but I would still prefer it to
"stick" only to the content area and not overflow to the entire width of
the screen and go into panels or whatever the skin might have around the
content area (in edit mode).

Thanks,
Eduard

On Wed, Apr 12, 2017 at 2:15 PM, Ecaterina Moraru (Valica) <
[hidden email]> wrote:

> On Wed, Apr 12, 2017 at 11:53 AM, Guillaume Delhumeau <
> [hidden email]> wrote:
>
> > +1 for the solution 3:
> > http://design.xwiki.org/xwiki/bin/download/Proposal/
> > IdeaVisibleSave/smallViewPort.png
>
>
> Hi Guillaume,
>
> They are not separate proposals, just one, but it looks a bit different
> when it's fixed at bottom, versus in its position. Just wanted to make that
> clear.
>
>
> >
> >
> > 2017-04-11 21:58 GMT+02:00 Vincent Massol <[hidden email]>:
> >
> > > Hi,
> > >
> > > > On 11 Apr 2017, at 21:25, Denis Gervalle <[hidden email]> wrote:
> > > >
> > > > Hi Caty,
> > > > Very happy to see progress in this area, this is a real pain to
> scroll
> > > to the bottom of the document to save it, and there is a long time it
> is
> > > affecting us.
> > > > However, I am not really happy with your current proposal. I found
> the
> > > text area for the version summary way too small for the purpose.
> >
>
> Beginner users sometimes don't know what that is for. Somebody asked me to
> remove it all together :) you think it's too small :P
>
>
> > It should
> > > IMO stay on a separate line in order to be large enough. Since this not
> > > always useful, it might, however, be collapsed somehow in certain
> > > circumstances.
> >
>
> Currently it is on a separate line. I tried to integrate everything in a
> single line, that will be always visible, although I agree we have many
> functionalities (autosave, summary, minor, preview, etc.) and they look a
> bit crowded.
>
>
> > > > I also wonder if just having some buttons on the top in addition to
> the
> > > bottom, wouldn’t be simpler and as efficient, even if the top feature
> is
> > > limited (just save / save&view).
> >
>
> Usually save is a the bottom. Still the same view will be also in Full
> Screen and the top area is already taken by the CkEditor controls, see
> http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaVisibleSave/fullScreen.png
>
> Thanks,
> Caty
>
>
> > It might also work with your fixed bottom
> > > UI, that might also be more limited than what you can do by scrolling.
> > > > I hope these are useful comments. I am also curious to see other
> > > opinions on this important feature.
> > >
> > > For me, the issue with the always-on-bar is that it takes up space and
> > > thus reduces the available vertical space for editing content. Thus I
> > find
> > > it interesting to have it on only one line and also to only have it at
> > the
> > > bottom and not repeat it at the top. I’d really not like to see it at
> the
> > > top.
> > >
> > > Thanks
> > > -Vincent
> > >
> > > > --
> > > > Denis Gervalle
> > > > SOFTEC sa - CEO
> > > > On Tue, Apr 11, 2017 at 17:59, Ecaterina Moraru (Valica) <
> > > [hidden email]> wrote:
> > > > Hi devs,
> > > >
> > > > Some users have complained that when editing they don't know that
> they
> > > need
> > > > to scroll in order to see the Save buttons.
> > > >
> > > > This is a proposal that tackles:
> > > > - Displaying the save buttons in a bottom area, when they are out of
> > the
> > > > viewport, see
> > > > http://design.xwiki.org/xwiki/bin/download/Proposal/
> > > IdeaVisibleSave/bottomBar.png
> > > > - Reorganizing the bottom zone in order to compact all the save
> > functions
> > > > into a single bar
> > > > - When the user scrolls, the buttons go into their position, see
> > > > http://design.xwiki.org/xwiki/bin/download/Proposal/
> > > IdeaVisibleSave/after.png
> > > >
> > > > For the whole proposal and more screenshots, see
> > > > http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaVisibleSave
> > > >
> > > > WDYT?
> > > >
> > > > Thanks,
> > > > Caty
> > >
> > >
> >
> >
> > --
> > Guillaume Delhumeau ([hidden email])
> > Research & Development Engineer at XWiki SAS
> > Committer on the XWiki.org project
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal][UX] Visible Save buttons

Ecaterina Moraru (Valica)
Another proposal by Olivier
http://design.xwiki.org/xwiki/bin/view/Proposal/Idea%3A%20Contextual%20Actions%20Toolbar

On Mon, Apr 24, 2017 at 3:41 PM, Eduard Moraru <[hidden email]> wrote:

> Generally, I like the proposal. A sticky save button is clearly the
> solution.
>
> However, the mobile view is a mess:
> http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaVisibleSave/mobile.png
>
> Side note: I think it`s a good time to address the "Save & Continue" +
> "Save & View" duality that I found deeply confusing when I first started
> with XWiki. If we take it down to only 2 buttons (Save + Cancel), it will
> improve the mobile view as well.
>
> My last note about the proposal is related to the sticky state visible in
> http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaVisibleSave/bottomBar.png
> ... I`m not sure on the technical aspects, but I would still prefer it to
> "stick" only to the content area and not overflow to the entire width of
> the screen and go into panels or whatever the skin might have around the
> content area (in edit mode).
>
> Thanks,
> Eduard
>
> On Wed, Apr 12, 2017 at 2:15 PM, Ecaterina Moraru (Valica) <
> [hidden email]> wrote:
>
> > On Wed, Apr 12, 2017 at 11:53 AM, Guillaume Delhumeau <
> > [hidden email]> wrote:
> >
> > > +1 for the solution 3:
> > > http://design.xwiki.org/xwiki/bin/download/Proposal/
> > > IdeaVisibleSave/smallViewPort.png
> >
> >
> > Hi Guillaume,
> >
> > They are not separate proposals, just one, but it looks a bit different
> > when it's fixed at bottom, versus in its position. Just wanted to make
> that
> > clear.
> >
> >
> > >
> > >
> > > 2017-04-11 21:58 GMT+02:00 Vincent Massol <[hidden email]>:
> > >
> > > > Hi,
> > > >
> > > > > On 11 Apr 2017, at 21:25, Denis Gervalle <[hidden email]> wrote:
> > > > >
> > > > > Hi Caty,
> > > > > Very happy to see progress in this area, this is a real pain to
> > scroll
> > > > to the bottom of the document to save it, and there is a long time it
> > is
> > > > affecting us.
> > > > > However, I am not really happy with your current proposal. I found
> > the
> > > > text area for the version summary way too small for the purpose.
> > >
> >
> > Beginner users sometimes don't know what that is for. Somebody asked me
> to
> > remove it all together :) you think it's too small :P
> >
> >
> > > It should
> > > > IMO stay on a separate line in order to be large enough. Since this
> not
> > > > always useful, it might, however, be collapsed somehow in certain
> > > > circumstances.
> > >
> >
> > Currently it is on a separate line. I tried to integrate everything in a
> > single line, that will be always visible, although I agree we have many
> > functionalities (autosave, summary, minor, preview, etc.) and they look a
> > bit crowded.
> >
> >
> > > > > I also wonder if just having some buttons on the top in addition to
> > the
> > > > bottom, wouldn’t be simpler and as efficient, even if the top feature
> > is
> > > > limited (just save / save&view).
> > >
> >
> > Usually save is a the bottom. Still the same view will be also in Full
> > Screen and the top area is already taken by the CkEditor controls, see
> > http://design.xwiki.org/xwiki/bin/download/Proposal/
> > IdeaVisibleSave/fullScreen.png
> >
> > Thanks,
> > Caty
> >
> >
> > > It might also work with your fixed bottom
> > > > UI, that might also be more limited than what you can do by
> scrolling.
> > > > > I hope these are useful comments. I am also curious to see other
> > > > opinions on this important feature.
> > > >
> > > > For me, the issue with the always-on-bar is that it takes up space
> and
> > > > thus reduces the available vertical space for editing content. Thus I
> > > find
> > > > it interesting to have it on only one line and also to only have it
> at
> > > the
> > > > bottom and not repeat it at the top. I’d really not like to see it at
> > the
> > > > top.
> > > >
> > > > Thanks
> > > > -Vincent
> > > >
> > > > > --
> > > > > Denis Gervalle
> > > > > SOFTEC sa - CEO
> > > > > On Tue, Apr 11, 2017 at 17:59, Ecaterina Moraru (Valica) <
> > > > [hidden email]> wrote:
> > > > > Hi devs,
> > > > >
> > > > > Some users have complained that when editing they don't know that
> > they
> > > > need
> > > > > to scroll in order to see the Save buttons.
> > > > >
> > > > > This is a proposal that tackles:
> > > > > - Displaying the save buttons in a bottom area, when they are out
> of
> > > the
> > > > > viewport, see
> > > > > http://design.xwiki.org/xwiki/bin/download/Proposal/
> > > > IdeaVisibleSave/bottomBar.png
> > > > > - Reorganizing the bottom zone in order to compact all the save
> > > functions
> > > > > into a single bar
> > > > > - When the user scrolls, the buttons go into their position, see
> > > > > http://design.xwiki.org/xwiki/bin/download/Proposal/
> > > > IdeaVisibleSave/after.png
> > > > >
> > > > > For the whole proposal and more screenshots, see
> > > > > http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaVisibleSave
> > > > >
> > > > > WDYT?
> > > > >
> > > > > Thanks,
> > > > > Caty
> > > >
> > > >
> > >
> > >
> > > --
> > > Guillaume Delhumeau ([hidden email])
> > > Research & Development Engineer at XWiki SAS
> > > Committer on the XWiki.org project
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal][UX] Visible Save buttons

oseres
This post has NOT been accepted by the mailing list yet.
Thanks Caty,
the idea here is to have the actions button in the same location area so that users
1/ users don't have to scroll to find the save button
2/ access a contextual menu displaying the most common actions they need in a each context (view, edit,etc.. )
The inspiration of contextual menus simply comes from GMail
I know that there is some work left in terms of design to display all the possibilities
Thanks for your feedbacks on this approach.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal][UX] Visible Save buttons

Eduard Moraru
In reply to this post by Ecaterina Moraru (Valica)
On Mon, Apr 24, 2017 at 5:07 PM, Ecaterina Moraru (Valica) <
[hidden email]> wrote:

> Another proposal by Olivier
> <a href="http://design.xwiki.org/xwiki/bin/view/Proposal/Idea%3A%">http://design.xwiki.org/xwiki/bin/view/Proposal/Idea%3A%
> 20Contextual%20Actions%20Toolbar


There are a lot of problems with this proposal, but I just wanted to
address the main proposal that the Save button should be on the same place
as the edit/actions/etc., since I`ve noticed it in the original design
page, marked as a "need".

It breaks the behavior of the content menu buttons because no current
button has a direct effect (i.e. action) on the Wiki, all buttons leading
to a different screen where the action should be configured and executed.

It breaks the left->right; top->bottom workflow, as an editor would have to
start from the title, go to the content and then *come back to the top* in
order to save, instead of continuing to the bottom where we currently have
the save action.

As mentioned, there are other problems like losing the ability to switch
editors and accessing all other page functions which is actually breaking
consistency instead of preserving it, etc.

Simply put, the premise that "Edit and save button belong to the same
category" is not really valid, since, as mentioned, Edit goes into the edit
mode (does not actually do anything yet), while Save is an action that
changes the state of the wiki/page when clicked (a bit like close window,
cancel, OK, etc., which are not in a menu, but at the margin of a
window/UI).

Thanks,
Eduard

>
>
> On Mon, Apr 24, 2017 at 3:41 PM, Eduard Moraru <[hidden email]>
> wrote:
>
> > Generally, I like the proposal. A sticky save button is clearly the
> > solution.
> >
> > However, the mobile view is a mess:
> > http://design.xwiki.org/xwiki/bin/download/Proposal/
> > IdeaVisibleSave/mobile.png
> >
> > Side note: I think it`s a good time to address the "Save & Continue" +
> > "Save & View" duality that I found deeply confusing when I first started
> > with XWiki. If we take it down to only 2 buttons (Save + Cancel), it will
> > improve the mobile view as well.
> >
> > My last note about the proposal is related to the sticky state visible in
> > http://design.xwiki.org/xwiki/bin/download/Proposal/
> > IdeaVisibleSave/bottomBar.png
> > ... I`m not sure on the technical aspects, but I would still prefer it to
> > "stick" only to the content area and not overflow to the entire width of
> > the screen and go into panels or whatever the skin might have around the
> > content area (in edit mode).
> >
> > Thanks,
> > Eduard
> >
> > On Wed, Apr 12, 2017 at 2:15 PM, Ecaterina Moraru (Valica) <
> > [hidden email]> wrote:
> >
> > > On Wed, Apr 12, 2017 at 11:53 AM, Guillaume Delhumeau <
> > > [hidden email]> wrote:
> > >
> > > > +1 for the solution 3:
> > > > http://design.xwiki.org/xwiki/bin/download/Proposal/
> > > > IdeaVisibleSave/smallViewPort.png
> > >
> > >
> > > Hi Guillaume,
> > >
> > > They are not separate proposals, just one, but it looks a bit different
> > > when it's fixed at bottom, versus in its position. Just wanted to make
> > that
> > > clear.
> > >
> > >
> > > >
> > > >
> > > > 2017-04-11 21:58 GMT+02:00 Vincent Massol <[hidden email]>:
> > > >
> > > > > Hi,
> > > > >
> > > > > > On 11 Apr 2017, at 21:25, Denis Gervalle <[hidden email]> wrote:
> > > > > >
> > > > > > Hi Caty,
> > > > > > Very happy to see progress in this area, this is a real pain to
> > > scroll
> > > > > to the bottom of the document to save it, and there is a long time
> it
> > > is
> > > > > affecting us.
> > > > > > However, I am not really happy with your current proposal. I
> found
> > > the
> > > > > text area for the version summary way too small for the purpose.
> > > >
> > >
> > > Beginner users sometimes don't know what that is for. Somebody asked me
> > to
> > > remove it all together :) you think it's too small :P
> > >
> > >
> > > > It should
> > > > > IMO stay on a separate line in order to be large enough. Since this
> > not
> > > > > always useful, it might, however, be collapsed somehow in certain
> > > > > circumstances.
> > > >
> > >
> > > Currently it is on a separate line. I tried to integrate everything in
> a
> > > single line, that will be always visible, although I agree we have many
> > > functionalities (autosave, summary, minor, preview, etc.) and they
> look a
> > > bit crowded.
> > >
> > >
> > > > > > I also wonder if just having some buttons on the top in addition
> to
> > > the
> > > > > bottom, wouldn’t be simpler and as efficient, even if the top
> feature
> > > is
> > > > > limited (just save / save&view).
> > > >
> > >
> > > Usually save is a the bottom. Still the same view will be also in Full
> > > Screen and the top area is already taken by the CkEditor controls, see
> > > http://design.xwiki.org/xwiki/bin/download/Proposal/
> > > IdeaVisibleSave/fullScreen.png
> > >
> > > Thanks,
> > > Caty
> > >
> > >
> > > > It might also work with your fixed bottom
> > > > > UI, that might also be more limited than what you can do by
> > scrolling.
> > > > > > I hope these are useful comments. I am also curious to see other
> > > > > opinions on this important feature.
> > > > >
> > > > > For me, the issue with the always-on-bar is that it takes up space
> > and
> > > > > thus reduces the available vertical space for editing content.
> Thus I
> > > > find
> > > > > it interesting to have it on only one line and also to only have it
> > at
> > > > the
> > > > > bottom and not repeat it at the top. I’d really not like to see it
> at
> > > the
> > > > > top.
> > > > >
> > > > > Thanks
> > > > > -Vincent
> > > > >
> > > > > > --
> > > > > > Denis Gervalle
> > > > > > SOFTEC sa - CEO
> > > > > > On Tue, Apr 11, 2017 at 17:59, Ecaterina Moraru (Valica) <
> > > > > [hidden email]> wrote:
> > > > > > Hi devs,
> > > > > >
> > > > > > Some users have complained that when editing they don't know that
> > > they
> > > > > need
> > > > > > to scroll in order to see the Save buttons.
> > > > > >
> > > > > > This is a proposal that tackles:
> > > > > > - Displaying the save buttons in a bottom area, when they are out
> > of
> > > > the
> > > > > > viewport, see
> > > > > > http://design.xwiki.org/xwiki/bin/download/Proposal/
> > > > > IdeaVisibleSave/bottomBar.png
> > > > > > - Reorganizing the bottom zone in order to compact all the save
> > > > functions
> > > > > > into a single bar
> > > > > > - When the user scrolls, the buttons go into their position, see
> > > > > > http://design.xwiki.org/xwiki/bin/download/Proposal/
> > > > > IdeaVisibleSave/after.png
> > > > > >
> > > > > > For the whole proposal and more screenshots, see
> > > > > > http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaVisibleSave
> > > > > >
> > > > > > WDYT?
> > > > > >
> > > > > > Thanks,
> > > > > > Caty
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Guillaume Delhumeau ([hidden email])
> > > > Research & Development Engineer at XWiki SAS
> > > > Committer on the XWiki.org project
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal][UX] Visible Save buttons

vmassol
Administrator
In reply to this post by Denis Gervalle-2
Hi Denis/All,

> On 11 Apr 2017, at 21:25, Denis Gervalle <[hidden email]> wrote:
>
> Hi Caty,
> Very happy to see progress in this area, this is a real pain to scroll to the bottom of the document to save it, and there is a long time it is affecting us.

Note that shouldn’t be a problem in most cases and you shouldn’t have to scroll anywhere since the content is inside a textarea with scrollbars and the preview/save/cancel buttons are outside of it and only reasonable resolution they are always visible.

Just tested on a small 1024x76 resolution and they’re very visible and there’s still vertical room:
https://www.evernote.com/l/AHfKSY4sB3lO_6TarSsjkw889qlffOGX4P8

And in full screen it’s the same.

So I’m curious to understand when it’s a problem for you. There’s probably something I’m missing.

Thanks
-Vincent

> However, I am not really happy with your current proposal. I found the text area for the version summary way too small for the purpose. It should IMO stay on a separate line in order to be large enough. Since this not always useful, it might, however, be collapsed somehow in certain circumstances.
> I also wonder if just having some buttons on the top in addition to the bottom, wouldn’t be simpler and as efficient, even if the top feature is limited (just save / save&view). It might also work with your fixed bottom UI, that might also be more limited than what you can do by scrolling.
> I hope these are useful comments. I am also curious to see other opinions on this important feature.
> --
> Denis Gervalle
> SOFTEC sa - CEO
> On Tue, Apr 11, 2017 at 17:59, Ecaterina Moraru (Valica) <[hidden email]> wrote:
> Hi devs,
>
> Some users have complained that when editing they don't know that they need
> to scroll in order to see the Save buttons.
>
> This is a proposal that tackles:
> - Displaying the save buttons in a bottom area, when they are out of the
> viewport, see
> http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/bottomBar.png
> - Reorganizing the bottom zone in order to compact all the save functions
> into a single bar
> - When the user scrolls, the buttons go into their position, see
> http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/after.png
>
> For the whole proposal and more screenshots, see
> http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaVisibleSave
>
> WDYT?
>
> Thanks,
> Caty

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal][UX] Visible Save buttons

vmassol
Administrator
In reply to this post by Ecaterina Moraru (Valica)
Hi,

> On 24 Apr 2017, at 16:07, Ecaterina Moraru (Valica) <[hidden email]> wrote:
>
> Another proposal by Olivier
> http://design.xwiki.org/xwiki/bin/view/Proposal/Idea%3A%20Contextual%20Actions%20Toolbar

It would be nice if Olivier could also comment about the other proposals.

I don’t like this new proposal too much for several reasons:
* In general I don’t think it’s a good idea to replace existing button by other ones. This is a bit a WTF effect IMO and I’m pretty sure some people will not notice the swap in.
* It also prevents easy navigation away from the edit mode and this was very important. For example you edit in wysiwyg or wiki and then you want to switch to the object mode or edit permissions, etc
* It completely hides several features such as the save comment text + the minor edit one and those are typical fields that are well-known and expected in the wiki world. If you remove them then you can be sure nobody is going to use them ever. Also note that we have some config properties that forces a save comment and the validation would be really weird if this field was not visible.

So far I prefer the other proposals.

Thanks
-Vincent

> On Mon, Apr 24, 2017 at 3:41 PM, Eduard Moraru <[hidden email]> wrote:
>
>> Generally, I like the proposal. A sticky save button is clearly the
>> solution.
>>
>> However, the mobile view is a mess:
>> http://design.xwiki.org/xwiki/bin/download/Proposal/
>> IdeaVisibleSave/mobile.png
>>
>> Side note: I think it`s a good time to address the "Save & Continue" +
>> "Save & View" duality that I found deeply confusing when I first started
>> with XWiki. If we take it down to only 2 buttons (Save + Cancel), it will
>> improve the mobile view as well.
>>
>> My last note about the proposal is related to the sticky state visible in
>> http://design.xwiki.org/xwiki/bin/download/Proposal/
>> IdeaVisibleSave/bottomBar.png
>> ... I`m not sure on the technical aspects, but I would still prefer it to
>> "stick" only to the content area and not overflow to the entire width of
>> the screen and go into panels or whatever the skin might have around the
>> content area (in edit mode).
>>
>> Thanks,
>> Eduard
>>
>> On Wed, Apr 12, 2017 at 2:15 PM, Ecaterina Moraru (Valica) <
>> [hidden email]> wrote:
>>
>>> On Wed, Apr 12, 2017 at 11:53 AM, Guillaume Delhumeau <
>>> [hidden email]> wrote:
>>>
>>>> +1 for the solution 3:
>>>> http://design.xwiki.org/xwiki/bin/download/Proposal/
>>>> IdeaVisibleSave/smallViewPort.png
>>>
>>>
>>> Hi Guillaume,
>>>
>>> They are not separate proposals, just one, but it looks a bit different
>>> when it's fixed at bottom, versus in its position. Just wanted to make
>> that
>>> clear.
>>>
>>>
>>>>
>>>>
>>>> 2017-04-11 21:58 GMT+02:00 Vincent Massol <[hidden email]>:
>>>>
>>>>> Hi,
>>>>>
>>>>>> On 11 Apr 2017, at 21:25, Denis Gervalle <[hidden email]> wrote:
>>>>>>
>>>>>> Hi Caty,
>>>>>> Very happy to see progress in this area, this is a real pain to
>>> scroll
>>>>> to the bottom of the document to save it, and there is a long time it
>>> is
>>>>> affecting us.
>>>>>> However, I am not really happy with your current proposal. I found
>>> the
>>>>> text area for the version summary way too small for the purpose.
>>>>
>>>
>>> Beginner users sometimes don't know what that is for. Somebody asked me
>> to
>>> remove it all together :) you think it's too small :P
>>>
>>>
>>>> It should
>>>>> IMO stay on a separate line in order to be large enough. Since this
>> not
>>>>> always useful, it might, however, be collapsed somehow in certain
>>>>> circumstances.
>>>>
>>>
>>> Currently it is on a separate line. I tried to integrate everything in a
>>> single line, that will be always visible, although I agree we have many
>>> functionalities (autosave, summary, minor, preview, etc.) and they look a
>>> bit crowded.
>>>
>>>
>>>>>> I also wonder if just having some buttons on the top in addition to
>>> the
>>>>> bottom, wouldn’t be simpler and as efficient, even if the top feature
>>> is
>>>>> limited (just save / save&view).
>>>>
>>>
>>> Usually save is a the bottom. Still the same view will be also in Full
>>> Screen and the top area is already taken by the CkEditor controls, see
>>> http://design.xwiki.org/xwiki/bin/download/Proposal/
>>> IdeaVisibleSave/fullScreen.png
>>>
>>> Thanks,
>>> Caty
>>>
>>>
>>>> It might also work with your fixed bottom
>>>>> UI, that might also be more limited than what you can do by
>> scrolling.
>>>>>> I hope these are useful comments. I am also curious to see other
>>>>> opinions on this important feature.
>>>>>
>>>>> For me, the issue with the always-on-bar is that it takes up space
>> and
>>>>> thus reduces the available vertical space for editing content. Thus I
>>>> find
>>>>> it interesting to have it on only one line and also to only have it
>> at
>>>> the
>>>>> bottom and not repeat it at the top. I’d really not like to see it at
>>> the
>>>>> top.
>>>>>
>>>>> Thanks
>>>>> -Vincent
>>>>>
>>>>>> --
>>>>>> Denis Gervalle
>>>>>> SOFTEC sa - CEO
>>>>>> On Tue, Apr 11, 2017 at 17:59, Ecaterina Moraru (Valica) <
>>>>> [hidden email]> wrote:
>>>>>> Hi devs,
>>>>>>
>>>>>> Some users have complained that when editing they don't know that
>>> they
>>>>> need
>>>>>> to scroll in order to see the Save buttons.
>>>>>>
>>>>>> This is a proposal that tackles:
>>>>>> - Displaying the save buttons in a bottom area, when they are out
>> of
>>>> the
>>>>>> viewport, see
>>>>>> http://design.xwiki.org/xwiki/bin/download/Proposal/
>>>>> IdeaVisibleSave/bottomBar.png
>>>>>> - Reorganizing the bottom zone in order to compact all the save
>>>> functions
>>>>>> into a single bar
>>>>>> - When the user scrolls, the buttons go into their position, see
>>>>>> http://design.xwiki.org/xwiki/bin/download/Proposal/
>>>>> IdeaVisibleSave/after.png
>>>>>>
>>>>>> For the whole proposal and more screenshots, see
>>>>>> http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaVisibleSave
>>>>>>
>>>>>> WDYT?
>>>>>>
>>>>>> Thanks,
>>>>>> Caty
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Guillaume Delhumeau ([hidden email])
>>>> Research & Development Engineer at XWiki SAS
>>>> Committer on the XWiki.org project
>>>>
>>>
>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal][UX] Visible Save buttons

Denis Gervalle-2
In reply to this post by vmassol
Hi Vincent,
On Mon, Apr 24, 2017 at 21:07, Vincent Massol <[hidden email]> wrote:
Hi Denis/All,

> On 11 Apr 2017, at 21:25, Denis Gervalle <[hidden email]> wrote:
>
> Hi Caty,
> Very happy to see progress in this area, this is a real pain to scroll to the bottom of the document to save it, and there is a long time it is affecting us.

Note that shouldn’t be a problem in most cases and you shouldn’t have to scroll anywhere since the content is inside a textarea with scrollbars and the preview/save/cancel buttons are outside of it and only reasonable resolution they are always visible.

Just tested on a small 1024x76 resolution and they’re very visible and there’s still vertical room:
https://www.evernote.com/l/AHfKSY4sB3lO_6TarSsjkw889qlffOGX4P8

And in full screen it’s the same.

So I’m curious to understand when it’s a problem for you. There’s probably something I’m missing.
Well, I don’t really know how you made your screenshot and how you measured your resolution. Your evernote picture looks scrambled and large. In the most popular landscape desktop resolution ( 1366x768, see http://gs.statcounter.com/screen-resolution-stats/desktop/worldwide), with a menu, here is what I got: http://d.pr/i/R1i3 And, this is even worse than that, since we should consider that the viewport is much lower than the screen size, in particular the height of it.
Any resolution with a viewport less than 1080px in height doesn’t really make it for me. Which means that unless you are on something retina or at least 15”, you had to scroll. According to the above charts, we get covered for less than 1 internet users over 4 on desktop.
Does my mileage vary that much compared to others ? I should admit that I am really puzzled by your remarks, since this has always been a source of pain for me. While I have a large screen, I am often using the debugger in my browser stuck to the bottom, and this put me back in the common use case above (and like this idea of being close to it when testing my work).
Maybe others can shed some lights on this ?
--
Denis Gervalle
SOFTEC sa - CEO


Thanks
-Vincent

> However, I am not really happy with your current proposal. I found the text area for the version summary way too small for the purpose. It should IMO stay on a separate line in order to be large enough. Since this not always useful, it might, however, be collapsed somehow in certain circumstances.
> I also wonder if just having some buttons on the top in addition to the bottom, wouldn’t be simpler and as efficient, even if the top feature is limited (just save / save&view). It might also work with your fixed bottom UI, that might also be more limited than what you can do by scrolling.
> I hope these are useful comments. I am also curious to see other opinions on this important feature.
> --
> Denis Gervalle
> SOFTEC sa - CEO
> On Tue, Apr 11, 2017 at 17:59, Ecaterina Moraru (Valica) <[hidden email]> wrote:
> Hi devs,
>
> Some users have complained that when editing they don't know that they need
> to scroll in order to see the Save buttons.
>
> This is a proposal that tackles:
> - Displaying the save buttons in a bottom area, when they are out of the
> viewport, see
> http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/bottomBar.png
> - Reorganizing the bottom zone in order to compact all the save functions
> into a single bar
> - When the user scrolls, the buttons go into their position, see
> http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/after.png
>
> For the whole proposal and more screenshots, see
> http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaVisibleSave
>
> WDYT?
>
> Thanks,
> Caty
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal][UX] Visible Save buttons

oseres
This post was updated on .
In reply to this post by vmassol
@Vincent : as a PO, you should stay positive in commenting enhancement proposals of others + avoid subjective statement as : "I don't like" or  denigrant "WTF" expression.

@Vincent @Edouard : I think your opinions on this Action Toolbar proposition are too dogmatic : if a change makes the software easier to learn I think it's acceptable to break some rules. However, I accept that the burdon of proof is on me to show that this is indeed likely to improve user experience and learnability.


Here's why I think this change will improve learnability and UX : 

* I think users need to associate that Edit and Save form the major workflow of page modifications. Putting the 2 buttons next to each other reinforce the understanding of the workflow by newcomers
* There is no strong reason not to have Save available at the bottom of the document, I just believe that it needs to also be available at the top too so users see it and not scroll
* Other wikis (including Mediawiki in their Visual Mode and SharePoint wiki ) put the Save Button next to the Edit One (see http://d.pr/i/Qvw8 and http://d.pr/i/rpoJ), they probably have put some effort into usability and so we should consider taking advantage of their effort.

Further more, in other contexts (editors, e-commerce websites), major "final action" ("Publish", "Add to the Cart" are most of the time in the top of the page, so users don't miss it)
* It is more efficient to do one click rather than two (and other software such as Thunderbird accepts to mix buttons like "reply" which start an action but do not complete it with buttons such as "delete message" which do complete an action; GMail also mixes 1-step and 2-steps actions buttons)
* Switching between editor types seems like an advanced feature, it is not exposed to simple users which should be most users


@Vincent : I took your Version summary concern into consideration and made a new proposal here : http://design.xwiki.org/xwiki/bin/download/Proposal/Idea%3A%20Contextual%20Actions%20Toolbar/ContextualToolbarEditModeZoom.png (also avoiding a popup)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal][UX] Visible Save buttons

vmassol
Administrator
Hi Olivier,

> On 25 Apr 2017, at 11:34, oseres <[hidden email]> wrote:
>
> @Vincent : as a PO, you should stay positive in commenting enhancement
> proposals of others, avoid subjective statement as : "I don't like" or
>  denigrant "WTF" expression.

1) PO has no meaning on this list. I’m a committer like any other here.
2) I’m giving my opinion so it is my POV ofc and that’s what we’re asking to everyone here. Don’t take it badly, it’s not personal.
3) I’m not just saying that I don’t like it much, I’m also taking the time to provide some arguments…
4) You didn’t reply to Caty’s proposal and instead you just made another proposal. In general I’ve observed in the past that you rarely comment on what exists or what people propose and instead you have a tendency to want to propose something new coming from you. I appreciate (really I do) that you take the time to make proposals but it would also be nice to comment on other people’s proposals. For example I’d be interested to understand what you don’t like in Caty’s proposal that’s making you propose something different and whether or not you find Caty’s proposal interesting.

> @Vincent @Edouard : I think your opinions on this Action Toolbar
> proposition are too dogmatic : if a change makes the software easier to
> learn I think it's acceptable so break some rules. However, I accept that
> the burdon of proof is on me to show that this is indeed likely to improve
> user experience and learnability.

And also why your proposal is better than Caty’s in your opinion (ie what it solves that Caty’s proposals don’t).

> Here's why I think this change will improve learnability and UX :
>
> * I think users need to associate that Edit and Save form the major workflow
> of page modifications. Putting the 2 buttons next to each other reinforce
> the understanding of the workflow by newcomers

Yes but the counter argument is that the flow goes from top to bottom: as user enter text they move more and more to the bottom. So the bottom is a logical place to find the save.

Also on all UIs I know and on all our Admin Screens for example the validation buttons are always at the bottom.

See https://tinyurl.com/mx8j5re and you’ll see that all UIs have validation buttons at bottom.

> * There is no strong reason not to have Save available at the bottom of the
> document, I just believe that it needs to also be available at the top too
> so users see it and not scroll

I’m not convinced that it’s a good thing to have the same buttons in several places. One drawback of course is that you remove all the options that currently exist in the page content menu (switch editors, edit admins options for the page, etc). If the save buttons are always visible even we scroll I don’t see any compelling reasons to loose the current features by replacing them with another duplicated save button.

> * Other wikis (including Mediawiki in their Visual Mode and SharePoint wiki
> ) put the Save Button next to the Edit One (see http://d.pr/i/Qvw8 and
> http://d.pr/i/rpoJ), they probably have put some effort into usability and
> so we should consider taking advantage of their effort.
> <http://xwiki.475771.n2.nabble.com/file/n7603611/Screen_Shot_2017-04-25_at_11.png>
> Further more, in other contexts (editors, e-commerce websites), major "final
> action" ("Publish", "Add to the Cart" are most of the time in the top of the
> page, so users don't miss it)

Yes that’s a good point but the same argument applies to other wikis. Just to give 3:
* Confluence: https://marketplace-cdn.atlassian.com/files/images/ecbea49f-8a0c-49d0-9d56-e5f12555a207.png and
* Dokuwiki: https://www.dokuwiki.org/features?do=edit
* TikiWiki: https://tinyurl.com/lcrk3pj

> * It is more efficient to do one click rather than two (and other software
> such as Thunderbird accepts to mix buttons like "reply" which start an
> action but do not complete it with buttons such as "delete message" which do
> complete an action; GMail also mixes 1-step and 2-steps actions buttons)

I don’t understand this point. Caty’s proposals and the current way it’s implemented is just one click to save.

> * Switching between editor types seems like an advanced feature, it is not
> exposed to simple users which should be most users

It’s not just that but also all the other features (see the other actions). But even that is important; we certainly don’t want to only have simple users in XWiki. We also need to cater for the needs of advanced users.

> @Vincent : I took your Version summary concern into consideration and made a
> new proposal here
> : http://design.xwiki.org/xwiki/bin/download/Proposal/Idea%3A%20Contextual%20Actions%20Toolbar/ContextualToolbarEditModeZoom.png (also
> avoiding a popup)

Thanks. I still find it a strange UI (it’s strange to add options under a menu). So that I understand: when the user clicks save (not the arrow) what happens? The save menu always open?

Again don’t take it badly but I still find Caty’s proposal closer to the initial need (make the save always visible - your proposal has the issue of loosing sight of the bar when you scroll down, that’s the main problem we’re solving), more natural (doesn’t repurpose buttons), more powerful (still allows to switch edit modes and perform other actions - this one would be a major pain, I use that all the time, switching from one editor to another for example) and more visible (it’s more logical to look for save at the bottom than at the top IMO since the flow goes from top to bottom).

Thanks
-Vincent

> View this message in context: http://xwiki.475771.n2.nabble.com/Proposal-UX-Visible-Save-buttons-tp7603449p7603611.html
> Sent from the XWiki- Dev mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal][UX] Visible Save buttons

vmassol
Administrator
In reply to this post by Denis Gervalle-2

> On 25 Apr 2017, at 00:46, Denis Gervalle <[hidden email]> wrote:
>
> Hi Vincent,
> On Mon, Apr 24, 2017 at 21:07, Vincent Massol <[hidden email]> wrote:
> Hi Denis/All,
>
>> On 11 Apr 2017, at 21:25, Denis Gervalle <[hidden email]> wrote:
>>
>> Hi Caty,
>> Very happy to see progress in this area, this is a real pain to scroll to the bottom of the document to save it, and there is a long time it is affecting us.
>
> Note that shouldn’t be a problem in most cases and you shouldn’t have to scroll anywhere since the content is inside a textarea with scrollbars and the preview/save/cancel buttons are outside of it and only reasonable resolution they are always visible.
>
> Just tested on a small 1024x76 resolution and they’re very visible and there’s still vertical room:
> https://www.evernote.com/l/AHfKSY4sB3lO_6TarSsjkw889qlffOGX4P8
>
> And in full screen it’s the same.
>
> So I’m curious to understand when it’s a problem for you. There’s probably something I’m missing.
> Well, I don’t really know how you made your screenshot and how you measured your resolution. Your evernote picture looks scrambled and large. In the most popular landscape desktop resolution ( 1366x768, see http://gs.statcounter.com/screen-resolution-stats/desktop/worldwide), with a menu, here is what I got: http://d.pr/i/R1i3 And, this is even worse than that, since we should consider that the viewport is much lower than the screen size, in particular the height of it.
> Any resolution with a viewport less than 1080px in height doesn’t really make it for me. Which means that unless you are on something retina or at least 15”, you had to scroll. According to the above charts, we get covered for less than 1 internet users over 4 on desktop.
> Does my mileage vary that much compared to others ? I should admit that I am really puzzled by your remarks, since this has always been a source of pain for me. While I have a large screen, I am often using the debugger in my browser stuck to the bottom, and this put me back in the common use case above (and like this idea of being close to it when testing my work).
> Maybe others can shed some lights on this ?

ok maybe the issue is the retina display indeed. I have a plugin for chrome called resizer (https://chrome.google.com/webstore/detail/window-resizer/kkelicaakdanhinjdeammmilcgefonfh) and it’s supposed to resize the browser window to well known sizes. That’s how I’ve done to test various resolutions. Since that tool is supposed to use pixels, I don’t understand why the retina display would be an issue (since i think it just means more pixels per inch, ie a higher density). But I accept that there is most likely something I don’t understand.

Thanks
-Vincent

> --
> Denis Gervalle
> SOFTEC sa - CEO
>
>
> Thanks
> -Vincent
>
>> However, I am not really happy with your current proposal. I found the text area for the version summary way too small for the purpose. It should IMO stay on a separate line in order to be large enough. Since this not always useful, it might, however, be collapsed somehow in certain circumstances.
>> I also wonder if just having some buttons on the top in addition to the bottom, wouldn’t be simpler and as efficient, even if the top feature is limited (just save / save&view). It might also work with your fixed bottom UI, that might also be more limited than what you can do by scrolling.
>> I hope these are useful comments. I am also curious to see other opinions on this important feature.
>> --
>> Denis Gervalle
>> SOFTEC sa - CEO
>> On Tue, Apr 11, 2017 at 17:59, Ecaterina Moraru (Valica) <[hidden email]> wrote:
>> Hi devs,
>>
>> Some users have complained that when editing they don't know that they need
>> to scroll in order to see the Save buttons.
>>
>> This is a proposal that tackles:
>> - Displaying the save buttons in a bottom area, when they are out of the
>> viewport, see
>> http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/bottomBar.png
>> - Reorganizing the bottom zone in order to compact all the save functions
>> into a single bar
>> - When the user scrolls, the buttons go into their position, see
>> http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/after.png
>>
>> For the whole proposal and more screenshots, see
>> http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaVisibleSave
>>
>> WDYT?
>>
>> Thanks,
>> Caty

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal][UX] Visible Save buttons

Denis Gervalle-2
--
Denis Gervalle
SOFTEC sa - CEO On Tue, Apr 25, 2017 at 12:20, Vincent Massol <[hidden email]> wrote:

> On 25 Apr 2017, at 00:46, Denis Gervalle <[hidden email]> wrote:
>
> Hi Vincent,
> On Mon, Apr 24, 2017 at 21:07, Vincent Massol <[hidden email]> wrote:
> Hi Denis/All,
>
>> On 11 Apr 2017, at 21:25, Denis Gervalle <[hidden email]> wrote:
>>
>> Hi Caty,
>> Very happy to see progress in this area, this is a real pain to scroll to the bottom of the document to save it, and there is a long time it is affecting us.
>
> Note that shouldn’t be a problem in most cases and you shouldn’t have to scroll anywhere since the content is inside a textarea with scrollbars and the preview/save/cancel buttons are outside of it and only reasonable resolution they are always visible.
>
> Just tested on a small 1024x76 resolution and they’re very visible and there’s still vertical room:
> https://www.evernote.com/l/AHfKSY4sB3lO_6TarSsjkw889qlffOGX4P8
>
> And in full screen it’s the same.
>
> So I’m curious to understand when it’s a problem for you. There’s probably something I’m missing.
> Well, I don’t really know how you made your screenshot and how you measured your resolution. Your evernote picture looks scrambled and large. In the most popular landscape desktop resolution ( 1366x768, see http://gs.statcounter.com/screen-resolution-stats/desktop/worldwide), with a menu, here is what I got: http://d.pr/i/R1i3 And, this is even worse than that, since we should consider that the viewport is much lower than the screen size, in particular the height of it.
> Any resolution with a viewport less than 1080px in height doesn’t really make it for me. Which means that unless you are on something retina or at least 15”, you had to scroll. According to the above charts, we get covered for less than 1 internet users over 4 on desktop.
> Does my mileage vary that much compared to others ? I should admit that I am really puzzled by your remarks, since this has always been a source of pain for me. While I have a large screen, I am often using the debugger in my browser stuck to the bottom, and this put me back in the common use case above (and like this idea of being close to it when testing my work).
> Maybe others can shed some lights on this ?

ok maybe the issue is the retina display indeed. I have a plugin for chrome called resizer (https://chrome.google.com/webstore/detail/window-resizer/kkelicaakdanhinjdeammmilcgefonfh) and it’s supposed to resize the browser window to well known sizes. That’s how I’ve done to test various resolutions. Since that tool is supposed to use pixels, I don’t understand why the retina display would be an issue (since i think it just means more pixels per inch, ie a higher density). But I accept that there is most likely something I don’t understand.
FYI, we are on the same tool, but I am using the next version currently in beta: https://chrome.google.com/webstore/detail/window-resizer-beta/pnhnbekjlbamfnnemcaolkjchjlidbib However, I have not used retina display for the test. I have noticed that taking screenshot from a retina display might mislead you since it gives you a very high resolution screenshot. It should not influence your test, however. Puzzling indeed.
-- Denis

Thanks
-Vincent

> --
> Denis Gervalle
> SOFTEC sa - CEO
>
>
> Thanks
> -Vincent
>
>> However, I am not really happy with your current proposal. I found the text area for the version summary way too small for the purpose. It should IMO stay on a separate line in order to be large enough. Since this not always useful, it might, however, be collapsed somehow in certain circumstances.
>> I also wonder if just having some buttons on the top in addition to the bottom, wouldn’t be simpler and as efficient, even if the top feature is limited (just save / save&view). It might also work with your fixed bottom UI, that might also be more limited than what you can do by scrolling.
>> I hope these are useful comments. I am also curious to see other opinions on this important feature.
>> --
>> Denis Gervalle
>> SOFTEC sa - CEO
>> On Tue, Apr 11, 2017 at 17:59, Ecaterina Moraru (Valica) <[hidden email]> wrote:
>> Hi devs,
>>
>> Some users have complained that when editing they don't know that they need
>> to scroll in order to see the Save buttons.
>>
>> This is a proposal that tackles:
>> - Displaying the save buttons in a bottom area, when they are out of the
>> viewport, see
>> http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/bottomBar.png
>> - Reorganizing the bottom zone in order to compact all the save functions
>> into a single bar
>> - When the user scrolls, the buttons go into their position, see
>> http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/after.png
>>
>> For the whole proposal and more screenshots, see
>> http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaVisibleSave
>>
>> WDYT?
>>
>> Thanks,
>> Caty
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal][UX] Visible Save buttons

Ecaterina Moraru (Valica)
We had some brainstorming, some conclusions:
- We will try the fixed bottom bar solution, since it provides better
discoverability of the Save button and also works in case of pages that
have scroll;
- Inline mode is problematic since users might think the page is over and
miss some inputs to fill. For this reason we will apply the changes only to
the Wiki and WYSIWYG mode;
- We will apply also the new fields organization (summary, minor,
auto-save);

Let me know what you think.
Thanks,
Caty


On Tue, Apr 25, 2017 at 3:59 PM, Denis Gervalle <[hidden email]> wrote:

> --
> Denis Gervalle
> SOFTEC sa - CEO On Tue, Apr 25, 2017 at 12:20, Vincent Massol <
> [hidden email]> wrote:
>
> > On 25 Apr 2017, at 00:46, Denis Gervalle <[hidden email]> wrote:
> >
> > Hi Vincent,
> > On Mon, Apr 24, 2017 at 21:07, Vincent Massol <[hidden email]>
> wrote:
> > Hi Denis/All,
> >
> >> On 11 Apr 2017, at 21:25, Denis Gervalle <[hidden email]> wrote:
> >>
> >> Hi Caty,
> >> Very happy to see progress in this area, this is a real pain to scroll
> to the bottom of the document to save it, and there is a long time it is
> affecting us.
> >
> > Note that shouldn’t be a problem in most cases and you shouldn’t have to
> scroll anywhere since the content is inside a textarea with scrollbars and
> the preview/save/cancel buttons are outside of it and only reasonable
> resolution they are always visible.
> >
> > Just tested on a small 1024x76 resolution and they’re very visible and
> there’s still vertical room:
> > https://www.evernote.com/l/AHfKSY4sB3lO_6TarSsjkw889qlffOGX4P8
> >
> > And in full screen it’s the same.
> >
> > So I’m curious to understand when it’s a problem for you. There’s
> probably something I’m missing.
> > Well, I don’t really know how you made your screenshot and how you
> measured your resolution. Your evernote picture looks scrambled and large.
> In the most popular landscape desktop resolution ( 1366x768, see
> http://gs.statcounter.com/screen-resolution-stats/desktop/worldwide),
> with a menu, here is what I got: http://d.pr/i/R1i3 And, this is even
> worse than that, since we should consider that the viewport is much lower
> than the screen size, in particular the height of it.
> > Any resolution with a viewport less than 1080px in height doesn’t really
> make it for me. Which means that unless you are on something retina or at
> least 15”, you had to scroll. According to the above charts, we get covered
> for less than 1 internet users over 4 on desktop.
> > Does my mileage vary that much compared to others ? I should admit that
> I am really puzzled by your remarks, since this has always been a source of
> pain for me. While I have a large screen, I am often using the debugger in
> my browser stuck to the bottom, and this put me back in the common use case
> above (and like this idea of being close to it when testing my work).
> > Maybe others can shed some lights on this ?
>
> ok maybe the issue is the retina display indeed. I have a plugin for
> chrome called resizer (https://chrome.google.com/webstore/detail/window-
> resizer/kkelicaakdanhinjdeammmilcgefonfh) and it’s supposed to resize the
> browser window to well known sizes. That’s how I’ve done to test various
> resolutions. Since that tool is supposed to use pixels, I don’t understand
> why the retina display would be an issue (since i think it just means more
> pixels per inch, ie a higher density). But I accept that there is most
> likely something I don’t understand.
> FYI, we are on the same tool, but I am using the next version currently in
> beta: https://chrome.google.com/webstore/detail/window-resizer-beta/
> pnhnbekjlbamfnnemcaolkjchjlidbib However, I have not used retina display
> for the test. I have noticed that taking screenshot from a retina display
> might mislead you since it gives you a very high resolution screenshot. It
> should not influence your test, however. Puzzling indeed.
> -- Denis
>
> Thanks
> -Vincent
>
> > --
> > Denis Gervalle
> > SOFTEC sa - CEO
> >
> >
> > Thanks
> > -Vincent
> >
> >> However, I am not really happy with your current proposal. I found the
> text area for the version summary way too small for the purpose. It should
> IMO stay on a separate line in order to be large enough. Since this not
> always useful, it might, however, be collapsed somehow in certain
> circumstances.
> >> I also wonder if just having some buttons on the top in addition to the
> bottom, wouldn’t be simpler and as efficient, even if the top feature is
> limited (just save / save&view). It might also work with your fixed bottom
> UI, that might also be more limited than what you can do by scrolling.
> >> I hope these are useful comments. I am also curious to see other
> opinions on this important feature.
> >> --
> >> Denis Gervalle
> >> SOFTEC sa - CEO
> >> On Tue, Apr 11, 2017 at 17:59, Ecaterina Moraru (Valica) <
> [hidden email]> wrote:
> >> Hi devs,
> >>
> >> Some users have complained that when editing they don't know that they
> need
> >> to scroll in order to see the Save buttons.
> >>
> >> This is a proposal that tackles:
> >> - Displaying the save buttons in a bottom area, when they are out of the
> >> viewport, see
> >> http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaVisibleSave/bottomBar.png
> >> - Reorganizing the bottom zone in order to compact all the save
> functions
> >> into a single bar
> >> - When the user scrolls, the buttons go into their position, see
> >> http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaVisibleSave/after.png
> >>
> >> For the whole proposal and more screenshots, see
> >> http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaVisibleSave
> >>
> >> WDYT?
> >>
> >> Thanks,
> >> Caty
>
Loading...