| RE: [ecf-dev] Shared Editor Usage Scenarios |
From: ecf-dev-bounces@xxxxxxxxxxx [mailto:ecf-dev-bounces@xxxxxxxxxxx] On Behalf Of Ken Gilmer
Sent: Friday, May 12, 2006 1:03 PM
To: Eclipse Communication Framework (ECF) developer mailing list.
Subject: Re: [ecf-dev] Shared Editor Usage Scenarios
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
kenOn 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---------------------------------------------------------------------------------
Gary Pollice gpollice@xxxxxxxxxx
Professor of Practice, Computer Science gpollice@xxxxxxxxxxxx (alternate)
Worcester Polytechnic Institute Office: 508-831-6793
100 Institute Road Mobile: 978-798-0019
Worcester, MA 01609-2280 < http://www.cs.wpi.edu/~gpollice/>
From: ecf-dev-bounces@xxxxxxxxxxx [mailto:ecf-dev-bounces@xxxxxxxxxxx] On Behalf Of Ken Gilmer
Sent: Friday, May 12, 2006 12:48 PM
To: Eclipse Communication Framework (ECF) developer mailing list.
Subject: [ecf-dev] Shared Editor Usage Scenarios
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