Gary,
Interesting...thanks for your response! So
in your situation, where students may be in a variety of places, connecting
via various ways (campus network, dial up, etc.) how do you see students
creating/connecting to a shared ECF instance? Are the current ECF
scenarios of creating a shared session sufficient for you and your
students?
[GFP] I think the current scenarios of joining a group will work
fine. We want to be able to establish a chat connection, possibly other types
of connections with voice, etc. I have to look in more detail about
the scenarios. I'm still coming up to speed on
ECF.
Regarding shared editing, do you see a
free-for-all model working best? Do you think more explicit control over
who can edit is important?
[GFP] I think we need both. Free-for-all might work
when dealing with diagrams. This is like some of the net meeting things where
you can all be drawing at the same time. But when it comes to editing code, I
think you need to be able to control the driver and be able to change drivers
whenever necessary.
One thing that strikes
me from your example is that the TA/Instructor in this case cannot count on
having the same project/file in their workspace. Students will create
arbitrary project structures. Due to this it makes sense (at least in
this use case) to have project synchronization occur before shared editing
begins. Naturally, this would exist as a new project wizard, in which
files from remote peers would be transferred locally. After the shared
session ends, the project could safely be deleted, etc..
[GFP] There are two things I see. One is that the two (or more)
participants will have the same project. Student team members should have this
and the change will need to be propagated at some point to everyone.
Although, I could accept the change being made at the originating project and
then propagated through the version control system. I think project
synchronization should be optional. Also, it would have to be agreed upon by
all parties. For example, I might have the "solution" project as my current
Eclipse project. I don't want to have the student be able to synchronize with
mine without my permission.
There is the second case, where I probably won't have the same project
structure as the student. In that case I just want the shared file that we can
work on, but that will be compiled and stored on the student's project.
This could be subsumed by the above condition where the change is
propagated via the VCS.
Let me know what you
think...
thanks
ken
On 5/12/06, Gary
Pollice <gpollice@xxxxxxxxxx> wrote:
As an
instructor, one of the things I regularly do with my students is talk
to them over a chat client when I'm at home and they're in their dorm rooms
or in the lab working on an assignment. I often have to have them email me
their code so I can look at what they're saying. One of the reasons I want a
shared editor in the collaborative environment we're building, based upon
ECF, is that in such situations I, or one of my TAs, can establish a
session with the student to see exactly what they're trying to do, have them
explain it while they show me, and then to possibly insert code into the
file so they can get started on the right path.
--Gary
Hello,
I've been thinking about various
ways groups might use shared editing. My initial (base) use case was a
distributed development team, perhaps in a design meeting or doing code
review. However I can think of a few other scenarios. These
scenarios also imply better sharing models:
1. Instructor use
case. In an education context, one peer may have exclusive write
access to an editor, others would be read only. Additionally, file
open/close actions on the instructor node would propagate to "student"
nodes.
2. Document collaboration use case: A document (rtf, etc.) is
being edited by a group. Higher levels of locking semantics are
required, as these people are not developers (or even if they are) and may
be confused by free-for-all shared
editing.
a) A token style
workflow, where the user with the token can edit, and can also pass the
token to other users in the collaboration
context.
b) A lock style
workflow, where a user locks a portion (paragraph? line item?) of a
document. Others cannot edit until locker unlocks.
Any
thoughts? Any other use cases people can think of? I may work on
implementing these in the shared editor if they seem of value to
others.
Thanks
Ken
_______________________________________________
ecf-dev
mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev