6 7 Authoring application
6.8 The /M MEDIA TE prototype
Once the con stituent applications had been coded a nd tested ind ividually, they then n eeded to be tested in relation to each other. An i mportant part of the i ncremental
Chapter 6: Prototyping 1 69
prototyping process has been assembling the applications into the overall I M M E D IATE system , a nd then testi ng and mod ifying them so that they worked togethe r to support all the requ i red fu nctionality of the Learn ing Shell.
To begin with , I M M E D IATE was assembled a nd debugged on a single computer. Then , the un iversity-end components and the Learn ing Shell were installed o n separate PCs and modified to run over a peer-to-peer LAN .
This section conce ntrates o n the main cha llenges t o get IMMED IATE t o ru n over a network. These were:
• Integrating the three component appl ications (student, a uthoring and repository
management) a nd the FTP server into a working prototype ru nning on an Ethernet LAN . On the network level th is was quite stra ightforward. lt involved linking two PCs ru nning Windows 98 using a 1 0Base2 Ethernet coaxial bus (Ta nenba u m , 1 996, p. 277), a nd configuring the PCs to communicate over TC P/I P protocols. Withi n the cl ient applications (Shell and authoring), the hard coding of the FTP server's l P address was changed t o a parameter t o b e read from a set-up file .
As an application, the Learning Shell was easily instal led , together with its folder system and data fi les, from CD or the Internet. lt could then be accessed from an icon on the Windows Desktop.
The Delphi installation utility was used to create a set of installation files, which were used to i nstal l the Shell on the second PC . This highlighted some issues caused by variations in graphics capabilities (e . g . available colours) a nd screen resolution. A lowest common denominator a pproach has to be taken to the use of colour in the She l l . In relation to varying screen resolutions, all interface components must be designed for the lowest resolutio n , an algorith m has to be introduced to resize screen objects to match the resolution on the use r's computer, or the user has to be guided to set the screen resolution to the optim a l level. For the pu rposes of this initial prototype, the latter strategy was assumed.
• Installing a section of an extramural computer science paper, using the a uthoring
application . Th is proceeded smooth ly. But as the course a uthor was also the system developer, it could only be a test of the application's functionality, not its usabi lity.
The main change introduced at this stage was to provide for a wider range of materials to be displayed by learning com ponents, for instance, multiple web pages instead of a single document. This e ntailed altering the resources directory
Chapter 6 : Prototyping 1 70
structure of the Learn ing Shell. And it required additions and a lterations to the a uthoring system to support the fu nctionality added to the Lea rning Shell e . g . e nabling a hiera rchy o f folders ( a s with web pages) t o be added to cou rse material in the same manner as a single file.
I mprovements were also introduced at this stage for updating the Extramural S u pport database in response to student queries and communications. This is discussed under "Authoring and Updati ng the Support System" (6 . 7 . 3 ) .
• A self-evalu ation of the prototype for fu nctionality using the set of scenarios that
defined the main functiona l requirements of the Lea rn ing Shell (Appendix D).
• Mod ifying and debugg ing the prototype u ntil it satisfied the essential functional req uirements i n these scenarios. This is discussed in the following sections .
6 . 8 . 1 Mod ifications to the prototype
Considerable effort was directed at this stage to perfecting the methods by which the three core appl ications commun icated with each other over the network so as to accu rately transfer data and maintain consistency across the ove rall syste m . Modifications o f a l l th ree component applications were made t o simplify updating of course materia ls and the extramural support database by the student, a nd to provide more visual feed back. Many of these changes have already been discussed.
Some changes a lso had to be made at this stage that were required by techn ical limitations of the tools u sed . For example, the database engine that Delphi provided for free d istri bution with an application supported a smaller su bset of SQL functionality than the version provided with the prog ramming environment itself.
(a) failed query:
select MAX( entered ) from Messaging where F _From = : F _From;
(b) replaced by selecting the first member of result set from this alternative:
select entered from Messaging where F _From = :F _From order by entered desc;
Figure 6.31 : SQL q uery rewritten to run outside Delphi environment.
For instance , updating of messages between the Lea rning Shell and Repository databases relied on use of the MAX function in SQL (6.5.2). But the call to MAX fu nctio n failed in the d istributed version. Th is meant that when the Lea rning Shell was
Chapter 6: Prototyping 1 7 1
installed on a sepa rate computer synchron isation of data between the databases fa iled. Because this problem only occu rred outside the Delphi IDE, it was very difficu lt to locate . Once located , however, it was easily solved by rephrasing SQL queries where necessary, as in Figure 6 .3 1 .
The final network specification for IMMEDIATE is shown in Figure 6.32.
Repos•tory (Database. update files) - - -
---
Off-campus ( Secunty) ' Internet D-ROM t � �Figure 6 .32: IMMEDIATE prototype imp lementation.
6.8.2 Debugging
T h e difficu lties in troubleshooting a relatively s i m p l e SQL problem highlig hts how challenging it can be to locate and fix errors in programming logic and semantics in a project of this scope.
One of the advantages of software development in Delphi is the prog ra m m i ng environment's comprehensive set of integ rated debugging features, including being able to step through sou rce code line by line while the prog ram is run ning. H owever, implementing some of the requirements of the Learn i n g Shell inhibited debugging using the Delph i tools.
For example, shutting o ut Windows operating system features while the Learn i n g S hell is being used had the side effect of shutting out Delphi's debugg ing windows a s well. This function of the Shell had to be switched off d u ri n g debugging sessions.
Chapter 6 : Prototyping 1 72
And, for debugging the complex log ic of the overall system - especially the interactions between the different applications -- it was often more helpful to trace component interactions using the wel l-proven method of writing status messages direct to the screen and to a log file as the application ran , using the method:
procedure tell User( com ponent, msg: stri ng; loglt, tell it: boolean ) ;overload;
available in the Shell's System Utilities unit (Appendix F). Special debugg ing code is inherited or added to screen forms to support these features a nd enable Delphi's own debugging tools to work unimpeded.
This code is activated by a D E B UG variable in the controller object which activates a D E B U G variable in parent component forms, through which it is passed to its child forms . Alternatively, by directly activating the DEBUG variable in a parent component form , the prog ra mmer can troubleshoot that part of the code , wh ile the rest of the application fu nctions norma lly.
The tei i U ser method has a lso been used to provide an application-specific standard format to display a message to the student user where necessary, such as if an
u nexpected e rror occu rs.
By using these debugging featu res to track user i nteractions with the Learning Shell , the Log File became a n evaluation tool d u ring user testing.
6.9 Conclusion
To i m plement I M M E D IATE for the pu rposes of eva luating the learning computer hypothesis, three separate applications have been built and then networked with an FTP Server i nto a working system . They are a Learni ng Shell , a Course Autho ring a nd Manage me nt Application a nd a Repository Manager. This chapter has summarised that experience .
P rototyping I M M E D IATE proved t o b e a su bstantial programming task involving more than 2 5 , 000 lines of sou rce code. Often, several d ifferent approaches needed to be tried before a satisfactory way of meeting a specification was foun d .
Perhaps the m ost challenging aspect of this prototyping work was developing and implementing a method for communicating and transferri ng data files over an unreliable n etwork, while shielding the complexities of this process from the student user.
Using incremental prototyping , all the main req u i rements a nd functionality were successfully implemented . F rom an i n itial evaluation over a LAN , it was concluded that the prototype has demonstrated the technical feasibility of the learning computer
Chapter 6 : Prototyping 1 73
concept, at least under laboratory conditions.
Once I M M E D IATE was up, run ning and fully functional over a LAN , the next task was to install and test it under realistic field conditions. This aspect of prototyping and refi ning I M M E D IATE was combined with the user testing and is covered in Chapter 7.
Chapter 7 : User evaluation 1 75