[DISCUSSIE] Hoofd-movie preloader vs. oEF bytes check (preloaders)

[TrueChaoZ]

Jaja weer eens een topic over die goeie preloaders (alsof er nog niet genoeg langs zijn gekomen :P), maar deze is niet bedoeld als hulp of uitleg topic, maar ik wil eens even jullie mening weten over de volgende stelling.

Update 24-09-2005: Na het antwoord van Roenes zag ik in dat mijn startpost niet helemaal klopte bij de stelling/vraag, en bleek deze niet helemaal te kloppen naar het eerste idee wat ik hierover had, zie mijn reactie in post 4 van dit topic. Hieronder vind je de nieuwe stelling/vraag die hier oorspronkelijk had moeten staan.

Stelling: "Gebruik je voor een website een "hoofd-movie preloader" (meer swfjes) of gebruik je een "oEF bytes check" op frame 1 (één swf)?"

Uitleg Stelling
Als je een website maakt, zit daar in feite altijd een preloader voor, nu kan je deze preloader op verschillende manieren inbrengen in je website. Eén van de simpelste manieren is om een onEnterFrame te maken op frame1 van je Flash movie, deze oEF checkt dan de bytes geladen tegenover de bytes totaal van de movie en zodoende kan je op basis daarvan de movie net zo lang laten stil staan op frame1 totdat de movie volledig geladen is. Nu heb je ook nog de mogelijkheid om een soort "hoofd" Flash movie te maken waarin alleen maar de preloader zit, deze preloader werkt dan in feite via loadMovie of de MovieClipLoader class (zoals je in de onderstaande 3 posts al kan zien naar aanleiding van de oude stelling, MCL heeft hier duidelijk de voorkeur boven loadMovie, indien er controle gewenst is).

Hoofd-movie preloader
Bij de hoofd-movie heb je dus een Flash movie waar zo min mogelijk op grafisch en animatie gebied in komt zodat deze lekker snel laadt. Als er gebruik gemaakt wordt van classes of er toch nog wat zware objecten in deze preloader movie zitten, moet hier uiteraard weer een preloader voor in de vorm van een 'oEF bytes check' (een preloader voor een preloader dus). Doordat de eigenlijke website/applicatie in een aparte swf zit heb je met de hoofd-movie de volledige controle over het inladen van die swf. Maar een nadeel is het bijhouden voor elke website van 2 aparte Flash movies. Als je geen standaard preloader movie maakt betekent dit natuurlijk wel meer werk, zeker als de website al uit meerdere movies bestaat.

oEF bytes check
Het grote voordeel van deze preloader methode is natuurlijk dat je één movie hebt om te onderhouden, maar een nadeel schuilt volgens mij in het feit dat je geen volledige controle hebt over het inladen van je flashmovie zelfs al laat je de movie op frame1 een 'oEF bytes check' script doorlopen en zorg je ervoor dat alle zware items pas na frame1 worden geladen. Voor de kleine applicaties is dit op zich geen probleem, voor grotere applicaties kan het wel een probleem zijn. Met 'geen controle' bedoel ik hier: "op het moment dat de flashplayer de code op frame1 gaat uitvoeren kan de movie al voor een bepaald deel zijn ingeladen, aangezien deze preloader code in de movie zit, die aan het laden is".

Nu wil ik graag weten van jullie hoe jullie hierover denken? Gebruiken jullie altijd een aparte "hoofd-movie preloader" als oplossing? Of geven jullie juist de voorkeur aan de simpele "oEF bytes check" oplossing? En wat denk je dat het met de snelheid van het laden doet? En geeft de preloader dan wel de juiste informatie aan de gebruiker weer? Etc...

Update 24-09-2005: De oude stelling/vraag staat hieronder in greyed out tekst.

Stelling: gebruik je voor een website een MovieClipLoader (twee swfjes minstens) of gebruik je een oEF loadMovie op het 1e frame (één swf)?

MovieClipLoader Website Preloader
Bij de MCL heb je dus een hoofdmovie (een preloader movie) waar zo min mogelijk op grafisch en animatie gebied in komt zodat deze lekker snel laadt. Als er gebruik gemaakt wordt van classes of er toch nog wat zware objecten in deze preloader movie zitten, moet hier uiteraard weer een preloader voor in de vorm van een oEF loadMovie (een preloader voor een preloader dus). Doordat de eigenlijke website/applicatie in een aparte swf zit heb je met MCL de volledige controle over het inladen van die swf, hoewel het bijhouden voor elke website van 2 aparte swfjes (als je geen standaard preloader movie maakt) natuurlijk wel meer werk betekent.

loadMovie Website Preloader
Het grote voordeel is natuurlijk dat je één movie hebt om te onderhouden, maar een nadeel schuilt volgens mij in het feit dat je geen volledige controle hebt over het inladen van je flashmovie zelfs al laat je de movie op frame1 een oEF loadMovie script doorlopen. Voor de kleine applicaties is dit op zich geen probleem, voor grotere applicaties kan het wel een probleem zijn. Met 'geen controle' bedoel ik hier: "op het moment dat de flashplayer de code op frame1 gaat uitvoeren kan de movie al voor een bepaald deel zijn ingeladen, aangezien de code in de movie zit die aan het laden is".

Nu vraag ik aan jullie, hoe denken jullie hierover? Gebruiken hier mensen MCL ook voor gewone websites (zonder spelletjes of andere echte aparte dingen die ingeladen moeten worden)? Wat is de mening over loadMovie, geeft deze functie eigenlijk wel genoeg controle over het inladen? En wat denk je dat het met de snelheid van het laden doet? En geeft de preloader dan wel de juiste informatie weer aan de gebruiker? Etc...

[Roenes]

Interessante topic dit :) Goed initiatief :)

Voordat ik mijn mening hierover geef, wil ik even iets aanstippen wat jij zegt:
Bij de MCL heb je dus een hoofdmovie (een preloader movie) waar zo min mogelijk op grafisch en animatie gebied in komt zodat deze lekker snel laadt. Als er gebruik gemaakt wordt van classes of er toch nog wat zware objecten in deze preloader movie zitten, moet hier uiteraard weer een preloader voor in de vorm van een oEF loadMovie (een preloader voor een preloader dus).Dit is volgens mij onzin. :) Of je nou een MCL of een loadMovie gebruikt, je hebt altijd een "hoofd" swf die "sub" swfjes inlaad. Je kan deze inrichten hoe je wil. Of je loadMovie of MCL gebruikt maakt daarvoor niet (veel) uit. Daarom is het ook niet zo, dat als je MCL gebruikt, dat je dan een grotere kans hebt dat je een preloader voor je preloader moet knallen. Deze kans is even groot als bij het gebruik van loadMovie (Oke, MCL is een class waardoor het misschien een paar kb meer is, maar niet aanzienlijk veel meer waardoor dit een minpunt is van MCL)

Zo, nu dat opgehelderd is ga ik mijn mening hierover geven ;)

Als je enigzins controle wil hebben over het load proces, dan vind ik dat je dom bent als je loadMovie gebruikt. (Er vanuitgaand dat je voor een FP ontwikkeld die zowel MCL als loadMovie ondersteund) loadMovie bied standaard geen enkele ondersteuning voor het load proces. Preloader moet je zelf schrijven, je moet zelf afvangen wanneer het laden klaar is, enz enz. MCL heeft hier standaard een aantal methodes voor die heel makkelijk in het gebruik zijn. Ik vind het daarom dom om uitgebreide functies te schrijven die hetzelfde doen als MCL. Ik bedoel, je kunt zelf een functie schrijven die kijkt of er progressie in het laden zit, een functie die kijkt of het laden klaar is, een functie om te kijken of er iets fout ging met het laden, enz enz. Maar waarom die moeite doen (het is niet heel veel werk, maar toch) als die standaard al in Flash beschikbaar zijn? Je hoeft alleen de methode nog maar in te vullen. Het werkt dus makkelijker en scheelt je aardig wat tijd met ontwikkelen. Dit is uiteraard alleen voordeel als je iets van het load proces in de gaten wil houden.

Wil je geen preloader gebruiken en hoef je niet perse af te vangen wanneer het laden klaar is, dan kun je natuurlijk gewoon loadMovie gebruiken. Dan is het gewoon een kwestie van smaak. loadMovie is dan misschien zelfs makkelijker aangezien het 1 regel is en MCL weer niet.

Dus mijn (voorlopige) conclusie: Wil je controle hebben over het load proces, gebruik dan MCL. Heb je geen controle nodig, dan volstaat loadMovie ook

[Tha Narie]

Groot nadeel van MCL is dat hij (bijna) niets doet in de bandwidth profiler. Verder istie helemaal top!

[TrueChaoZ]

Oops, startpost error...
Eerst wil ik even aanstippen dat mijn oorspronkelijke bedoeling was om dit topic te laten gaan over het gebruik van MCL of een oEF bytes check voor het laten zien van een preloader, hierbij is het dus niet zo dat je loadMovie gebruikt, in mijn stelling lijkt het wel zo alsof je de keuze hebt uit MCL of loadMovie, en daardoor klopt mijn startpost niet helemaal. Hierdoor kwam Roenes ook op de proppen met een juiste mening over een stukje uit mn startpost, aangezien dat wat ik gezegd had inderdaad niet klopt.
Of je nou een MCL of een loadMovie gebruikt, je hebt altijd een "hoofd" swf die "sub" swfjes inlaad. Je kan deze inrichten hoe je wil. Of je loadMovie of MCL gebruikt maakt daarvoor niet (veel) uit. Daarom is het ook niet zo, dat als je MCL gebruikt, dat je dan een grotere kans hebt dat je een preloader voor je preloader moet knallen. Deze kans is even groot als bij het gebruik van loadMovie (Oke, MCL is een class waardoor het misschien een paar kb meer is, maar niet aanzienlijk veel meer waardoor dit een minpunt is van MCL)
Inderdaad als je MCL tegenover loadMovie zet, en dan ben je dus 'altijd' bezig met het inladen van swfjes (of images), maakt het inderdaad vrijwel geen verschil uit of je loadMovie gebruikt of MCL voor de grote van de 'hoofd' swf (en zal daar vaak een kleine 'bytes check preloader' voor gebruikt worden).

En ik denk dat Roenes met zijn (voorlopige) conclusie ook wel gelijk een einde maakt aan deze eventuele discussie, want ja dat is inderdaad vrij logisch als je toch al swfjes aan het inladen bent. Voor de oorspronkelijke stelling die ik voor ogen had is deze informatie wel van belang, maar ik wil toch graag terug naar de stelling die ik eigenlijk wilde posten, ik zal hiervoor de startpost iets wijzigen en een nieuwe stelling lanceren in de eerste post.

Update 24-09-2005: Na het antwoord van Roenes zag ik in dat mijn startpost niet helemaal klopte bij de stelling/vraag, en bleek deze niet helemaal te kloppen naar het eerste idee wat ik hierover had, zie mijn reactie hierboven in dit bericht. Hieronder vind je de nieuwe stelling/vraag die hier oorspronkelijk had moeten staan, voor meer uitleg hierover wil ik je graag verwijzen naar de startpost.

Stelling: "Gebruik je voor een website een "hoofd-movie preloader" (meer swfjes) of gebruik je een "oEF bytes check" op frame 1 (één swf)?"

[Roenes]

Ben ik weer :D

Zeker wel een meerdere-swfjes-site. Dit heeft vele voordelen: 1) je kunt delen van de site apart ontwikkelen. 2) het laden van data gaat gefaseerd. 3) data wordt alleen geladen die de gebruiker opvraagt en dus niet meteen alles. Vooral deze laatste vind ik een belangrijk punt (samen met 2 eigenlijk) De gebruiker geeft aan wat hij wil zien, dus alleen dat hoeft geladen te worden. Stel je hebt een grote site, dan wordt het totaal al snel een aantal mb's. Als je dan alles moet downloaden om bijvoorbeeld een bepaald gedeelte van de site te bekijken heb je 1) overbodige data gedownload en moet je 2) lang wachten voor je iets kan doen en 3) is je site niet user friendly.

Dus ik vind het niet meer dan normaal dat je alleen laad wat de gebruiker wil. Hierdoor hoeft deze minder lang te wachten en wordt alleen de nodige data opgevraagd. Dus sites die uit 1 swf bestaan, zijn een beetje achterhaald vind ik :)

[TrueChaoZ]

Ok maar die meerdere-swfjes-site heeft nog steeds 1 swf die werkt als frame voor de rest (vaak zit hier al het menu/achtergrond/etc in). Wat voor preloader stop je dan in dit frame, een "oEF bytes check" of maak je nog een aparte swf met een MCL/loadMovie er in?

Voorbeeld Tree van meerdere-swfjes-site met "oEF bytes check"
- meerdere-swfjes-site- menuitem1.swf
- menuitem2.swf
- menuitem3.swf
- audioplayer.swf

Voorbeeld Tree van meerdere-swfjes-site met aparte swf met MCL/loadMovie
- preloader-swf- meerdere-swfjes-site- menuitem1.swf
- menuitem2.swf
- menuitem3.swf
- audioplayer.swf

Of de pagina's en/of onderdelen daarvan apart worden ingeladen maakt mij in feite niet uit, ik ben het met je eens dat als er grote onderdelen tussen zitten dat je deze beter apart 'on demand' kunt laden. Maar bij voorbaat je site "user unfriendly" noemen als alles niet apart ingeladen wordt vind ik wat ver gaan, ik ben namelijk ook wel eens op sites geweest waar ieder onderdeeltje zowat apart ingeladen werd, en dan gaat dat continu laden toch ook echt op je zenuwen werken. Ik bedoel het is toch geen HTML site. Het beste hierbij is goed kijken of het ook echt nodig is om iets in te laden, er is toch vaak een pad wat mensen volgen in je website. En vergeet niet dat je 1 swf kan gebruiken als je OOP werkt met AS2 classes.

[Roenes]

Ok maar die meerdere-swfjes-site heeft nog steeds 1 swf die werkt als frame voor de rest (vaak zit hier al het menu/achtergrond/etc in). Wat voor preloader stop je dan in dit frame, een "oEF bytes check" of maak je nog een aparte swf met een MCL/loadMovie er in?Zelf gebruik ik dit soort dingen niet vaak, maar ik heb in 2004 een website gemaakt voor een EK poule. Dat had ik als volgt opgebouwd: ik had 1 hoofd swf die alleen een achtergrond bevatte en een aantal lege mc's. Hierin werden het menu/content/stand/etc geladen. Dus mijn hoofd swf was maar een paar kb max en die had dus geen preloader nodig. De overige swfjes werden ingeladen op het moment dat daarom gevraagd werd door een klik op een menu item :)


ik ben het met je eens dat als er grote onderdelen tussen zitten dat je deze beter apart 'on demand' kunt laden. Maar bij voorbaat je site "user unfriendly" noemen als alles niet apart ingeladen wordt vind ik wat ver gaanVind ik niet. Doordat alles geladen moet worden, heb je een langere wachttijd. Oke, het overgrote deel van de mensen heeft wel kabel of adsl, maar dat is geen excuus om maar meteen alles te laden. Ook roep je content op waar de gebruiker niet om gevraagd heeft. Vind ik ook niet netjes. Daarom vind ik dat je een site om die reden user unfriendly kan noemen. Maar dan ook alleen op dat punt he. Voor de rest kan het gerust nog lekker werken en zo, maar op dat punt is (voor mij) de site dan heel erg user unfriendly :)

[TrueChaoZ]

Zelf gebruik ik dit soort dingen niet vaak, maar ik heb in 2004 een website gemaakt voor een EK poule. Dat had ik als volgt opgebouwd: ik had 1 hoofd swf die alleen een achtergrond bevatte en een aantal lege mc's. Hierin werden het menu/content/stand/etc geladen. Dus mijn hoofd swf was maar een paar kb max en die had dus geen preloader nodig. De overige swfjes werden ingeladen op het moment dat daarom gevraagd werd door een klik op een menu itemZaten er in deze aparte onderdelen geen preloaders?

Vind ik niet. Doordat alles geladen moet worden, heb je een langere wachttijd. Oke, het overgrote deel van de mensen heeft wel kabel of adsl, maar dat is geen excuus om maar meteen alles te laden. Ook roep je content op waar de gebruiker niet om gevraagd heeft. Vind ik ook niet netjes. Daarom vind ik dat je een site om die reden user unfriendly kan noemen. Maar dan ook alleen op dat punt he. Voor de rest kan het gerust nog lekker werken en zo, maar op dat punt is (voor mij) de site dan heel erg user unfriendly :)Ok inderdaad kan dit het geval zijn bij veel websites, maar dan nog vind ik dat je uit moet kijken dat je niet zoveel laad schermpjes elke keer krijgt dat je bij het switchen van pagina's/onderdelen elke keer eerst weer naar een laadschermpje zit te kijken. De overloop van het ene onderdeel naar het andere onderdeel en ook subdelen op 1 scherm moet vrij makkelijk en snel gaan. Ik probeer hier absoluut niet te pleiten voor alles in 1 keer inladen als iets echt groot is, maar ik ben wel van mening dat dit soms nauw luistert en er niet echt een standaard voor is :)

Daarnaast is het bij online applicaties (waar je vaak dus wel alles gebruikt) net zoals bij offline applicaties naar mijn mening handiger om eerst de applicatie even te laten laden (moet niet te gek lang duren natuurlijk), zodat er tijdens het werken met de applicatie geen lange laadtijden ontstaan. Gelukkig hebben ze hiervoor ook Flex uitgevonden waar je een beter laad-management hebt dan in Flash, maar goed ik dwaal af ;)

[Roenes]

Zaten er in deze aparte onderdelen geen preloaders?Toen niet, had wel gemoeten maar wegens tijdgebrek heb ik die toen achterwege gelaten :)

maar dan nog vind ik dat je uit moet kijken dat je niet zoveel laad schermpjes elke keer krijgt dat je bij het switchen van pagina's/onderdelen elke keer eerst weer naar een laadschermpje zit te kijken.Ben ik zeker met je eens. Maar je hoeft ook niet overal een preloader voor te zetten vind ik. Bestanden waarvan je een preloader over het algemeen maar 1 a 2 seconden ziet, hebben geen preloader nodig vind ik. Hierdoor valt het niet zozeer op dat er weer wat geladen wordt en heb je niet het idee dat je constant tegen een laadscherm aankijkt. Je hoeft de gebruiker niet overal van op de hoogte te stellen ;)

Ik bedoel: bij html sites zit je soms ook even tegen een wit scherm te kijken terwijl een subgedeelte geladen wordt, maar daar krijg je geen preloader bij. Als het laden niet te lang duurt, is er ook niemand die je erover hoort klagen. Dit is nou eenmaal ingebakken bij internet gebruikers :)

[Ea.Z]

lol...
kheb nie alles gelezen maar van wat ik gezien heb wil ik even dit kwijt

**er is nog een derde soort preloader (deze is heel oud, maar ik gebruik hem nog altijd voor mijn _root-movie in mijn swf) (dat is een preloader die je zelf samen raapt uit de getBytesTotal en getBytesLoaded en dan kun je nog een Loading - animatie maken ook)

** een onEnterFrame preloader voor een MCL class movie? is voor niets nodig... als iemand op en flash site komt geef je hun toch wel de keuze voor broadband smallband, en op basis van die keuze krijgen ze een zware, of lichtere swf... bij mensen met een broadband connectie ga ik pas preloaden vanaf de 50-100kb, anders maak je de swf onnodig zwaar met een preloader die meer kb's is dan de rest van die swf:p)

** MCL class is inderdaad een super class waarmee je heel wat kan uisteken. maar kzou deze ook nie om de haverklap gebruiken om een kleine movie in te laden... Ik gebruik da liever om foto's in te laden... als je een swf maakt die te zwaar wordt, voorzie je die toch lekker van een preloader? :p

--Hoopt dat dit geen herhaling was van wat hierboven staat... (te lui om alles te lezen :p) --

[Tha Narie]

**er is nog een derde soort preloader (deze is heel oud, maar ik gebruik hem nog altijd voor mijn _root-movie in mijn swf) (dat is een preloader die je zelf samen raapt uit de getBytesTotal en getBytesLoaded en dan kun je nog een Loading - animatie maken ook)

Dit is een onEnterFrame preloader.

[TrueChaoZ]

Ik bedoel: bij html sites zit je soms ook even tegen een wit scherm te kijken terwijl een subgedeelte geladen wordt, maar daar krijg je geen preloader bij. Als het laden niet te lang duurt, is er ook niemand die je erover hoort klagen. Dit is nou eenmaal ingebakken bij internet gebruikersMaar dit is natuurlijk juist iets waar je met Flash vanaf kunt zijn ;) Dat is mijn inziens juist het mooie van het kunnen over laten lopen van Flash-pagina's in elkaar. Maar ja als die overloop continu een preloader is dan is dat ook niks, het mooiste is als de preloader op de achtergrond wel loopt maar dat de gebruiker er niks van merkt, dan hoef je ook geen informatie te laten zien aan de gebruiker. Natuurlijk zit je dan wel weer met de verschillende gebruikers (ADSL/kabel/telefoon), maar de meeste doelgroepen hebben tegenwoordig wel ADSL/kabel (en die gaan eind van dit jaar weer omhoog in snelheid, dus zelfs de goedkoopste abonnementen zijn vrij snel) en niet te vergeten ADSL2+ komt eraan. Dus alleen als een pagina-in-pagina overgang erg lang zou duren (in feite dan alleen bij telefoon-internet) zou je alsnog een preloader kunnen laten zien.

** een onEnterFrame preloader voor een MCL class movie? is voor niets nodig... als iemand op en flash site komt geef je hun toch wel de keuze voor broadband smallband, en op basis van die keuze krijgen ze een zware, of lichtere swf... bij mensen met een broadband connectie ga ik pas preloaden vanaf de 50-100kb, anders maak je de swf onnodig zwaar met een preloader die meer kb's is dan de rest van die swf) Ouch... een splashscreen is heel erg not done in 'usability-land'. En zie ook mijn reactie hierboven over internet-verbindingen en preloaders in die setting.

**er is nog een derde soort preloader (deze is heel oud, maar ik gebruik hem nog altijd voor mijn _root-movie in mijn swf) (dat is een preloader die je zelf samen raapt uit de getBytesTotal en getBytesLoaded en dan kun je nog een Loading - animatie maken ook)Dit is een onEnterFrame preloader.Ik denk ook net als Tha Narie dat jij het hier hebt over hetzelfde soort preloader als een "oEF bytes check", maar dan in de vorm van meerdere frames met een loopje er in, met een "onEnterFrame" zit dat loopje al ingebakken en hoef je daar niet meerdere frames voor te gebruiken. Ik vind dit dus dezelfde soort preloaders aangezien ze altijd in de movie zitten die ge-preload moet worden en niet als een aparte swf die de te preloaden movie inlaadt.

[Ea.Z]

ow ja!
had ff onEnterFrame en ifFrameLoaded verwart... sry... dan...

[Folkert]

sjee topic startert, wat een bak verhaal staat er om evt de stelling te kunnen onderbouwen ;). terwijl het toch echt gewoon een vraag is die je stelt :P of eigenlijk een keuze optie.
Helaas kan ik geen van beide kiezen en val dus buiten de boot :P
Kortom, meestal laadt ik de 'main' applicatie in de hoofdmovie.
De main applicatie kan vervolgens van alles bevatten wat er gepreload gaat worden.
Dus van beide een beetje ;)

[TrueChaoZ]

sjee topic startert, wat een bak verhaal staat er om evt de stelling te kunnen onderbouwen ;). terwijl het toch echt gewoon een vraag is die je stelt :P of eigenlijk een keuze optie.I know...en het was meer bedoeld als uitleg....ik was nog even aan het oefenen voor dat ik met een echte stelling kwam ;) (zie Code-becommentariseren, dat is wel een echte stelling) Discussies voeren hier op FF is lang geleden, en ook voor mij was het even geleden dat ik een stelling moest verzinnen :D

Helaas kan ik geen van beide kiezen en val dus buiten de boot :P
Kortom, meestal laadt ik de 'main' applicatie in de hoofdmovie.
De main applicatie kan vervolgens van alles bevatten wat er gepreload gaat worden.
Dus van beide een beetje ;)Ik denk dat veel mensen beide veel gebruiken, zeker voor applicaties, die toch vaak aparte onderdelen bevatten die je inlaadt 'on-demand', een simpel voorbeeld is dan natuurlijk een video/music player die apart ingeladen wordt. Ik zelf gebruik wel eens een hele aparte flashmovie om dan de 'werkelijke' site in te laden (en daarbinnen kunnen dan weer aparte onderdelen geladen worden), maar ja echt handig in onderhoud is dat niet. Maar ja het is niet echt erger dan met HTML ofzo natuurlijk, in Flash werk je nog altijd met minder bestanden dan met HTML als het goed is ;)