For us noobs in patching, could someone make a screencast of Sugar running with this patch?
Eduardo 2009/10/16 Eben Eliason <e...@laptop.org>: > I wanted to include Christian on this thread since he may also wish to > try it out and have some valuable feedback. > > It seems like this thread is somewhat split between design discussions > and process issues. Should it be exclusive to the sugar-devel list? If > we want feedback from people other than developers it seems we should > have a broader scope. > > Eben > > > On Thu, Oct 15, 2009 at 11:19 PM, Eben Eliason <e...@laptop.org> wrote: >> On Thu, Oct 15, 2009 at 10:09 PM, Avi <fiendi...@gmail.com> wrote: >>> Tomeu wrote: >>> >>>> I'm more concerned about developers proposing big user experience >>>> changes because they feel it's better. Before I look at the patch I >>>> would like to know if there's agreement from people close to our users >>>> that this behavior change is desired. How can we get that? >>> >>> How about users (me) proposing big user experience changes by asking a >>> developer (Michael) "why the fuck does this UI take so goddamned long to >>> react?" Also, define "our users". Is it people using Sugar? Is it people >>> using XOs? Is it people other than you? I'll gladly put myself into any of >>> these categories if it makes you happy. >> >> I think we'd all agree that the primary audience for Sugar is children >> of varied age groups and levels of education, and that audience should >> be considered first in terms of the user experience. I'm not >> suggesting, of course, that the rest of us aren't also users with >> valid input and experiences, or that this proposed patch was submitted >> without the best interests of that audience, or at least a reasonable >> portion of that audience, in mind. >> >> I also don't believe that Tomeu was stating a challenge of any kind, >> or insinuating that no one other than Michael was likely to have a >> positive response to the proposed change. The suggestion was that we >> collect feedback from many people, yourself included, and also from >> children in our primary audience and the teachers and instructors who >> work with them daily. In that regard, thank you for your feedback; it >> would be more constructive, of course, if you could provide it without >> the profanity and apparent disgust. >> >>> Eben wrote: >>> >>>> The initial design intent was to develop a system which worked in a >>>> sufficiently complete manner without needing palettes at all. >>> >>> 1) For whom? What about people who know how to recognize English letters and >>> words better than they remember what an obscure picture means? Because >>> you've failed on that front. >> >> For children! And actually, I agree with you. In many cases text is >> minimized more than I would like it to be. Clearly it's beneficial for >> those learning to read to see associations of words and icons, and >> words are naturally useful to those who already can. >> >>> 2) Good luck. Sincerely. I hope that if that's still your goal that it's >>> actually possible. I'm personally not convinced, but only because I haven't >>> yet seen a demonstration that shows progress on that front. >> >> Honestly, I think we've come relatively close. Would you strongly >> disagree? It's possible to create new activities, resume past >> activities, join collaborative activities, connect to networks, >> participate in activities, copy, paste, and stop activities with the >> use of primary actions only. I'm not suggesting that the full power of >> the UI is available without the need for seeing any text, but I am >> suggesting that there are a great many things you can do with Sugar >> without needing to use the secondary actions and tools available in >> palettes. >> >> If there are basic functions or actions that are frequently needed >> that aren't exposed as primary actions, it would be useful to identify >> those areas in order to make improvements. Do you have any >> suggestions? >> >>>> Finding that many kids were actually waiting for the palette to appear >>>> always, instead of, for instance, simply clicking on an activity icon >>>> to join it, encouraged us to INcrease the delay on the palettes to >>>> help emphasize this as a secondary mechanism for interaction. >>> >>> Jesus, why? Think about what you just said for a moment. Why might someone >>> wait for the palette to appear before clicking? Probably because they want >>> to see what's on the palette! The situation of the palette is that all it >> >> I was not precise enough in my statement. Upon observation, many >> children were waiting for the palette exclusively to select the first >> option within it, which is the primary action that a click on the >> object itself would also invoke. They were NOT attempting to access >> the secondary functionality, but instead, due to the appearance of the >> palette, assumed that this was the only means of interaction. >> >> As Michael correctly points out, the contextual menus are indeed an >> inferior solution to direct interactions, since they require finer >> motor skills (and are difficult with poor trackpads, such as those on >> XOs) and movement away from the object they wish to interact to a >> secondary target within the menu. The icons are larger targets, easy >> to click without delay, and would have saved children both time and >> aggravation had they learned to act upon them directly. >> >>> takes is one accident to discover that hovering shows useful information. >>> And with the knowledge that the palette shows useful information, and that >>> hovering shows the palette, it is reasonable that one might just engage in >>> the described behavior. Either make the useful information available without >>> the contextual menu or make the current expected behavior more responsive. >> >> I think it may be useful to show the primary palette (which provides >> this useful information and text to elucidate the meaning and identity >> of various icons throughout the UI) immediately, though my (again, >> merely personal) preference would be to keep the secondary menu, which >> is needed less often, on some delay (or at least determine a manner of >> exposing it that does not obscure the primary target — the object >> itself — and encourage kids to take the long route via the context >> menu). >> >>>> Removing the delay pushes us, I fear, even farther away from an >>>> interface in which nice friendly large clickable icons can be directly >>>> manipulated and encourages every action to be done through a >>>> contextual menu with a bunch of text in it. Is that really what we >>>> want kids to face? >>> >>> So what you're saying is that you want to force children to use the system >>> in a way that you just said is contrary to what THEY actually want to do. >> >> As mentioned above, I wanted to encourage (not force) children to use >> the system more efficiently to accomplish what they wanted to do, with >> less delay, and with less movement of their finger upon a trackpad. >> >>>> Perhaps. What would you define as the ailment, yourself? The primary >>>> intent was to encourage use of a direct interaction model, in which >>>> palettes we're supposed to play a big role. When it turned out that >>>> young kids, who didn't read, and who didn't have motor skills for >>>> selecting form the palettes, we aimed to reduce accidental invocation >>>> of them without entirely eliminating discovery by increasing the >>>> delay. >>> >>> Many kids have motor skills, and the ones that don't initially are >>> remarkably good (being kids) at developing motor skills that they don't yet >>> have. Many kids also read. In fact, let's cut into some real deep philosophy >>> stuff here... >> >> Even adults with great motor skills had trouble with the trackpads on >> XOs. And, regardless of motor skills, I still wouldn't want to >> encourage a less direct means of interaction when a direct one is >> available. The problem seems to be balancing the exposure of the >> secondary actions (which clearly will require additional movement of >> the cursor to at least some degree, which should be minimized) with >> the exposure of the more basic and efficient methods of direct >> interaction. >> >>> The idea that the XO laptop is mainly for kids who can't read is completely >>> bogus. Now, maybe you're thinking of other children when you say this, but I >> >> Fair enough. They are certainly not *the* audience, but I do consider >> them to be among the audience. >> >>> prefer to first consider the main existing userbase. Laptops which have >> >> Agreed. >> >>> Sugar installed on them are primarily located in schools and are used for >>> education. It is kind of ridiculous to say "Well, you don't actually need to >>> know how to read to use the laptops, so we should make the interface not >>> require reading." when the truth is that, for most activities that have any >>> educational merit, you DO need to read and you need to read things >>> significantly more complicated than activity names. Most of the people who >>> use Sugar for most of the time WILL know how to read. >> >> Agreed. As mentioned before, cutting text from the first layer of the >> UI was a controversial decision at the time, and something I didn't >> fully agree with myself. Also, I think it would be useful to have the >> associated text (primary palette) appear quickly. I'm more worried >> about immediately revealing of all secondary actions, which pull >> attention from the more efficient manner in which basic actions can be >> performed — namely, clicking on the big icons. >> >> If we can do this in a manner which doesn't distract from the primary >> interaction methods and encourage inefficient paths through the UI, >> that would be great. Another possibility would be to educate children >> about right click somehow. Perhaps, as suggested by Wade, we could >> allude to the availability of more information immediately on hover, >> and perhaps even try making the right button the only means of >> invoking the secondary actions. This does work today, but the lack of >> discoverability is a definite problem. >> >> Also, for what it's worth, the initial design goal was to expand the >> secondary palette over the duration of the currently imposed delay. >> That is, it was meant to feel "snappy" by providing quick indication >> that "more stuff is here", without immediately expanding completely to >> show information that may not be needed or desired and without >> immediately obscuring a substantial portion of the screen. A sample of >> this idea can be seen here: >> http://www.sugarlabs.org/index.php?template=gallery&page=media_01 >> >>> Daniel Drake wrote: >>> >>>> It makes all menus that currently have a delay appear instantly? >>> >>> Not even close. On the XO sitting next to me it still feels like over a >>> second. There appears to actually be ANOTHER delay somewhere that was not >>> modified at all, because the UI takes the same amount of time to respond >>> with the change on both an XO and on a significantly more powerful laptop. >>> What is noticable, however, is that it just doesn't feel like things are >>> craaaaaaaaaaw-awwwwww-aawwwwwww----aaaaaaawwwwwww-ling (ling) after the >>> change, because before the user was met with a multi-stage, phased delay, >>> whereas now the delay is brief and only up front. >>> >>> If you haven't yet, you really need to at least try it. All of this "I don't >>> like it, but I haven't actually tried it" stuff is just unhelpful. >> >> That's true. I'll give it a shot. Thanks for all the feedback! >> >> Eben >> > _______________________________________________ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel