Design/Meetings/2013-12-29

Attendees

 * astron
 * LLyaudet
 * mahfiaz
 * mirek2

Topics

 * Minimum target size
 * Options

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