Design/Meetings/2013-12-01

    From The Document Foundation Wiki

    Attendees

    • astron
    • mirek2
    • vsfoote

    Topics

    • Controversial Start Center Topics

    Log

    [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 [~work@krlh-5f71e370.pool.mediaWays.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.64.148.242.81] 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 [~chatzilla@64-148-242-81.lightspeed.snantx.sbcglobal.net] 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 [~work@krlh-5f71e370.pool.mediaWays.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...