[sugar] Question about clipboard service

[Eben Eliason]

On Fri, Sep 5, 2008 at 4:37 PM, Greg Smith <gregsmitholpc at gmail.com> wrote:
> Hi Eben,
>
> I'm resurrecting an old thread here.
>
> BTW if you have any more specs or design proposals to share, now is a
> good time to consider them for 9.1-sugar .84 so send them out.

The clipboard specification on the wiki is a good starting place for
discussion, I think, and there are a number of tickets open on the
subject as well.

> I see where you are going with this work flow for kids writing on their
> own then coming together. It could work but it feels like we are forcing
> the kids to adapt to the technology rather than having the technology
> adapt to the way kids learn.

It's interesting that you see it that way.  I'd almost argue it the
other way:  We're attempting to keep the technology simple by taking
advantage of spacial proximity and social interaction, rather than
complicating it in ways which make it harder to guarantee robustness.
I want to be able to say "if nothing else works, manual merge via copy
paste will."  I think you can probably agree with that sentiment.

> Having the two instances of the activity open and moving back and forth
> between them seems especially inelegant.

Inelegant, perhaps.  But it's also, by definition, the fail-safe
solution to the problem.  I'm all for creating APIs that enable more
intelligent merge behaviors.  But some things simply can't be merged.
Some activities may not take advantage of these APIs.  When nothing
else works, we MUST support the simple ability to aggregate content
via basic copy/paste.

Moreover, I'm not sure that this manual system is as entirely
inelegant as you suggest.  Most merge software shows a two-up display
of differences, side by side, providing info about what to merge.  But
XO screens are small.  In a completely non-technical way, allowing
multiple instances to be open at once allows you and I, for instance,
to present our individual documents on our own screens, side by side
for comparison.  Then one or the other of us can copy/paste bits and
pieces together as needed.

> That said, I don't have a better idea readily available :-(. I think we
> should go back to fundamentals and think this through one more time.

Again, I don't think there's more to think through for a first pass.
The manual merge capability is an essential part of the system, and
the most basic, regardless of what other conveniences we can build up
to support these types of use cases.

> How do kids collaborate on projects with pencil and paper? Is anyone on
> the list a teacher? I'll run it by my own kids but I think we need to
> watch this process in action to get a better feel for it.
>
> I can't remember any times when my kids wrote something at home then
> brought it in to class then combined it in to a project. They usually do
> some research, come up with ideas then write it together in person.

Perhaps, but were they using a pencil and paper?  If they had typed
their ideas up instead, wouldn't they be irritated at having to type
it again?  Of course, I'm not pushing any particular learning style
here.  The kids don't have to wind up in a circumstance where a merge
is needed.  If they never do, great! (But they will, even if they
don't intend to...) As long as we offer collaborative software, the
case exists, and we need to have a way to handle it smoothly within
the system we've built.

I, for the record, have collaborated in this way countless times.

> I believe that when kids get together in a group, one kid takes the lead
> and does most of the writig while others shout out ideas and make
> suggestions.

It's true that, often, one person is in charge of performing the
merge.  That's partly because it's been the only way to do it so far.
And, in another sense, this is still how it will likely happen.  Even
if we have several documents open, we might assign a single individual
in the group to be the aggregator who does all the copy/pasting.  Once
finished, everyone closes their own version and continues working in
his (and henceforth our) copy. Even if others aren't around to shout
out ideas, the fact remains that the only way to do the merge is to
open both documents at once!

> We don't have to imitate how its done now, but maybe watching kids
> interact will help inform the design. One thing you hear a lot is that
> kids teach each other how to use the XO better than teachers teach them.
> What does that look like in detail? One kid leans over and types on
> another kids keyboard or she tells the other kid what to do?
>
> May be the right design is to have each kid open write (or a web page?)
> and then they click a button and everything on their screen is copied in
> to the shared version which they now also see. Sort of a fast start
> option. Then kids edit that down to a final product. A dump everything
> in then prune it down approach. That's my working methodology (see 9.1
> page :-) but my brain is way different than a kids...

This is an interesting alternative (or subcase of) a traditional merge
algorithm.  Perhaps if an activity doesn't support complex merges, or
a merge can't be done automatically, something like this could happen.

In any case, I'm sure you're starting to see my deeper argument, which
is that this copy/paste functionality is required regardless of the
niceties we can add to do it automatically.  Effectively, we have to
consider each version of a document as a separate file (eg.
my_document_1.doc and my_document_2.doc).  We'd find it appalling if,
for instance, Word wouldn't allow us to open both of these up at the
same time, instead requiring us to open one, copy from it, close it,
open the other, and then paste (and repeat, as necessary).

- Eben

> Time to crack open the Piaget again. Maybe this one will inspire some
> new design ideas:
> http://www.amazon.com/Childs-Conception-Space-Jean-Piaget/dp/0393004082/ref=sr_1_1?ie=UTF8&s=books&qid=1220645614&sr=8-1
>
> Minsky, Papert or other references welcome too.
>
> I believe there have been some "blackboard" or shared space ideas kicked
> around in the past. Does anyone have a link to those?
>
> I know its a fuzzy question but I wanted to throw it out so we think
> about it from the ground up while we still have time. For now, we stick
> with your design until someone comes up something better...
>
> Have a great weekend,
>
> Greg S
>
>  >
>  >>> Can you walk me through the steps needed for that? e.g. one kid
> starts an
>  >>> activity then shares it, each other kid opens the activity and
> joins (or
>  >>> opens their own work?), then ???. How do they get their own work on the
>  >>> clipboard and how do they add it to the shared activity?
>  >>
>  >> Step by step. I limit the example to 2 kids for simplicity; the method
>  >> scales naturally.
>  >>
>  >> 1. Kid A starts an activity
>  >> 2. Kid A shares the activity
>  >> 3. Kid B joins the activity
>  >> 4. Kids A and B collaborate (synchronously) in the activity
>  >> 5. Kids A and B go home
>  >> 6. Either kid A, kid B, or both work in the activity (asynchronously)
>  >> 7. Kids A and B come back to school
>  >> 8. Kid A opens his version of the activity*
>  >> 9. Kid B joins A's version of the activity
>  >> 10. Kid B opens his own version of the activity**
>  >> 11. Kid B copies part of his own version to the clipboard
>  >> 12. Kid B pastes that clipping into A's version of the activity
>  >
>
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>