Hi Kévin, On Sun, Mar 24, 2013 at 12:51 PM, Kévin PEIGNOT <[email protected]>wrote:
> Hi Mirek > > 2013/3/24 Mirek M. <[email protected]> > > Hi Kévin, >> On the wiki page, I can only open the second mockup, the first tells me >> that it can't be displayed because it contains errors. >> My thoughts on the design below: >> >> I know this, we discored this during > > the IRC Chat yesterday don't ask me why but the wiki do not wan't it. Go > there it worked better (the same version > http://ubuntuone.com/5dzsz5Lnu3ZuuTkU2HxYmG) > The wiki labels it as an SVG file... Are you sure you didn't accidentally upload the SVG instead of the PNG? > On Sun, Mar 17, 2013 at 6:23 PM, Kévin PEIGNOT <[email protected] >> > wrote: >> >>> Hi all >>> >>> >>> <Mirek> I would put the Old and New indicators in another place. As they >>> aren't click-able, it doesn't make sense to put them in the place that's >>> most accessible for a mouse -- they only increase the distance the mouse >>> has to travel to reach a clickable target. (In my proposal, these >>> indicators were shown below the picker, with only the old color shown >>> first and then the new color superposed on it as one hovered over it.) >>> Done >>> >> >> I would still prefer it if they were shown separately from the clickable >> area, e.g. in a balloon/tooltip. >> Right now, it's not visibly obvious that they are not clickable. >> > I don't agree. Except it would make the popover look more cluttered (my > thought), I think the "OLd" at least should be clickable : for example, > when you define personal color, if you wan't a very close color to the > actual and made an error and would like to restart, instead of Ctrl+Z, > clicking on "Old" re-define the old color as the new one. > Firstly, a well-designed balloon would help visually distinguish between the picker area and the preview area. When there isn't enough separation, there is clutter, and the brain has to work harder to interpret different areas of the picker. Secondly, it's hard for me to imagine a consistent clickable Old/New button behavior. In custom color view, clicking Old would bring the original color back. Would it do nothing in normal color view? Would the New button do nothing? If so, the feature would be quite hard to discover. Thirdly, unlike with Undo/Redo, there would be no way to get back to the New color. > > <Issa> Since it is a pop-over and not a dialog the custom colors should >>> be applied immediately upon changing the current color. The window can >>> be closed when the focus moves away or using an ok button >>> <Mirek> As Issa said, "Since [...] button." An apply button would be >>> unnecessary in this case. (Actually, it would be confusing, as this >>> button would do nothing.) >>> Done with a OK button. I precised in the explanation on the >>> mockup that >>> clicking "OK" or loosing focus just close the popover, as the color is >>> applied as soon as it's defined >>> >> >> The "OK" button is still as confusing as an "Apply" button would be, as >> it still does nothing. >> If you feel there absolutely must be a button, make it say "Close". >> > > In a lot of windows, we have "OK" "Apply" et "Close". "Close" close the > window without applying changes, so it's not a good choice, "Apply" apply > changes without closing, not the good choice too. "OK" apply and close. so > even if the color is already applied, it makes sense use it, as this just > definitively validate your choice. > > So I don't agree at all with Close button > > "Cancel" means close and lose all changes, whereas "Close" means just what it says -- close. No more, no less. That's what this button does. In general, it's best not to use "OK" on buttons, especially if it isn't answering a question, because it has no clear meaning. Gnome has been using "Close" for years in its dialogs and I've never heard a single complaint. If you think "Close" is unclear, it could be "Apply and Close". Honestly, though, given that the pop-over closes when clicking outside of it and that we can assume the user has this knowledge, because otherwise he wouldn't be able to close the current pop-over we have if he opened it accidentally, I'm thinking it's best not to go with any button. > <Mirek> If we agree to have a gear button, it should really be a menu. >>> I'm not 100% sure that we need it for the first implementation, though. >>> <Issa> The theme creator dialog should be replaced with a drop down menu >>> for changing themes, possibly next to the theme colors label. >>> I'm not sur about that : You do not change your theme so often, >>> The >>> popover is a fast access tool. More of that, seeing the M$ theme creator >>> window [2], this could take a lot of place. Not sure it's a good idea >>> having such a big popover >>> >> >> You misunderstood what I said. >> I didn't mean having theme management in the pop-over. I meant that the >> gear button should be a drop-down menu, as it may grow to include more than >> one item. >> > you mean > > a line just for theme managment ? would take lot of place I think, that we > don't have vertically > No. Here's what I mean: Clicking the gear icon would open up a menu. The menu would include the item "Manage theme...". Or, for the time being, we could only have a non-gear icon for theme >> management, but that icon would have to be labeled. >> >>> >>> <Mirek> Also, it would be good if the "Palette" section of the pop-over >>> was designed to be able to carry other palettes than the default. Thus, >>> the section wouldn't have a separate area for grays, as few palettes >>> separate their grays like this. >>> I put the grey bar on the left. I don't really think why palette >>> couldn't be tweaked, but I'm not sure this would be useful : for me >>> palette is there to present almost every color existing. if you need >>> personalized colors, the theme colors are there. As I answers to Issa >>> concerns, for the palette itself should be fixed (I mean, not easily >>> changeable) >>> >> >> I disagree. We shouldn't design for one specific palette, but rather >> assume that a user might like to use a custom palette -- perhaps his >> company has a palette, perhaps he's working on Tango icons in Gnome and >> needs the Tango palette, ... >> > So, adding a button to import a palette ? > I was thinking this button could be part of the palette chooser, as in https://wiki.documentfoundation.org/images/7/7d/C-menu.png . About Issa's concerns: >>> >>> -Wouldn't using square tiles be more consistent and natural with the >>> desktop UI ? >>> I don't know, the old theme is very square, for sure, but newly >>> introduced features (header/footer note etc) are not really. Personally, >>> I would keep rounded squares. (More of that, the Flat icon set, even if >>> not default, is designed rounded, as it follows Gnome design) >>> >> >> Gnome uses slightly rounded squares. >> > Right, even if I don't like that. However, we don't design for Gnome, but > for LibreOffice, a cross nplatform software > Sure. The original idea came from Gnome, as we are using Gnome's icons and the Gnome HIG is our de-facto go-to HIG, but you're definitely free to experiment with the look of the color tablets. > >>> -Wouldn't it be better if we use a color map/square for the HSL instead >>> of the wheel since it's already implemented and prettier in my opinion? >>> Personally I prefer the wheel. Then I'm not sure what would be >>> the good >>> choice. >>> >> >> Or perhaps use sliders, which I personally prefer? >> > Look the proposal, sliders are there. And we have a tab we wheel or color > table (still to choose) > In http://ubuntuone.com/5dzsz5Lnu3ZuuTkU2HxYmG, there are only sliders for RGB, not for HSL. Or is that an older mockup? > >> On Mon, Mar 18, 2013 at 2:24 AM, Kévin PEIGNOT <[email protected] >> > wrote: >> >>> Hi All >>> >>> I just thought about something related to the "Old/New" icons. On >>> desktop version, that's right it's better having that at the bottom is >>> it means less distance with the mouse. But on the tablet version, this >>> MUST be at the top of the popover ... Or you will hide it with your >>> hand while touching the popover to define the color. We have to keep >>> that in mind. >> >> >> Actually, on a tablet, there is no hover, so the "Old/New" previews are >> completely unnecessary there, which means it's fine to put them at the >> bottom. >> > You're right for palette or theme, but not for HSL etc : as you define, > you wan't to see them (while turning the wheel is an example). So I > definitively would put the "Old/New" preview on top for tablets. > As I said, there is no special tablet view, so it means either they're on the top always or never. Given that we're doing a desktop-first design, I'd go for the latter. Trying it on my screen with a finger, it doesn't seem like a huge issue -- I can always see the color preview. It would be good if the preview stretched out across the whole width of the picker, though. > >> THen, once we agree on the global design (actual mock >>> ups), I will make separates desktop (5x5mm squares, "New/Old" at the >>> bottom) and tablet (9x9mm as actual, but with "New/Old" at the top) >>> versions. >> >> >> Be aware that both of these are desktop versions, with the larger version >> appearing in tandem with larger icons. On certain desktops, such as Gnome >> and its derivatives, icons are large by default, and perhaps it might be a >> good idea to make them default on Windows 8+ in the future as well, given >> the OS's touch-first design. (However, it would be good to streamline the >> toolbars first.) >> > If you think gnome desktop or windows in desktop mode would be better with > big tiles, that's OK, but I don't agree, it take really a lot of place > (half the screen), so it means too much time with the mouse to go from the > top to the selected part. > You're forgetting that bigger targets are easier to target. Since we're increasing the size of the targets proportionately to the distance it takes to get to them, according to Fitts's law [1], the time it takes to get to them should remain the same. Large color tiles go with large icons, both of which are the standards on Gnome. On Windows, I don't think it's a good idea to have them large by default yet. > >> About the Old/New icons: I would prefer it if we could pull them off >> without labels and show the color label on both instead. (Perhaps the new >> color could be labelled comparatively if it was similar to the old one, >> e.g. "darker red", "brighter red", ...) >> > COuld be a good idea but I think almost impossible to do ( what f you > added one to R > > and G, and nothing to B ? > The color would be lighter. Or it might classify as a different shade altogether. Initially, the pop-over wouldn't show any New color and, as the user would >> hover over a color, the New section would change dynamically while the Old >> section would stay the same, so there isn't really need to have Old/New >> labels. And if we decide we need them, they should be tiny, like the labels >> on the custom color sliders. >> > Yes I see that. Personnaly I think we need them, has comparative texts, As > I said would be too hard to do., and useless (if you go brighter and > brighter on red, you say brighter red the first time, but what then ? > Still brighter red. You're only comparing with the old color, not the colors you chose in between. We don't need comparative text, but we do need color labels. Right now, it's not clear whether the color label applies to the old color or the new color, as it's centered above. Also, emphasis is put on the "Old"/"New" labels, which are constant, rather than the color label. Because "New" is placed on the color preview, the mind is constantly rereading "New" by looking at the preview. If a color blind person looks at the color preview, he first has to look at the color, then look up at the color name, and he has to do that with each color. It would make more sense to have the name on the preview and the "Old"/"New" labels above, as those never change and therefore don't need to be constantly read. > > On the topic of labels: the "Theme colors" and "Recent colors" labels >> should also match the style of the small labels in custom colors. (The >> style of the label comes from Gnome.) >> > will change that > Cool. > >> Lastly, please align everything to a grid, keeping consistent spacing. >> The padding on the theme colors panel seems uneven. >> > They are already, but that, we don't care. these are are mockup, Mockups > don't even have (and shouldn't to be exact) use a theme (here, it's more or > less gnome one), it should be almost black and white, as if done wit > pencils, as you could do with balsamiq (see there to see what I mean > https://www.mybalsamiq.com/). Of course the real version have to be > aligned. > It's true that first mockups should have relatively low fidelity, to be able to draft them quickly and compare different ideas without focusing on appearance. However, as the design gets more refined, so should mockups gain in fidelity. A tentative design should look like what the final result should look like. When giving the design to the developers, it's best to provide a copy of the mockup with all the metrics. If we designers don't have the right alignment in our final mockups, don't expect the developers to have it in their implementation. [1] http://en.wikipedia.org/wiki/Fitts_law -- Unsubscribe instructions: E-mail to [email protected] Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/design/ All messages sent to this list will be publicly archived and cannot be deleted
