From The Document Foundation Wiki


    • Date/Time: 6:00 pm GMT (supposed start time)
    • Location: IRC, freenode, channel #libreoffice-design


    • alexanderW
    • camillem
    • christoph_n
    • IvanFilho
    • Mirek2


    (18:57:48) christoph_n: Hello everyone!
    (18:57:53) alexanderW: Hi
    (18:58:23) IvanFilho: Just in time :D
    (19:01:07) christoph_n: Well, seems we have to wait until the others arrive ...
    (19:01:12) christoph_n: How are you guys?
    (19:03:22) IvanFilho: I'm ok... You?
    (19:03:26) alexanderW: Fine, how are you? Hope they'll arivve soon, I've got time until 19:15
    (19:03:32) alexanderW: gmt
    (19:04:00) christoph_n: I'm fine as well ... just a bit too much stuff to do. So I hoped to be rather in "reading" mode this evening. Let's see how much there is to read ;-)
    (19:04:21) christoph_n: Do you think its worth to ping the design list now? Maybe some kind reminder mail ... shall I send that?
    (19:04:57) alexanderW: Yes, that would be good
    (19:05:05) IvanFilho: Yes
    (19:06:54) christoph_n: done
    (19:07:22) christoph_n: So, maybe I missed that, what is the goal of the today's discussion? Any topic selected so far?
    (19:08:43) alexanderW: Mirek mentioned a HIG for LibO#
    (19:08:56) alexanderW: a) Converging the keyboard+mouse and touch input -- especially important if
    (19:08:56) alexanderW: we want to target hybrid platforms, such as Gnome 3, Windows 8, and, of
    (19:08:56) alexanderW: course, the Web.
    (19:08:56) alexanderW: b) Avoiding double-click [2] -- fortunately, single-clicking is the
    (19:08:56) alexanderW: standard on the web and on touch-first platforms (Android, webOS, etc.)
    (19:08:57) alexanderW: c) Dialogs -- Could we slowly obsolete dialogs in favor of contextual
    (19:08:59) alexanderW: toolbars? Complex dialogs have no place on mobile UIs, where it's
    (19:09:01) alexanderW: preferable to simply integrate commands into the toolbar, with commands not
    (19:09:03) alexanderW: fitting into the toolbar placed in an overflow menu on the toolbar; it's
    (19:09:05) alexanderW: also much easier and faster to work with commands inside a toolbar than
    (19:09:07) alexanderW: with commands in a dialog window, plus the toolbar allows the user to his
    (19:09:09) alexanderW: changes applied directly, whereas dialog windows tend to cover up most of
    (19:09:11) alexanderW: the document.
    (19:09:50) BS [c831be68@gateway/web/freenode/ip.] hat den Raum betreten.
    (19:10:26) Mirek2 [d5dcf47d@gateway/web/freenode/ip.] hat den Raum betreten.
    (19:10:31) Mirek2: sorry I'm late
    (19:10:36) christoph_n: Hi BS, hi Mirek!
    (19:10:41) IvanFilho: Hi!
    (19:10:44) alexanderW: hi
    (19:10:46) Mirek2: hi
    (19:10:59) Mirek2: have you discussed anything yet?
    (19:11:19) christoph_n: Nope, Alex just posted some proposals you've made ago ...
    (19:11:25) IvanFilho: No, we were just pointing some topics to discuss...
    (19:11:43) christoph_n: I think you're the moderator this evening, right?
    (19:12:26) Mirek2: I'm not sure we need a moderator, but sure I can fill the position
    (19:12:45) Mirek2: First I'd like to talk about the flat icon set
    (19:12:46) Mirek2:
    (19:12:52) christoph_n: Trust me, if you have the right persons on board and its about "design" you will need one ;-)
    (19:13:04) Mirek2: :)
    (19:13:31) Mirek2: Is it ok if I mark the Bold and Italic icons as approved?
    (19:13:31) christoph_n: For later, I'd like to add a small proposal concerning the organization of such meetings via Doodle.
    (19:13:33) IvanFilho: So... about flat icon set, I think the main subject is about the text symbology, right?
    (19:13:47) BS hat den Raum verlassen (quit: Client Quit).
    (19:14:13) christoph_n: Sorry, what was the latest proposal? A a i ?
    (19:14:27) Mirek2: @Christoph -- let's discuss the next meeting at the end of this one, so that we can take this first chat into account
    (19:14:31) BS [c831be68@gateway/web/freenode/ip.] hat den Raum betreten.
    (19:14:39) christoph_n: Mirek2: sure
    (19:14:43) Mirek2: @Ivan: yes
    (19:14:52) Mirek2: lowercase vs. uppercase in particular
    (19:14:55) Mirek2: and also Vegur
    (19:15:35) alexanderW: If we are gonna use the uppercase As, I'd like to suggest that the italic icon should be tweaked
    (19:15:47) Mirek2: it's something that will influence all the forthcoming text-related icons, so it's important we get it right
    (19:15:57) Mirek2: @alexander how so?
    (19:16:05) IvanFilho: Okay, I think the best font is Vegur, of course, since we need a standard.
    (19:16:39) Mirek2: I also think Vegur is best -- especially because it's public domain, so we really don't have to worry about licensing
    (19:16:43) alexanderW: The line on the left is thinner than the one on the right
    (19:17:08) alexanderW: it should be as thick as the right one
    (19:17:28) Mirek2: Could you post a proposal when you have time?
    (19:19:19) BS hat den Raum verlassen (quit: Client Quit).
    (19:19:25) IvanFilho: That's why I prefer the tweaked version.
    (19:19:58) Mirek2: I'll add a different call for proposals for this week and give this topic another week, ok?
    (19:20:22) IvanFilho: It's easier to recognize, the first bold "A" looks like a regular A.
    (19:21:30) IvanFilho: @Mirek Do you mean the text symbology or the entire flat icon set?
    (19:21:32) Mirek2: In this period, please submit your proposals for improvement, and I guess we could make a poll for people to see whether they prefer uppercase or lowercase (as suggested by Maggie)...
    (19:21:51) brenden [c831be68@gateway/web/freenode/ip.] hat den Raum betreten.
    (19:21:57) Mirek2: @Ivan: Text symbology
    (19:22:51) Mirek2: Also, could you give some feedback about the current landscape and portrait mode proposals?
    (19:23:29) alexanderW: Q sketch of what I meant
    (19:23:48) alexanderW: * a sketch
    (19:23:54) IvanFilho: Of course... I personally like your proposal, it's better than mine ;D
    (19:24:31) Mirek2: :D thanks
    (19:25:09) Mirek2: @alexander: Can't see, at least not on the web app
    (19:25:41) IvanFilho: It shows the current state and the "changing" symbology, it's clearer than a single page.
    (19:26:50) alexanderW:
    (19:26:51) camillem [52e2240d@gateway/web/freenode/ip.] hat den Raum betreten.
    (19:27:08) IvanFilho: Also, the borders are nicely similar to the Android main icons, so it looks more native.
    (19:27:48) Mirek2: @Alex: That is better -- submit it to the wiki when you have time
    (19:30:27) alexanderW: I personally prefer Mireks icons for the landscape/portrait mode, since they show that the page is being turned
    (19:30:45) IvanFilho: Yes
    (19:31:01) Mirek2: I'll take a poll on the landscape/portrait mode icons on the mailing list, then, and, if nobody disagrees, I'll mark my proposal as approved...
    (19:31:38) alexanderW: I'm not too sure about the dotted line in the background
    (19:32:02) Mirek2: What line would you suggest? The dotted line is supposed to represent the former state...
    (19:32:21) alexanderW: could you tweak it so that we don't have those 'ls' in the corners?
    (19:33:03) Mirek2: I'll try to
    (19:33:19) alexanderW: fine
    (19:33:36) Mirek2: In the meantime, let's discuss the color picker...
    (19:33:49) Mirek2:
    (19:34:28) christoph_n: @Mirek: As far as I remember, somebody had a question about the "out of scope" ... right?
    (19:34:38) Mirek2: yes
    (19:34:41) christoph_n: May I?
    (19:34:47) Mirek2: go ahead
    (19:34:57) IvanFilho: What about the Font and Highlight color icons? I'd like if you give some feedback :)
    (19:35:12) christoph_n: The reason for creating that page was an offer by Björn M. to help to improve the basic color handling.
    (19:35:34) alexanderW: I like those icons
    (19:35:52) christoph_n: Given the available time, we tried to narrow the focus by avoiding any new UI elements that may cause trouble, because ...
    (19:36:08) Mirek2: @Ivan: I like them, though I'd like to shelve the call for proposals until we know whether to use uppercase or lowercase letters
    (19:37:01) christoph_n: ... this would mean making it work on numerous platforms. We've assumed that this would require too many resources, so that the color handling improvements wouldn't be possible at the end.
    (19:37:01) IvanFilho: Ok.
    (19:37:33) christoph_n: That means: If we assume that devs jump in with toolkit improvements / enhancements, then this "out of scope" is not needed anymore.
    (19:37:49) Mirek2: @christoph: right; my problem was that it reads as it is out of scope to "use with the given UI technology we have so far"
    (19:38:02) christoph_n: Ah!!!
    (19:38:07) Mirek2: while it should be out of scope to "create new UI technology"
    (19:38:14) christoph_n: True!
    (19:38:35) Mirek2: I'll change it, then...
    (19:38:40) christoph_n: Cool, thanks!!!
    (19:40:03) Mirek2: there are a few mockups on
    (19:40:18) Mirek2: + a link to this mockup:
    (19:40:47) christoph_n: Well, the question is: What is the main problem, and what do we want to offer ...
    (19:41:48) christoph_n: For example, the "Tentative Design" in the first link e.g. misses to provide the shading in one row "Black to White" needs 1.5 lines which is strange ...
    (19:41:50) Mirek2: the main problems are that the user can't choose a custom color and that the current color palette is quite bad and chaotic
    (19:42:34) alexanderW: It should be easier to access a certain color or at least one that is similar
    (19:42:39) christoph_n: I'm also for a change in the color palette, but the "bad and chaotic" is rather its representation in a matrix.
    (19:42:42) Mirek2: This is the GSoC idea, btw:
    (19:43:38) Mirek2: @christoph: I just took the Gnome/Tango color pallette
    (19:43:51) Mirek2:
    (19:44:20) IvanFilho: Why shoudn't we use color bars and hex colors? (4th example)
    (19:44:38) Mirek2: Wouldn't have to be ordered as such, though -- I realize it's a bit strange
    (19:45:31) alexanderW: I think users want fast access to specific colors and reuse them, too
    (19:45:33) Mirek2: @Ivan: I'd like to support touch, which means we either make the color squares huge enough to be easily targeted by fingers or that we add enough padding
    (19:45:38) christoph_n: IvanFilho: Why not using color bars? That's more than fine ... but hex colors, seem a bit web-ish. To me, at least the most basic colors should have some naming.
    (19:46:21) alexanderW: Should we go for some selected colors which fit nicely together or some sort of 'rainbow' colors
    (19:46:23) alexanderW: ?
    (19:46:24) Mirek2: a HEX entry box appears under "custom color"
    (19:46:46) Mirek2: @alex: ideally, both
    (19:46:58) alexanderW: ^^
    (19:47:06) Mirek2: the Tango set fits together nicely
    (19:47:06) IvanFilho: Yes, it's web-ish... Since the web standards are becoming default for everything, why not?
    (19:47:10) christoph_n: Mirek2: General question - why touch compatibility, if our whole UI doesn't really support touch? That requires more space, hides more document content ... or should the enlargement only take place if the system provides touch capability?
    (19:47:37) Mirek2: @christoph: our UI is actually not that bad at touch
    (19:47:57) Mirek2: with large icons, toolbars are considerably more usable than MS Office
    (19:47:58) christoph_n: IvanFilho: The users I know still say "red" but "#FF0000" :-)
    (19:48:09) alexanderW: I think the possibility to type a hex value should only be present in the window popping up when clicking 'Add custom color'
    (19:49:08) Mirek2: @christoph: supporting touch is useful for hybrid UIs (Gnome 3, Windows 8) and ports to touch platforms
    (19:49:32) Mirek2: @alex: I agree
    (19:49:51) IvanFilho: @christoph_n Hahaha... of course, but I'm not suggesting to remove the palette, I just think it would be good to put this option on "custom color".
    (19:50:44) IvanFilho: @alex Yes, exactly.
    (19:52:27) Mirek2: It's important to define our goals for the color picker: can we all agree with the goals on ?
    (19:52:40) Mirek2: Anything that should be added?
    (19:54:21) alexanderW: What would the pipette symbol be used for?
    (19:54:46) alexanderW: Should we include such options in the pop-over or the dialogue
    (19:54:49) IvanFilho: To pick a color from any part of the screen, like GIMP.
    (19:54:58) Mirek2: yes
    (19:55:09) Mirek2: although I'd put it under the custom color window...
    (19:55:31) Mirek2: (I'd make some changes to my original mockup)
    (19:55:42) alexanderW: alright
    (19:55:49) alexanderW: that would unclutter it even more
    (19:56:16) brenden hat den Raum verlassen (quit: Quit: Page closed).
    (19:57:15) alexanderW: regarding the lay-out
    (19:57:23) alexanderW:
    (19:57:24) Mirek2: yes?
    (19:57:58) alexanderW: I think we should use a rainbow-like selection like in this mock-up, but with fewer colos
    (19:58:17) alexanderW: and it should be turned by 90 ? counter-clockwise
    (19:58:44) alexanderW: similar to the first mock-up
    (19:58:53) Mirek2: with added padding, for touch?
    (19:58:58) alexanderW: yes
    (19:59:08) Mirek2: fine by me :)
    (19:59:21) alexanderW: what about 'no fill'
    (19:59:29) alexanderW: ?
    (19:59:39) christoph_n: Needs to be added, I think ...
    (19:59:45) Mirek2: I agree
    (19:59:52) christoph_n: How is the currently selected color visualized?
    (19:59:56) Mirek2: how about this -- custom colors on top
    (20:00:36) Mirek2: an "automatic" entry being the first entry in the custom color row, before the "Add" square
    (20:00:51) christoph_n: Would avoid that - the number of custom colors might vary. If they change, then the "default colors" would change their position - which would be bad for the "habituation" of users.
    (20:01:07) alexanderW: agree with christoph
    (20:01:50) Mirek2: yes, but if we allow the user to choose custom palettes, we'll have the same problem, as palettes have different numbers of colors
    (20:02:03) christoph_n: Question: Do the custom colors contain only user defined colors, or also colors that are in the document (e.g. by other users) but not within the palette?
    (20:02:56) Mirek2: good question -- I think it should include colors on the document
    (20:03:26) camillem: @christoph_n : colors used in the document is a nice feature, but that might hinder performances, i'm afraid
    (20:03:33) christoph_n: Mirek2: That depends whether people mainly use pre-defined colors, or whether they heavily use custom colors.
    (20:04:09) christoph_n: Mirek2: The final solution should be to offer colors matching the current "Visual Theme" of the document. Thats a feature we don't have yet.
    (20:04:41) camillem: i think that if you have a way to know the color of the selected element that's already a huge leap forward
    (20:05:17) Mirek2: @camillem -- not really, that's been there for ages
    (20:05:19) christoph_n: camillem: To me, not offering these colors mainly decreases the performance of users ;-) If users get a document created by others (which is quite normal) they usually want to continue the style the original author started. So re-selection of already available colors is a must (to me) - something LibreOffice really lacks today.
    (20:05:54) IvanFilho: It can be in a separated row... There's no reason to put custom colors and document colors together.
    (20:05:56) camillem: @christoph_n : I very much agree
    (20:06:18) christoph_n: Or wait ... aren't they already added at the end of the current palette?
    (20:06:35) christoph_n: Mirek2: Do you remember the exact behavior?
    (20:06:39) alexanderW: Gotta go, guys
    (20:06:51) christoph_n: alexanderW: Bye! Thanks for being with us!!!
    (20:06:55) IvanFilho: Oh, ok
    (20:06:59) IvanFilho: Thanks!
    (20:07:04) alexanderW: Hope we'll have another IRC meeting soon
    (20:07:05) Mirek2: ok, see you later
    (20:07:13) alexanderW: Bye all & Thanks :)
    (20:07:17) alexanderW hat den Raum verlassen (quit: Quit: Verlassend).
    (20:07:53) Mirek2: @christoph -- what exactly are you suggesting? Saving color palettes with documents or generating a color palette based on the colors within a document if there is no palette within the document?
    (20:10:04) Mirek2: @christoph: what behavior do you mean?
    (20:10:18) christoph_n: Mirek2: Rather the latter one - since embedding palettes is a rather new feature (and only or selected applications). But one question to fully get it - the "custom colors" are added by the user, but are not part of a palette.
    (20:10:35) christoph_n: Mirek2: How document defined colors are handled today ...
    (20:11:05) Mirek2: @christoph: techically, they could be saves under a "Custom" palette that the user could then export...
    (20:11:51) camillem: (Have to go too) Bye *
    (20:12:00) christoph_n: camillem: Bye! See you soon ...
    (20:12:00) camillem hat den Raum verlassen (quit: Quit: Page closed).
    (20:12:08) IvanFilho: I really don't know, why don't we test it?
    (20:12:40) christoph_n: IvanFilho: I currently miss a test document ;-)
    (20:12:50) Mirek2: me too
    (20:13:12) christoph_n: Ah wait, maybe I have ...
    (20:13:45) IvanFilho: So... just put some text and some colors, where's the hardness? :D
    (20:14:18) christoph_n: IvanFilho: Time, because I'm already doing some things in parallel :-)
    (20:15:15) Mirek2: In Draw, with a shape, it shows the color with two empty brackets "[]" and allows you to reuse the color for other shapes
    (20:16:29) Mirek2:
    (20:19:03) Mirek2: I think color picker should feature the colors of elements within the document
    (20:19:40) christoph_n: I give up ... changing a palette in Writer trying to force that effect is out of my today's skills ;-)
    (20:19:43) Mirek2: the question is: should it present them as a) a "Document colors" palette, b) under "Custom colors", c) in a separate "Document colors" section?
    (20:21:00) Mirek2: btw, the same thing does not happen with text -- LibreOffice doesn't even indicate the current text color
    (20:22:08) IvanFilho: c
    (20:22:15) christoph_n: If "Custom colors" are meant to survive LibO sessions, then "Document Colors" do have a different quality and should be separate. If "Custom Colors" are just valid for the given document, then we might simply add it to "Custom Colors" (or better: usually the Document Colors would already be there).
    (20:22:17) Mirek2: or is there anything else you wanted to check?
    (20:23:24) christoph_n: Mirek2: Missing "current selection" is something bad in LibO, yes ... (although it works fine in Draw and Impress). Which, by the way, leads to the question where the new toolbar palette should be used.
    (20:24:04) Mirek2: wherever the user might apply a color
    (20:24:18) christoph_n: Mirek2: Fine.
    (20:24:40) christoph_n: Next question: Shall we (finally) harmonize hatches, gradients, ... so this might have impact on the color palette as well.
    (20:25:54) Mirek2: @christoph: yes. Elements that support this should have a tabbed UI in the picker.
    (20:28:00) Mirek2:  good question, though -- should custom colors survive LibO sessions?
    (20:28:35) christoph_n: I'm not sure, since I don't know how users work today ... for example:
    (20:28:46) christoph_n: * we might limit the use of custom colors to one document
    (20:28:53) Mirek2: I feel that perhaps they shouldn't -- the user would collect a lot of colors over the years
    (20:29:09) christoph_n: * we might limit it to the session (so that e.g. Writer and Impress share the same colors in one session)
    (20:29:17) Mirek2: and it's not as simple to delete custom colors
    (20:29:29) christoph_n: * we might store manually added colors forever (like a separate palette)
    (20:29:48) Mirek2: @christoph: wouldn't really feel intuitive, I think...
    (20:29:50) christoph_n: Finally, we need a good way to manage palettes and the custom palette
    (20:30:01) Mirek2: but we should make it easy to create and export palettes
    (20:30:07) Mirek2: yes
    (20:30:37) christoph_n: My personal gut feeling (today, having had some chocolate and some nice Cappucchino):
    (20:31:00) christoph_n: * we should have some pre-defined palettes supplied with LibreOffice (featuring color bars)
    (20:31:30) Mirek2: I agree
    (20:31:36) christoph_n: * users may add own colors in a separate section called "Custom Colors" - technically this may be identical to a pre-defined palette, but the user won't notice that
    (20:31:41) Mirek2: or, better yet, we should have document themes
    (20:32:02) christoph_n: That would solve the question how to manage such palettes - the same, but access to Custom Colors is much faster for users (because no naming needed etc.)
    (20:32:03) IvanFilho: So, Custom Colors will be saved in the user config?
    (20:32:24) christoph_n: * Document colors should be added in a separate section (if there are any other colors)
    (20:32:50) christoph_n: IvanFilho: Don't know yet - maybe a standard palette file saved in the user config path?
    (20:33:09) christoph_n: Mirek2: Yes, document themes would be something desireable ...
    (20:33:45) Mirek2: -- about document themes
    (20:33:46) christoph_n: As I said, my gut feeling :-)
    (20:34:18) Mirek2: I'd prefer if we kept custom colors tied to the document, with an option to export
    (20:34:23) christoph_n: Mirek2: Document themes are great, but don't really fit into the today's model of LibO. Although we had something like that some years ago in Calc :-)
    (20:34:47) IvanFilho: Hm, document themes would be nice
    (20:34:59) Mirek2: having separate custom, document, and palette sections could be too confusing, and the user would have a hard time deciding whether to add to the custom or the document section
    (20:35:21) christoph_n: The user wouldn't be able to add it to the Document Section ... 
    (20:35:47) Mirek2: @Christoph: Why not? They're basically styles for the document...
    (20:36:29) Mirek2: @Christoph: What do you mean?
    (20:36:54) christoph_n: If the user selects a color, it would be part of the current palette or the custom colors (or user colors). Only if a document is loaded featuring different colors, this would appear (although that doesn't yet answer the question what should happen if users switch through palettes, so sometimes previously selected colors aren't visible anymore).
    (20:38:09) christoph_n: Styles are part of a group, but they don't include color palettes. To have themes, I think the styles handling needs to be expanded to handle colors as well. Maybe (I'm not sure) this is even something that needs changes for ODF.
    (20:38:23) christoph_n: But there are enough devs to ask stuff like that ...
    (20:39:24) Mirek2: How about this -- custom colors would be tied to the document and there would be a "Create palette" entry at the bottom of the style dropdown...
    (20:39:24) christoph_n: ... I hope ;-)
    (20:39:59) IvanFilho: So, basically, with the custom colors tied to the document, "colors in the document" will be hidden almost all the time, since the user needs to create a custom color in order to apply a color that is not in the palette
    (20:40:24) christoph_n: IvanFilho: Yep.
    (20:40:44) christoph_n: Mirek2: I'm not sure whether this fits common use cases. Let's take some scenario which happens quite frequently in our office like environment att work ...
    (20:40:51) Mirek2: ...then the user would a) determine where the palette is saved, b) have a place to temporarily create a color and not overload the custom colors section, ...
    (20:41:54) Mirek2: whoops, meant to say palette dropdown
    (20:42:37) christoph_n: Mirek2: You work on a documentation in Writer and you want to have graphics imported from Draw. Each time you use a new color in both applications, you would need to export it again ... but I like the idea of "transforming" a user palette to a palette that would pop up along the LibreOffice palettes.
    (20:43:37) Mirek2: @christoph: not sure I understand. If you imported graphics from Draw, then you'd import their colors with them.
    (20:44:12) christoph_n: Mirek2: Well, I talk Microsoft Office here ... people never copy the drawings, but only Meta File versions ;-)
    (20:44:55) Mirek2: metafile?
    (20:45:14) IvanFilho: I didn't understand... Can you explain better?
    (20:46:48) christoph_n: Stuff like "Enhanced Meta File" or "Windows Meta File" ... instead of having real Microsoft Office Drawing Objects, copying metafile versions (via the clipboard) better preserves the formatting in some cases. So its not the native drawing objects, its a different format. - I just wanted to point out that we use MSO at work but LibO. But maybe more important, it points out that we need to understand the real use cases a bit better.
    (20:47:53) Mirek2: do meta files not copy over the color?
    (20:48:16) IvanFilho: These meta files are only used when the current application does not support the object... That's not LibO's case.
    (20:48:18) Mirek2: isn't that kind of pointless to use them, then, if what you want is primarily the color?
    (20:48:32) christoph_n: Mirek2: As far as I understand, they preserve the color, but the color list isn't touched.
    (20:49:08) Mirek2: that's a LibreOffice bug that should be solved, then
    (20:49:24) Mirek2: but it shouldn't influence the way the picker works
    (20:49:39) Mirek2: ideally, the picker should register all the colors in the document
    (20:50:10) christoph_n: Mirek2: Sorry, I may have confused you ... I just wanted to point out that we need to understand the use cases a bit better, before such a decision about exporting / using palettes is made.
    (20:51:41) christoph_n: For example, people might prefer to have a default palette (like the company color palette, delivered by the company) in parallel to their (few) custom colors. So having only custom colors on a per document basis makes working quite hard ... but that's only one example.
    (20:52:34) Mirek2: yes -- but they should create a custom palette for that
    (20:52:40) christoph_n: (Again our company: our corporate identity features a color palette, but totally misses the color green. So any report / cockpit chart misses the green for "okay" ... that is what many people fix by using their "own" green in a variety of documents).
    (20:52:56) Mirek2: if they do that, then they could also easily import and export it
    (20:53:42) christoph_n: Mirek2: Again, it is just an example for a use case (and we might need more of them). In that case, we might upset users because they have to switch back / forth between palettes - which is as bad as offering them a huge palette like we have today.
    (20:54:57) IvanFilho: That's why I don't like the idea of multiple palettes -- RGBA is much more simpler.
    (20:55:50) christoph_n: IvanFilho: For experienced designers, yes. But normal people simply want to pick a color ... and for few use cases, RGBA (or similar stuff) needs to be provided in advance.
    (20:56:35) IvanFilho: Sometimes the user will need a color that isn't in the current palette, so he will need to switch between palettes frequently.
    (20:56:35) christoph_n: By the way ... running out of time (a bit).
    (20:56:53) Mirek2: On the other hand, though, a user might want to use a custom color once and then never use it again
    (20:57:35) Mirek2: if we keep custom colors persistent, it might get pretty full pretty fast
    (20:57:36) christoph_n: Mirek2: Also valid - but that is why we should work on use cases to weight such decisions.
    (20:58:41) Mirek2: right
    (20:59:41) Mirek2: it sounds like a persistent "custom colors" section would be useful for having a few persistent custom colors appended to the default color palette -- how about we make adding colors to the palette easy instead?
    (21:00:37) IvanFilho: The user should have a quick option to delete a custom color... Maybe a simple drag & drop to outside.
    (21:01:07) Mirek2: that's too unintuitive
    (21:01:20) Mirek2: and could be easily done by accident
    (21:01:29) christoph_n: Sorry guys, running out of time ... may I go and we continue in the next chat or on the list?
    (21:01:57) Mirek2: ok
    (21:02:15) IvanFilho: Unintuitive?
    (21:02:16) Mirek2: concerning the next chat -- should it be next saturday or sometime during the week?
    (21:03:19) christoph_n: Mirek2: Can't say in advance, since we might be on the road - but I'll join if possible (at any time). So would it be better to ask on the list so that the others are informed as well?
    (21:03:31) Mirek2: ok, I'll ask
    (21:03:57) IvanFilho: Maybe we can chat during the week, when do you guys have time?
    (21:04:16) christoph_n: IvanFilho: You can't see that this feature works ... like the "Awesome Bar" of Firefox supports deleting entries by pressing "DEL". People need to be able to see what is possible, otherwise the feature is unhelpful for many.
    (21:04:29) Mirek2: I'll put up a Doodle poll
    (21:04:54) christoph_n: IvanFilho: By the way, for some it might even mean "Apply the dragged color to the location the user released the mouse button".
    (21:04:57) christoph_n: Mirek2: Thanks!
    (21:05:28) Mirek2: @ivan: it's behavior that I've never come across before, and I don't think we could implement it consistently. For example, the user shouldn't be able to delete the automatic entry and probably shouldn't be able to delete colors from palettes this way either
    (21:05:29) IvanFilho: christoph_n: You're right... I didn't realized that.
    (21:05:54) christoph_n: Mirek2: Finally, the topic I wanted to talk about initially. If you close the poll after a few days, then people might be aware what time was chosen - and they can select their time zone to get their local time. That's pretty handy ... we've used that for some other chats.
    (21:06:07) christoph_n: Mirek2: Another question - is there any place to conserve the today's discussion?
    (21:06:18) IvanFilho: Mirek2: Mac's dock bar and apps like RocketDock have this shortcut to delete icons
    (21:06:34) christoph_n: Design/Meetings/2012-03-24 ???
    (21:06:36) Mirek2: @christoph: not yet
    (21:06:50) Mirek2: @christoph: fine by me
    (21:06:51) christoph_n: Mirek2: Okay, then I'll add that page - if you both agree.
    (21:07:01) Mirek2: agreed
    (21:07:04) IvanFilho: ok
    (21:07:13) christoph_n: Thanks ... wish you both a nice evening!
    (21:07:16) Mirek2: "If you close the poll after a few days, then people might be aware what time was chosen - and they can select their time zone to get their local time." -- what do you mean?
    (21:08:33) christoph_n: Mirek2: I observed that a poll can be closed - you can do this by selecting the most appropriate time. If that is done, Doodle provides the option to convert the time according to the visitor's time zone. But I don't know if thats a special poll type (time and date, but pizza flavor ...).
    (21:08:48) Mirek2: @Ivan: yes, but Mac's dock and its copies have been criticized for this behavior; my mom uses a Mac and she keeps accidentally removing icons
    (21:09:26) Mirek2: @christoph: might be confusing, though -- the user might not know if it's in his timezone or in GMT
    (21:09:37) Mirek2: I'd prefer to have GMT only
    (21:09:41) christoph_n: Mirek2: Trust Doodle, the visualization is quite good :-)
    (21:10:08) IvanFilho: It's not that hard to realize it's GMT
    (21:10:08) christoph_n: (I hope I don't regret the last sentence if people don't attend the next chat ...)
    (21:10:18) christoph_n: Okay, see you ... bye!
    (21:10:47) Mirek2: btw, do you know how to enter times automatically?