Improving real-time collaboration with highlighting

Future Generation Computer Systems 20 (2004) 605–625

Improving real-time collaboration with highlighting

Haifeng Shen, Chengzheng Sun∗School of Computing and Information Technology, Griffith University, Brisbane, Qld 4111, Australia

Abstract

Highlighting is a common tool in most single-user editors. It provides users with a mechanism of communication andcollaboration between the author and readers by emphasizing some important text. This tool is also necessary and even morevaluable in multi-user collaborative editors. However, it is non-trivial to extend it from single-user environment to multi-userenvironment because of the following challenges: (1) the need to differentiate highlights performed by different users, (2)the need to tackle inconsistency problems caused by concurrent operations and non-deterministic communication latency,and (3) the need to provide a flexible undo facility with the capability of undoing any highlighting operation at any time. Inthis paper, we will systematically address these issues and offer our solutions. These solutions lay a foundation for handlingupdate operations similar in nature to highlighting, which update attributes of text instead of inserting/deleting text.© 2003 Elsevier B.V. All rights reserved.

Keywords: Collaborative editing; Consistency maintenance; Group awareness; Highlighting; Operational transformation; Undo

1. Introduction

Highlighting is a common tool in most single-usereditors, such as Microsoft Word. It provides users witha mechanism of emphasizing important text in orderto support non-real-time communication between theauthor and readers. This tool is naturally necessary inmulti-user collaborative editors because features avail-able in single-user applications must also be availablein corresponding multi-user applications for encour-aging users to learn, use and adopt new collaborativeapplications. Moreover, this tool is even more valu-able in multi-user collaborative editors for the follow-ing reasons.

Firstly, besides supporting non-real-time collabora-tion, highlighting can be used to help real-time col-

∗ Corresponding author.E-mail addresses: [email protected] (H. Shen),[email protected] (C. Sun).URL: http://www.cit.gu.edu.au/∼scz.

laboration, such as highlighting key points in brain-storming, discussing interesting topics, and debuggingprograms.

Secondly, highlighting may be used for other pur-poses that have never been met in single-user edi-tors. Highlighting can be used for providing awarenesshints. For instance, when doing some crucial tasks inan area, one can highlight the area to warn others fromupdating this area. To avoid conflicts, warning can beused as a complementary method to preventing, whichis normally achieved by the technique of locking.

Finally, highlighting can be used as a complemen-tary tool to telepointer, a gestural communicationtool for supporting real-time discussion. Telepointer[2,16,17] is a well known and commonly used toolin real-time collaborative applications for indicatingremote users’ cursor or mouse locations[2]. It canserve as a mechanism of gestural communicationthrough which participants indicate relations betweenthe artifacts on the display, draw attention to partic-ular artifacts, show intentions about what they are

0167-739X/$ – see front matter © 2003 Elsevier B.V. All rights reserved.doi:10.1016/S0167-739X(03)00176-6

606 H. Shen, C. Sun / Future Generation Computer Systems 20 (2004) 605–625

......How are you do today?I have a seminar........How old are your sister?She is not old.

(a) (b)

......How are you do today?I have a seminar........How old are your sister?She is not old.

Fig. 1. Telepointers versus highlights.

about to do, suggest emotional reactions, and so on[17]. However, a telepointer can only lay a focus onone character, which usually does not make muchsense for text-based documents. Moreover, a tele-pointer dynamically moves around a document andthe user cannot see its history, hence it is incapableof simultaneously keeping multiple focuses, whichmakes it hard to indicate relations among multipleartifacts in a document. Highlighting can compensatefor these drawbacks because highlighting is naturallyto highlight a region rather than a single characterand multiple highlights can be simultaneously kept ina document.

To illustrate the above points, an example is shownin Fig. 1, where a teacher continuously checks Englisherrors in a document and a student concurrently cor-rects the errors pointed out by the teacher. InFig. 1(a),the teacher’s telepointer moves from one error to an-other. The teacher has to wait for the student to correctthe current error before moving to the next one be-cause once his telepointer moves to the next error, theinformation on previous errors (shown as gray tele-pointers) will disappear. Moreover, the last focus ofthe telepointer for instance does not tell where the er-ror exactly is. In contrast, inFig. 1(b), all errors havebeen simultaneously kept as highlights, which haveindicated where the errors are exactly are. As a re-sult, the teacher can keep checking and marking errorswithout waiting for the student to correct while thestudent can keep correcting the marked errors withoutcatching up the teacher’s pace.

However, it is non-trivial to extend single-user high-lighting to collaborative highlighting. Firstly, the userinterface for highlights in multi-user collaborative edi-tors should be carefully studied because it is necessaryto distinguish different users’ highlights in order toprovide some sort of group awareness support. Groupawareness[1,8,10,11]is a fundamental and challeng-

ing issue in collaborative applications. The user inter-face design has a fundamental impact on other issues.

Secondly, concurrent operations and non-determini-stic communication latency may cause inconsistencyproblems[24]. In particular, concurrent highlightingoperations may overshadow each other in differentways at different sites, concurrent editing opera-tions may change the document contents on whichsome highlighting operations were defined, andnon-deterministic communication latency may causeoperations to arrive out of order. Consistency mainte-nance is another fundamental and challenging issue indistributed collaborative applications with replicatedarchitecture[2,4,24].

Finally, collaborative undo of highlighting oper-ations is needed for recovering from errors[21],exploring alternatives by backtracking[21], andchanging focuses during a collaborative session[18]in multi-user environments. It is very challenging toachieve collaborative undo[3,6,7,13,15,21]in general.Most existing solutions are about undo of text insert-ing/deleting operations[13,15,21]and graph editingoperations[6]. No work has been done on the undoof text attribute updating operations like highlighting,and none of existing solutions is able to be directlyapplied for the undo of highlighting operations. Theredifference between highlighting operations and textinserting/deleting operations are twofold. On the onehand, highlighting operations do not insert or deletecharacters but change some attribute of existing char-acters. On the other hand, the relation between a pairof highlighting operations is how they are layering.Although the relation between a pair of graph edit-ing operations is also how they are layering[6], thedifference between highlighting operations and graphediting operations is that highlighting operations areperformed on sequential characters while graph edit-ing operations are performed on independent objects.

Collaboratively highlighting text is an importantand significant extension to collaboratively insert-ing/deleting text. It lays a foundation for handlingupdate operations similar in nature to highlighting,which update attributes of text instead of insert-ing/deleting text. As we notice, many sophisticatededitors such as Microsoft Word, have rich attributesfor decorating characters, such as font, size, back-ground/foreground color, bold, italic, and underline.Solutions for consistency maintenance and undo for

H. Shen, C. Sun / Future Generation Computer Systems 20 (2004) 605–625 607

collaborative highlighting are general techniques,which can be directly applied to tackling the issues ofconsistency maintenance and undo for collaborativelytext attribute updating operations.

The paper is organized as follows.Section 2dis-cusses the issue of user interface design.Section 3presents a package of consistency maintenance solu-tions followed by a flexible undo solution. Finally thepaper is concluded with a summary of major contri-butions and future work.

2. User interface design

The user interface for representing highlights is afundamental issue in collaborative editors. In single-user editors, a highlight is usually represented bychanging the background color of a text region to arandomly chosen color. In multi-user collaborativeapplications, color is commonly used to differentiateoperations performed by different users in order toprovide some sort of group awareness support[1,11].Each user in a collaborative session is representedby an unique color, which is called the user’s IDcolor. For example, in some collaborative editors[9], the foreground color of the characters insertedby a user is set to the user’s ID color. The sameapproach is also used to differentiate highlightingoperations performed by different users in multi-usercollaborative editors. The MMM shared editor[5]has already demonstrated the use of color to differen-tiate highlighting operations performed by differentusers.

The question is how to design the user interface torepresent highlights. There are many design choices.For example, as shown inFig. 2, in MMM sharededitor[5], each highlight is marked by an underline inone user’s ID color. Multiple overlapping highlightsare represented by multiple underlines stacked beneaththe text. The major drawback of this approach is thatit adopts a totally different user interface to representthe same function in single-user editors, which has adramatic impact in discouraging users to learn, useand adopt this shared editor. In addition, the followingissues are non-neglectable either:

1. If highlighting is represented as underlining, howto represent underlining itself?

Site 1 Site 2abcde abcde

abcde

red green

H1 =Highlight abcd

abcde

H2 =Highlight bcde

abcde

abcde

Fig. 2. Highlights represented as underlines.

2. A document could be distorted if unlimited andnon-deterministic number of stacked underlines areallowed between any two lines.

It is important that a multi-user collaborative appli-cation emulates the user interface of the correspond-ing single-user application in order to encourage userswho are used to the single-user application to learn, useand adopt the multi-user collaborative version. There-fore, as shown inFig. 3, the user interface for a high-light should be represented as changing backgroundcolor of a selected text region to the ID color of theuser who performs the highlighting operation. On thebasis of this user interface design, we discuss the is-sues of consistency maintenance and undo. Prior todoing that, the internal representation of highlighting

Site1 Site2abcde abcde

abcde abcde

redg reen

H1=Highlightabcd H2=Highlightbcde

abcde abcde

Fig. 3. The user interface of highlights.


operations and some notations are necessary to be in-troduced.

A highlighting operation can be simply denoted asHlt[P, N], which means highlighting a sequence ofN

characters starting from positionP in the document.However, as discussed inSection 1, undoing a high-lighting operation must recover highlighting regionsthat have been overshadowed by the undone high-lighting operation. To support the recovering of high-lighting regions, highlighting regions overshadowedby a highlighting operation should be maintained someway in that operation. The data structure OHS (over-shadowed highlighting set) is used to maintain thatinformation, where each element is called an OHR(overshadowed highlighting region) denoted by a tu-ple 〈S, L, C〉, representing a overshadowed highlight-ing region in colorC (null is used if the region has notbeen highlighted) covering a sequence ofL charactersstarting from positionS.

As a result, a highlighting operation highlightinga sequence ofN characters starting from positionPovershadowingm OHRs will be denoted asH =Hlt[P, N, OHS], where OHS= {〈Si, Li, Ci〉|0 ≤ i ≤m − 1}. If 〈Si, Li, Ci〉 (0 ≤ i ≤ m − 1) are sorted bySi’s value, then it must beSi = Si−1 + Li−1 (0 ≤i ≤ m − 1), P = S0, and N = ∑m−1

i=0 Li. A high-lighting operationH ’s inverse operationH is denotedasUhlt[P, N, OHS], representing recovering the over-shadowed highlighting regions for a sequence ofN

characters starting from positionP . Concretely speak-ing, for anyi (0 ≤ i ≤ m−1), highlighting a sequenceof Li characters starting from positionSi in color Ci.

A special highlighting operation is dehighlighting,which clears highlights covered by a specified re-gion. A dehighlighting operation can also be denotedas Hlt[P, N, OHS]. The only difference is the colorfor a dehighlighting operation is not the ID color ofuser who performs the operation but the document’sdefault background color. The solutions for theconsistency maintenance and undo of highlightingoperations are naturally applied to dehighlighting op-erations. Therefore highlighting and dehighlightingoperations will not be differentiated in the proposedsolutions.

An inserting/deleting operation is denoted asIns/Del[P, N, S] representing inserting/deletingstring S whose length isN at position P . For aninserting/deleting operationE, P(E) is denoted as

H2 = Hlt [1,4,{<1,3,red>,<4,1,null>}]

abcde

H1= Hlt [0,4,{<0,4,null>}]

abcde

abcde

abcde

Site 1red

Site 2green

= Uhlt[1,4,{<1,3,red>,<4,1,null>}]

2H

= Uhlt [0,4,{<0,4,null>}]1H

abcde

Fig. 4. Highlighting operations and their inverses.

its position parameter,N(E) denoted as the lengthparameter, andS(E) denoted as the text parameter.For a highlighting operationH = Hlt[P, N, OHS],P(H) is denoted as its position parameter,N(H) de-noted as its length parameter, and OHS(H) denotedas its OHS parameter. For any operationO, T(O) =Ins/Del/Hlt/Uhlt is denoted as its type parameter,andC(O) is denoted as the ID color of the user whoperformsO.

An example is shown inFig. 4 to illustrate theinternal representation of highlighting operationsand their inverses. Site 1 performs highlightingoperation H1 to highlight charactersa, b, c, andd in its ID color red. After the execution,H1 =Hlt[0, 4, {〈0, 4, null〉}], which covers one OHR=〈0, 4, null〉 representing charactersa, b, c, andd havenot been highlighted by any operation beforeH1has been performed. Subsequently, Site 2 performshighlighting operationH2 to highlight charactersb,c, d, ande in its ID color green. After the execution,H2 = Hlt[1, 4, {〈1, 3, red〉, 〈4, 1, null〉}], which cov-ers one OHR= 〈1, 3, red〉 representing charactersb,c, and d have been highlighted in red and anotherOHR = 〈4, 1, null〉 representing charactere has not


been highlighted by any operation beforeH2 has beenperformed.

Then Site 2 performsH2 to undoH2’s effect. Afterthe execution ofH2 = Uhlt[1, 4, {〈1, 3, red〉, 〈4, 1,

null〉}], charactersb, c, andd are recovered to be high-lighted in red and charactere is recovered to be in thedocument’s default background color. Finally, Site 1performsH1 = Uhlt[0, 4, {〈0, 4, null〉}] to undoH1’seffect. After then, charactersa, b, c, andd are recov-ered to be in the document’s default background color.

3. Consistency maintenance

The consistency model proposed by Sun et al.[24] addressing inconsistency problems caused byconcurrent text inserting/deleting operations andnon-deterministic communication latency in real-timecollaborative editing systems can also be used toaddress inconsistency problems for collaborativehighlighting text in real-time collaborative editingsystems.

3.1. Causality violation

As shown in Fig. 5, consider a document con-tains charactersA, B, and C, replicated at threesites, Sites 1–3. Site 1 performs an inserting opera-tion E = Ins[1, 2, xy] to insert charactersx andy atposition 1, that is between characterA and B. Sub-sequently, Site 2 performs a highlighting operationH = Hlt[1, 2, {〈1, 2, null〉}] to highlight charactersxandy inserted by operationE. So the highlighting op-erationH is causally after the inserting operationE.

After both operations have been executed at thesethree sites, results at Sites 1 and 2 are both correctbecause the causal relationship between operationsE

and H have been correctly preserved. However, thiscausal relationship was not preserved at Site 3, whichexecuted the highlighting operationH before the in-serting operationE, leading to the result that charac-tersB andC instead ofx andy have been highlighted.Obviously, the highlighting operationH is executedout of causal order, which refers to the wrong textBCbecause the textxy thatH intends to highlight has notbeen inserted yet.

This is a typical causality violation problem and thewell-knowncausal ordering technique[12,14]can be

Site 2

ABC ABC ABC

AxyBC

Site 3

AxyBC

redg reen blue

E=Ins[1,2,xy]

H=Hlt [1,2, {<1,2,null>}]

AxyBC

delayed

Site 1

AxyBCABC

AxyBC

AxyBC

Fig. 5. An example of causality violation.

directly used to solve this problem. This technique re-lies on a timestamping scheme based on a data struc-ture namedState Vector [9,24] to capture the causalrelationships among all operations. Operations that ar-rive out of causal order are selectively delayed. In thisexample, as depicted inFig. 5, whenH arrives at Site3, H ’s state vector tells the system that an operationthat is causally beforeH has not arrived yet. So thesystem will delayH ’s execution until operationE thatis causally beforeH arrives and is executed.

3.2. Divergence

Fig. 3 reveals a divergence problem that concur-rent overshadowing highlighting operations executedin different orders at different sites would producehighlights overshadowed in different ways at differentsites, leading to divergence. Divergence in collabora-tive highlighting is defined in terms of different lay-ering of highlights, although document texts could bethe same, which is different from that defined in[24],addressing different document texts at different sitesas a result of text inserting/deleting operations.

Serialization is a commonly used technique toensure convergence, which forces operations to be


executed in the same order at all sites. Serializationcan certainly be used to ensure convergence in col-laborative highlighting.Turn-taking [2] is a strictserialization protocol, which prohibits any operationto be executed out of order at any time. In this proto-col, only one user is allowed to perform operations ata time. As a result, there is no concurrent operationand all operations are serialized to be executed in thesame order at all sites. Because only one user can geta turn to perform operations, concurrent work is notsupported by this protocol. Moreover, this protocolis unsuitable for supporting real-time collaborationin slow network environments such as the Internetbecause the long communication latency makes ittake a long while for a user to get a turn to performoperations, causing poor local response.

Undo/do/redo [24] is a relaxed serialization proto-col, which allows operations to be executed out of or-der but deploys a repairing mechanism to cope without of order operations. Briefly speaking, local oper-ations are executed immediately as generated withoutrequesting a turn. When a remote operation arrives, ifit is in the right order, it will be executed immediately,otherwise a repairing mechanism will be provoked tofirst undo operations that should be executed after thisremote operation, then do the remote operation, andfinally redo all operations that have just been undone.As a result, all operations are serialized in the sameexecution order at all sites. In this protocol, becauselocal operations are executed immediately without anyrestriction, local response is good and concurrent workis supported. However, an undesirable effect of thisprotocol is that every undo/do/redo process reflects anannoying flash on the user interface.

Our solution is to emulate serialized effect althoughoperations are not actually executed sequentially in thesame order at all sites. Like the undo/do/redo proto-col, local operations are executed immediately withoutany restriction, therefore local response is good andconcurrent work is supported. When a remote opera-tion arrives out of order, the repairing mechanism issubstantially different from undo/do/redo, which doesnot serialize operations to be executed in the same or-der but still achieve the serialized effect. Furthermore,unlike the undo/do/redo protocol, the repairing mech-anism does not cause flashes on the user interface.

The proposed solution is based on the operationaltransformation technology[23]. Briefly speaking, lo-

cal highlighting operations are executed immediately.When a remote highlighting operation arrives in theright order, it would be executed as it is. Otherwise,it is transformed against local concurrent highlightingoperations to include their effects before execution.On the other hand, those local concurrent operationsare also transformed against this remote operation toinclude its effect. By means of transformation, the re-mote operation will be executed as if it was executedbefore local concurrent highlighting operations andlocal concurrent operations have been updated as ifthey were executed after the remote operation. To im-plement this approach, each highlighting operation istimestamped by a state vector and each site maintainsa data structure called HB (history buffer) to store ex-ecuted local and remote operations. Based on the to-tal ordering relation defined in[24], the HOSE (high-lighting operation serialization emulation) algorithmfor preserving convergence in collaborative highlight-ing is defined as follows.

Algorithm 1. HOSE(Hnew, HB)At site k, m highlighting operations have been ex-

ecuted and saved in HB= [H1, . . . , Hm]. When anew highlighting operationHnew is generated locally,it will be executed immediately as is, and then ap-pended to HB, which becomes [H1, . . . , Hm, Hnew].When a new highlighting operationHnew arrives froma remote site:

1. Scan HB from the left to the right to find the first op-eration that is totally afterHnew. If no one is found,Hnew will be executed as is and then appended toHB, which becomes [H1, . . . , Hm, Hnew]. If thehighlighting region covered byHnew overshadowshighlighting regions covered byH1, . . . , Hm, itshould be on the top layer. Therefore,OHS(Hnew)

should be replaced with the new OHRs collectedin the process of execution.

2. Otherwise, supposeHi (1 ≤ i ≤ m) is found.Hnew’s execution form EHnew is achieved bytransformingHnew against concurrent operationsin [Hi, . . . , Hm] in the way as ifHnew is to beexecuted before the list of operations.Hnew’s ex-ecution formEHnew may contain more than onehighlighting operation asHnew could be split intoa set of highlighting operations covering smallerhighlighting regions in the process of transforma-


tion. That is to say,EHnew = {H1new, . . . , Hn

new}.The list of operations in [Hi, . . . , Hm] are alsotransformed againstHnew in the way as ifHnewhas been executed before them. In brief,EHnew =transformDo(Hnew, [Hi, . . . , Hm]).

3. Finally, execute operations inEHnew = {H1new, . . . ,

Hnnew}, and then insertHnew into HB at the position

before Hi, which then becomes [H1, . . . , Hi−1,

Hnew, Hi, . . . , Hm].

The transformDo(H, L) function returnsH ’s ex-ecution form by including the effects of concurrentoperations in the listL in such a way as ifH was ex-ecuted before the list of operations inL. On the otherhand, the list of operations inL also take into accountH ’s effect as if the list of operations inL were exe-cuted afterH .

Function 1. TransformDo(H, L): EH

{ EH = {H};for (j = 0; j < sizeof(L); j++){ EH′ = {};

for (k = 0; k < sizeof(EH); k++){ EH′ += IT EH(EH[k], L[j]);

if T(H) == HltIT HH(L[j], EH[k]);

else if T(H) == UhltIT HU(L[j], EH[k]);

}EH = EH′;

}return EH;

}The transformation functionIT EH(H1, H2) is to

achieveH1’s execution form by inclusively transform-ing operationH1 against operationH2. The highlight-ing region covered byH1 and overshadowed byH2 isremoved fromH1 in order to emulate the effect thatH1was executed beforeH2. After transformation,H1’sexecution form could consist of 0, 1, or 2 highlightingoperation(s).

Function 2. IT EH(H1, H2): {Hi1|i = 0, 1, 2}

{ if T(H1) == Hlt{ {〈Pi, Li〉|i = 0, 1, 2}

= Transform-EH(P(H1), N(H1), H2);switch (sizeof({〈Pi, Li〉|i = 0, 1, 2}))

{ case 0: return {};break;

case 1: return {H11 =

Hlt[P1, L1, OHS(H1)]};break;

case 2: return {H11 =

Hlt[P1, L1, OHS(H1)], H21 =

Hlt[P2, L2, OHS(H1)]};break;

}} else if T(H1) == Uhlt{ OHSnew = {};

for (j = 0; j < sizeof(OHS(H1)); j + +)

{ OHR = OHS(H1)[j];{〈Pi, Li〉|i = 0, 1, 2} =Transform-EH(OHR.S, OHR.L,H2);switch (sizeof({〈Pi, Li〉|i = 0, 1, 2})){ case 0: break;

case 1: OHSnew +={〈P1, L1, OHR.C〉};break;

case 2: OHSnew +={〈P1, L1, OHR.C〉,〈P2, L2, OHR.C〉};break;

}}return {H1

1 = Uhlt[P(H1),N(H1), OHSnew]};

}}

Function 3. Transform-EH(P, L, H): {〈Pi, Li〉|i =0, 1, 2}

{ if P ≤ P(H) and P + L ≤ P(H) + N(H)

return {〈P, P(H) − P〉};else if P ≥ P(H) and P + L ≤ P(H) + N(H)

return {};else if P ≥ P(H) and P + L ≥ P(H) + N(H)

return {〈P(H) + N(H),P + L − P(H) − L(H)〉};

else if P ≤ P(H) and P + L ≥ P(H) + N(H)

return {〈P, P(H) − P〉, 〈P(H) + N(H),P + L − P(H) − L(H)〉};

elsereturn {〈P, L〉};

}


The transformation algorithm ITHH(H2, H1)

transforms a highlightingH2 against another high-lighting H1 in such a way thatH1’s effect is includedin H2 in order to emulate the effect thatH2 is executedafterH1.

Procedure 1. IT HH(H2, H1)

{ for (i = 0; i <sizeof(OHS(H2)); i++){ OHR = OHS(H2)[i];

if P(H1) ≤ OHR.S andP(H1) + N(H1) ≤ OHR.S+ OHR.L{ OHS(H2)+ = {〈OHR.S,

P(H1) + N(H1)− OHR.S,C(H1)〉};OHR.S = P(H1) + N(H1);OHR.L = OHR.S+ OHR.L−(P(H1) + N(H1));

} else if P(H1) ≤ OHR.S andP(H1) + N(H1) ≥ OHR.S+ OHR.L

OHR.C= C(H1);else if P(H1) ≥ OHR.S andP(H1) + N(H1) ≥ OHR.S+ OHR.L{ OHS(H2)+ = {〈P(H1),

OHR.S+ OHR.L − P(H1), C(H1)〉};OHR.L = P(H1) − OHR.S;

} else if P(H1) ≥ OHR.SandP(H1) + N(H1) ≤ OHR.S+ OHR.L{ OHS(H2)+ = {〈P(H1), N(H1), C(H1)〉,

〈P(H1) + N(H1), OHR.S+ OHR.L−(P(H1) + N(H1)), OHR.C〉};OHR.L = P(H1) − OHR.S;

}}

}

The transformation algorithm ITHU(H2, H1)

transforms a highlighting operationH2 against theinverse of a highlighting operationH1 in order to ex-cludeH1’s effect fromH2. This function is designedto support undo of the highlighting operationH1.

Procedure 2. IT HU(H2, H1)

{ /∗find the OHR in OHS(H2) that storesH1’s information∗/for (i = 0; i <sizeof(OHS(H2)); i++){ if P(H1) ≤ OHS(H2)[i].S and

OHS(H2)[i].S + OHS(H2)[i].L ≤ P(H1) +N(H1)

and OHS(H2)[i].C = C(H1)

{OHR2 = OHS(H2)[i];break;

}}/∗removeH1’s information fromH2 andincorporate OHS(H1) into OHS(H2)∗for (j = 0; j <sizeof(OHS(H1)); j++){ OHR1 = OHS(H1)[j];

if OHR2.S ≤ OHR1.S andOHR2.S+ OHR2.L ≤ OHR1.S+ OHR1.L{ OHR1.L = OHR2.S +

OHR2.L − OHR1.S;OHR1.C = OHR2.C;

} else if OHR2.S ≤ OHR1.S andOHR2.S+ OHR2.L ≥ OHR1.S+ OHR1.L{ OHR1.C = OHR2.C;} else if OHR2.S ≥ OHR1.S andOHR2.S+ OHR2.L ≥ OHR1.S+ OHR1.L{ OHR1.S = OHR2.S;

OHR1.L = OHR1.S +OHR1.L - OHR2.S;OHR1.C = OHR2.C;

} else if OHR2.S ≥ OHR1.S andOHR2.S + OHR2.L ≤ OHR1.S + OHR1.L{ OHR1.S = OHR2.S;

OHR1.L = OHR2.L;OHR1.C = OHR2.C;

}}

}

Let us demonstrate how the HOSE algorithmsolves the divergence problem inFig. 3. As shownin Fig. 6, at Site 1, after the execution ofH1, H1 =Hlt[0, 4, {〈0, 4, null〉}], HB = [H1], and charactersa, b, c, and d are highlighted in red. When remoteoperation H2 = Hlt[1, 4, {〈1, 4, null〉}] arrives, itwill be executed as is because it is totally afterH2.After the execution ofH2, OHS(H2) is replacedwith the newly collected OHRs. Therefore,H2 =Hlt[1, 4, {〈1, 3, red〉, 〈4, 1, null〉}], HB = [H1, H2],and charactersb, c, d, ande are highlighted in greenwhile the charactera remains highlighted in red.

At Site 2, after the execution ofH2, H2 =Hlt[1, 4, {〈1, 4, null〉}], HB = [H2], and charactersb, c, d, ande are highlighted in green. When the re-mote operationH1 arrives, because it is totally before


H2, its execution formEH1 = IT EH(H1, H2) ={Hlt[0, 1, {〈0, 4, null〉}]} and H2 is updated withIT HH(H2, H1) = Hlt[1, 4, {〈1, 3, red〉, 〈4, 1, null〉}].After the execution of the highlighting operationin EH1 = {Hlt[0, 1, {〈0, 4, null〉}]}, charactera ishighlighted in red while other characters remainhighlighted in green.

To reminder the user at Site 2 thatH1’s intentionis actually to highlight charactersa, b, c, andd ratherthan only charactera in red, charactersb, c, d wouldbe rotated from being highlighted in red and greenfor a while for visualizing the effect that charactersb, c, d were initially highlighted in red but finallyhighlighted in green by another highlighting operation.The paper[18] has a detailed description on thedisplayrotation technique to achieve the visualization effect.After the execution ofEH1, highlighting operationH1is inserted into HB at the position beforeH2, whichthen becomes [H1, H2]. As shown inFig. 6, afterH1andH2 have been both executed at both sites, Sites 1and 2 are convergent.

3.3. Intention violation

As shown inFig. 7, consider a document containscharactersa, b, c, d, ande, replicated at two sites. Site1 performs a deleting operationE = Del[1, 1, a] todelete the character at position 1, which is charactera.

Site1 Site2abcde abcde

abcde

abcde

redg reen

H1=Hlt [0,4,{<0,4,null>}]

H2=Hlt [1,4,{<1,4,null>}]

EH1=IT_EH(H 1,H2)= {Hlt [0,1,{<0,4,null>}]}H2 = IT_HH(H2 ,H1)= Hlt [1,4,{<1,3,red >,<4,1,null>}]

EH2= {H2}={Hlt [1,4,{<1,3,red >,<4,1,null>}]}

HB= [H1]

HB= [H1 ,H 2]

HB= [H2]

HB= [H1 ,H 2]

abcde

abcde

Fig. 6. The HOSE algorithm for preserving convergence.


bcde

red green

E=Del [0,1,a] H = Hlt [1,3,{<1,3,null>}]

abcde

bcdebcde

Fig. 7. An example of intention violation.

Site 2 concurrently performs a highlighting operationH = Hlt[1, 3, {〈1, 3, null〉}] to highlight charactersb,c, and d in green. At Site 1, after the execution ofE, the document text is changed to bebcde. Whenthe remote highlightingH arrives and is executed,charactersc, d, ande would be highlighted in green,which apparently violatesH ’s intention to highlightcharactersb, c, andd in green.

Highlighting operations have no impact on thedocument text, therefore they have no impact on textinserting/deleting operations. However, text insert-ing/deleting operations make changes to the documenttext, therefore they may have impact on highlight-ing operations. The root of the problem inFig. 7is the deleting operationE has changed the docu-ment text on which the highlighting operationH wasoriginally defined. Concurrent text inserting/deletingoperations may prevent a highlighting operation frompreserving its intention. To preserve the intentions ofhighlighting operations in the presence of concurrenttext inserting/deleting operations, highlighting oper-ations should include the effects of concurrent textinserting/deleting operations in the following ways:

• When the inserting/deleting operation is an insertionoperation:1. if it is performed at the left side of a highlighting

region covered by a highlighting operation, thehighlighting region shifts to the right;

2. if it is performed within a highlighting regioncovered by a highlighting operation, the high-lighting region expands;

3. if it is performed at the right side of a high-lighting region covered by a highlighting


operation, it has no impact on the highlightingregion.

• When the inserting/deleting operation is a deletionoperation:1. If it is performed at the left side of a highlighting

region covered by a highlighting operation:◦ if the deleting region covered by the dele-

tion operation does not overlap with thehighlighting region, the highlighting regionshifts to the left;

◦ otherwise the highlighting region is trimmedoff from the left.

2. If it is performed within a highlighting regioncovered by a highlighting operation:

◦ if the deleting region totally falls into thehighlighting region, the highlighting regionshrinks;

◦ otherwise the highlighting region is trimmedoff from the right.

3. If it is performed at the right side of a highlight-ing region covered by a highlighting operation,it has no impact on the highlighting region.

Based on the above analysis, the transformationfunctionsIT HI(H, E) andIT HD(H, E) are definedto inclusively transform a highlighting operationHagainst an inserting operation and a deleting opera-tion E in such as way that the execution form ofthe highlighting operationH have taken into accountthe effect of the concurrent inserting/deleting opera-tion E.

Procedure 3. IT HI(H, E)

{ if P(E) ≤ P(H)

{ P(H)+ = N(E);for (i = 0; i <sizeof(OHS(H)); i++)

OHS(H)[i].S+ = N(E);} else if P(E) < P(H) + N(H)

{ N(H)+ = N(E);for (i = 0; i <sizeof(OHS(H)); i++)

if P(E) ≤ OHS(H)[i].SOHS(H)[i].S+ = N(E);

else if P(E) ≤ OHS(H)[i].S+OHS(H)[i].LOHS(H)[i].L+ = N(E);

}}

Procedure 4. IT HD(H, E)

{ Transform-HD(P(H), N(H), E);for (i = 0; i <sizeof(OHS(H)); i++)

Transform-HD(OHS(H)[i].S,OHS(H)[i].L, E);

}

Procedure 5. Transform-HD(P, L, E)

{ if P(E) + N(E) ≤ P

P− = N(E);else if P(E) < P and P(E) + N(E) < P + L

L = P + L − P(E) − N(E);else if P(E) ≥ P and P(E) + N(E) ≤ P + L

L− = N(E);else if P(E) ≤ P and P(E) + N(E) ≥ P + L

{ P = P(E);L = 0;

} else if P(E) ≥ P and P(E) + N(E) ≥ P + L

L = P(E) − P ;}

For the example inFig. 7, when the remote high-lighting operationH arrives at Site 1, it cannot beexecuted as is. Instead, as shown inFig. 8, its execu-tion form EH should be achieved by transformingH

against the local concurrent editing operationE, thatis EH = IT HD(H, E) = Hlt[0, 3, {〈0, 3, null〉}]. Af-ter the execution of EH, charactersb, c, and d arehighlighted in green, which correctly preservesH ’sintention.

Two transformation functions ITHI and IT HD arenot enough to completely solve the intention violation


bcde

bced

red green

E = Del [0,1,a] H = Hlt [1,3,{< 1,3,null>}]

EH = IT_HD (H,E) =Hlt [0,3, {<0,3,null>}]

abcde

bcde

Fig. 8. Transformation to solve the intention violation problem.


Site 1 Site 2abc abc

xyabc

xyc

c

xyabc

xyc

red green

E1= Del [0,2,ab] E2= Ins [0,2,xy]

E2= IT_ID(E2,E1)=Ins [0,2,xy]

H = Hlt [0,2,{<0,2,null>}]

E1= IT_DI(E1,E2)= Del [2,2,ab]

H= IT_HD(H, E1) = Hlt[0,1,{<0,1,null>}]

HB= [E1] HB= [E2]

HB= [E2 ,H ]

HB= [E1,E 2]

HB= [E2,H ,E 1]

HB= [E1 ,E 2,H ] xyc

Fig. 9. Another example of intention violation.

problem. Look at the example shown inFig. 9, wherea document initially contains charactersa, b, andc,replicated at two sites, Sites 1 and 2. Site 1 performs adeleting operationE1 = Del[0, 2, xy] to delete charac-tersa andb. Site 2 concurrently performs two sequen-tial operationsE2 = Ins[0, 2, xy] to insert charactersx and y at the beginning of the document andH =Hlt[0, 3, {〈0, 3, null〉}] to highlight charactersx andy

(just inserted byE2) and charactera.At Site 1, after the execution of local editing op-

eration E1, charactersa and b are deleted and thedocument contains only characterc. When the remoteediting operationE2 arrives, it must be transformedagainst the local concurrent editing operationE1 be-fore execution in order to includeE1’s effect[23]. Thatis, E2 = IT ID(E2, E1) = Ins[0, 2, xy]. After the ex-ecution of the transformedE2, charactersx andy areinserted at the beginning of the document, which thencontains charactersx, y, andc. When the remote high-lighting operationH arrives, it should be transformedagainst local concurrent editing operationE1. Thatis, H = IT HD(H, E1) = Hlt[0, 1, {〈0, 1, null〉}].When the transformedH is executed, only char-acter x is highlighted, which apparently violatesH ’s intention of highlighting both charactersx andy.

The root of this problem is concurrent insert-ing/deleting and highlighting operations may be gen-

erated on different document states, resulting in theirparameters not directly comparable. As a result, sim-ply applying IT HI and IT HD transformation func-tions to transform a highlighting operation againstconcurrent inserting/deleting operations may not pro-duce correct results. In this example, simply applyingIT HD(H, E1) would lead to a wrong execution formfor the highlighting operationH because the precon-dition imposed for the IT transformation[24] thatH and E1 must be defined on the same documentstate was not satisfied. The deleting operationE1 wasdefined on the document state containing charactersa, b, and c while the highlighting operationH wasdefined on the document state containing charactersx, y, a, b, andc.

Sun et al.[24] have addressed the similar issue incontrolling the transformation of inserting/deleting op-erations in real-time collaborative editing. The basicidea is to ensure the satisfaction of the preconditionfor every IT transformation. For example, to ensurethe correctness of the transformationIT(Oa, Ob) inthe face thatOa andOb were not defined on the samedocument state,Ob would be inclusively and/or exclu-sively transformed against other operations to achievethatOb is defined on the same document state as thaton whichOa was defined. Both the GOT (generic oper-ational transformation) algorithm[24] and the GOTO(GOT optimized) algorithm[23] can be used to tacklethis issue. Because the GOTO algorithm is the opti-mized version of the GOT algorithm, the followingintroduces the GOTO algorithm and how to solve theintention violation problem by means of the algorithm.

Algorithm 2. GOTO(Onew, HB): O′new At site k,

HB = [E1, . . . , Em] storesm executed editing op-erations. When a new highlighting or editing op-eration Onew is generated locally, it will be exe-cuted as is and appended to the HB, which becomes[E1, . . . , Em, Onew]. When a remote operationOnewarrives:

1. Scan HB[1,m] from left to right to find the firstoperation that is concurrent withOnew. If no suchoperation is found,O′

new = Onew.2. Otherwise, supposeEk is found. Then scan

HB[k+1, m] to find operations causally beforeOnew. If no single such operation is found,Onew’sexecution form is achieved by transformingOnew


against operations in HB[k, m], that is O′new =

LIT(Onew, HB[k, m]).3. Otherwise, let [EC1, . . . , ECr ] be the list of oper-

ations in HB[k+1, m], which are causally beforeOnew. The list of operations [EC1, . . . , ECr ] aretransformed and shifted (with theLTranspose(L)procedure) to the position beforeEk.

for (i = 1; i <r; i++)LTranspose(HB[k + i − 1, Ci]);

After then, operations that are causally beforeOneware placed beforeEk while operations that are con-current withOnew are placed afterEk. Onew’s ex-ecution formO′

new is then achieved by transform-ing Onew against operations in HB[k + r, m], thatis O′

new = LIT(Onew, HB[k + r, m]).

Function 4. LIT (O, L): O′

{ for (i = 0; i <sizeof(L); i++)IT(O, L[i]);

return O;}

Procedure 6. Transpose(Oa, Ob)

{ ET(Ob, Oa);IT(Oa, Ob);

}

Procedure 7. LTranspose(L)

{ for (k = sizeof(L); k > 1; k−){ /∗ transform∗/

Transpose(L[k − 1], L[k]);/∗ shift ∗/O = L[k];L[k] = L[k − 1];L[k − 1] = O;

}}

For the example inFig. 9, when the remote insert-ing operationE2 arrives at Site 1, as shown inFig. 10,GOTO(E2, HB) is executed to determineE2’s execu-tion form E′

2. E1 is the only operation in HB, whichis concurrent withE2, so E′

1 = IT ID(E2, E1) =Ins[0, 2, xy]. After the execution ofE′

2, charactersx

Site 1 Site 2abc abc

xyabc HB = [

xyc

c

xyabc

xyc

red green

E1= Del [0,2,ab]E2= Ins [0,2,xy]

GO TO(E 2 ,H B):E'

2 = IT_ID(E2,E1) =Ins [0,2,xy]

H = Hlt [0,3,{<0,3, null>}]

GO TO (E1,HB):E'

1= IT_DI (E1,E2)= Del [2,2,ab]

GO TO (H,HB):E2 =ET_ID(E'

2 ,E1)=Ins [0,2,xy]E'1 = IT_DI(E1 ,E2)=De l[2,2,ab]H' = IT_HD(H,E '

1)=Hlt [0,2,{<0,2,null>}]

HB= [E1]E2]

HB= [E2 ,H]HB=[ E1,E

'2]

HB= [E2 ,H,E'1]

HB= [E2,E '1,H'] xyc

Fig. 10. The GOTO algorithm to solve the intention violationproblem.

andy are inserted at the beginning of the document,which then contains charactersx, y, andc.

When the remote highlighting operationH arrivesat Site 1,GOTO(H , HB) is executed as follows todetermineH ’s execution formH ′. Firstly, scan HB=[E1, E′

2] to find the first editing operation that is con-current withH , which should beE1. Secondly, scan[E′

2] to find the first operation that is causally be-fore H , which should beE′

2. Thirdly, transform andshift E′

2 to the left of E1 to re-order HB in such away that operations that are causally beforeH areplaced on the left while operations that are concur-rent with H are placed on the right. That is, HB=[E2, E′

1], whereE2 = ET ID(E′2, E1) = Ins[0, 2, xy]

andE′1 = IT DI(E1, E2) = Del[2, 2, ab] [24].

Finally, H ’s execution formH ′ is achieved bytransformingH against the local concurrent delet-ing operationE′

1, that is H ′ = IT HD(H, E′1) =

Hlt[0, 2, {〈0, 2, null〉}]. After the execution ofH ′,charactersx and y are highlighted, which correctlypreservesH ’s intention in the presence that charactera was deleted by the local operationE1.


3.4. An integrated consistency maintenancealgorithm

Based on the HOSE algorithm for preserving con-vergence and the GOTO algorithm for preservingintention, an integrated algorithm named PICOT(preserving intention and convergence by operationaltransformation) is devised to preserve both intentionand convergence in the presence of the mixture ofinserting, deleting, and highlighting operations.

Algorithm 3. PICOT(Onew, HB): EOnewAt site k, HB = [O1, . . . , Om] storesm executed

operations. When a new operationOnew is generatedlocally, it will be executed as is and appended to theHB, which then becomes [O1, . . . , Om, Onew]. Whena remote operationOnew arrives:

• If Onew is an inserting/deleting operation:1. Scan HB[1, m] from left to right to find the first

inserting/deleting operation that is concurrentwith Onew. If no such operation is found,O′

new =Onew.

2. Otherwise, supposeOk is found. Then scanHB[k + 1, m] to find inserting/deleting op-erations causally beforeOnew. If no sin-gle such operation is found,Onew’s execu-tion form is achieved by transformingOnewagainst operations in HB[k, m], that is O′

new =LIT(Onew, HB[k, m]).

3. Otherwise, let [OE1, . . . , OEr ] (1 ≤ E1, . . . , Er ≤m) be the list ofinserting/deleting operationsin HB[k + 1, m], which are causally beforeOnew. The list of inserting/deleting operations[OE1, . . . , OEr ] are transformed and shifted(with the LTranspose(L) procedure) to the po-sition beforeOk.

for (i = 1; i < r; i++)LTranspose(HB[k + i − 1, Ei]);

After then,inserting/deleting operations that arecausally beforeOnew are placed beforeOk whileinserting/deleting operations that are concurrentwith Onew are placed afterOk. Onew’s execu-tion formO′

new is then achieved by transformingOnew against operations in HB[k + r, m], that isO′

new = LIT(Onew, HB[k + r, m]).4. EOnew = O′

new. After the execution ofEOnew,O′

new is appended into HB.

• If Onew is a highlighting operation:

1. Suppose [OE1, . . . , OEl] be the list of insert-

ing/deleting operations in HB. Transform andshift (with theLTranspose(L) procedure) the listof inserting/deleting operations [OE1, . . . , OEl

]to the left side of HB.

for (i = 1; i < l; i++)LTranspose(HB[i, Ei]);

After this step, all inserting/deleting operationsare on the left side of HB while all highlightingoperations are on the right side of HB, whichlooks like [OE1, . . . , OEl

, OH1, . . . , OHr ],where [OE1, . . . , OEl

] (1 ≤ E1, . . . , El ≤m) are inserting/deleting operations and[OH1, . . . , OHr ] (1 ≤ H1, . . . , Hr ≤ m andH1, . . . , Hr �= E1, . . . , El) are highlighting op-erations.

This is anessential step because it is after thisstep that all highlighting operations would be de-fined on the document text same as that on whichOnew was defined. As a result, the parameters ofhighlighting operations in HB are directly com-parable withOnew’s parameters in doing ITEHand IT HH transformations.

2. O′new = GOTO(Onew, [OE1, . . . , OEl

]) andEOnew = HOSE(O′

new, [OH1, . . . , OHr ]).3. After the execution of highlighting operations

in EOnew, O′new is inserted into [OH1, . . . , OHr ]

at the position beforeOHk, whereOHk

is firstoperation that is totally afterOnew.

To cope with the mixture of inserting, deleting, andhighlighting operations in HB, some empty transfor-mation functions are defined as follows.

Procedure 8. IT IH(E, H) {}: Inclusively transform-ing an inserting operationE against a highlighting op-erationH .

Procedure 9. IT DH(E, H) {}: Inclusively transform-ing a deleting operationE against a highlighting op-erationH .

Procedure 10. ET IH(E, H) {}: Exclusively trans-forming an inserting operationE against a highlight-ing operationH .



acde

red green

E1 = Del [1, 1, b] E2 = Del [3, 1, d]

H1 = Hlt [0, 3, {<0, 3, null>}]

HB = [E1]

acdeHB = [E1, H 1]

HB = [E2 , H 2 , E'1]aceHB = [E1 , H 1 , E '

2]

H2 = Hlt [2, 2, {<2, 2, null>}]

abce HB = [E2 , H 2]

abce HB = [E2]

EE1 = PICOT(E1 , HB ):

EE1 = E '1 = GOTO (E1 , HB) = IT_DD(E 1, E 2) = Del [1, 1, b]

EE2 = PICOT(E2 , HB ):

EE2 = E '2 = GOTO(E2 , HB) = IT_DD(E 2 , E 1) =

Del [2, 1, d]

aceHB = [E2 , E '1 , H '

1 , H '2 ]

EH1 = PICOT(H 1 , HB ):

1. HB = [E2 , E '1 , H

'2]

H'2 = IT_HD(H 2 , E

'1) = Hlt [1, 2, {<1, 2, null>}]

2. H '1 = GOTO (H1 , [E2 , E '

1]):

E1 = ET_DD (E'1 , E 2) = Del [1, 1, b]

E'2 = IT_DD(E2 , E 1) = Del [2, 1, d]

H'1 = IT_HD(H 1 , E '

2)= Hlt [0, 2, {<0, 2, null>}]

3. EH 1 = HOSE(H'1 , [H

'2]):

EH1 = IT_EH(H '1 , H

'2) = {Hlt [0, 1, {<0, 2, null>}]}

H'2 = IT_HH(H '

2 , H'1) = Hlt [1, 2, {<1, 1, red>, <2, 1, null>}]

HB = [E1 , E '2 , H '

1 , H '2 ]

ace

EH2 = PICOT(H 2 , HB ):

1. HB = [E1 , E '2 , H

'1]

H'1 = IT_HD(H 1 , E

'2) = Hlt [0, 2, {<0, 2, null>}]

2. H '2 = GOTO(H 2 , [E1 , E '

2 ]):

E2 = ET_DD(E'2 , E 1) = Del [3, 1, d]

E'1 = IT_DD(E1 , E 2) = Del [1, 1, b]

H'2 = IT_HD(H 1 , E '

1) = Hlt [1, 2, {<1, 2, null>}]

3. EH 2 = HOSE(H '2 , [H

'1]):

EH2 = {H '2}= {Hlt [1, 2, {<1, 1, red>, <2, 1, null>}]}

ace

Fig. 11. The PICOT algorithm to preserve both intention and convergence.

Procedure 11. ET DH(E, H) {}: Exclusively trans-forming a deleting operationD against a highlightingoperationH .

The example shown inFig. 11 is to demonstratehow the algorithm works. Consider a document ini-tially contains charactersa, b, c, d, ande, replicatedat two sites, Sites 1 and 2. Site 1 performs a deletingoperationE1 = Del[1, 1, b] to delete the character atposition 1 (i.e., characterb) followed by a highlight-ing operationH1 = Hlt[0, 3, {〈0, 3, null〉}] to high-light three characters starting from position 0 (i.e.,charactersa, c, andd) in red. Site 2 concurrently per-forms two operations with a deleting operationE2 =Del[3, 1, d] to delete the character at position 3 (i.e.,characterd) and a subsequent highlighting operationH2 = Hlt[2, 2, {〈2, 2, null〉}] to highlight two charac-

ters starting from position 2 (i.e., charactersc ande)in green.

At Site 1, after the execution of local operationsE1andH1, the document contains charactersa, c, d, ande with charactersa, c, andd highlighted in red, andHB = [E1, H1]. When the remote editing operationE2 arrives,PICOT(E2, HB) is executed to determineE2’s execution formEE2. BecauseE1 is the onlyin-serting/deleting operation in HB, which is concur-rently with E2. E′

2 = IT DD(E2, E1) = Del[2, 1, d].After the execution ofEE2 = E′

2, the character atposition 2 (i.e., characterd) is deleted, and HB=[E1, H1, E′

2].When the remote highlighting operationH2 ar-

rives, PICOT(H2, HB) is executed as follows todetermine H2’s execution form EH2. Firstly, re-order HB to make all inserting/deleting operations


on the left side and all highlighting operations onthe right side by repeating theLTranspose proce-dure. After then, HB= [E1, E′

2, H ′1], where H ′

1 =IT HD(H1, E′

2) = Hlt[0, 2, {〈0, 2, null〉}]. Secondly,H ′

2 = GOTO(H2, [E1, E′2]). The list [E1, E′

2] is firstreordered as [E2, E′

1] whereE2 = ET DD(E′2, E1) =

Del[3, 1, d] andE′1 = IT DD(E1, E2) = Del[1, 1, b].

Then H ′2 is achieved by transformingH2 against

the concurrent deleting operationE′1, that is H ′

2 =IT HD(H2, E′

1) = Hlt[1, 2, {〈1, 2, null〉}]. H ′2’s exe-

cution formEH2 is determined byHOSE(H ′2, [H ′

1]).BecauseH ′

2 is totally afterH ′1, EH2 = {H ′

2}. Finallyafter the execution of the highlighting operation inEH2, charactersc ande are highlighted in green whilecharactera remains highlighted in red, andOHS(H ′

2)is updated to be{〈1, 1, red〉, 〈2, 1, null〉}. Then H ′

2is inserted into HB at the position afterH ′

1, whichbecomes [E2, E′

1, H ′1, H ′

2].At Site 2, after the execution of local operations

E2 andH2, the document contains charactersa, b, c,and e with charactersc and e highlighted in green,and HB= [E2, H2]. When the remote deleting opera-tion E1 arrives,PICOT(E1, HB) is executed to deter-mineE1’s execution formEE1. BecauseE2 is the onlyinserting/deleting operation in HB, which is concur-rently with E1. E′

1 = IT DD(E1, E2) = Del[1, 1, b].After the execution ofEE1 = E′

1, the character atposition 1 (i.e., characterb) is deleted, and HB=[E1, H1, E′

1].When the remote highlighting operationH1 ar-

rives, PICOT(H1, HB) is executed as follows todetermine H1’s execution form EH1. Firstly, re-order HB to make all inserting/deleting operationson the left side and all highlighting operations onthe right side by repeating theLTranspose pro-cedure. After then, HB = [E2, E′

1, H ′2], where

H ′2 = IT HD(H2, E′

1) = Hlt[1, 2, {〈1, 2, null〉}].Secondly, H ′

1 = GOTO(H1, [E2, E′1]). The list

[E2, E′1] is first reordered as [E1, E′

2] whereE1 = ET DD(E′

1, E2) = Del[1, 1, b] and E′2 =

IT DD(E2, E1) = Del[2, 1, d]. Then H ′1 is achieved

by transforming H1 against the concurrent delet-ing operationE′

2, that is H ′1 = IT HD(H1, E′

2) =Hlt[0, 2, {〈0, 2, null〉}]. H ′

1’s execution form EH1is determined byHOSE(H ′

1, [H ′2]). BecauseH ′

1is totally before H ′

2, EH1 = IT EH(H ′1, H ′

2) ={Hlt[0, 1, {〈0, 2, null〉}]}. H ′

2 is transformed againstH ′

1 to include its effect, that isH ′2 = IT HH(H ′

2, H ′1) =

Hlt[1, 2, {〈1, 1, red〉, 〈2, 1, null〉}]. Finally after theexecution of the highlighting operation inEH1, onlycharactera is highlighted in red while characterc ande remain highlighted in green. ThenH ′

1 is insertedinto HB at the position beforeH ′

2, which becomes[E1, E′

2, H ′1, H ′

2].If the highlighting operationH2 were not moved

to the position afterE′1, the result would be wrong.

In that case,H2 = Hlt[2, 2, {〈2, 2, null〉}], EH1 =IT EH(H ′

1, H2) = {Hlt[0, 2, {〈0, 2, null〉}]}. Afterthe execution ofEH1, charactersa and c would behighlighted in red, which is wrong becauseH1 shouldnot overshadow the highlighting region covered byH2 that is totally afterH1. The reason isH ′

1 andH2 are defined on different document texts, thereforetheir parameters are not directly comparable.H ′

1 isdefined on the document that contains charactersa,c, and e while H2 is defined on the document thatcontains charactersa, b, c, ande.

4. Flexible undo solution

Most single-user editors have undo facilities to undohighlighting operations mainly for recovering errors.In multi-user collaborative editors, this facility is nat-urally needed and even more valuable because besideserror recovering, undo is necessary for changing fo-cuses during a discussion[18]. To change the focusduring a discussion, old highlights should be undoneand new highlights need to be created.

Only chronological undo of highlighting operationsis available in single-user editors. But chronologicalundo is too restrictive to be used in multi-user collab-orative editors because the flow of changing focusesduring a discussion is not structured chronologically,which is actually arbitrary subject to the nature ofthe discussion topic and the thinking style of everyparticipant. We think selective undo[3,13,21]is mostsuitable for the undo of highlighting operations inmulti-user collaborative editors because it can supportundo of any operation at any time.

Generally speaking, to correctly undo a highlight-ing operation, the effect of the undone operationH

must be removed from the document while the effectsof all other operations must be maintained. Chrono-logical undo is easy to achieve becauseH must be themost recent operation. That is to say, all operations


executed afterH must have been undone. Therefore,simply executingH ’s inverse would removeH ’s effectwhile the effects of other operations are kept. Howeverit is non-trivial to achieve selective undo of highlight-ing operations even in single-user editors because thecurrent highlighting regions in the document could bedifferent from those whenH was created. There couldbe some operations executed afterH and simply exe-cutingH ’s inverse may not produce the correct result.In multi-user collaborative editors, the mixture of con-current do and undo of inserting, deleting, and high-lighting operations makes selective undo even morecomplicated.

We propose the SUIT (selective undo by inclusivetransformation) algorithm that can be used to supportselective undo of any operation at any time. In brief,to undo an operationO at a site, the following stepswill be executed. Firstly, makeO’s inverse operationO. Secondly,O cannot be executed as is. Instead, itsexecution formEO should be achieved by transform-ing O against operations situated afterO in HB. Fur-thermore, those operations that are situated afterO inHB should be transformed againstO to excludeO’seffect.

Thirdly, by executingEO, O’s effect is removedwhile the effects of all other operations are preserved.Finally, if the undo is initiated locally, the undo com-mand carryingO’s ID rather thanEO itself is propa-gated to remote sites. There are two reasons for doingthis. One is a remote site normally has a different HB,which may result inEO derived in terms of the localHB not applicable to the remote site. The other is thatdirect execution ofEO at a remote site could alterthe effect of concurrent operations at that site becausethe derivation ofEO has no knowledge of these con-current operations. ThereforeO’s ID is propagated toa remote site, whereO’s execution formEO will bederived.

Algorithm 4. SUIT(Id(O), HB): EO

At site k, HB[1, m] storesm executed operations.To undo the operation whose ID= Id(O) in HB:

1. Find operationO with a matchingId(O) in HB.Suppose HB[i] = O (1 ≤ i ≤ m).

2. If O is an inserting/deleting operation, that isT(O) == Ins/Del, the ANYUNDO algorithm[22] for supporting selectively undoing any in-

serting/deleting operation in a HB can be directlyapplied to the undo ofO as follows:(a) MakeO’s inverse operationO = makeInverse

(O).(b) O’s execution form EO is achieved by

transforming O against the list of opera-tions in HB[i + 1, m]. The list of opera-tions in HB[i + 1, m] are transformed againstO to exclude O’s effect. In brief, EO =LIT Transpose(O, HB[i + 1, m]).

3. If O is a highlighting or the inverse of a highlightingoperation, that isT(O) == Hlt/Uhlt:(a) Suppose [OE1, . . . , OEt ] be the list ofinsert-

ing/deleting operations in HB[i, m]. Trans-form and shift (with theLTranspose(L) pro-cedure) the list of operations [OE1, . . . , OEt ]to the left of HB[i]:

for (k = 1; k <t; k++);LTranspose(HB[i + k − 1, Ek]).

After then, there is no inserting/deleting oper-ation afterO in HB. In other words, HB[i, m]are all highlighting operations.

(b) MakeO’s inverse operationO = makeInverse(O).

(c) EO = transformDo(O, HB[i + 1, m]). (Thefunction defined in the HOSE algorithm inSection 3.)

4. ExecuteEO.5. Mark O and O as a do–undo pair. Concretely

speaking, if HB = [O1, . . . , Oi, . . . , Om],when Oi has been undone, HB would become[O1, . . . , O∗

i , . . . , Om], whenOi has been redone,HB would become [O1, . . . , Oi, . . . , Om] again.

6. Finally, if the undo is initiated locally,Id(O) willbe propagated to remote sites.

Transforming and shiftinginserting/deleting oper-ations on the right side of the highlighting operationto be undone to its left side in the HB isessential forthe SUIT algorithm to correctly undo a highlightingoperation. The spirit behind this is that theEH1 =IT EH(H1, H2) transformation is a lossy transforma-tion. After transformation, highlighting regions cov-ered byEH1 are only some fragments of the originalhighlighting region covered byH1. When highlightingoperations inEH1 are to be transformed against an in-serting/deleting operation, the relation between high-lighting regions covered byEH1 and the effect region


covered by the inserting/deleting operation does notcorrectly reflect the relation between the highlightingregion covered byH1 and the effect region coveredby the inserting/deleting operation. Therefore the al-gorithm must prevent highlighting operations inEH1from being transformed against any inserting/deletingoperation.

Marking do–undo pair is another technical essen-tial in this algorithm. Firstly, it can save the memoryfor explicitly storing inverse operations and avoid thecost for timestamping inverse operations. Secondly,transforming an operationO against a list of opera-tions inL (i.e., in the LIT, LIT Transpose, and trans-formDo functions) will skip those do–undo pairs inL, which can avoid undo puzzles[22] caused by thefact that transforming an operationOa against anotheroperationOb and then its inverse operationOb maynot correctly recoverOa. Finally, it can avoid defin-ing and executing transformation functions ITUH,IT UU, IT UI, and IT UD for transforming the inverseof a highlighting operation against a highlighting op-eration, the inverse of another highlighting operation,and an inserting/deleting operation.

The followingmakeInverse(O) function makes theinverse operation of operationO:

Function 5. makeInverse(O): O

{ switch T(O)

{ case Hlt: O = Uhlt[P(O),N(O), OHS(O)];break;

case Uhlt: O = Hlt[P(O), N(O),OHS(O)];break;

case Ins: O = Del[P(O), N(O), S(O)];break;

case Del: O = Ins[P(O), N(O), S(O)];break;

}return O;

}

The LIT Transpose(O, L) function returnsO’s ex-ecution form by inclusively transformingO againstthe list of operations inL. On the other hand, the listof operations inL are transformed againstO in orderto includeO′ effect.

Function 6. LIT Transpose(O, L): EO

{ for (i = 0; i < sizeof(L); i++){ TO = IT(L[i], O);

O = IT(O, L[i]);L[i] = TO;

}}

The example shown inFig. 12demonstrates how theSUIT algorithm works. Consider a document initiallycontains charactersa, b, c, d, ande. A highlighting op-erationH1 = Hlt[0, 3, {〈0, 3, null〉}] highlights char-actersa, b, andc in red and a subsequent highlightingoperation H2 = Hlt[2, 3, {〈2, 1, red〉, 〈3, 2, null〉}]highlights charactersc, d, ande in green. Finally aninserting operationE = Ins[2, 2, xy] inserts charac-ters x and y at position 2 (i.e., between characterc

andd). Charactersx andy inserted byE fall into H1’shighlighting region, so they are highlighted in red.

Now HB = [H1, H2, E]. To selectively undoH1, ifH1’s inverse operationH1 = Uhlt[0, 3, {〈0, 3, null〉}]were directly executed as shown inFig. 12(A), char-actersa, b, and x would be dehighlighted, which iswrong because part of the highlighting region cov-eredH1 has not been undone yet (charactery is stillhighlighted in red). The reason is thatH1’s executionform EH1 did not take into account the effects ofH2and E. If H1’s execution formEH1 were achievedby transformingH1 against the list of operations in[H2, E], that isEH1 = transformDo(H1, [H2, E]) ={Uhlt[0, 3, {〈0, 2, null〉}]}, as shown inFig. 12(B), theexecution of the highlighting operation inEH1 woulddehighlight charactersa and b, which is wrong ei-ther because part of the highlighting region coveredby H1 has not been undone either (characterx andy

are still highlighted in red). The reason is that afterEH1 = IT EH(H1, H2), the highlighting region cov-ered byEH1 only contains charactersa andb, whichis only a fragment of the highlighting region coveredby H1 that contains charactersa, b, and c. Conse-quently, when the highlighting operation inEH1 isfurther transformed against the inserting operationE,it cannot identify that charactersx andy inserted byoperationE are part of the highlighting region coveredby the highlighting regionH1.

As shown inFig. 12(C), the SUIT(Id(H1), HB)algorithm, however, is able to correctly undoH1’s


H2 = Hlt [2, 3, {<2, 1, red>,<3, 2, null>}]

abcde

H1= Hlt [0, 3, {<0, 3, null>}]

abcde

E = Ins [2, 2, xy]

abycdex

HB = [H 1]

HB = [H 1 , H 2]

HB = [H 1 , H 2 , E](C) Undo H 1 (correct):

1. HB = [E, H '1 , H

'2)

H'2 = IT_HI(H 2 , E) = Hlt [4, 3, {<4, 1, red>, <5, 2, null>}]

H'1 = IT_HI(H 1 , E) = Hlt [0, 5, {<0, 5, null>}]

2. = makeInverse (H '1) = Uhlt [0, 5, {<0, 5, null>}]

3. = transform Do ( , [H '2])

= IT_EH ( , H '2) = {Uhlt [0, 5, {<0, 4, null>}]}

H'2 = IT_HU (H '

2 , ) = Hlt [4, 3, {<4, 3, null>l>}]

(B) Undo H 1 (wrong):1. = makeInverse (H1) = Uhlt [0, 3, {<0, 3, null>}] 2. = transform Do( , [H 2 , E]) = IT_EH ( , H 2) = {Uhlt [0, 3, {<0, 2, null>}]} = IT_EH ( , E) = {Uhlt [0, 3, {<0, 2, null>}]}H2 = IT_HU (H 2 , ) = Hlt [2, 3, {<2, 3, null>l>}]

1H

1HE 1H1HE 1H1HE 1HE

1H

(A) U

ndoH

1 (w

rong

)

(B) Undo H

1 (wrong)

abcdexy

HB = [E,*H'1 , H

'2)

(A ) UndoH 1 (wrong): = = makeInverse (H1) = Uhlt [0, 3, {<0, 3, null>}]1H1HE

abxycde

(C) U

ndo H1 (correct)

HB = [*H1 , H 2 , E)HB = [*H1 , H 2 , E)

red green

1'H

1'HE

1'HE

1'H

1'H

1'H

abcde

abxycde

Fig. 12. The SUIT algorithm to selectively undo a highlighting operation.

effect. Firstly, findH1 with a matching ofId(H1) inHB, which is the first operation in HB. Then transformand shift the inserting operationE to the left side ofH1 in HB. After then, HB= [E, H ′

1, H ′2], whereH ′

2 =IT HI(H2, E) = Hlt[4, 3, {〈4, 1, red〉, 〈5, 2, null〉}]and H ′

1 = IT HI(H1, E) = Hlt[0, 5, {〈0, 5, null〉}].Secondly, makeH ′

1’s inverse operationH ′1 =

makeInverse(H ′1) = Uhlt[0, 5, {〈0, 5, null〉}]. Thir-

dly, H ′1’s execution formEH ′

1 is achieved by trans-

forming H ′1 againstH ′

2, that is,EH ′1 = IT EH(H ′

1,

H ′2) = {Uhlt[0, 5, {〈0, 4, null〉}]}. On the other hand,

H ′2 is transformed againstH ′

1 to excludeH ′1’s ef-

fect, that is H ′2 = IT HU(H ′

2, H ′1) = Hlt[4, 3,

{〈4, 3, null〉}]. Finally, after the execution of the high-lighting operation inEH ′

1, charactersa, b, x, andy are all dehighlighted while charactersc, d, and e

remain highlighted in green, which is correct.H ′1

and H ′1 are marked as a do–undo pair as shown in

HB = [E, ∗H ′1, H ′

2].The SUIT algorithm is able to correctly han-

dle situations where the undo of a highlightingoperation is mixed with a concurrent highlight-ing/inserting/deleting operation, or concurrent undo ofa highlighting/inserting/deleting operation. An exam-ple is that undoing a highlighting operation is mixedwith a concurrent highlighting operation. Consider adocument contains charactersa, b, c, d, ande, repli-cated at two sites as shown inFig. 13. Site 1 performsa highlighting operationH1 = Hlt[0, 4, {〈0, 4, null〉}]to highlight charactersa, b, c, and d in red. Sub-sequently, Site 2 performs a highlighting operationH2 = Hlt[1, 4, {〈1, 3, red〉, 〈4, 1, null〉}] to high-light charactersb, c, d, ande in green. Concurrently


Site 1 Site 2

abcde abcde

abcde

abcde

red green

H1 = Hlt [0,4,{<0,4,null>}]

HB= [H1]abcde HB = [H1]

abcdeHB= [ *H1]

H2 = Hlt [1,4,{<1,3,red>,<4,1,null>}]

[H1,H2]

HB=[ *H1 ,H 2]

abcde HB= [ *H1,H2]

EH2 = PICOT(H2 ,HB)EH2 = {H2} = {H lt [1,4 ,{<1,4,null>}]}

=SUIT (Id(H1), HB) :1. =makeInverse (H1)=Uhlt [0,4,{<0,4,null>}]2. = transform Do (,[H2])

= IT_EH ( , H2) ={Uhlt [0,4,{<0,1,null>}]}H2 = I T_HU(H )2 , =Hlt [1,4,{<1,4,null>}]

1HE

1H

1HE 1H

1HE 1H

1H

Undo H1:=SUIT( Id(H1), HB)=makeInverse(H1)=

Uhlt [0,4 ,{<0,4,null>}]={ }

1HE

1H

1HE1H

abcde

Fig. 13. Undo a highlighting operation is mixed with a concurrent highlighting operation.

with H2, Site 1 issues the command of undoingH1.

At Site 1, after the execution ofH1, charactersa,b, c, and d are highlighted in red and HB= [H1].To undoH1, SUIT(Id(H1), HB) simply executesH1’sinverse operationH1 = Uhlt[0, 4, {〈0, 4, null〉}] be-causeH1 is the only operation in HB. After then,charactersa, b, c, andd are dehighlighted and HB=[∗H1]. Then the undo command carryingId(H1) ispropagated to Site 2. When the remote highlightingoperationH2 arrives,PICOT(H2, HB) simply exe-cutesH2 as is becauseH2 is totally afterH1. Afterthen, charactersb, c, d ande are highlighted in green,OHS(H2) = {〈1, 4, null〉}, and HB= [∗H1, H2].

At Site 2, after the execution ofH1 andH2, char-actera is highlighted in red, charactersb, c, d, ande are highlighted in green, and HB= [H1, H2],

where H1 = Hlt[0, 4, {〈0, 4, null〉}] and H2 =Hlt[1, 4, {〈1, 3, red〉, 〈4, 1, null〉}]. When the re-mote undo command arrives, if the undo commandwere straight carryingH1’s execution formEH1 =Uhlt[0, 4, {〈0, 4, null〉}], the execution ofEH1 woulddehighlight charactersa, b, c, and d, which is ob-viously wrong because part ofH2’s effect has beenerased. The reason is the derivation ofEH1 at Site 1had no knowledge about the concurrent highlightingoperationH2 performed at Site 2. Therefore the undocommand should carryId(H1) instead ofEH1. TheSUIT(Id(H1), HB) is executed as follows to deriveEH1 at Site 2 to undoH1. Firstly, find H1 with amatching ofId(H1) in HB, which would be the firstoperation in HB. Then makeH1’s inverse operationH1 = makeInverse(H1) = Uhlt[0, 4, {〈0, 4, null〉}].Secondly, H1’s execution form EH1 is achieved


by transforming H1 against H2, that is EH1 =IT EH(H1, H2) = Uhlt[0, 4, {〈0, 1, null〉}]. On theother hand,H2 is transformed againstH1 to ex-clude H1’s effect, that is,H2 = IT HU(H2, H1) =Hlt[1, 4, {〈1, 4, null〉}]. Finally, after the execution ofEH1, only charactera is dehighlighted while char-actersb, c, d, e remain highlighted in green, andHB = [∗H1, H2].

More examples about the SUIT algorithm handlingsituations where the undo of a highlighting oper-ation is mixed with a current operation or currentundo of another operation can be found in[20]. Forinstance, undoing a highlighting operation is mixedwith undoing another highlighting operation, undoinga highlighting operation is mixed with a concurrentinserting/deleting operation, or undoing a highlight-ing operation is mixed with concurrent undoing aninserting/deleting operation.

5. Conclusions

Highlighting is a common tool in most single-usereditors, which provides users with a mechanism ofsupporting non-real-time communication betweenthe author and readers. However, it is challenging toextend highlighting text from the single-user envi-ronment to the multi-user collaborative environmentbecause of the need for supporting group awareness,consistency maintenance, and flexible undo.

We emulate the user interface for highlighting usedin single-user editors in order to encourage users whoare used to the single-user application to learn, use andadopt the multi-user collaborative version. We use col-ors to differentiate highlights performed by differentusers to provide some sort of group awareness supportin multi-user environments. In this paper, we presentan integrated concurrency control algorithm based onthe operational transformation technology, which isable to achieve convergence and intention preservationin the presence of concurrent inserting, deleting, andhighlighting operations in real-time collaborative edit-ing systems. Selective undo is most desirable for theundo of highlighting operations in order to improvereal-time collaboration in multi-user editing systems.We contribute a flexible undo solution that is able tosupport undo of any inserting, deleting, and highlight-ing operation at any time.

Solutions for collaborative highlighting lay a foun-dation for handling update operations similar in natureto highlighting, which update attributes of text insteadof inserting or deleting text. All algorithms presentedin the paper have been implemented in the REDUCE(REal-time Distributed Unconstrained CollaborativeEditing) system[24] for supporting collaborative pro-gramming in RECIPE (REal-time Collaborative Inter-active Programming Environment)[19]. We continuevalidating the proposed algorithms by applying themto the collaborative update of attributes in rich texteditors, such as Microsoft Word.

Acknowledgements

The authors wish to thank David Chen and AguidoHoratio Davis for their valuable comments on this pa-per. The work reported in this paper has been partiallysupported by an ARC (Australian Research Council)Large Grant No. 00000711.

References

[1] R.M. Baecker, D. Nastos, I.R. Posner, K.L. Mawby, Theuser-centred iterative design of collaborative writing software,in: Proceedings of the ACM INTERCHI’93 Conferenceon Human Factors in Computing Systems, Meetings andCollaborative Writing, Amsterdam, 1993, pp. 399–405.

[2] J. Begole, M.B. Rosson, C.A. Shaffer, Flexible collaborationtransparency: supporting worker independence in replicatedapplication-sharing systems, ACM Trans. Comput.–HumanInteraction 6 (2) (1999) 95–132.

[3] T. Berlage, A selective undo mechanism for graphicaluser interfaces based on command objects, ACM Trans.Comput.–Human Interaction 1 (3) (1994) 269–294.

[4] T. Berlage, A. Genau, A framework for shared applicationswith a replicated architecture, in: Proceedings of the ACMSymposium on User Interface Software and Technology,1993, pp. 249–257.

[5] E.A. Bier, S. Freeman, Mmm: a user interface architecturefor shared editors on a single screen, in: Proceedings of theFourth Annual ACM Symposium on User Interface Softwareand Technology, 1991, pp. 79–86.

[6] D. Chen, C. Sun, Undoing any operation in collaborativegraphics editing systems, in: Proceedings of the ACM2001 International Conference on Supporting Group Work,Colorado, USA, September 2001, pp. 197–206.

[7] R. Choudhary, P. Dewan, A general multi-user undo/redomodel, in: Proceedings of the European Conference onComputer Supported Work, October 1995, pp. 231–246.


[8] P. Dourish, S. Bly, Portholes: supporting awareness ina distributed work group, in: Proceedings of the ACMCHI’92 Conference on Human Factors in ComputingSystems, Systems for Media-supported Collaboration, 1992,pp. 541–547.

[9] C.A. Ellis, S.J. Gibbs, Concurrency control in groupwaresystems, in: Proceedings of the ACM SIGMOD Conferenceon Management of Data, May 1989, pp. 399–407.

[10] S. Greenberg, C. Gutwin, A. Cockburn, Awareness throughfisheye views in relaxed-wysiwis groupware, in: Proceedingsof the Graphics Interface, Toronto, Canada, May 1996,Morgan Kaufmann, Los Altos, CA, pp. 28–38.

[11] J. Grudin, Groupware and social dynamics: eight challengesfor developers, Commun. ACM 37 (1) (1994) 92–105.

[12] L. Lamport, Time, clocks and the ordering of events in adistributed system, Commun. ACM 21 (7) (1978) 558–565.

[13] A. Prakash, M.J. Knister, A framework for undoing actionsin collaborative systems, ACM Trans. Comput.–HumanInteraction 1 (4) (1994) 295–330.

[14] M. Raynal, M. Singhal, Logical time: capturing causality indistributed systems, IEEE Comput. Mag. 29 (2) (1996) 49–56.

[15] M. Ressel, R. Gunzenhauser, Reducing the problems of groupundo, in: Proceedings of the ACM Conference on SupportingGroup Work, Pheonix, USA, November 1999, pp. 131–139.

[16] K.J. Rodham, S.R. Olsen Jr., Smart telepointers: maintainingtelepointer consistency in the presence of user interfacecustomization, ACM Trans. Graph. 13 (3) (1994) 300–307.

[17] M. Roseman, S. Greenberg, Teamrooms: network placesfor collaboration, in: Proceedings of the ACM Conferenceon Computer Supported Cooperative Work, Places forCollaboration, 1996, pp. 325–333.

[18] H. Shen, C. Sun, Collaborative highlighting for real-timegroup editors, in: Proceedings of the Second InternationalConference on Innovative Internet Computing Systems,Kühlungsborn, Germany, 2002, pp. 39–50.

[19] H. Shen, C. Sun, RECIPE: a web-based environment forsupporting real-time collaborative programming, in: Procee-dings of the International Conference on Networks, Pa-rallel and Distributed Processing, Tsukuba, Japan, 2002,pp. 283–288.

[20] H. Shen, Internet-based Collaborative Programming Tech-niques and Environments, Ph.D. Thesis, Griffith University,Brisbane, Australia, 2003.

[21] C. Sun, Undo any operation at any time in group editors,in: Proceedings of the ACM Conference on ComputerSupported Cooperative Work, Philadelphia, PA, December2000, pp. 191–200.

[22] C. Sun, Undo as concurrent inverse in group editors, ACMTrans. Comput.–Human Interaction 9 (4) (2002) 309–361.

[23] C. Sun, C.A. Ellis, Operational transformation in real-timegroup editors: issues, algorithms, and achievements, in:Proceedings of the ACM Conference on Computer SupportedCooperative Work, Seattle, USA, November 1998, pp. 59–68.

[24] C. Sun, X. Jia, Y. Zhang, Y. Yang, D. Chen, Achievingconvergence, causality-preservation, and intention-pre-servation in real-time cooperative editing systems, ACMTrans. Comput.–Human Interaction 5 (1) (1998) 3–8.

Haifeng Shen is a Ph.D. student in theSchool of Computing and InformationTechnology at Griffith University, Aus-tralia. He received his B.E. in computertechnology and applications in 1993 andM.E. in computer organization and archi-tecture in 1997 from Tianjin University,China. His research interests are in the ar-eas of Distributed Systems, Internet Com-puting, Collaborative Systems and tech-

nologies, and Software Engineering.

Chengzheng Sun is currently a Professorat the School of Computing and Infor-mation Technology in Griffith University,Australia. He obtained his Ph.D. in com-puter science and engineering from Uni-versity of Amsterdam, The Netherlands,and from National University of DefenseTechnology, China, respectively. His ma-jor areas of expertise and research inter-ests include Internet computing technolo-

gies and applications, groupware and CSCW, distributed operatingsystems and networks, mobile computing, and parallel implemen-tation of object-oriented and logic programming languages.

Improving real-time collaboration with highlighting

Documents

Transcript of Improving real-time collaboration with highlighting