30
conflictsbetweencollaborators.Thehighlymodularnatureofmostsoftwarealsoreduces
conflictssinceaprogramistypicallydividedintomanysemi-independentfiles,eachcom-
posedofmanysemi-independentunits(subroutines,methoddefinitions,datadefinitions,
etc.).
Thegranularityatwhichchangesneedtobetrackedisalsofixedandrelativelylarge,
sincethelineofcodeisanadequate,relativelyuniformunitinalmostallprogramminglan-
guages.
Documenteditors,unlikecodeeditors,mayneedtosupportcollaborationatatimescale
thatisverydifferentfromthatinsoftwaredevelopment.Real-timesharededitingisnot
easilypossibleunderacheck-in/check-outmodel,noriscommunicationbyasharedfilesys-
temnecessarilysensibleforsuchsituations.Real-timeupdatebymultipleauthorsisessen-
tiallyavariationofthemergeproblem;evensourcecodecontrolsystemslikeCVSthatsup-
portautomaticmergingarenotdesignedforthisfrequencyofupdate.Insummary,the
problemsofcollaborativedocumenteditingaresimplydifferentfromthosefacedbysoftware
engineering,despitethesimilarityoftheproblemsandpointsoftechnicaloverlap.
Someofthesedifferenceshaveeffectsonthemostappropriateunderlyingtechnologies;
line-baseddifferencealgorithmsarenotsuitablefortext(Neuwirth,Chandhoketal.1992);
mergeandselectiveundoarerelativelyinfrequentoperationsinsoftwareengineering.Oth-
ersaffecttheuserrequirements:theneedtosupportinformalaccessprotocols,andtheneed
topresentarelativelysimpleversionmodel.Ageneralframeworkshouldalsosupportawide
rangeofpoliciesforversionmanagement,underthecontroloftheapplication.Noone-
versionmanagementmodelwillservealldifferentneeds.Ibrieflyconsidersomeneedsand
approachestoversionmanagementbelow,allofwhich,ideally,shouldbeavailabletoan
applicationdesigner.TheVerSEsystemhasproposedthenotionofuserselectable
“versioningstyles”(HaakeandHicks1996)thataresupportedbyasystemontopofanin-
tegratedframeworkandthatcanevenbeadjustedasthepatternofcollaborationchanges.
31
1.9.1 Versioningandhypertext
Atthispointintime,theassumptionthattheartifactsinartifact-basedcollaborationare
hypertextorhypermediaobjectsisunexceptional.Evenifhypertextlinksarenotpartsof
theobjectsthemselves(anincreasinglyunlikelystateofaffairs),itisanearcertaintythat
hypertextlinksintotheartifactswesharearebecomingmoreandmorecommonandimpor-
tant.
Thetopicofversionmaintenancehasbeenatraditionalpartofhypertextsystemdesign
sincethefield’sinception(Engelbart1963;Nelson1987).Inthetraditionalview,versioning
ispresentedasadesirableoressentialconvenienceforahypertextauthor(Haake1991a;
Haake1991b).IndeeditisthisjustificationforversioncontrolthatHalaszquestionedin
(Halasz1988).However,someofthemostimportantargumentsfortheimportanceofver-
sioncontrolandhistoryretentionarenotsolelyforuserversioncontrolcapabilities,butto
ensurecorrectnessandconsistencyinthedistributededitingofcollaborative,constructive
hypertexts(Joyce1988).
TheexperimentalsystemRHYTHM(Maioli,Solaetal.1994;Maioli,Solaetal.1994)ex-
ploredtheuseofversioningspecificallytosupportaccountabilityandfine-grainedtracking
ofhypertextanchorsacrossrevisionsoftextnodesinhypertextdocuments.RHYTHMalso
implementedtransclusion—structuraldatasharingbetweendocuments,usingthesame
mechanismsthatitusedforversionmaintenance.
Versionmanagementhassomeimportantvirtuestoofferanysystemthatincludeshyper-
textlinking,sinceimmutableversionscanpreservethestateofasharedobjectatthetime
oflinkcreation.Thisisusefulbecausethemeaningofalinkisdeterminedpartlybythe
contentsofitsendpoints.Evensubtlechangesinalinkeddocumentmayradicallychangeits
meaninginthecontextofaneditoriallinkassertingbiasorinaccuracy.Inacollaborative
context,theattachmentofannotationsmayformasignificantchannelofcommunication
betweentheauthors,andtheabilitytoviewannotationsinconjunctionwiththeiroriginal
Previous Page Next Page