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 <d...@softec.lu> wrote: > -- > Denis Gervalle > SOFTEC sa - CEO On Tue, Apr 25, 2017 at 12:20, Vincent Massol < > vinc...@massol.net> wrote: > > > On 25 Apr 2017, at 00:46, Denis Gervalle <d...@softec.lu> wrote: > > > > Hi Vincent, > > On Mon, Apr 24, 2017 at 21:07, Vincent Massol <vinc...@massol.net> > wrote: > > Hi Denis/All, > > > >> On 11 Apr 2017, at 21:25, Denis Gervalle <d...@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) < > vali...@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 >
