Design/Meetings/2013-12-29
TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate
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!