Calligra/End 2010 Text Styles UI IRC Meeting Log

From KDE Community Wiki
Revision as of 21:31, 26 December 2010 by Estan (talk | contribs) (Added IRC log.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

This is the full IRC log of the conversations that took place during the text styles UI IRC meeting on December 26, 2010.

--- Log opened Sön Dec 26 19:47:39 2010
19:48 < estan> *testing logging*
20:00 -!- ZaggeM [[email protected]] has quit [Ping timeout: 260 seconds]
20:03 < estan> we're missing the pierre's, but; meeting opened!
20:05 < boemann> thanks ,adn thanks for organizing
20:06 < estan> np.
20:06 < colomar> hi
20:06 < boemann> hi colomar
20:07 < boemann> great to see you here
20:07 < boemann> colomar: i've come a long way on the non-flickering docker stuff
20:08 < boemann> (side issue though)
20:08 < colomar> sounds great!
20:08 < boemann> but it does have one implication for what we are talking about
20:08 < boemann> the docker should only be two lines of text high
20:08 < boemann> anything else and it needs to pop up
20:10 < colomar> Two lines of text? That's not exactly much...
20:10 < estan> wow. the whole thing just two rows? so no long list of styles to choose from, but a combobox-ish thing?
20:10 < boemann> estan: yes
20:10 < boemann> well two rows of buttons
20:11 -!- PierreSt [[email protected]] has joined #calligra-styles-ui
20:11 < boemann> wellcome PierreSt we are not really started yet
20:11 < estan> hmhm. okay.. not very good discoverability, needs a click to see available styles.. pretty radical imho ;)
20:11 < PierreSt> hello there
20:11 < colomar> But can users still add a bigger "normal" styles docker if they wish?
20:12 < estan> ^ my question too.
20:12 -!- ZaggeM [[email protected]] has joined #calligra-styles-ui
20:12 < boemann> they can
20:12 < boemann> but it's bad for flexibility for users
20:12 < estan> so we'll discuss the UI of both then i guess.
20:13 < boemann> colomar: well you can add as many dockers your need . the point is you can then give aach two rows a headline too
20:14 < boemann> estan: regarding discoverability with two rows you can make a single tall widget that shows a lot
20:15 < boemann> plus a headline saying styles
20:15 < colomar> ?
20:15 < boemann> let me screen shot for you guys
20:15 < colomar> Okay maybe you should clarify what you mean by "two rows"
20:15 < colomar> Yes please ;)
20:15 < estan> boemann: ah. when you said "two lines of text" i was imagining you meant it as a # of pixel limit, but you mean two logical rows, that might be high?
20:16 < estan> yea ;)
20:16 < colomar> dito
20:16 < boemann> estan: no i meant limit on number of pixels
20:16 < estan> hm. okay.
20:17 < colomar> So how can you fit a tall widget in there then?
20:17 < estan> another thing, but we can get to that later; i'd really like us to iron out how styles should be applied by the user.. single/double click, apply buttons (where?), d&d.. et.c.
20:17  * estan wonders too.
20:18 < boemann> http://img691.imageshack.us/img691/2861/docker.png
20:19 < boemann> as you can see right now the styles section is too tall in relation to the others
20:19 < boemann> though there is a scrollbar
20:19 < colomar> ah ok. But that still doesn't allow to see many styles at a time
20:20 < boemann> exactly
20:20 < boemann> so a popup is needed
20:20 < boemann> just like when chosing fonts
20:20 < estan> yes, that's what i mean when i say discoverability. i mean the user can find the styles docker easy enough, but with just a combobox there won't be any way to see the available styles without clicking.
20:20 < boemann> or popup on hover
20:20 < estan> hm. ok.
20:21 < colomar> Hover is problematic
20:21 -!- ZaggeM [[email protected]] has quit [Quit: Lost terminal]
20:21 < colomar> It always has the problem that it disappears if the cursor moves outside of its boundaries
20:21 < estan> as you can hear i'm a little sceptical, but sure lets roll with it and see where it gets us ;)
20:22 < colomar> Here's what I think of it so far:
20:22 < colomar> Many office suites use a combo box to choose styles and that works okay
20:22 < estan> with this compact styles docker, how would the user go about editing the properties of a style? would the items in the combobox be pimped up items of some kind, with minibuttons for bringing up properties?
20:23 < colomar> But for users who use styles very often, a list box is much more convenient
20:24 < colomar> So we should still allow those users to add a docker with a list to their sidebar
20:24 < boemann> i use styles a lot but would still prefer a popup thing
20:24 < colomar> Why?
20:24 < estan> aye, interacting with a combobox is more fiddling.
20:24 < boemann> because when i still spend most of the time writing
20:25 < colomar> ?
20:25 -!- ZaggeM [[email protected]] has joined #calligra-styles-ui
20:25 < boemann> even if i change style every so often, i still spend much more time on typing
20:25 < colomar> But on a widescreen you don't need the horizontal space anyway, so a sidebar won't hinder you
20:26 < boemann> says who, i certainly would like as much horizontal space i can get
20:26 < boemann> and i have a widescreen
20:26 < colomar> What for? To zoom in extremely?
20:26 < boemann> zoom out more likely so i can see a page width and still make out the letters
20:27 < estan> why do you spend more time typing with a combobox vs. a list? not sure i understand.
20:27 < boemann> estan: i don't
20:27 < boemann> i spend more typing than choosing styles
20:28 < colomar> You might want a maximum of horizontal space, okay. But there was a Reason why the KOffice team originally came up with a docker bar to the right
20:28 < ZaggeM> the docker is also used in e.g. stage
20:28 < colomar> And I still find that reasonable
20:28 < boemann> how i choose styles offcourse needs to be efficiennt, but related to having a good overall ui having a list is not that important
20:28 < colomar> Of course we should not force users to have one
20:28 < boemann> not forcing is one, and i still whant the left side for dockers
20:29 < estan> alright, i get your argument now.
20:29 < colomar> But I know many many users for whom vertical space is a lot more precious than horizontal space
20:29  * estan raises hand.
20:29 < boemann> well horizontal is more important if you will be srolling left and right while you type
20:30 < colomar> True, but not all users use zoom levels that would require that
20:30 < colomar> This is really a matter of personal preference
20:31 < boemann> it's not about zoom levels but screen size
20:31 < boemann> anyway
20:31 < colomar> And of Screen aspect ratio and size
20:31 < colomar> yes
20:31 < boemann> it should be flexible enough to accomodate all users
20:31  * estan agrees.
20:32 < colomar> totally agree
20:32 < boemann> and having a popup for a list of styles doesn't seem that big a sacrifice to me
20:33 < PierreSt> but if this is the case, then the interaction with the popup should be minimal
20:33 < colomar> So what would be the disadvantage if a user chooses to add a separate, taller docker for styles if she finds a list more comfortable than a combo box?
20:33 < boemann> none
20:33 < colomar> Ok.
20:34 < boemann> colomar: well except you would get back in to the flickering
20:34 < PierreSt> i mean: if we have a popup, it should already be populated with either (and only) the headings or char or parag
20:34 < colomar> boemann: yes
20:34 < boemann> PierreSt: yes
20:34 < PierreSt> which means that the choice of styel type should be available before the popup
20:35  * boemann much more interested in the design of the list than of: list or popup
20:35 < estan> +1
20:35 < colomar> yes
20:35 < PierreSt> i reiterate what i said with the list then
20:36 < PierreSt> i find that this mixture of headings/char/parag style overly confusing
20:36 < colomar> absolutely
20:36 < PierreSt> in one common list
20:36 < boemann> actually PierreSt brought up something i've been thinking about: do we want two lists. one for char and one for parag
20:36 < boemann> i for sure think the tree structure is too complex
20:37 < boemann> i get it, but am sure no normal user does
20:37 < PierreSt> the thing is:
20:37 < estan> i don't even understand it. i did once but now i've forgotten it.
20:37 < colomar> Basically I'd say yes. What we should consider, though, is the fact that paragraph styles are probably used a lot more than character styles
20:37 < PierreSt> a paragraph style is composed of two entities:
20:37 < PierreSt> the character style of the paragraph, and the "layout" style of the paragraph
20:38 < PierreSt> and here comes the confusion
20:38  * boemann uses parag styles much more yes, but i also heavily use char styles
20:38 < colomar> Maybe we should start with thinking about when which is used when
20:38 < boemann> ms word solves this by listing the parag styles at the beginning of the list and char styles below
20:38 < PierreSt> so you have orphaned char styles, and char styles which belongs to a paragraph style
20:39 < boemann> also ms word has the filter of only showing styles in use
20:39 < ZaggeM> a paragraph style has always a char style in itself
20:39 < PierreSt> i think this is good for the docker
20:40 < PierreSt> ZaggeM: does it have to define one?
20:40 < ZaggeM> PierreSt: in the end it will use the default
20:40 < boemann> well if it doesn't define it's properties it will fall back to defaults
20:40 < ZaggeM> :-)
20:41 < boemann> so colomar asked about uses
20:41 < PierreSt> which means that a parag style do not necessarily have (ie, own) a char style
20:42 < colomar> We're in danger of getting too technical here
20:42 < PierreSt> it could well only define the "layout" properties
20:42 < boemann> PierreSt: no it has also char properties
20:43 < boemann> i use parag style both to set the font and the layout of a paragraph
20:43 < boemann> like for example a headline
20:43 < ZaggeM> PierreSt in odf it does have but as all is inherit it does not need to set properties
20:43 < boemann> or main text
20:43 < colomar> We should focus back on users and uses. Users neither know nor care about properties, inheritance, embedded styles or anything like that ;)
20:43 < PierreSt> my question was not if it can have char properties, but if it must have char properties
20:43 < boemann> if i wan't my headlines to have different size i then edit the headline (parag) style, but it's char properties
20:44 < PierreSt> which ZaggeM answered
20:44 < boemann> colomar: not completely true, all of those things are commonly exposed to users
20:45 < estan> alright, but the parent child relationsship between parag and char styles, what's the point of exposing that to users?
20:45 < colomar> exactly
20:45 < ZaggeM> no use
20:45 < PierreSt> estan: i don't think there is any in the docker
20:45 < boemann> none afaict
20:45 < estan> is there currently any way for the user to define a char style that two parag style uses?
20:45 < colomar> The fact that it's exposed to them doesn't mean it's useful
20:45 < estan> and would there be any point in giving that power to the user?
20:45 < ZaggeM> and in odf there is no separation
20:46 < PierreSt> estan: that power could be given but i don't think the docker is the place for that
20:46 < estan> PierreSt: i agree.
20:46 < boemann> uhm a parag style can't inherit a char style afaik
20:46 < colomar> I'd think the difference between char and paragraph styles from a user's point of view is a lot more simple:
20:46 < estan> boemann: sorry i probably phrased it bad. the parag style has a char style, can two parag styles have the same char style?
20:46 < colomar> When I want to change the appearance of a paragraph, I use a paragraph style
20:46 < ZaggeM> estan: no
20:47 < estan> ZaggeM: aight.
20:47 < colomar> If I want to change only the appearance of some words/chars within a paragraph, I use a char style
20:47 < boemann> colomar: exactly
20:47 < estan> right.
20:47 < PierreSt> ZaggeM: can't two named parag style use the same named char style in odf?
20:47 < ZaggeM> estan: in odf the paragraph and char style is on style
20:47 < ZaggeM> PierreSt: not in odf
20:48 < colomar> So we should focus on that distinction instead of thinking about any technical implications
20:48 < boemann> a parag style has parag and char propertiesn, it doesn't have styles
20:48 < estan> ZaggeM: ah.
20:48 < colomar> Technical stuff is important, but should be considered later
20:48 < ZaggeM> PierreSt: it can't evenuse one named char style
20:48 < boemann> the entire parag style can inerit from another entire parag style
20:49 < boemann> colomar: that destinction is also what happens echnically
20:49 < boemann> technically
20:49 < boemann> so
20:49 < boemann> question is how to present styles to the user
20:50 < colomar> Yes.
20:50 < ZaggeM> different icons
20:50 < ZaggeM> ?
20:50 < estan> i'm all for having two lists, one for parag styles and one for char styles.
20:50 < PierreSt> i think we should first visually segregate 3 different types: characters, paragraph, headings
20:50 < colomar> Wait. Let's see if we might be able to find a smarter solution
20:51 < colomar> Why do we need heading styles? Are those really different than paragraph styles?
20:51 < PierreSt> technically no
20:51 < ZaggeM> not in my pov
20:51 < PierreSt> but for me a title is different than a paragraph
20:51 < boemann> 1) you can have both a current parag style plus a current char style, at THE SAME time
20:51 < boemann> heading and parag styles are one and the same
20:51 < ZaggeM> all is different but still it is onlz a style
20:52 < boemann> just more properties set
20:52 < colomar> Let's focus on the use cases again
20:52 < PierreSt> boemann: yes technically a heading and a paragraph style is the same
20:53 < PierreSt> however if i present you a piece of text and tell you, point me a paragraph, will you point me the title?
20:53 < colomar> What if we do what KDE generally hates to do but often still helps the user: Guessing what the user wants to do?
20:53 < ZaggeM> I think we need an easy way to set a style
20:53 < colomar> My suggestion:
20:53 < ZaggeM> also it should allways be visible which style is used at thr moment
20:53 < boemann> colomar: i my view guessing is always bad, but go ahead
20:54 < colomar> Not necessarily. Only if done bad and there is no way around the guess
20:54 < boemann> ZaggeM: but there are both a current parag and char style
20:54 < ZaggeM> boemann: not allways
20:55 < boemann> true, but i can be in a body text paragraph with a word in "emphasis" char style
20:55 < colomar> If the user selects a whole paragraph, she will most of the time want to set the paragraph style for it. There still has to be a way to set a char style to a whole paragraph, but it should be easier to set the paragraph style at that point
20:56 < boemann> colomar: i don't want to select a whole paragraph in order to change it's style
20:56 < colomar> If the user selects only a word or character within a paragraph, it is _very_ unlikely she wants to set a paragraph style for it
20:56 < boemann> true
20:56 < colomar> boemann: true
20:56 < colomar> So if nothing is selected, it's paragraph style
20:57 < colomar> Because you don't want to set the char style for "nothing"
20:57 < boemann> right
20:57 < boemann> well
20:57 < ZaggeM> not sure if that is right
20:57 < boemann> i might want to be able to see the stye i wil begin typing with
20:57 < PierreSt> colomar: not really, you might want to select the char style of what you are going to type
20:58 < ZaggeM> I often e.g. change the font size before I start typing
20:58 < boemann> me too, except i choose a char style :)
20:58 < colomar> yes, but usually you change it before you start a new paragraph, don't you?
20:58 < PierreSt> not necessarily
20:58 < PierreSt> if i want to add something in the middle of a paragraph (like a citation)
20:59 < boemann> +1
20:59 < colomar> Yes. I don't say it never happens
20:59 < colomar> That's why we still need to support it
21:00 < colomar> I'm just not sure if we have to present both kinds equally prominently at all times
21:00 < ZaggeM> but from what I read here it sound most likely we should have two different thinks char and paragraph styles at the same time
21:00 < colomar> I'm not offering completely thought-through solutions here. I'm just trying to think "out of the box" a little
21:01 < boemann> colomar: sure, and so do we
21:01 < boemann> two lists is not common at all
21:02 < boemann> filtering yes
21:02 < PierreSt> i think we should in a first step present the categories, to the user, then display the list of the pointed category in a second stage
21:02 < boemann> that is how ooo does it
21:02 < PierreSt> a bit like the Lancelot launcher
21:02 < colomar> But then there is yet another click
21:02 < boemann> but it adds another step :(
21:02 < colomar> yes
21:03 < PierreSt> or mouse over, but the user is already disrupting his typing
21:03 < PierreSt> to grab his pointing device
21:03 < boemann> colomar: well not if the choises are selected already in the dopopupstage
21:03 < ZaggeM> we could have a tabbed docker on for paragraph and one for char styles
21:04 < ZaggeM> or a selector for the different styles
21:04 < PierreSt> so i don't think that this small extra step is worse than a visual complex docker all the time
21:04 < boemann> i'm beginning to agree
21:05 < boemann> i've been very torn on this issue
21:05 < PierreSt> we could also think at providing (keyborad) shortcuts for setting specific syles
21:05 < estan> i'm not sure i understand, "in a first step present the categories", how would that look, UI-wise?
21:05 < PierreSt> without disrupting the typing ork flow
21:06 < boemann> two buttons, each pop up their own list
21:06 < ZaggeM> I would more likely prefer a switch between paragraph and char styles
21:06 < colomar> I'm sorry I don't have KOffice nor Calligra installed at the machine I'm currently at, so could you please tell me how it currently behaves:
21:06 < PierreSt> estan: have you got Lancelot app launcher?
21:06 < estan> PierreSt: no :/
21:06 < ZaggeM> boemann: we should still display the current style to the user
21:06 < colomar> What happens if i place the cursor somewhere (without selecting anything) and change apply a paragraph style
21:06 < colomar> ?
21:06 < PierreSt> well: it functions a bit like OS X finder
21:07 < boemann> ZaggeM: sure but that is just what is painted on the button
21:07 < colomar> Is it applied to the paragraph the cursor currently is in?
21:07 < ZaggeM> boemann: ???
21:07 < estan> PierreSt: haven't used that either ;)
21:07 < boemann> colomar: the parag is style is changed
21:08 < boemann> ZaggeM: nevermind i agree with you
21:08 < PierreSt> estan: well imagine you have the docker with just two lines: paragraph >, and character >
21:08 < estan> PierreSt: right.
21:08 < colomar> And what happens if I apply a character style?
21:08 < PierreSt> when you hover one line, a list appears next to it with all the corresponding styles
21:09 < boemann> colomar: it sets the current charstyle that you will write any new text with
21:09 < ZaggeM> PierreSt: I don't like this approch
21:09 < colomar> Oh. So paragraph and char styles behave quite differently
21:09 < estan> PierreSt: alright, so the idea is just two lists?
21:09 < estan> (or well, combo boxes)
21:10 < colomar> One changes things that are already written, the other doesn't
21:10 < boemann> colomar: well if you have selected a range of text and select a char style it will be applied to that text
21:10 < ZaggeM> PierreSt: for our use cas we could show 2 drop down boxes and use the same space but have more information
21:10 < PierreSt> well, i just described the thing at concept level, not visual representation
21:11 < ZaggeM> colomar: the behaviour boemann describes is what I expect as user
21:11 < colomar> ZaggeM: Yes, it is
21:12 < boemann> The one bad thing about two lists is that you can have a situation where there is no current  char style (new text will be using the font properties of the parag style)
21:12 < colomar> But that means they do quite different things with those and we should probably treat them more differently than just place to comboboxes next to each other
21:12 < PierreSt> ok, i have a bit of a situation here, i'll leave the computer on, but won't be in front of the keyboard for a while
21:12 < PierreSt> so i can catch up later
21:12 < boemann> PierreSt: okay
21:13 < estan> boemann: well wouldn't the combobox/whatever show Character Style: None then or something?
21:13 < colomar> boemann: I don't really see a problem here. We can just display "none" for the current char style
21:13 < boemann> colomar: maybe, but both ooo and msword doesn't care 
21:13 < boemann> colomar: sure
21:14 < boemann> estan: sure too
21:14 < ZaggeM> boemann: we could have an entry in the char list saying use char style from paragraph
21:14 < boemann> ZaggeM: good point
21:14 < boemann> actually this makes a lot of sense to me
21:15 < colomar> So does every paragraph style always have a corresponding char style?
21:16 < boemann> no
21:16 < ZaggeM> I think we all say these are 2 different thinks so e should treat them differently
21:16 < ZaggeM> colomar: depends on how you see it
21:16 < boemann> colomar: a parag style define char properties, but is not related to char styles at all
21:16 < boemann> colomar: so only if you don't have an overruling char style will the the char properties of the paragraph style be sued
21:17 < boemann> used
21:18 < boemann> and being allowed to set the char style back to none means that we ones again rely on what the parag style defines
21:18 < colomar> I'd still think "none" would be less confusing than "use char style from paragraph", since we want to present these two as pretty much unrelated
21:18 < ZaggeM> colomar: that is fine by me too
21:19 < boemann> yes but it could be like: "NONE, what is shown relies on the current paragstyle"
21:19 < colomar> Theoretically, but that would be a bit long to fit in a list, wouldn't it?
21:19 < ZaggeM> a bit long for a combobox :-)
21:19 < boemann> explaination with small letters 
21:20 < colomar> Maybe a tooltip?
21:20  * estan tries to mock it.
21:20 < ZaggeM> it could be in a tooltip
21:20 < estan> yea tooltip is probably good idea..
21:21 < boemann> while estan mocks we could talk about list vs tree
21:22 < boemann> is there anyone in favour of showing inheritance in tree?
21:22 < boemann> or should the (pretty insignificant) inheritance oly be visible in properties
21:22 < boemann> only
21:22 < ZaggeM> tree might be more obvious
21:23 < boemann> it would show the relation for sure
21:23 < boemann> but is it relevant
21:23 < ZaggeM> but not sure it needs to be shown in the list
21:23 < colomar> I don't think it's relevant enough
21:23 < ZaggeM> we could have 2 modes
21:23 < boemann> ZaggeM: or maybe use tree in the style manager but only list here
21:24 < ZaggeM> one with tree and one without
21:24 < ZaggeM> orderd by name
21:24 < ZaggeM> which is better for selecting
21:24 < colomar> boemann's idea sounds good
21:24 < ZaggeM> what is here?
21:24 < boemann> the docker
21:24 < colomar> The inheritance only matters when creating or editing styles
21:24 < colomar> Not when selecting them
21:25 < boemann> yeah
21:25 < boemann> i can't think of a case where inheritance seem significant when selecting
21:26 < colomar> me neither
21:27 < ZaggeM> so the docker will bring up the style manager for editing styles?
21:27 < boemann> ZaggeM: i was just thinking that we may want that indeed
21:27 < colomar> Id's just place an icon next to the combo boxes to edit styles
21:27 < boemann> just with the style preselected
21:28 < colomar> yep
21:28 < ZaggeM> sounds good
21:28 < estan> http://dose.se/styles-mock.png
21:29 < boemann> estan: for concept yes
21:29 < estan> yes of course.
21:29 < boemann> i'd use icons instead of writing paragraph or character , or maybe even making it obvious from the combo itself
21:30 < boemann> or i'd may want to two have two dockers
21:30 < ZaggeM> what if there are char styles applied and I want to set it to the paragraph style?
21:31 < boemann> ZaggeM: you'd select the none option
21:31 < ZaggeM> 2 docker might be a bit much
21:32 < boemann> well for the "popped down look" of the combo i'd like to show what the style looks like
21:32 < colomar> good idea
21:33 < colomar> Just like the usual font selector
21:33 < estan> boemann: (refresh)
21:33 < ZaggeM> might be hard for the char style if e.g. only italic is set
21:33 < boemann> I'm thinking we can even show the char and parag styles differently, makinging it easier to see the difference
21:33 < colomar> Although it might be difficult to visualize char layout
21:33 < boemann> estan: yup :)
21:33 < ZaggeM> or will it use the current font to create the preview?
21:34 < boemann> ZaggeM: preview could be based on on content yes
21:34 < colomar> estan: Yes, only I'd use better Icons ;) Finding distinguishable icons for paragraph and character shouldn't be too hard
21:35 < colomar> ZaggeM: Yes, that would be good
21:35 < estan> colomar: of course, i'm just kludging this in inkscape as we speak ;)
21:35 < boemann> okay here is another question:
21:35 < colomar> Thought so ;)
21:35 < boemann> automatic styles (ie style not named)
21:35 < colomar> estan: Just wanted to make sure they don't stick ;)
21:35 < boemann> do we show them?
21:36 < colomar> hm...
21:36 < boemann> colomar: easy, we all hate the current ones ;)
21:36 < estan> boemann: no! ;)
21:36 < ZaggeM> in the text styles 
21:36 < estan> i was going to bring that up, i think showing them is bad and confusing.
21:36 < ZaggeM> where you also can set them
21:36 < ZaggeM> we should not show them as styles
21:37 < colomar> agree
21:37 < boemann> so how do we then show that what is current is a style plus some add-hoc properties
21:37 < colomar> They should not be exposed to the user at all. Unless she wants to create a new style from the current settings
21:37 < ZaggeM> so that would be mainly as it is at the moment
21:38 < colomar> boemann: Might make sense to change the appearance of the name in the combo box
21:38 < colomar> maybe add an icon
21:38 < boemann> maybe in the docker show a + sign next to the combo to show that
21:38 < boemann> :)
21:38 < colomar> something like that
21:39 < boemann> clicking on that icon/+sign could bring up the stylemanager filled out so the user can create a new named style of current settings?
21:40 < colomar> yes
21:42 < boemann> okay then
21:42 < boemann> now for the list we have:
21:42 < boemann> show as list
21:43 < boemann> single click to apply?
21:43 < colomar> yes
21:43 < ZaggeM> definitely
21:43 < boemann> an extra button on each entry to bring up the stylemanager
21:43 < estan> hm. that means no way to just select a style in the list (not apply it) e.g. in order to change its properties.
21:44 < estan> boemann: alright, problem solved ;)
21:44 < boemann> :9
21:44 < boemann> :)
21:44 < estan> i like that, it brings the action closer to what it's acting on.
21:44 < boemann> and takes up less space :)
21:45 < colomar> We'll have to see if the list doesn't look too crowded with all those buttons
21:45 < boemann> colomar: they can be visible on hover only
21:45 < colomar> boemann: Sounds good
21:46 < boemann> also only show named styles
21:46 < colomar> For that case, hover is okay, since this action is not that common so users can take a little more time to move the mouse precisely
21:46 < boemann> anything else?
21:46 < estan> yes, i want a hacker way of applying styles.
21:46 < colomar> *lol*
21:47 < estan> a key combo that brings up a type-ahead searchable list of styles.
21:47 < estan> at the cursor location.
21:47 < estan> ;)
21:47 < colomar> *ggg*
21:47 < boemann> lol suit yourself :)
21:48 < boemann> but actually we should be able to apply styles by keyboard
21:48 < estan> could maybe be done as a plugin in the future i guess. but i think i'd really like it.
21:48 < boemann> and typing the name may be the only long term solution
21:48 < colomar> It would be cool, but there are quite a few more important things to do first, I guess ;)
21:48 < estan> +1
21:49 < estan> colomar: regarding cramped lists, did you see my old mockup? http://community.kde.org/File:Styles-tree-mock.png
21:50 < boemann> yeah, i think what we have will be way less cramped
21:50 < estan> yes.
21:50 < boemann> so how should the preview of a paragraph style look
21:50 < colomar> But we should redesign the alternative tall docker as well
21:51 < estan> the Properties: [P] [C] [L] in my mockup will be just one properties button, and the apply button doesn't have to say "Apply", could be just icon.
21:51 < boemann> colomar: wouldn't it just be the same list without the popup?
21:51 < colomar> estan: I think the list docker should apply on single click as well, since that's still by far the most common action
21:52 < estan> colomar: yea, i'm with you all on that.
21:52 < colomar> boemann: Could be, yes.
21:52 < colomar> But that would be a redesign compared to its current state, wouldn't it? ;)
21:52 < boemann> colomar: that would really help our efforts if that could be the case
21:53 < boemann> yes
21:53 < boemann> but we have to do that anyway
21:53 < colomar> The only problem there is: Two lists together would take up a lot of screen space
21:53 < estan> but if the two lists are exactly the same, except for the popup part of it, then having a button next to the combobox to bring up style manager wouldn't be necessary, as that action would be available on every item in the list.
21:53 < estan> right?
21:53 < colomar> estan: yes
21:53 -!- colomar [[email protected]] has quit [Remote host closed the connection]
21:53 < estan> alright.
21:54 < estan> o noes we lost our usability man-power.
21:54  * boemann will do the preview in the near future, so would like some ideas on how the previews should look
21:55 -!- colomar [[email protected]] has joined #calligra-styles-ui
21:55  * boemann will do the preview in the near future, so would like some ideas on how the previews should look
21:55 < estan> right. how about a little window as in my mockup, but perhaps square shaped, and some kind of overlayed icon to show that hovering the preview square will bring up a full size preview.
21:55 < colomar> (sorry, client crashed. What did I miss?)
21:55 < estan> colomar: we waited for you ;)
21:55 < boemann> colomar: nothing
21:55 < colomar> thx
21:56 < boemann> estan: well first of all i'd like to use the entire entry to be a preview
21:56 < boemann> the text of the preview could be the name
21:56 < colomar> yes
21:57 < colomar> like all good font selectors do ;)
21:57 < boemann> yeah
21:57 < estan> boemann: okay.
21:57 < colomar> Visualising paragraph styles would be more tricky, though
21:57 < boemann> yeah
21:57 < boemann> as there are many more things that can happen
21:57 < colomar> Alignment might be doable if we use a little extra width
21:57 < boemann> including drop caps and line spacing
21:58 < colomar> (although it might be hard to tell justify from center
21:58 < colomar> )
21:58 < boemann> colomar: or a small symbolic representation
21:58 < estan> hm.. i think it's better for the list to just show the character properties of the style, and if you really want a full-blown preview of all the character properties, there could be a button to bring that up.
21:58 < boemann> like the icons on the buttons that chose
21:59 < colomar> estan: Or a tooltip instead of a button
21:59 < boemann> so char properties plus a small iconic preview
21:59 < estan> colomar: yes.
21:59 < boemann> and a popup yes
21:59 < estan> i think tooltip is a good idea, or maybe that's abusing tooltips?
21:59 < boemann> popup/tooltip
21:59 < colomar> estan: no
21:59 < colomar> I don't think so
21:59 < boemann> no krita does the tooltip thing with great success
22:00 < boemann> in it's layer box
22:00 < estan> alright.
22:00 < estan> but regarding the two lists, should we have a tabbed styles docker then, one tab with the list for character styles and another with the styles for paragraph styles?
22:01 < colomar> hm maybe
22:01 < boemann> still i think a small iconic representation is good too
22:01 < boemann> estan: i'd like them side by side and not tabbed
22:01 < colomar> boemann: I'm not sure. Maybe we should do a hi fidelity mockup of it and see if it looks good
22:01 < boemann> colomar: yeah
22:01 < estan> alright. but that will be one big docker.
22:02 < boemann> estan: yeah we'd have to experiment
22:02 < boemann> also for font size i don't think we should do actual representation
22:02 < boemann> only to an extent
22:03 < boemann> otherwise the text might become too big
22:03 < estan> yea, naturally there must be some limit.
22:03 < estan> hm. should both the compact and the big docker have buttons to add/remove styles?
22:04 < boemann> good question
22:04 < boemann> remove should be a popup on each entry
22:04 < boemann> as we don't select anymore
22:04 < colomar> yes
22:04 < estan> ah right.
22:04 < estan> but, popup? you mean a little pushbutton?
22:04 < boemann> yes
22:05 < estan> k.
22:05 < colomar> but appearing on hover
22:05 < colomar> like the edit button
22:05 < boemann> yes
22:05 < estan> yea.
22:05 < colomar> The big docker should definitely have an add button. I'm not entirely sure about the compact one, though...
22:06 < estan> yea me neither.
22:06 < boemann> me neither
22:06  * ZaggeM goes to bed
22:06 < boemann> g'night ZaggeM
22:06 < estan> good night.
22:06 < colomar> n8
22:06 < ZaggeM> was good to be here and see all the nice ideas
22:07 < estan> layout-wise it would be easier if it didn't have one. but for someone working with just the compact docker, how would he/she add a style then?
22:07 < boemann> you know the +sign next to current is a kind of add button already
22:07 < ZaggeM> but I have to say using the N900 as ird client is not easy
22:07 < boemann> ZaggeM: :)
22:08 < colomar> ZaggeM: I can imagine that
22:08 < estan> boemann: hm. plus sign? was this discussed earlier? or is it something that is there now? i must have missed that during a smoke break.
22:09 < colomar> estan: It is a button to add a modified style as a new one
22:09 < estan> ah.
22:09 < boemann> next to combo
22:10 < estan> ah. but in addition to that, could we not just have one item (the last?) in the combobox be "+ Add new" or something?
22:11 < boemann> could work
22:11 < colomar> hm maybe
22:12 -!- ZaggeM [[email protected]] has quit [Ping timeout: 240 seconds]
22:12 < boemann> a little bit weird but could be made to look good
22:12 < boemann> it wouldn't be an entry but just some buttons that would be scrolled too
22:13 < boemann> hmm
22:13 < estan> yea. i've seen that approach used in some places. e.g. for filters in gmail if you've used that. it's a little wonky, but works.
22:14 < colomar> btw: I would place the button to add a modified style as a new one inside the combobox next to the current style as well, not next to the box
22:14 < boemann> colomar: yes
22:15 < estan> yes, i think that makes sense to, brings it closer to what it's related to.
22:15 < estan> it will be one pimped out combobox ;)
22:15  * estan back in 5.
22:16 < boemann> colomar: meanwhile in the first screenshot i showed
22:16 < boemann> in the top right corner there is a lock icon
22:16 < boemann> this brings up a titlebar for the super docker
22:16 < boemann> and unfixes the the size of the docker
22:17 < boemann> when locked the docker can not be moved or resized
22:17 < boemann> preventing flicker
22:17 < boemann> the scroll bar appears if the stuff inside is too large
22:18 < colomar> cool. That's pretty much what we had envisioned together, isn't it?
22:19 < boemann> yes
22:19 < boemann> i'm not sure if we have a build service set up for calligra yet
22:20 < boemann> but otherwise you might be able to try it out
22:21 < boemann> there is some details yet to be ironed out, and i stil need to do a tabbed mode
22:22 < colomar> I won't be able to try it this year anyway, since I'm at my parents' without my laptop and don't want to install anything on their machine
22:22 < colomar> So I can only try it when I'm back home
22:23 < estan> so, do we have any more burning issues regarding the styles UI to discuss? while we haven't covered everything naturally, i think we've concluded quite a bit already. it's a start at least.
22:23 < estan> tomorrow i'll re-read our conversation and summarize it on the wiki, and do a more serious first mockup sketch.
22:24 < estan> and then you can all comment on what i got wrong ;)
22:27 < estan> for now, i'll just put up the IRC log.