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