Web   ·   Wiki   ·   Activities   ·   Blog   ·   Lists   ·   Chat   ·   Meeting   ·   Bugs   ·   Git   ·   Translate   ·   Archive   ·   People   ·   Donate

#sugar-meeting, 2010-01-23

 « Previous day | Index | Today     Channels | Search | Join

All times shown according to UTC.

Time Nick Message
10:36 christianmarcsch great, thanks erikos
10:36 is gerald here?
10:36 erikos #TOPIC 0.88 Design meeting (2)
10:37 gmanb5 This is Gerald
10:37 Good morning
10:37 christianmarcsch good morning, thanks for making it
10:37 erikos hey gmanb5 - thanks for joining!
10:37 christianmarcsch so, the test i sent out is only a draft, and we should feel free to iterate on it
10:37 it is intended to be conducted with a classroom
10:38 ca 5 minutes one on one per student
10:38 during which they will answer questions and demonstrate certain pathways
10:38 as specified in the questionnaire
10:39 walterbender christianmarcsch: gmanb5 may have some opinion, as he is a likely one to run the test
10:39 christianmarcsch half the students will get build A (the current build), the other half will get build B (the test build with the home view changes we discussed last week)
10:39 gmanb5 The test seems good and doable to me.
10:39 christianmarcsch walterbender: yes, that would be great
10:39 gmanb5 I preferred Pathway 2, as it seems to match how students seem to work
10:39 but either would work
10:39 erikos christianmarcsch: yeah, I think it is a great way to mix: show how you would sove a task, and answer a few questions
10:39 christianmarcsch let me go through my rationale, then we can all discuss
10:40 erikos christianmarcsch: that is what I did in my test, too
10:40 christianmarcsch yes, the idea is to cover a few different scenarios
10:40 so, we split the students between Build A and B,
10:40 and then we could alternate between Path 1, testing resuming an activity primarily, and Path 2, testing start new primarily
10:40 garycmartin christianmarcsch: question 2.4 "do you know why the symbols are different colours" will be a dud for half the group (using start new build)
10:41 christianmarcsch the main difference between the pathways is the order
10:41 garycmartin: actually, i think it's still relevant, since the journal will be color vs. the other symbols
10:41 but we can choose to only ask it for build A
10:42 anyway: does the structure make sense the way i just described it?
10:42 path 1 and 2 are both important to test, since they address a different order
10:42 it will be interesting to see how they effect the results of each build
10:43 also, i thought it would be more interesting to test on an experienced "user"
10:43 not first-time
10:43 so we can really probe their understanding of the UI
10:43 erikos christianmarcsch: what I am a bit unsure about is how one presents those task to a kid that has been using either start-new or resume before
10:44 garycmartin christianmarcsch: will the users be told they are (possibly) using different software?
10:44 christianmarcsch erikos: well, my thought is that we would simply observe them performing the tasks, and have them narrate what they are doing
10:44 erikos christianmarcsch: do you tell them that the sugar they use for this task has not changed?
10:44 christianmarcsch: has changed, I meant
10:44 christianmarcsch through the observation we can gain insights on how well they have understood the interaction
10:44 eben christianmarcsch: I think this can work, but I agree there's a small bias toward the "familiar"
10:45 christianmarcsch garycmartin: i think we should tell them in the case of Build B, yes
10:45 eben: i was trying to make it unbiased by changing the order of the two pathways
10:45 erikos heh garycmartin had the same question ;p
10:45 christianmarcsch it should be unbiased--whatever we can do to make it so we should
10:45 garycmartin christianmarcsch: will the tests be conducted one at a time. I'd imagine it would be hard in a class full of kids perhaps copying each other.
10:46 christianmarcsch garycmartin: that is where i could use some help, not having interacted with children in a classroom setting
10:46 there is the test, but also how we facilitate it
10:46 i think one-on-one's would be best, since we need to closely observe how each participant is using the system
10:46 erikos christianmarcsch: from my experience one-on-one is best
10:46 eben christianmarcsch: Perhaps we should try both builds on each student, but switch which build is shown first?
10:47 christianmarcsch erikos: sounds good. i don't think this would work as well in a group
10:47 eben: we could perhaps, but i thought we would alternate one build per student
10:47 eben: to not confuse too much
10:48 m_stone gentlefolks: apologies for missing the start of your meeting: I had the great       fortune last night both to catch a cold and to slice my finger on a metal bookshelf.
10:48 christianmarcsch eben: i think we are mostly trying to measure an intuitive understanding,
10:48 m_stone consequently, I'm neither thinking nor typing as fast as usual.
10:48 garycmartin eben: using both builds could take some time to carry out, lot's of questions...
10:48 christianmarcsch hi m_stone
10:48 silbe christianmarcsch: would the students get time to experience the new build?
10:48 christianmarcsch silbe: half the students, yes
10:48 but we should talk about it
10:49 m_stone christianmarcsch: I some comments on your protocol which I'd like to share. the     first two are minor but the third is more serious.
10:49 silbe m_stone: Welcome, and bless you (hope that's the right phrase)!
10:49 m_stone silbe: close enough. :)
10:49 christianmarcsch if you think giving each student both builds would help, we should explore that
10:49 m_stone: sure, go ahead
10:49 m_stone first, I like the questions that you're asking about each build and I think they'll give interesting data.
10:49 so good work on that.
10:49 however, I have some methodological concerns.
10:49 christianmarcsch that's why were having this discussion!
10:50 m_stone :)
10:50 perhaps you've already covered this and, if so, I apologize...
10:50 first, why do think that 5 minutes is the right expected duration?
10:50 christianmarcsch that's just what i was aiming for in the interest of being able to conduct the test with an entire classroom of students
10:50 not sure if it is realistic
10:50 but i'd hope for at least that much time
10:50 m_stone christianmarcsch: it seems highly unrealistic to me.
10:51 christianmarcsch m_stone: too long?
10:51 m_stone no; significantly too short.
10:51 christianmarcsch well, there is also the feasibility of conducting the test at all
10:51 but what are you thinking?
10:51 m_stone (I'm also including the time required to explain the experiment in the time budget though, which maybe you weren't.)
10:52 christianmarcsch m_stone: i imagine one could explain it in advance of the one-on-one sessions
10:52 m_stone christianmarcsch: consider me to be suggesting, then, that you add preparation time to an overall time budget for the proposal.
10:52 christianmarcsch the 5 minutes came from trying to scope it so we could actually (hopefully) carry it out
10:52 m_stone christianmarcsch: I understand.
10:52 christianmarcsch m_stone: ok, that's a good idea
10:52 m_stone my next question will shed more light on the issue.
10:52 second, how do you propose to physically record the responses?
10:53 christianmarcsch i was going to prepare a template that one could fill in by hand
10:53 m_stone "worksheet", then.
10:53 "written questionnaire"
10:53 erikos christianmarcsch: that should work fine, +1
10:53 christianmarcsch m_stone: right
10:54 m_stone christianmarcsch: so your goal is to enable the testing to happen in parallel?
10:54 christianmarcsch there may be issues with recording sound, i'm guessing
10:54 m_stone: yes. ideally there might be two people conducting each test
10:54 erikos christianmarcsch: an important part is that the proband feels in a safe environment
10:55 christianmarcsch erikos: i see. actually, from your experience, what would work best?
10:55 erikos christianmarcsch: that is why recording is not my first choice
10:55 christianmarcsch erikos: oh ok
10:55 erikos christianmarcsch: I think having a sheet of paper is fine
10:55 m_stone christianmarcsch: okay. I think it's likely that, with a written worksheet in parallel testing, you're going to have people who get confused mid-way through.
10:55 christianmarcsch m_stone: are you concerned about interviewing a student and taking notes at the same time?
10:56 m_stone: i was thinking that the interviewer would fill out the worksheet, not the student
10:56 erikos christianmarcsch: the design people of the company Iam working in at the moment, do the same thing
10:56 christianmarcsch m_stone: it should encapsulate a summary of our observations
10:56 m_stone christianmarcsch: ah. so that's more of a serial test than a parallel test.
10:56 erikos christianmarcsch: works quite well (and a similar test with tasks and awnsers
10:56 )
10:56 christianmarcsch erikos: yes, i learned this method from ideo... ;)
10:56 m_stone you can only record as many streams of data as you have data-recording-people.
10:56 erikos christianmarcsch: ;p
10:57 m_stone okay. that sounds more consistent than what I'd understood before.
10:57 one more question.
10:57 christianmarcsch m_stone: sounds good.
10:57 m_stone my third question is about the underlying data that you're trying to collect.
10:58 basically, you seem to me to be asking "is default-resume or default-start-new better?"
10:58 christianmarcsch m_stone: well not quite. the test is attempting to understand the cognitive model of the Home view, and how students go about performing basic tasks (resuming/starting new)
10:58 m_stone where "better" means something like "how well do kids' understandings of the screens and their affordances agree with my understanding"
10:58 and with "how many roadblocks do we see?"
10:58 christianmarcsch: one moment, please. :)
10:59 christianmarcsch go ahead
10:59 m_stone I think that the question, as I stated it, accurately reflects the kind of data you're going to get out of this work.
10:59 my concern is that I think that the underlying question we're trying to answer is: "what affordances should be on the home home screen?"
11:00 want more explanation?
11:00 christianmarcsch m_stone: no, let me respond what i think
11:00 silbe m_stone: yes, please.
11:00 christianmarcsch silbe: oh, sorry
11:00 m_stone christianmarcsch: let me try to clarify for silbe, then I will eagerly await your response.
11:01 silbe christianmarcsch: sorry to interrupt, but's it's important to me that I understand the difference as well as possible
11:01 christianmarcsch silbe: definitely
11:02 m_stone the difference has to do with the selection of experimental treatments.
11:03 as I said before, I think that the actual responses christianmarcsch wants to elicit are well chosen.
11:03 the problem is that asking the questions he proposes to ask *only about default-resume vs. default-start-new* isn't going to tell us what affordances should actually be on the home screen
11:03 we really need to know more.
11:04 we need to know "well, is both better than one or the other? is it the same? is it worse?"
11:04 this idea has been suggested by multiple people like walter, eben, and myself.
11:04 christianmarcsch m_stone: the thinking is correct, but we can only do so much in a test like this
11:04 m_stone however, it has also been criticized, e.g. by garycmartin as being overly complex.
11:05 christianmarcsch: let's start with what we *want* to know, then let's think about how much it costs to collect.
11:05 silbe m_stone: which idea, exactly?
11:05 garycmartin puts his tinfoil hat on and humms ;-)
11:05 tomeu I guess we will do more tests if the first one runs well?
11:05 christianmarcsch m_stone: I actually don't think we're at the point yet where can get specific data on the affordances of the home screen.
11:05 m_stone christianmarcsch: for example, we might get more help collecting the data if people thought that the data we collected would be more valuable
11:05 eben I'd also like to get more information about the childrens' understandings of the Journal and it's purpose, as well.
11:05 christianmarcsch tomeu: yes, that's what i think
11:06 eben: that's a good idea, but i only caution to not make the test too complex
11:06 The goal of this test is primarily to observe out how children perform the tasks of starting new/resuming activities
11:06 silbe eben: I guess we all want that :)
11:06 eben It may just be one additional cognitive model question.
11:06 christianmarcsch eben: that sounds good
11:07 m_stone let's slow down a little bit; we're accumulating discussion items on the stack.
11:07 silbe: do you feel you understand fully now?
11:07 erikos I think this test is more than a great start, we move forward and not just for the sake of it
11:07 christianmarcsch m_stone: so, i don't think we can expect students to tell us what affordances need to be in Home view
11:08 m_stone christianmarcsch: of course not.
11:08 christianmarcsch m_stone: i think we need to try to get to that point by asking questions about their current behavior patterns
11:08 m_stone: by making Build B part of the test, we can then begin to compare the two versions
11:08 m_stone christianmarcsch: I'm actually suggesting that we use the excellent questions you developed with a more powerful matrix of treatments.
11:08 silbe m_stone: I guess I understand it enough for now - will try to ask additional questions as they arise
11:09 christianmarcsch m_stone: definitely open to that!
11:09 m_stone (here "treatment" basically means "the choice of build to show to the kid")
11:09 garycmartin m_stone: so you'd like a Build C where both resume and new icons are displayed?
11:10 m_stone garycmartin: yes.
11:10 christianmarcsch interesting idea
11:10 silbe is starting to see
11:10 christianmarcsch i have reservations on that build, since i think the duplication of icons will cause confusion
11:10 m_stone christianmarcsch: I know. so does garycmartin.
11:10 christianmarcsch so i'm personally not sure it warrants testing
11:11 but i'm open to it if everyone thinks it would be valuable
11:11 erikos christianmarcsch: I think once you identify so much issues already when looking at it, there is not much point in testing it
11:11 christianmarcsch part of me thinks that we should stick to a single build, the current one, since that is what students are familiar with
11:11 m_stone christianmarcsch: here's my real position:
11:11 christianmarcsch but having the comparison with what we discussed last week seems like it may yield interesting comparative data
11:12 m_stone 1) we should list people's ideas for what the home view should be like without worrying too much about our personal reservations.
11:12 erikos ok, we want something for 0.88 - or at least try to move forward, making the test
11:12 m_stone 2) if the number is fairly small, we should try to make a build for each one. it might be hard for some, so we might have to put those off.
11:13 however, this is a simple enough change that we can probably build most of them without undue duress.
11:13 3) then we should try them out internally.
11:13 christianmarcsch m_stone: on 1--agree in general, though we need to use our judgment to downselect the options to make the test feasible
11:13 m_stone this will give the people who have personal reservations about a design the opportunity to document their concerns.
11:13 after that, we should basically vote (maybe even with selectricity) on which designs to bring forward into user testing.
11:14 we might do that with a specific budget of kid-testing resourcs: i.e. "we can run Christian's protocol with 2, or with 3 builds"
11:14 christianmarcsch m_stone: if you ask me, we are already past that point--we are bascially looking at two options, though a third one may evolve based on the feedback
11:14 m_stone alternately, we might find that individual deployers want to run a single small general test and to contribute some additional results of their own with their favorite approach.
11:14 christianmarcsch m_stone: though in principle you are right
11:15 silbe m_stone: sounds good to me; especially part 3 since we're doing the test only on a) very few probands b) with pre-experience, i.e. potential preference for "current" behaviour
11:15 m_stone: not sure on doing the voting, though
11:15 m_stone christianmarcsch, erikos: would it help to here more about why I think this is a better way to do things?
11:16 silbe: if the results from the internal testing were sufficiently clear, then I agree that we could drop the voting.
11:16 yevlempy Sorry for being late
11:16 m_stone silbe: alternately, someone else might come forward with a better idea on how to select the designs to go forward into user testing.
11:16 erikos m_stone: well, I think you are trying to make it too complicated
11:16 silbe m_stone: ah, wait, the voting was before the test - that should be fine
11:17 erikos m_stone: a) we just started to get the design team going again
11:17 m_stone erikos: I feel that I'm trying to make it as simple as possible but no simpler.
11:17 erikos m_stone: no
11:17 m_stone: who is going to do the testing?
11:17 m_stone: who implements all those possibilities
11:17 garycmartin m_stone: how about paper mockups / questionsheet? Kind'a what happens when you click here.
11:17 m_stone erikos: I believe that rgs and gerald ardito are on board for doing the testing. I hoped that you would contribute there too.
11:18 erikos m_stone: we can do such complex things once we are on a solid ground to act on
11:18 m_stone: I never said I would not
11:18 christianmarcsch m_stone: i think it would be best if we kept the options tightly focused. build a and b would allow us to test two contrasting "perspectives" (starting new vs. resume),which should give us valuable data to think about which of the two seems more intuitive, or whether a third option should be considered
11:18 m_stone again; I apologize that I can only respond to one person at a time.
11:18 erikos m_stone: but I want things to happen at some point
11:18 m_stone who should I respond to: erikos, garycmartin, or christianmarcsch?
11:19 silbe m_stone: I think a practical problem is that we re-started the design team meetings way too late, so we need to take whatever resources we can get within the next days and decide what to do for 0.88. I.e. we need to decide in a kind of rush, which is always bad.
11:19 eben christianmarcsch: I agree that we want to keep it simple, though I do want to point out that I don't think it's a "start" vs. "resume" argument.
11:19 erikos hey yevlempy - we still have time ;p
11:19 m_stone silbe: I think doing this right is much more important than doing a rush job to hit an arbitrary deadline.
11:19 erikos silbe: well, the issue has been on th etable for longer already
11:19 silbe m_stone: I definitely agree.
11:20 erikos silbe: I agree that we should not rush through things
11:20 m_stone really, 0.88 has plenty of other stuff into it.
11:20 christianmarcsch eben: i agree that we want to ultimately enable both. but the test is not about giving us solutions, more about understanding behaviors
11:20 erikos silbe: but we should do things based on our ressources as well
11:20 silbe erikos: it has been, but we never did anything about it.
11:20 where "we" includes me
11:20 m_stone much better to take our time, to agree to work very systematically on a nice list of bite-size bugs
11:21 eben christianmarcsch: yup. coming back to my previous point, I think the behaviors we need to understand include use (or disuse) of the Journal, not just the Home screen.
11:21 m_stone and to work very happily and cooperatively because everyone feels that their favorite idea will receive due consideration and will be treated fairly.
11:22 eben: I agree with you and I'd like to apply the same testing methodology to the journal/home view affordances but I want to get a proof-of-concept of the *method* for doing this first
11:22 christianmarcsch eben: yes, let's make the journal a part of the test then without going too deep into a journal scenario
11:22 eben: i was actually imagining that we might see some kids using the journal to resume
11:22 eben: when we probe on how they would resume an activity
11:22 m_stone christianmarcsch: good point.
11:22 christianmarcsch, eben: maybe we could compromise by asking a question about the journal but by not including it in the experimental treatments?
11:23 in this particular round of testing.
11:23 christianmarcsch m_stone: that is fine, i think. i was trying to be very general about the tasks (resume vs. start new) so that we would see how kids currently accomplish them (home view, journal, etc.)
11:24 eben m_stone: Yes, I agree that's fine. I think all I'm saying is that I'd like perspective on how/when kids use it. Perhaps that will come out without asking anyway.
11:24 m_stone erikos: I'll return to the discussion of feasibility and scheduling as soon as I make sure that eben is okay with this idea.
11:24 christianmarcsch eben: my thinking was that it would come out
11:24 m_stone eben: well, perhaps christian's questionnaire can be tweaked to focus on eliciting that information.
11:25 why don't the two of you talk later this week and see if you can propose an edit to that effect.
11:25 christianmarcsch m_stone: and yes, we should definitely tweak the questionnaire!
11:25 m_stone ?
11:25 christianmarcsch sounds fine.
11:25 m_stone shall we return to the resources and scheduling discussion?
11:25 eben Sure.
11:26 m_stone erikos: you sounded like you had several concerns that you wanted to raise here, both about the task of making the builds and about the task of collecting the data.
11:26 would you mind going over those concerns in more detail?
11:26 erikos m_stone: no there are no details to make
11:27 let's see if we can make a small vote how we go forward
11:27 we have a few other points we wanted to discuss today
11:27 tomeu erikos++
11:28 m_stone ah. I would rather understand your concerns before voting, but I don't really want to obstruct progress.
11:28 silbe let's take our time to get this right
11:28 erikos christianmarcsch: proposed a test - who is with small modifications (journal case) ok with doing this test?
11:28 tomeu silbe: I think we should go with "right enough"
11:29 m_stone tomeu: what's the rush?
11:29 tomeu m_stone: this is a scheduled meeting, people have other appointments
11:30 silbe tomeu: we'll need more iterations to get the design "right", so "right enough" is a good answer for the final decision - but no reason to rush the process.
11:30 christianmarcsch i also want gmanb5 to speak up--he has some thoughts on facilitating the test
11:30 tomeu m_stone: if in a meeting we cannot fully agree on something, we need to defer the discussion to offline channels
11:30 silbe tomeu: which parts don't we agree on, exactly?
11:30 tomeu silbe: as I said, there's a practical limit on the time that people can devote to discuss things
11:31 erikos actually, I don't see the big issue with the change we last weel discussed
11:31 silbe tomeu: but that's a soft limit, not a hard one. Just aborting the discussion won't do any good. Let's finish it up properly.
11:31 tomeu silbe: I don't understand it
11:32 I won't be able to keep discussing it if I have to leave to do something else
11:32 walterbender we are also not going to get everything right in the first go... we will need to iterate in our test design for certain... so while it is great to get the various concerns we know of in advance on the table, we should not feel obliged to address everything before taking any action.
11:32 erikos let's do a test, that matches our ressources and move on (if the test does not work out well, fine we have to do another iteration)
11:32 walterbender: thanks!
11:32 m_stone erikos: let's not waste testing resources on a test that doesn't speak to the question we're actually trying to answer.
11:32 gmanb5 christianmarcsch: may I make a suggestion?
11:32 christianmarcsch gmanb5: yes please!
11:32 erikos m_stone: that is your opinion, I do not share that one
11:33 gmanb5 I would suggest doing the test that you have proposed as a set of focus groups
11:33 with, say, 6 students at a time
11:33 the facilitator could collect their responses and add some observational data as well
11:34 this would work for the kids I have been working with at least
11:34 tomeu sounds great
11:34 gmanb5 and would mimic how they actually use the XOs/Sugar, which is in a social way
11:34 christianmarcsch gmanb5: that sounds like it could work well
11:34 silbe gmanb5: interesting point
11:34 christianmarcsch gmanb5: we may need to modify the protocol slightly, but i like that we could test the UI in a social context
11:35 gmanb5 And, to Walter's point
11:35 we can then do the testing iteratively, even with the same students
11:36 christianmarcsch gmanb5: sounds great. how soon do you think we would be able to set up a couple of focus group sessions?
11:36 erikos I like those additions from gmanb5
11:36 gmanb5 If you get me the builds we want to test
11:36 I could do them this week
11:36 and share results day by day, if that would work
11:37 erikos gmanb5: :)
11:37 christianmarcsch gmanb5: that would be excellent. i'm not sure where we are on Build B...
11:37 erikos: is build B ready?
11:37 erikos christianmarcsch: I am sure we can hack that up quite quickly
11:38 tomeu notes that it's 1 hour since the start of the meeting and yevlempy is here to discuss the fonts control panel
11:38 christianmarcsch great--why don't erikos, gmanb5 and i talk offline about facilitating a first round of tests next week
11:38 erikos christianmarcsch: for me this would be a good way to move forward
11:38 gmanb5 works for me
11:38 erikos me too
11:38 tomeu erikos: you plan to do the test this week in berlin?
11:38 erikos next one
11:39 christianmarcsch i'll send out a note to the group with a finalized test protocol--if anyone wants to contribute any more suggestions, please forward them to me!
11:39 erikos tomeu: I have to check the avilability of the kids
11:39 tomeu: but would be great (wednesday is my class)
11:39 christianmarcsch erikos: that's perfect--it would also give us the opportunity to make some adjustments
11:39 erikos christianmarcsch: awesome!
11:39 tomeu great
11:40 erikos Font configuration
11:40 christianmarcsch thanks everyone--moving on!
11:40 erikos http://wiki.sugarlabs.org/go/D[…]ont_configuration
11:40 this feature is about adjusting the Font size of the sugar desktop from within an option in the control panel section
11:41 there has been a proposal of two buttons (+-)
11:41 or a slider
11:41 and to show an example font below the buttons to give direct feedback
11:42 yevlempy: (we are at your topic at the moment)
11:42 any other solutions I have missed?
11:42 (btw: to keep it simple we only want to adjust the size, not the font type)
11:42 yevlempy erikos: yeah
11:43 garycmartin erikos: there was also a question of the font type needed to be altered (for some language scripts)
11:43 erikos garycmartin: ohh thanks
11:43 garycmartin: yeah, sayamindu said so because of arabic languages
11:43 yevlempy erikos: but although changing the fonts also would have been  good idea
11:44 erikos: but as per the mockups the first one had got a good feedback
11:44 garycmartin perhaps font selection should be limited to just a few hard coded choices, a huge pop-up of every installed font would seem to be a poor solution.
11:45 yevlempy The drag one
11:45 christianmarcsch where can i find the mockups?
11:45 erikos garycmartin: ahh, that might be a good option
11:45 eben I'm +1 for a slider with dynamic preview; slider could have labels for "small", "default", and "large"
11:45 yevlempy erikos: can you please point christianmarcsch to mockups because i have a damn bad internet here :(
11:46 eben garycmartin++
11:46 christianmarcsch slider + dynamic preview sounds like a good option
11:46 tomeu wonders if displaying the actual font size wouldn't be useful for users to communicate their preference
11:47 yevlempy eben: and i will also replace the numbers with an arrow to point the default size
11:47 erikos yevlempy: yup
11:47 garycmartin tomeu: perhaps the font name and size could be used in the preview?
11:47 tomeu sounds good, I think I have seen that somewhere
11:47 yevlempy garycmartin: that is a good idea
11:48 erikos christianmarcsch: http://img693.imageshack.us/im[…]garfontpanel1.png
11:48 christianmarcsch thanks erikos
11:48 the slider looks good, and adding eben's dynamic preview would make it more informative
11:48 erikos yes
11:48 yevlempy was thinking like wise there is font configration in gnome, we can do same way in sugar
11:49 erikos dsd_: can you outline why you think we should only have one font type?
11:49 yevlempy christianmarcsch: i could not get the dynamic view thing
11:49 christianmarcsch yevlempy: you mean technically?
11:50 erikos dsd_: (I know that sayamindu said that it might be helpful to have diferent fonts because of arabic fonts etc)
11:50 yevlempy christianmarcsch: no the design
11:50 christianmarcsch yevlempy: oh ok. we could generate a mockup if it would help then
11:50 yevlempy christianmarcsch: thanks
11:50 christianmarcsch no problem
11:51 erikos ok, I think we have nailed that pretty much down
11:51 just if we have an option for different font types is not clear to me yet
11:51 dsd_ erikos: i'd argue why it is necessary to have others
11:51 erikos: we have always had 1 until now
11:52 christianmarcsch erikos: i'd say no different font types
11:52 dsd_ erikos: and even for arabic deployments it is not necessary to customise it
11:52 erikos dsd_: you mean they could set one by default?
11:52 dsd_ yes, the characters dont exist in the font that we ship on XO and in soas, but some part of the system is clever enough to pull in the arabic characters from other fonts
11:52 *in the default font
11:53 eben could we set the default font intelligently based on the language preference instead?
11:53 yevlempy dsd_: But i dont get, why different fonts idea will not be good ?
11:53 dsd_ there is no need to do so
11:53 or at least there has not been until this point - has somethign changed?
11:53 eben It seems like setting them independently is more control than necessary.
11:54 erikos dsd_: not for me - none of my kids has asked me to ;p
11:54 dsd_ if you put an XO in amharic mode, it uses amharic characters even though they dont exist in the systemwide default for "Sans" (which is DejaVu)
11:54 for this reason, i discard the argument that font selection is necessary for language reasons
11:54 erikos dsd_: thanks for the technical clarification
11:55 yevlempy ok
11:55 dsd_ as for giving the user a choice of font face and displaying the size, i simply think its not necessary and that sugar should focus on simplicity
11:56 my feature proposal is based on experience in the field, and i've never seen these things as desirable
11:56 erikos dsd_: sounds very reasonable to me
11:56 dsd_ it could of course be added later, it is just a UI detali
11:56 *detail
11:56 but i dont think we have a use case at this time
11:56 tomeu dsd_++
11:56 yevlempy dsd_: yes
11:57 erikos this was dsd_ live with feedback from the field! :)
11:57 ok, who will do the mockup?
11:57 eben I can take a stab at it.
11:57 erikos wants to set an action item ;p
11:57 eben: thanks!
11:57 next one
11:58 thumbs view we discussed already last week - so we can skip that one
11:58 Enhanced Color Selector
11:58 http://wiki.sugarlabs.org/go/F[…]ed_color_selector
11:59 walterbender: any open questions about that one?
12:00 tomeu needs to go :(
12:00 m_stone tomeu: good bye.
12:00 erikos tomeu: enjoy your evening
12:00 tomeu cheers all
12:00 christianmarcsch bye tomeu--thanks!
12:00 garycmartin erikos: I'm worried it's  a little confusing
12:00 eben bye, tomeu!
12:00 garycmartin waves to tomeu
12:00 erikos garycmartin: ok
12:01 christianmarcsch for the color selector, i wonder if one might just show a grid of all color combinations?
12:01 erikos looks if we have a last design somewhere
12:01 garycmartin erikos: it mixes random selection, a limited 1D refinement, and a hidden undo.
12:01 erikos http://wiki.sugarlabs.org/go/F[…]tor#Release_Notes
12:02 garycmartin: I thought for example that the undo would go away
12:02 garycmartin: but ok
12:02 garycmartin: and random selction, too
12:02 hmm walterbender ?
12:02 walterbender garycmartin: (a) the undo is gone
12:02 erikos ahh nice ;p
12:02 garycmartin erikos: the current solution is lovely and simple, but suffers from frustration if you click past a colour you liked. Just adding a history (undo) woluld resolve that main case.
12:03 walterbender garycmartin: (b) we could remove random as well
12:03 garycmartin: I disagree. Kids get close and then want to explore
12:03 garycmartin walterbender: remove random and use 2D navigation?
12:03 walterbender garycmartin: I think we should do the following:
12:04 garycmartin (not just left right but up and down?)
12:04 walterbender 1. assign a random color on init
12:04 silbe tomeu: cu
12:04 walterbender 2. in the cp, let kids move through the list using forward and backward arrows.
12:04 christianmarcsch the design looks clear to me--adding up and down might make it feel more exploratory
12:05 walterbender garycmartin: so we'd eliminate the selector in init.
12:05 and we'd eliminate random in the cp
12:05 christianmarcsch instead of the arrows, it might be enough just to click on the smaller XOs to make a selection?
12:05 eben Isn't choosing your colors an integral part of starting with Sugar?
12:05 walterbender garycmartin: in the end, we'd have more functionality than today and simpler controls
12:05 eben: getting a color is essential, not selecting a color necessarily
12:06 but eben, we could add the navigation at init as well, after a random color is assigned... sure
12:06 but random is not ever a user control
12:06 eben walterbender: sure, yup
12:06 garycmartin eben: +1 it's all about making it your own.
12:07 eben Well, I admit I kind of like the idea of 2-axis. fill left/right, stroke up/down
12:07 walterbender if someone can show me how to pack the icons properly, it would be easy enough to try
12:07 christianmarcsch eben: +1
12:07 eben we could drop the arrows as christianmarcsch suggested, and just show the next/previous fill/stroke XOs colors on all 4 sides of the large one.
12:08 garycmartin eben: +1
12:08 walterbender again, piece of cake if I can figure out the packing in hippo canvas :(
12:08 erikos walterbender: ok, we can have a look
12:09 eben walterbender: Indeed. :)
12:09 walterbender erikos: I will modify xocolor to provide the proper methods for the navigation.
12:09 erikos: that is Step 1.
12:11 erikos ok, so people are happy with having the 'configuration cross' ?
12:11 christianmarcsch erikos: yes, sounds great
12:11 erikos christianmarcsch: that would somehow go into a direction of a grid in some way
12:12 christianmarcsch yes, and i like the exploratory aspects
12:12 erikos christianmarcsch: just represented differently
12:12 walterbender maybe an X (nav in the opposite corners) instead up-down/left-right
12:13 :x:
12:13 eben I think that would make the opposites harder to identify.
12:13 walterbender it would be more compact
12:14 top row could be fill, bottom row stroke;
12:14 garycmartin walterbender: if you don't like the + how about 8 mini icons, NE, NW, SE, SW as well. A tidy box with no religious overtones?
12:14 christianmarcsch i prefer the plus-arrangement
12:15 it seems clearer
12:15 erikos yeah, the plus looks good to me, too
12:15 eben christianmarcsch: agreed
12:15 erikos just need to call it plus instead of a cross ;p
12:15 walterbender christianmarcsch: I think it is arb. is fill horz. and stroke vert?
12:16 garycmartin erikos: ;-)
12:16 eben I think the orthogonality concept can be understood intuitively that way...even though they've never heard the term. :)
12:16 christianmarcsch walterbender: sure, that seems fine. it may be arbitrary, but easy to discover by interacting with it
12:18 walterbender OK. I'll start coding... maybe we should move to the next topic?
12:18 erikos if there are no objections and people are happy with the 'plus'
12:18 garycmartin +1
12:19 erikos ok
12:19 so the next are two items i am not sure we are able to do them for 0.88
12:19 tags in Journal, multiple selection in Journal
12:20 eben I think tags is likely out of scope
12:20 multiple selection seems potentially feasible, but could still be a lot of work.
12:20 erikos eben: yes
12:21 eben: and officially it has not been proposed as a feature
12:21 eben: (multipl I mean)
12:21 eben: but as it has been regrested many times from the field
12:21 eben For multiple selection, we have designs for both list and grid view already, assuming everyone agrees that checkboxes are a good solution. Otherwise there will be a design phase needed.
12:21 erikos could be slipped in
12:21 garycmartin erikos: is there agreement over 'check boxes' verses regular shift/ctrl selection?
12:21 erikos garycmartin: I don't think so
12:22 garycmartin: we could discuss it now, I guess
12:22 do people still have the ten minutes to discuss this?
12:22 alsroot: ping
12:22 eben We could knock of the drag icon first, maybe. That might be fast
12:22 alsroot erikos: yup
12:22 christianmarcsch sorry, i'm going to have to leave
12:23 erikos alsroot: http://wiki.sugarlabs.org/go/D[…]Meeting#Drag_icon you added that question, right?
12:23 eben I have to go in about 8 minutes, too.
12:23 erikos eben: yup
12:23 christianmarcsch erikos, let's talk later offline about the test for next week
12:23 erikos christianmarcsch: absolutely
12:23 alsroot erikos: yeah, would be good
12:23 christianmarcsch thanks--talk to you again soon!
12:23 erikos eben: ok lets use the last 8 minutes for the icon then
12:23 christianmarcsch: thanks!!!
12:24 christianmarcsch bye
12:24 eben I think the designs generally call for the "object" to be the icon. (See all the drag examples in the Frame design sequence: http://wiki.sugarlabs.org/go/D[…]/Designs/Frame#15)
12:26 So the XO, the activity, the clipping, the device, etc....those should be the icon dragged, as though it were a physical object. When appropriate, the cursor is meant to change to a plus for valid drop targets, and an N/A symbol for invalid ones.
12:27 erikos alsroot: and in your mockup, you drag all of the row, right?
12:27 alsroot erikos: thats not mockup but current code
12:27 erikos alsroot: ok ;p
12:27 alsroot ..0.86 I mean
12:27 erikos yup
12:28 alsroot: is what eben describes technically hard to do?
12:28 garycmartin erikos: yea current code drags a huge strip (i.e in the Journal) where you can't then see where you are going.
12:28 erikos alsroot: possible at all? any insights?
12:28 alsroot I like  eben's mockup, and going to implement it
12:28 eben I thought we had this working before, actually. I remember working on it at one point. :-/ Maybe it only works in some isntances.
12:28 alsroot at least not in 0.84+
12:28 erikos alsroot: nice ;p
12:28 garycmartin +1 for dragging icons
12:29 erikos eben: I can't remember how it was in the past actually :/
12:29 eben alsroot: This is also important since each row can have more than one object in it....for instance, in the Journal, you have both activities and people in each row.
12:29 erikos eben: we might have broken it too at some point
12:29 garycmartin erikos: I think it was just the icon, I think we lost that with the change of view types.
12:29 erikos garycmartin: ahh, ok
12:30 so we are clear on that one, too it looks like
12:30 and aleksey will be our coding hero!
12:30 garycmartin :-)
12:30 alsroot thinks we need review hero as well
12:31 erikos alsroot: :D
12:31 eben Thanks alsroot!
12:31 erikos shall we call it a meeting then for today?
12:31 we advanced on many topics, i think
12:31 eben Sounds good. We just hit the 2 hour mark.
12:31 garycmartin erikos: do we plan to have another next week?
12:31 erikos and we will try to make it shorter in the future
12:32 garycmartin: I would be ok with it
12:32 eben: are you available next week?
12:32 garycmartin: and you?
12:32 garycmartin erikos: me too, perhaps see what's left on the design list later in the week.
12:32 erikos garycmartin: yup, and maybe follow up on possible test results
12:32 eben Let me make sure...
12:33 Yeah, I can make it next week.
12:34 erikos ok, cool - i will send out notes so people are informed and have their action items ;p
12:34 garycmartin eben: BTW like you gsm device icon, will try to post a mockup with the USB + ))) type signal and see what it's like.
12:34 erikos thanks everyone!
12:34 eben garycmartin: sounds good
12:34 erikos eben: oh, yeah - i liked it, too
12:34 eben bye everyone!
12:34 garycmartin thanks folks!
12:34 erikos #endmeeting

 « Previous day | Index | Today     Channels | Search | Join

Powered by ilbot/Modified.