多媒体教学软件开发经验谈一、脚本要求
1. 流畅性
拿到一个脚本，最起码的要求是文字要读起来非常流畅、琅琅上口，如果连基本的语句都读不通，用户听起来就会觉得很累。影响语句流畅性的因素包括以下几个方面：一是脚本人员本身就没有把问题说清楚，这可能和自己的理解能力有关，和表达能力有关，也可能是问题本身就很难表述。这就需要脚本人员在实际编写过程中不断的加以改正和积累经验，碰到相应情况后应该能够找到解决方法。在编写过程中应该尽可能的形成一个统一规范，避免个人色彩太浓，避免方言的搀杂。另一个因素和录音人员的读法有关，要着重强调的地方应加重语气，有的文字是要在屏幕上输入的文字，此时就应该和操作性文字分开来读。例如对于“在下面的文本框中输入名门软件”这句话，“名门软件”这四个字是要在屏幕上输入的，在录音的时候就应该和前面的文字有一点停顿以区分开来。流畅性主要在于汉语语法和结构上的把握，如主谓宾的搭配问题，修饰问题等。流畅和流水帐完全是两回事，流畅不仅指每个实例的讲解是不是如行云流水一般，还包括各个实例间的衔接是否通畅，不要在第一章讲基础知识，第二章就讲高级应用了。流水帐大多出现在对具体操作过程的讲解中，例如在向导中的多个“单击下一步”，我们应该尽量对每一步操作进行解释（重复性的例外），告诉用户这一步为什么要这样操作，告诉用户这一步操作起了什么作用等。
2. 通俗性
由于我们的用户水平较低，所以脚本的通俗性显得尤为重要。我们的最终目的是要教别人学会这种软件，如果写出来的文字别人看都看不懂，无法理解，这个产品就是一个失败的产品。通俗易懂、一学就会是一种理想情况，为了给人以说服力，可以给脚本增加适当的专业性，但我们的解释一定要通俗，既要让人一看就懂，又要留有探索研究的余地。要是你的软件别人看一遍就会了，那就没有购买的必要了，应该有值得回味的地方。
3. 生动性
生动性和趣味性可以激发用户观看演示的兴趣。当前普遍的问题就是演示让人看的想睡觉，脚本文字太枯燥，演示的表现手法太单调，我们并没有充分发挥Director的多媒体特性。程序员可以适当换一种方式来体现脚本所要表达的内容，当然最主要的因素还是在于脚本本身。如果一个实例能够让人看得津津有味，看了一遍还有继续看下去的愿望，而不是觉得很没劲，所以他会把这个产品看完。用户想学这种软件是用户买这个产品的主要原因，我们可以通过产品本身的生动性和趣味性给用户增加一种学习的愿望。这样一来，哪怕是不想学这种软件的人，看到我们的产品很有趣，也有可能会购买。就好像公司里大家都喜欢看三维动画的宣传光盘一样。
脚本的生动性还体现在文字优美动听，不生硬。有的脚本虽然很生动，列举了一些生活中有趣的实例，但语句组织的不好，最终效果还是不尽人意。
有时为了增加脚本的生动性，我们会在脚本中增加一些调侃的语句，特别是在脚本中有人物和场景的情况下，此时就应该避免脚本中的调侃语句过多。如果上课时间老师在和学生进行聊天，学生学不到东西，学生就会有抱怨。
4. 科学性
产品本身一定要做到正确和科学。因为我们是在教别人，一传十，十传百，这个影响面是不容忽视的，所以一定要做到正确和科学。就好像老师教学生，如果老师教的是错误的，后果将是不堪设想的。对相关术语的解释，除了参考相关的书籍外，最主要的还是以该软件的帮助文件为主，帮助文件中没有的解释就需要脚本人员自己进行分析了。对于实在无法解释的知识点，可以暂时回避一下。同时，相关的解释一定要相对严谨，不能含糊不清，不能似是而非，模棱两可。
科学性的体现还表现在对各知识点的划分是否科学，因为我们是要由浅到深的向用户传授知识，所以脚本结构和知识点的划分应该具有一定科学性，符合人们学习的一般过程和掌握速度。
5. 逻辑性
脚本的逻辑性主要体现在内容的前后安排上。一般过程都是由浅到深，逐步深入。刚开始都要讲一些简单的初步的知识点。这些知识点不仅包括该软件本身，还包括和该软件密切相关的知识点，例如在讲解网页制作软件时，对Internet、HTML、TCP/IP及互联网上的服务等知识点的讲解就是必不可少的，这不仅有助于加深对该软件的理解，对扩展产品的趣味性、增加用户的知识面也是很有帮助的。在具体讲解一个知识点时，前后语句的连贯性，是不是一气呵成，还是罗罗嗦嗦讲了半天都没有切入主题。对于一个完整的实例，该实例所体现的知识点是不是相关的，是这里讲一点，还是那里讲一点。在写脚本前就对所有知识点进行归纳概括，总结相关的知识点，然后通过一个实例进行讲解，不仅在实例的选材上（某章集中讲建模，某章集中讲材质，某章集中讲渲染等）、内容的安排上（根据选材对内容进行确定）、深浅层次的把握上（由于知识点较集中，所以可以对各个知识点进行细分，讲解多少和深度上也可以灵活把握，从而体现出深浅层次）、章节菜单的确定上都是很有帮助的。但我们都知道一个完整的实例不可能只用到一部分知识点，这就需要我们把握好轻重的度。对于在其他章节中已经讲过的知识点，在本章中就可以一笔带过，或者只进行操作而不进行操作解释（即为什么要这么操作，本步操作的意义），或者在本章中以另一种方法来实现该操作。脚本要合乎逻辑，也要合乎条理。总结出了各个知识点，具体怎么进行安排，先讲哪个实例，后讲哪个实例，知识点的跳跃性是不是太大了等，一个较好的解决方法就是参考某一本书的目录。同时，最忌讳的一点是跑题，因为每个实例都包含具体的知识点、具体的章节，实际上我们是在限制了主题的基础上进行扩展，所以象跑题这样的现象是不应该出现的。
6. 亲和度
一个产品如果能有自己的形象代表是最好不过了，因为熟悉的对象会给人一种亲切感和信任感，这就需要在脚本里添加适当的人物角色和场景。我们当前的产品中都没有这一要求，可以暂不考虑，但对于脚本则一定要体现出一种亲和度。教与学的过程是个双向的过程，虽然我们是老师，但老师有严厉的，也有和蔼的。我们采用和蔼的那一种。在脚本中需要大家彼此间用心交谈，大家共同学习，因而不能采用教训的语气，不能采用上对下的口吻，用户就是上帝，我们要为用户服务。教训的语气让人听了不高兴，让人感觉到一种压力，脚本应该体现出一种人性化的色彩。用户在学习的过程中应该感觉到轻松愉快的心情，而不是紧张和压抑，这也是多媒体教学软件不同于常规课堂教学的一大特点，在脚本中体现出来就是要避免象“你必须……否则的话……”这样的句子出现，可以采用第一人称以“我们可以……”来替代，要让用户觉得是有人在带着他一起学习，而不是强制他去学习。
亲和度的体现除了脚本外，就是美工设计和演示制作了。例如对某个地方的突出显示，除了用一个方框框一下外，可能还会有更好的表现手法。
7. 幽默性
幽默性的体现可能是脚本中最难达到的一点要求了。幽默不仅对文字本身有较高要求，而且更主要的是体现出其内涵，让人觉得有韵味，让人在笑后回味深长。当前的教学软件几乎没有一个能达到这一要求，偶尔有的一些则显得较为做作。幽默并不要在全篇脚本中处处都有，每个实例都能体现一点是最好不过了。
8. 附属文档
脚本写完后，还要编写本产品的内容简介和包装盒上的说明文字。内容简介应该富有概括性和生动性，能够准确表达本套产品的主要内容，能够表现本公司教学产品的教学方式。编写包装盒的生动文字时还应该截取具有代表性的几幅图片。
二、脚本人员要求
1. 绝对熟悉要编写脚本的软件
脚本人员的最基本要求是绝对熟悉要编写脚本的软件，如果连自己都不会就谈不上去教别人了。
2. 能够根据脚本制定人物和场景，具有一定的想像力和创造力
在编写脚本之前，首先可以考虑需不需要在脚本中增加人物对话和场景等。如果需要人物，则人物的起名、表情、动作和相关身份等都应该有个大致的规划设想。如果需要场景，则具体为什么场景，是在一个教室里、办公室里还是其他地方等。脚本人员可以先提出一个大致的蓝图，然后和美工人员进行商讨，因而对脚本人员的第二点要求就是能够制定脚本人物和场景，具有一定的想像力和创造力。如果脚本中不需要人物和场景则这点要求可以忽略。同时，脚本人员应该具有一定的知识面，能够对软件进行一些引申以增加脚本的广泛性和趣味性。同时，脚本本身除了具体的实例讲解外，还应该有一点其他的创作性手法，例如在实例后面添加对本例知识点的巩固方式，例如原有的练习题，在上一个实例中给出下一个实例的提示等等，这需要脚本人员具有相当的创造性。
3. 能够向美工传达自己所要表达的意思
在具体编写脚本过程中，应该能够根据相关内容进行发挥，有的地方可能需要一幅图片或一个动画，因而对脚本人员的第三点要求是能够向美工传达自己所要表达的意思。
4. 具有从全局把握软件的能力，并由此制定脚本大纲
在编写脚本之前，脚本人员需要对软件进行全面分析，总结出应该讲些什么内容，哪些内容是重点，哪些内容可以不讲，如何对各知识点进行归类划分得出一个个的篇章，然后最终确定出本软件可以用多少个实例讲解完。因而脚本人员的第四点要求是具有从全局把握软件的能力，并由此制定脚本大纲。脚本大纲是决定脚本能否通过的依据。
5. 拥有较强的专业技能和一定的艺术细胞
在脚本大纲制定后，脚本人员需要根据各知识点的划分制作出具体的每个实例，实例的选材，实例的代表性、趣味性、普遍性和欣赏性都应该有所体现。选材是否得当，该实例是不是相关知识点的最佳应用和代表，“别人会的我也会！”这一点可以通过实例的普遍性得到体现。有的实例虽然能够完整的体现出很多的知识点，但列举的实例枯燥乏味，这种情况应该尽量避免。本要求是一个技术和艺术的结合点，因而对脚本人员要求较高。拥有较强的专业技能和一定艺术细胞是对脚本人员的第五点要求。
6. 具有较强的分析问题和阐述问题的能力
产品的最基本目的就是为了让人能学会一种软件，因此我们的脚本一定要把问题说清楚。对各知识点的讲解一定要有条有理、有根有据。如何把复杂的问题说的通俗，如何把简单的问题变的有趣，如何对少的内容进行发挥、补充和扩展，如何对重复的内容进行精简压缩，这都需要脚本人员具有一个聪明的头脑。因而脚本人员的第六点要求是具有较强的分析问题和阐述问题的能力。口头上的阐述能力不做要求，但书面阐述能力一定要过硬。
7. 避免太浓重的个人主义色彩，但最好又体现出自己的风格
每个人都有自己的语言风格和写作习惯和兴趣爱好，有时这一点通过脚本可以得到体现。同样的意思，多个人有多种表达方式，但具体的操作步骤文字应该可以得到统一。例如，执行某个菜单下的某个命令，既可以说是单击某个菜单项，也可以说是执行某个菜单项。这可以参考脚本统一规范加以改正。语言风格主要表现在脚本的方言色彩上，我们的产品是面向全国的，因而脚本人员应该避免文字中过多的体现出方言色彩。由于兴趣爱好的不同，脚本人员在列举实例时就可能会偏向于自己喜欢的一面，而忽略其他部分。例如对于编程工具这样的脚本，有的人偏向于数据库，有的人偏向于多媒体，因而在实例中就会出现偏重点。但在实际上，如果所有的脚本看起来仅仅是内容上的不同，用户在观看我们的多个产品时也会感到乏味，会感到太机械化，所有软件就象是一个模特在换衣服，衣服虽然好看，但本质上没有多大改善，也会让人生腻。因而脚本人员的第七点要求就是避免太浓重的个人主义色彩，但最好又体现出自己的风格。个人特色可以通过脚本的生动性、实例的取材、阐述问题的方式等来体现。
8. 具有较强的责任心
在编写脚本的过程中，我们不可避免的会参考一些书籍，有时是对书上的内容进行改编，有时则是全盘抄袭（例如对很专业的术语的解释），二者都是有好有坏。大多数时候我们还是在自己进行创作，因为我们的产品都是以实例的形式出现的，在市场上还找不到这样的书籍和资料。脚本人员不可能精通该软件的方方面面，所以扩展和改编书上的相应知识点是可取的。对专业术语的解释，参考较权威的资料或公认的解释同样也是可取的。我们希望脚本中有90%以上的内容是脚本人员自创的（包括改编过的脚本），这需要脚本人员对脚本负责，对产品负责，绝对不允许抄袭过多的书面资料。因而脚本人员的第八点要求是具有较强的责任心。如果是从外面购买脚本，则在购买之前应该对其声明相关版权和责任问题。
责任心的体现还表现在有没有在脚本中回避自己不会的知识点，对于自己还不会的知识点，可以先将其暂时放下，然后寻找解决方法。不要因为某个地方不会而延误了整个写作进度。
9. 很强的自学和接受领悟新知识的能力
脚本既然成为一个职业，就说明有固定的人来从事他，不能说某个人不会这种软件就不让写这个脚本。作为脚本人员，他的第九点要求就是拥有很强的自学和接受领悟新知识的能力。对于不会的软件，他能够在很短的时间内学会，领悟新知识比别人快，虽然是后学的，但一旦上手后，能够迅速与别人拉开距离，对该软件掌握能够在较短时间内达到一定深度。只有这样，才不会出现用完一个脚本人员后就重新招募新脚本人员的情况发生，因为某个脚本人员所能掌握的软件数量是有限的，不能因为公司里没有人会这种软件就重新找新人（在一定程度上，必要时候还是要进行扩充），如果公司要开发什么样的软件，已有的脚本人员虽然不会，但可以在很短的时间内达到一定深度，对公司来说是极为有利的，因为招募新人也需要一点时间进行培养，原有脚本人员学习也需要一点时间，但后者更能适应公司环境和对脚本的各种要求，所以脚本人员最好拥有很强的自学和领悟能力。如果公司是从外面购买脚本的话，脚本人员应该能够将该脚本迅速转换为自己的知识，然后对其进行修改，使其符合公司对脚本的要求。
三、一点补充
在实际编写大量的脚本之前，可以先对脚本进行一下内容的规划，写出大致的脚本提纲，开始可以尽量多加些内容，以便以后进行筛选，当然脚本提纲基本的特点应该能够体现出教学过程的由浅到深，循序渐进。
开始实际的脚本编写时，不仅仅只是编写脚本，还应该考虑美工的设计和程序的实现。脚本中设计到插图的，应该予以突出标识，写明对美工的详细要求。在程序上可以将实现方式写出来（如添加动画固然生动，但如果角色变化强烈，内容太过于丰富，反而有喧宾夺主的感觉，增加了美工创作的难度，对演示的流畅性也增加阻力，还影响了整个软件的整体风格），上述内容也可以和其它组员进行协商，但一定要在脚本中进行编号，以便有章可循。单个脚本的大致结构是先由人物场景引出本章节要学习的内容，然后是实际的演示操作，最后是人物的对话，对本次学习进行归纳总结，或者引申后面的内容，或者本次内容的扩展。此外还应该完成相关文件的备份，包括最新的脚本、录音修正后的脚本、原始的截图、脚本最后的目录纲要、产品的内容简介和实例相关的所有文件等。
