Design/Meetings/2014-06-29

Attendees

 * _0rAX0_ : Reda Lazri
 * abhra
 * LLyaudet
 * mirek2

Topics

 * design workflow
 * design team organization
 * color for non-printable characters

Log
[13:54] == LLyaudet [58ab762a@gateway/web/freenode/ip.88.171.118.42] has joined #libreoffice-design [14:06]  Hi @mahfiaz [14:06]  Any topic you would like to discuss ? [14:17] == mirek2 [56311b91@gateway/web/freenode/ip.86.49.27.145] has joined #libreoffice-design [14:17] really sorry for being late [14:17] was anyone else here? [14:18]  Hi mirek [14:18]  @mahfiaz is not responding [14:19]  Any topic you would like to discuss ? [14:19] well, I was hoping to discuss the way the team is organized and how to move forward [14:19] but I'd really prefer if at least Astron was here [14:20]  I agree two persons is rellay not sufficient [14:20]  *really [14:20]  we can discuss the mail Improvement of Tooltip Texts if you want [14:21] hold on a sec [14:25] I'm looking for the bug on non-printing character color [14:26] now I'm thinking it doesn't exist... do you happen to know if a bug was reported on the color selected for non-printing characters being too bright? [14:27]  astron and pedro opened two bugs [14:27]  astron : https://bugs.freedesktop.org/show_bug.cgi?id=79381 [14:29]  pedro : https://bugs.freedesktop.org/show_bug.cgi?id=80054 [14:29] thanks [14:29] I suppose Astron's bug is the closest to what I'm looking for, but not quite [14:30] I guess I'll just contact the original dev directly [14:30] the color that seems most usable based on our social network survey is Solarized blue [14:31] (and, yes, I realize that the way the survey was conducted is not ideal and should've been tested on people with different seeing abilities as well; however, it's the best we've got right now) [14:32]  I don't know how the survey was done [14:32]  It was using your jsfifflle I assume [14:32] https://plus.google.com/102673546895803839652/posts/HXn215Yq9Yp [14:32]  *fiddle [14:32] and https://diasp.eu/posts/1984952 [14:36] as for Improvement of tooltip texts, perhaps we could draft some guidelines on tooltips [14:37] or, better yet, see if the Gnome or elementary HIG says something [14:38] "The tooltip should be a concise description of the control, but should provide more information than its text label where possible. For example, Open an existing document, or Undo last operation." [14:38] https://developer.gnome.org/hig-book/stable/toolbars-labels-tooltips.html.en [14:39] elementary HIG doesn't seem to say anything about tooltips [14:39]  Well, I would have prefered a duddle for the survey. We have half a dozen of commentaries... [14:39]  Two commentaries mention having the choice of the color [14:39] AFAIK, doodles are only for picking dates and times [14:40] <LLyaudet> Not really [14:40] the commentaries are easy to look through, don't think that's an issue [14:40] <LLyaudet> see this : https://dudle.inf.tu-dresden.de/Non-printing_characters_color/ [14:41] == _0rAX_ [~rax@197.202.238.41] has joined #libreoffice-design [14:41] == _0rAX_ has changed nick to _0rAX0_ [14:41] <LLyaudet> I posted it to the designlist the 2th of june [14:41] LLyaudet: oh, didn't know about dudle, thought you meant doodle [14:41] <_0rAX0_> Hello everyone [14:41] <LLyaudet> dudle is a free clone of doodle [14:41] _0rAX0_: hi Reda [14:42] <LLyaudet> Hi [14:42] <_0rAX0_> I almost missed it :P [14:42] <LLyaudet> I assume doodle also provide this kind of choices [14:42] _0rAX0_: good thing you didn't :) [14:42] LLyaudet: nope [14:43] I suppose now we can talk about the team structure [14:43] <LLyaudet> Let's finsh on the color first [14:44] <LLyaudet> We change the color for solarized blue as an easy hack then we add an option to modify this default ? [14:44] yup, that sounds right [14:45] the color change should make it into 4.3 and the option will come later (it's past UI freeze) [14:45] <LLyaudet> Ok I'll validate pedro's bug report for future enhancement. [14:45] sounds good [14:47] <_0rAX0_> mirek2, is this all the team? [14:47] not exactly [14:48] Astron is an active team member, but I guess he couldn't make it today [14:48] <_0rAX0_> I see. [14:48] and there's K. J., who doesn't tend to attend, but does most of the marketing visual design [14:49] btw, mahfiaz tends to be a silent listener most of the time [14:49] <_0rAX0_> ok [14:50] things could definitely be better :) [14:50] <_0rAX0_> Yes, with proper goals and subjects to discuss. :) [14:51] any particular subjects you'd like to address today? [14:51] <_0rAX0_> What about the voting? Have you found other nominees? Did you do it already? [14:51] so it seems like it's going to go this way: [14:52] instead of "leads", we'll have "experts", to show clearly that it's not really an official position [14:52] we'll specify what the position means on the wiki [14:53] and then whoever wants to take the position will have the position [14:53] <_0rAX0_> Ah, sounds good. [14:53] if there's several vying for a position, they can either split up the tasks or there can be a vote [14:55] I guess I'll specify the jobs on the wiki and then open that up to feedback on the mailing list [14:55] unless someone else wants to do that [14:55] ? [14:57] <LLyaudet> I can take care of this if you want [14:57] if you'd like to, sure [14:57] <_0rAX0_> You can also divide tasks based on skills [14:57] you have the three positions described in the mailing list [14:57] <LLyaudet> I'll add a section "Organization" after "Meeting" [14:57] it'd be better if you could reuse the existing out-of-date team page [14:58] https://wiki.documentfoundation.org/Design/Team [14:58] <LLyaudet> Ok should I mention IRC chat moderator either on "Team", "Meeting" or both ? [14:59] both would be fine [14:59] <LLyaudet> ok [15:01] _0rAX0_: I'm just wondering -- what are your thoughts on the future of LibreOffice? Where do you see it going? [15:04] _0rAX0_: or rather, how do you hope it will evolve? [15:05] <_0rAX0_> mirek2, tbh I don't think LO is in a very good shape UI/UX wise; up until I started working on the icons I actually thought of it as yet-another FOSS project that will never be the project it wants to be. [15:05] <_0rAX0_> But seeing the recent work, that impression might have gone down a little [15:05] could you be specific about which work you mean? [15:06] (I mean the recent work you mention) [15:07] <_0rAX0_> The new iconset to be specific. It's what brought me here [15:07] <_0rAX0_> It's a nice initiative [15:07] <_0rAX0_> If only the UI could follow [15:08] do you mean the redesigned Gnome-based Tango icon set or the monochrome set? [15:08] <_0rAX0_> I mean Sifr [15:08] <_0rAX0_> The one I worked on [15:09] ok [15:10] <_0rAX0_> So are there any plans to move it forward UX-wise? [15:10] <_0rAX0_> It's still screaming OpenOffice and that's not very good. [15:10] that's a complicated topic [15:11] so, first of all, there's this nice initiative to streamline options [15:11] https://wiki.documentfoundation.org/Design/Whiteboards/Options [15:12] in order to do that, we need to have a usable "Advanced options" dialog as well [15:12] (as the LibO devs are generally against removing options) [15:13] we have something called "expert config" which includes tons and tons of options, but without a search function, it's unusable, so we have to get devs to work on that [15:14] and we also have to go through all the options and sort them out [15:14] which we've done together on the chat, but I'm thinking it'd be better if a single person did it and then others commented on that [15:14] so that's one UX-related project... [15:15] <_0rAX0_> I see [15:15] then there's custom colors, and a student is working on that as part of his GSoC project [15:16] <_0rAX0_> I see a lot of 'Unnecessary' red tabs, but you said that devs are unwilling to remove features. How can this be done then? [15:16] most of the "Unnecessary" tabs will probably turn into "Advanced" [15:17] some have been removed [15:17] <LLyaudet> I changed the team page https://wiki.documentfoundation.org/Design/Team Tell me if it's ok [15:17] (e.g. Netscape HTML export) [15:17] and some of them may become necessary if the right tweaks are made [15:17] (those should be described in the box) [15:18] the color picker is kind of a testament to how tho process we've been using so far hasn't been working (and I'm to be blamed here) [15:18] https://wiki.documentfoundation.org/Design/Whiteboards/Color_Picker [15:19] we really need to bring it to a final design this summer [15:19] for the GSoC project [15:19] as for the GSoC, the plan is to first implement a color picker section called "Document colors", with all the colors used in the current document [15:20] the reasoning behind it is: a) we don't have themes, but want the user to be able to keep the same color scheme across the document [15:21] <_0rAX0_> I see a lot of mockups! [15:21] b) we want to be able to change the default color choices, but users using the old palette should be able to continue using it in their old documents [15:22] _0rAX0_: thoughts on the design process? [15:22] <_0rAX0_> I take it that those are done by the team members? [15:23] anyone may propose a mockup [15:23] but also anyone may be a team member, so yes? [15:24] (there's no way to officially gain "member" status -- anyone that contributes anything is a member) [15:25] <_0rAX0_> Hmm... propose based on what criteria? Seeing how different the mockups are leads me to think that there hasn't been much of a discussion going on before the mockup work started, am I right? [15:26] the process went like this: we established a goal and a scope, collected relevant art, collected proposals, discussed the proposals on our IRC chat (those used to be weekly), decided on what the tentative design should be like, had a single person make the tentative design, discussed it the following week at the IRC chat and refined and discussed until it was acceptable to everyone [15:27] _0rAX0_: the proposals were based on the scope and on the goal (that's the first sentence under "summary"), as well as our guidelines and principles [15:27] <_0rAX0_> And when did all of this go wrong? [15:27] <_0rAX0_> and stalled [15:28] that's hard to say [15:29] I tried my best at it in the e-mail I sent you [15:29] lack of: user testing, dev communication, skilled volunteers with lots of time, goals [15:30] in addition, it was basically design by committee, which rarely works [15:30] <_0rAX0_> I see a very obvious problem related to contibutor-seeking: There is no way for a new contributor to land a hand at an ongoing work unless they hunt for archived IRC logs and wiki pages... [15:31] what would you propose? [15:32] (take a look at https://wiki.documentfoundation.org/Design and comment on what should be done differently) [15:32] <_0rAX0_> It's not something that can be easily fixed. I've been thinking of a solution since last year [15:32] <_0rAX0_> I've seen something similar when I worked with the GNOME design team [15:32] <_0rAX0_> But they seem more efficient than the LO team [15:33] I think it's a general problem across all floss design teams [15:33] <_0rAX0_> yep [15:33] <_0rAX0_> I blame this IRC thing. [15:33] _0rAX0_: yes, but they have paid skilled employees [15:33] <_0rAX0_> No no, I'm talking about the methods they use [15:34] could you expand on that? [15:34] (btw, our workflow was heavily inspired by the Gnome workflow, or at least my understanding of it) [15:35] <_0rAX0_> First they have the gnome-mockups GH repo which hosts EVERYTHING related to what they work on [15:35] that's true [15:35] <_0rAX0_> Simply following that repo would give you an idea on what it's being worked on [15:36] <_0rAX0_> And they have the wiki pages with extensive explanation (not always) [15:36] <_0rAX0_> example: https://wiki.gnome.org/Design/Apps/SoundRecorder [15:36] <_0rAX0_> One of the apps I helped with [15:37] that seems about as explanatory as our whiteboards, no? [15:39] or is there a piece of information that's missing from our whiteboards? [15:39] <_0rAX0_> except that it has specific people working on it and the 'Status' area [15:40] <_0rAX0_> If I go to the link I gave you I can see who's working on the design and who's the developper [15:40] <_0rAX0_> and whether the project needs design or not [15:40] we have a similar status area (unless I'm misunderstanding you) [15:42] it's true that we should add a contributors section, though [15:42] (and that goes hand in hand with the planned project leads) [15:43] <_0rAX0_> Yes, I've seen it. Maybe the GNOME one has better wording? Simpler? [15:44] I agree, in some ways [15:44] but it also reflects different ways of working [15:45] <_0rAX0_> The other issue is the proposals. First, it's messy. There is no feedback on single proposals making it impossible for new designers to know what you really want. [15:45] what would you say is the best way to collect feedback? [15:46] <LLyaudet> Sorry to interrupt. I modified https://wiki.documentfoundation.org/Design/Team to include Mirek's point of view on leads and mine. Feel free to modify or comment [15:46] LLyaudet: please change "lead" to "expert" [15:46] <LLyaudet> ok [15:47] == abhra [~dr@117.254.95.73] has joined #libreoffice-design [15:47] LLyaudet: also, I would say project leads take care of whiteboards and aren't designed; they just take care of the project [15:48] LLyaudet: they should also be responsible for crafting the tentative design [15:48] abhra: hi abhra [15:48] <LLyaudet> Hi abhra [15:49] _0rAX0_: sorry for the interruption; feedback on proposals was usually given on the IRC chat or on the mailing list, and I agree that's not the best way to give feedback [15:49] <_0rAX0_> mirek2, Still thinking of a way [15:50] <_0rAX0_> At least restructure the page to be Proposals> proposal#1 > Feedback | #2 > Feedback... [15:50] I saw great hope in Gnome's Glitter gallery, which, if I understood it correctly, was a way to showcase designs and gather feedback as design progresses, but I don't think that's stable yet (or being worked on, for that matter) [15:51] _0rAX0_: ok, that sounds reasonable [15:51] we could restructure the whole workflow as well, though, so if you think it doesn't work well, don't hesitate to suggest something else [15:52] btw, what was your experience of the Gnome workflow? and how did you get involved? [15:52] <_0rAX0_> Like I said. I still blame IRC. I've seen it with GNOME and I'm seeing it with LO [15:53] <_0rAX0_> I was contacted by the dev who was working on the GNOME Calendar [15:53] (as an aside, I see some recent activity for glitter gallery: https://github.com/glittergallery/GlitterGallery/commits/master; I guess it's not dead after all) [15:53] <_0rAX0_> https://wiki.gnome.org/Design/Apps/Calendar [15:54] ok [15:54] how does the workflow go? [15:54] <_0rAX0_> And I already had contact with some of the design team members (we have each other circled in G+) [15:54] <_0rAX0_> so it was easy to get in [15:55] ok [15:55] <_0rAX0_> I personally dilike IRC so I don't go there a lot, I take the task work on it and then push to Github and find someone to give feedback [15:56] <_0rAX0_> dislike* [15:56] <_0rAX0_> usually I find more than one member and discussions and suggestions start pouring [15:57] ok; so if I understand correctly [15:57] : [15:57] there's one person doing the design, with other experienced designers giving feedback throughout [15:57] ? [15:58] <_0rAX0_> Hmm, It was like that in my case [15:58] that seems like a very sensible approach [15:58] <_0rAX0_> And seeing that only one person usually push designs I would say yes [15:59] <_0rAX0_> But the discussion goes on on IRC, events ... so again not very efficient if you're and "outsider" [15:59] <_0rAX0_> an* [15:59] I understand that [16:01] <_0rAX0_> My ideal workflow involves clean structure (pages...), clear goals, few cooks in the kitchen, and written feedback that is accessible at all times [16:01] agreed [16:01] hi mirek2 and LLyaudet [16:01] <_0rAX0_> Currently, the feedback is lost in all projects workign through IRC [16:02] entered a bit late today [16:03] abhra: currently discussing the design team workflow [16:03] one of the problems I frequently run up against is that the community is a fear of a lack of democracy [16:04] there's a pervasive feeling that there must always be consensus on everything [16:04] <_0rAX0_> Hmm, yep I've seen that before [16:04] I see that with Gnome as well [16:04] <LLyaudet> vote isn't consensus [16:05] democracy does not mean consensus [16:05] <LLyaudet> it's quite easy to organize things in a democratic way [16:05] <_0rAX0_> Yes, the GNOME design team don't vote on stuff. [16:05] right, sorry for the bad wording [16:06] <LLyaudet> personally, I prefer a quick vote when no new argument appear in a debate [16:06] mirek2, some people just afraid of changes; particularly drastic changes. they at least want the UI to remain same and not to be changed much. [16:07] <LLyaudet> for me this has nothing to do with changes, it's just about decision process [16:07] LLyaudet, if new arguments are not appearing in debate, how is a vote going to help? [16:08] well, I think the core problem is that the goals and purposes of things aren't clearly defined and people have different visions for things [16:08] <LLyaudet> democracy can be an efficient decision process [16:08] BTW, this was my first attempt at suggesting a purpose for Impress: http://nabble.documentfoundation.org/The-purpose-of-Impress-td4092904.html [16:08] <_0rAX0_> I agree with mirek2 [16:08] <LLyaudet> abhra : at the beginining of a debate arguments arise, but after some time no new argument appear and that's the time to end the debate with a vote. That's what I mean [16:09] LLyaudet: democracy is efficient, but it doesn't solve design problems well [16:09] mirek2, exactly. and one more thing should be remembered, its not possible to make everyone happy with a single step/decision [16:09] LLyaudet, oh! ok then [16:10] design decisions should never be a matter of opinion, but a matter of solving problems in the most elegant way possible [16:11] <_0rAX0_> Also you have to have a team of devs that understand and believe in what you're trying to do [16:11] <_0rAX0_> If you solve a problem that only exists in your head then good luck making it happen [16:11] that's another problem we have [16:12] <_0rAX0_> One problem is the one size fits all [16:12] <LLyaudet> mirek2: it's hard to define "an elegant way" I had a lengthy discussion on this with astron on the ml. In the end we have only opinions (that may be funded on rationnal arguments) [16:12] <_0rAX0_> LLyaudet What about user-testing? do you do that? [16:13] <LLyaudet> results of uesre testing are rationnal arguments [16:13] <LLyaudet> *user [16:13] _0rAX0_: no, but I hope we can get that ball rolling [16:14] oh, except Bjorn Balazs has done some testing on our icons [16:14] <LLyaudet> please read this topic "Light Blue for Non-printing characters" on the ml if you want to understand my point of view [16:18] LLyaudet: I understand your point of view, but still maintain that voting should be used as an absolutely last resort, when no amount of additional user testing, goal specification, or UX guidelines can solve the problem [16:19] <LLyaudet> I agree with that mirek [16:19] ok, good :) [16:20] would you agree to whiteboards being worked on by a single designer, working with a dev and open to community feedback? [16:20] just to add the link of the light blue non printing character in this discussion - http://nabble.documentfoundation.org/Light-Blue-for-Non-printing-characters-td4110478.html [16:22] <_0rAX0_> http://blog.codinghorror.com/listen-to-your-community-but-dont-let-them-tell-you-what-to-do/ [16:22] LLyaudet: (that question was directed at you) [16:22] <LLyaudet> I agree if the community feedback is part of the process from the start and if it can stop the process if further debate is needed [16:24] so how about this: the project lead can only take the project up to "tentative design" and that design has to be approved on the IRC chat and by the three "experts" we will hopefully have if they're not on the chat [16:26] feedback could be given throughout [16:27] LLyaudet: what do you think? [16:28] _0rAX0_: thanks for the link, completely agree [16:28] <LLyaudet> project must be advertised on the ml and if soemeone requests a vote, there must be a vote. The opinion of the three experts is enough if nobody opposes [16:28] sounds good to me [16:28] <LLyaudet> still reading the link [16:29] agreed on the ML part, but not the vote part [16:29] voting at every stage will delay the process. [16:29] <LLyaudet> but that's the last resort vote we talked about... [16:29] <LLyaudet> I'm talking baout voting at the end [16:30] <LLyaudet> *about [16:30] how about this: if someone finds a design problem, that particular design decision must be approved or rejected on the IRC chat/by the experts [16:31] <LLyaudet> sorry but I'll maintain last resort is voting [16:32] <_0rAX0_> LLyaudet, even though voting can sometimes result in the poorest choice being made? [16:32] and if they can't reach a decision, then the principles and guidelines will be consulted; and if there's not any clear indication of what to do from those, then the problem will be tested on users; and if that can't be done or doesn't have a clear outcome, only then will there be a vote [16:32] as a last resort [16:33] how does that sound? [16:33] <LLyaudet> "experts" opinions also can sometimes result in the poorest choice being made. I know no decision process that can garantee quality of decisions [16:34] it wouldn't just be expert opinions, but opinions based on solid arguments from everyone at the IRC chat + the experts [16:34] and there has to be consensus in that case [16:35] <LLyaudet> mirek I almost agree the only controversial point left is "doesn't have a clear outcome" because it is sometimes a matter of interpretation but for the intent I agree with you [16:36] how will these experts be chosen? will they be chosen for lifetime? another potential for controversy! [16:37] <LLyaudet> abhra: voted for 6 months ? [16:37] LLyaudet: what don't you agree with? If there are multiple confilcing interpretations of user testing, then that falls under "doesn't have a clear outcome". [16:37] <LLyaudet> abhra see : https://wiki.documentfoundation.org/Design/Team [16:38] <LLyaudet> mirek2: then ok [16:38] LLyaudet: about the experts: [16:38] <LLyaudet> I was afraid of "dominant" interpretation from the experts [16:39] LLyaudet, if they are voted by the users then they will represent the users. if users do not agree with their design choice/performance, they will be outvoted. [16:39] it's been discussed on the maling lists (especially the board-discuss list) that not having voted-on leads has been working relatively well for us [16:39] <LLyaudet> anyway I would like to add that lot of people fear voting when it can be done efficiently and reach good decisions most of the time as the other decision process [16:40] but I'm not against voting there; we could definitely vote for experts, but let's please not make a big hassle out of it :) [16:41] LLyaudet, so why should another vote be conducted for the users? afterall, mirek2 proposed consensus among the experts for any design changes! [16:41] <LLyaudet> abhra: my opinion is a general opinion. In politics, we elect people and the result is far from what we expect. That's what I vote for direct referendums and in general I'm for direct democracy not representative democracy [16:42] <LLyaudet> *Thats why [16:43] <_0rAX0_> mirek2, LLyaudet: excuse me for being a bit simplistic here but isn't this discussion a little bit futile at the moment? How do we choose the best results implies that the problems that are present _before_ the phase are solved, no? [16:44] I'm a bit lost now, sorry [16:44] _0rAX0_: could you rephrase that? which phase? [16:46] <_0rAX0_> when you talk about "the best way to come to the best results" it implies that you have already solved the problems of "attracting contributors" "structuring the project" "finding 'experts'" "having a good workflow _before the tentative design results" "having a good system for getting feedback" ... [16:47] <_0rAX0_> all of those are stil present [16:47] <_0rAX0_> still* [16:47] _0rAX0_: isn't this an important part of finding the right workflow? [16:48] the decision making process affects the workflow before the tentative design [16:49] <_0rAX0_> What about the steps before the tentative design? [16:49] <_0rAX0_> Each step has its own set of issues [16:49] yes, that's true [16:50] <_0rAX0_> Even if you agree that leaving voting as a last resort [16:50] it seems like we've agreed to give a lot of creative power to the project lead given that the whiteboard is advertised on the design list and given that there's a decision process when a tentative design is done [16:51] so I imagine the entire process to go as follows: [16:51] 1) a designer and a dev agree to work on a project [16:51] if a dev wants to work on a project, he contacts the design ML and hopefully an interested designer will show up [16:51] and vice versa [16:54] 2) the designer and the dev will formulate a goal and specify the scope of the project with the help of the design team experts [16:54] <_0rAX0_> mirek2, sorry to interrupt but how and who decides that a project is needed to be worked on. Woldn't it this be inneficient without first having goals? [16:55] well, goals are another matter, but we can talk about them [16:56] LibreOffice is a meritocracy and a very accepting meritocracy at that [16:56] <LLyaudet> _0rAX0_: at this point of the process, I would allow free will of a designer and a dev, the control can appear later [16:57] I would love to have goals motivate the progress of LibreOffice and I hope to move closer to that [16:57] <_0rAX0_> LLyaudet I agree about the free will part, but I suggest that LO would have clear goals and THEN it's up to the designer to choose what then can work on [16:58] <_0rAX0_> they* [16:58] definitely [16:58] <LLyaudet> ok for the goals as well [16:58] right now, it's been devs that choose what to work on [16:59] <_0rAX0_> One main goal to make it usable for new users. LO has a frightening UI compared to competitors [16:59] agreed [17:00] that said, you need a dev to work on something [17:00] <_0rAX0_> Yes [17:01] it's been quite hard to find devs that would work on front-end stuff [17:01] and VCL is, from what I've heard, quite a mess, so it's not very approachable for volunteer devs [17:02] easyhacks?? [17:02] do you have any tips for attracting devs to work on UX-related issues? [17:03] abhra: yeah, those are good! we need to have more of those! :) [17:04] <_0rAX0_> mirek2, without goals there is nothing you can do at all. Let's say you attract someone, what would the objective be? and how would they go at dealing with VCL? [17:05] well, here's what I think we should do in terms of goals: [17:05] I'd love to define a purpose for each module [17:05] one clear purpose [17:07] and basically work toward fulfilling that purpose in the best way we can [17:07] your suggestion for impress was impressive mirek2 :) [17:07] :) thanks [17:08] so, for example, for Impress I suggested "to make it simple and quick to craft a slide show to perfectly complement a speech" [17:10] if you pick that apart, you'll see that e.g. "simple" brings a focus on an uncluttered interface [17:10] quick does as well [17:11] quick could also imply being able to e.g. just write a quick outline + images and get a good result automatically [17:12] complementing a speech implies the presentation content [17:12] not a wordy essay, not an auto-play animation [17:13] "perfectly" implies being able to tweak things to make them perfect if automation gets things wrong [17:14] complementing a speech also implies that there's a speech to go with the presentation, which could result in features that e.g. help you record the speech and publish it alongside your slides [17:14] etc. [17:15] so, basically, the design would be based on looking at the purpose and seeing if anything could be done better [17:16] could things be simpler, quicker, could the presentation complement a speech better, and so on. [17:16] _0rAX0_: thoughts on that? [17:17] <_0rAX0_> one sec i'm on the phone [17:18] (actually, scratch the part about recording the speech -- that's actually NOT part of the purpose) [17:23] on another topic, there is no topic set for this channel. [17:23] may i set a topic for the channel? [17:23] go ahead [17:24] something like - This is the LibreOffice DESIGN channel, covering user experience design and visual identity design on the last Sunday of every month at 12:00 UTC => #libreoffice-design, bugs => http://goo.gl/IM1Yw |  https://wiki.documentfoundation.org/Design | mailing list subscription: design+subscribe@global.libreoffice.org [17:24] sure [17:26] == abhra changed the topic of #libreoffice-design to: This is the LibreOffice DESIGN channel, covering user experience related to design and visual identity on the last Sunday of every month at 12:00 UTC => #libreoffice-design, bugs => http://goo.gl/IM1Yw | https://wiki.documentfoundation.org/Design | mailing list subscription: design+subscribe@global.libreoffice.org [17:30] <_0rAX0_> abhra, how about a link to a page containing all those three link? [17:30] <_0rAX0_> mirek2, back [17:31] great [17:31] thoughts on defining a purpose? [17:31] <_0rAX0_> I think that would be a great starting point [17:32] ok [17:32] <_0rAX0_> I suggest that LO would have a main goal of being a 21st century suite that is easy for new users and powerful for existing ones [17:32] _0rAX0_, does any single libreoffice official page have all the three links? [17:33] <_0rAX0_> abhra, no idea, I'm new here. :P [17:34] abhra: you can just point to the Design page [17:34] _0rAX0_, no problem; so am i. if i find out, i'll change it [17:34] it mentions the mailing list and the bug assistant [17:34] https://wiki.documentfoundation.org/Design [17:34] mirek2, ok will do [17:35] <_0rAX0_> great [17:35] == abhra changed the topic of #libreoffice-design to: This is the LibreOffice DESIGN channel, covering user experience related to design and visual identity on the last Sunday of every month at 12:00 UTC => #libreoffice-design | https://wiki.documentfoundation.org/Design [17:35] done [17:36] <_0rAX0_> so mirek2, is them main goal okay? [17:36] I'd prefer setting specific purposes for the individual modules just because LibreOffice is such a varied suite [17:37] e.g. I expect users of Base to have very different needs from the users of Impress [17:38] <_0rAX0_> Yes, but both should be usable and modern-looking. You can't fix Impress in a way and Base in a another way, no? [17:39] definitely, but I'm not sure that goal brings us anywhere [17:39] both usable and modern-looking should be based on our guidelines [17:40] (it's also worth noting that the design of LibreOffice is a bit restricted by the need to look and feel native) [17:43] that said, I'm not against your goal, just not sure if it gets us anywhere [17:43] <_0rAX0_> That would be pretty hard to maintain. Expecially on Windows and macOS. Both have different UX patterns. And with Ubuntu and GNOME doing their own things it would be difficult [17:44] <_0rAX0_> My goal is intended as a starting point [17:44] <_0rAX0_> it can be translated to each component [17:45] <_0rAX0_> in way that makes sense to it [17:46] sorry, I have to go now [17:46] but I would like to continue the conversation sometime... [17:47] ... could we set another IRC chat, maybe? [17:47] or should we just communicate through e-mail? [17:47] <_0rAX0_> I do prefer email myself [17:47] ok [17:47] <_0rAX0_> thank you all [17:48] can it be on the public mailing list, tehn? [17:48] then [17:48] (the design team mailing list) [17:48] <_0rAX0_> yes, I'll join then. Link? [17:48] joining instructions at https://wiki.documentfoundation.org/Design [17:48] <_0rAX0_> OK thanks [17:48] I'll send the e-mail later [17:49] <LLyaudet> I'll post the log of today IRC meeting on the wiki [17:49] great, thanks :) [17:49] bye [17:49] <LLyaudet> see you [17:50] == mirek2 [56311b91@gateway/web/freenode/ip.86.49.27.145] has quit [Quit: Page closed] [17:50] <_0rAX0_> see you later guys [17:50] <LLyaudet> bye [17:50] == _0rAX0_ [~rax@197.202.238.41] has quit [Quit: _0rAX0_] [17:50] bye [17:52] == abhra [~dr@117.254.95.73] has left #libreoffice-design ["Leaving"]