Design/Meetings/2013-12-01

From The Document Foundation Wiki
Jump to: navigation, search

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 Mac OS 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 OS X 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...