Design/Meetings/2012-04-14

General

 * Date/Time: 6:00 pm GMT (supposed start time)
 * Location: IRC, freenode, channel #libreoffice-design

Attendees

 * alexanderW
 * Maggie
 * astron
 * Mirek2

Log


Mirek2 18:00:23 hi astron

astron5 18:00:26 hello so wait five more mins for more people? 18:02:02 Mirek2 18:02:24 since we're the only two here so far, I'd like to talk about your https://wiki.documentfoundation.org/Design/Whiteboards/PropertiesButtonLayout page, if that's ok

astron5 18:03:02 ahem, ok, we can, but on the other hand no one is currently working on that...

Mirek2 18:03:33 my issue is with the summary

astron5 18:03:44 okay... if its only that. sure, discuss this then 18:03:53 Mirek2 18:04:00 like I said on the mailing list, the summary should be generic and allow for some creativity

astron5 18:04:24 hm, but where do we end up with that? "improve office suite" 18:04:34 we need to make sure that we dont get so generic that the problems with the current approach arent in the summary any more... 18:05:35 mirek_2 has entered the room 18:05

astron5 18:05:51 were you disconnected?

mirek_2 18:06:04 yes, Firefox crashed

astron5 18:06:13 ok.

mirek_2 18:06:32 however, your summary basically dictates the design: "no OK button, live changes, undo/redo buttons, and no more (that would be too many)"

eagles0513875 18:07:22 hey astron5

astron5 18:07:22 well, yes those are the problems that we currently have, right?

astron5 18:07:31 hello

eagles0513875 18:08:08 do have some updates regarding android UI work i am doing

mirek_2 18:08:08 how about something like "streamline (or rethink or redesign) the bottom row of buttons on dialogs"?

eagles0513875 18:08:08 I'm wondering if you guys would be interested in me testing a white board for android UI development Mirek2 hat sich abgemeldet (Ping timeout: 245 seconds) 18:08

eagles0513875 18:08:30 btw i might ask florian about who is in charge of registering channels for the TDF related stuff like since this 18:08:33 mirek_2 18:08:47 @eagles: that's not really what a whiteboard is for; it's for crafting a design

eagles0513875 18:08:51 ahh ok nm then 18:08:52 astron5 18:09:04 whats your problem with this channel?

eagles0513875 18:09:15 astron5: its an unregistered channel

astron5 18:09:21 so?

eagles0513875 18:09:44 wouldn't it be better to have this channel registered and make it a permanent official channel like the libreoffice and libreoffice-dev but this focused on the design community 18:09:52 mirek_2 18:09:58 I don't know how to do that; if you know how to, go ahead, please

astron5 18:10:14 whats the gain?

eagles0513875 18:10:58 the gain would be an official channel where anyone with design questions can pop in and ask a quick question and get help and suggestions yes there is the mailing list but that is not always the fastest way to get an answer if someone is in the middle of doing some work for instance the white boards. 18:11:15 astron5 18:11:50 ill ask later today (after the chat) (since hes in the room) 18:11:58 mirek_2 18:12:02 the design team is too small to be able to answer questions 24/7 i think 18:12:02 astron5 18:12:13 right

mirek_2 18:12:14 but I would have no problem with the room becoming official @astron: back to the whiteboard 18:12:28 astron5 18:12:32 right

mirek_2 18:13:07 in my eyes, an undo and redo button on dialogs is a bit of an overkill, and I would not put it in my proposal

astron5 18:13:32 uh, yeah, i had the same problem with it at first,... christoph talked me into that ... 18:13:42 mirek_2 18:13:55 that's an example of a reason why the descriptions should remain simple sentences

astron5 18:14:05 ..?

mirek_2 18:14:13 ok, i'm just trying to say that it's something that belongs in the proposal part, not in the description part

astron5 18:14:26 it is in the proposal

eagles0513875 18:14:33 ill be bk I'm going to eat something

astron5 18:14:52 the summary only says that you should enable people to undo/redo conveniently

mirek_2 18:15:13 yes, but there's "the dialog UI is not very forgiving as it doesn't allow atomic undo/redo actions"

astron5 18:15:24 whether you add the buttons to the dlgs or not is not in the summary mirek_2 18:16:01 and the whiteboard is focused on the bottom row of dialogs

astron5 18:16:04 (you can also just have buttons on the toolbar or the menu)

mirek_2 18:16:06 so it's implied that you're supposed to add undo/redo to the bottom row of dialog buttons

astron5 18:16:10 no

mirek_2 18:16:24 yes, you can, but that's not what the whiteboard is about

astron5 18:16:25 the toolbar buttons already exist you "just" need to integrate with them 18:16:42 mirek_2 18:16:42 yes I understand 18:16:43 right 18:16:49 but that doesn't belong on this whiteboard 18:16:59 since this whiteboard is concerned with the buttons on dialogs only... 18:17:09 it'd be a very useful feature to have, though 18:17:58 just doesn't have much to do with the whiteboard unless you put undo/redo buttons at the bottom of dialogs 18:18:20 astron5 18:18:25 i am sorry, i dont see the point of moving to a new whiteboard

mirek_2 18:18:41 I'm not saying that

astron5 18:18:43 and immediacy does have to with undo/redo

mirek_2 18:19:13 here's my problem with the whiteboard: it doesn't have a single goal its goals are based on a single proposal 18:19:27 and therefore it's hard to design for 18:19:33 if it's summary was only "Redesign the bottom row of dialogs", it'd be much easier to design for 18:19:59 astron5 18:20:33 but ... we dont want to "redesign the button row", what we want is to solve the problems with it

mirek_2 18:20:50 with dialogs or with the button row?

astron5 18:21:15 with button rows as part of dialogues?

mirek_2 18:21:25 right

astron5 18:21:48 anyway, we cant replace the reasoning why we want things.

mirek_2 18:22:06 if it's only about fixing problems with that button row and not about redesigning it, then the "undo/redo" buttons have no place there

astron5 18:22:06 (because doing things without a reason is pointless) okay, then make a proposal in earnest how you would like to structure this thing. 18:22:58 mirek_2 18:23:36 it depends: do you want to redesign the button row (e.g. add undo/redo) or just simplify it?

astron5 18:23:48 both because i want to solve a problem 18:24:07 mirek_2 18:24:59 then "Redesign the button row on dialogs" should be the goal of the whiteboard alexander has entered the room 18:24 alexander ist jetzt bekannt als Guest90209 18:25 Guest90209 ist jetzt bekannt als alexanderW 18:25

alexanderW 18:25:13 hi

mirek_2 18:25:14 or, rather, on "advanced dialogs" or "properties dialogs", which we'll define under "Definition of terms" hello 18:25:15 alexanderW 18:25:16 sorry for being late

astron5 18:25:16 hi alexander were discussing whiteboard summaries 18:25:36 mirek_2 18:25:52 using https://wiki.documentfoundation.org/Design/Whiteboards/PropertiesButtonLayout as an example

astron5 18:25:52 specifically on my button row proposal right... 18:25:58 mirek_2 18:26:35 I've been arguing that the goals need to be stated in a generic way, like "Redesign the button row on dialogs", to allow people to come up with their own proposals whereas the description on https://wiki.documentfoundation.org/Design/Whiteboards/PropertiesButtonLayout seems to allow very little creative space for others and points to only a single possible proposal, in my view 18:27:25 what do you think, Alex? 18:27:32 alexanderW 18:27:45 one sec

mirek_2 18:28:23 ok

alexanderW 18:28:55 you mean the points listed under 'scope'?

astron5 18:29:03 no, summary

mirek_2 18:29:20 (the first sentence of the summary) (or, rather, the first paragraph of the summary) 18:29:42 astron5 18:29:47 exactly

alexanderW 18:30:35 I think it's good since it adresses the current issues Why would it limit the creativity? 18:31:16 astron5 18:31:43 mirek argues we only want one very generic sentence.

mirek_2 18:32:11 well, basically, it asks for undo/redo buttons, no apply/OK button, and no other buttons as that would be too many there's not really any other way to design it 18:32:14 and if somebody disagress with having undo/redo on the button row, for example, then he has to go to a different whiteboard, since this one explicitly asks for the feature 18:32:47 astron5 18:33:32 i am not asking for undo/redo on the button row youre reading that into it. 18:33:50 mirek_2 18:34:00 but the whiteboard is called "PropertiesButtonLayout" it's about the layout of buttons on properties dialogs 18:34:10 if undo/redo isn't supposed to be among them, then it isn't supposed to be on this whiteboard 18:34:40 astron5 18:35:04 huh? it can be, but it doesnt have to

alexanderW 18:35:20 So those issues should be listed as part of a proposal?

astron5 18:35:21 (i favour it, btw)

mirek_2 18:35:39 @alex: yes, I would say they should and not part of the summary 18:36:04 in my view, the summary should simply be something like "Redesign the button row on properties dialogs" 18:36:35 eagles0513875 18:37:00 alexanderW: are you the one that emailed me about the android work and how to get that setup or am i getting u mixed up btw

alexanderW 18:37:25 @eagle: No, I didn't hm 18:37:32 Don't we all agree that those issues exist? 18:38:18 mirek_2 18:39:01 that's not really the point yes, those issues exist, but they don't necessarily belong on a single whiteboard 18:39:35 the issues are random unless they're put into a single proposal 18:39:54 I feel like I can't propose a dialog without undo/redo buttons in the bottom row and an "Apply" button if I wanted to on this whiteboard 18:40:25 because of what the summary says 18:40:32 astron5 18:40:42 sorry was occupied with something else...

mirek_2 18:41:12 (there are good reasons for not having undo/redo or "Apply" or doing away with "Help", like following the OS's HIG, for example)

astron5 18:43:07 maybe ... although we never did that.

alexanderW 18:43:47 We'd need to discuss those different premises when merging the proposals into a single tentative design, then

mirek_2 18:44:17 another example -- if I put "It's hard to define a custom color" under "Summary" on the "Design/Status bar" page, it wouldn't really make sense on the whiteboard unless a proposal put custom colors into the status bar

astron5 18:44:51 what, sorry?

mirek_2 18:45:06 @alex: yes -- that's what the assessment of proposals is for @astron5: it's a theoretical example 18:45:15 suppose I created a mockup with a place for creating custom colors in the status bar 18:45:35 astron5 18:46:11 okay. Maggie has entered the room 18:46

Maggie 18:46:52 Sorry I'm late. Just came back from outside.

mirek_2 18:46:53 and then put "The status bar is overcrowded and hard to read through. It's hard to define a custom color. We need to fix these issues." under the summary of the "Design/Status bar" page Don't you think it would imply that we should have custom colors in the status bar? 18:47:20 and make it hard to propose not to have them there? 18:47:50 hi maggie 18:47:50 good to have you here 18:47:57 astron5 18:48:03 i think thats absurd.

Maggie 18:48:21 I'm just going to listen for now.

astron5 18:48:22 and doesnt make any sense whatsoever as a summary were discussing the summary of https://wiki.documentfoundation.org/Design/Whiteboards/PropertiesButtonLayout and ... hi! 18:48:55 mirek_2 18:49:07 how so? it's basically the same issue, only it seems stranger to put custom colors in the status bar right, I agree 18:49:07 @Maggie: we're discussing the summary of pages right now 18:49:07 I'm arguing that it should be a single sentence with a single goal in mind 18:49:20 and that the summary of https://wiki.documentfoundation.org/Design/Whiteboards/PropertiesButtonLayout is an amalgamation of different issues 18:49:47 and the only proposal that makes sense based on the summary is the one proposed on that page 18:50:13 astron5 18:50:51 its the only proposal that currently is there, not the only to make sense

alexanderW 18:52:18 What about the scope? The points listed seem quite specific, too 18:52:30 mirek_2 18:53:43 I agree -- the scope should be changed too but the scope, of course, depends on the summary 18:53:53 astron5 18:55:07 okay, right, if you want the scope widened up then ... what would you propose

mirek_2 18:55:28 I'd propose to figure out the summary right now here's another example of what I mean 18:55:40 if I put "The status bar holds too many items that only serve to confuse users. Additionally, the bar doesn't show the current background/foreground color. Finally, while it shows the position of objects, it doesn't allow the user to manually change it. All of these problems should be solved." on the Design/Whiteboards/Status bar page 18:56:02 astron5 18:56:56 makes sense to me

mirek_2 18:57:11 then the designs would be pretty much locked into having to show the background/foreground color and allowing the user to type into the status bar to change the position of objects it makes sense, but it restricts the proposals too much 18:57:14 there's no consideration for people who think that the user shouldn't be allowed to type into the status bar 18:57:46 or that the background/foreground color belongs somewhere else 18:57:59 astron5 18:58:33 maybe, but it also shows which things were though of as being problematic

alexanderW 18:58:35 The alternative would be 'Cleaning up the status bar'?

mirek_2 18:58:49 yes, something along those lines

astron5 18:58:57 +t

mirek_2 18:59:13 a proposal could suggest to show the background/foreground color and allow the user to type into the status bar to change the position of objects and we'd consider that while evaluating proposals 18:59:23 astron5 18:59:35 oh forbid, that still means that proposals are supposed not to add to the status bar

mirek_2 19:00:12 depends on the scope and the summary 19:00:20 if it's simply streamlining the current status bar, then we shouldn't add features 19:01:25 new features would be proposed under a different whiteboard then 19:01:39 astron5 19:02:00 ... oh my thats becoming complicated (for my little head) 19:02:15 mirek_2 19:02:20

basically, if the scope forbids adding features, then the proposals shouldn't add features 19:03:20 if a designer wanted to add a feature, he would make a separate whiteboard 19:03:34 astron5 19:03:55 but the direction you are taking here is "status bar" instead of "streamline he status bar"

mirek_2 19:04:48 alex suggested "cleaning up the status bar" which could (but doesn't have to) mean "no new features" 19:05:14 or at least I thought you understood it as such 19:05:38 astron5 19:05:41 it means "no new features inside the status bar"

mirek_2 19:05:59 since you wrote "oh forbid, that still means that proposals are supposed not to add to the status bar" right, exactly 19:05:59 anyway, we've really swerved off topic 19:06:16 astron5 19:06:50 okay... should we postpone that discussion ? 19:07:08 mirek_2 19:07:09 it seems like a pretty important matter it influences the way we design all our whiteboards 19:07:22 I mean the discussion about whether to include various bugs in our summaries 19:07:47 Maggie, Alex -- your thoughts? 19:08:54 alexanderW 19:09:10 on what exactly?

astron5 19:09:13 afk for a sec

alexanderW 19:09:20 the bugs, the summary?

mirek_2 19:09:28 the summary

Maggie 19:11:00 from what I can tell, you feel that the summary for the Button Properties covers too many issues at once, right?

mirek_2 19:12:25 I feel that it basically summarizes the proposal and leaves little room for different views on the button properties design

alexanderW 19:12:40 Maybe everyone who wants to submit a proposal should mention the main reason why wants to do so on the mailing list so that we can agree on a single phrase

mirek_2 19:12:51 for example, I'd like the "Undo/Redo" buttons to not be among the buttons on dialogs

Maggie 19:13:31 Why not?

mirek_2 19:14:54 because they're not necessary, they go against every OS's HIG, and the undo/redo on the main toolbar should suffice but that's beside the point 19:14:54 I feel that every whiteboard should be aimed at either a) improving a UI element, b) making a task easy or possible, or c) improving the way a certain area of LibreOffice is handled. 19:16:50 Like a) "Make the status bar more usable", b) "Make it easy to pick a custom color", or c) "Improve color management" 19:17:09 so I like the sentence "Redesign the button row on dialogs" for the summary of "Design/Whiteboards/PropertiesButtonLayout" 19:18:36 astron5 19:18:37 mirek, please start a new whiteboard on this, ill add my proposal.

mirek_2 19:19:12 on the summary for whiteboards? or on redesigning the button row on dialogs? 19:19:36 astron5 19:20:13 ah, no, id like to ask you to start a whiteboard on the button row please 19:20:23 mirek_2 19:21:29 I could just tweak the current one I don't think there's much use in having two whiteboards that target a similar thing 19:21:29 astron5 19:21:44 (weve burned 80 mins on this, i dont think this is productive.) the original proposal will be archived 19:22:09 mirek_2 19:23:15 sorry, I don't want to create problems, but I am nitpicky and adamant 19:23:21 I'll put my proposed revision of the page on my user page and we'll discuss it on the mailing list, ok? 19:23:50 astron5 19:23:52 there are always two needed to create a problem.

alexanderW 19:24:17 alright what's next? 19:24:18 astron5 19:24:21 so: we wont get this out of the way right now okay, id like to talk about the status bar removal thingy 19:24:44 mirek_2 19:24:52 I guess not, if we're both convinced we're right ok 19:25:09 astron5 19:25:26 so, kendy approached me about that here.

mirek_2 19:25:32 I merged it with the status bar reorganization proposal

astron5 19:25:40 oh great ill have a look again 19:25:51 mirek_2 19:26:26 alright https://wiki.documentfoundation.org/Design/Whiteboards/Status_bar 19:27:17 astron5 19:27:24 anyway, his argument was, that if we show only part of it at the bottom of windows and while doing that, overlay the status bar, it will just look like a graphics problem... (ie ugly) 19:27:33 alexanderW 19:27:36 I think the link on the overview page is broken

mirek_2 19:27:52 I just broke it, and then fixed it minor misspelling 19:27:58 alexanderW 19:28:27 ah

mirek_2 19:28:34 @astron: what do you mean? btw, I've changed my mind on keeping the status bar -- I'd like to completely replace it, but I still have to work on the proposal 19:29:26 astron5 19:30:08 what do you mean, changed your mind? i thought you always were of that opinion

mirek_2 19:30:59 i'm still not sure what you mean where do we overlay the status bar 19:31:11 astron5 19:31:28 well in the case where the zoom slider overlays the horizontal scrollbar, that will look ugly. sorry, for using statusbar, i meant scrollbar 19:31:45 mirek_2 19:32:04 The zoom slider wouldn't overlay it, it would be shown above it

astron5 19:32:21 that breaks fitts law, though fitts law compliance, i mean 19:32:37 mirek_2 19:33:39 yes, but only when the horizontal scroll bar is shown which isn't that often in Writer or Impress 19:34:04 astron5 19:34:53 not in writer, but due to a bug/feature in impress,yes most important is calc, though. 19:35:05 mirek_2 19:35:15 having the slider be part of the row that the horizontal scroll bar is part of would be a problem in Calc and Draw, where part of it is already taken up by layers mirek2 has entered the room 19:35

mirek2 19:35:56 disconnected, again

astron5 19:36:00 (as in calc we are always in the position that the zoom slider overlays useful content ) 19:36:02 nothign happened since your last post 19:36:12 mirek2 19:36:18 ok, good as Calc features infinite scrolling, I wouldn't worry about it. 19:36:57 the user can always get to the content 19:37:04 astron5 19:37:22 you can reach the end. its not truly infinite. 19:37:29 but a corner case nevertheless 19:37:38 mirek2 19:38:01 sure, but I doubt a user will truly have a problem with accessing the billionth cell in the billionth row on the other hand, I'm still not against having the zoom slider in the vertical scroll bar 19:38:33 astron5 19:38:43 i think its the millionth row in the 1024 column which creates other problems 19:39:07 mirek2 19:39:22 well, it's still improbable that the user will film up 1 billion 24 million cells @astron: I know you argued that it would make the vertical scroll bar too small 19:39:54 but for that to be a problem, the window would have to be so small that it wouldn't really be possible to use it anyway 19:40:27 especially if the zoom slider collapsed into a single button, just like many volume sliders collapse into buttons 19:41:17 a slider on the side would also fare better under Fitts law 19:41:55 astron5 19:41:55 yes, but then youd need two clicks (minimum) to get the funtionality why that? 19:42:01 mirek2 19:42:21 as most operating systems put a bar at the bottom, but not a single one puts it on the right side

astron5 19:42:51 ah, right.

mirek2 19:43:00 so even if our zoom slider was at the bottom, it wouldn't follow Fitts law under Windows, macOS, Gnome 2, KDE, Cinnamon, elementary, ... the zoom slider would expand on hover 19:43:15 check out how youtube's volume slider works 19:43:26 astron5 19:43:36 windows seem to never be fullscreen under macOS

mirek2 19:44:03 actually, I forgot that macOS now has a fullscreen mode

astron5 19:44:31 only for apps that support it (i think – not a mac user) 19:44:52 mirek2 19:44:57 oh anyway, where does this leave us? 19:44:58 I guess I'll refine my proposal 19:45:06 and put back a vertical zoom slider 19:45:15 if you'd like a horizontal one, you can add your proposal too 19:45:28 astron5 19:45:37 ill try

mirek2 19:45:45 ok finished with zoom for now? 19:45:53 astron5 19:46:04 do you still think a single button would suffice? =zoom button 19:46:24 mirek2 19:46:29 I want a slider that would collapse into a hover-triggered button when the window was too small 19:46:49 astron5 19:47:11 ah okay... sounds useful

mirek2 19:48:00 anyway, I put up an idea workflow that each whiteboard could go through: https://wiki.documentfoundation.org/User:Mirek2#Proposed%20Idea%20Workflow tell me what you think 19:48:01 the status bar whiteboard or the color handling whiteboard could go first 19:48:01 astron5 19:48:03 okay... then lets move on i think youre too ambitious 19:48:50 (your timeline is) 19:48:58 mirek2 19:49:43 too little time for proposals? would 2 weeks be better? 19:49:46 astron5 19:49:54 i think.

alexanderW 19:50:15 I doubt it is that easy to find developers for so many whiteboards

mirek2 19:50:30 well, right now it's hard to find any interested developers in general

astron5 19:50:48 i see lots of interested faces

mirek2 19:50:50 but maybe some good designs might convince them to work on a feature or two

alexanderW 19:51:05 cool

mirek2 19:51:05 really?

alexanderW 19:51:17 btw, are you already in Hamburg?

mirek2 19:51:20 could you ask them what they'd like to work on?

astron5 19:51:22 i am.

mirek2 19:51:36 so that we know what to design first?

astron5 19:52:00 so, ive had kendy come up to me, he wanted to work on getting previews for styles ive talked a bit to throsten (to work with on sth about:config like) 19:52:29 -ro+or 19:52:37 and of course, kendy has also thought about the status bar 19:52:53 ill talk to markus later about conditional formatting 19:53:17 alexanderW 19:53:57 you mean in the drop-down box or live previews?

mirek2 19:53:57 ok, so status bar and style drop-down should be our priorities?

eagles0513875 19:53:57 astron5: any chance to poke for about my android UI patch to at least get that in the master branch

astron5 19:55:05 im sure, tor can judge your patches better than i can. and as you are getting responses from him, you know you have his attention @alex: yes 19:56:01 @mirek: well, ~yeah 19:56:20 Maggie 19:56:39 Say, is anyone working on converting the whiteboards to the new templates for the following? https://wiki.documentfoundation.org/Design/Whiteboards/Styles_and_Formatting_window 19:56:47 https://wiki.documentfoundation.org/Design/Whiteboards/OptionsRework 19:56:58 https://wiki.documentfoundation.org/Design/Whiteboards/Progress_Indicators 19:57:08 astron5 19:57:11 im gonna do options

Maggie 19:57:22 https://wiki.documentfoundation.org/Design/Whiteboards/MenuIdeas

astron5 19:57:23 (as i started it) ill archive menuideas 19:57:38 mirek2 19:57:44 I already did

astron5 19:57:48 oh okay good 19:57:53 Maggie 19:58:43 So what about Progress Indicators and Menu Ideas? Oh wait, menu was archived never mind. 19:58:48 mirek2 19:58:53 ask Daud about the Styles and Formattin window

astron5 19:59:14 can we add that as a proposal to the new styles wb?

mirek2 19:59:32 if he doesn't respond within a reasonable amount of time (4 days, let's say), then you can work on it

eagles0513875 19:59:44 astron5: ok just trying to push forward with inclusion i have at least 2 other people interested in helping out with UI development

mirek2 20:00:00 @astron: which new styles wb?

astron5 20:00:17 didnt you start one?

mirek2 20:00:26 a while ago and I forgot to link it 20:00:36 you mean https://wiki.documentfoundation.org/Design/Whiteboards/Style_dropdown_split_button ? 20:01:25 astron5 20:02:01 yes. okay, i see it has a focus too narrow

mirek2 20:02:29 I'll change the focus and integrate the two 20:02:31 the whiteboard was only a thing I quickly whipped up as Michael was asking for GSoC suggestions 20:02:41 astron5 20:02:48 cool. right, gsoc ... there should be something definite on wednesday 8ie students accepted) 20:03:18 mirek2 20:03:33 any projects they want to work on ? 20:03:37 alexanderW 20:03:41 good

astron5 20:04:17 as far as i gathered, use your phone as a remote for impress is v popular

eagles0513875 20:05:04 astron5: would be interesting to have a google app or integrate something like that in the android port

astron5 20:05:05 well, thorsten told me.

eagles0513875 20:05:21 but one step at a time

mirek2 20:05:21 too bad, I'd prefer if they chose to target some of the more pressing problems any UI work needed on that? 20:05:21 astron5 20:05:47 likely. but cant say whos mentoring that, also, were too few people for too many projects here already 20:06:10 mirek2 20:06:22 back to the color handling and status bar then

astron5 20:06:26 yes.

mirek2 20:06:44 the idea workflow I proposed already takes 3 weeks... I guess we should work in parallel on projects and you said the proposal period was too short -- should I lengthen it to 2 weeks? 20:06:57 then a single idea would take almost a month to design 20:07:11 astron5 20:07:34 i guess having it closer to two months is more realistic seriously 20:07:39 mirek2 20:07:54 when does GSoC development start?

astron5 20:08:25 https://wiki.documentfoundation.org/Development/GSoc

alexanderW 20:08:50 May 21

mirek2 20:09:09 we have a week and a month, then to produce the ones needed for GSoC 20:09:20 astron5 20:10:00 and then some overlap with development time

mirek2 20:10:42 ok are the gsoc projects already picked? 20:11:15 astron5 20:11:21 no that happens after wednesday 20:11:33 alexanderW 20:11:42 I think they'll announce who's been chosen on the 26th

mirek2 20:11:50 ok

alexanderW 20:12:03 or the 18th?

astron5 20:12:37 (students pick projects, but in some cases multiple qualified students happen to pick the same one – thus the need to give some students different projects)

mirek2 20:12:58 and when will we know the projects they picked?

alexanderW 20:13:05 "Stay tuned as we will announce the accepted students for this year's Google Summer of Code on April 23rd at 19:00 UTC (Noon PST). Good luck students!"

astron5 20:13:17 thanks, alex

mirek2 20:14:24 alright how about this: we start working on color management now, as it's the most pressing problem, I think 20:14:24 astron5 20:14:32 ok.

mirek2 20:14:45 adopt the idea workflow @ https://wiki.documentfoundation.org/User:Mirek2 and just postopone by a week if there's been little or no activity

astron5 20:14:58 ok.

mirek2 20:15:40 So this week is the call for proposals, then?

astron5 20:15:50 + alex, maggie..? 20:16:35 Maggie 20:17:31 Are we focusing on proposals for GSoC or on the color management?

alexanderW 20:17:31 GsoC

mirek2 20:18:08 GSoC proposals, of which color management is a part

alexanderW 20:18:13 ah

mirek2 20:18:36 we might refocus once we know which proposals were picked for GSoC

alexanderW 20:18:36 Maybe color managment

astron5 20:18:51 so, clr mgmt for now only?

alexanderW 20:18:52 until we know what projects have been accepted

Maggie 20:19:05 Okay, that makes sense.

astron5 20:19:33 good

mirek2 20:20:03 alright

astron5 20:20:20 anything more we should discuss right now?

mirek2 20:20:33 so start working on your color management proposals, we'll go over them next week there's the HIG, but it's not a pressing matter 20:20:49 Maggie 20:21:15 and what issues should be addressed? Should the proposals be done using the new template? 20:21:18 mirek2 20:21:45 yes, with separate mockup and description sections under your section under proposals on https://wiki.documentfoundation.org/Design/Whiteboards/Color_Handling 20:22:23 astron5 20:22:28 right ok so, lets conclude, id say..? 20:23:21 Maggie 20:23:25 Alright got it. I'm assuming that the deadline for these proposals is april 21.

mirek2 20:23:38 yes

alexanderW 20:23:55 ok

astron5 20:23:56 ill post the log, unless anyone else absuletly wants to do this.

alexanderW 20:24:16 yep

mirek2 20:24:22 ok

astron5 20:24:50 okay, then, bye and thanks for the discussion.

Maggie 20:25:00 one last question: Will the best ideas from each proposal be picked?

alexanderW 20:25:21 We'll discuss the proposals and somehow merge the best ideas or choose the best overall design 20:25:35 Maggie 20:25:38 Okay. That's cool.

mirek2 20:25:57 right