AGOCG logo
Graphics Multimedia VR Visualisation Contents
Training Reports Workshops Briefings Index
Next Back

An Interactive package for constructing personal portfolios and its Mac-to-PC conversion

This case study was prepared in November 1994 for the Advisory Group on Computer Graphics (AGOCG) Technical Report 26

Clive Richards and Simon Turner

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.

I. The design of the package

The client-developer relationship

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.

The design approach

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 users

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:

Key features of the package

Using the information gathered from the lecturers, the Learning For Tomorrow package was designed and developed, and has the following key features:


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.

II. Macintosh-to-PC conversion issues

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.

Issues related to the inherent differences between the two platforms

Issues related to transferring files physically from one machine to the other

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.

Issues related to differences between Director 3 and Player for Windows

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:

Conclusions on the conversion process

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.

Appendix - Other Player anomalies

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.

Next Back