Design/Meetings/2013-04-20

    From The Document Foundation Wiki

    TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate

    Attendees

    • issa
    • Computer1
    • mirek2
    • medieval

    Topics

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

    Log

    [18:18] <medieval> hi
[18:18] <@issa> hi
[18:19] <medieval> 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] <medieval> 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] <medieval> mirek just wrote a letter about UI design into mailing list
[18:23] <medieval> long letter...i am reading it now
[18:23] <@issa> I'll do that too
[18:25] <medieval> I would look up the grid lines icon
[18:25] <medieval> I think you should make border width smaller
[18:29] <@issa> like this? http://i.imgur.com/TVam1Rr.png
[18:30] <medieval> 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] <medieval> https://www.dropbox.com/s/13i6zs7ivz93h49/ixe.png
[18:34] <@issa> yes I've seen this one :p
[18:36] <medieval> i think both show well what they are doing
[18:36] <medieval> it is your decision there
[18:37] <@issa> notice how the current one has shaded "header" cells
[18:39] <medieval> ye
[18:41] <medieval> (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] <mirek2> hi guys
[18:56] <@issa> hi mirek
[18:57] <@issa> (medieval is away, he should be back in 15 mins)
[18:57] <mirek2> 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] <mirek2> I don't think I agree
[19:02] <mirek2> actually, I think the icon's lines aren't thick enough
[19:02] <mirek2> 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] <mirek2> what does the inner grid represent?
[19:04] <mirek2> are there really 9 squares needed?
[19:04] <@issa> the calc grid
[19:04] <mirek2> the table icon fits them ideally, imho
[19:04] <@issa> no, could do with four
[19:04] <mirek2> that would do
[19:05] <mirek2> 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] <mirek2> yes, I was saying that it's possible to have thick lines, because the table icon has them
[19:06] <mirek2> but we should definitely differentiate the cell icon from the table icon
[19:07] <@issa> I guess so
[19:11] <mirek2> I'm just wondering -- how did you get involved with LibreOffice?
[19:12] <mirek2> what draws you to open source software? what motivates you to volunteer?
[19:16] <@issa> well I'm not exactly volunteering
[19:17] <mirek2> not even with the icons?
[19:17] <@issa> I'm working at the national FOSS program here in Saudi Arabia
[19:17] <mirek2> oh, ok, cool :)
[19:17] <mirek2> could you tell me more about it?
[19:18] <mirek2> 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] <mirek2> :) any developers among you?
[19:20] <mirek2> would be great if we could get some of our easyhacks fixed
[19:20] <mirek2> could bring the UX forward
[19:21] <medieval> hi, am back
[19:21] <@issa> welcome back
[19:21] <@issa> mirek2: we are all developers
[19:22] <mirek2> oh, ok
[19:22] <mirek2> 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] <mirek2> once the code pointers are added, though, it should be relatively easy to do
[19:23] <@issa> I guess so
[19:23] <mirek2> :) great
[19:25] <@issa> so lets go back to the icons, shall we?
[19:25] <mirek2> sure, go ahead
[19:26] <medieval> 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] <medieval> i read it
[19:27] <medieval> i think its about the lighter frame color
[19:29] <mirek2> I also don't think the proposed "borders" icon fits in
[19:29] <mirek2> 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] <mirek2> that can be done with a 3x3 grid
[19:32] <mirek2> just like the icons we use now
[19:33] <mirek2> or you could try a 3x2 grid
[19:33] <@issa> so I should only change the borders icon?
[19:34] <mirek2> as well as the grid lines icon
[19:35] <mirek2> however, I think the problem with that icon was that it was highlighting an irrelevant aspect of the icon
[19:35] <mirek2> in that icon, the cells are relevant, no the border
[19:35] <mirek2> yet the border was thicker
[19:36] <mirek2> it should be the other way around
[19:36] <@issa> hmm
[19:41] <mirek2> still there?
[19:41] <mirek2> ignore that, I just needed to check if I wasn't disconnected
[19:48] <mirek2> 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] <mirek2> much better, imho
[19:57] <mirek2> and I don't think there's need for the 4x4 icon
[19:58] <mirek2> anymore, with the changes you made
[20:02] <mirek2> medieval: what do you think?
[20:03] <medieval> as I said before I like these: thicker borders
[20:03] <medieval> thinner*
[20:03] <mirek2> so you like the proposed icons?
[20:03] <medieval> yes
[20:05] <mirek2> me too
[20:05] <mirek2> so I guess let's use those
[20:05] <mirek2> 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] <mirek2> just a note about the f(x) icon
[20:08] <@issa> yeah?
[20:08] <mirek2> I think the x should be smaller, to resemble a subscript
[20:09] <@issa> it's not a subscript
[20:10] <mirek2> hm, I'm trying to see where the symbolism comes from
[20:10] <mirek2> the standard notation is f(x) if anything
[20:10] <mirek2> in any case, I guess it's good as it is
[20:11] <mirek2> 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] <mirek2> right
[20:12] <@issa> still doesn't look like a subscript to me :p
[20:12] <mirek2> it's probably best to keep it as is
[20:12] <mirek2> 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] <mirek2> I like the second one from the top
[20:15] <mirek2> though any one from the three is fine IMHO
[20:15] <medieval> second
[20:15] <@issa> yes second seems to be the clearist
[20:15] <medieval> third maybe
[20:15] <medieval> first resembles borders
[20:17] <@issa> now we can move on to another topic
[20:18] <mirek2> alright
[20:18] <mirek2> any topics you would suggest?
[20:18] <mirek2> if not, we can talk about the color picker
[20:18] <medieval> mirek i saw you wrote great letter to mailing list
[20:19] <mirek2> 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] <medieval> i am in the same line with you
[20:20] <medieval> mirek*
[20:20] <mirek2> cool :) good to know we are in the same boat
[20:21] <medieval> * Nonconformity. The ribbon is alien to all platforms except Windows. macOS requires a menu bar for each application.
[20:21] <medieval> I think it hard to make ribbon to be used bt linux users
[20:21] <medieval> is* by*
[20:22] <mirek2> yes, sort of
[20:22] <@issa> I don't think so, the menu bar will stay only the icons will be replaced
[20:22] <mirek2> we would have to use our own UI elements and try to make them fit with the environment
[20:22] <medieval> why don't you introduce you citrus UI to them, or as we agreed it is kind of our "goal"
[20:23] <mirek2> actually, the UI proposal is quite outdated and not really presentable
[20:23] <mirek2> it was more of a UI brainstorm/experiment than something to be presented as a vision
[20:24] <medieval> ok
[20:24] <mirek2> 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] <mirek2> well, here's how I imagine the roadmap:
[20:24] <mirek2> it all depends on the EasyHacks
[20:25] <mirek2> https://wiki.documentfoundation.org/Design/Blueprints
[20:26] <@issa> well I'd say the pretty hacks are a bit subjective
[20:26] <medieval> is somebody here usng ubuntu?
[20:26] <mirek2> I'm on a borrowed laptop using macOS
[20:26] <@issa> medieval: I do, but not atm
[20:26] <mirek2> on my own netbook that's being repaired, I have elementary
[20:26] <mirek2> why do you ask?
[20:26] <medieval> is the hud usable?
[20:27] <medieval> (i use eOS and win7 myself)
[20:27] <mirek2> somewhat usable, but not discoverable
[20:27] <@issa> what do you mean? the shell?
[20:27] <medieval> it would be nice addition
[20:27] <mirek2> it would
[20:27] <medieval> http://www.youtube.com/watch?v=w_WW-DHqR3c
[20:27] <mirek2> macOS has a similar feature
[20:28] <mirek2> only in the help menu
[20:28] <mirek2> 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] <mirek2> www.youtube.com/watch?v=7IP__mFL7d4
[20:29] <mirek2> I think they are going away
[20:29] <mirek2> 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] <medieval> issa, how much to you know about different widget toolkits?
[20:30] <medieval> or mirek
[20:31] <mirek2> why do you ask?
[20:31] <mirek2> we can't really move to GTK or Qt yet -- that would be too much effort
[20:32] <medieval> but doesn't the effort pay itself?
[20:32] <mirek2> not really, at least from my talks with the devs
[20:32] <mirek2> basically, I was told that it would take a year of work from every dev working on LibreOffice
[20:32] <mirek2> all work would be suspended for a year
[20:33] <mirek2> whereas VCL, though not excellent, is still workable
[20:33] <mirek2> and considerably easier to just maintain
[20:33] <@issa> medieval: I know pretty much nothing
[20:33] <medieval> ok
[20:34] <mirek2> 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] <mirek2> 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] <mirek2> 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] <mirek2> 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] <medieval> (asking about hud, I wated to know if it is working with libreoffice)
[20:39] <mirek2> I assume it will work with versions that integrate with Ubuntu's application menus
[20:39] <mirek2> it works on macOS
[20:39] <@issa> seems like it http://iloveubuntu.net/pictures_me/libreoffice%203.6.2%20hud%20support1.png
[20:39] <medieval> ok
[20:40] <medieval> link doesen't open
[20:41] <medieval> but point taken
[20:41] <@issa> I dunno, one of the first google images results
[20:42] <mirek2> www.iloveubuntu.net/libreoffice-362-landed-ubuntu-1210-full-hud-support-and-strengthened-appmenu
[20:43] <mirek2> 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] <medieval> (i think i need to move to unity again which i don't like)
[20:44] <mirek2> roadmap:
[20:44] <mirek2> "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] <mirek2> "Hidden Items Menu" would allow us to streamline toolbars while adding more commands
[20:46] <@issa> ok
[20:46] <mirek2> (i.e. narrow down the selection of the icons shown by default, add more to the menus)
[20:47] <mirek2> the menu could include a button to the relevant dialog, thus making going through the menus less necessary
[20:48] <medieval> (office have  it from 2003?)
[20:48] <mirek2> 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] <mirek2> https://wiki.documentfoundation.org/Design/Whiteboards/Toolbars#Proposal_by_Mirek2
[20:49] <mirek2> medieval: really? are you sure that the Office implementation doesn't just toggle the visible buttons?
[20:50] <medieval> (i don't 2003 now, not sure)
[20:50] <mirek2> ok
[20:51] <mirek2> in any case, this AppMenu would eventually allow the user to forego the menubar altogether
[20:51] <mirek2> and hide it, thus fitting into platforms that discourage against the use of menus
[20:51] <medieval> (i think it have the same system as we have now)
[20:52] <mirek2> oh, ok
[20:52] <@issa> it's still would be weird having new open etc on the far right
[20:53] <mirek2> well, we'll cross that bridge when we come to it, I guess
[20:53] <@issa> perhaps
[20:53] <mirek2> that's the problem with trying to make any UI changes
[20:53] <mirek2> the change is well-reasoned, though
[20:53] <@issa> true
[20:53] <mirek2> and for you, it would be on the far left
[20:53] <mirek2> (for RTL languages, I mean)
[20:54] <@issa> I don't actually use RTL interfaces
[20:54] <mirek2> oh, alright
[20:54] <mirek2> 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] <mirek2> the rest is just smoothing out the experience
[20:54] <mirek2> yes
[20:55] <mirek2> that's another reason why I'm avoiding proposing a whole UI change
[20:55] <mirek2> 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] <mirek2> how so?
[20:56] <@issa> all toolbars are left-aligned, you want to us to have both?
[20:57] <medieval> yes
[20:57] <medieval> as i understand
[20:57] <medieval> ?
[20:57] <mirek2> yes, sort of
[20:58] <mirek2> they wouldn't be as flexible, though
[20:58] <mirek2> i.e. they would always stick to the side
[20:58] <mirek2> you wouldn't be able to move them freely along the bar as you can with left-aligned toolbars
[20:58] <mirek2> which I would argue is a good thing -- it doesn't allow you to create gaps
[20:59] <mirek2> 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] <mirek2> 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] <mirek2> 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] <mirek2> so that it's always at the right
[21:01] <mirek2> 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] <mirek2> there shouldn't be
[21:01] <mirek2> they are normal icons
[21:01] <@issa> but they aren't in a normal toolbar
[21:01] <mirek2> only the toolbar sticks to the right of the window
[21:01] <mirek2> it is a normal toolbar
[21:01] <mirek2> it just sticks to the right of the window
[21:02] <mirek2> 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] <mirek2> LibreOffice can't handle flexible spaces, so this is the next best thing
[21:03] <mirek2> issa: icons are not aligned to the left next to them
[21:03] <mirek2> it's just the toolbar that is always at the right
[21:03] <mirek2> the contents are not affected
[21:03] <@issa> I know
[21:03] <@issa> but there aren't clear visual distinction between toolbars
[21:03] <mirek2> why should there be?
[21:04] <mirek2> 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] <mirek2> but these toolbars are normal toolbars
[21:05] <@issa> they are sticky toolbars
[21:06] <@issa> or presistant toolbars
[21:06] <mirek2> they're meant not to stick out
[21:06] <mirek2> they're not persistent
[21:06] <mirek2> they can be removed
[21:06] <@issa> really? why do we need them then?
[21:08] <mirek2> it boils down to spacial orientation and symmetry
[21:08] <mirek2> when all toolbars are left-aligned, there's a bunch of icons to the left and none to the right
[21:08] <mirek2> 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] <mirek2> what is the right solution?
[21:09] <@issa> justifying icons is the right solution
[21:09] <mirek2> how would that work?
[21:09] <@issa> (as in equal space between icons)
[21:10] <mirek2> I disagree
[21:10] <mirek2> then you're faced with spread out icons on large monitors
[21:10] <mirek2> and you can no longer take advantage of your muscle memory when moving between commands
[21:11] <mirek2> 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] <mirek2> it would also significantly alter the UI when a contextual toolbar would appear
[21:11] <mirek2> other applications do it
[21:11] <@issa> maybe the problem just isn't there
[21:11] <mirek2> it's quite common in elementary http://elementary-art.deviantart.com/
[21:12] <mirek2> what do you think about e.g. http://spiceofdesign.deviantart.com/art/Writer-Concept-351501580?q=favby%3Aelementary-art%2F45954099&qo=3 ?
[21:12] <mirek2> where issa some icons are on the right, some on the left
[21:13] <mirek2> or about iWork pages: http://images.appleinsider.com/new-iwork-070807-1.png ?
[21:13] <@issa> it's uncomfortable
[21:13] <mirek2> 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] <mirek2> really? well, you wouldn't be required to use them
[21:14] <mirek2> issa: not right now
[21:14] <mirek2> though they're planning to
[21:14] <@issa> iWork seems to have the same problem as justification
[21:14] <mirek2> I posted an older version
[21:14] <@issa> I guess we should have justification on toobars level then
[21:14] <mirek2> the newer one aligns left, center, and right
[21:15] <mirek2> 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] <mirek2> also, iWork can afford to justify toolbars, as they don't change and aren't customizable
[21:16] <mirek2> what browser are you using, btw?
[21:16] <@issa> firefox
[21:16] <mirek2> basically any browser I can think of right now has some buttons aligned to the right
[21:17] <mirek2> 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] <mirek2> it also plans to move the application menu to the right https://wiki.mozilla.org/Features/Desktop/Panel_Menu
[21:19] <mirek2> issa: previous and next are left-aligned
[21:19] <@issa> previous and next are merged into the address bar
[21:19] <mirek2> on non-Linux platforms
[21:20] <mirek2> 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] <mirek2> on Android, it's a standard to have right-aligned icons
[21:22] <mirek2> issa: well, Firefox uses flexible spacing and a flexible address bar
[21:22] <mirek2> 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] <mirek2> 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] <mirek2> 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] <mirek2> 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] <mirek2> no, I want it to be in a separate area from the contextual toolbar
[21:25] <mirek2> 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] <mirek2> for commands relating to the document or application as a whole, static commands, the user will move his eyes to the right
[21:26] <mirek2> 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] <mirek2> that's another topic
[21:28] <mirek2> 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] <mirek2> or perhaps to just give toolbars equal space
[21:29] <mirek2> issa: the initial implementation would really be just as simple as positioning the toolbar to the far right
[21:30] <mirek2> 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] <mirek2> right
[21:31] <@issa> great, sorry if I sounded harsh :)
[21:31] <mirek2> no worries :)
[21:31] <mirek2> should we move to another topic?
[21:31] <mirek2> 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] <mirek2> issa: I thought we were only talking about the right-aligned toolbars?
[21:33] <mirek2> the EasyHacks were already approved once, several weeks ago
[21:34] <mirek2> 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] <mirek2> they were also approved by a dev I met with
[21:34] <mirek2> Kendy, a LibreOffice dev
[21:35] <mirek2> so I'd prefer not to have to reevaluate all of them again...
[21:36] <@issa> mirek2: ok
[21:37] <mirek2> but I'm definitely OK with a thread or two about a specific EasyHack
[21:38] <mirek2> I hope that didn't sound too harsh
[21:39] <mirek2> new topic?
[21:39] <mirek2> color picker?
[21:39] <mirek2> 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] <mirek2> the thing is, it's not an official roadmap and LibO's UI may take any turn
[21:42] <mirek2> this was just something I imagine
[21:42] <mirek2> 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] <mirek2> I'll think about it
[21:43] <mirek2> I certainly don't want to sound like it's this roadmap or no roadmap
[21:43] <mirek2> I want everyone to have a say
[21:44] <mirek2> not to force people to a roadmap set out by me
[21:44] <@issa> yeah you have to work on phrasing it
[21:44] <mirek2> yeah, I'll think about it
[21:45] <mirek2> I'd also like to avoid seeming like an unnecessary thought piece that doesn't belong on the ML
[21:45] <mirek2> I want it to have a point
[21:45] <mirek2> ...
[21:45] <mirek2> in any case, color picker
[21:45] <mirek2> https://wiki.documentfoundation.org/Design/Whiteboards/Color_Picker
[21:45] <@issa> yes go on
[21:45] <mirek2> as I said on the ML, I'm not happy with certain aspects of the current tentative design
[21:47] <mirek2> they should go on "Custom colors", where the rest of the "static" colors are
[21:47] <mirek2> Recent colors shouldn't go on the "Theme colors" panel, as, unlike theme colors, they are not variable
[21:47] <mirek2> 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] <mirek2> then we have a problem in separating out static colors
[21:48] <mirek2> 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] <mirek2> 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] <mirek2> 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] <mirek2> issa: that's not what is is at all
[21:50] <mirek2> you use theme colors if you want your document to follow a certain theme
[21:50] <mirek2> 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] <mirek2> 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] <mirek2> 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] <mirek2> 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] <mirek2> issa: I guess that could be done, but why?
[21:53] <mirek2> 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] <mirek2> 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] <mirek2> 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] <mirek2> issa: why? recent colors only make sense once you've used the custom colors panel anyway
[21:56] <mirek2> 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] <mirek2> 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] <mirek2> 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] <mirek2> theme colors and static colors have different use cases
[21:59] <mirek2> theme colors you use when the color itself isn't relevant
[21:59] <mirek2> for text, for charts, etc.
[21:59] <mirek2> static colors you use when you're drawing something
[21:59] <mirek2> an apple, a tree, a building
[22:00] <mirek2> unless you're constantly writing and drawing, though, I doubt you'll need to switch between the two very often
[22:00] <mirek2> 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] <mirek2> 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] <mirek2> 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] <mirek2> however, you should not mix theme colors and custom colors
[22:02] <mirek2> 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] <mirek2> 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] <mirek2> issa: we should certainly discourage it
[22:03] <mirek2> issa: but you have quick access to static colors
[22:03] <mirek2> though only when you're not working with theme colors
[22:04] <mirek2> 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] <mirek2> I explained why it's dangerous above
[22:04] <mirek2> 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] <mirek2> if red isn't your theme color, I don't see why you'd need to create such an inconsistency
[22:06] <mirek2> it would stick out like a sore thumb
[22:06] <mirek2> 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] <mirek2> let me give a counter-example:
[22:07] <mirek2> let's say you have used red in those 20 pages that's not in the theme colors
[22:07] <mirek2> and you intended for red to be distinct from the theme colors
[22:08] <mirek2> your company then changes its theme colors and you automatically retheme the document
[22:08] <mirek2> unfortunately, those new colors contain red, meaning the intended contrast is lost
[22:08] <mirek2> and the red has lost its function
[22:08] <mirek2> thus, if you use it to highlight errors, that won't be visible anymore
[22:09] <mirek2> 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] <mirek2> 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] <mirek2> 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] <mirek2> I know
[22:11] <mirek2> 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] <mirek2> it doesn't matter though
[22:12] <mirek2> it just encourages bad habits if it's on one panel
[22:12] <mirek2> say you draw a person using a theme color and then, within him, a heart with a custom red color
[22:13] <mirek2> 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] <mirek2> 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] <mirek2> thus making it appear that text is a mistake
[22:14] <@issa> these are the users problems
[22:15] <mirek2> https://wiki.documentfoundation.org/Design/Principles
[22:15] <mirek2> ux-error-prevention
[22:15] <mirek2> "Interfaces should proactively try to prevent errors from happening."
[22:15] <mirek2> we should not encourage bad practices
[22:15] <@issa> hmmm
[22:16] <@issa> but that is quite annoying
[22:16] <mirek2> if a person really needs to use a custom color among theme colors, he can resort to styles
[22:16] <mirek2> use a custom color there
[22:16] <mirek2> and since it is a single custom color, that should be the best way to do it
[22:17] <mirek2> 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] <medieval> issa: recent colors?
[22:18] <@issa> I guess that person should just use the standard palette in the custom colors
[22:19] <mirek2> yeah, definitely
[22:20] <@issa> although I still think most people wouldn't get that easily
[22:20] <mirek2> we just need to communicate the point of themes better
[22:21] <mirek2> I think most people don't understand that one can change themes
[22:21] <mirek2> 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] <mirek2> 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] <mirek2> that would eliminate precise custom colors, though
[22:22] <mirek2> which is something I'd really hate to do
[22:23] <mirek2> 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] <mirek2> 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] <mirek2> that's a bit confusing, though
[22:25] <mirek2> as "more colors" gets rid of theme colors
[22:25] <mirek2> not really something I would expect
[22:26] <mirek2> in that regard, I prefer the current tentative design
[22:26] <mirek2> except for the "Recent colors" area, it's also much clearer as to which colors are custom and which are theme colors
[22:27] <mirek2> in any case, have we agreed on having recent colors in "Custom colors"?
[22:30] <mirek2> perhaps we should leave the conversation for next week?
[22:31] <medieval> yes
[22:31] <@issa> yes probably
[22:31] <@issa> (sorry was a bit busy(
[22:32] <mirek2> 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] <mirek2> ok, but then you have the standard palette in two areas
[22:33] <mirek2> the palette picker and the default area
[22:34] <mirek2> IMO, that makes things unnecessarily complex
[22:34] <mirek2> and, honestly, I can't really imagine a realistic scenario when you would need to constantly switch between custom and theme colors
[22:35] <mirek2> anyway, let's leave it for next week
[22:35] <@issa> ok
[22:35] <mirek2> does one of you want to upload the log?
[22:35] == Computer1_ [~computer1@117.239.204.226] has joined #libreoffice-design
[22:35] <mirek2> hi computer :)
[22:36] <mirek2> it seems as though we are just ending
[22:36] <mirek2> unless there's something you'd like to talk about
[22:37] <Computer1_> Hey!
[22:38] <Computer1_> i am working on fdo#41572...and i wanted some guidance regarding the UI part to it...
[22:38] <Computer1_> if its convinient for you!
[22:38] <mirek2> sure
[22:38] <mirek2> coul you provide a link to the bug?
[22:39] <mirek2> https://bugs.freedesktop.org/show_bug.cgi?id=41572
[22:40] <Computer1_> https://bugs.freedesktop.org/show_bug.cgi?id=41572
[22:40] <Computer1_> 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] <Computer1_> my email id is : janit92 at gmail.com
[22:44] <mirek2> I'm not sure I understand your proposal
[22:45] <Computer1_> what proposal..? :/
[22:45] <mirek2> in "[Libreoffice-ux-advise] Help to make it possible to add custom animation to Master Slides."
[22:45] <mirek2> the last bullet point
[22:45] <Computer1_> yeah wait
[22:46] <mirek2> with regards to the code-related things, I can't help you
[22:46] <mirek2> you should try libreoffice-dev for that
[22:46] <Computer1_> yeah
[22:47] <mirek2> or what exactly do you need help with?
[22:47] <Computer1_> oh yeah the last bullet point :
[22:47] <Computer1_> 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] <Computer1_> we can select the details of them and choose the CustomAnimation effect we decide to add
[22:48] <mirek2> in the master?
[22:48] <mirek2> so, say, the 3rd text box on the tenth slide would have a specific animation?
[22:50] <mirek2> I probably just misunderstood what the proposal is
[22:52] <mirek2> Computer1_: are you still there?
[22:52] <Computer1_> yeah
[22:53] <Computer1_> morek2 : your are right
[22:53] == Computer1_ has changed nick to Computer1
[22:54] <mirek2> I can't imagine any use case for that
[22:56] <mirek2> if a user needs that functionality, it's better to do simply using custom animations
[22:56] <mirek2> not using master slides
[22:56] <Computer1> look right now the problem is that we arent able to assign custom animation to all the slides at one go.
[22:56] <mirek2> right
[22:56] <Computer1> that is what the fdo#41572 says
[22:56] <Computer1> :P
[22:56] <mirek2> yup
[22:57] <mirek2> 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] <mirek2> well, as I said, I can't imagine a use case
[22:59] <mirek2> especially as users tend to move slides and objects around
[22:59] <mirek2> if you want a specific animation for a certain kind of element, that would be a better fit for styles
[23:00] <medieval> 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] <medieval> then i see a lot of use cases
[23:03] <medieval> mirek2?
[23:04] <mirek2> I see a lot of use-cases for that, yes
[23:04] <mirek2> I don't see use-cases for specifying a certain object to apply that animation to in the master
[23:04] <mirek2> as proposed in "[Libreoffice-ux-advise] Help to make it possible to add custom animation to Master Slides."
[23:05] <mirek2> 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] <medieval> why not add these same way as we add them to specific slide?
[23:06] <medieval> (from right pane?)
[23:06] <Computer1> yeah we can do that too....so that is what i was asking----suggestions
[23:07] <medieval> because changing other aspects of themes work same way - just changing them in master slide
[23:07] <mirek2> I'm still confused
[23:08] <mirek2> you're asking where to set these animations from?
[23:08] <medieval> yes
[23:08] <mirek2> in that case, I agree with medieval
[23:10] <Computer1> mirek2 : i think u r running a different story :/
[23:12] <mirek2> sorry
[23:12] <mirek2> I understand the general proposal
[23:12] <mirek2> but I don't agree with the last point on your ML thread
[23:12] <mirek2> "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] <mirek2> 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] <mirek2> 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] <mirek2> 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] <mirek2> 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] <mirek2> ok
[23:25] <mirek2> then I'm with medieval on this one
[23:29] <mirek2> 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] <mirek2> I'm sorry guys, I really have to go
[23:30] <mirek2> issa, medieval, I hope one of you can upload the log
[23:31] <mirek2> see you next week :)
[23:31] <@issa> mirek2: sure
[23:31] <@issa> see you
[23:31] <mirek2> bye
    Retrieved from "https://wiki.documentfoundation.org/index.php?title=Design/Meetings/2013-04-20&oldid=161491"