1. A Collaborative Writing Mode for Avoiding Blind Modifications Center for E-Business Technology Seoul National University Seoul, Korea Nam, Kwang-hyun Intelligent Database Systems Lab School of Computer Science & Engineering Seoul National University, Seoul, Korea Claudia-Lavinia Ignat, G´erald Oster, Pascal Molli and Hala Skaf-Molli Nancy-Universit´e, LORIA-INRIA Lorraine Campus Scientifique France 9th International Workshop on Collaborative Editing Systems (IWCES), 2007

2. Copyright  2009 by CEBT Contents  Introduction  Motivating Example  Our approach  Revisiting Motivating Example  View user interface  Conclusions and Future Work  Discussion IDS Lab Seminar - 2

3. Copyright  2009 by CEBT Collaborative Editing IDS Lab Seminar - 3  Blind modification When user modify a document without being aware of concurrent changes

4. Copyright  2009 by CEBT Synchronous/Asynchronous Work Modes  Synchronous editing Reduces conflicts and task completion times Disadvantage – no support for work in isolation  Asynchronous editing Support for work in isolation Workspace copies kept in consistent states Risk of blind modifications – Useless work – Redundant work IDS Lab Seminar - 4

5. Copyright  2009 by CEBT Main Issue  How to allow Work in isolation? Avoid blind modifications?  Our proposition Provide information in real-time about group activities Deal with trade-off awareness/privacy Annotate the document with uncommitted changes IDS Lab Seminar - 5

6. Copyright  2009 by CEBT Motivating Example Actions User 1 Actions User 2 Actions User 3 Removes method isRealupdates method isRealcreates test class IntegerTest IDS Lab Seminar - 6

7. Copyright  2009 by CEBT Scenario with standard VCS StepActions User 1 Actions User 2 Actions User 3 1op1= removes method isReal op 2 = updates method isReal op 3 = creates test class IntegerTest 2COMMIT 3UPDATE (conflict op 1 ↔ op 2 ) UPDATE (IntegerTest does not compile) 4Reinsert new method isReal Remove test for isReal 5COMMIT 6UPDATE & COMMIT (no test for isReal) 7UPDATE IDS Lab Seminar - 7 Useless work Side effects Useless work Side effects Re-execution of own changes Re-execution of own changes Useless work Incomplete task Useless work Incomplete task

8. Copyright  2009 by CEBT User can perform…  Modifies a document by generating operations that are immediately applied on his local copy  Makes available his local changes to other users by committing his local operations to the repository If some non-integrated remote operations are available on the repository, the user is not allowed to commit local operation.  Updates his local copy of a document by integrating remote operations from the repository IDS Lab Seminar - 8

9. Copyright  2009 by CEBT Our approach  Assumption Users continuously connected – In order to notice real-time non-committed parallel modifications  However, this assumption can violate user privacy As users may not agree to send draft changes of their work  A trade-off between privacy and the usefulness of awareness To deal with this trade-off, a filtering mechanism is provided.  Ghost operation Filter non-committed local operations before sending them to other users by masking some operation parameters Filtered name, filtered type, and filtered value IDS Lab Seminar - 9

10. Copyright  2009 by CEBT Our approach  Send non-committed operations in real-time  Preserve user privacy by filtering the non-committed operations (ghost operations) Example: – op1= insert(User2,"file.txt",4,"Preventingblindmodifications") Original operation – g(op1) = insert(User2,"file.txt",4,30) The content of the inserted line is masked. – g(op1) = edit("file.txt",4) The identity of the user is masked. Trust metric may be used for automatic filtering  Integrate ghost operations as annotations within the document IDS Lab Seminar - 10

11. Copyright  2009 by CEBT Revisiting Motivating Examples IDS Lab Seminar - 11 Generated OperationsPrivacy filterGhost operations op 1 =delete(User 1, Integer.java, 15-18) No filterg(op 1 )=delete(User 1, Integer.java, 15-18) op 2 =update(User 2, Integer.java, 16, "return false“) Filter contentg(op 2 )=update(User 2, Integer.java, 16, -) op 3 : create IntegerTest.javaNo ghost-

12. Copyright  2009 by CEBT Interface User1  op 1 = delete(User 1, Integer.java, 15-18)  g(op 2 ) = update(User 2, Integer.java, 16, -)  No ghost operation from User 3 IDS Lab Seminar - 12 User 1 will not validate the removal of method isReal() User 1 will not validate the removal of method isReal()

13. Copyright  2009 by CEBT Interface User2  op 2 = update(User 2, Integer.java, 16, "return false")  g(op 1 ) = delete(User 1, Integer.java, 15-18)  No ghost operation from User 3 IDS Lab Seminar - 13 User 2 is aware of removal of isReal() – can Initiate communication User 2 is aware of removal of isReal() – can Initiate communication

14. Copyright  2009 by CEBT Interface User3  op 3 : createIntegerTest.java  g(op 1 ) = delete(User 1, Integer.java, 15-18)  g(op 2 ) = update(User 2, Integer.java, 16, -) IDS Lab Seminar - 14 User3 can examine changes in Integer and Postpone testing User3 can examine changes in Integer and Postpone testing

15. Copyright  2009 by CEBT Conclusions and Future Work  Conclusions Awareness approach for avoiding blind modifications (in text, wiki, source code documents) Ghost operations – Trade-off awareness – Privacy  Future work Develop a model for our proposed interaction mode (Operational Transformation Mechanism) Provide users suitable interfaces for filtering Implement a prototype for awareness in software engineering Perform user studies IDS Lab Seminar - 15

16. Copyright  2009 by CEBT Discussion  Pros The idea focus on not managing conflict after the task is done, but managing it during the task Consider privacy  Cons Assume many users modify same document or page, – Can this approach be effective? IDS Lab Seminar - 16