Design/Meetings/2013-12-29

From The Document Foundation Wiki
Jump to: navigation, search

Attendees

  • astron
  • LLyaudet
  • mahfiaz
  • mirek2

Topics

  • Minimum target size
  • Options

Log

[12:01] <mirek2> hi guys
[12:01] <LLyaudet> hi everyone
[12:02] <mirek2> what topics would you like to discuss today?
[12:03] <LLyaudet> I have no topic in particular except for the minimum target sizes you proposed
[12:04] <mirek2> ok, cool
[12:04] <mirek2> are there any UX bugs in LibreOffice that really bother you?
[12:04] <mirek2> for the upcoming UX hackfest...
[12:06] <LLyaudet> I don't know. I filled some bug reports but I don't think they have high priority
[12:08] <mirek2> feel free to post links to the bug reports to the mailing list
[12:08] <mirek2> so thath they get some attention
[12:08] <mirek2> (I plan to do the same with my own bug reports)
[12:08] <LLyaudet> ok
[12:10] <mirek2> ok, let's get to the minimum sizes, then
[12:10] <mirek2> you were talking about shapes
[12:10] <mirek2> however, I see two problems with that:
[12:11] <mirek2> a) defining target by area has its own problems
[12:12] <mirek2> (e.g. area 144 could mean 12x12 or 1x144, the latter being very hard to target)
[12:13] == atrons [bc66b00b@gateway/web/freenode/ip.188.102.176.11] has joined #libreoffice-design
[12:13] <LLyaudet> I was thinking that maybe we can ask that the target must *contain* a square with minimum dimensions
[12:13] <LLyaudet> or a rectangle
[12:13] <LLyaudet> hi astron
[12:13] <atrons> hi all
[12:14] <mirek2> well, if I'm not mistaken, the common practice is to use rectangular target sizes even for small non-rectangle widgets
[12:14] <mirek2> (e.g. circular radio buttons)
[12:14] <mirek2> not sure if that's the current LibreOffice behavior, though
[12:15] <mirek2> (from my quick test now, it seems to be)
[12:16] <mirek2> I'd agree to "the target area must be big enough to fit a 6x6px square"
[12:16] <mirek2> ha atrons
[12:16] <mirek2> hi
[12:17] <mirek2> talking about minimum target sizes right now
[12:17] <mirek2> see https://wiki.documentfoundation.org/User:Mirek2#Targets
[12:18] <mirek2> (reasoning in the mailing list)
[12:18] <LLyaudet> I agree but maybe we should lower it to 5x5 or modify the target between column headers
[12:18] <mirek2> we should modify the target
[12:18] <LLyaudet> *in calc
[12:19] <LLyaudet> ok
[12:19] <mirek2> we shouldn't bend the guidelines to the current behavior
[12:19] <mirek2> guidelines should lay out the ideal behavior, then we need to modify LibreOffice to fit it
[12:20] <mirek2> now for the phrasing...
[12:21] <mirek2> would it be enough to just replace "6px" and "7mm" with "6x6 sq. px" and "7x7 sq. mm"?
[12:22] <atrons> btw, http://lunabarrow.com/yubi
[12:24] <mirek2> thanks for the link
[12:24] <atrons> (would be a lot more practical if libo were a web app, but still...)
[12:24] <mirek2> or a smartphone app... (don't think thumbs apply all that much here)
[12:25] <mirek2> I guess the tough target size should be defined as a radius
[12:25] <LLyaudet> 7mm seems to be the diameter
[12:26] <mirek2> yup
[12:27] <LLyaudet> possible phrasing : mouse target size : a mouse target (of any shape) must be bigger than a 6x6 px square
[12:28] <LLyaudet> touch target size :  a touch target (of any shape) must be bigger than a 7mm diameter disk
[12:29] <atrons> note that the yubi bookmarklet also adds a little distance.
[12:29] <atrons> (to its touch target)
[12:30] <LLyaudet> maybe "be bigger" is not precise and could be interpreted like "has bigger area" so maybe we should use "be big enough to fit" as you suggested
[12:31] <mirek2> how about this: https://wiki.documentfoundation.org/User:Mirek2#Targets ?
[12:32] <mirek2> atrons: should we define minimum margins as well?
[12:33] <LLyaudet> it sounds good, just a typo : targets should *be* as large
[12:33] <mirek2> yup, will fix that
[12:33] <mirek2> atrons: what do you think?
[12:34] <atrons> to make it sound more natural: "should be large enough to fit:"
[12:34] <mirek2> sounds good
[12:35] <atrons> also, the distance should be in the guideli8nes somewhere, but it is actually only necessary for targets that are the bare minimum size
[12:36] <atrons> (if theres a large object that doesnt have any dsistance aroudn there is no problem)
[12:36] <atrons> ^li8nes^lines
[12:36] <atrons> ^dsistance^distance
[12:36] <mirek2> how would you phrase it, then?
[12:38] <LLyaudet> a mouse target must be large enough to fit a 8x8 px square or must be separated from any other target by at least two pixels ?
[12:38] <atrons> nah, the distance is more necessary for touch
[12:39] <atrons> targets under 10mm² must have a distance of at least 1mm to all neighbouring elements?
[12:40] <mirek2> a circle with a 8mm diameter for touch targets and their margin?
[12:40] <mirek2> atrons: where's that 10mm coming from
[12:40] <mirek2> ?
[12:40] <atrons> uhm ... well not sure
[12:41] <atrons> right, lets use the same 7mm we use elsewhere
[12:41] <mirek2> also, think about the segmented control in Gnome
[12:41] <atrons> segmented control? what do you mean?
[12:42] <atrons> the "tabs"?
[12:42] <mirek2> yup
[12:42] <mirek2> take the stack switcher, where the buttons are wide, but don't have any room between them
[12:42] <mirek2> say the height of the target area was 7mm
[12:43] <atrons> as i said, these are usually large (rather, wide) targets, its not necessary to have 1mm distance to elements to the left and right of theses
[12:43] <mirek2> yup
[12:43] <atrons> but since they're not very high, they need space at the top and bottom
[12:43] <mirek2> yup
[12:44] <mirek2> let's incorporate that into the wording somehow
[12:44] <atrons> so, lets say, we care about thumbs too (because, i think tablets are still mostly used with thumbs)
[12:45] <atrons> (the other 8 fingers are motlsy used to hold the tablet when writing)
[12:45] <atrons> ^motlsy^mostly
[12:45] <LLyaudet> I googled "stack switcher" and "gnome stack switcher" but it doesn't help. Can you provide a screenshot for that ?
[12:45] <mirek2> at least I think it's the stack switcher
[12:46] <atrons> LLyaudet: "stack switcher"? never heard that name either
[12:46] <mirek2> hm, then I'm not sure what it's called...
[12:46] <mirek2> in any case, I meant the tabs at https://github.com/gnome-design-team/gnome-mockups/raw/master/music/music-albums.png
[12:47] <mirek2> https://developer.gnome.org/gtk3/3.10/GtkStackSwitcher.html
[12:47] <mirek2> here it is
[12:47] <LLyaudet> thanks
[12:47] <atrons> mirek2: wasnt saying that stack switcher is wrong, just that i never heard this name
[12:48] <mirek2> atrons: right, but I wasn't completely sure it was the name to begin with
[12:50] <atrons> in any case, maybe the guideline could be our 7mm guideline + "together with its margins, every element must fill at least a 10mm² square" (8mm thumb + 2 mm margin)
[12:50] <mirek2> why not a circle?
[12:51] <mirek2> (given that we define the min. touch target as a circle)
[12:51] <mirek2> also, I'd prefer to define things for thumbs and other fingers separately
[12:51] <mirek2> (not all targets will be for thumbs)
[12:52] <atrons> why? are there elements that can never be used with a thumb?
[12:52] <mirek2> there are elements that are unlikely to be used with thumbs
[12:53] <LLyaudet> for the mathematical precision, pi*r² = pi*25 ~= 78,5 mm²
[12:54] <mirek2> we're defining by diameter, not by area
[12:54] <LLyaudet> yes but mm² is an area
[12:54] <mirek2> (I think 10mm^2 was meant as 10x10, not as having an area of 10)
[12:55] <LLyaudet> ok
[12:55] <atrons> so, do you want different guidelines for buttons at the bottom (probably used with thumbs at least sometimes) and those at the top (unlikely to be used by thumb)
[12:55] <atrons> ?
[12:56] <mirek2> I wouldn't mind leaving thumbs out of the picture, but if we are to incorporate thumbs, have separate guidelines for them
[12:57] <mirek2> also, I'd leave the areas where thumbs are used up to third-party research
[12:57] <atrons> what does third-party research say then?
[12:58] <mirek2> can't find anything right now...
[12:58] <atrons> (my example made sense for me...)
[12:58] <atrons> ^for me^to me
[13:00] <mirek2> how about this: https://wiki.documentfoundation.org/User:Mirek2#Targets
[13:00] <mirek2> a circle with an 8mm diameter for a touch target together with its margins, a 10mm diameter for thumbs
[13:01] <mirek2> about leaving thumbs out: remember that we're talking about minimum touch targets, not ideal touch targets
[13:02] <mirek2> we could go ahead and define ideal touch targets as well
[13:03] <atrons> well, ideal touch targets will be different for everzbodz.
[13:04] <mirek2> e.g. Android defines recommended target sizes as 7-10 mm
[13:04] <mirek2> http://developer.android.com/design/style/metrics-grids.html
[13:05] <mirek2> WP as 9mm: http://www.lukew.com/ff/entry.asp?1085
[13:06] <atrons> and indeed, i think windows phone is pretty easy to touch...
[13:06] <atrons> (its miles better than the iphone)
[13:08] <atrons> anyway ... so, i wouldnt oppose defining a range, same as you quoted for android
[13:08] <mirek2> so... do we agree to go without thumbs for minimum target sizes?
[13:08] <mirek2> and otherwise just go with https://wiki.documentfoundation.org/User:Mirek2#Targets ?
[13:09] <atrons> 7+1 v/ 8+2... whats the point of not including thumbs? the difference is not that large
[13:10] <mirek2> well, we are talking about minimum target sizes
[13:11] <mirek2> so if we have a target that might be more comfortable for thumbs, it can still be hit with other fingers
[13:12] <atrons> i dont get what you are saying
[13:12] <mirek2> :) ok
[13:12] <mirek2> let's just go with thumbs
[13:13] <atrons> thanks... that should make the rules simpler for everyone
[13:15] <mirek2> added: https://wiki.documentfoundation.org/Design/Guidelines#Targets
[13:16] <mirek2> do we want to define the recommended sizes now, or should we suggest sizes on the ml and decide next week?
[13:18] <LLyaudet> recommended sizes are more complicated, as said in your links it depends of the frequency
[13:20] <mirek2> so let's decide next week then
[13:20] <mirek2> other topics?
[13:21] <mirek2> we could resume going through the options we have
[13:21] <LLyaudet> ok
[13:27] == Enervation [4a4817bd@gateway/web/freenode/ip.74.72.23.189] has joined #libreoffice-design
[13:27] <mirek2> hi Enervation
[13:28] <Enervation> hi everyone
[13:28] <LLyaudet> hi
[13:28] <atrons> hi
[13:29] <mirek2> Enervation: any topics you'd like to talk about?
[13:29] <mirek2> if not, we could go through options
[13:29] <Enervation> sure
[13:29] <mirek2> https://wiki.documentfoundation.org/Design/Whiteboards/Options/Writer
[13:30] <mirek2> seems we left off at https://wiki.documentfoundation.org/Design/Whiteboards/Options/Writer#Display
[13:32] <mirek2> Graphics and objects
[13:33] <atrons> hm, inkscape has something similar and it can greatly help performance
[13:33] <atrons> (referring to the first option)
[13:33] <mirek2> let's keep it "Generic"
[13:33] <atrons> but in inkscape it is in the menu which makes it much more practical to toggle
[13:33] <mirek2> as it can be key to usability on older machines
[13:34] <mirek2> so... Contextual, and move to View menu?
[13:35] <atrons> i think
[13:35] <mirek2> ok, agreed
[13:35] <mirek2> others: shout if you disagree, otherwise we move on
[13:35] <mirek2> there's a lot of options to go through, so I won't wait for consensus from everyone
[13:36] <atrons> tables -- not otherwise known asa performance hog
[13:36] <LLyaudet> ok
[13:36] <mirek2> atrons: not?
[13:36] <atrons> i would try to see where this is coming from and remove it if possible
[13:36] <mirek2> yup
[13:37] <atrons> mirek2: do you have problems with them?
[13:37] <atrons> (you definitely have the slower machine)
[13:37] <mirek2> not really
[13:37] <mirek2> then again, I don't really have documents with long tables
[13:38] <mirek2> something we might want to think about doing, though:
[13:39] <mirek2> if the document takes too long to load because of one of these things (images, tables, ...), let's not display them by default for the document and show an infobar
[13:39] <mirek2> the infobar would let the user load the elements anyway, and the option to load them would still be in the View menu
[13:40] <atrons> yup. sounds good.
[13:40] <atrons> much better than a manual checkbox, indeed
[13:41] <mirek2> so... I'd make Tables contextual as well, add them to View, and do the thing with the infobar if possible
[13:41] <mirek2> agreed?
[13:42] <atrons> ok
[13:43] <LLyaudet> ok
[13:43] <mirek2> Drawings and controls
[13:43] <mirek2> same?
[13:43] <atrons> yep, same, same & same.
[13:43] <atrons> (for the next three items)
[13:43] <mirek2> sounds good
[13:44] <mirek2> Formatting Aids -- Display of
[13:44] <mirek2> Paragraph end
[13:45] <mirek2> Advanced?
[13:47] <mirek2> (each and every one of those under "Display of")
[13:47] <atrons> yes
[13:47] <mirek2> ok, moving to Direct cursor
[13:48] <mirek2> seems the description wasn't copied correctly
[13:49] <mirek2> oh, nevermind, it was
[13:50] <mirek2> does anyone here use the cursor?
[13:50] <mirek2> what is it for?
[13:50] <atrons> right ... the last time i used this was in staroffice 5.2 or so where it was active by default (as far as i remember)
[13:50] <atrons> well, it will automatically create the right amount of paragraph breaks
[13:51] <mirek2> ok
[13:51] <mirek2> Advanced?
[13:51] <atrons> e.g. click in the middle of the page to edit, and it will create enough breaks to get you into the middle of the page
[13:51] <mirek2> right, I got it
[13:51] <atrons> sorry
[13:52] <mirek2> :) no, thanks for explaining
[13:52] <atrons> it used to be somewhat of a standout feature in older versions, so i would keep it visibile
[13:52] <atrons> ^visibile^visible
[13:53] <mirek2> if it's a useful feature, let's move it to Tools
[13:54] <atrons> tools menu? i.e. contextual?
[13:54] <mirek2> hold on...
[13:54] <atrons> i think people who like it leave it on all the time & people who dont keep it off all the time
[13:54] <mirek2> https://help.libreoffice.org/Writer/Direct_Cursor_On_Off
[13:54] <mirek2> it interferes with AutoCorrect
[13:55] <mirek2> so I guess contextual isn't an option
[13:55] <atrons> doesnt make much sense in a menu to me anyway
[13:56] <mirek2> hm... I'd love tosee it spun off as an extension, but I guess that's not an option
[13:57] <mirek2> it'd be good to see how useful it is...
[13:57] <mirek2> should we post about it somewhere, to judge the usefulness of the feature?
[13:58] <mirek2> (I'm still leaning towards Advanced here, it doesn't seem like a vital option to me)
[13:59] <atrons> as i said, its a nice feature that used to be on by default (presumably before autocorrect was added) ... keep it under generic
[14:00] <mirek2> hm, ok
[14:00] <mirek2> what about the Direct cursor options?
[14:01] <mirek2> Insert?
[14:01] <atrons> why? those can be advanced
[14:01] <mirek2> I assume Generic as well, as it's pretty core to the direct cursor
[14:01] <mirek2> Cursor in protected areas: Advanced?
[14:03] <atrons> yes ... not sure what its good for
[14:03] <mirek2> ok, so all the DC options advanced, except enabling it is generic
[14:03] <atrons> yep
[14:03] <mirek2> ok
[14:04] <mirek2> Grid
[14:04] <mirek2> Snap to grid
[14:05] <LLyaudet> generic I think
[14:05] <mirek2> Contextual?
[14:05] <mirek2> I wonder why this is Writer-specific...
[14:05] <LLyaudet> why contextual?
[14:05] <atrons> generic & on by default or contextual
[14:07] <mirek2> contextual because sometimes you want to snap to grid and sometimes you don't
[14:07] <mirek2> (Inkscape works that way)
[14:07] <atrons> right
[14:07] <mirek2> how does Draw handle things?
[14:07] <LLyaudet> that's why there is the Ctrl option
[14:07] <mirek2> btw, Visible Grid does nothing for me -- does it work for you?
[14:08] <mirek2> LLyaudet: it's not discoverable, though
[14:08] <LLyaudet> I agree
[14:09] <LLyaudet> Visible grid works for me but the doted lines are realy hard to see
[14:10] <mirek2> hm... visible grid works for me under Draw, but not under Writer...
[14:11] <mirek2> anyway, I'll mark it Contextual. Put it under "Edit > Snap to Grid"?
[14:12] <LLyaudet> I still prefer Generic for it
[14:12] <mirek2> we already allow snapping to grid on an item-by-item basis
[14:13] <mirek2> putting the element in the menu bar would just make it accessible to those who didn't read the manual (i.e. most people)
[14:14] <mirek2> LLyaudet: any reason why it shouldn't be in the menu bar?
[14:15] <mirek2> it's discoverable there, and faster to access, so it plays into (at least) two of our UX principles
[14:16] <LLyaudet> yes but it shouldn't be switched on and off frequently in this menu
[14:16] <mirek2> but we already have frequent on and off switching, just undiscoverable
[14:17] <LLyaudet> ok but we encourage the wrong way to switch it on and off
[14:17] <LLyaudet> if we put it in the menu
[14:18] <mirek2> if switching in the menu is "wrong," switching in Options is even wronger
[14:18] <LLyaudet> no switching with control is the good option
[14:19] <mirek2> yes, but that's undiscoverable
[14:19] <LLyaudet> The default has to stay in the option IMHO
[14:19] <atrons> in the option?
[14:20] <LLyaudet> in Options
[14:20] <LLyaudet> You go in Options to chose your default and you change when needed with Ctrl
[14:21] <mirek2> LLyaudet: please make your decisions as if the Ctrl shortcut wasn't there
[14:21] <mirek2> it's not discoverable, most users won't find out about it
[14:22] <LLyaudet> The main problem I see is that there is no text on hover of the option to say that the Ctrl shortcut exists
[14:23] <mirek2> users don't tend to look for shortcuts under Options, so I don't think a tooltip would help there
[14:23] <atrons> right, christoph noack wanted status bar text for things like that some long time ago
[14:24] <atrons> mirek2: a tooltip explaining the usage of ctrl
[14:24] <mirek2> atrons: do you have a link to the proposal? not sure what to picture...
[14:24] <atrons> well, the model was inkscape
[14:25] <atrons> if you draw/modify anything in inkscape, it will show possible modifier keys in the status bar
[14:25] <mirek2> :) funny, I never took notice of that until now that you mentioned it
[14:25] <LLyaudet> It would help since the person interested in "snap to grid" would have the information the first time he looked after it in the options
[14:26] <atrons> mirek2: right, thats a problem with it...
[14:26] <mirek2> well, I guess this isn't something we'll agree on today, so let's skip it?
[14:26] <atrons> still not too discoverable
[14:26] <mirek2> atrons: could be fixed with better design, though, maybe
[14:27] <mirek2> e.g. if it wasn't in sentences, and if keys were represented in rectangles instead of just text
[14:27] <mirek2> anyway, let's skip to Visible grid for now
[14:28] <atrons> ok
[14:28] <mirek2> Contextual, under View -> Grid?
[14:29] <mirek2> btw, I see that both View Grid and Snap to Grid are in the menu in Draw
[14:30] <mirek2> it might be good to have them in the menu in Writer as well for consistency
[14:30] <LLyaudet> ok then it should be coherent
[14:30] <atrons> i think in draw there is a toolbar that toggles the grid, too...
[14:30] <atrons> ^toggles^lets you toggle
[14:30] <mirek2> atrons: seems to be hidden by default...
[14:31] <mirek2> right: the Options toolbar
[14:31] <mirek2> (frankly, the current set of toolbars is a mess)
[14:32] <mirek2> LLyaudet: so you agree with making Snap to grid contextual in Writer?
[14:33] <LLyaudet> Yes it's better to have consistency in LibreOffice
[14:33] <mirek2> ok, great
[14:34] <mirek2> Visible grid as well, then
[14:35] <mirek2> Resolution: Generic?
[14:36] <atrons> yup
[14:36] <mirek2> Subdivision as well?
[14:36] <LLyaudet> yes
[14:37] <mirek2> basic fonts
[14:38] <mirek2> basically kind of a stand-in for Themes until they come, I guess
[14:39] <atrons> in mso, you (used to) do that by creating styles and then selecting "set as default"
[14:39] <mirek2> and based on that (and basic typography rules), there should only be two choices: Default and Heading
[14:40] <atrons> right
[14:40] <mirek2> well, we have the option to set template as default...
[14:41] <mirek2> so, agreed to make choices other than default and heading unnecessary?
[14:41] <mirek2> (keeping them would be counterproductive)
[14:42] <LLyaudet> I don't know probably someone use it
[14:42] <LLyaudet> Could be advanced
[14:43] <atrons> right ... soemone probably would, but then: use a real template.
[14:43] <mirek2> exactly -- all this functionality and much more is already part of templates
[14:44] <mirek2> and using a different font for lists, captions, and indexes is bad practice anyway
[14:45] <LLyaudet> I never read a typograpghy book saying that. I have no argument to judge it that way
[14:46] <atrons> well, even powerpoint tells you that its bad style to mix more than three fonts if you try to :)
[14:46] <LLyaudet> I'm not sure powerpoint recommendations apply for all types of document ;)
[14:47] <mirek2> one example: http://www.linguisticedge.com/pdfs/tips_for_professional_docs.pdf
[14:48] <atrons> anyway, none of that really is the point... lets move on
[14:49] <mirek2> so, agreed to make caption, index, and list unnecessary, I take it
[14:49] <LLyaudet> ok
[14:49] <mirek2> Default and Headng generic?
[14:49] <LLyaudet> ok
[14:50] <mirek2> what about Current document only?
[14:50] <LLyaudet> I have read typography books explaining a book with a different font for different elements of the text is easier to read
[14:51] <mirek2> is this just a duplicate of what you would get if you were to change the "Default" and "Headings" styles?
[14:51] <atrons> i think ive said it before, but the options are the wrong place for document-specific settings
[14:51] <LLyaudet> I agree
[14:51] <atrons> mirek2: no, those apply for all future documents (and maybe the current one)
[14:52] <mirek2> LLyaudet: http://www.learnnc.org/lp/editions/webwriting/711 : "You should use no more than three fonts per page or document: one for text, one for headings, and a third (possibly) for titles and/or decoration."
[14:53] <mirek2> atrons: I was talking specifically about the "Current document only" option
[14:53] <mirek2> is there something it offers that you can't do with styles?
[14:53] <atrons> not really
[14:53] <mirek2> (not to mention that editing the styles is about as quick if not quicker)
[14:53] <atrons> no
[14:54] <LLyaudet> mirek2: I have paper books on typography that are more professional than these recommandations
[14:54] <mirek2> provide citations :)
[14:54] <atrons> why are we discussing this?
[14:54] <atrons> this is completely beside the point
[14:55] <mirek2> in any case, themes are limited to two font choices, and given that we'll be moving to themes sooner or later, we'll also be limited to two font choices
[14:55] == LLyaudet [58ab762a@gateway/web/freenode/ip.88.171.118.42] has quit [Quit: Page closed]
[14:55] == LLyaudet [58ab762a@gateway/web/freenode/ip.88.171.118.42] has joined #libreoffice-design
[14:56] <mirek2> anyway, "Current document only" -- unnecessary?
[14:56] <mirek2> (given that Styles offer the same functionality and more)
[14:56] <LLyaudet> Lexique des règles typographiques en vigueur à l'imprimerie nationale for example (in French)
[14:57] <LLyaudet> The current advice to use no more than 2 or 3 fonts is to avoid beginners doing stupid things
[14:58] <LLyaudet> But there are cases it's nicer to use more than 3 fonts in your document
[14:58] <mirek2> LLyaudet: advanced users can always use styles (in fact, that's preferable here)
[14:58] <LLyaudet> I agree
[14:59] <mirek2> so... "Current document only" -- unnecessary, right?
[14:59] <LLyaudet> yes
[14:59] <mirek2> and the same goes for CTL fonts, of course
[15:01] <mirek2> Default button -- Generic?
[15:01] <mirek2> (it's called Standard on the wiki, but default in the dialog)
[15:01] <atrons> awesome!
[15:01] <atrons> can you file a bug about  that?
[15:02] <mirek2> I guess so
[15:03] <mirek2> anyway, Generic, right?
[15:06] <mirek2> I'll set it to Generic
[15:06] <mirek2> Print: all generic?
[15:07] <mirek2> I assume these are the same settings as in the Print dialog, only set for all documents
[15:07] <atrons> btw, default is easily misunderstood. reset to default would be much clearer
[15:07] <mirek2> agreed
[15:10] <mirek2> so Print: all generic?
[15:11] <LLyaudet> yes
[15:12] <Enervation> I have to go. Bye.
[15:12] <mirek2> see you
[15:12] <LLyaudet> bye
[15:12] == Enervation [4a4817bd@gateway/web/freenode/ip.74.72.23.189] has quit [Quit: Page closed]
[15:13] <mirek2> OK -- Table
[15:16] <mirek2> Heading
[15:17] <mirek2> I think it'd be good to remember the last option selected when inserting a table and make this option Advanced
[15:19] <atrons> right ... these are really per table options that are all also in insert > table
[15:19] <mirek2> so, mark as advanced and remember the last choice in Insert > Table
[15:21] <LLyaudet> yes
[15:21] <atrons> id like to leave now...
[15:21] <mirek2> ok to keep discussing options without you?
[15:21] <mirek2> or would you prefer to be there for that?
[15:21] <LLyaudet> I'll be leaving also
[15:22] <atrons> sure...
[15:22] <mirek2> oh, ok, lets stop then
[15:22] <mirek2> repeat on each page should be the same, though, right?
[15:22] <atrons> ok ... i guess, bye then.
[15:22] <LLyaudet> bye everyone
[15:22] == LLyaudet [58ab762a@gateway/web/freenode/ip.88.171.118.42] has quit [Quit: Page closed]
[15:22] <atrons> will you upload the log again, mirek2
[15:22] <atrons> ?
[15:22] <mirek2> yup
[15:22] <atrons> thanks.
[15:22] <mirek2> see you later
[15:22] <atrons> bye!