[IAEP] Teacher in Uruguay enchanted to see his ideas integrated, into global Sugar update

[Eben Eliason]

On Fri, Sep 19, 2008 at 2:58 PM, Greg Smith <gregsmitholpc at gmail.com> wrote:
> Hi Eben et al,
>
> I'm going to break this in to three parts:
>
> 1 - In terms of aggregating and passing on key themes of user input, I'm
> on it full time :-). Like Janus I have two faces and one of them points
> towards the users and the other towards the engineers.
>
> That said, its much more than a full time job. Its going to take a
> community engineers and users learning to work together. Hopefully I
> don't interfere and I can be disintermediated as more direct channels
> open up. My vision of where we need to go is here:
> http://wiki.laptop.org/go/User:Gregorio

Awesome.  I'm glad to hear Seth is also coordinating similar efforts.

> In terms of the 9.1 page, I'm asking that people put things which have
> been aggregated. That is:
> - collect the input and specific feature request
> - uncover themes from multiple requests
> - decide if something is well defined and describe what its for and why
> (not so much how we will address it)
> - ensure you have a good communication channel to the requester

I think the same, but I don't think the "point of aggregation" should
be on a page specific to a particular release.  Instead, we should
have a space (just another page on the wiki?  a mailing list? a
database?) for collecting feedback, thoughts, ideas, suggestions,
etc., and we should move items from that place of aggregation INTO
pages for specific milestones (and, of course, into trac tickets so we
have record!).

> That's what I think of as aggregating. Once that is done it and its
> something you think should be built I encourage you to put it on the 9.1
> page.

Right, we're mostly on the same wavelength.  I just want a space for
aggregation to happen so it's not split among a bunch of random wiki
pages.

> In terms of how better to collect and aggregate feedback in to a system
> from which we can easily extract it, I'm open to suggestions. You said
> "If our biggest problem is sifting through *too much* feedback, then
> we're in good shape."
>
> 2 - Christoph, you asked for a press release showing "teacher asked for
> this and we delivered". Luis gave you something a teacher needs we also
> got the name of the relevant engineer. Can we close the loop, deliver
> this and issue a press release?
>
> This is what it takes to build trust and create a lasting relationship.
> One request, understood and worked on by a few people and delivered.
> Then ++. If you get requests and we ignore them or say "you don't want
> that" that hinders future input and damages our relationship building
> capacity.
>
> 3 - This is a related point which deserves its own thread. I will also
> make related comments on the design meeting and clipboard threads. Just
> warming you up here.
>
> We need copy and paste. My concern is that working on copy and paste
> does not show us listening to the users. The only user complaint about
> copy and paste or the clipboard is that it doesn't work reliably. For

That's certainly part of it.  Making copy and paste a) buttons b)
keyboard shortcuts and c) drag'n'drop ubiquitous is a very important
goal.  Without this, user's won't even know how to take advantage of
it.  However, I'm fairly certain there have been numerous complaints
regarding the lack of identifiability for clippings.

> example, I started to discuss the work flow of copy and paste from one write
> instance to another with Julian from Birmingham yesterday and he stopped me.
> He said, first you should make what you have work. I asked if he would
> accept no new features for 6 months in return for much greater reliability
> and he replied "yes" without hesitation.

I think a "working clipboard" goes under the reliability and stability
goal.  You're right that the addition of a preview is likely a
feature, but we already have colors, titles, and icons which *don't
work* consistently.  We should, at least, be fixing that half of the
system even if we wait until a future release to add an API for
activities.  We'll see how it goes.  My focus is similar to yours, but
different in a key way:  while you seem to want
no-new-features-period, I'm of the mind to add-nothing-big-and-new
while still-fleshing-out-the-things-we've-got.  The clipboard is a
prime example of a system/feature that doesn't work reliably or to its
potential, and I want to massage it into shape so that the things
we've started building, and exposed within the UI already, actually
become useful and reliable.

> Aside from that, the priorities from users related to moving data are around
> how to upload content to the Internet, how to get it off the
> internet and on to the XO for editing and how to move files from one XO
> to another. The first three suggestions on the Uruguay forum
> (http://www.mediagala.com/rap/foro/viewforum.php?f=12) are requests to
> build a TamTam lesson plan, simplification of getting files off the
> internet and better tools for posting content to the internet. Since
> they are on build 656, some of those issues may be solved. Nonetheless
> its necessary input which tells us what they are most interested in doing.

Interesting ideas.  We also need to consider which of these fall under
Sugar, and which do not.  The first suggestion is clearly activity
specific.  We should be making downloads and uploads easier, for sure
(I think we went a LONG way toward uploads with this release, too!).
Moving data from XO to XO is on the sugarlabs goals page also, but I
believe you pushed it into the unwanted features section.

> I want to make sure that all of our work is grounded in specific
> requests and user goals. That has to come first before we design code or
> GUIs. Part of my work is to explain what is most important to users so I
> apologize for falling behind on making that clear. As usual, engineering
> has gotten ahead of me. I did post a few ideas on the file moving area
> here: http://wiki.laptop.org/go/9.1.0#File_Management
>
> We urgently need to listen to the input we have so far. Everything
> we do must be tied to a high level goal and to specific input and users.
> That is my most fundamental request!

Sounds good.  Thanks for the guidance so far.

- Eben

> BTW I'm not trying to cast aspersions on your work. The 8.2 release has been
> getting great reviews with respect to the new GUI. Its by far the strongest
> new feature set in the release.
>
> Thanks,
>
> Greg S
>
> PS sorry for the long e-mail. Not time to edit as we need to make a real
> release candidate for 8.2 ASAP!
>
> Eben Eliason wrote:
>>
>> On Thu, Sep 18, 2008 at 4:19 PM, Greg Smith <gregsmitholpc at gmail.com>
>> wrote:
>>>
>>> Hi Eben,
>>>
>>> There's already a lot of feedback. Start sifting :-) Please post
>>> anything you aggregate and think we should work on to the 9.1 page:
>>> http://wiki.laptop.org/go/9.1.0
>>
>> None of us have time to aggregate, if we even find out where we might
>> pull info from. That's the point I'm getting at.  I want a way to make
>> this info readily accessible to everyone, without devoting half of my
>> week to scouring scattered sources.  That could be a full time job.
>>
>> Also, I'm not sure that aggregating on the 9.1 page is a good
>> solution. That's a good way for a lot of good feedback to get lost in
>> 6 months.  I'd rather have a mailing list, or forum, or some other
>> form of database from which we can reference individual responses on
>> trac tickets, so that the feedback can live on as a reference in a
>> place we won't lose it.  A mailing list sounds like the easiest
>> solution, at least short term.
>>
>> - Eben
>>
>
>