Las tecnologías de la información y la comunicación – TIC-, en los procesos

The entry of the two new researchers into the project and our overlapping research interests explained in Section 5.2 motivated us to collaborate in designing our new version of the XML. We first reviewed the original design (see Section 4.3.2) and then investigated JavaScript Open Notation JSON (http://www.json.org) as an al-ternative data interchange format.

We met with the researchers in four technical meetings and later by email

cor-respondence. Our meetings aimed to outline the technical requirements for each of our SignSupport contexts. Their involvement in the project was to collaboratively co-design a data interchange structure that was applicable to all our application contexts of SignSupport. Their context, similar to our project, were collaborative projects with DCCT and the institutions mentioned above and are beyond the scope of this dissertation.

The initial outcome of the meetings was to finalise the choice of the data in-terchange format: XML or JSON. The starting point was the review of pharmacy version of SignSupport [72] and the version 1 of XML in Section 4.3.2. The design of the first XML version was based on the hierarchical structure of the e-Learner manual. The choice of data interchange format also took into consideration JSON as an alternative data interchange format.

We explored JavaScript Open Notation JSON as an alternative. JSON and XML were text-based and needed to be parsed character by character thus imposing a limit on deserialization speed [93]. JSON makes use of nested brackets with name:value pairs. JSON had the advantage of a lightweight structure making it efficient to transfer over a data connection in comparison with XML which is verbose due to opening and closing tags. JSON fell short of our requirements because of lack of namespaces support, extensibility drawbacks and input validation [77]. The namespaces are used to provide uniquely named elements and attributes in the XML document. Once JSON was ruled out, we settled on XML and outlined the requirements for the its structure.

In version 2, the requirements extended to the other application contexts of SignSupport namely the pharmacy context and health context. To understand how the new version of XML will fit in, Figure 5.2 illustrates the contexts of use of SignSupport showing how the XML data structure and considerations fit in.

In Figure 5.2, the context of use referred to the communication domain areas or application contexts where SignSupport could be used. The ICDL context de-termined the scope of our research. The authoring tool organised and sequenced SASL videos and images to make them meaningful to a communication domain (see Chapter 4). XML data files, exported by the authoring tool, structured the lesson

Context!of!use!

Pharmacy! Health! ICDL!

Authoring!tool! Sequencing!

images!and!

video!

!

SASL!video!

files! Images!

XML!Data!structure!

XML!files! Assets!

Figure 5.2: The architecture of SignSupport. The context of use highlights different communication domains and the authoring tool organises the communication depending on the context to produce the XML files and managing the assets such as videos and images

content of the e-Learner which was then parsed by an XML parser on the mobile device (not included in the Figure). Comparison of mobile XML parsers is carried out in a related SignSupport project.

Common to all application contexts of SignSupport were screens represented by a screen tag where SASL video instructions are viewed. These screens contained a SASL video that needed a video to tag represent the link to the video file location.

This tag was retained from XML version 1 (see Section 4.3.2). In addition, each screen had navigation buttons that allowed the user to move forward or backward between a series of screens. However, in our design discussion, navigation could not be represented in XML and was not included in the XML design.

Our application context of SignSupport differed from the other researchers in terms of user input fields. The design did not cater for user input because our

context did not utilise it but which the others needed. In the place of input, images of icons were needed for displaying together with the some of the SASL videos.

These images provided visual cues to identify the icon to select which was beneficial for Deaf learners (see Section 3.1.5).

The resulting design for XML version 2 added animage tag. The tag contained the Universal Resource Locator (URL) of the image location represented by an absolute file path. Each Screen tag (see Figure 5.4) represents a screen that shows a video to the user containing a video frame and/or an image (see Figure 5.3). Figure 5.3, shows the XML tags defined to represent a lesson. Navigation tags were not defined because XML only represents data.

Lesson...

Screen

.

Screen .

Screen

Figure 5.3: Version 2 of the XML data format showing the representation of a lesson.

Screen...

screenID

.

video frame .

video caption .

image

Figure 5.4: The screen element representing the data that will be displayed to the learner.

The element contains child elements that will contain the necessary information for the user interface.

To avoid the user interface being cluttered, only XML elements that provided the necessary information for the learners were utilised and rendered on the user inter-face. These XML elements were child elements of the Screen tag. The video frame element was rendered into a video view with media controls. The data contained in that element was the URL to the video file location. The video caption text would was extracted from the SASL video file name. In addition the caption was used as an indicator to navigate the list of lesson sections shown in Figure 5.6. Navigating the list of screen tags was achieved using buttons built-in in the mobile prototype that traversed screen tags linearly and the rendered child elements of the screen

using the appropriate widgets in Android.