Design/Meetings/2013-12-08

TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate

• Wiki Home
• Development
• Design
• QA
• Events
• Documentation
• Website
• Localization
• Accessibility
• Marketing
• Diversity
• Wiki Help

• Design Home
• Whiteboards
• Development Blueprints
• UX Principles
• UX Guidelines
• Artwork Resources
• Branding Guidelines
• Meetings

Attendees

• astron
• LLyaudet
• mirek2
• vsfoote

Topics

• Start Center

Log

[12:13] <vsfoote> 'morning all
[12:13] <mirek2> hi there
[12:14] <mirek2> we haven't gotten started yet
[12:15] <mirek2> so, I guess the topics for today are color coding
[12:15] <mirek2> any other topics?
[12:16] <mirek2> (I'd like to wait with color coding until someone else comes -- I don't want to be the sole judge here)
[12:16] <mirek2> (then again, it's no guarantee that someone else will come)
[12:16] == astron [~frootzowr@dslb-188-096-196-253.pools.arcor-ip.net] has joined #libreoffice-design
[12:17] <mirek2> :) hi astron
[12:17] <astron> hi mirek
[12:17] <mirek2> let's discuss color coding
[12:17] <mirek2> https://wiki.documentfoundation.org/Design/Whiteboards/Start_Center#File_Type_Differentiation
[12:19] <mirek2> honestly, I'm not really happy with either proposal (despite one of them being mine)
[12:19] <astron> also, hi all others :)
[12:20] <astron> what does MOX mean?
[12:20] <astron> (sorry, haven't read mail all week again.)
[12:20] <vsfoote> that is Microsoft OpenOffice XML
[12:21] <astron> vsfoote: thanks for the explanation
[12:21] <mirek2> btw, the standard initialism is OOXML
[12:21] <astron> (i doubt anyone will understand that)
[12:22] <vsfoote> think one problem with current implementation has been that the icons are the "default" LibreOffice icons for all documents that don't have thumbnails
[12:23] <mirek2> I think a clearer way to represent MS Office files is with their traditional letters
[12:23] <astron> well, the idea behind using the same icon for any file that will be opened by the same libo component is that there shouldnt be much of a difference between the types
[12:23] <mirek2> (i.e. W, P, X, etc.)
[12:23] <vsfoote> later in chat last week I offered to cobble together a set of icons for other types,  see need to distinguish OOXML -- MOX from other Office 95-2007 flavors
[12:24] <astron> also, internally, they are all convereted to something ODF-like
[12:24] <astron> ^ret^rt
[12:24] <vsfoote> astron -- sure but why should there not be "richer" representation of content in the icons?
[12:25] <astron> what do you mean by richer?
[12:25] <vsfoote> visually more informative to keep pace with our "thumbnail" visualizations
[12:26] <vsfoote> but since no efficient way to render thumbnails for non-ODF types, better ICONs
[12:26] <mirek2> I agree that it'd be good to have special icons for Office files, as one could easily start editing an OOXML file and save it as an ODF file (as LibreOffice asks the user to)
[12:27] <mirek2> and it'd be good to clearly differentiate the two
[12:28] <vsfoote> other aspect of doing additional icons is to move to larger size
[12:28] <vsfoote> attempts thus far have sized down the thumbnails to match the 128px icons
[12:29] <vsfoote> set I worked up (and I do not have that much skin in them) are at 256px
[12:29] <vsfoote> and then are centered in a 300px tile with even gullies
[12:30] <mirek2> we already have 256px icons
[12:30] <mirek2> so that's not a problem
[12:31] <mirek2> also, our icons are vectors, so we can tweak them for any size relatively easily
[12:33] <vsfoote> yes lifted colors and shape from the "initial-Artwork-logo" SVG
[12:33] <vsfoote> the Vegur font family was a goose-chase
[12:34] <mirek2> anyway, I think that if we want special icons for OOXML files, there should be a lot more time spent on designing them
[12:34] <mirek2> something for the icon set volunteers to do
[12:34] <mirek2> (I'll talk to Ahmad about it)
[12:34] <vsfoote> concur, but basic issue of color?
[12:35] <mirek2> the color coding -- as I said, I don't really like either proposal
[12:35] <vsfoote> relative size of the corner tab?
[12:36] <vsfoote> or staying with base color design?
[12:38] <mirek2> I don't like the look of the corner tab
[12:38] <mirek2> that's just my opinion, though
[12:39] <mirek2> astron: your thoughts?
[12:40] <astron> uh...
[12:40] <astron> i like the round corners better than your square ones (brand etc.)
[12:41] <mirek2> I think my issue with the tab is that either the tabs aren't aligned or the aspect ratio of the page isn't carried across
[12:41] <astron> but stuarts mockup does not yet look very polished
[12:44] <vsfoote> when I started, thought the "thumbnails" would fit better into the frame -- would probably drop the border and stay with just the corner tab
[12:44] <mirek2> honestly, as the aspect ratio does usually give some info about the file type, I'm thinking that it'd be better to stay with the current design for now
[12:44] <vsfoote> the ODF thumbnail views are nominally 256px, but they vary quite a bit from document to document and file types
[12:45] <astron> mirek2: yes, aspect ratio should be reflected in the thumbnails
[12:46] == LLyaudet [58ab762a@gateway/web/freenode/ip.88.171.118.42] has joined #libreoffice-design
[12:46] <LLyaudet> hi everyone sorry for being late
[12:46] <vsfoote> llyaudet -- `morning
[12:46] <astron> hi
[12:47] <LLyaudet> what is the current topic?
[12:47] <mirek2> here's the log so far: //piratepad link//
[12:47] <LLyaudet> thanks mirek
[12:47] <vsfoote> myrek2 -- yes they do retain it for most part
[12:48] <mirek2> in the current implementation, yes
[12:48] <vsfoote> but a math formula comes in as a square ~180px
[12:48] <mirek2> ok
[12:48] <vsfoote> a impress slide at ~256px X ~175px ish
[12:50] <vsfoote> so using a tile layout seems to offer advantages for spacing and layout, and simplicity for implementing
[12:51] <vsfoote> question then becomes how to handle tiles?   touching, gullies, labeling, transparent or theme colored?
[12:51] <astron> making the tiles always visible though as in your mockup creates visual clutter though
[12:52] <vsfoote> sure, but it may still be the most efficient way to differentiate the document type using color
[12:53] <mirek2> by "tiles", do you mean something like https://wiki.documentfoundation.org/images/e/e2/Thumbs.png, where the thumbnail is fitted to a square area, or something where the thumbnail would be stretched to fit within a square area?
[12:53] <astron> right – we should clarify terminology.
[12:53] <astron> [ftr: i thought of the grey squares behind the icons]
[12:54] <astron> [from stuarts mockup]
[12:54] <vsfoote> yest, tile would structure the layout of the page,  icons or thumbnail would be overlay
[12:55] <vsfoote> believe this is the way it is currently coded
[12:56] <astron> so, how does a grey tile help users recognise file types
[12:56] <astron> ?
[12:57] <vsfoote> it would not, color association currently from the corner tab lifted from standard iconography
[12:58] <mirek2> I would say it's best to eliminate the gray background
[12:58] <vsfoote> the corner tab could equally be a puddle under the icon or "thumbnail" on a transparent tile
[12:58] <astron> yep
[12:59] <mirek2> in any case, I'm thinking we don't have a good design yet, so I'd propose to keep designing
[12:59] <vsfoote> title and tool-tip will be basis of support to AT at 4.2.0 --- color alone will never suffice
[13:00] <LLyaudet> what is AT?
[13:00] <vsfoote> sorry -- Assistive Technology for accessibility and automation support
[13:00] <LLyaudet> thanks
[13:02] <mirek2> so... can we agree to keep designing, with color coding probably being put off until the next release?
[13:02] <LLyaudet> I agree
[13:03] <mirek2> others?
[13:03] <vsfoote> sure, push color scheme off to 4.3.0 -- but we still have immediate issues of size and labeling to resolve for current cycle
[13:03] <mirek2> ok
[13:04] <vsfoote> so is there agreement that a 300px working object is correct for StartCenter use?
[13:05] <mirek2> 300px per thumbnail? that seems too big, tbh.
[13:05] <LLyaudet> sorry what do you mean by 300px working object ?
[13:06] <vsfoote> layout would be structured with 300px squares --- using native size ODF thumbnails and suitable 256px icon set
[13:07] <LLyaudet> thanks do we have a minimum size for the start center?
[13:08] <vsfoote> just checked, the GTK widget UI allows it to shrink to nothing, some object drop out
[13:09] <astron> LLyaudet: not currently, but i would propose to use something like 640*480 or sor
[13:09] <LLyaudet> astron: I agree
[13:09] <LLyaudet> we need at least 4 tiles to fit I think
[13:10] <vsfoote> astron -- why, the UI lets us resize so that the thumbnail view goes away
[13:10] <mirek2> the main sizing problem we have is that the sidebar icons simply get hidden when the window height is too small
[13:10] <astron> vsfoote: but does that make any sense?
[13:11] <vsfoote> yes, we allow the user to infinitely reshape and resize the UI to suit their needs
[13:11] <vsfoote> we give them a default on installation, on launch -- from there it is up to them
[13:12] <astron> but we can't fit al lfunctionality of the ui anymore
[13:12] <vsfoote> that is the power of shifting over to UI widgets
[13:12] <mirek2> I agree with astron here
[13:12] <astron> no, that is just annoying
[13:12] <vsfoote> no - we code default on install default on launch  -- user adjusts to their preference
[13:13] <mirek2> the usability problems with no restrictions on resizing are:
[13:14] <mirek2> * hiding sidebar buttons and the thumbnail grid without any indication that they are there
[13:14] <vsfoote> not our problem, we set a starting point
[13:15] <mirek2> * making it hard to spot and resize LibreOffice if the dialog is sized to its minimum
[13:15] <vsfoote> if we are concerned in that regard we would need to provide a "reset" button
[13:15] <mirek2> vsfoote: people can easily resize a dialog by accident
[13:15] <vsfoote> just checked and the minimum currently is the existing three item tool bar
[13:16] <mirek2> vsfoote: a "reset" button would get hidden as well :)
[13:16] <astron> vsfoote: i hope the reset button idea was meant ironically :)
[13:16] <mirek2> vsfoote: perhaps on Windows, but on Ubuntu Gnome 13.10, the minimum is a tiny, unnoticable rectangle
[13:17] <vsfoote> check that -- minimum width is the current tool bar (an argument for keeping it) but height of fram can be reduced to zero (thats bad)
[13:17] <mirek2> vsfoote: that's not an argument for keeping the toolbar if we can set the minimum width for the dialog ourselves
[13:18] <mirek2> which is what we're talking about here
[13:18] <mirek2> in any case, I feel we're talking in circles here
[13:18] <mirek2> it seems like most of us agree on setting reasonable minimum widths and heights
[13:19] <vsfoote> no you were discussing the minimum size for the thumbnail view and how many objects fix it at as minimum size
[13:19] <mirek2> and it seems to be the simplest way to prevent usability problems
[13:20] <vsfoote> others will argue (especially having implemented widget UI interface) that allowing it to shrink to zero thumbnails is a great feature
[13:20] <mirek2> "<LLyaudet> thanks do we have a minimum size for the start center?" -- start center = the whole window, no?
[13:20] <LLyaudet> yes that's what I mean
[13:21] <astron> yes, but LLyaudet also asked for 4 thumbnails minimum to fit into the window
[13:21] <astron> which is sensible
[13:21] <mirek2> I'd say that depends on the thumbnail size
[13:22] <mirek2> I'd suggest simply 1 thumbnail minimum
[13:22] <vsfoote> why?  the GTK widget does not require it and useability is NOT so enhanced by forcing use of thumbnail viewpanel
[13:22] <mirek2> given the minimum height of the sidebar, though, it will probably turn out to be around 3 thumbnails, though
[13:22] <LLyaudet> I would say it's still reasonnable if we have a first line of two tiles and the second line is partly seen so we have an hint to scroll
[13:23] <mirek2> vsfoote: let's imagine this scenario:
[13:23] <mirek2> a user starts the center for the first time, sees the welcome message in the thumbnail area
[13:24] <mirek2> he resizes the dialog to see the sidebar only
[13:24] <mirek2> he won't discover that the area where the welcome message was is used to host thumbnails of recent files
[13:25] <mirek2> unless he resizes the window again (which he might never do)
[13:26] <mirek2> thus missing out on a pretty important feature, no?
[13:27] <mirek2> honestly, though, we're talking about such corner cases that I don't really care
[13:27] <vsfoote> but it goes the other way (probably more substantive) why should we steal user desktop when we can have the StartCenter shrunk to manageable size?
[13:27] <vsfoote> posting up a clip from working 4.3.0alpha+
[13:28] <mirek2> all I'm asking for is that the minimum width and height allows for all the buttons in the sidebar to be visible
[13:28] <mirek2> can we all agree on that?
[13:28] <LLyaudet> I agree
[13:29] <mirek2> vsfoote: would you agree with that?
[13:29] <vsfoote> disagree, there is no need to force showing the full sidebar!
[13:29] <vsfoote> https://wiki.documentfoundation.org/File:MinimalSideBar.PNG
[13:30] <mirek2> let's also keep in mind that the Start Center turns into a module -- it's not a separate window
[13:30] <vsfoote> That is imposing a static UI and UX when we have a dynamic and user friendly widget interface
[13:31] <astron> what the hell is userfriendly about having to scroll everywhere?
[13:31] <LLyaudet> It's still dynamic but we have bounds
[13:32] <mirek2> given that the modules are unusable at small sizes like these, it doesn't make sense to allow such small sizes
[13:32] <vsfoote> scroll? it is one button click to resize to full window
[13:32] <LLyaudet> vsfoote: if someone really wants to shrink to save some space on the desktop then there is also a button for full shrink
[13:33] <vsfoote> no, there is a button to "iconify" and remove from the desktop
[13:33] <astron> vsfoote: your last statement shows that you agree the window is unusable at that small size
[13:33] <vsfoote> removing the UI from immediate use
[13:33] <vsfoote> astron -- not at all, look at the clip I posted it is fully functional too get real work done
[13:34] <vsfoote> the sidebar does not shrink, just its exposed frame
[13:35] <mirek2> vsfoote: you'd have to resize the window every time you opened or created something -- that's a horrible UX
[13:35] <astron> i am sorry – we should stop discussing this particular and agree to disagree
[13:35] <mirek2> btw, since you're opening the start center to work on something, it makes sense to have the SC window the same size as the document window
[13:35] <astron> particular issue, i meant
[13:36] <mirek2> does the Gnome HIG say anything about window size, btw?
[13:36] <vsfoote> mirek2 -- no the module opens at its default or prior user setting
[13:38] <mirek2> vsfoote: really? the module opens at the size of the Start Center for me
[13:38] <mirek2> has the behavior changed recently?
[13:39] <astron> mirek2: if we want the start centre to have more of a separate identity it would make sense to allow for it to have an own size
[13:39] <mirek2> it would, I agree
[13:39] <astron> but thats not the case currently
[13:40] <vsfoote> mirek2 -- oops, you are correct, currently when opening, opens to size of SC
[13:40] <mirek2> I'm just talking about how it works now, which is probably the behavior it will have in the next release
[13:40] <vsfoote> https://wiki.documentfoundation.org/File:MinimalJustToolbar.PNG
[13:41] <mirek2> I'm still pulling for the minimum at the very least including the whole of the sidebar
[13:42] <mirek2> if we can't agree, let's just vote on it
[13:43] <mirek2> or, better yet, let's create a guideline on minimum window sizes
[13:43] <astron> thats a 3:1 then, i guess.
[13:44] <mirek2> I'll post a thread to the mailing list, let's discuss this issue with the wider community
[13:44] <mirek2> and craft a guideline on sizing next week
[13:45] <mirek2> I can also ask the Gnome guys to give their input
[13:46] <mirek2> (given that we're following their HIG when we don't have our own guidelines, it seems appropriate)
[13:46] <LLyaudet> I agree opinions from Gnome and the community will be welcome
[13:46] <mirek2> anyway, let's move on and base our window size decision on the guideline we'll have next week
[13:47] <mirek2> so, back to thumbnail size... :)
[13:48] <vsfoote> ok with me... nominal ~128px or ~256px?
[13:48] <astron> i will go now ...
[13:48] <astron> bye then
[13:48] <mirek2> I'd suggest the thumbnail be made fit within a 180x180px square, which is roughly what Gnome documents do
[13:48] == astron [~frootzowr@dslb-188-096-196-253.pools.arcor-ip.net] has quit [Quit: astron]
[13:48] <LLyaudet> bye
[13:48] <mirek2> bye
[13:48] <vsfoote> bye
[13:50] <mirek2> given that we defer to the Gnome guidelines when we don't have our own, it would make sense to use the same thumbnail sizes they use
[13:50] <LLyaudet> it's hard to decide without at least the *default* size of the start center
[13:50] <vsfoote> it looks like Kriztian and Kendy had it about that size --180px-- not sure
[13:51] <vsfoote> the nominal thumbnail within the ODF is at 256px
[13:52] <LLyaudet> which is quite  large but it's better to downsize
[13:52] <mirek2> vsfoote: no, it was smaller
[13:53] <mirek2> I'd actually like to go as well
[13:53] <mirek2> so, would you like to discuss this just the two of you?
[13:54] <vsfoote> Apologies -- I need to step out for a bit as well lets terminate
[13:54] <mirek2> ok
[13:54] <vsfoote> llyaudet?
[13:54] <mirek2> I'll post the log, then
[13:55] <LLyaudet> I feel we need to think more about the sizes of the different elements
[13:55] <vsfoote> Next week and on ML then...
[13:55] <mirek2> yup
[13:55] <LLyaudet> ok
[13:55] <mirek2> I posted a proposal on the ML
[13:55] <mirek2> "Start Center Niggles"
[13:55] <mirek2> see the attached mockup: http://ubuntuone.com/0bhbyPRVt8hChFsZ64HBfO
[13:55] <mirek2> it doesn't include thumbnails
[13:56] <mirek2> but those are excellently portrayed by Gnome Documents mockups
[13:56] <mirek2> https://wiki.gnome.org/Design/Apps/Documents
[13:56] <mirek2> reply in the mailing list thread with specific comments
[13:57] <LLyaudet> ok bye everyone