BtM ik ben bezig met een artiekel daarover, maar dat heb ik even moeten laten rusten omdat ik last van RSi heb gehad. Maar ik wil het hier wel even voor je posten
kan ik er meteen wat feedback op krijgen, ik geloof dat van de groep hier alleen Waxle, mr10 en Owen het hebben gelezen.
deel 1:
Zen and the art of preloading
On preloading
Preloading may sound like a relatively new concept in the world, but actually it is based on a much older principle. Preloading at it’s most basic level is creating anticipation for an event. A ‘preloader’ can also serve as an indicator that a certain event is going to happen. Think of the count-down clocks we saw in the entire western world at the ending of the last millennium. They were in a sense ‘preloading’ or ‘creating anticipation for’ the year two thousand.
In a more conventional way the preloader has become part of modern day communication. The first preloaders were bare necessities on old computers. Loading a tape of information took quite some time and an indicator or a ‘progress bar’ was essential. Should you go out and make some coffee or just read a bit while the game on your MSX was loading?
Preloading really took off in the Flash-age. Since Flash 4 there was this beautiful command called getFramesLoaded. All hipsters could go totally berserk in their designs and graphical experiments as they could now let their (online) audiences wait for the content to load. Of course they could have done that earlier, but if a common internet user sees an empty page for more than point-five seconds he automatically thinks something has gone wrong and he clicks away. Not with a preloader, now anticipation can be created by a simple ‘loading’. This automatically indicates that the computer is not broken but is ‘loading’ some graphically intense page.
Preloading as a cultural icon
Since then the preloader has become something of a cultural icon. Much like the screensaver. With the screensaver it’s much more artistic though since there is really no more use for a screensaver these days. The screensaver was initially intended to keep screens from ‘burning in’ when a specific picture or application was on the screen for too long. Screens and monitors don’t burn in anymore but the screensaver persisted; now more as an artistic or comic gadget then a necessary tool.
The preloader has adopted some of these characteristics. On major television channels there can be seen ‘preloaders’ anticipating a commercial break or the next broadcast. All embedded in some flashy design. Preloading on a television is plain stupid.
I can’t press this enough, so I’m saying it again:
Preloading on a television is plain stupid!
Preloading on a television is one of the of the most idiotic examples of horseless carriage syndrome (McLuhan 1968).
On a television there is nothing to preload! Unless the editor is at that moment working on the next edit. Which he isn’t. The only sensible preloader on television would be one preloading a rerun in slow-motion of a brilliant move in a sports game.
Preloading stupidity
The only real preloaders nowadays are made for slower web connections on graphically intense sites. This stands to reason, but luckily there are enough people who can mess with this simple principle.
I’ve seen preloaders of over 200 or 300 kilobytes, which would take a slow web connection about 10 to 20 seconds to load. So I have to wait for my preloader to show.
The whole point of preloading is then completely wasted, users will switch the site off, expecting a 404. The artistic elements that have been inherited by the preloader mess up the essential thing that makes a preloader work. A preloader should be as small as possible, and does not need to reflect the artwork in the site ahead.
It should not come as a surprise that some designers have gone so far as to ‘preloading their preloaders’ which means you see a progress bar, telling you it’s ‘loading’ and then when it finishes another, more sophisticated, progress bar appears telling you it’s now ‘really loading’. What were you thinking it was doing before, Einstein?
Couldn’t you have loaded the whole thing in the first loader? I’m waiting for content nobody has asked for, I’m basically anticipating more anticipation, and personally I think that is pretty lame.
Well then, having explained the basics of preloading we can now proceed to the interesting stuff: preloading in flash and how to get it right.
Readers without a basic understanding of flash can now stop reading and go and play crack attack or some other highly addictive game.
Deel 2:
(en dit is meer technisch, en ook nog niet helemaal af)
Preloading in flash and how to get it right
We have come a long way since the days of ifFrameisLoaded, we now have in flash a complete armory at our disposal to preload everything neatly and nice. The most important of these are the movieClip.getBytesLoaded() and movieClip.getBytesTotal(), but even those are obsolete when compared with .getProgress, _framesloaded, .onLoadInit and all kinds of nifty commands telling you exactly what you want to know about the bytes and bits streaming into the users computer.
We’ll get to those later, but for now let’s stick with the basics;
preloading is essentially measuring the time it will take to load, and communicating that to the user. Then he or she knows if he should go out and get some coffee or just read a bit in a comic book.
Okay, the code is very simple; first make a movieClip of a progress bar and make it hundred frames (so the bar should be empty on frame 1 and full on frame hundred). Add a stop(); on the first frame and place it on the stage and call it ‘loader’.
The actionscript should be something like this:
code:
1
2
3
| Loaded = theThingYouWantToLoad.getBytesLoaded();
Total = theThingYouWantToLoad.getBytesTotal();
Loader.gotoAndStop( Math.round (loaded/total * 100) ); |
Nobody is expecting you to take ‘the next step’ in preloading, a progress bar with ‘loading’ will do. Everybody knows what it is you want to communicate and they can see how fast things are progressing. Sure, you have the loader information up to the last byte and you could do all kind of nifty shit with it. You could feed the bytesLoaded into a sinus function and apply it to an object on stage, make it spin or wiggle faster and faster as the bytes come streaming in. Heck you could take a Bob Ross painting and see it develop as more and more information drips into your site.
But why would you?
The preloader is not the work of art you want people to see; it’s just a necessary bit of information so your users don’t click away. It’s telling people they have to wait, which is essentially a bad thing. Don’t shout.
I’m not saying all the preloaders should be the same, a bit of variation is cool, but don’t overdo it. Before you know it people are preloading the preloader because you had to cram so much information in it. Therefore:
The second rule of preloading is: keep it small.
Preloaders are build to appear before everything else. They should appear within a second of loading a page. Although we in the West all have fat ADSL or cable connections ranging from 128k up to 1024k and more, there are still large parts of the world where they have 56k6 modems or lagging satellite connection. If you want your page to be truly international you should limit the size of the preloader to 4k. This is not that hard, 4k is a lot of room for just some vector locations and a bit of code.
It’s rather small unless you want to use gradients, neat pictures or other graphical intense stuff so don’t do that. All the graphical stuff is exactly what you are preloading, don’t mess it up. (note to the mac users: don’t cram 128 bits imagery in there!)
There are those of you that are now in the league for the ‘the smallest preloader in the world’. I’m sure you are now thinking of using only one element and duplicating that in the preloader, or building everything out of dots. Well, if you plan on making the smallest preloader: don’t. I’ve already beaten you to the punch:
The smallest preload in the world ( with a progress bar )
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| (coded for Flash 6 and ActionScript 1)
(It could be even smaller if you remove the textformat and the rounding ;) )
function p() {
createTextField('o', 0, 100, 100, null, null);
o.autoSize = 'right';
o.setNewTextFormat(new TextFormat('_sans', null, null, null, null, null, null, null, 'center'));
onEnterFrame = function() {
if (getBytesLoaded() >= getBytesTotal() & getBytesLoaded() > 4) {
delete onEnterFrame;
o.removeTextField();
} else {
o.text = '__Loading__\n[' + '||||||||||||||||||||||||||||'.substr(0, (33 * (getBytesLoaded()/getBytesTotal()))) + ']\n' + Math.round(getBytesLoaded()/1000) + 'kb of ' + Math.round(getBytesTotal()/1000) + 'kb';
}
}
}
p();
stop(); |
Now if all is well you got all the tools to make an awesome preloader, which basically means you can make a very efficient one.
Still, if your site is amazingly large because you want to present pictures of mars in their full size or you have a fetish for body hair on women’s uvula and want to show pictures of that in an amazingly large frame you’re still not there.
These are not the days of the MSX where people really went to make coffee as loading times could exceed an hour. Even with the best preloaders in the world people will click away if they have to wait for more then a minute, so:
The third rule of preloading is: keep it swift
We want our preload times to be under one minute; on a 56k6 modem (5k/s) I can load 300k of data. That may not be much. Basically you want your site to be under that number, but that is not always an option. Here are a few solutions you could take into consideration.
If it must take forever, try telling people how long forever takes. Waiting is never nice, but if people have to wait for something they like to know for how long. A simple progress bar might not be sufficient because with long loading times the progress bar would animate really slow. It might be interesting to point out how many (estimated) seconds it will take to complete the loading.
To achieve this you need to know how many bytes are loaded every second, how many bytes are loaded at this moment, and how many bytes the total load is. The latter two can be asked with the getBytesLoaded() and the getBytesTotal(), the first one you need to calculate. For this you make a little cycle of one seconds and check how many bytes are actually loaded. The (estimated) load time is then:
( bytesTotal – bytesLoaded ) / bytesPerSecond.
Or in actionscript:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
| Loaded = theThingYouWantToLoad.getBytesLoaded();
Total = theThingYouWantToLoad.getBytesTotal();
Loader.gotoAndStop( Math.round ( loaded/total * 100 ) );
setInterVal(bytesPerSecond, 1000)
function bytesPerSecond() {
currentLoad = Loaded
perSecond = currentLoad – lasLoad
lastLoad = currentLoad
}
someTextField.text = Math.round(perSecond) add “s” |
Still, this is only a temporary solution, if people are told that they have to wait for several minutes they still think something like ‘screw you’ and click away. So a very interesting option is to give people something to do; preferably something addictive.
A game like ‘pong’ or even a small version of ‘pac-man’ can easily be fitted into 4k of preloading space. Other options are ‘simon says’ or ‘lingo’. If you add a highscore script you even might get some traffic on your preloaded and people will be mailing you with questions like ‘can’t you put that preloader separate so I can continue playing?’. True story.
The best solution though is to preload content in chunks. Only preload a certain picture when it is asked, and not beforehand. Preload it in the background if you wish, but it might be an option to only load the framework of a site and then use preloaders to load the different content areas leaving the preload time well under the one minute. If you would count all preloading times together you might come on several minutes, but the user experiences it differently because he gets handed a bit of information before some preloader starts again. Basically this is the hard part:
Flash and preloading dynamic content
Now you might have got some php backend running somewhere. So flash is getting all kinds of variables. In this case it is a good time to build a host file in which all content is loaded. Now since content is streaming or comes in blocks (one picture at a time…, song after song…) we only need to preload static elements.
If you work with ‘placers’ like I usually do a function can be described called:
code:
1
| function placeObject(place, object) { statement } |
We could also call this function:
code:
1
| function objectPlacer(object, place) { statement } |
But that is all semantics.
What we want to do here is describe a way to place objects on the stage. An object can be a mp3 file placed into an mp3 player or a picture placed at a certain location on the stage.
Within this function a preloader is embedded (or called), taking the form and the place of object. If you have several standard size places to put stuff in (for instance: a window for slides and a window for thumbnails) you can make 2 standard loaders for each place.
So let’s say we are building a slideshow and we have 2 places where we send pictures to; a list with thumbnails, and a larger windows for the full size pictures. In this case we need to preloaders; one for the thumbnails and one for the larger picture. There are a few things to consider then.
Firstly the shape and size of the preloaders. Since there will be many thumbnails preloading you want to keep their preloaders simple and light. Another thing to consider here is the load-order. Mr10 was kind enough to point out that when you try to load over 16 or more objects into flash the connection will be lagging. So you might want to consider scaling the number of thumbs down, or create a load order, loading in one row of pictures at the time.
Still you will have a lot of preloaders staring at the user at the same time. It might be nice to make a loader-animation that is somewhat tilable, so all the loaders together look like one animation loading in the thumbnails. You can also join every row or column of thumbnails together in one loading-array and make a preloader per set of thumbs.
The preloader for the bigger window displaying the larger pictures will be in the view of the user longer, since there is more to load. You might want to consider making this preloader a bit more sophisticated since the user will be looking at it longer. (see also the third rule of preloading)
When all is well and done you should be able to make this simple example with these basic principles of preloading. But what if you got a variety of dynamic content instead of same-sized pictures. What if there are complete flash files to be loaded along side music, video and other broadband content. You need a strategy. So here goes:
The rules of engagement
When you are setting up a framework or portal in flash you need to index all the kinds of content that can be presented within that framework. Surely you need to build players for that content, but what you also need is a way of creating anticipation for the content, and give feedback on the loading-progress of content. Say we want to build a portfolio that supports streaming video, streaming mp3, gallery’s and a large amount of text. That’s basically covering all ‘broadband content’.
Now I really detest the word ‘broadband content’ since it reminds me of ‘multimedia computer’ which was singing around at the end of the nineties. It’s stupid to speak of a multimedia computer when you know that in a few years every computer will have on-board sound and the ability to playback video. In that aspect it’s also pretty stupid to speak of ‘broadband content’ when you know that in a few years all content will be presented in a ‘broadband manner’, it’s simply a question of time. What we really need to know it how to make sure that people don’t need to wait for that content to come streaming in, and surely they don’t need to be kept in the dark about how many seconds it will take to get some of the data played.
What we need is a way to determine what content should be loaded in what manner too
The plan of battle
Some content can be preloaded, yes. But other content should not always be preloaded, but it should be loaded so far as to be able to play. This content I refer to as ‘streaming media’. ‘Streaming media’ is another word that makes my skin crawl, because in essence all media is streaming, but I won’t go off-topic about this again.
What I need to do is take a look at all the content I want to port through my portal and think of a way to load it in neatly.
There are the pictures in the galleries. There can also be pictures in the container or hostfile. These are for instance background pictures, menu items. Smileys etc. Pictures can only be loaded in flash as a whole.
Sadly enough pictures can not be streamed although there was an amazing browser once that actually streamed pictures in. First it would give you a really pixilated version of a picture which then would gather resolution as it came loading in. You could simulate this and it would make an amazing preloader, but sadly enough, flash (and the jpg file codec) are not designed for this.
Next there is the sound. Sound in flash comes in two different flavors, streaming and non-streaming. If you can you should make all sound streaming. There is a simple reason for this, if you stream it you don’t need to preload it all at once. The drawback here is that you have a lag time connecting to the mp3 file and that you can’t make it loop without a nasty hick-up at the end. So for all menu-clicks and beep-sounds you need to make a little place in the library where they feel comfy. For all other sounds (including irritating background-loops) make them streaming. You are not only getting rid of that nasty loop, but you are also making your application faster.
Then there is the video. It doesn’t really matter if you use .swf or .sfv files for this (although I find using swf a bit more convenient) but whatever you do: stream your video-files. I can’t even begin to explain how far up your arse your head is if you are not streaming the video. Even a small video file is usually well over 200k and stuffing that into your library is eating space (and bandwith) fast. Secondly it’s not necessary. Like audio, video is a linear file and we have a special weapon for these kind of files.
Finally I have the framework of my site, which is a host-swf. This consist of essential parts of the site or this can consists of only an empty swf containing only your actionscript code. I’ll be talking about the how and why of this decision later on, but keep in mind that this has to be loaded as well. (a couple of hundred lines of code easily surpass the 5k threshold I set in the ‘keep it swift’ section).
Usually this file also contains the library, and even if you use shared libraries, this can get really big and messy. So keep in mind that:
The best defense is striking first
Flash MX 2004 has some weird options concerning preloading the library content. I ran across this when I was doing a site for a clothing company. The main timeline had no objects, I called everything from a library fill using the attachFrom Library(). When preloading this site there was a library to download in the first frame. This meant it wouldn’t show anything until the library was loaded. This is a problem because my ‘loading’ animation would not show until everything was loaded already. You have to keep in mind that unless you do something about it Flash loads everything in the first frame; even stuff that isn’t actually there. This goes for components and component objects as well. Luckily you can change this using your ‘publish settings’.
To correctly load a flash (that is, first load the preloader, then start loading the rest of the site do the following; go to your publish settings and find the ‘settings’ under your Flash-tab. Then set ‘export frame for classes’ on 2 and put the preloader on frame 1. This solves the problem for components.
Now set your entire library on frame 3, just drag and drop it on the stage; the stuff will now not load in advance, but after frame one. You can then put your site on frame 4 to which the preloader will jump after everything is loaded. This way you can manage your preloading-load using the timeline.
Now the trick is to load only what you need in advance, and the rest during runtime.
Er komt nog iets over
Weakening the enemy (background loading, predicting user behavior etc)
Wapons of war: Buffering (over streaming events)
Fight in Style (over het gebruik van preloaders als artestiek element)
Het is misschien nog wat lang als ik het zo overlees
misschien dat ik het wel in driieen of vieren ga hakken
/u/776/crop5de4d07a1f5c1.png?f=community)
:strip_exif()/u/29747/avakrul.gif?f=community)
/u/7685/ruinmytune-60x60.png?f=community)
:strip_exif()/u/80759/monstermania_small.gif?f=community)
er is genoeg te vinden hoor, maar meeste flash dingetjes (zoals problemen :strip_icc():strip_exif()/u/932/crop5f8b22f8e0571_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/113752/v-logo_tweakers.jpg?f=community){kind=logo}
:strip_icc():strip_exif()/u/63621/dutch_flag_minbuza.jpg?f=community)
:strip_icc():strip_exif()/u/40490/avatar23.jpg?f=community){kind=avatar}
