Trimming Bandwidth

Hello . . . our company has a bandwidth testing process with a target threshold of 56 kbps.  I've recently submitted a course through bandwidth testing and it did not pass the threshold.

The individual that did the testing noted that there were significant spikes each time the screen changed.  This course does have audio, and he felt the spikes might be attributed to the course trying to load audio for each slide, and perhaps the bitrate for the audio is too high.  I'm using the default 24 kbps for audio, so I don't think that's the issue.

I've heard in the past that Articulate Presenter is set up to progressively download screens as the user progresses through the course.  I'm wondering if these are really the spikes he's seeing.

If I've heard correctly, is the progressive download process Presenter uses documented anywhere?

Is there anything else I should look at to try and trim bandwidth?

Thanks.

3 Replies
A @work

Hi Brian,

Articulate cues up the slide you are watching and then progressively downloads the next two slides in sequence. So when you start a course, after it loads the player, it downloads slide 1 and the slide 1 master slide, and plays them, then it downloads slides 2 and 3 while you watch slide 1. When you move to slide 2, it downloads slide 4, since 3 is already downloaded and ready to play. If you skip ahead to slide 12, then it would download and play 12, as well as 13 and 14 in the background. This preloading is a good thing as it allows the next slide to play instantly when cued and can help users on slower connections have the time to download the files before they are needed. It doesn't preload any of the flash objects, engage, quizzes or web objects - these are all downloaded when cued by the player. (Does anyone know if it preloads the other master slides if the master changes within the 3 slides? I don't think it does, but I'm not sure.)

So yes, when the slide changes, Articulate downloads at least 1 slide or as many as 3 slides, in addition to any of the extra objects on that first slide, and you would see additional bandwidth used as it does. The intial bandwidth demand of the course when first loaded will eventually lessen once all of these elements have been dowloaded, the course should be lighter and easier as the viewer settles in to watch, at least if the course has a linear design. How much bandwidth required for each slide depends on your player settings and your course content.

The audio settings sound good. 24 Kbps is very lean. So it's probably the visual demands.

Here are a few places to cut bandwitdh using the player settings:

1. In the "Presentation Options" menu, there is a "Quality" tab with several options for compressing your graphics. The lower the quality, the better the bandwith performance. The default is 75% quality, so sliding it down will increase performance. This menu also has a setting for Resize Factor, and this can also be cut to reduce bandwidth.

2. Also in "Presentation Options" in the "Publish" menu, you can publish your course using a lower frame rate. I think default is 30, like film, but depening on your content, you may be able to use 15 frames or lower. If you rarely have animation, you can go quite low.

A couple of things you could do to trim bandwidth from the content side:

1. Length of your slide content is a factor. Longer slides have bigger file sizes for their SWF than shorter slides. If a slide is 8 minutes long, it will require exponentially more bandwidth to download than a slide that is 30 seconds long. If you have several long slides, you could divide the audio across two or three or more identical slides and hide the copies in the player interface so they appear as a single piece of content. This way the player is downloading several small and easy to handle chunks of information on a more frequent basis rather than a single long and demanding file.

2. Use master slides effectively by putting as many of your design elements into your master slides as possible. When you do, all the design elements in those masters only need to download once when the master slide SWF is first played, but they stay visible while all the other slide SWF enter and exit. This means the bandwidth demand of each of the slide swf will be lower since there will be less graphic information contained in each slide.

3. Master slides work best (in the context of bandwidth) when you have several slides with the same master consequtively.

4. The more pixels on the slide that change at once, the more information needs to be transfered. So certain animations will take up more bandwidth than others. First, the size of moving objects can play a factor. If you animate a series of full screen pictures, you will use more bandwidth than if you animate a series of half screen pictures with the same settings. Likewise, a lot of simultanious movement of several smaller discrete images can also take up more bandwith than the same animations as a series of events. It's about the overall movement on the screen at once - more information in each frame= higher bandwith needs.

5. Also the type of motion in the animation can be significant. If you fade from one full screen picture to another, every pixel on the screen is changng and will require the maximum bandwidth allowed under your settings. On the other hand, applying a circle animation to transition between the same full screen pictures is very efficient, since only a small part of the image is changing at any time. In the case of a cicrle transition, only the pixels on the edge of the circle change while everything else remains the same for any given frame.

6. Likewise the length of an animation can also impact bandwith. A 5 second slow fade requires more than twice the information of a 2 second fade with the same settings. In this example, every pixel is changing in every frame due to the fade, so the longer the fade, the more frames have to contain the fade information.

There are probably a bunch of other ways to reduce bandwidth and file size, but those are my go to places. When you start the design with bandwidth in mind, it's a lot easier to preserve your high quality settings. If you already have the course designed, it's usually much easier to pull down the quality to get better performance, even if it means a little more pixelation in the final product. It's just a matter of how much time you have to tweak it. Hope that's helpful

Brian Duvall

A@OSPI . . . great explanation on the progressive download process.  I don't know if this will make my IT guys feel any better, but I may pass it along just so they understand a little better how Articulate behaves.  I was actually wondering about how the Slide Masters load as well.  I have used Masters where I could, but was a little worried that might be part of the problem.  I wasn't sure if Articulate was trying to load all the Masters at once, and that was causing a big spike up front.

If I can't work it out through some other means, I may downgrade the Quality a bit through the Presentation Options menu as you suggested.  My screens do have some simple animations, but not a ton.  So the frame rate may be especially helpful.

Your other suggestions are great . . . I'll relook at them all, but I think I'm already following most of them.

A @work

Thanks! I am fairly confident that the masters download only when prompted and not all at once on the onset of the course. I'm not sure if they pre-load automatically as part of the 3 slide preload, but my gut says they don't. So if that proves true, then you would only download a master at a slide on which it changes. Anyone confirm that?