The Design and Implementation of the Smartphone-based GroupNotes App for Ubiquitous and Collaborative Learning

The lecture accounts for about half of staff-student interaction yet many students fail to engage in them as they find the environment is not conducive to the social learning paradigm they are accustomed to. Smartphones are rapidly replacing mobile phones within the student population and the screen size, connectivity and text entry speed provide a readily accessible platform for students to conduct ubiquitous and collaborative learning activities. In this paper, we present the design and implementation of a Smartphone App GroupNotes, which allows a small group of students to participate in a real-time collaborative note-taking session using their own Smartphones in the lecture. Key technical contributions include an innovative collaborative note-taking interface, synchronisation of multi-user editable notes, and compression of operation buffers to reduce the consumption of network resources and Smartphone battery.


INTRODUCTION
We proposed that a Smartphone-based approach to increasing student engagement in lectures is a viable and, most importantly, an accessible option for today's students (Reilly and Shen (2011)).A Smartphone-based collaborative notetaking application will provide a platform for small groups to create a self-motivating, social learning environment allowing them to collaborate silently in lectures while providing the necessary options and customisation to cater for the different learning styles of the individuals within those groups.
The choice of the Smartphone as the platform for a collaborative tool suitable for use within a lecture environment is due to the predicted ubiquity of such devices.At present the majority of university students either own or have access to a mobile phone (Litchfield et al. (2009)) and IDG predicted that by the start of 2010 sales of Smartphones within Australia would exceed 50% of new sales.While larger devices such as a T abletP C may provide a more usable learning environment (Kam et al. (2005); Simon et al. (2008)), not all students are able, or willing to purchase the device, bring it to university with them, and then actually use it in the lecture environment.
The Smartphone is attractive to the student as there is no imposition associated with carrying an additional device, or in learning to use it or the new software since they have already learnt how to use the device voluntarily.There will be no additional monetary costs to use the device in the lecture environment as wireless access is already provided free therefore removing a major concern of students (Litchfield et al. (2009)).
Staff-student contact time at university is dominated by the lecture because it is recognised for its ability to uniformly deliver information not found in the standard texts, as well as the possibility to inspire and motivate students ranging from hundreds to perhaps thousands (Bligh, D. A. (2000)).Yet many students view some, or all of them as a waste of time (Hitchens and Lister (2009)) and either cease attending those lectures, or lose interest in as little as 20 minutes of a lecture due to no interaction with either the lecturer or other students in the vicinity (Bligh, D. A. (2000)).
The actual lecture environment itself is sub-optimal as it promotes the feeling that the students are at a performance.The shape of many lecture halls is that of an amphitheatre where the lecturer is far removed from the audience of students who are expected to sit in silence while the lecturing "performance" takes place.Students are disadvantaged in several ways with this environment, most notably because with the implied or actual prohibition on speaking, there is no opportunity to immediately interact with their fellow students, for clarification or validation of their understanding on the lecture content.Students feel isolated, part of an "anonymous mass" (Falkner and Munro (2009)).This change of teaching paradigm away from social learning as a member of an interactive (high school) classroom to that of a (mostly) passive audience member is seen as a cause of students failing to successfully complete their studies.
Note-taking during lectures is established as an important part of the process of codifying lecture content into knowledge that can be retrieved later.The current technology, in the form of soft keyboards such as Swype, Swif tkey and T 9 T race allow text entry speed comparable or even faster than penand-paper handwriting.Our proposal is based on this observation (Reilly and Shen (2011)) and incorporates opportunities for the social learning attributes of challenging or validating one's current "knowledge" against others in a group in real time, which motivates a student to remain on task and to produce quality work.The application will also provide for the individuals who prefer to work alone, or who cannot keep up with multiple students during the lecture but would like to be part of a group with sharing of knowledge.In this instance, the student works alone, but stays motivated to produce quality work and to remain on task by the prospect of receiving multiple sets of notes from their other group members at the end of the lecture.
When the students are fully engaged, their attention span seems infinite, regardless of the teaching method (Matheson, C. (2008)).In this paper, we aim to design and implement such a Smartphone App -GroupN otes, a collaborative note-taking application that allows students to teach, correct, motivate and learn from their peers during the lectures.Key technical contributions include an innovative collaborative note-taking interface, synchronisation of multi-user editable notes, and compression of operation buffers to reduce the consumption of network resources and Smartphone battery.
The rest of the paper is organised as follows.The next section describes the application user interface.After that, we present the technical solutions for the note synchronisation and the operation buffer compression.Finally we conclude the paper with a summary of major contributions and future work.

APPLICATION USER INTERFACE
The Smartphone App user interface design is based on the results of a needs finding questionnaire given to third year computer science topic students at our university (Reilly and Shen (2011)).Working scenarios and screenshots are provided to illustrate particular design choices, with reference back to the educational requirements.

Device Characteristics
Today's Smartphone primarily uses a soft keyboard on a viewing screen ranging from approximately 3 to a maximum of 5 inches and our design focus will be on devices meeting these criteria.

Working Scenarios
The working scenarios provided show the application's user interface from the point of view of a single student's device.In order for the student to view more editors, they need to drag one or more editors from the radar view area to the editor area.In this example, there are four individual editors available representing the four students who are part of this group.The group may be made up of more or less students; four was identified from the questionnaire as being the maximum number of concurrent users an individual could keep up with cognitively during a lecture.The available screen real estate also limits the number of viewable editors possible.Figure 2 shows that the student has chosen to view two editors at the same time.This occurs by dragging Student 2's editor radar view (the bottom left editor in Figure 1) up to the editor area.To return to a single editor, which may or may not be the device owner's editor, would require the reverse action, i.e. dragging the unwanted editor down to the radar view area.Figure 3 shows all four editors that take up all available screen real estate.It is worth pointing out that while a student can view up to four editors at the same time, when they start doing text entry in an editor, that editor will occupy the entire editor area, pushing the rest of editors from the editor area to the radar view area, primarily due to the significant screen real estate taken by the soft keyboard.

Text Editing Functions
At present the text editor only has basic functions including the ability to change the colour of the text (system enforces the text colour and users are not allowed to), present text in plain, bold or italic, highlight the background of selected text, strikethrough selected text or underline selected text.These features will be accessed through a floating toolbar which will appear whenever text is selected.Figure 3 illustrates all of these features.Student 1 is using plain text in red in their own editor.Student 2 has written notes in green in their editor to which Student 1 has performed a strikethrough of the acronym CSCL and then entered the correct acronym CSCW; both changes are in a different colour to identify an input from other than the owner of the editor.Student 2 has also highlighted something they consider important in their notes and has underlined the words Wikipedia picture.Student 3 is using blue text and has provided emphasis on four words from their notes through highlighting.Student 4 using the colour purple has used bold on the words CSCW matrix and italicised real world and technical terms for emphasis.

User Identification
The questionnaire strongly suggested that users should be differentiated on the individual's device through the use of a unique colour for each group member.This colour borders the editor where that user writes their notes and is illustrated in each of Figures 1-3.The colour also identifies specific user generated content which is entered into another group members writing area, such as Figure 2 where Student 1 (in red) performed a strikethrough on the text CSCL written by the owner of editor 2 (in green).CSCW is the new text written in this green area, also in red.This allows other group members to determine who has made the change.

NOTE SYNCHRONISATION
In a real-time collaborative note-taking session consisting of up to 4 students, each student is allocated a dedicated multi-page note that corresponds to the the number of lecture slides.Each note can be jointly edited by the 4 students; therefore, the notetaking session is actually composed of 4 parallel collaborative editing sessions, one for each note.We devised an optimistic concurrency control solution to synchronise each note by leveraging the GroupN otes Server as the mediator.In this solution, each note is replicated in every student's App and operations performed in one App are broadcast to all other Apps.

Operational Transformation
There are two types of operations involved in editing a note: Ins/Del[ page, position , length, text] denotes inserting/deleting a piece of text of length at the position in the page of the note.Updating an attribute of a piece of text, e.g., highlighting the text, is represented by deletion of the text with the old attribute value followed by insertion of same text but with the new attribute value.

Note Synchronisation
The note synchronisation solution consists of an operation broadcast protocol, an operation replaying algorithm, and a set of collaborative editing session management protocols.As shown in Figure 5, the server runs m (m ≥ 1) collaborative note-taking sessions; each session has up to 4 collaboratively edited notes.There are n (n ≥ 1) Apps connected to the server and up to 4 Apps, e.g., App i, j, k, and l (1 ≤ i, j, k, l ≤ n), can share the same session, e.g., session p (1 ≤ p ≤ m).For each note, the server maintains a master note M N , a master incoming operation buffer M IB storing all operations that should be executed on M N to get its latest state, and a server-side incoming operation buffer for each App involved in the same note, e.g., SIB i , SIB j , SIB k , and SIB l in session p, storing remote operations that have been received by the server but are yet to be received by the corresponding App.
,-%.)*%+"#'!"-0"-'Each App can write into any of the 4 notes at any time, therefore it needs to separately synchronise these 4 notes.For each note, the App maintains a replica of the note RN , an outgoing operation buffer OB storing locally generated operations on RN , and a client-side incoming operation buffer CIB storing remote operations that have already been received by the App and will be replayed on RN .In Figure 5, RN i j , OB i j , and CIB i j (1 ≤ i ≤ 4 and 1 ≤ j ≤ n) are App j's replica, OB, and CIB for note i respectively.

Operation Broadcast
A note synchronisation process consists of two subprocesses: broadcast local operations and replay remote operations.Suppose App (a) lock note r, including the MIB and all the , and returns transformed ones Sq b a and Sq a b , can be found in an earlier work (Shen and Sun (2002)).

Operation Replay
The other sub-process involved in a note synchronisation is to replay remote operations stored in an App's CIB.The above operation replay algorithm executes remote operations in CIB r k to complete the synchronisation process on note r at App k.
It is worth pointing out that because local and remote operations need to modify the same replica of note r at App k, execution of local operations and replaying of remote operations must be mutually exclusive.In case of contention between local and remote operations, local operations must be given the priority to ensure good local response.Otherwise, if all remote operations in CIB r k were replayed as a continual stream, local operations would suffer starvation, resulting in poor local response.Due to the space space limitation, collaborative editing session management protocols are not given in the paper.

OPERATION BUFFER COMPRESSION
The network connection between an App and the server is based on Wi-Fi, where the network resource is always limited.Frequent broadcast and replay of every individual operation is undesirable as it will consume too much network resource as well as the battery of the Smartphone running the App.It is also unnecessary as students are only interested in what note their peers are taking rather than micro-step operations.Therefore, we devised an operation buffer compression technique to compress each App's OB so that only the net effects of the operations in each OB will be broadcast and replayed.The compression technique can significantly reduce both the size of an OB and the number of operations in it.

Operation Relationships Definition 1 (Operation Context)
Given an operation O, its context, denoted by Υ O , is the state of the note on which O is defined.
Definition 2 (Operation Context Preceding Relation) , where ' ' is the operation execution operator.
Υ Oa is the context (i.e., state of the note) on which O a is defined.After the execution of O a on Υ Oa , the new context can be described by Because operations performed in different pages of a note cannot be compressed, for the good of presentation, operation O is represented as Two adjacent operations can be merged into one operation by concatenating their effect regions.In this way, the number of operations in an OB can be reduced by one.The same type of two overlapping operations can be merged into one operation by combining their effect regions.In this way, the number of operations in the OB can be reduced by one.Different types of two overlapping operations can be merged in such a way that the overlapping region is removed from both operations.In this way, the size of the OB can be reduced and the number of operations in the log could be reduced by one or two if the effect region of one operation totally falls into the effect region of the other operation or the effect regions of the two operations are completely overlapping.The following functions are defined to merge two operations in an OB.

The Compression Algorithm
Definition 6 Maximally compressed OB " Ω OB " Given an OB, Ω OB denotes its maximally compressed form in which for ∀O i , O j ∈ OB (0 ≤ i, j < |OB| and i = j), O i O j .
We devised a compression algorithm based on operational merging, which can achieve maximal compression.First, the algorithm exhaustively examines every two operations in an OB, including those that are not physically located one after another in the buffer.In the aforesaid example, the compressed OB is ALGORITHM 5: LTranspose(OB, i, j) Applying LTranspose (OB, 1, 2) to the aforesaid example would result in a reshuffled , 4, c123].This OB has achieved maximal compression, i.e., OB = Ω OB , achieving 60% reduction in operation number and 57% reduction in buffer size.
After D 3 : I 1 /D 1 I 2 /D 2 (A) A later insertion operation would never make two previous disjointed operations overlapping or adjacent.
(B) A later deletion operation could make two previous disjointed operations adjacent.

Figure 6: Hidden adjacent operations
Second, the algorithm can discover hidden adjacent operations, i.e., these operations were initially disjointed and then made adjacent by subsequent operations.As shown in Figure 6(A), operations I 2 (an insertion operation) or D 2 (a deletion operation) and I 1 /D 1 were initially disjointed.If a new insertion operation I 3 inserts a sequence of characters, for instance between the effect regions covered by I 1 /D 1 and I 2 /D 2 , it can never make I 2 /D 2 and I 1 /D 1 adjacent.In contrast, a later deletion operation could create new adjacent relations among previous disjointed operations.As shown in Figure 6(B), operations I 2 /D 2 and I 1 /D 1 were initially disjointed.
If a new deletion operation D 3 deletes all characters between the effect regions covered by I 1 /D 1 and I 2 /D 2 , I 2 /D 2 and I 1 /D 1 then becomes adjacent.
To address this issue, the algorithm transposes all deletion operations to the left side of all insertion operations in an OB in order to effectively detect the hidden adjacent relations created by these deletion operations.Therefore, the algorithm first merges all deletion operations with other operations and then merges insertion operations with the rest of the operations.In this way, insertion operations must have already taken into account the effects of all deletion operations and consequently the algorithm can merge hidden adjacent operations.As a result, a maximally compressed ) is a deletion operation and I j (1 ≤ j ≤ s) is an insertion operation.
The COMET (Compression by Operational Merging & Transformation) compression algorithm can achieve maximal compression, as described by the following theorem.Given an storing a list of user-issued operations on a note, where EO i (1 ≤ i ≤ m) is referred to as an effective operation.A list of effective operations is the minimal list of essential operations in transforming a note from its initial state to the final state while preserving the intentions of user-issued editing operations.
, where all D i (1 ≤ i ≤ r) are disjointed deletion operations, all I j (1 ≤ j ≤ s) are disjointed insertion operations, and D i I j .
, where all operations are disjointed.That is OB = Ω OB and the theorem holds.

If ∃I
where all operations are disjointed.
, where all operations are disjointed.That is OB = Ω OB and the theorem holds.
If O n+1 is a deletion operation, the proof is as follows.

Given ∀D
, where all deletion operations are disjointed.However, the deletion operation O n+1 may create a new adjacent relation between I l and I q (1 ≤ l, q ≤ s).As a result, COMET([I , where all operations are disjointed.That is OB = Ω OB and the theorem holds.

Given ∀I
, where all deletion operations are disjointed.O n+1 may create a new adjacent relation between I l and I q (1 ≤ l, q ≤ s).As a result, COMET( where all insertion operations are disjointed.So OB , where all operations are disjointed.That is OB = Ω OB and the theorem holds.

Given ∀D
where all operations are disjointed.That is OB = Ω OB and the theorem holds.
where all insertion operations are disjointed.So OB , where all operations are disjointed.That is OB = Ω OB and the theorem holds.By the induction argument, the theorem holds, that is, for an OB containing any number of operations, after COMET(OB), it must be OB = Ω OB .
Due to space limitation, other important properties of the compression algorithm are not given in the paper.

CONCLUSIONS AND FUTURE WORK
Our approach to increasing the engagement of students in lectures using Smartphones is innovative, both in terms of the purpose that the device is being used for, but also the technical contributions allowing for the different learning abilities and styles.A single editor, where notes from all group members are intermingled and there is no opportunity for an individual to look at just a single group member's notes, does not meet the primary requirement for flexible and effective collaborative learning in lectures.
Design for multiple editors with each being explicitly owned by a student but allowing for collaborative editing of the same note provided the driving force behind the technical innovations outlined in this paper.The innovative collaborative interface allows any group member to freely write into any editor at any time, the optimistic note synchronisation solution allows a note to be fully synchronised without requiring much network bandwidth or any constraint on users' activities, and the novel operation buffer compression algorithm allows the App to take full advantage of the available wireless networking resources and a Smartphone's battery life.
Future work includes usability study of the GroupN ote system, including evaluation of the user interface and collaboration features as well as study of human factors.Studies into collaborative learning using the system will be carried out to determine the learning outcomes of students participating in the system compared to either non-participation or participation using alternative technologies.

Figure 1
Figure1shows the default screen view of the student after they have finished making a note.The screen is divided into the editor area (upper part) and the radar view area (lower part).The device owner can view and make notes in the editor area, while editors from their group members who have joined the session are shown in the radar view area.In this figure, Student 1's editor is shown in the editor area on the screen, while the editors from Students 2, 3 and 4, from left to right at the bottom of the screen,

Definition 3 Definition 4
Ins/Del[position, length, text], where P(O) = position denotes O's position parameter, N(O) = length denotes O's length parameter, S(O) = text denotes O's text parameter, and T(O) = Ins/Del denotes O's type parameter.The following definitions are used to describe the relationships between any two operations in an OB.Operation overlapping relation "⊕" Given two operations O a and O b where O a → O b , O a and O b are overlapping, denoted as O a ⊕ O b , iff (if and only if) one of following conditions holds: 1. T(O a ) = T(O b ) = Ins, and P(O a ) < P(O b ) < P(O a )+N(O a ). 2. T(O a ) = T(O b ) = Del, and P(O b ) < P(O a ) < P(O b )+N(O b ). 3. T(O a ) = Ins and T(O b ) = Del, and P(O a ) ≤ P(O b ) < P(O a )+N(O a ) or P(O b ) ≤ P(O a ) < P(O b )+N(O b ).4.2.Operational Merging Two operations O a and O b are overlapping if their effect regions are overlapping.First, if an insertion operation O b inserts a string that falls into the effect region of a previous insertion operation O a , then O a and O b are overlapping.Second, if a deletion operation O a deletes a range that falls into the effect region of a later deletion operation O b , then O a and O b are overlapping.Third, if an insertion operation O a inserts a string which or part of which falls into the effect region of a later deletion operation O b , then O a and O b are overlapping.Finally, under no circumstance could an insertion operation overlap with a previous deletion operation because there is no way for a string to be inserted into a nonexistent string (i.e., a string that has already been deleted).Operation adjacent relation " " Given two operations O a and O b where O a → O b , O a and O b are adjacent, denoted as O a O b , iff one of the following conditions holds: 1. T(O a ) = T(O b ) = Ins, and P(O b ) = P(O a ) or P(O b ) = P(O a )+N(O a ). 2. T(O a ) = T(O b ) = Del, and P(O a ) = P(O b )+N(O b ) or P(O a ) = P(O b ).The same type of two operations are adjacent if their effect regions are adjacent.If an insertion operation O b inserts a string that is adjacent to the string inserted by a previous insertion operation O a , then O a and O b are adjacent.If a deletion operation O b deletes a range that is adjacent to the range deleted by a previous deletion operation O a , then O a and O b are adjacent.Definition 5 Operation disjointed relation " " Given two operations O a and O b , O a and O b are disjointed, denoted as O a O b , iff neither O a ⊕ O b nor O a O b .

ALGORITHM 2 :
OM(O a , O b ): (O a , O b ) Require: O a → O b Ensure: O a O b if (T(O a ) == Ins and T(O b ) == Ins then return OM II(O a , O b ) else if (T(O a ) == Ins and T(O b ) == Del then return OM ID(O a , O b ) else if (T(O a ) == Del and T(O b ) == Del then return OM DD(O a , O b ) else return (O a , O b ) end if ALGORITHM 3: OM DD(O a , O b ): (O a , O b ) if (P(O a ) ≥ P(O b ) and P(O a ) ≤ P(O b )+N(O b )) then head ← substring(S(O b ), 0, P(O a )-P(O b )) tail ← substring(S(O b ), P(O a )-P(O b ), N(O b )) T(O a ) ← Del; P(O a ) ← P(O b ) N(O a ) ← N(O a )+N(O b ) S(O a ) ← head+S(O a )+tail return (O a , I) else return (O a , O b ) end if ALGORITHM 4: OM II(O a , O b ): (O a , O b ) if (P(O b ) ≥ P(O a ) and P(O b ) ≤ P(O a )+N(O a )) then head ← substring(S(O a ), 0, P(O b )-P(O a )) tail ← substring(S(O a ), P(O b )-P(O a ), N(O a )) T(O a ) ← Ins; P(O a ) ← P(O a ) N(O a ) ← N(O a )+N(O b ) S(O a ) ← head+S(O b )+tail return (O a , I) {I is an identity (null) operation} else return (O a , O b ) end if OM II(O a , O b ) is defined to merge two insertion operations O a and O b where O a → O b .If O a ⊕ O b or O a O b , O a and O b will be merged into a single insertion operation O a that integrates the effect regions covered by both O a and O b .OM DD(O a , O b ) is defined to merge two deletion operations O a and O b where O a → O b .If O a ⊕ O b or O a O b , O a and O b will be merged into a single deletion operation O a that integrates the effect regions covered by both O a and O b .OM ID(O a , O b ) function is defined to merge an insertion operation O a and a deletion operation O b where O a → O b .If O a ⊕ O b , the overlapping region will be removed from both O a and O b in such a way that the common substring ST inserted by O a but later deleted by O b is eliminated from both O a and O b .OM ID(O a , O b ) is the most effective merging function that can dramatically reduce the size and the number of operations in an OB by removing redundant operations or redundant information in operations.Due to the space limitation, the OM ID function is not given in the paper.
is not examined.We adopt the operational transformation technique to reshuffle an OB through the following LTranspose (OB, i, j) (0 ≤ i < j < |OB|) function, which contextually swaps operations OB[i] and OB[j].
To minimise the impact on the local response, each remote operation in CIB r k should "give way" to new local operations before being replayed.
k |== 0 or HOB's turn) For |OB| = n, hypothesize that the theorem holds, that is, given OB and O n+1 are disjointed deletion operations.If O n+1 creates a new adjacent relation between I l and I q