Design/Meetings/2013-12-01

Attendees

 * astron
 * mirek2
 * vsfoote

Topics

 * Controversial Start Center Topics

Log
[12:01] hi guys [12:09] let's get started [12:09] https://wiki.documentfoundation.org/Design/Whiteboards/Start_Center [12:09] let's start with "Sidebar Positioning" [12:10] my position on that is that it should be on the left [12:11] the only pro listed of having it on the right is irrelevant, as keyboard focus can start wherever [12:11] mahfiaz, Guest86117 what are your thoughts? [12:14] == astron [~work@krlh-5f71e370.pool.mediaWays.net] has joined #libreoffice-design [12:15] hi all [12:15] hi there [12:16] so far, it's been a one-man show -- you didn't miss anything [12:16] https://wiki.documentfoundation.org/Design/Whiteboards/Start_Center [12:16] oh great. [12:16] what are your thoughts on the sidebar position? [12:17] I'd keep in on the left for LTR locales, as the only pro for having it on the right is, IMHO, irrelevant [12:17] as keyboard focus is not tied to position [12:17] what would be the onlz pro? [12:17] (keyboard focus?) [12:17] https://wiki.documentfoundation.org/Design/Whiteboards/Start_Center#Sidebar_Positioning [12:18] it's the only pro listed [12:19] right ok [12:19] so, what do you think? [12:21] keep it on the left – with the added benefit that it looks a little like mso 2013's redesign of the backstage view [12:23] I wouldn't really call that a benefit (we don't want to look like a bad copy of Office), but ok :) [12:23] moving on: Icons or Thumbnails [12:23] i just had the idea of why not try to do both at once? [12:24] i. e. a coloured document shape with the thumbnail inside it [12:24] a colored document shape? [12:24] something like Chrome does, where it has a colored bottom border below each site thumbnail? [12:25] or the colored shadows that someone proposed on the mailing list? [12:25] or something completely different? [12:26] let me check [12:26] i hadnt read the coloured shadows proposal. [12:26] but in any case, the current thumbnails look pretty bad [12:27] (although one reason for that is that they dont have a common horizontal baseline) [12:27] actually, I think it's just that the grid isn't laid out well [12:28] I really like how the Gnome Documents thumbnails look [12:28] https://live.gnome.org/Design/Apps/Documents [12:28] they don't have a common baseline, but the space reserved for thumbnails is always square and the thumbnails have enough breathing room [12:29] our thumbnails are tiny and squished [12:30] as I wrote on the ml, I'd like us to adopt the same look as Gnome Documents [12:30] == Guest86117 [4094f251@gateway/web/freenode/ip.64.148.242.81] has quit [Quit: Page closed] [12:30] :) [12:30] you are right – despite the missing common baseline, gnome docs looks organised [12:31] (which is still not a saving it from being borderline useless) [12:31] (of course, but that's another matter altogether, and has nothing to do with the thumbnail overview) [12:32] right [12:33] okay, so what are they doing? [12:34] is there some way they get near same-sized thumbnails everywhere? [12:34] they have a square maximum for each thumbnail [12:34] (each thumbnail is made to fit in a square) [12:35] I'm not exactly sure what we do now [12:36] something similar, i think [12:36] == vsfoote [~chatzilla@64-148-242-81.lightspeed.snantx.sbcglobal.net] has joined #libreoffice-design [12:36] (although our thumbnails are stored in the file instead of being generated o-t-f) [12:37] that's good [12:37] eliminates the "added overhead" con [12:38] anyway, back to thumbnails vs icons [12:39] if we feel the need to differentiate thumbnails based on file type, how about adding a colored triangle to the top right of each thumbnail [12:39] mirek2: thats pretty much what i meant [12:40] ok, sounds good :) [12:40] let's go through the pros and cons listed, though [12:41] "Concise neat layout" for icons doesn't really apply -- if we had a square area for each thumbnail, like Gnome Documents does, it would be clean too [12:41] privacy -- possibly an issue, though we do have a "Clear list" option [12:41] "added overhead" -- not an issue [12:42] Icons with thumbnails on mouse over -- has the cons of both (not just the pros), plus renders thumbnails virtually useless [12:42] privacy is somewhat of a non-issue, i think [12:42] (in general) [12:42] alternative to the color triangle in corner would be a half-tone background for the tile holding the icon - or thumbnail at the full "aligned" tile size [12:43] (you'd have to mouse over each one to see the thumbnail, and given that thumbnails are there for instant recognition) [12:43] regards privacy, so long as we can implement a VCL button to immediately clear the list--should resolve any concerns [12:43] vsfoote: feel free to make a mockup :) [12:44] vsfoote: we already have a button, it's just buried in the File menu [12:44] (I already wrote to Kendy to make it more visible) [12:45] in any case, we're agreed on thumbnails with some kind of indication of file type, right? [12:45] great, it should be a straight forward issue to link the existing Recent Documents -> Clear List action to a new button on the start center [12:46] we might actually keep it in the menu, just right under File, not hidden away in a submenu [12:46] yes a color border will work from a GUI perspective, but from an a11y aspect will need full tool tips and accessible role for file type association [12:47] make that perhaps an accessible role for file type association -- as such a role does not now exist [12:47] if we have the file extension in the tooltip (which I hope we do, and I wrote to Kendy about this), that should be sufficient [12:48] guess the key would be the construction of the tool tip, we already detect what type of document to generate the thumbnail [12:49] construction of the tooltip? [12:49] isn't it enough to just show the file extension? [12:50] Not at all, the tool tip currently contains the file name [12:50] yes, currently, but if it did contain the file extension, that should be enough [12:51] (the file extension itself is more informative than the color labels) [12:51] it could be much more informative, including some of the detail others have asked for--file type being one obvious element [12:51] btw: for how i thought the thumbnails could look: https://dl.dropboxusercontent.com/u/87946285/libreoffice/Screenshot%20from%202012-07-14%2020%3A19%3A55.png (very ugly rendition) [12:52] astron: I think you linked to the wrong file [12:52] oops ... thats correct [12:52] https://dl.dropboxusercontent.com/u/87946285/libreoffice/ugly-icon.png [12:53] of course as Astron mentioned would probably be stored as attributes along with the thumbnail rendering for each [12:53] astron: I don't particularly like the idea of the thumbnail being surrounded by a border [12:53] feels jarring [12:53] mirek2: normal people dont really understand file extensions that well [12:54] having a two-line tooltip with a file type in it sounds good to me [12:54] I'd very much prefer just the top right rectangle [12:54] mirek2: we already have a border, also, the border could be just one pixel thick – as i said, its an ugly, quick example [12:55] astron: really? in my experience, people ask for "a DOC file" or a "DOCX file", but have no clue what the difference between an "Office 2003 document" and "OOXML Office 2010 document" is [12:55] astron: could you make a non-ugly example and present it later? [12:56] I might just not be imagining it right... [12:56] mirek2: why? cant you imagine what it might look like? [12:56] I'm imagining something, but I don't like the way that looks [12:57] so I might just not be getting the right idea [12:57] if we are increasing the size of the tile to hold the thumbnails (25 right), the genearl size of the icon and the thumbnail rendering needs to be comparable, right? [12:58] as I proposed on the ml, both the thumbnail and the icon should be fitted to a square area [12:58] so, yes [12:58] if so, the border around the frame would be the whole tile--and thumbnail or icon would sit on top of the tile [12:59] the background color, or the frame at 5px would be less jarring [12:59] could you make a mockup? [13:00] https://github.com/gnome-design-team/gnome-mockups/blob/master/documents/documents.svg is a good starting point [13:00] https://wiki.documentfoundation.org/File:LibreOffice_Initial_Icons-pre_final.svg is a source for the icons [13:03] OK, but we need to keep in mind that it needs to be implemented for the 4.2 release cycle. Thinking along lines of the empty page history of Mozilla FF [13:04] I get absolutely no color coding on the empty page history in Firefox [13:04] there is color coding in Chromium/Chrome, though [13:04] (a thick bottom border) [13:05] could you show me in a screenshot what you mean by the FF example? [13:05] Correct, but they are not "categorizing" the prior pages and have a greyscale border--we would be doing so and could use color code [13:07] Can't get a snap at the moment as chatting in FF [13:08] so you're saying to have square thumbnails showing a portion of a page/slide/sheet rather than thumbnails of differing sizes? [13:11] Maybe, but that would mean rework of the thumbnail generator--probably best to just deal with the fixed tiles and center the thumbnail or icon (for non-thumbnail) [13:12] yes, I think so too [13:12] but I'm not sure what exactly you're proposing [13:12] please make a mockup :) [13:12] I've posted up the FF tile example -- https://wiki.documentfoundation.org/File:FF_tileSnip_for_StartCenter_example.PNG [13:14] Greyscale border on slightly lighter than background tile [13:14] ok, so you propose to have thumbnails within these tiles [13:16] Correct, and the fixed size tile layout would respond to Start Center resizing. [13:18] Current code limited to 25, could be increased to maximum of 100, so requires scroll bars. Already have vertical in place, don't think horizontal. [13:22] The key aspect is a fixed size for tile, allowing resize of SC.  All mock-up to date has been too tightly spaced. [13:23] honestly, I prefer the clean look of thumbnails alone [13:23] I agree about the spacing though [13:23] as I said earlier, I like the Gnome Documents spacing: https://live.gnome.org/Design/Apps/Documents [13:29] They look to be centered horizontally and vertically, with document titles centered horizontally at a fixed offset from bottom of tile. [13:29] here's something along the lines of what I would imagine: http://ubuntuone.com/2AcFfU22tcFhYLCdugnkXY [13:30] anyway, how about we move on, discuss the visual representation later? [13:31] OK, was next item Tabs? [13:31] yup [13:32] given that we have 25 recent documents, filtering doesn't make much sense right now, IMHO [13:32] so I'd say no to tabs, for now [13:33] (if we expand the Start Center to be a document manager, that'll be another matter) [13:33] your thoughts? [13:33] no tabs. [13:33] Concur, it was a good exercise---but just not that useful for managing documents. SC layout with GUI visual queues and text annotation (tool-tip) suffice. [13:34] Sidebar Button Names [13:35] I generally prefer the action to be part of the button, but given the prominence and proximity of "Create" to the buttons, I guess it's not an issue here [13:35] I quite like the idea of having the module names part of the button labels [13:35] tautologic, in a way, but its okay [13:36] astron: how so? [13:36] in the sense that you can't really create text documents in calc [13:37] sure, but there are different types of documents than Writer documents [13:38] you can open or create PDFs in Draw, those are also documents [13:38] those can be considered text documents [13:39] ok. as i said, im okay with it [13:39] :) sorry [13:40] So are the button labels to be Writer Text, Calc Spreadsheet, Impress Presentation, Draw Drawing, Math Formula, Base Database--or some alternates? [13:40] I'm not sure about calling Writer Documents "Texts" [13:40] "text document" would seem like the correct way of putting it [13:40] in general, textual documents are always called "documents", I never heard them being called "texts" [13:40] astron: yup, that sounds good [13:41] (since "text" = sms) [13:41] exactly [13:41] Dropping the "Writer" module lable? [13:41] no, I'd keep that [13:41] mirek2: but together with "Writer" it gets pretty long [13:41] that's what I was thinking too [13:41] "Writer Text Document" [13:41] either it's not an issue, or I would just say "Writer Document" [13:41] ok [13:41] Thougts on how that translates for the l10n efforts? [13:42] (just like "Word Document" is a common phrase) [13:42] well, the side bar should have a somewhat flexible width [13:42] I hope so [13:43] we better put that somewhere … lest it be forgotten [13:43] vsfoote: it shouldn't be a problem -- we have the same strings in the current start center, we would just prefix them with the module name [13:43] astron: feel free to mail Kendy about it, or post it under my "SC niggles" thread [13:44] Kendy's pretty good with flexible sizing, though [13:44] ok [13:44] i would be ok with two-lin labels in extreme cases – it just shouldnt be cut off [13:44] (he's the one behind porting the sidebar to .ui so that it is sized flexibly) [13:45] astron: agreed, though hopefully it won't come to that [13:45] I'd rather get rid of the module prefix in that language [13:46] well, if you know how to best talk to the translaters about that – i wouldnt know who to ask [13:46] but at least you cann add a comment in the corresponding source file [13:46] I don't know either [13:46] I suppose so [13:46] but maybe we're worried for nothing [13:47] anyway, let's move to the last controversial topic [13:47] the greeting [13:47] I'm behind "Welcome to LibreOffice. Open or create a file to get started." [13:48] I'd like the message to be welcoming. [13:48] i think the welcoming people "to libreoffice" a bit useless … as is the libreoffice logo in the background [13:48] Especially as you'll probably only see it on first launch, given you'll be opening/creating documents afterwards [13:49] ok, right. [13:49] id like a hint that advises to use the sidebar somewhere [13:49] astron: I agree about the logo, but it might be good to have some branding there [13:49] (it should be obvious, but even an arrow wouldnt hurt) [13:50] I don't think that's necessary [13:50] the sidebar is basically the only thing you can act on there [13:50] (it's like game interfaces -- if there's only one thing to click on, you click it) [13:50] (especially if it's big and upfront) [13:50] ok [13:51] What of a translatable word art for the Welcome? [13:51] I don't want to push my greeting on you, though, so please give brutal feedback and propose alternatives. :) [13:52] i wont be more brutal than i already was. [13:52] you weren't brutal at all [13:52] a hint to the sidebar and im reasonably happy with the outcome [13:53] "Welcome to LibreOffice. Use the sidebar to open or create a file." -- sounds good? [13:53] yep [13:53] vsfoote: what kind of word art do you imagine? (hope it's not the ugly Office kind) [13:54] vsfoote: thoughts on the above greeting? [13:54] No, just something along the lines of Mateusz's suggestion [13:55] a simple text -- inserted at half tone onto the start center [13:55] which one? [13:55] string available for translation [13:56] from his original -- https://wiki.documentfoundation.org/File:89328.jpg [13:57] I'd prefer to keep the thumbnails area free of text when there are thumbnails on it [13:57] positioned lower edge of the empty Thumbnail view frame against the sidebar [13:57] the "Welcome" text reminds me of XP: http://winsupersite.com/site-files/winsupersite.com/files/archive/winsupersite.com/content/content/127384/reviews/winxp_2462_000a.gif [13:58] replaced perhaps with the "Clear documents" text when thumbnails-icons are present [13:58] as I said, I'd prefer to keep the are clean [13:59] area [13:59] mirek2: this isnt XP, this is a beta of xp – the final version looked somwhat different [13:59] ^somwhat^somewhat [13:59] ok, this: http://gallery.techarena.in/data/519/Windows-XP-welcome-screen.gif [14:00] anyway, ill go now ... i hope youll find a solution without me ... but the huge welcome at the bottoms looks ugly to me too [14:00] maybe, but if you look at Matuesz last -- the clear list works -- https://wiki.documentfoundation.org/File:4.2_start_center.png [14:00] ok, see you later [14:01] vsfoote: let's stick to the greeting for now, debate "clear list" afterwards [14:01] bye [14:01] == astron [~work@krlh-5f71e370.pool.mediaWays.net] has quit [Quit: Hasta la vista, baby.] [14:01] see you [14:01] my opinion being that we should only show the greeting when there are no thumbnails, to fill the empty space [14:02] and to use "Welcome to LibreOffice. Use the sidebar to open or create a file." as a greeting [14:02] would you be ok with that? [14:03] Yes greeting only when "thumbnail view" frame is empty. [14:05] Translatable greeting text of "Welcome to LibreOffice. Use the sidebar to open or create a file" works, but still believe splitting the Welcome out is more appealing. [14:06] Real question is what Kendy is able to accomplish with the cycles he has to devote to this, absent another dev--the single line of text is likely to be the best outcome. [14:06] "Welcome to LibreOffice. Use the sidebar to open or create a file" wouldn't be a single line of text. It would be two lines. [14:07] See http://ubuntuone.com/0mqVtlqmcqUpoVkGXbmh10 [14:08] Believe it would be a single translatable string with line feed. [14:08] Is that the right link you sent? [14:09] no, it's http://ubuntuone.com/0bhbyPRVt8hChFsZ64HBfO [14:10] maybe it would be a single translatable string, but that's not relevant to us [14:10] (and I'm sure it could be two strings if that was best) [14:10] :-) [14:11] So if two strings--any reason not to be in different fonts - point size? [14:12] Position? [14:12] you can see in the mockup that the point size and the font weight is different [14:12] different fonts -- that would probably look ugly [14:13] the common practice is to use one font for display text, another for body text [14:13] (or one font for both) [14:13] the greeting is display text only [14:14] position: I like the way it looks when centered [14:14] given that people tend to like symmetry (the brain actually works harder when it doesn't perceive symmetry), I think it's best to have the greeting in the middle [14:14] Done this way, same font is best. [14:15] centered vertical, centered horizontal works this way as well [14:17] that's what I proposed [14:18] yes that works [14:18] see sc.html in the package I linked to [14:18] notice on that last mockup you've gone to CAPS with the CREATE bar [14:19] that was before Adolfo's comment [14:19] ok, so that gets set back to Capitalized [14:20] you can change it by right-clicking on it, clicking "Inspect element", and changing the "text-transform" property for .green-category to capitalized [14:20] yes [14:20] to "capitalize", not capitalized [14:21] so, agreed on the greeting? [14:21] yes, it works [14:21] ok, good [14:22] So that brings us to the end of the items. [14:23] yup [14:23] any other topics? [14:24] we still have to sort out the visual representation of file types, but I'd do that over the week [14:24] let's have thumbnails only for now, add color coding later [14:25] but let's add extensions to tooltips right away [14:25] not sure how exactly you wanted file types to be represented [14:26] something along the lines of "ODF Text Document" or "Microsoft Word 2007/2010 XML"? [14:27] (here I'm thinking the extension might be as clear to people, maybe clearer, without taking up so much space; that's just my assumption, though) [14:27] Hmmm, we don't generate thumbnails for non-ODF types [14:27] that probably has to do with the thumbnail being stored in the file [14:27] but we do detect what type of document it is, so guess it could be a set of fixed icons [14:28] with labeling in the icon - and suitable tool-tip [14:28] I don't think we have a good icon designer willing to work on this [14:29] (actually, nobody wants to work on the Tango icons right now at all) [14:29] does it have to be "good" ;-) [14:29] yes :) [14:29] for the MS-OOXML icons should we lift common MS? [14:30] we don't have the rights for those [14:30] we could theoretically do something like Windows or macOS does -- writing the extension on top of the icon [14:30] and of course for PDF we'd use something appropriate [14:32] OK, I'll work up a set (license appropriate) and include it in my tile mock-up [14:32] :) ok [14:32] make sure it follows the Tango icon guidelines [14:32] license appropriate = CC-BY-SA [14:33] got it... [14:33] (we're using that for all the icons, so it's much easier if you don't use MPL icons, as that would add chaos to the icon licensing) [14:34] (and feel free to use the Gnome icons as a base -- they're dual-licensed, GPL and CC-BY-SA) [14:34] yup, what I was thinking... [14:35] agreed on having just the extension in the label, though, right? not the whole file type? [14:35] What additional items? [14:35] I didn't mean label, I meant tooltip [14:36] what did I say about additional items? [14:36] Yes minimum tool-tip needs to allow two lines if needed, with GNOME Document suggestion of truncation. [14:37] the label needs to allow two lines [14:37] I'd say the tooltip should allow as many lines as needed (provided they fit on screen) [14:39] as in parsing the document object for attributes and pushing the key elements into the tool-tip? [14:40] no -- I just want the name of the file in the tooltip, perhaps the author too [14:40] not just name -- path [14:40] Would work, but need to assure that the key attributes: document name and file type are paramount, we'll need those for a11y [14:40] as I was arguing earlier -- isn't the file type covered by the file extension? [14:41] except that Linux and macOS don't depend on file extension the way Windows OS does. [14:42] very common to have files that have no extension, don't believe extension is an ODF requirement. [14:42] no, but files are opened based on the file extension [14:43] or on the file type as detected by OS or application [14:43] (e.g. changing the extension "ODT" to "SVG", even if it's an ODF file, would open it in the default SVG editor) [14:44] only on Windows [14:45] no -- I'm trying it now in Linux [14:45] and I know it works the same way on a Mac [14:46] changing the extension .pdf to .html opens the pdf in a browser, and not displayed as a PDF [14:47] Nautilus (my file browser) gives no indication as to the true file type, BTW [14:47] Yes but remove the .PDF and what does the OS do? [14:48] yes, it opens it as a PDF, but it's incredibly rare to send files without an extension [14:48] (except for simple text files) [14:48] also, all office suites that I know of save files with file extensions [14:49] you'd have to really hate file extensions to put in the effort and remove them deliberately [14:50] and if you do that, you won't mind the extra step of visiting the Properties dialog to get the file type [14:50] back to the question of function as a document manager, outside scope--concede that majority of LibreOffice documents will be created-manipulated with extension. [14:50] right now, it's not a document manager [14:51] it might grow into one, but that's up to the devs to decide [14:51] ;-) [14:51] so the tool-tip and the document label should both provide type? [14:52] the document label just the name, with the type indicated by the color code or icon [14:52] OK [14:53] the tooltip would have the full path, including the extension [14:53] the type in the tooltip is not needed, IMHO [14:54] how would an AT pick it up for a11y requirements? [14:55] Name, Type, Path, Date last edited? What other attribute into a tool tip? [14:55] as I said, I'd just include the full path in the tooltip [14:56] I don't want it to get too long [14:56] (and full paths can get quite long themselves) [14:57] if we get requests for a certain attribute, we can add it later [14:58] but in general I'd prefer not to go overboard [14:58] Concur [14:58] max two-line for the tool-tip? [14:59] I'd show the full path for the tooltip, max 2 lines for the label [14:59] the former for when the label isn't clear enough [15:00] so allow the tool-tip to wrap within frame of the SC? [15:00] or within width of the current tile? [15:01] no, the tooltip could step out of the SC frame [15:01] as tooltips tend to do [15:01] it would act as a traditional tooltip [15:03] guess implementation would be up to Kendy -- a single line allowed to expand beyond boundary is probably easiest, but wrapping might be preferable -- let him choose? [15:04] ok [15:05] any other topics? [15:06] Not from me, other than non-ODF icons and mock-up(s) of SC with tiles, any thing else I owe the team? [15:07] no, that sounds good :) [15:07] let's end the chat, then [15:07] I'll post the log [15:08] I'll post my input to the SC design wiki, feed back there or the ML niggles? [15:11] what kind of input and feedback? [15:12] post your mockups to the wiki, other kinds of feedback to the ML, I guess [15:13] OK, signing off...