| 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 |
![http://img693.imageshack.us/im[…]garfontpanel1.png](http://img693.imageshack.us/img693/8779/sugarfontpanel1.png){kind=link}