Design/Meetings/2012-11-03

    From The Document Foundation Wiki

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

    Attendees

    • Astron
    • @Medieval
    • Mirek2

    Topics

    • Color handling
      • Palettes

    Tasks

    Astron:

    • Work on FOSDEM T-Shirts
    • Give feedback on caretakers idea

    Mirek2:

    • Create Color picker whiteboard and craft the tentative design

    Log

    [16:06] <astron247> hello
[16:06] <mirek2> hi everyone
[16:06] <mirek2> I suppose we can get started now
[16:06] <astron247> i guess.
[16:06] <astron247> uhm... sorry about the missing esc call news. i couldnt attend
[16:07] <mirek2> alright
[16:08] <astron247> im not sure about the gist of it ... did the minutes make out the next release as 4.0 or was it less conclusive?
[16:08] <mirek2> I don't know
[16:08] <mirek2> but I don't think it really matters much
[16:08] <mirek2> (a rose by any other name would smell as sweet)
[16:09] <astron247> it matters quite a bit in terms of amrketing
[16:09] <astron247> ^am^ma
[16:09] <mirek2> sure, but we're not in marketing
[16:10] <astron247> in a way were all in marketing.
[16:10] <astron247> but, youre right, we are not specifically in marketing.
[16:10] <mirek2> anyway, there was mention of color handling on the esc minutes
[16:10] <astron247> but i think a lot of people will expect a big-bang redesign
[16:10] <astron247> yes, i saw that.
[16:10] <mirek2> we wouldn't do a big-bang redesign either way, really
[16:11] <mirek2> do you have any idea about it? did Alex attend the chat, or nobody from design?
[16:11] <astron247> hm, no, but we discussed it last week already.
[16:12] <astron247> you can see my minutes from last week – but i forgot during the chat, i guess
[16:13] <mirek2> oh, I thought what you wrote only concerned changing the defaults
[16:13] <astron247> so, what would probably be good if we could distill some minimal consensus from the colours whiteboard and propose that on ux-advise
[16:13] <mirek2> well, we still need to do the UI for gradients
[16:14] <astron247> it started from the defaults discussion, and we then discussed how hard it is change these defaults without getting better handling (as alex and you already noticed)
[16:14] <astron247> mirek2: i would leave gradients out of the picture for now.
[16:15] <mirek2> but wouldn't that make things MORE complex, as we would need to improve both the color list with names picker and the square color picker?
[16:15] <astron247> i know we kinda should have a plan to convert everything, but if we can come up with something immediately relieving of our colour pains, that would be great
[16:16] <mirek2> hmph... so you propose gradually tweaking the current square color picker?
[16:16] <astron247> yes.
[16:16] <@Medieval> yes
[16:16] <astron247> (if by square you mean toolbar icon)
[16:16] <mirek2> and leave the more complex picker with gradients and patterns and whatnot alone?
[16:16] <@Medieval> for further steps
[16:16] <astron247> yes.
[16:16] <astron247> hehe^^
[16:17] <mirek2> by "square", I mean that colors are presented as squares, not as a list of color names.
[16:17] <astron247> okay, yeah, the toolbar icon version, not the combo box version :)
[16:18] <mirek2> yes :)
[16:18] <mirek2> ok, let's look at what we have so far
[16:18] <mirek2> frankly, looking back, 12 recent colors seems like too much
[16:19] <mirek2> isn't 6 enough?
[16:19] <@Medieval> but if we change palette then how can user access color that are used in document?
[16:20] <astron247> five + a button to expand to load more recent colours?
[16:20] <mirek2> Medieval: "Document colors would be shown in a separate palette."
[16:20] <mirek2> we would have a palette picker
[16:21] <@Medieval> ok...then its ok
[16:21] <mirek2> astron247: do we really need to save that many recent colors? remember that we'll have all the document colors available from elsewhere
[16:21] <@Medieval> then 6 is enough?
[16:21] <astron247> where's elsewhere?
[16:21] <@Medieval> no more needed probably
[16:21] <astron247> medieval: let me find the old whiteboard?
[16:21] <astron247> ^?^...
[16:21] <mirek2> https://wiki.documentfoundation.org/Design/Whiteboards/Color_Handling
[16:22] <astron247> ah, thanks
[16:22] <mirek2> astron247: as said above, there would be a palette picker, and "Document colors" would be one of the palettes
[16:22] <@Medieval> I would go with this Mirek, your design: https://wiki.documentfoundation.org/File:C-libre.png
[16:23] <@Medieval> In first step
[16:23] <mirek2> :) thanks
[16:24] <@Medieval> I think the tango colors are best for defaults
[16:24] <astron247> mirek: i am a bit unsure about floats on floats, i. e. the combo box for different palettes
[16:25] <astron247> (deja vu – did we have this argument already?)
[16:25] <mirek2> how would you suggest to pick different palettes, then?
[16:26] <astron247> ill try drawing it. waitasec
[16:31] <astron247> https://dl.dropbox.com/u/87946285/libreoffice/clr.png
[16:32] <mirek2> hm... seems interesting, though it could take up a lot of space
[16:32] <astron247> i know, but do we care?
[16:33] <@Medieval> is it possible to make dropdown button
[16:33] <@Medieval> button do open list
[16:33] <mirek2> well, there's the possible disadvantage of not seeing the live preview because of the size
[16:34] <astron247> live preview?
[16:34] <mirek2> one thing I wanted to bring up -- touch support
[16:34] <mirek2> astron247: when you see the color of an object changing as you hover over colors
[16:34] <mirek2> but I suppose that's not something needed
[16:35] <astron247> okay, so, for one for the first instalment of it it likely wont happen anyway
[16:35] <mirek2> yeah, I don't think we need live preview, really
[16:35] <astron247> also, it does not make sense on touch., really
[16:35] <mirek2> right
[16:35] <astron247> medieval: you mean making it foldable?
[16:37] <@Medieval> no
[16:37] <@Medieval> just one button
[16:39] <astron247> well, click something like a "Palette >" button, then it expands and closes when one clicks it again ("Palette <")?
[16:39] <@Medieval> https://dl.dropbox.com/u/87946285/libreoffice/clr.png there will be problem if there is a lot palettes
[16:39] <@Medieval> just button that opens some menu
[16:39] <@Medieval> 7list
[16:39] <astron247> adding a scrollbar to it seems ~pkayish though not necessarily pretty to me
[16:40] <astron247> ^~pk^~ok
[16:41] <astron247> if we have a very short palette, we could probably also force a minimum size of three lines or so.
[16:41] <mirek2> about touch support, the recommended minimal size for a touch target is 34px
[16:41] <mirek2> so the size of color squares should ideally be somewhat like https://ubuntuone.com/4WrqFbyCy4NbPG0U4puNAL
[16:42] <@Medieval> these are very big
[16:42] <mirek2> compared to the current standards, yes
[16:42] <astron247> i agree, for a desktop, they seem imposingly large
[16:43] <mirek2> Gnome has something similar now: http://library.gnome.org/misc/release-notes/3.4/figures/rnusers.color-chooser.png.en
[16:43] <astron247> i know.
[16:43] <mirek2> it actually works really well once you get used to it
[16:44] <astron247> youre right. but it is in a modal window, not an overlay
[16:44] <mirek2> is that an important differentiator?
[16:45] <astron247> to my mind, yes. but i cant so much explain why.
[16:46] <mirek2> perhaps because touch interfaces have strayed clear of drop-down overlays?
[16:46] <astron247> not actually because of that, but it is another important thing
[16:47] <mirek2> oh wait, I'm wrong -- they haven't
[16:47] <@Medieval> cant the size of color made changable in menu?, where there is icon size "automatic small large"
[16:48] <mirek2> that would add more complexity, which is something we should avoid; we should just pick good defaults
[16:48] <mirek2> but perhaps the size of everything in the picker could be halved if icon size is set to "small"
[16:48] <astron247> mso 2013 has a touch mode... not that i find that a good thing
[16:49] <mirek2> of course it does, now that ms is trying to create a tablet ecosystem
[16:50] <mirek2> + office being the only desktop app to run on RT
[16:50] <astron247> well, they didnt bother creating a touch mode for windows 8 – it just IS a touch OS
[16:50] <astron247> http://arstechnica.com/information-technology/2012/07/why-bother-the-sad-state-of-office-2013-touch-support/
[16:51] <astron247> (half of win8 is a touch os at least)
[16:51] <mirek2> if you ask me, LibreOffice with big icons is pretty touch-friendly (at least on Gnome)
[16:51] <astron247> have you tried?
[16:52] <mirek2> I have no way how to
[16:52] <astron247> how do you know then?
[16:52] <mirek2> but many of the targets have a good enough size to be touched
[16:52] <mirek2> at least the toolbars and menus do
[16:52] <mirek2> (menus under Gnome, that is)
[16:53] <mirek2> and I'm hoping dialogs will as well, once they're converted to .ui files
[16:53] <mirek2> (right now, they're sized differently from the OS defaults)
[16:54] <mirek2> Still, though, they often seem to be reasonably touch-friendly as well
[16:54] <astron247> i am not very sure about that. esp. since most touch devices have higher pixel densities than pc monitors and libo is still rather pixel-dependent
[16:55] <mirek2> that's something that will need to be fixed sooner or later
[16:55] <astron247> in any case. i am not against the large buttons really.
[16:56] <astron247> mirek2: youre right
[16:56] <mirek2> but with Windows 8, Gnome, and Ubuntu growing to be touch-based, we really shouldn't ignore touch interaction when designing new things
[16:56] <astron247> okay.
[16:57] <astron247> as i said, i am not against the large colour buttons
[16:57] <mirek2> ok, great :)
[16:57] <@Medieval> these are okei on my monitor
[16:59] <@Medieval> How about the palette picker then?
[16:59] <astron247> medieval: can you make a short sketch of what you meant?
[17:02] <@Medieval> yes
[17:02] <astron247> thanks!
[17:03] <mirek2> btw, I suppose we don't plan to support palette editing in the initial implementation, right?
[17:03] <astron247> no.
[17:03] <mirek2> ok
[17:03] <@Medieval> http://ubuntuone.com/4Um4cbiEg7rlGrFzEyWoHr
[17:04] <astron247> that should still be done via the options
[17:04] <@Medieval> sub menu
[17:04] <astron247> ah okay.
[17:05] <astron247> well, the problem i tried to solve is that we had one overlay over another
[17:05] <mirek2> yes -- I like your proposed solution, astron
[17:06] <astron247> ...which your (medivals) proposal doesnt really solve
[17:06] <@Medieval> yes i know
[17:07] <mirek2> is it ok if I change the scope of the whiteboard to reflect that we won't target palette editing, gradients, patterns, etc.?
[17:08] <mirek2> oh, and will we support palette import?
[17:08] <@Medieval> yes probably
[17:08] <astron247> is it maybe easier to add a new whiteboard that says it tries to lay out the steps to be taken to get to where the old whiteboard tried to go?
[17:09] <astron247> (@is it ok if I change the scope...)
[17:11] <@Medieval> yes
[17:11] <mirek2> a separate "color picker" whiteboard, then?
[17:12] <mirek2> Scope: "* Palettes; * Document colors; * Custom colors"
[17:13] <astron247> yes
[17:13] <astron247> also, @importing palettes: yes, but only from the options for now.
[17:13] <@Medieval> yes
[17:13] <mirek2> why? wouldn't it be simple to just add "Import palette" to the picker sidebar?
[17:14] <astron247> it would be simple, but i think it wouldnt be so relevant to most users
[17:15] <mirek2> it hasn't been relevant to them so far, because it wasn't very discoverable so far
[17:16] <astron247> i think what the picker should provide are the following three things:
[17:16] <astron247> * provide colours from any palette
[17:16] <astron247> * serve up colours from the document
[17:16] <astron247> * give the user a chance to define one (1) custom colour and apply it
[17:16] <mirek2> use cases for adding a custom palette:
[17:16] <astron247> mirek2: i dont think importing palettes is something  people will do all the time
[17:16] <mirek2> * company tells you you should use their colors
[17:17] <mirek2> astron247: sure, but they won't use document colors all the time either
[17:18] <mirek2> and if we're supporting palettes and putting them up front with a large sidebar, why not have palette import discoverable?
[17:18] <astron247> can we maybe instead put a link to the colour options somewhere?
[17:19] <mirek2> isn't that just adding an unnecessary step (ux-efficiency)? what's wrong with adding a palette from the palette picker, where it makes sense?
[17:22] <astron247> i am somewhat unsure if it does make sense there, as it is really somewhat more involved than picking a custom colour
[17:22] <mirek2> "more involved"?
[17:23] <astron247> its more of managerial task to import a palette
[17:23] <astron247> i think that is well suited within the options
[17:24] <mirek2> it's a very simple process -- download a palette, browse for it, push "import"
[17:24] <astron247> thats nothing to do with my argument :)
[17:24] <mirek2> the reason why it hasn't been used very much is because the process has been made difficult in LibreOffice
[17:25] <astron247> mirek2: yes, but we shouldnt overestimate its importance now
[17:26] <mirek2> it's a feature that is at least important in Draw, and Impress probably too
[17:26] <mirek2> I use palettes all the time in Inkscape
[17:26] <mirek2> what's wrong with adding a single button to the color drop-down?
[17:27] <astron247> it would make the ui more complicated.
[17:27] <@Medieval> but if it doesn´t slow down color picker, don´t take too much space, isn´t out of context - then where is problem?
[17:28] <astron247> also, we dont even support palette editing, so why, implement importing from the picker?
[17:28] <@Medieval> most of time you don´t see it if it is on dropdown menu
[17:28] <mirek2> we plan to support palette editing
[17:29] <mirek2> and even if we didn't, there are tons of use-cases where you just want to import a palette
[17:29] <mirek2> as I said, I use Inkscape palettes all the time, but I've never actually edited any
[17:30] <mirek2> as to making the UI complicated -- if we think it's a niche feature, then it doesn't really belong in LibreOffice, and is more suited to be an extension/advanced option
[17:30] <astron247> mirek2: can you even edit them in inkscape, dont you have to use gimp for that?
[17:31] <mirek2> honestly, I have no clue -- as I said, I use various palettes, but I've never had the need to make my own
[17:31] <mirek2> continuing on from where I left:
[17:32] <mirek2> since we have Draw, where palettes should be reasonably important as it is a vector editor, and if we plan to implement palette editing and have a sidebar dedicated to palettes, then I don't think palettes are a niche features
[17:32] <mirek2> -s
[17:34] <astron247> please stop with your black-and-white view. i think palette import is reasonably important to be implemented, but people wont be doing that with such frequency as to make an entry in the colour picker necessary
[17:35] <mirek2> alright, let's leave palette import alone for now and come back to it sometime later
[17:36] <mirek2> anyway, what have we agree on so far?
[17:36] <mirek2> 6 columns per palette, separate palette for document colors, 6 recent colors under the palette picker?
[17:37] <@Medieval> yes
[17:37] <astron247> okay
[17:38] <mirek2> 34 sq px buttons for colors minimum?
[17:38] <astron247> fine with me
[17:39] <mirek2> ok
[17:39] <@Medieval> if these are okei in smaller screens, then ok
[17:39] <@Medieval> okay*
[17:40] <mirek2> yes, it's fine on smaller screens
[17:40] <mirek2> btw, we might want to default to large icons on all desktops
[17:41] <astron247> me agree-y
[17:41] <astron247> one thing that would be good to solve is that somehow need to display two kinds of selection
[17:41] <astron247> * the current object colour being the one
[17:41] <astron247> * the colour that the user chose for the last object
[17:41] <astron247> (being the other)
[17:42] <mirek2> current object color will be highlighted, color the user chose for the last object will be the first entry in "Recent colors"
[17:43] <mirek2> or did I misunderstand?
[17:43] <astron247> but then the document colours might duplicate the palette entries..?
[17:43] <@Medieval> is this problem?
[17:44] <astron247> i am not sure, but it seems its screen space not well used to me...
[17:44] <mirek2> astron247: that's not a problem: "Document colours" appear in a separate palette
[17:45] <mirek2> recent colors might duplicate document colors and that's the expected behavior
[17:45] <astron247> okay, then.
[17:46] <mirek2> great :)
[17:46] <@Medieval> And if you use one color from default palette and lot of from others, then it is easier when they are stored in "document colors" palette, no need for jump between palettes, all in one place
[17:47] <mirek2> a bit off-topic: as we were talking about defaulting to large icons, what do you think about having a drop-down button for fonts?
[17:47] <mirek2> https://wiki.documentfoundation.org/File:F-list.png
[17:47] <astron247> i dont really like it
[17:47] <mirek2> to increase space on the formatting toolbar
[17:48] <astron247> (unless you could somehow see the font name without opening the menu)
[17:48] <mirek2> we could have it in the status bar, though I really think that it's overrated
[17:49] <mirek2> character style name is more important information, I would say, and that's not shown anywhere either
[17:49] <astron247> haha, thought of the status bar too, but didnt find it to be a good fit
[17:49] <astron247> mirek2: what do you mean by character style info?
[17:50] <mirek2> the name of the current character style
[17:50] <@Medieval> styles
[17:51] <astron247> like "default" usually?
[17:51] <mirek2> the style dropdown only shows the paragraph style, not the character style
[17:51] <@Medieval> styles. just reduce the sizes of these
[17:52] <@Medieval> I have only one font that reaches to end
[17:52] <@Medieval> font name*
[17:53] <@Medieval> and none of styles
[17:53] <mirek2> anyway, the primary reason behind having a font drop-down comes down to ux-visual-hierarchy: there's not really any good use-case where using the font drop-down would be more appropriate than using a style
[17:53] <@Medieval> and font size need space only for 3 numbers
[17:54] <mirek2> when you apply a font, you usually want to apply it to the whole document, or at least to a certain type of paragraph, so paragraph styles are more appropriate there
[17:55] <astron247> mirek2: you can define styles both ways: start from a style name and finish with the specifics OR you can create the specifics first and then give it a name
[17:55] <astron247> also, the first thing i usually do for new documents is pick a font i like
[17:56] <mirek2> sure, but a drop-down wouldn't be detrimental in those cases
[17:56] <mirek2> as you still end up using styles, thus need to see the style name, not the font name
[17:56] <@Medieval> trust me, most users don´t use styles
[17:57] <mirek2> yes, because their usability is awful atm
[17:57] <astron247> but if we discuss your font button idea now, then were talking the second step before the first
[17:58] <astron247> also, styles can be management overhead and if youre just writing something simple but still want to pick fonts youre (in that case: i am) not going to create new styles, are you?
[17:59] <mirek2> if the styles UI is simple, then you are
[17:59] <mirek2> (I edit styles in Google Docs all the time -- it's a breeze)
[18:00] <@Medieval> I use styles all the time
[18:00] <@Medieval> (only thing that is missing is preview)
[18:01] <@Medieval> but why we need to change current font selecting box to button? only for space?
[18:02] <mirek2> Medieval: as I said above, it's a matter of ux-visual-hierarchy
[18:02] <mirek2> https://wiki.documentfoundation.org/Design/Principles
[18:02] <mirek2> anyway, let's focus on color handling now, target better style handling afterwards (unless there's a developer willing to work on it now)
[18:03] <@Medieval> ok
[18:03] <astron247> okay, we should finish, i guess...
[18:03] <mirek2> I think we have all the necessary info for a tentative design
[18:03] <mirek2> so I would skip to that phase, to speed things up
[18:03] <@Medieval> yes
[18:04] <mirek2> I'd like to take the task of shaping the tentative design, if that's alright with you
[18:04] <astron247> okay, mirek, if thats okay, ill take the t-shirts thing again, can you concentrate on the colours?
[18:04] <astron247> argh... you wer first.
[18:04] <mirek2> ok, sure
[18:05] <@Medieval> dropdown menu then for selecting palettes?
[18:05] <@Medieval> or no consensus?
[18:05] <mirek2> sidebar, I think
[18:06] <mirek2> we can try a sidebar, then come back to drop-down if it doesn't work
[18:06] <astron247> id rather like the sidebar too
[18:06] <@Medieval> https://dl.dropbox.com/u/87946285/libreoffice/clr.png
[18:06] <@Medieval> this?
[18:06] <mirek2> based on our principles, the sidebar makes more sense (ux-efficiency and ux-error-prevention)
[18:07] <mirek2> oh, btw, feedback about the caretakers idea?
[18:07] <mirek2> I'm especially curious of your take on it, Astron, since you introduced the owner idea in the first place
[18:08] <astron247> sorry.
[18:08] <astron247> i havent read the thread completely yet. but i am positive :)
[18:08] <astron247> initially.
[18:08] <astron247> ill write on the list, if thats okay.
[18:08] <mirek2> yes, that's fine
[18:09] <astron247> okay. bye then today
[18:09] <@Medieval> bye
[18:09] <astron247> (for)
[18:09] <astron247> (oh, ill post the transcript)
[18:09] <mirek2> ok, sure
    Retrieved from "https://wiki.documentfoundation.org/index.php?title=Design/Meetings/2012-11-03&oldid=122787"