Design/Meetings/2013-04-20

Attendees

 * issa
 * Computer1
 * mirek2
 * medieval

Topics

 * Calc flat icons
 * UI EasyHacks
 * Color picker
 * Master slides custom animation

Log
[18:18] hi [18:18] <@issa> hi [18:19] how is the icon work going? [18:20] <@issa> I stopped for a while because I was busy but I'm back at it [18:20] <@issa> currently working on Calc icons [18:20] ok [18:21] <@issa> https://raw.github.com/libodesign/flat-icons/master/sc_small.png [18:21] <@issa> maybe we should wait 15 mins to see if anyone else is coming? [18:22] mirek just wrote a letter about UI design into mailing list [18:23] long letter...i am reading it now [18:23] <@issa> I'll do that too [18:25] I would look up the grid lines icon [18:25] I think you should make border width smaller [18:29] <@issa> like this? http://i.imgur.com/TVam1Rr.png [18:30] i think so [18:30] <@issa> I wasn't sure which one to use [18:30] <@issa> but the thick lines sort of represented the sheet itself rather than a bunch of cells [18:33] https://www.dropbox.com/s/13i6zs7ivz93h49/ixe.png [18:34] <@issa> yes I've seen this one :p [18:36] i think both show well what they are doing [18:36] it is your decision there [18:37] <@issa> notice how the current one has shaded "header" cells [18:39] ye [18:41] (i am going to shop, back in half hour, i hope here is more people then) [18:41] <@issa> take your time [18:56] == mirek2 [4e66c274@gateway/web/freenode/ip.78.102.194.116] has joined #libreoffice-design [18:56] hi guys [18:56] <@issa> hi mirek [18:57] <@issa> (medieval is away, he should be back in 15 mins) [18:57] have you already started the meeting? [18:58] <@issa> not yet [18:59] <@issa> I just told him I was working on Calc icons https://raw.github.com/libodesign/flat-icons/master/sc_small.png [19:00] <@issa> and he told me the last icon needed narrower borders like this http://i.imgur.com/TVam1Rr.png [19:02] I don't think I agree [19:02] actually, I think the icon's lines aren't thick enough [19:02] the icon doesn't really fit well with the rest of the theme [19:03] <@issa> I can't make the inner grid thicker [19:03] <@issa> and the outer border is already 2 px [19:03] what does the inner grid represent? [19:04] are there really 9 squares needed? [19:04] <@issa> the calc grid [19:04] the table icon fits them ideally, imho [19:04] <@issa> no, could do with four [19:04] that would do [19:05] you could have the lines thick, but dotted [19:05] <@issa> the table icon has 9 as well https://raw.github.com/libodesign/flat-icons/master/sw_small.png [19:05] yes, I was saying that it's possible to have thick lines, because the table icon has them [19:06] but we should definitely differentiate the cell icon from the table icon [19:07] <@issa> I guess so [19:11] I'm just wondering -- how did you get involved with LibreOffice? [19:12] what draws you to open source software? what motivates you to volunteer? [19:16] <@issa> well I'm not exactly volunteering [19:17] not even with the icons? [19:17] <@issa> I'm working at the national FOSS program here in Saudi Arabia [19:17] oh, ok, cool :) [19:17] could you tell me more about it? [19:18] is there a website where I could read about it? [19:18] <@issa> http://blog.documentfoundation.org/2012/09/13/libreoffice-localization-program-in-saudi-arabia-announced-to-enhance-arabic-language-related-features/ [19:19] <@issa> we are supposed to work on right to left bugs, but working on design is more fun :p [19:20] :) any developers among you? [19:20] would be great if we could get some of our easyhacks fixed [19:20] could bring the UX forward [19:21] hi, am back [19:21] <@issa> welcome back [19:21] <@issa> mirek2: we are all developers [19:22] oh, ok [19:22] do you think there'd be some interest in working on the easyhacks, then? [19:22] <@issa> we never added features though, only fixing things [19:23] <@issa> yes, we are interested on fixing the ui [19:23] <@issa> *in [19:23] once the code pointers are added, though, it should be relatively easy to do [19:23] <@issa> I guess so [19:23] :) great [19:25] <@issa> so lets go back to the icons, shall we? [19:25] sure, go ahead [19:26] to me now width 2 px border the icon look like out of space, don't fit with rest of icons [19:27] <@issa> mirek was saying the opposite [19:27] i read it [19:27] i think its about the lighter frame color [19:29] I also don't think the proposed "borders" icon fits in [19:29] perhaps try both with a 4x4 grid? [19:30] <@issa> what about the merge icon, it wouldn't work in 4x4 [19:31] <@issa> (the one next to the alignment buttons) [19:32] that can be done with a 3x3 grid [19:32] just like the icons we use now [19:33] or you could try a 3x2 grid [19:33] <@issa> so I should only change the borders icon? [19:34] as well as the grid lines icon [19:35] however, I think the problem with that icon was that it was highlighting an irrelevant aspect of the icon [19:35] in that icon, the cells are relevant, no the border [19:35] yet the border was thicker [19:36] it should be the other way around [19:36] <@issa> hmm [19:41] still there? [19:41] ignore that, I just needed to check if I wasn't disconnected [19:48] any progress? [19:53] <@issa> just a second [19:54] <@issa> http://i.imgur.com/jSfBQxe.png [19:55] <@issa> this is what would happen if we had the same icon as tables but without highlighting the border [19:55] <@issa> (the 4x4 grid couldn't be the same size obviously) [19:57] much better, imho [19:57] and I don't think there's need for the 4x4 icon [19:58] anymore, with the changes you made [20:02] medieval: what do you think? [20:03] as I said before I like these: thicker borders [20:03] thinner* [20:03] so you like the proposed icons? [20:03] yes [20:05] me too [20:05] so I guess let's use those [20:05] should we move onto another topic? [20:07] <@issa> if the rest of the icons are ok then yes [20:07] <@issa> (there's these two also :p https://raw.github.com/libodesign/flat-icons/master/sc_small2.png ) [20:07] just a note about the f(x) icon [20:08] <@issa> yeah? [20:08] I think the x should be smaller, to resemble a subscript [20:09] <@issa> it's not a subscript [20:10] hm, I'm trying to see where the symbolism comes from [20:10] the standard notation is f(x) if anything [20:10] in any case, I guess it's good as it is [20:11] in Excel, it's presented as a subscript: http://www.excel-formulas.com/mathematical-excel-formulas/images/excel-substruction-formula.gif [20:12] <@issa> but it looks too small when the parentheses are there [20:12] right [20:12] <@issa> still doesn't look like a subscript to me :p [20:12] it's probably best to keep it as is [20:12] ok :) [20:13] <@issa> also it's fx in Tango [20:13] <@issa> just one more question about these http://i.imgur.com/jSfBQxe.png [20:13] <@issa> which one for the show/hide grid icon? [20:14] I like the second one from the top [20:15] though any one from the three is fine IMHO [20:15] second [20:15] <@issa> yes second seems to be the clearist [20:15] third maybe [20:15] first resembles borders [20:17] <@issa> now we can move on to another topic [20:18] alright [20:18] any topics you would suggest? [20:18] if not, we can talk about the color picker [20:18] mirek i saw you wrote great letter to mailing list [20:19] what are your thoughts on it? [20:20] <@issa> I agree with most of it, although I haven't been keeping up with the thread [20:20] i am in the same line with you [20:20] mirek* [20:20] cool :) good to know we are in the same boat [20:21] * Nonconformity. The ribbon is alien to all platforms except Windows. macOS requires a menu bar for each application. [20:21] I think it hard to make ribbon to be used bt linux users [20:21] is* by* [20:22] yes, sort of [20:22] <@issa> I don't think so, the menu bar will stay only the icons will be replaced [20:22] we would have to use our own UI elements and try to make them fit with the environment [20:22] why don't you introduce you citrus UI to them, or as we agreed it is kind of our "goal" [20:23] actually, the UI proposal is quite outdated and not really presentable [20:23] it was more of a UI brainstorm/experiment than something to be presented as a vision [20:24] ok [20:24] and rather than try to get people to agree with the vision, I'm just trying to encourage small changes [20:24] <@issa> so how shall we address the UI now? split it into specific problems with a whiteboard for each [20:24] well, here's how I imagine the roadmap: [20:24] it all depends on the EasyHacks [20:25] https://wiki.documentfoundation.org/Design/Blueprints [20:26] <@issa> well I'd say the pretty hacks are a bit subjective [20:26] is somebody here usng ubuntu? [20:26] I'm on a borrowed laptop using macOS [20:26] <@issa> medieval: I do, but not atm [20:26] on my own netbook that's being repaired, I have elementary [20:26] why do you ask? [20:26] is the hud usable? [20:27] (i use eOS and win7 myself) [20:27] somewhat usable, but not discoverable [20:27] <@issa> what do you mean? the shell? [20:27] it would be nice addition [20:27] it would [20:27] http://www.youtube.com/watch?v=w_WW-DHqR3c [20:27] macOS has a similar feature [20:28] only in the help menu [20:28] also works for all apps with a menu bar [20:28] <@issa> oh, didn't know they call it that [20:28] <@issa> yes I think that's why menus aren't going anywhere [20:28] www.youtube.com/watch?v=7IP__mFL7d4 [20:29] I think they are going away [20:29] Canonical is actually planning to broaden the scope of the HUD outside of menus [20:30] <@issa> well not in the near future [20:30] issa, how much to you know about different widget toolkits? [20:30] or mirek [20:31] why do you ask? [20:31] we can't really move to GTK or Qt yet -- that would be too much effort [20:32] but doesn't the effort pay itself? [20:32] not really, at least from my talks with the devs [20:32] basically, I was told that it would take a year of work from every dev working on LibreOffice [20:32] all work would be suspended for a year [20:33] whereas VCL, though not excellent, is still workable [20:33] and considerably easier to just maintain [20:33] <@issa> medieval: I know pretty much nothing [20:33] ok [20:34] however, as part of the effort to bring LibO to Android and iOS, the front-end is being separated from the back-end [20:35] which means that, hopefully, in the not-so-distant future, it might not be so hard to create a custom UI for editing documents using any desired toolkit [20:36] getting back to the topic of menus: LibreOffice is almost definitely keeping its menus, but, in the future, it might hopefully be possible to hide them [20:37] and that should be the default for platforms like elementary and of course for touch-first operating systems, which discourage the use of menus [20:38] <@issa> great [20:38] (asking about hud, I wated to know if it is working with libreoffice) [20:39] I assume it will work with versions that integrate with Ubuntu's application menus [20:39] it works on macOS [20:39] <@issa> seems like it http://iloveubuntu.net/pictures_me/libreoffice%203.6.2%20hud%20support1.png [20:39] ok [20:40] link doesen't open [20:41] but point taken [20:41] <@issa> I dunno, one of the first google images results [20:42] www.iloveubuntu.net/libreoffice-362-landed-ubuntu-1210-full-hud-support-and-strengthened-appmenu [20:43] we got a bit off topic -- should I still flesh out what I imagine to be the roadmap, or should we move onto another topic? [20:43] <@issa> mirek2: flesh out the roadmap [20:43] (i think i need to move to unity again which i don't like) [20:44] roadmap: [20:44] "Page selection" coupled with "Page toolbar" will allow users to forgo using the Page dialog for the most common page formatting [20:44] <@issa> (medieval: I would like to implement the hud in Gnome one day) [20:45] <@issa> sounds great [20:45] "Hidden Items Menu" would allow us to streamline toolbars while adding more commands [20:46] <@issa> ok [20:46] (i.e. narrow down the selection of the icons shown by default, add more to the menus) [20:47] the menu could include a button to the relevant dialog, thus making going through the menus less necessary [20:48] (office have it from 2003?) [20:48] that menu, along with right-aligned toolbars, would allow us to make something similar to Chrome's Tools menu or elementary's appmenu [20:48] https://wiki.documentfoundation.org/Design/Whiteboards/Toolbars#Proposal_by_Mirek2 [20:49] medieval: really? are you sure that the Office implementation doesn't just toggle the visible buttons? [20:50] (i don't 2003 now, not sure) [20:50] ok [20:51] in any case, this AppMenu would eventually allow the user to forego the menubar altogether [20:51] and hide it, thus fitting into platforms that discourage against the use of menus [20:51] (i think it have the same system as we have now) [20:52] oh, ok [20:52] <@issa> it's still would be weird having new open etc on the far right [20:53] well, we'll cross that bridge when we come to it, I guess [20:53] <@issa> perhaps [20:53] that's the problem with trying to make any UI changes [20:53] the change is well-reasoned, though [20:53] <@issa> true [20:53] and for you, it would be on the far left [20:53] (for RTL languages, I mean) [20:54] <@issa> I don't actually use RTL interfaces [20:54] oh, alright [20:54] so, as I see it, those four are the most important EasyHacks [20:54] <@issa> also I guess deciding what items goes there would be another task for later [20:54] the rest is just smoothing out the experience [20:54] yes [20:55] that's another reason why I'm avoiding proposing a whole UI change [20:55] people get caught up in the nitty-gritty [20:55] <@issa> just a second [20:55] <@issa> I don't really agree with the right-aligned toolbars [20:55] <@issa> they are pretty confusing [20:56] how so? [20:56] <@issa> all toolbars are left-aligned, you want to us to have both? [20:57] yes [20:57] as i understand [20:57] ? [20:57] yes, sort of [20:58] they wouldn't be as flexible, though [20:58] i.e. they would always stick to the side [20:58] you wouldn't be able to move them freely along the bar as you can with left-aligned toolbars [20:58] which I would argue is a good thing -- it doesn't allow you to create gaps [20:59] I don't think it's good that we allow gaps with the current toolbars [20:59] <@issa> I prefer office like "special" toolbar [21:00] that would be unnecessarily complex, IMHO [21:00] <@issa> http://www.addintools.com/documents/excel/images/paste-sepcial/shot-excel-paste-special-toolbar-698-218.png [21:00] the easiest way to implement right-aligned toolbars, as Kendy told me, would be to simply set the toolbar position to some kind of large number [21:00] <@issa> the ones on top next to the program icon [21:00] so that it's always at the right [21:01] issa: yes, as I said, unnecessarily complex [21:01] <@issa> yes but there aren't clear distinction between them and the normal icons [21:01] there shouldn't be [21:01] they are normal icons [21:01] <@issa> but they aren't in a normal toolbar [21:01] only the toolbar sticks to the right of the window [21:01] it is a normal toolbar [21:01] it just sticks to the right of the window [21:02] you're used to icons aligned to the right from Chrome or Firefox, right? [21:02] <@issa> not when there are icons aligned to the left next to them [21:02] LibreOffice can't handle flexible spaces, so this is the next best thing [21:03] issa: icons are not aligned to the left next to them [21:03] it's just the toolbar that is always at the right [21:03] the contents are not affected [21:03] <@issa> I know [21:03] <@issa> but there aren't clear visual distinction between toolbars [21:03] why should there be? [21:04] there is a separator at the beginning of each toolbar [21:04] <@issa> I dunno they just feel wrong [21:05] <@issa> I think having a simple difference as a different background (ala office icons) would help [21:05] <@issa> *as simple a [21:05] but these toolbars are normal toolbars [21:05] <@issa> they are sticky toolbars [21:06] <@issa> or presistant toolbars [21:06] they're meant not to stick out [21:06] they're not persistent [21:06] they can be removed [21:06] <@issa> really? why do we need them then? [21:08] it boils down to spacial orientation and symmetry [21:08] when all toolbars are left-aligned, there's a bunch of icons to the left and none to the right [21:08] it makes the left side feel heavy and noisy, whereas the right side feel empty [21:08] <@issa> oh [21:09] <@issa> then this is the wrong solution to the problem [21:09] what is the right solution? [21:09] <@issa> justifying icons is the right solution [21:09] how would that work? [21:09] <@issa> (as in equal space between icons) [21:10] I disagree [21:10] then you're faced with spread out icons on large monitors [21:10] and you can no longer take advantage of your muscle memory when moving between commands [21:11] as the space between commands keeps changing [21:11] <@issa> true [21:11] <@issa> but still I don't think that's the solution [21:11] it would also significantly alter the UI when a contextual toolbar would appear [21:11] other applications do it [21:11] <@issa> maybe the problem just isn't there [21:11] it's quite common in elementary http://elementary-art.deviantart.com/ [21:12] what do you think about e.g. http://spiceofdesign.deviantart.com/art/Writer-Concept-351501580?q=favby%3Aelementary-art%2F45954099&qo=3 ? [21:12] where issa some icons are on the right, some on the left [21:13] or about iWork pages: http://images.appleinsider.com/new-iwork-070807-1.png ? [21:13] <@issa> it's uncomfortable [21:13] here's a more current screen: http://www.wyodor.net/_Demo/MyHouse/Pages_Landschap_01.png [21:13] <@issa> eOS seems to have them in the titlebar which is even more unorthodox [21:13] really? well, you wouldn't be required to use them [21:14] issa: not right now [21:14] though they're planning to [21:14] <@issa> iWork seems to have the same problem as justification [21:14] I posted an older version [21:14] <@issa> I guess we should have justification on toobars level then [21:14] the newer one aligns left, center, and right [21:15] here's a screenshot from an actual elementary app: http://www.linux-ai.com/wp-content/uploads/images/elementary%20OS%20/elementary-luna-scratch-text-editor.png [21:15] <@issa> the settings makes sense, the other one not so much [21:15] also, iWork can afford to justify toolbars, as they don't change and aren't customizable [21:16] what browser are you using, btw? [21:16] <@issa> firefox [21:16] basically any browser I can think of right now has some buttons aligned to the right [21:17] firefox has the bookmarks and home buttons there [21:17] <@issa> let me look up the default ui [21:18] <@issa> well seems like all icons are right-aligned [21:18] it also plans to move the application menu to the right https://wiki.mozilla.org/Features/Desktop/Panel_Menu [21:19] issa: previous and next are left-aligned [21:19] <@issa> previous and next are merged into the address bar [21:19] on non-Linux platforms [21:20] on Linux, they appear as toolbar icons [21:21] <@issa> I don't use the default interface but if you remove the address bar wouldn't everything move to the left? [21:21] on Android, it's a standard to have right-aligned icons [21:22] issa: well, Firefox uses flexible spacing and a flexible address bar [21:22] it doesn't split up icons into individual toolbars, but rather has a single toolbar [21:22] <@issa> then it's not a fair comparison [21:22] you can align items to the right by adding a flexible space [21:22] <@issa> also I removed the address bar and the icons all went to the left [21:22] I wasn't comparing the implementation, I was comparing the layout [21:22] <@issa> so technically nothing is aligned to the right [21:23] <@issa> you can't compare the layout [21:23] <@issa> libo has tens of icons [21:23] my point being that right-aligned icons are quite normal [21:23] <@issa> I disagree [21:24] <@issa> all I understand from your right aligned mockup is that you want that toolbar to stick out [21:25] no, I want it to be in a separate area from the contextual toolbar [21:25] the idea is that, for commands relating to the selection, the user will move his eyes and mouse to the left [21:26] <@issa> I know that now, but that isn't what I get from the mockup [21:26] for commands relating to the document or application as a whole, static commands, the user will move his eyes to the right [21:26] issa: sure, the mockup was done hastily and on a netbook [21:26] <@issa> it's the idea itself [21:27] <@issa> also why would the left-aligned icons be below the right-aligned ones? [21:27] <@issa> aren't you giving them priority that way? [21:27] that's another topic [21:28] I would prefer to give them priority, but possibly the best solution would be to allow assigning a z-order to toolbars [21:28] <@issa> mirek2: that would make them even more confusing [21:28] <@issa> I think we need to discuss the topic as a problem and solution in the mailing list [21:28] or perhaps to just give toolbars equal space [21:29] issa: the initial implementation would really be just as simple as positioning the toolbar to the far right [21:30] sure, feel free to start a mailing list thread [21:30] <@issa> mirek2: still we should implement it if people agree with it [21:31] <@issa> *we should only [21:31] right [21:31] <@issa> great, sorry if I sounded harsh :) [21:31] no worries :) [21:31] should we move to another topic? [21:31] color picker, perhaps? [21:32] <@issa> mirek2: maybe you should post the roadmap first and then I reply to it [21:33] <@issa> sure [21:33] issa: I thought we were only talking about the right-aligned toolbars? [21:33] the EasyHacks were already approved once, several weeks ago [21:34] they don't come just from me, we had a general discussion about EasyHacks and the proposed ones are what we agreed on [21:34] they were also approved by a dev I met with [21:34] Kendy, a LibreOffice dev [21:35] so I'd prefer not to have to reevaluate all of them again... [21:36] <@issa> mirek2: ok [21:37] but I'm definitely OK with a thread or two about a specific EasyHack [21:38] I hope that didn't sound too harsh [21:39] new topic? [21:39] color picker? [21:39] or other suggestions? [21:40] <@issa> color picker is good [21:40] <@issa> mirek2: it's alright [21:40] <@issa> mirek2: I meant just posting the roadmap first [21:42] the thing is, it's not an official roadmap and LibO's UI may take any turn [21:42] this was just something I imagine [21:42] I might post it, we'll see... [21:42] <@issa> yes you need to propose it as a roadmap [21:42] <@issa> (as in not keep it just in here) [21:43] I'll think about it [21:43] I certainly don't want to sound like it's this roadmap or no roadmap [21:43] I want everyone to have a say [21:44] not to force people to a roadmap set out by me [21:44] <@issa> yeah you have to work on phrasing it [21:44] yeah, I'll think about it [21:45] I'd also like to avoid seeming like an unnecessary thought piece that doesn't belong on the ML [21:45] I want it to have a point [21:45] ... [21:45] in any case, color picker [21:45] https://wiki.documentfoundation.org/Design/Whiteboards/Color_Picker [21:45] <@issa> yes go on [21:45] as I said on the ML, I'm not happy with certain aspects of the current tentative design [21:47] they should go on "Custom colors", where the rest of the "static" colors are [21:47] Recent colors shouldn't go on the "Theme colors" panel, as, unlike theme colors, they are not variable [21:47] right? [21:47] <@issa> umm no [21:47] <@issa> they should be there for ease of access [21:47] <@issa> maybe on a different panel below the theme colors [21:48] <@issa> (have a seperator between them) [21:48] then we have a problem in separating out static colors [21:48] the thing is, the Recent colors won't include Theme colors [21:48] <@issa> yes [21:48] <@issa> but don't look at it this way [21:49] and if you don't use the Custom colors tab, you won't ever see anything there [21:49] <@issa> look at it as basic colors and advance colors [21:49] if, on the other hand, you do use that panel, you will want to see the recent colors that you've used before [21:49] <@issa> basic colors should include: automatic, theme colors and recent colors [21:49] issa: that's not what is is at all [21:50] you use theme colors if you want your document to follow a certain theme [21:50] you use custom colors when you need things to have a constant color [21:50] <@issa> or if you are simply using the default settings [21:50] e.g. in Draw you are likely to keep the Custom colors panel open, whereas in Writer, you are likely to keep the Theme one open [21:51] by default, the picker should open in the panel you were in last [21:52] <@issa> then the default custom colors panel tab should be the standard palette tab [21:52] also consider that a user who uses custom colors frequently and probably has that panel by default would really miss a recent colors section [21:53] issa: I guess that could be done, but why? [21:53] if you're a designer, you'll likely want to be able to refine your colors [21:53] <@issa> what if I want that one certain custom color? [21:54] <@issa> actually scratch that, what if I want to use that one certain custom color alongside my theme colors? [21:54] I'm not saying we should remove the Palette tab, I'm just not sure if that's a good default [21:55] <@issa> then we'll need the recent colors on the normal or theme panel [21:55] we should definitely save the last open tab in the panel, though, so that the user gets back to the tab he uses [21:55] <@issa> lets say my organization uses a fully green theme [21:55] issa: why? recent colors only make sense once you've used the custom colors panel anyway [21:56] issa: ok [21:56] <@issa> but I have to use red to convey errors or highlight things [21:56] <@issa> I won't need any other color besides red and the theme [21:56] that runs a bit counter to the idea of a theme [21:56] <@issa> do I have to switch panels everytime? [21:56] <@issa> well this will happen a lot, most people would never change the theme [21:57] a theme needs to have contrasting colors [21:57] <@issa> still, regardless of how contrasting the colors are sometimes you just need red [21:58] theme colors and static colors have different use cases [21:59] theme colors you use when the color itself isn't relevant [21:59] for text, for charts, etc. [21:59] static colors you use when you're drawing something [21:59] an apple, a tree, a building [22:00] unless you're constantly writing and drawing, though, I doubt you'll need to switch between the two very often [22:00] it's certainly not a good idea to mix static and theme colors [22:00] <@issa> what if I want to add a heart shape and make it red? [22:01] <@issa> it's either that or give me quick access to the colors I specifically chose [22:01] if these shapes are meant to fit stylistically into the document, you should use a theme with a red color [22:01] <@issa> no, I'm using my organization theme which has contrasting colors but not red [22:01] if red itself is the important factor, no matter what the document looks like, you should use static red [22:02] <@issa> thus I need to quickly access it [22:02] however, you should not mix theme colors and custom colors [22:02] e.g. if you put text into that red heart, make sure it also uses a static color [22:02] <@issa> but people will do that [22:02] if you use a theme color for that and later on change the theme, that text might be unreadable later [22:03] <@issa> so give me quick access to my static colors [22:03] issa: we should certainly discourage it [22:03] issa: but you have quick access to static colors [22:03] though only when you're not working with theme colors [22:04] as it's dangerous to mix the two and therefore we should discourage it [22:04] <@issa> imagine a scenario where I'm 100 pages into a document [22:04] I explained why it's dangerous above [22:04] right [22:04] <@issa> and I need to use red in the next 20 pages [22:04] <@issa> I wouldn't change the theme [22:04] <@issa> but I would need red next to my theme colors [22:05] if red isn't your theme color, I don't see why you'd need to create such an inconsistency [22:06] it would stick out like a sore thumb [22:06] you do have 6 accent colors to choose from -- why red? [22:06] <@issa> because I'm talking about the color red [22:06] <@issa> or simply drawing figures including hearts [22:07] let me give a counter-example: [22:07] let's say you have used red in those 20 pages that's not in the theme colors [22:07] and you intended for red to be distinct from the theme colors [22:08] your company then changes its theme colors and you automatically retheme the document [22:08] unfortunately, those new colors contain red, meaning the intended contrast is lost [22:08] and the red has lost its function [22:08] thus, if you use it to highlight errors, that won't be visible anymore [22:09] what the correct practice would be is to have a special theme color for errors [22:09] <@issa> no I didn't use it for the contrast, I just wanted it to be red for whatever reason [22:09] and if you're drawing, like you said above, you should only use custom colors [22:10] <@issa> what if I'm constantly drawing and formatting text/charts? [22:10] imagine if the blue sky you had in your drawing turned red because you changed the theme [22:10] <@issa> no no no [22:10] <@issa> I'm not saying have red as part of the theme [22:10] <@issa> just make it appear there [22:10] I know [22:11] and I'm saying it's dangerous to mix theme colors and custom colors [22:11] <@issa> it should be clearly labeled as a custom color or non-theme color [22:11] it doesn't matter though [22:12] it just encourages bad habits if it's on one panel [22:12] say you draw a person using a theme color and then, within him, a heart with a custom red color [22:13] if you then change the theme and the theme color you happened to use for the person turns red, it will render the heart invisible [22:14] if you mix theme and custom colors in text, a theme color you use for mistakes could later be the same color as the custom color you used for text [22:14] thus making it appear that text is a mistake [22:14] <@issa> these are the users problems [22:15] https://wiki.documentfoundation.org/Design/Principles [22:15] ux-error-prevention [22:15] "Interfaces should proactively try to prevent errors from happening." [22:15] we should not encourage bad practices [22:15] <@issa> hmmm [22:16] <@issa> but that is quite annoying [22:16] if a person really needs to use a custom color among theme colors, he can resort to styles [22:16] use a custom color there [22:16] and since it is a single custom color, that should be the best way to do it [22:17] if it was a bunch of custom colors, the Custom color view would fit better with the user's needs [22:17] <@issa> hmm [22:18] issa: recent colors? [22:18] <@issa> I guess that person should just use the standard palette in the custom colors [22:19] yeah, definitely [22:20] <@issa> although I still think most people wouldn't get that easily [22:20] we just need to communicate the point of themes better [22:21] I think most people don't understand that one can change themes [22:21] MS Office does a very poor job, as it's much harder to access custom colors than theme colors [22:21] <@issa> even if they do most people won't bother to [22:21] <@issa> https://wiki.documentfoundation.org/File:I_colorpicker.png [22:22] therefore even artists can resort to theme colors, even though they want custom ones [22:22] <@issa> my idea was to have both standard and theme close to each other [22:22] that would eliminate precise custom colors, though [22:22] which is something I'd really hate to do [22:23] I mean, make it harder to use, not eliminate [22:23] <@issa> not really [22:23] <@issa> https://wiki.documentfoundation.org/File:I_colorpicker2.png [22:23] given that custom colors are meant mostly for drawings, precise control is quite important [22:23] <@issa> you can still change the panel [22:23] <@issa> same way it's currently in the tentative design [22:25] that's a bit confusing, though [22:25] as "more colors" gets rid of theme colors [22:25] not really something I would expect [22:26] in that regard, I prefer the current tentative design [22:26] except for the "Recent colors" area, it's also much clearer as to which colors are custom and which are theme colors [22:27] in any case, have we agreed on having recent colors in "Custom colors"? [22:30] perhaps we should leave the conversation for next week? [22:31] yes [22:31] <@issa> yes probably [22:31] <@issa> (sorry was a bit busy( [22:32] alright [22:32] <@issa> mirek2: more colors should've been custom colors anyway [22:32] <@issa> (which always gets rid of theme colors) [22:33] ok, but then you have the standard palette in two areas [22:33] the palette picker and the default area [22:34] IMO, that makes things unnecessarily complex [22:34] and, honestly, I can't really imagine a realistic scenario when you would need to constantly switch between custom and theme colors [22:35] anyway, let's leave it for next week [22:35] <@issa> ok [22:35] does one of you want to upload the log? [22:35] == Computer1_ [~computer1@117.239.204.226] has joined #libreoffice-design [22:35] hi computer :) [22:36] it seems as though we are just ending [22:36] unless there's something you'd like to talk about [22:37]  Hey! [22:38]  i am working on fdo#41572...and i wanted some guidance regarding the UI part to it... [22:38]  if its convinient for you! [22:38] sure [22:38] coul you provide a link to the bug? [22:39] https://bugs.freedesktop.org/show_bug.cgi?id=41572 [22:40]  https://bugs.freedesktop.org/show_bug.cgi?id=41572 [22:40]  and yeah it would be of great help to me as well as on your side if someone can have a look at their emails,i had sent a detailed email regarding the help i need. [22:40]  my email id is : janit92 at gmail.com [22:44] I'm not sure I understand your proposal [22:45]  what proposal..? :/ [22:45] in "[Libreoffice-ux-advise] Help to make it possible to add custom animation to Master Slides." [22:45] the last bullet point [22:45]  yeah wait [22:46] with regards to the code-related things, I can't help you [22:46] you should try libreoffice-dev for that [22:46]  yeah [22:47] or what exactly do you need help with? [22:47]  oh yeah the last bullet point : [22:47]  we can provide users with a toolbox or popup...which has all the slide no's and the no. of textboxes they have.. [22:48]  we can select the details of them and choose the CustomAnimation effect we decide to add [22:48] in the master? [22:48] so, say, the 3rd text box on the tenth slide would have a specific animation? [22:50] I probably just misunderstood what the proposal is [22:52] Computer1_: are you still there? [22:52]  yeah [22:53]  morek2 : your are right [22:53] == Computer1_ has changed nick to Computer1 [22:54] I can't imagine any use case for that [22:56] if a user needs that functionality, it's better to do simply using custom animations [22:56] not using master slides [22:56]  look right now the problem is that we arent able to assign custom animation to all the slides at one go. [22:56] right [22:56]  that is what the fdo#41572 says [22:56] <Computer1> :P [22:56] yup [22:57] and you want feedback on your feature suggestion or a suggestion on what the UI should be for adding animations to elements in master slides? [22:58] <Computer1> yeah on the first one [22:58] well, as I said, I can't imagine a use case [22:59] especially as users tend to move slides and objects around [22:59] if you want a specific animation for a certain kind of element, that would be a better fit for styles [23:00] if i understand the point is to change all animations in one place? as we change theme in maste slide? [23:02] <Computer1> medieval : that is what is missing and i am planning to work on the code to fix it [23:02] <Computer1> :) [23:02] then i see a lot of use cases [23:03] mirek2? [23:04] I see a lot of use-cases for that, yes [23:04] I don't see use-cases for specifying a certain object to apply that animation to in the master [23:04] as proposed in "[Libreoffice-ux-advise] Help to make it possible to add custom animation to Master Slides." [23:05] which is what I though the conversation was about? [23:05] <Computer1> mirek2 : medieval : i am sure we can do that...but i have just proposed an additional feature to the same issue which i am sure can ease up stuff for users [23:05] why not add these same way as we add them to specific slide? [23:06] (from right pane?) [23:06] <Computer1> yeah we can do that too....so that is what i was askingsuggestions [23:07] because changing other aspects of themes work same way - just changing them in master slide [23:07] I'm still confused [23:08] you're asking where to set these animations from? [23:08] yes [23:08] in that case, I agree with medieval [23:10] <Computer1> mirek2 : i think u r running a different story :/ [23:12] sorry [23:12] I understand the general proposal [23:12] but I don't agree with the last point on your ML thread [23:12] "We can provide something like a popup/box,etc. that can provide a user to select the slide no. as well as the textbox no. upon which he/she wants to apply the corresponding CustomAnimation Effect." [23:14] the master slide workflow should be to select an element, then apply an animation effect to it in the animation pane [23:14] <Computer1> mirek2 : why not..? [23:15] just like one would do with elements in regular slides [23:15] <Computer1> mirek2 : can u please guide me if there is already a feature of that sort..! [23:16] I don't think there is for master slides [23:17] <Computer1> mirek2 : the fdo#41572 talks about giving the same animation to all the textboxes in all the slides at one go right..? [23:18] oh, I misunderstood it as giving an animation to certain master slide elements in one go [23:19] <Computer1> nope...the first comment itself states the purpose for the bug. [23:24] ok [23:25] then I'm with medieval on this one [23:29] I guess that's all you needed? [23:29] <Computer1> hmmm...because presently it doesnt give the animation to "all" the textboxes in "all" the slides [23:30] I'm sorry guys, I really have to go [23:30] issa, medieval, I hope one of you can upload the log [23:31] see you next week :) [23:31] <@issa> mirek2: sure [23:31] <@issa> see you [23:31] bye