Re: [Libreoffice-ux-advise] [PATCH] fix bug 51231, but...
Hi Astron, many thanks for the detailed reply. On 02.08.2012 03:34, Stefan Knorr wrote: Hi there, On 29 July 2012 13:20, Ivan Timofeev timofeev@gmail.com wrote: But (don't cast stones at me) could we revert this feature? No casting stones at you (I won't, at least). I agree with you. So can I use your sign-off for reverting http://cgit.freedesktop.org/libreoffice/core/commit/?id=4866b20ec6205b04cd21077fd00d68c4d4bb2c1b on the libreoffice-3-6 branch? As a makeshift fix, would it be possible to make the overlay appear half/a quarter of a second later? Sure, the corresponding constant is Theme_ButtonFadeInDelay in sd/source/ui/slidesorter/inc/view/SlsTheme.hxx Feel free to push patches. :) So, you read until here, possible solutions that we could explore: [...] Of all those, I slightly favour #1, but really not by much. #3 is good too IMHO, especially due to fdo#37654. Best regards, Ivan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-ux-advise] [PATCH] fix bug 51231, but...
Hi Ivan, Terribly sorry for the belated answer. On 2012-08-02 at 18:15 +0400, Ivan Timofeev wrote: So can I use your sign-off for reverting http://cgit.freedesktop.org/libreoffice/core/commit/?id=4866b20ec6205b04cd21077fd00d68c4d4bb2c1b on the libreoffice-3-6 branch? Yes, if Astron says it should go, you have my sign-off too :-) - I am not personally attached to that code. It was an attempt to fix the behavior when the button appears under the mouse just at the very moment you try to click the slide to select that that annoyed some people too. As a makeshift fix, would it be possible to make the overlay appear half/a quarter of a second later? Sure, the corresponding constant is Theme_ButtonFadeInDelay in sd/source/ui/slidesorter/inc/view/SlsTheme.hxx Feel free to push patches. :) Maybe a short-term solution would be not to increase the the timer, but actually decrease it? Ie. let the buttons appear immediately when you enter the slide in the slidesorter? That would let the user to position the mouse carefully to avoid clicking what she does not want to click. All the best, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-ux-advise] [PATCH] fix bug 51231, but...
Hi Astron, [Keeping this just the UX-advise list.] On 2012-08-02 at 01:34 +0200, Stefan Knorr wrote: So, you read until here, possible solutions that we could explore: #1 Have the overlay appear permanently on the currently active slide PRO: touch-friendly, not too flashy, expectable CON: interactions will be much slower, because you have to click every slide before being able to use it. [...] Of all those, I slightly favour #1, but really not by much. Hope that helps in any way. I particularly like #1 too. In order to address the need to click - what if the buttons were next to each slide, but faded for the non-selected slides? Thank you, Kendy ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] [PATCH] fix bug 51231, but...
Hi Ivan, Terribly sorry for the belated answer. On 2012-08-02 at 18:15 +0400, Ivan Timofeev wrote: So can I use your sign-off for reverting http://cgit.freedesktop.org/libreoffice/core/commit/?id=4866b20ec6205b04cd21077fd00d68c4d4bb2c1b on the libreoffice-3-6 branch? Yes, if Astron says it should go, you have my sign-off too :-) - I am not personally attached to that code. It was an attempt to fix the behavior when the button appears under the mouse just at the very moment you try to click the slide to select that that annoyed some people too. As a makeshift fix, would it be possible to make the overlay appear half/a quarter of a second later? Sure, the corresponding constant is Theme_ButtonFadeInDelay in sd/source/ui/slidesorter/inc/view/SlsTheme.hxx Feel free to push patches. :) Maybe a short-term solution would be not to increase the the timer, but actually decrease it? Ie. let the buttons appear immediately when you enter the slide in the slidesorter? That would let the user to position the mouse carefully to avoid clicking what she does not want to click. All the best, Kendy ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] [PATCH] fix bug 51231, but...
Hi there, On 29 July 2012 13:20, Ivan Timofeev timofeev@gmail.com wrote: But (don't cast stones at me) could we revert this feature? No casting stones at you (I won't, at least). I agree with you. Kendy's analysis was/is obviously correct in that there's a problem with the little black overlay and the time at which it appears. Finding a solution to the problem isn't all that easy either, I'll explain below. I discussed this with Kendy at the hackfest, and while we reached a conclusion there, I later went back to it and found that it wasted lots of space. As a makeshift fix, would it be possible to make the overlay appear half/a quarter of a second later? So, you read until here, possible solutions that we could explore: #1 Have the overlay appear permanently on the currently active slide PRO: touch-friendly, not too flashy, expectable CON: interactions will be much slower, because you have to click every slide before being able to use it. #2 Let the overlay overlay the next (or previous) slide: PRO: overlay appears completely outside of the mouse pointer's area CON: technically not feasible due to the stacking of the slides (according to Kendy) #3 Move the slide number below the slide and display the slide title again, then have the overlay appear off the slide (but in the title area below it) [mockup attached: left – current; right – proposal]: PRO: it's off the main clicking area (still somewhat in the way but fine for most) CON: the area would have to be made much larger, it wastes much more vertical space (even at the same thumbnail size) #4 Add a toolbar to either the top or the bottom of the slid sorter: PRO: not flashy, very conventional CON: would make the interaction a bit indirect, and worse: since the slide sorter and the slide sidebar share their code: it would look terrible in the sorter (three icons on a whole screen's width looks awful) Of all those, I slightly favour #1, but really not by much. Hope that helps in any way. Astron. attachment: slides.png___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
RE: [Libreoffice-ux-advise] [PATCH] fix bug 51231, but...
But (don't cast stones at me) could we revert this feature? These new features are annoying me too. In Writer we now have Footer and Header pop-ups and maybe other pop-ups as well. The ones in Writer are not nearly as problematic as the ones in Impress, but they don't work that well either (the control button that appears on mouse over top of document is located outside the header area, and moving the mouse to the button leads to leaving that area quite often, which results in that damn button to disappear). These pop-ups/overlays can be helpful, when they are working as expected and when much thought has been put into what they do and how they react. But in most cases, they distract me and they break my work-flow. A rather good example for such a pop-up can be found in Microsoft Office (2010?), where a context menu box is shown after text got pasted into a document. This implementation is robust and works well 99 % of the time. But I feel that with the 1 % of the time when it doesn't work, I loose more in total than I gain from those flawless 99 %. I can only speak for myself here, and I know that I am offending some programmers, who invested a lot of work in those features, but intelligent software is _always_ plain wrong, wrong and wrong and keep it simple is the best approach to usability. The user should not have to anticipate what the software might or might not do depending on different situations! Greetings, Daniel M From: libreoffice-ux-advise-bounces+daniel.mania=umb...@lists.freedesktop.org [libreoffice-ux-advise-bounces+daniel.mania=umb...@lists.freedesktop.org] on behalf of Ivan Timofeev [timofeev@gmail.com] Sent: 29 July 2012 13:20 To: libo-dev Cc: libo-ux-advise; Jan Holesovsky Subject: [Libreoffice-ux-advise] [PATCH] fix bug 51231, but... Hi, this patch fixes https://bugs.freedesktop.org/show_bug.cgi?id=51231 UI: Slide thumbnail overlay start presentation, disable slide, copy slide position depends on slides pane scroll slider position and mouse way where depends on slides pane scroll slider position is a bug, but and mouse way is a feature: http://cgit.freedesktop.org/libreoffice/core/commit/?id=4866b20ec6205b04cd21077fd00d68c4d4bb2c1b But (don't cast stones at me) could we revert this feature? IMHO it only creates the nervous tension: oh, where this black thing would appear now?. My usual mouse movements are sweeping, and if I entered a (quite small) slide preview at the bottom, it does not mean that I will stop and click immediately at the bottom. If you disagree with me and want this feature staying in - just push my patch to master and 3-6, it fixes a MAB. :) Cheers, Ivan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
