24 Apr
2017
24 Apr
'17
5:23 p.m.
On Mon, Apr 24, 2017 at 5:07 PM, Ecaterina Moraru (Valica) <
valicac(a)gmail.com> wrote:
Another proposal by Olivier
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 <enygma2002(a)gmail.com>
wrote:
a
Thus
I
at
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) <
valicac(a)gmail.com> wrote:
it
On Wed, Apr 12, 2017 at 11:53 AM, Guillaume
Delhumeau <
guillaume.delhumeau(a)xwiki.com> wrote:
that
> clear.
>
>
> >
> >
> > 2017-04-11 21:58 GMT+02:00 Vincent Massol <vincent(a)massol.net>et>:
> >
> > > Hi,
> > >
> > > > On 11 Apr 2017, at 21:25, Denis Gervalle <dgl(a)softec.lu>
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 +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 > is
> > > affecting us.
> > > > However, I am not really happy with your current proposal. I
found
the
to
> 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 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 > 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
scrolling.
> 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 > > > 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. >
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 the
of
> top.
>
> Thanks
> -Vincent
>
> > --
> > Denis Gervalle
> > SOFTEC sa - CEO
> > On Tue, Apr 11, 2017 at 17:59, Ecaterina Moraru (Valica) <
> valicac(a)gmail.com> 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 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 (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project