Heightened security concerns as a result of the tragic events of September 11, prevented our traditional format for Connecting Technology (CT) Fall 2001 in San Diego; but disappointment turned into an exciting opportunity for the CT team to excel in a new avenue. With only thirty days to plan — we produced the first Virtual CT.
The primary objective of CT is the sharing of knowledge. To achieve this objective in a virtual setting we had to first identify each element of knowledge sharing normally performed in the traditional CT format and then establish a virtual method to achieve the same objective. While a physical symposium permits a wide range of knowledge sharing options, such as one-on-one networking between industry and government attendees, a virtual Internet information exchange is much more limiting. We chose only those major knowledge-sharing elements that we could virtually reproduce: 1) Vendors sharing information about their products, 2) A learning environment for attendees to glean the most up-to-date information from government and industry, and 3) Q&A (question and answer) sessions between attendees and government and industry representatives in a live setting.
As stated by Dan Porter, Department of the Navy Chief Information Officer (DON CIO), in his opening remarks for Virtual CT, "This is the first time we have actually stressed the paradigm of CT — connecting people via technology. This event is being brought to you completely through cyberspace — whether it's chat rooms, video presentations, or roundtables — all of it will be done this year through the magic of CT."
Many of our virtual guests expressed an interest in how we constructed CT online so read on to learn how we successfully staged a cyber symposium. Three of the CT team's IT wizards explain their areas of expertise and share lessons learned in producing CT for Web interaction.
Video Presentations on the Web
By Rick Paquin
The first challenge we faced was how to receive the presentations from speakers/vendors at our site in a short period of time. We set up a File Transfer Protocol (FTP) site and an e-mail account, and invited both vendors and speakers to either upload or e-mail their videos and MS PowerPoint (PPT) presentations. We established a deadline to ensure that we would have the necessary time to re-process and post the virtual information. We requested that Audio Visual Interleave (AVI) formatted files be restricted to a 320x240 format and compressed, if possible.
Due to the short notice, speakers were concerned that they didn't have enough time to produce a presentation by our deadline so we were forced to adjust our deadline to just a few days prior to going live! We also learned that our FTP site, which is shared with other command network traffic, was unreliable and too slow; so many of our participants attempted to e-mail their presentations to us. Although we had an e-mail account without file size limitations, industry representatives found that their companies had file attachment size limits that prevented them from e-mailing their files to us. The only other option available — was to send us their presentations on compact disk (CD) via the U.S. Mail, Federal Express or United Parcel Service (UPS). Because of unexpected new mail restrictions — due to the anthrax threat, we did not receive most of our virtual material until the very last minute!
Our second challenge was working with very large video files. We knew that some video presentations would be large, however we were not expecting 30-minute presentations that were nearly 500MBs in size! Initially we had decided to simply store the video presentations on our Web site and have guests download them as ZIP (compressed data) files. We had initially ruled out video streaming delivery because our Web site didn't have sufficient bandwidth. In addition, AVI files would have to be converted to an Advanced Streaming Format (ASF) or streaming media files, which would be time consuming for our staff. The option of downloading the Audio/Visual (A/V) files proved a major problem though. For some receiving sites, downloading even one 100 or 200MB file could take hours or even days! For that reason, we re-evaluated our video delivery methods; and decided to stream the video files from a commercial server at two different rates. We had one streaming rate for low speed (or dialup connections) and a higher quality version — 128k (kilobyte) — for higher speed connections. This required converting each video presentation to an acceptable streaming audio or video format that could be played using the standard MS Media Player. Conversion was very time consuming since audio and video files totaled about 3.2GBs (gigabytes). Using Adobe Premiere, we converted each file to an ASF format and posted each streaming file on our commercial server just minutes prior to going live. The CT staff simultaneously made last minute changes to our Web page code so that it would call the user requested video file from the commercial server.
Premiere 6.0 has many video conversion methods available, but we encountered some problems. We found that AVI to ASF conversions proved very reliable if the frame size of the original AVI didn't exceed 320 x 240, and only one video stream rate was used. Adobe cautions retaining the original video frame size for best results. If you lower the frame size below the frame size of the original file to create smaller files, the file size does not decrease much, and the video quality decreases very rapidly. We found that the options for developing variable bit rate files (those files that contained both low and high video streaming rates in one file) were unsuccessful because they did not stream well at the lower rate with any of the ASF viewers we tried. Therefore, we had to develop two different stream rate files (56k and 128k), with two button choices on our Web page. We also had one MPEG file with a frame size of 640 x 480. It required a streaming rate of at least 500k, which, would have greatly exceeded the bandwidth available for most users. We attempted to use a 1.0 GHz (gigahertz) notebook and Premiere to convert to either an MPEG or ASF file with a lower streaming rate; but this method was not successful without severely dropping frames or introducing video/audio synchronization problems. In fact, simple AVI to MPEG conversions also exhibited serious synchronization problems for a video that ran more than 30 seconds. Adobe technical support staff could not find a solution so we had to rely strictly on AVI to ASF single rate file conversions for video files on our CT Web site.
PowerPoint Presentations on the Web
By Doris Bohenek
To make PPT presentations available on the Web, we initially tried converting the PPT file format to HyperText Markup Language (HTML) format, but we found that some PPT options did not convert properly when saved as HTML and results varied depending on which Web browser was used. To maintain the original slide effects and animation, we retained the original PPT format and saved each file as a PPS (PPT Show). Using this method, as each PPS file downloads, the Internet Explorer (IE) browser opens the file in a PPS format within the browser window.
The presentation files were reviewed for screen formats, standard font usage, note content and embedded objects. For example, speakers may have included personal notes and other content that may not have been intended for audience viewing, but some browsers allowed the audience to see the notes.
There is a nice feature in PPT that gives a live feel to a presentation enabling the speaker to record an audio narration. We had one presentation with audio, which conveyed a very professional and personal touch. Audio narrations can be created within PPT by using a microphone connected to your sound card or by using a built-in microphone — available on most notebooks. A more professional studio quality file can be created by recording WAV (a format for storing sound files) files outside of PPT. This format also allows better editing capabilities. The WAV file must be embedded as a sound effect on each slide to avoid linking problems when publishing the presentation on a Web server. This method is tedious and is time consuming; but offers more flexibility in recording and editing. To reduce time and labor involved with embedding pre-recorded WAV files, the best method is to record narrations within PPT:
1) From the slide in which you would like to begin narration, select the Slide Show menu, and then Record Narration; 2) Select the Set Microphone Level to run a microphone check routine. I received an error on several systems, but the microphone still functioned properly; 3) To embed the audio in the presentation file — DO NOT select the check box entitled Link Narration — click the OK button; 4) Record your narration on each slide by clicking the mouse or spacebar for the next slide; 5) To complete, press the Escape (ESC) key. PPT will ask if you want to save the timing with each slide. If you answer yes, this will save the timing for advancing each slide with your presentation. If changes are needed, individual slides can be re-recorded.
That's it! Keep in mind this may cause the size of the presentation to increase depending on the amount and quality of audio recorded.
A "LIVE CHAT" SESSION
By Tony Virata
Our first challenge in planning for chat sessions was to find the best format for the virtual interaction between speakers and attendees. We investigated the options of using a message board — a type of electronic bulletin board, where questions and answers are posted in public view; and a chat forum — a real-time interactive correspondence between a speaker and the audience. The message board would be quicker to implement and maintain because questions and answers are posted at the user's leisure with very little monitoring and maintenance required. However, we thought that a message board was too impersonal. Our top priority was to connect people just as the traditional CT format does.
Instead we used the chat forum option because it would offer real-time action between speakers and audience. We used a moderator to host the Q&A sessions to more closely resemble the format for CT symposia. We also used screeners to intercept questions from the audience to determine the appropriateness of the question before passing questions to the moderator. We set up several training sessions for staff and speakers, and held mock chat sessions to simulate the real thing. Using the chat forum proved to be more challenging because it involved a lot of software configuration tinkering,; system testing; coordination to schedule speakers; and training for the moderators and question screeners — with less than three weeks to prepare! Our second hurdle was choosing chat software. We investigated WebBoard chat tool, but we quickly learned that WebBoard would not work because we needed the ability to screen and monitor the conversations so we selected ChatSpace, which has these options in their tools known as ChatSpace Community Server and LiveEvents.
Next — installation and configuration, according to the ChatSpace documentation, the minimum hardware requirements for installation requires a Pentium III 500 processor and 128MB memory. Since our Web server exceeded requirements, we did not anticipate any problems. However, we later learned that ChatSpace uses port 80, the same port used by our Web server, which caused conflicts. Our quick fix was to assign ChatSpace to another port, such as 2000, but we found that this would be a problem for speakers and the audience connecting from the Navy Marine Corps Intranet (NMCI). This is because the NMCI blocks all non-standard ports. The ultimate solution involved setting up another Internet Protocol (IP) server to host ChatSpace, thus maintaining chat operations on port 80. We did not have enough time to order another server, so instead, we modified another PIII 500 desktop machine, added more RAM, and installed ChatSpace Community Server and LiveEvents.
In the LiveEvents software, we set up the various user accounts and permissions for speakers, moderators, and screeners. We configured the virtual chat room with the appropriate greetings, banners, and welcome messages. Next, we added a few macros, using JavaScript, for the "canned" messages that the moderator would use during the course of a chat session.
After few rocky starts and network problems, we overcame our technical difficulties and refined our moderator/screener process to a point where we felt confident to go live with Virtual CT.
On October 30, 2001, Virtual Connecting Technology became a reality. CT history was made with the first virtual chat session. The system and procedures we so diligently practiced worked flawlessly. However, our initial glee was short lived. During the third chat session the network connection between our chat server and our speaker at a remote site had deteriorated to the point where the speaker could no longer log into his account. Thinking quickly, we established a telephone connection to the speaker and verbally read the audience's questions and typed the speaker's responses for Web viewing. Not the most elegant technical solution to the problem, but we managed to finish the session successfully.
The network connection between the remote speakers and the CT site became the biggest problem for providing flawless live chat. When we plan future live chat sessions, we will test the performance of the speaker's network prior to going into a live chat. Despite difficulties with two of the remote speaker's network connections — the chat sessions came off without any major technical incidents. This constitutes a success for Virtual CT — and all of the very talented CT team professionals!
Please join us for Connecting Technology Spring 2002 at the Pavilion Convention Center, Virginia Beach, Virginia.