Design/Meetings/2013-12-15

    From The Document Foundation Wiki

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

    Attendees

    • astron
    • LLyaudet
    • mirek2

    Topics

    Log

    [12:00] <LLyaudet> hi everybody can we start ?
[12:01] <mirek2> hi there
[12:01] <mirek2> any topic you'd like to talk about today?
[12:01] <LLyaudet> yes guidelines for minimum size
[12:02] <mirek2> ok -- I'd wait a little until everyone comes for that
[12:02] <LLyaudet> we haven't recieve lots of comments in the mailing list
[12:02] <LLyaudet> ok
[12:04] <mirek2> have you watched https://www.youtube.com/watch?v=LOBjTe-N_-I ?
[12:04] <mirek2> while we're waiting, we could watch this
[12:05] <LLyaudet> yes I'll watch it now
[12:16] <mirek2> tell me when you're done
[12:16] <mirek2> (you don't have to watch all of it)
[12:26] == atrons [83bc020b@gateway/web/freenode/ip.131.188.2.11] has joined #libreoffice-design
[12:26] <mirek2> hi astron
[12:26] <LLyaudet> hi astron
[12:26] <mirek2> we're watching https://www.youtube.com/watch?v=LOBjTe-N_-I right now
[12:27] <atrons> hi there
[12:27] <mirek2> have you watched it?
[12:27] <LLyaudet> mirek : I started noting comments on the feature request I'll post them when I'm finshed
[12:27] <mirek2> ok
[12:28] <mirek2> I guess we can talk about window size now
[12:29] <mirek2> nobody provided any comments on the ML
[12:31] <LLyaudet> I'm starting to measure the start center with kruler
[12:31] <LLyaudet> we have the sidebar for 245 px width
[12:31] <mirek2> given that we all agreed on having a minimum size last week, I'm assuming we're going to have a guideline on it
[12:31] <mirek2> can anyone phrase the guideline, though?
[12:32] <mirek2> BTW, we all agree that the minimum size is the minimum size at which the content of the window is usable, right?
[12:33] <LLyaudet> Yes I agree on that
[12:33] <mirek2> the guideline should also mention that the minimum size should not be above the minimum screen size that we agree on
[12:33] <LLyaudet> ok
[12:34] <mirek2> (and if the two are mutually exclusive, the window should be made more responsive, to be able to fit the minimum screen size)
[12:35] <LLyaudet> how do we define that the window is usable? I see two alternatives:
[12:35] <LLyaudet> - all the actions and options of the window must be displayed
[12:36] <mirek2> all of the content is accessible (not necessarily displayed, but accessible at least through scrolling or clicking a button to show it)
[12:36] * atrons will mostly listen here, as im sitting on a library pc, right next to the door and its a little weird. hope you dont mind.
[12:36] <mirek2> the visible content is decipherable
[12:36] <LLyaudet> - all the actions that are considered as "principal" must be displayed
[12:38] <mirek2> not necessarily -- on a touch device (which these guidelines apply equally to, as LibreOffice plans to support e.g. Android), important actions could be hidden behind a button or a gesture
[12:38] <mirek2> (in the new Windows 8 apps, that's the norm)
[12:39] <mirek2> so I'd go for: all of the content is accessible without resizing the window, and the visible content is decipherable
[12:40] <mirek2> BTW, while we're at it, we should also set the minimum target sizes, one for mice and one for fingers
[12:40] <mirek2> that's for later, though
[12:40] <mirek2> do we agree on "all of the content is accessible without resizing the window, and the visible content is decipherable"?
[12:41] <LLyaudet> Ok Do we agree that for each window we define a "principal" content (actions, a part of the screen reserved for thumbnails view for example, etc. ) that must be displayed or primarily accessible via button or gesture etc. ?
[12:41] <LLyaudet> I agree on your suggestion
[12:42] <mirek2> no -- I would say all the features should be accessible somehow (even if buried under several submenus)
[12:42] <LLyaudet> I think it's too permissive
[12:42] <LLyaudet> It lets a lot of room for bad UI
[12:43] <mirek2> but not displaying all the features at certain sizes goes directly against our ux-discovery principle
[12:43] <LLyaudet> We have somehow to define the primary functionnal target of a screen and make it *easily* accessible
[12:44] <mirek2> that's not always possible at small window sizes
[12:45] <mirek2> look at Impress -- there's a lot of important functionality there, and it's hard to fit into small window sizes (given the current UI)
[12:45] <LLyaudet> what is the minimum screen size we support : 640x480?
[12:46] <mirek2> I don't think we defined one yet
[12:46] <LLyaudet> I think we should
[12:47] <mirek2> I think so too
[12:47] <mirek2> 640x480 sounds good to me :)
[12:48] <LLyaudet> ok :)
[12:48] <mirek2> (yes, I realize that's REALLY small, but I'd really like LibreOffice to be responsive)
[12:51] <LLyaudet> Since we have now a minimum screen size, I would say that each window of LibreOffice displayed at full size on 640x480 must at least present the primary functionnal target of the screen
[12:52] <atrons> you both realise that currently none of the application windows fits in even 1024*768?
[12:52] <LLyaudet> It can be only 2-3 key actions even if they are dozens
[12:53] <mirek2> atrons: what do you mean? they seem to fit (maybe not well, but they do)...
[12:53] <atrons> (which is mostly because of our irresponsive status bar)
[12:53] <mirek2> oh, right
[12:54] <mirek2> that's why we should have these guidelines, though -- to encourage devs to make things responsive
[12:55] <atrons> at some point i think i proposed some concept that would give some importance to status bar items. (or maybe i just thought about menu bars and stole that thought from mso 2007+. anyway, i think that would be a good idea)
[12:55] <mirek2> does that have to be in the guidelines, though?
[12:56] <atrons> not necessarily
[12:56] <atrons> sorry for derailing you
[12:57] <mirek2> it seems common sense to make the most important tasks most accessible
[12:57] <atrons> i didnt intend to patent the idea :)
[12:57] <atrons> although i probably should
[12:58] <mirek2> :)
[12:58] <LLyaudet> yes but it's good practice to explicitely define which are important
[12:58] <mirek2> we can do that, but I'd prefer to leave it out of the guidelines
[12:58] <LLyaudet> why ?
[12:59] <mirek2> unless we do extensive user testing with a variety of users from all over the wordl, the way we judge the importance of commands could be highly subjective
[12:59] <LLyaudet> not necessarily
[12:59] <mirek2> (e.g. switching from LTR to RTL could be vital to some people, yet of no use to others)
[13:00] <mirek2> (styles might be vital to some in Writer, while hard formatting might be vital to others)
[13:00] <mirek2> etc.
[13:00] <LLyaudet> most of the users would agree on the same actions, switching from LTR to RTL would still be behind other actions like bold
[13:01] <LLyaudet> the guidelines just need to define a goal
[13:01] <mirek2> the people who use styles would happily remove all of the hard-formatting commands, bold included
[13:02] <mirek2> not "who use styles" -- rather "style maximalists"
[13:03] * atrons is glad you didnt say "fascists"...
[13:03] <LLyaudet> lol
[13:03] <mirek2> :)
[13:04] <LLyaudet> there is somewhat a contradiction
[13:04] <mirek2> where?
[13:04] <LLyaudet> we implicitely define impotrant actions whe we design the screnn
[13:05] <LLyaudet> Most important come first
[13:05] <LLyaudet> in the layout
[13:05] <mirek2> true
[13:06] <mirek2> I'm saying we don't have the necessary prerequisites to judge the important elements objectively
[13:06] <LLyaudet> we should be able to partly explicite it, it would still be interesting if we could locate when it's hard to explicite
[13:07] <LLyaudet> sometimes important actions will be agreed by almost everyone and sometimes not
[13:07] <mirek2> currently, the importance of elements is mostly decided subjectively (though in accordance to our principles) and then iterated on
[13:08] <LLyaudet> when not there may be an opportunity to improve the layout and design
[13:08] <mirek2> I just don't think we're ready for a guideline on showing the important elements, when we currently don't have a good way to judge the importance of elements
[13:08] <mirek2> however...
[13:09] <mirek2> a step to getting there could be to define the purpose of each module
[13:09] <LLyaudet> common sense is not so bad when judging important elements and we can still improve it later
[13:09] <mirek2> (as I said in the very lengthy mailing list discussion with Michel Renon)
[13:10] <LLyaudet> I agree on definign the purpose and if possible 2-3 key features
[13:11] <mirek2> LLyaudet: yes, but as it's still highly subjective, it's not fit to be listed in the guidelines
[13:11] <mirek2> unless we define a good way to judge the importance of elements
[13:12] <LLyaudet> we can try soemthing quantitative
[13:12] <LLyaudet> "used by at least 75% of the users of the module with a certain frequency"
[13:13] <LLyaudet> we define the goal
[13:13] <mirek2> then you leave out all the language-dependent features
[13:13] <LLyaudet> if information is unavailable we back-up on common sense
[13:14] <mirek2> of course, the language-dependent features should be contextual
[13:14] <LLyaudet> clearly an language independant feature that is used by more than 75% of the people is more important than language dependant feature
[13:15] <LLyaudet> if we want to take into account language dependant feature we need to design language dependant layout
[13:16] <mirek2> LLyaudet: we already do, at least a little, I believe
[13:16] <mirek2> and, yes, we should
[13:16] <mirek2> also, as to your claim above, not necessarily
[13:17] <mirek2> imagine a feature that allows you to draw Japanese characters within LibreOffice
[13:17] <mirek2> probably not a feature used by 75% of users, yet absolutely vital for the Japanese
[13:18] <mirek2> or zoom -- a feature I'd assume vital to people with very bad eyesight
[13:18] <LLyaudet> it's part of the more important feature "draw characters" for all users ;)
[13:19] <mirek2> imagine if it was a stand-alone feature
[13:20] <mirek2> I might be getting to hypothetical -- perhaps switching RTL and LTR is a better example
[13:21] <mirek2> "to" was meant as "too"
[13:21] <LLyaudet> Why don't we try ? It would be interesting to know that for some modules we are not able to define 2-3 key features that everyone agree on.
[13:22] <mirek2> let's see -- "New", "Open", "Close Window"?
[13:22] <mirek2> :)
[13:22] <LLyaudet> ><
[13:22] <mirek2> "Save" -- also important
[13:22] <atrons> close window is the most important one, obviously
[13:23] <atrons> so lets draw a big red X on the middle of the window everywhere
[13:23] <mirek2> sounds good
[13:23] <LLyaudet>  that's what XWindowSystem is all about ;)
[13:24] <atrons> LLyaudet: can create a design for that?
[13:25] <mirek2> "New", "Open", "Save", then?
[13:25] <mirek2> yet if you look at these, you completely miss the frequency with which they are used
[13:25] <atrons> at least for that we have the spreadsheet from OOo times
[13:26] <mirek2> "New" and "Open" are extremely important, yet tend to be used maybe once or twice during your use of a module
[13:26] <atrons> also, those are not the functions that LLyaudet meant, i think
[13:27] <mirek2> right -- I'm just trying to show that picking the important elements is more complex than it seems
[13:27] <LLyaudet> Key feature for writer : type text and see the result (WYSIWYG)*
[13:27] <LLyaudet> do we agree on that
[13:27] <mirek2> "Cut", "Copy", and "Paste", might be frequently used, yet these are mostly accessed using the right-click menu or keyboard shortcuts
[13:28] <atrons> but they are means to an end
[13:28] <mirek2> LLyaudet: "read text" is more important
[13:28] <mirek2> however, I wouldn't think of that as function
[13:28] <mirek2> a feature, sure, but not a function
[13:28] <LLyaudet> it depends it you create or read
[13:29] <mirek2> yup
[13:29] <atrons> mirek2: why not? a reading or maybe a correction mode would seem like a nice feature
[13:29] <LLyaudet> we have 3 use case : write, read, modify
[13:29] <mirek2> we have a read-only mode
[13:29] <atrons> yeah, but ... its still too cluttered
[13:30] <mirek2> I agree
[13:30] <mirek2> LLyaudet: where do you draw the line between write and modify?
[13:30] <LLyaudet> modify is a mix of read and write
[13:31] <mirek2> what? are you saying I can't read what I'm writing when in "write" mode?
[13:31] <LLyaudet> we can draw the line along many dimensions
[13:31] <LLyaudet> not that
[13:31] <LLyaudet> but if we take the dimension number of authors
[13:32] <LLyaudet> 1 author write
[13:32] <LLyaudet> 2 or more modify
[13:32] <LLyaudet>  is a possibility
[13:32] <mirek2> I still don't see the line
[13:32] <LLyaudet> the line is between 1 and 2 perdpendiculary to the dimension
[13:33] <mirek2> in any case, let's please hold off from having importance of features in the guidelines right now
[13:33] <mirek2> we can discuss this further on the mailing list
[13:33] <LLyaudet> ok
[13:33] <mirek2> right now, I'd like to see what we can agree on
[13:36] <mirek2> I'll write a draft of the minimum window size guideline
[13:37] <LLyaudet> Do we agree that even if we cannot define them key features are easily accessible with minimum size display (either on the screen or keyboard shortcut or whatever) ?
[13:38] <atrons> from my side, yes...
[13:39] <mirek2> LLyaudet: that's already covered by our ux-efficiency principle
[13:39] <mirek2> (the easily accessible part)
[13:39] <mirek2> the "accessible" part is covered by ux-discovery
[13:40] <LLyaudet> if it's covered by  our ux-efficiency principle we just need to mention compatibility of minimum size and ux-efficiency principle
[13:41] <LLyaudet> thats a good definition
[13:41] <mirek2> no need to mention that -- compatibility with our UX principles is always a given
[13:41] <LLyaudet> The minimum size for a screen is the minimum size that permites to respect the ux-efficiency principle (and other principles to list).
[13:42] <LLyaudet> do we agree on that ?
[13:42] <mirek2> not needed, really -- all principles should always be followed to the greatest extent that technological limitations allow
[13:43] <mirek2> if that's not clear, I could add "all principles should always be followed to the greatest extent that technological limitations allow" to the principles page
[13:44] <LLyaudet> yes but with this definition we recognize that we can not satisfactorily satisfy all principles if the size is too small
[13:45] <LLyaudet> if the greatest extent is 0 we have a problem and that's why we define minimum width
[13:45] <LLyaudet> *size
[13:46] <mirek2> yup
[13:46] <mirek2> so what's the problem?
[13:47] <LLyaudet> the problem is  we need a good definition of minimum width*
[13:47] <LLyaudet> *minimum size
[13:48] <mirek2> I mean, what's the problem with saying that all principles should always be followed to the greatest extent that technological limitations allow
[13:49] <LLyaudet>  I have no problem with that. I'm saying that we should explicit its consequence
[13:50] <mirek2> by "explicit", you mean "explicitly state", right?
[13:50] <LLyaudet> yes if the size doesn't allow to follow the principles it's bellow the minimum size that's all
[13:53] <mirek2> the problem with that is, there's no hard line between following the principles and not following them
[13:53] <mirek2> they should be followed to the greatest extent
[13:53] <mirek2> but it's always limited by technological limitations
[13:53] <LLyaudet> common sense on badly designed and not usable screen is the hard line
[13:53] <mirek2> for example, according to "ux-efficiency", LibreOffice should make all documents for you right away
[13:54] <mirek2> but it can't, given that it can't read your thoughts or predict the future
[13:54] <LLyaudet> try to stay concrete
[13:57] <mirek2> LLyaudet: we'll always use common sense
[13:57] <mirek2> here's the proposed definition: https://wiki.documentfoundation.org/User:Mirek2#Minimum_Sizes
[13:58] <mirek2> we could also define minimum margins if we'd like
[14:00] <mirek2> LLyaudet: if you'd like, I can add that "important features must be easily accessible"
[14:00] <LLyaudet> ok
[14:01] <mirek2> how's this: https://wiki.documentfoundation.org/User:Mirek2#Minimum_Window_Size
[14:02] <mirek2> I'd also like to agree on some minimum target size
[14:03] <mirek2> the sizes I specified on the page right now are just suggestions
[14:03] <mirek2> 48x48 px is a bit too big
[14:04] <mirek2> and the sizes should ideally be specified in mm, or in some other resolution-independent unit
[14:05] <LLyaudet> Maybe we can add a sentence just after your first sentence "The minimum size is always defined with the following principles in mind: ux-efficiency, etc."
[14:05] <LLyaudet> I look at the size
[14:05] <mirek2> as I said, all principles should be followed
[14:05] <mirek2> always
[14:05] <mirek2> in terms of any decision, including any guideline, we make
[14:06] <LLyaudet> Yes but it's good to say it again in the guidelines I think
[14:06] <LLyaudet> You always have to find the right level of redundancy
[14:07] <mirek2> OK, I'll add something to the guidelines page
[14:07] <LLyaudet> Thanks
[14:07] <mirek2> I'll also start a thread on the ML about minimum target sizes and non-native theming
[14:07] <mirek2> (also on the user page)
[14:08] <atrons> mirek2: defining target sizes in pixels wont get us far, i guess.
[14:08] <atrons> (i know its all we have, but...)
[14:08] <mirek2> that's what I said -- have it in a resolution-independent unit
[14:08] <atrons> oh. sorry
[14:09] <mirek2> I'll post it to the mailing list, don't worry
[14:09] <mirek2> now that that's all covered, let's talk about https://www.youtube.com/watch?v=LOBjTe-N_-I
[14:10] <mirek2> in general, I'm all for having markup language to then convert to elements
[14:11] <mirek2> however, I would say that this requires deeper thought
[14:11] <mirek2> I've also been thinking (for quite a while) that it'd be good to bring this kind of automation to Impress as well
[14:11] <LLyaudet> I haven't finished but I'll post my first comments. I agrre i t requires deeper thought
[14:11] <mirek2> where the Outline mode is severely lacking
[14:12] <LLyaudet> The idea is to create a specialized language fro Draw automation and to have an user-friendly WYSIWYG interface for this language. We need to think about the best language for this
[14:13] <LLyaudet> Safe distance : it could be used not only for automation but also  as an attribute of shapes so that when moving shapes you can never move one closer to another than the maximum of both shapes safe distance
[14:13] <LLyaudet> - first bug on Mad Wheels, Inc. there is a comma in the name  Maybe comma is  not the good separator to use or \, for comma in diagrams
[14:13] <LLyaudet> - we need an algorithm for automatic placement of the elements (it's not hard) but the example is not very reallistic since in an autmomated process  you'll most probably end up moving the automated placement that was proposed.
[14:13] <mirek2> safe distance: could be margins, really
[14:14] <mirek2> not really a fan of not allowing to bring things closer manually
[14:14] <mirek2> if the algorithm is good, you shouldn't end up moving the element
[14:15] <LLyaudet> if you look at its video the algorithm guess where he watnts to put thingsd that's unrealistic
[14:15] <mirek2> how is that unrealistic?
[14:16] <atrons> i havent watched the video, but there are already four script languages you can use in libo: libo-style basic, vb for application (although i think on import it gets converted to libo basic), js (via java) & python 3 (bundled interpreter)
[14:16] <LLyaudet> sometimes it's on the right for the second link, sometimes it's down-left, down center, down right for the new links it's not uniform compormtment
[14:16] <atrons> *vbscript not vb for applications, i think
[14:16] <mirek2> atrons: I think the proposal is to make this noob-friendly
[14:17] <mirek2> (think Outline view in Impress)
[14:17] <LLyaudet> not noob
[14:17] <LLyaudet> specialized languages are not just for noobs
[14:17] <atrons> yep -- but bundling yet another interpreter is a bit of a no-go
[14:17] <mirek2> I said noob-friendly, not noob-only
[14:18] <atrons> also, python is pretty simple in its basic concepts
[14:18] <LLyaudet> these are Turing-complete languages
[14:18] <LLyaudet> they can not be as efficient than specializeed languages
[14:19] <mirek2> I agree -- here we need a simple markup language, not a programming language
[14:20] <mirek2> anyway, probably not a feature that would get done soon
[14:21] <mirek2> however, I'll make a whiteboard for it
[14:21] <LLyaudet> probably but still intreresting
[14:21] <mirek2> and we'll see where it goes
[14:21] <LLyaudet> good we need to carefully think before creating a new language for automation
[14:22] <mirek2> yup
[14:22] <mirek2> perhaps we don't even need a markup language
[14:23] <mirek2> maybe simple list tools will suffice
[14:23] <LLyaudet> I don't think it should be a markup language
[14:23] <mirek2> (similarly to the Impress outline view)
[14:23] <mirek2> any other topics to discuss?
[14:24] <LLyaudet> no
[14:25] <mirek2> we've agreed on https://wiki.documentfoundation.org/User:Mirek2#Minimum_Window_Size, right?
[14:25] <LLyaudet> I agree with the added reference to the principles
[14:26] <mirek2> right
[14:26] <mirek2> atrons: ?
[14:30] <mirek2> do you agree?
[14:30] <atrons> well, i hate the word "chrome," and responsive is not defined, but otherwise im okay with it
[14:30] <mirek2> what would you say instead of chrome?
[14:31] <mirek2> I'm saying UI chrome, as we can't be sure that e.g. document content will be decipherable
[14:31] <mirek2> also, how would you define responsive?
[14:35] <mirek2> atrons: please suggest a different wording
[14:40] <atrons> mirek2: sorry for stalling you here, but what exactly is "decipherable"? is it just that elements need to be large enough for their contents to be readable?
[14:41] <atrons> also, why not just replace chrome with elements?
[14:41] <mirek2> it means that you're able to determine the meaning: icons need to be big enough not to be a tiny smudge, they shouldn't be cut off, and labels should be shortened in such a way as to still make sense
[14:42] <mirek2> atrons: as I said above, the document is an element, yet at small zoom levels it's undecipherable
[14:42] <atrons> but if youre using a small zoom level that is for a reason, e.g. in the slides sidebar of impress
[14:43] <atrons> and in that way it is usable
[14:43] <mirek2> yes
[14:43] <atrons> so, what is the big problem?
[14:44] <mirek2> "all visible elements are decipherable" -- that would mean documents at small zoom levels need to be decipherable as well
[14:44] <atrons> all visible _UI_ elements ...
[14:45] <mirek2> ok -- UI elements sounds good
[14:45] <atrons> responsive = UI elements are adaptive to window size
[14:46] <mirek2> could you rewrite the whole sentence?
[14:46] <atrons> (and will display in the most appropriate form defined)
[14:47] <atrons> If that can't be done without breaking the guideline above, UI elements must be modified to adapt to window size to display in more appropriate form.
[14:48] <atrons> so thats preetty long
[14:50] <atrons> ideas on how to shorten this?
[14:50] <mirek2> get rid of "to display in more appropriate form"?
[14:51] <atrons> well, that would leave the door open to non-sensical modfications... i guess (make all buttons heart-shaped, once we're under 1024*768 for instance)
[14:51] <atrons> but ... if we assume common sense...
[14:53] <mirek2> not sure how making buttons heart-shaped wouldn't help meet the guideline above
[14:54] <atrons> too many negations in that sentence, i am not sure if i understand you correctly
[14:55] <LLyaudet> *wouldn't* ???
[14:55] <atrons> ^ this!
[14:55] <mirek2> "wouldn't" was supposed to be "would", sorry
[15:01] <mirek2> look at https://wiki.documentfoundation.org/Design/Guidelines, give feedback
[15:04] <mirek2> refresh, then give feedback
[15:04] <mirek2> (made some minor edits, added the UX principles link)
[15:06] <atrons> _is_ decipherable => _are_ decipherable
[15:06] <mirek2> refresh :)
[15:07] <atrons> oaky
[15:07] <mirek2> now that I think about it, it should really be under Building Blocks
[15:08] <mirek2> I'll move it there afterwords
[15:08] <mirek2> afterwards
[15:08] <mirek2> everyone ok with the principle, right?
[15:09] <LLyaudet> ok
[15:10] <mirek2> if so, let's end the chat and I'll publish the log
[15:10] <LLyaudet> bye everyone
[15:10] <atrons> bye, then
[15:10] <mirek2> see you next week
    Retrieved from "https://wiki.documentfoundation.org/index.php?title=Design/Meetings/2013-12-15&oldid=99164"