25 Apr
2017
25 Apr
'17
7:01 p.m.
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 <dgl(a)softec.lu> wrote:
--
Denis Gervalle
SOFTEC sa - CEO On Tue, Apr 25, 2017 at 12:20, Vincent Massol <
vincent(a)massol.net> wrote:
On 25 Apr 2017, at 00:46, Denis Gervalle
<dgl(a)softec.lu> wrote:
Hi Vincent,
On Mon, Apr 24, 2017 at 21:07, Vincent Massol <vincent(a)massol.net>
wrote:
Hi Denis/All,
> 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 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) <
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 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