 |
 |
 |
 |
 |
 |
 | |||
 |
 |
 |
 |
 |
|
|
|||
This case study was prepared in November 1994 for the Advisory Group on Computer Graphics (AGOCG) Technical Report 26
Authors: Clive Richards is Director of the Visual and Information Design (VIDE) research centre of Coventry UniversitY. Simon Turner is a Research Assistant in the VIDE centre.
Keywords: Interactive; personal portfolio; curriculum vitae; action plan; personal statement; information desixn: Mac-to-PC conversion
This case study deals with the design and Macintosh-to-PC conversion of a software package which enables students, particularly adults retuming to education or to employment, to construct and print out a personal portfolio. This portfolio can comprise:
The package, entitled 'Learning For Tomorrow', was developed on an Apple Macintosh in Macromedia Director and converted, using translator software, into a PC version. Distribution is via a single CD containing both PC and Mac versions of the software, since the client (Coventry's four FE colleges) requires both versions.
The project was originally initiated by the local education authority in Coventry using seconded college lecturers who teach portfolio preparation, and the city's own computer programmers. However this team did not have access to the visual and interface design skills of the Visual and Information Design (VIDE) research centre at Coventry University, nor access to the appropriate authoring tools.
The University was able to undertake a commission to produce the package, and the trials with target users have shown it to be very successful. The software requires no tutor intervention, because a video presenter - Nicky' - acts as the guide and explains the software, showing her own portfolio as an example of what is achievable. Users are invited to assemble interactively on screen a lifeline of key events. Using this, Nicky asks for further details from which a CV, personal statement or action plan are automatically compiled.
Following this introduction there are two principal sections to this report. The first briefly describes the design of the package. The second deals with the process of conversion from Mac-to-PC format.
The Coventry University Visual and Information Design research centre spent a considerable amount of time with the client on developing the software specification. It is necessary in projects of this sort that all concerned are as clear as possible about what is to be produced, how its satisfactory completion is to be measured and how and when payment is to be made. The ownership of the intellectual property rights is an important issue about which all parties must be clear. An eight page specification document formed an integral part of the contract and took several weeks of negotiation to agree. This resulted in a project plan which required the client to sign-off key stages of the work on its completion. The time spent in this careful preparation was well spent and resulted in the relatively smooth progress of work.
From a computer science point of view creating software of this sort can often seem to be principally about the configuration of a database and lhe writing of code to manage it. The user interface is looked on as the means by which relevant data is input at the right time.
By contrast, what may be described as an information design approach was used for producing the Learning For Tomorrow package. Such an approach sees the problem as focussed essentially around the operation and look of the interface. It places at the centre of concern the needs of the users, and, most importantly their expectations. That is to say that as far as possible the interface should behave consistently in a way users expect. To develop an interface which does this the designer should have a clear view, a model, of the users, and, as far as practicable, be able to evaluate prototypes with sample users as part of the development process. This latter activity - evaluation of prototypes - is rarely budgeted for properly, if at all, and consequently is usually only done towards the very end of the development process, when their is little scope for change. This was certainly the case in respect of the project reported here. This places considerable reliance on the ability of the designer to see things from the user's point of view from the outset, and to develop a functional structure for the software which is easy to operate and attractive.The proposal for the interactive software described here arose from the need to find a more efficient means of carrying out a programme of leaming which was already undertaken in the traditional lecture room manner, ie: the lecturer addressing a group of students and then working with them individually. There were therefore two classes of user; lecturers and their students. The designer of the software spent a long time talking to the lecturers about their students and the way their teaching was carried out. Through these interviews a picture of the range of users was developed, and in respect of the students a number of points emerged including the following:
Using the information gathered from the lecturers, the Learning For Tomorrow package was designed and developed, and has the following key features:
1. Every stage in the operation of the software is explained to the student by a video guide called Nicky. Her presentation can be simply curtailed by students who have used the package before and if preferred Nicky's voice can be replaced by text. Having a video guide allows anyone with reading difficulties to operate the package and having a talking head overcomes the problem of unease some users report when a disembodied voice is used. Users may be able to identify with the presenter, who describes the process of constructing a personal portfolio using her own as an example. As students come from a wide range of ethnic backgrounds there was much discussion with the client before choosing a young, white woman as the guide. See figure 1.
2. When the software first starts, Nicky asks: Would you like to begin a new portfolio, or do you have a portfolio to open from a disk?' See figure 2.
3. Following the introductory stage users are offered the chance to find out more about the three documents in a portfolio by clicking onto the appropriate graphic. When a document is chosen, Nicky tells the user about hers, while the appropriate part of that document is shown on screen. Nicky also suggests approaches to making one's own.
4. An important feature of the process is the construction of a lifeline. The lifeline is something that lecturers currently develop on paper with students. The interactive version, like this paper version, represents key events in the life of the student. The primary function of the lifeline is to encourage students to acknowledge the things that they have done, both in terms of formal jobs and qualifications, as well as informal activities and voluntary work.
Before offering the student the opportunity to make a lifeline, Nicky explains what a lifeline is and an animated sequence shows the student how to create one. Nicky then invites the users to select from a set of options, and drag them with the mouse onto their own lifeline. See figures 4 and 5. A completed lifeline is shown in figure 6.
5 Once completed, the lifeline takes on a second function, being used as the basis of the student's CV and personal statement. It is especially helpful because it breaks down the daunting task of making these documents into a series of specific, personalised questions. For example, if a job was placed on the lifeline, Nicky asks what the job was, when it started and finished, and offers a range of job skills from which the user may select those acquired during that period of employment. This sort of information, together with other details (name and address etc.) enables the system to automatically generate a CV, personal statement or action plan, all of which the user can then edit if necessary.
6. At any stage in the precess the users may return to a previous stage, move forward to the next, update their lifeline, store to disk work completed, print out a document or quiL Figures 7 to 9 show some of the navigation aids which facilitate.
7. The overall styling is deliberately cool and unobtrusive. Colour is used in a restrained way. An index card atmosphere is used as the principal screen background in the interactive sections. Animation is used in explanatory sections. Figure 10 shows a typical CV produced using the package.
During the development of the package, a four day trial of a prototype was conducted with a sample of 30 students, using both PC and Macintosh versions of the package. This revealed the basic design to be sound, but revealed a number of small software bugs. With the exception of those students who got into difficulties because of these bugs, virtually no lecturer intervention was re~quired from the commencement of work, to the production of a printed document. On average a student was able to produce at least one of the three possible documents within their allotted one hour test Deriod.
The debugged version was later used in a training session with lecturers, for whom a 23 page user guide was written. This describes what sort of computers are needed and how they should be set up, as well as giving a brief overview of how the package operates and describes how to maintain and erase files etc.
No user guide is necessary for students, as the software has so far proved entirely self- explanatory.
This section of the report deals with the process of converting the software, developed using Macromedia Director 3 on a Macintosh, to run on an IBM-compatible PC. The conversion software for Director 3 is called Director Gaffer, and 'gaffered' Director movies play under Player For Windows on the PC. Using Player For Windows it is possible then to turn gaffered movies into projectors, which are stand-alone applications that don't need Player. As this project neared completion, Director 4 was released for Windows as well as for Macintosh. At the time of writing this is an unknown quantity, so problems in using Director 3 and Player may or may not apply to the new version of Director. The means used to transfer files to the PC was the cable and software combination MacLink Plus. The final objective of conversion was that the software runs from a CD-ROM containing both Macintosh and PC versions.
Broadly speaking three kinds of issues have arisen during the transfer procedure. These are - issues related to the inherent differences between the two platforms; issues related to transferring files physically from one machine to the other; issues related to differences between Director running on the Macintosh and Player running on the PC. A further list of all the discovered anomalies in Player is in an Appendix which follows this text.
Whilst we have been able to get the job of conversion done successfully, it remains debatable whether one can ever be entirely sure that the software on the PC is robust, since there is a potentially infinite number of ways an end user might have configured their system.
2. The other side of this coin is that a fault with the configuration of a system may only come to light when using a certain piece of software, leading the user wrongly to blame the software rather than the system. Precisely this occurred when we began running QuickTime video on the PC, as it was noticed that the sound was running out of synchronisation with the images. Several calls to the suppliers of QuickTime and of related products failed to produce an answer as to why QuickTime was not dropping frames, as it does on the Macintosh when the computer's processor cannot keep up with the video frame-rate. Eventually the trial of the same QuickTime movies on other (slower) machines led us to conclude that the machine itself was at fault. In fact the hard disk driver- software which the suppliers had installed was incorrect, and this had led to troublesome reading of the video information. The installation of the correct driver cleared up the problem. An end user with a similarly set up machine would presumably blame our CD-ROM rather than their machine.
3. On the Macintosh QuickTime is near to being a standard system extension, and is supplied with all new machines. On the PC it is rare-to-nonexistent, and therefore has to be supplied with, and installed by, our software. As a consequence of this we have to licence QuickTime for Windows from Apple in the United States. Furthermore to make a QuickTime movie available on the PC one has to 'flatten' the data fork using an Apple utility. This is because the PC must have both the sound and video in the same fork, rather than the two that the original QuickTime produces. These flattened movies are still usable on the Macintosh, but any alteration to the original movie means that it must be flattened again (and transferred to PC again). One must also give all movies the filename extension '.MOV' for the PC to recognise them. This is something not mentioned by the Player For Windows manual, and not done automatically by the flattening software.
4. Unlike on the Macintosh, where QuickTime is a single file in the System Extensions folder, QuickTime for the PC is a collection of 20 or so different files. These files can be installed so that the machine is globally aware of QuickTime, but this form of installation is only possible with the purchase of a full stand-alone version of QuickTime. Our copy of QuickTime came as an integral part of Player for Windows, and was installed automatically by that package. With this setup, QuickTime movies can only be played by an application that is in the same directory as the QuickTime files. In other words, Player installs the QuickTime files in the same directory as itself, and only applications in this directory can use QuickTime. Therefore in order to make QuickTime available to our projector when one distributes it on CD-ROM, one needs to identify the QuickTime files in this Player directory, and cause the CD installer to install them along with the projector into a directory on the host machine. This has been problematic, since there was no documentation provided with Player to enable us to distinguish Player files from QuickTime files.
5. On the Macintosh there is rarely much of an elaborate installation process, because the icon of a CD-ROM will appear automatically on the screen, and because QuickTime is usually on the machine already. On the PC however one must create an icon for the CD by making a Program Group (the visual equivalent of a Macintosh folder) and putting a Program Item (the icon itself) within it. QuickTime on the PC must also be installed (see above). In consequence it becomes necessa y on the PC to use some third-party installation software.
We used a shareware program called Install/Easy. This software allows us to generate our own installer which will prepare the host machine - placing files into directories, creating Program Groups and so on. Testing this installer is difficult, however, as it would be prohibitively expensive and time-consuming to keep pressing trial CDs until the installer worked satisfactorily, what one really needs is an external drive that can be set up as if it were the CD drive (with the same drive letter). An external drive not being available, we had to use cut down versions of the installer on floppy disk, and attempt to infer the way it would behave when used on the CD. In fact only one error in preparation of the first test CD occurred, and this was spotted and altered at the time, leaving a successful installer on the second CD that was pressed.
There is one basic issue in this category - time. Because of differences between Director on the Macintosh and Player for Windows, one cannot normally use the Macintosh version of a Director movie as the basis for a Player movie (see 'Issues related to differences between Director 3 and Player for Windows). Therefore every time an alteration is made to a Macintosh movie, the same alteration must be made to the PC version, and this must then be converted and transferred to the PC for checking. All this is time consuming, since even the fastest method of file-transfer takes about 10 minutes per megabyte.
Generally speaking, Player For Windows operates as it should, and offers a straightforward way of running Macintosh movies on a PC. Nevertheless we have come across an array of minor differences and anomalies whilst using Player for this purpose. Some of these differences are linked to inherent differences between Macs and PCs, others seem to be faults in the PlaYer software. The major problems are as follows:
1. Neither Director 3 nor Player For Windows have adequate printing functions (Player has no print function at all). This means that one has to use third-party external software (known as X-Objects') in order to print out files. There is to our knowledge no print X-Object which worB in the same way on both platforms. Of the two X-Objects that we used, the PC will only print a page at a time, and the command to print a second page whilst the first is still printing is ignored. Conversely the Macintosh X-Object prints multiple pages in one batch.
2. Since fonts on different machines can vary, and since the standard Windows fonts are not the same as the standard Macintosh fonts, text gets displayed differently on a PC to how it does on a Macintosh. To get around this Player requires a file known as an 'INI' file. This would be a file named after a projector but with the suffix '.INI', and placed in the machine' s Windows directory. This file is a text file which lists any font-substitution that one wishes to be used by that particular projector. Font-substitution is then a matter of trial and error until an acceptable substitute is discovered. For the record, we found that Geneva was adequately emulated by Lucida, and that despite the presence of Courier on the PC, Courier had to be substituted by Courier New because Courier on the PC displays and prints poorly.
3. A fulther difference between Director and Player is found in the respective ways that they handle QuickTime movies. Using Director on the Macintosh one has the option of making QuickTime movies partially obscured behind other images, whereas QuickTime movies running in Player on the PC can only appear on top of all other images. Obviously one has to settle for the lower specification of the PC version if the Director movie is to look the same on both platforms.
4. Finally, pathnames are a problem on the PC using Player. On both a Macintosh and a PC it is necessary to specify where the machine will find a certain file. This is done by specifying the path. The path lists lhe directory hierarchy from the drive that a file is on, down through the directories to the file itself. However the Macintosh and PC specify pathnames differently. Player has an internal conversion facility that means that a gaffered Macintosh Director movie with a script that reads go to movie 'Macintosh HD:Movies:MyMovie' will work on a PC despite the correct pathname on a PC implying that the script should read: go to movie 'C:\Movies\MyMovie:
In fact Player won't tolerate the correct DOS pathname, and insists that pathnames are left in their Macintosh forrn. This would be acceptable if Player's conversion facility worked consistently, but it appears that it does not. If Player is told to go to a movie called 'MyMovie' it will on occasion object that it cannot find a movie called EMyMovie'. In other words Player seems to read the back- slash \' (which it generated for pathname accuracy) as part of the name.
Whilst many of the problems encountered during the conversion process were trivial, these problems were exacerbated by the impossibility of directly altering Player movies. The release of Director 4 for both Macintosh and PC would apparently cure this (indeed when endeavouring to get advice from Macromedia about the anomalies in their Player software, we were told that Player was obsolete, and we should upgrade to the newly released Director 4). However, it remains uncertain whether even Director 4 movies would be absolutely compatible across the two platforms. A brief experiment with Director 4 has already revealed a difference between the two platforms in the way that they respond to the closing of a window. That said, Director is a hugely powerful authoring tool, and there are few viable altematives to it. Hypercard stacks can work on the PC using ToolBook, and Macromedia's own Authorware is fully cross-platform, but the former provides only an approximate equivalence, and the latter is intended only for more straightforward multimedia projects.
It should be borne in mind that Player does not claim to include every tacility of Director. However the following are anomalies not mentioned in the manual, and without obvious explanation. Some of these anomalies are trivial, yet they do mean that scripts which work happily on the Macintosh inexplicably don't work on the PC. All of these problems were revealed as a direct result of trying to run Macintosh movies on the PC.