Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index


Hi Mirek

2013/3/24 Mirek M. <mazelm@gmail.com>

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)

On Sun, Mar 17, 2013 at 6:23 PM, Kévin PEIGNOT <peignot.kevin@kpeignot.fr>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.



<Issa> New should be on the left and Old on the right.
        I don't really see why (for me, history (old) is on the left,
future
(new) on the right) but it's done;


Perhaps this makes more sense for RTL cultures?
New on the right makes more sense to me, not only because of the way my
culture draws time, but also because it's more typical to have the constant
part at the beginning and the variable part at the end.

As I said, I really don't care for this. Both places have good arguments,
but not enough to say it's definitively better than the other



<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



<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

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 ?



<Mirek> Please include a label of the color for the colorblind.
        Almost done. I didn't included the label for RGB and HSL, because
I
really don't see how we could decide the name of colors that have so few
diffenrences between them (except RGB of course, which is already at the
top, or we would have 300 red, 300 blue etc etc).


We could assign a name to ranges in hue, saturation, and lightness.

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



-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)



On Mon, Mar 18, 2013 at 2:24 AM, Kévin PEIGNOT <peignot.kevin@kpeignot.fr>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.



 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



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 ?

 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 ?


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


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.

Kévin

-- 
Unsubscribe instructions: E-mail to design+help@global.libreoffice.org
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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.