Section 2.2

     For the most part, upon entering this job, I was expected to have a decent knowledge of ActionScript, Macromedia Flash's programming language, as well as enough of an understanding of Macromedia Flash to get work done. My on-the-job work consisted on 4 main projects.

     First off, I was given an already-completed project, involving the company's aim towards Home Schooled children, and was asked to make it web-accessible. The way the file was done (i.e. made to go to CD-ROM or DVD, not web); the file size was way too big, and needed to be shrunk. I basically had to completely revamp the flash movie, using different techniques to make sure that the movies and sounds included did not make for an oversized file. I ended up needed to incorporate a few techniques, including diminishing the file size of the movie and sound clips that were imported into the main timeline, as well as using the built-in compression options. This also meant that I needed to use different ActionScript code in order to bring the movie and sound clips in differently. The way things were being done, the main timeline was attaching the clips to holder objects on the stage. This meant that each individual clip needed to be loaded and linked into the library. Unfortunately, this linking required every file to be embedded into the movie, adding each one's file size to the overall movie's size. Now, when putting such a movie onto a DVD or CD-ROM for distribution, size is not as much of an issue. But, for my task, I needed to find a way to get the necessary clips into the movie without linking them into the library. Luckily, there is such an option. By loading the clips from outside the movie, it may increase the number of files that are uploaded to whatever server the movie will be accessed from, but it greatly diminishes the size of the movie itself, making it easier for users with slower internet connections to be able to download and view the demo.

     The second task I was asked to work on consisted of a little more creativity on my part. I met with my supervisor to go over some basics of what kinds of projects that people in this company would be looking to do. Using this information, I was to create a multi-page form, using Flash of course, that employees in the company can fill out and submit to my supervisor, somewhat like a Project Request form. First off, I took the information I acquired, and created a sequential UML diagram to show how the information would flow through the pages in the form. Next, I set off to create a basic graphical design of how I wanted the pages in my form to look. Granted, I knew that what I was doing was preliminary, and it would ultimately be up to my supervisor to determine whether that layout would be sufficient, or if it would need to be touched up. It took me about a week to get that task done, as part of my "basic design" meant to make sure the pages would link together correctly (i.e. go forward when the "next" button was clicked, etc). After showing my design to my supervisor, he went ahead and created the template I would be using for the form, complete with company logo and better-looking color scheme. After re-linking the pages to follow the flow, I then ran into somewhat of a brick wall. My next part of the project required some webpage design experience (including HTML and PHP). I was asked to take the information collected in the form and somehow relay it to my supervisor via email, or web-based database, or any other way I could figure out. My first idea was to take the information, pass it from the Flash form to a PHP page, which would then display the information on a page, accessible by my supervisor. Unfortunately, I did not have much experience in the ways of MySQL, so making a web-based database to store all the information ended up not being such a good idea for my knowledge base. As I searched for another possibility, I came across the idea to transfer the information from Flash to the PHP page on the server. From the PHP page, an email would be sent out to my supervisor, containing all the information from the form, in a readable format. This plan was then put into action, and after a day of code writing (and a few more of code debugging), I managed to get a working version of the PHP form completed. My supervisor and I tested everything to make sure things were working correctly, and then the project was completed and marked off as such. This project really helped me to learn how project demands can change throughout the development period, and that one has to be flexible and accepting to the changes desired by the project champion.

     The next project I worked on during my stint at FLT required a lot more responsibility and planning. Every year, Rosetta Stone puts out flash animation movies to kiosks around the country (in such places as airports, malls, etc), advertising their products and appealing to those who would most likely be in the market for such software. I was informed that I would be working on the animations for this year's series of movies. Nine movies were originally to be made for the year's series, which consisted of two back-to-school movies, six winter holiday movies, and one New Year's movie. Unfortunately, as happens in very many projects, things did not work out exactly as planned. My supervisor, who was supposed to be helping me through getting started on the work for this project, became very busy himself with another, even bigger assignment for the company. This caused our communication on my project to diminish, making it more difficult for me to have any direction on the tasks at hand. A week later than I was supposed to, I received the script from the head of marketing, allowing me to have a general idea of what would be said in the movies, and giving me a better understanding of what time of images/animations would be required to get the point of each movie across. As I began my search for images to represent the movies to their fullest, my supervisor became more and more busy. Regrettably, this led to this project being turned over to a more experienced animator, to make sure that the work would get completed on time. Even though I didn't manage to actually get anything done on this assignment, it probably taught me the best lesson during my whole internship: Be prepared for anything. Not many interns or new hires, including myself, realize how easily issues can arise that would throw a wrench into a project they're working on. One always has to be ready for anything to happen, as very little in the working world is set completely in stone.

     The last two weeks of my internship were dedicated to a new project that had become increasing important to complete. Rosetta Stone has recently released a Student Management System (SMS) program that helps teachers to keep track of their students learning a new language. Our company had decided to release a sort of tutorial movie that would show instructors the various features of the SMS, using step-by-step instructions on how to perform different tasks in the program. We were running somewhat behind on getting this task done, so the pace of work picking up dramatically in those last couple weeks. I immediately delved into the task of creating the inner movies, the ones that show the different steps involved in the SMS, including how to manage students, create classes and view reports of students' studies. While I worked on getting the inner movies done, my co-worker Blaine designed the templates and opening splash screen that would ultimately give the final product its nice look. There turned out to be 15 inner movies that would be needed for the final product, which included 13 movies explaining the features of the product, and introduction and a conclusion. Each movie had required sound clips that were recorded by Duane Sider, director of marketing/sales and the voice of most of the Rosetta Stone advertising content. Part of creating all those movies included the necessity to rename and work the sounds correctly into each animation. This process became somewhat tedious, as I was basically doing the same task repeatedly, only with different clips. As a result of this, I worked longer days the final week at FLT, where I would come to work at 8:30 am, and leave usually no earlier than 7 pm. Once all these movies were completed, it came time to piece everything together. Timing was interesting, as the annual buyers' meeting was scheduled for the Thursday of my final week. This year, one of the big products the buyers wanted to see was, you guessed it, the SMS Instructional Video. We managed to establish a canned version of the video for the buyers to see. It included the basics of the SMS information, making sure that the buttons, graphics and animations all worked correctly. The meeting went quite well (as I was told, my supervisor would rather not have us interns in that meeting, to make sure no questions were directed towards us, the more inexperienced ones). One major development of the meeting was to extend the information included in the SMS Instructional Video. This meant, to us, that the video we had been working to finish would NOT end up being the final product. My supervisor and the other flash designer were setting aside a 3-week block in the beginning of September to take what we have so far, and extend it to meet the needs of the buyers. On the plus side, however, our work made it easier to nibble and bit at here and there, to finalize a working form that is a complete success.