Re: [Libreoffice-ux-advise] [GSOC] iOS remote control design
Hi Mirek, On Aug 7, 2013 7:55 PM, "Mirek M." wrote: > > Hi Siqi, > > On Mon, Aug 5, 2013 at 2:28 PM, Siqi Liu wrote: >> >> Hi Mirek, >> >> Thanks for you feedbacks! I've responded inline for certain issues that you have pointed out. >> >> On Aug 5, 2013 11:45 AM, "Mirek M." wrote: >> > >> > Hi again, >> > I was hoping someone else would comment, because I'm not well-versed in the iOS HIG and I don't care much for the platform. It doesn't help that the iOS 7 HIG is hidden behind an Apple ID login, which I don't have -- if you have one, take a look at the HIG [1] and the iOS 7 UI transition guide [2]. >> >> Me neither, I'm fairly new to iOS dev actually ^^ I will take a look at it. > > OK, good. >> >> > Based on what I've gathered from articles, screens, and videos about iOS, though, here are my comments and concerns: >> > * The swipe-in sidebar might not work on iOS 7 devices, as the swipe from the left side of the screen is used to go back. I'd recommend installing an iOS 7 beta to test out your app, and instead of a swipe-in sidebar, how about a pinch-out overview like on the Android app? As a plus, it won't be possible to accidentally show the sidebar when you meant to go to the last slide. >> >> Actually the swipe in sidebar is activated only by the detail button on the upper right corner since I don't want users to accidentally activate it by a swipe gesture. However I do need to swap the position of "stop presentation" button (on the left) and the "detail button" (on the right), didn't know why I placed them in wrong positions :-P > > OK. >> >> > * The style seems to be an odd combination of iOS 6 and iOS 7 styles. Please pick one and go with it (I would say iOS 7 is a better choice). It would be good to use orange as the accent color, like we do on Android. >> >> Ok, I will change the accent to orange throughout the app, which was green before. >> >> In terms of styling, I personally don't have any iOS 7 compatible device to test on so I can either test it in the iOS7 simulator (which is still in Dev preview) or really just customize all the iOS 6 elements to make them feel like iOS7...which doesn't appear to be a good choice to me... > > iOS 7 simulator sounds good. Don't customize the iOS 6 elements -- that would probably not give accurate results. Actually if we release the app as an iOS6 app, (which would be the case) it would continue to use iOS 6 ui elements on iOS7 devices. For now I've just customized some elements to be similar to the one used in ios 7, and it turns out fine since basically we are removing old styles components (gradients, shadow etc to get flatter). I have tested on iOS6 and iOS5 devices and both work fine. I've also borrowed an iOS7 device to test on and it works as expected though some tweaks are necessary to make the feeling more coherent throughout the app. >> >> But yes, I will investigate into how to make the design style transition between iOS6 based app and iOS7 based app. For now, all the customized elements are designed to be similar to the iOS7 because, ...let's admit it, the iOS6 UI is just too boring...I'm kind of struggling here as well. >> >> > * I don't quite understand the layout slide show control pad. Why is the next slide shown on the left whan one gets to it by swiping to the right? Why is it shown at all? >> >> First, I did not stick to the Android app which used a coverflow to change between slides because it's to me a little bit trickier to change to next slide by swiping. It doesn't seem to be as reliable as to simply click on a button. With a button, users don't even need to look at the app to know if they have swiped to the next slide or the next next slide... It was pointed out by Michael M during the initial proposition period as well and that's also why I made two big buttons for users to reliably control the next/previous slide. > > This would be good to test out. On the one hand, tapping is simpler, on the other, it requires the presenter to look at the screen to hit the target area, whereas, with swiping, the whole screen is the actionable area. Hmm..this still doesn't convince me... Scrolling is designed to easily browse through multiples items (in a nonlinear way like pick a music album) , and here the most used functionality is next/previous slide for a normal presentation. It doesn't feel right to put a cover-flow in such a prominent place...if users need to switch to another slide, it isn't really complicated to use the sidebar to do that. However if you do think it's a better way to go I can try that, no problem here. > BTW, on Android, there's also the option to use volume buttons to switch slides. Good point, I'll check if this is doable on iOS since they are known to be more strict on APIs. :-P >> >> Second, the reason I show a secondary slideshow preview is twofold: 1. It can be helpful for users to know what's the next slide, especially when the presentation is at the last slide, in which case the next slide will be bl
[Libreoffice-ux-advise] Fwd: Document Colors
On Wed, Aug 7, 2013 at 4:52 PM, Jan Holesovsky wrote: > Hi Mirek, > > Mirek M. píše v Út 06. 08. 2013 v 15:30 +0200: > > > How hard would it be to add a "Document colors" section below the > > color palette in the palette picker? Do you think it could qualify for > > an easy hack? > > Can you please provide a mockup / screenshot with "<- here we'd add > this"? :-) - I'm not sure I understand it well... > Here's a Pencil mockup: http://ubuntuone.com/53CaLAjsvNpbTx54wZ1l9q. I hope it's clear enough. I used the proposed 12-column layout [1] instead of the current 8-column one in the mockup. > > > Such a section would allow users to keep the style of a document if > > the document doesn't use LibreOffice colors, it would allow us to > > rethink our color selection, and it would be a step toward allowing > > the user to choose any custom color without having to go through the > > Options dialog. > > Sounds useful, and not too hard in general though; but need to > understand it better... > > Thank you a lot, > Kendy > > > [1] https://bugs.freedesktop.org/show_bug.cgi?id=67653 ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 38144] Functionality request:UI Option in Writer to enable snap to grid in ruler
https://bugs.freedesktop.org/show_bug.cgi?id=38144 --- Comment #24 from Tomaz Vajngerl --- Columns of tables already snap to ruler marks.. or should snap. There is currently a bug that makes snapping erratic but I will fix this sooner or later. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] Shape Icons
Hi Mirek, Mirek M. píše v Út 06. 08. 2013 v 16:14 +0200: > Since the shape icons in the Symbolic icon set have the same > silhouette as the ones in the Tango testing set, could someone just > make a script to automatically make the Tango testing shape icons > based on the Symbolic shape icons? I haven't been doing anything like that myself, but there seems to be a tutorial for scripting Inkscape; so I guess in general this is doable. The tutorial is here: http://wiki.inkscape.org/wiki/index.php/PythonEffectTutorial But how hard is that, I have no idea :-( 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] Document Colors
Hi Mirek, Mirek M. píše v Út 06. 08. 2013 v 15:30 +0200: > How hard would it be to add a "Document colors" section below the > color palette in the palette picker? Do you think it could qualify for > an easy hack? Can you please provide a mockup / screenshot with "<- here we'd add this"? :-) - I'm not sure I understand it well... > Such a section would allow users to keep the style of a document if > the document doesn't use LibreOffice colors, it would allow us to > rethink our color selection, and it would be a step toward allowing > the user to choose any custom color without having to go through the > Options dialog. Sounds useful, and not too hard in general though; but need to understand it better... Thank you a lot, 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] [GSOC] iOS remote control design
P. S. Could your app icon be orange, to be consistent with the Impress branding? ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] [GSOC] iOS remote control design
Hi Siqi, On Mon, Aug 5, 2013 at 2:28 PM, Siqi Liu wrote: > Hi Mirek, > > Thanks for you feedbacks! I've responded inline for certain issues that > you have pointed out. > > On Aug 5, 2013 11:45 AM, "Mirek M." wrote: > > > > Hi again, > > I was hoping someone else would comment, because I'm not well-versed in > the iOS HIG and I don't care much for the platform. It doesn't help that > the iOS 7 HIG is hidden behind an Apple ID login, which I don't have -- if > you have one, take a look at the HIG [1] and the iOS 7 UI transition guide > [2]. > > Me neither, I'm fairly new to iOS dev actually ^^ I will take a look at it. > OK, good. > > Based on what I've gathered from articles, screens, and videos about > iOS, though, here are my comments and concerns: > > * The swipe-in sidebar might not work on iOS 7 devices, as the swipe > from the left side of the screen is used to go back. I'd recommend > installing an iOS 7 beta to test out your app, and instead of a swipe-in > sidebar, how about a pinch-out overview like on the Android app? As a plus, > it won't be possible to accidentally show the sidebar when you meant to go > to the last slide. > > Actually the swipe in sidebar is activated only by the detail button on > the upper right corner since I don't want users to accidentally activate it > by a swipe gesture. However I do need to swap the position of "stop > presentation" button (on the left) and the "detail button" (on the right), > didn't know why I placed them in wrong positions :-P > OK. > > * The style seems to be an odd combination of iOS 6 and iOS 7 styles. > Please pick one and go with it (I would say iOS 7 is a better choice). It > would be good to use orange as the accent color, like we do on Android. > > Ok, I will change the accent to orange throughout the app, which was green > before. > > In terms of styling, I personally don't have any iOS 7 compatible device > to test on so I can either test it in the iOS7 simulator (which is still in > Dev preview) or really just customize all the iOS 6 elements to make them > feel like iOS7...which doesn't appear to be a good choice to me... > iOS 7 simulator sounds good. Don't customize the iOS 6 elements -- that would probably not give accurate results. > But yes, I will investigate into how to make the design style transition > between iOS6 based app and iOS7 based app. For now, all the customized > elements are designed to be similar to the iOS7 because, ...let's admit it, > the iOS6 UI is just too boring...I'm kind of struggling here as well. > > * I don't quite understand the layout slide show control pad. Why is the > next slide shown on the left whan one gets to it by swiping to the right? > Why is it shown at all? > > First, I did not stick to the Android app which used a coverflow to change > between slides because it's to me a little bit trickier to change to next > slide by swiping. It doesn't seem to be as reliable as to simply click on a > button. With a button, users don't even need to look at the app to know if > they have swiped to the next slide or the next next slide... It was pointed > out by Michael M during the initial proposition period as well and that's > also why I made two big buttons for users to reliably control the > next/previous slide. > This would be good to test out. On the one hand, tapping is simpler, on the other, it requires the presenter to look at the screen to hit the target area, whereas, with swiping, the whole screen is the actionable area. BTW, on Android, there's also the option to use volume buttons to switch slides. > Second, the reason I show a secondary slideshow preview is twofold: 1. It > can be helpful for users to know what's the next slide, especially when the > presentation is at the last slide, in which case the next slide will be > black with a big "SlideShow Finished" on it 2. The screen size of iPhone is > much narrower and shorter than most of the android devices, which makes it > impossible to present only one slide while leaving enough space for the > lecturer's notes and the buttons on the bottom (if we maintain the aspect > ratio of the slideshow of course). If we want to keep aspect ratio of the > slideshow image, it presenting two slides at the same time seems to solve > the problem. > > [image: Images intégrées 1] > > [image: Images intégrées 2] > > However, it does make more sense to place the next slide to the right. I > will change that soon. > Thanks. That will make more sense. Be sure to keep the new iPhone shape in mind as well, though. > > > * What does the Touch Pointer in settings do and how is it different > from the Pointer button in slide view? > > The "Touch Pointer" option, when disabled, activates accelerometer based > pointer. But if at the end of gsoc I don't have a reliable accelerometer > based pointer, I will remove this option and makes it touch pointer only, > > The pointer button, in "touch pointer" mode, will display an enlarged > current slide, which al
[Libreoffice-ux-advise] [Bug 67860] Auto detection of high contrast mode is easy to trigger
https://bugs.freedesktop.org/show_bug.cgi?id=67860 Michael Meeks changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||libreoffice-ux-advise@lists ||.freedesktop.org See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=67859 Component|UI |ux-advise Ever confirmed|0 |1 --- Comment #1 from Michael Meeks --- I've pushed a patch to master: http://cgit.freedesktop.org/libreoffice/core/commit/?id=0acdeacbe774b7e05323ad80b556e7102a083192 Which disables this auto-detection by default; a user can still turn that on again if they want. I'd love to back-port this to 4.1.x - but it'd be good to have some UX input on this. The previous algorithm looks for a couple of theme colours and if both are dark auto-switches to 'high contrast mode'. IMHO our high contrast mode should be implemented by using a different set of theme colours rather than this approach but ... Other ways to detect under Linux might be to grok the theme name and if it includes 'highcontrast' then enable that setting, otherwise never do it. Thoughts from designers / UX advice much appreciated. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
