Web 2.0-versus-Flash dilemma

[Verwijderd]

Vrolijk typ ik mijn code in mijn editor, een beetje css hier, een beetje php daar, html, javascript.. Trots scroll ik door mijn lap code doorregen met allerlei verschillende talen die ik in de afgelopen +/-6 jaar eigen heb gemaakt. Maar ik verstar.. . en bedenk dat DHTML en AJAX..oftewel Web 2.0 eigenlijk voortzetting is van de traditie om toch in 'pages' te werken, maar dan wel de eigenschappen van Flash!

Nou heb ik veel kennis opgedaan van CSS-hacks, JavaScript workarounds etc. om het maar werkend te krijgen op alle browsers... Maar waarom gebruiken we dan geen Flash. Het is platform-onafhankelijk, 90% van de gebruikers heeft de plugin al (dit zou hoger zijn als Flash de standaard was, en zelfs een standaard integratie van browsers worden), Flash heeft databaseondersteuning en je hoeft geen talloze regels, stijlen, tradities etc. te leren. Nou heb ik niet al t veel ervaring met Flash, maar ik ben nog geen dingen tegengekomen die Flash niet kan, wat Web 2.0 wel kan. (ik kom zo op het usability en browserinvloed issue). Het is eerder andersom. Je kunt met Flash een aantal zaken meer/beter. Maar ik zie vast iets over het hoofd. Ik ben absoluut geen Flash aanhanger. Het liefst zie ik iemand reageren die zegt: "ja maar ho eens.. PHP en Flash gaan niet samen, en met PHP kun je zus en zo wat flash niet kan, en nooit zal kunnen."

Betreft usability van Flash: problemen zoals onleesbare teksen voor braillemachines etc, zijn niet meer van de orde. De oplossing zit deels in Flash MX (alt teksten worden gescreent) en als dit niet ondersteund is, kun je een cloakpagina maken die alleen zichtbaar is voor zoekmachines en braileapparaten... En dan heb je een puike oplossing voor elk wat wils!! Geen website die daar tegenwoordig aan voldoet wel?

Maar wat zie ik over het hoofd? Waarom maken bedrijven nog steeds miljarden omzet met fosiele development? Ik ben zelf bijna afgestudeert Interaction Design bachelor.. dus ik kan makkelijk praten als het gaat om usebility. Als ik zin en tijd krijg, kan ik die ene flashsite doorzoekbaar maken met Ctrl+F, backbuttons maken en alle andere browser prularia. Heb ik voor niks curriculum gedaan? Graag jullie mening

[Boss]

Ik denk dat er maar 1 groot probleem is: Flash is een commercieel formaat, is dat niet van Macromedia? Zij bepalen de ontwikkelingen en de standaarden. Daar houdt men niet zo van bij het opstellen van standaarden.

AJAX etc. is allemaal open standaarden.

[Jero]

Ondanks wat je net zei is "ouderwetse" HTML nog steeds veel gebruiksvriendelijker. Je hebt bijv. geen plugin nodig. Zonder plugin kan je dus niks. Denk ook aan zoekmachines. Kunnen die alle content in de Flash app zien? Ik dacht het niet.

Een ander nadeel van Flash is de snelheid. Het is zooo langzaam en aangezien bandwidth nog steeds schaars is, is het dus van groot belang dat bestanden op het internet zo klein mogelijk zijn.

Een derde nadeel noemde je zelf al: het is geen standaard. HTML is een open standaard waardoor werken met deze taal een stuk makkelijker is. Je hebt geen enorme Macromedia Suite nodig om je website te bouwen. Je gebruikt gewoon je favo tekstbewerker. Werkt ook nog een stuk sneller.

[T-MOB]

1. Een flashsite is slecht te doorzoeken met een zoekmachine. Het maken van cloakpagina's levert dubbel zoveel werk bij het onderhouden van je site. Bovendien zou je cloakpagina voor het beste resultaat goed semantisch moeten worden opgemaakt. Als je dat al voor elkaar hebt is het imho onzin om daarnaast een flashsite te ontwikkelen...

2. Op een flashsite werken een hoop zaken niet meer zoals ik dat als gebruiker graag zie. Ik doorzoek een pagina niet met "ctrl-f" maar met "/", mijn vrienden geeft de voorkeur aan "F3" en "ALT-E" en dan "F". Je kunt niet in een flashpagina het gedrag van alle mogelijke browsers implementeren (en als je dat wel doet is, is flash dan nog wel een voordeel?).

3. Ik zit er als gebruiker niet op te wachten om op elke site een andere back-button-implementatie te moeten gebruiken. Noch zou ik het apprecieren als ik geen bookmark kan doen naar de huidige pagina in de website. (Deze kritiek is trouwens net zo hard van toepassing op sites die draaien op AJAX en aanverwante DHTML technieken.).

4. Een flash site is star, de maker definieert precies hoe het eruit moet komen te zien. Mocht dat voor de gebruiker onhandig zijn omdat ik de verkeerde resolutie draai, kleurenblind ben of ueberhaupt slecht zie dan kan ik op geen enkele manier de site bruikbaar maken. Op een html-pagina kun je met een paar klikken de rendering naar je hand zetten: text vergroten, kleuren uitschakelen, plaatjes uitzetten, etc.

Waarom je HTML en CSS development fossiel noemt ontgaat me verder even. Ik zou flash eerder als een achterhaalde technologie bestempelen omdat het louter gericht is op het weergeven van een enkele visuele representatie van een stukje informatie. Voor ontwikkelaars wordt het juist steeds relevanter om de informatie zoveel mogelijk los te koppelen van de weergave. Afgezien van het voordeel voor de ontwikkelaar dat het beter te onderhouden is op die manier is het ook voor interoperabiliteit aan te raden. Internet bestaat in toenemende mate uit meer dan alleen computers met monitoren, muizen en toetsenborden. Echt internetten met PDA's en mobieltjes is al mogelijk, en het zal op niet al te lange termijn wel redelijk "common" zijn. Een flash site maak je daar bijzonder lastig geschikt voor.

[sanderb]

Dan ga ik het hier even opnemen voor flash...

Flash is een commercieel formaat, is dat niet van Macromedia? Zij bepalen de ontwikkelingen en de standaarden. Daar houdt men niet zo van bij het opstellen van standaarden.

Niet helemaal juist. Flash actionscript is ECMA...net als javascript.
Ik durf zelfs te beweren dat door de snelle huidige ontwikkeling van flash, dat ECMA methods zal overnemen/beschrijven die actionscript wel al kan, en javascript niet.
Flash is een commercieel format, maar de standaard is volgens mij niet gesloten. Je kan een swf ook met andere programma's genereren. actionscript kun je zelfs in notpad typen als je wil

Een ander nadeel van Flash is de snelheid. Het is zooo langzaam en aangezien bandwidth nog steeds schaars is, is het dus van groot belang dat bestanden op het internet zo klein mogelijk zijn.

vector graphics zijn nou juist 1 van de voordelen van flash. Het is NIET langzaam, en al helemaal niet groot. Dat veel flash applicaties bloated zijn en boordevol animatie zitten is geen fout van flash.

Je hebt bijv. geen plugin nodig. Zonder plugin kan je dus niks.

html wordt net zo goed door een browser weergegeven. De penetratie van de flashplayer is bijna net zo hoog als de penetratie van javascript.
Het grote voordeel van die plugin is dat het zonder problemen crossbrowser is.
sterker nog, het is crossbrowser en crossplatform,scalable en dus onafhankelijk van schermgroote.

Flash heeft natuurlijk een hoop nadelen, en voor heel veel applicaties is het ook niet de juiste keuze,. Hetzelfde gaat imo op voor ajax.De discussie hier is volgens mij niet wat de voor- en nadelen van flash tov html/css zijn.
Ik heb me ook verwonderd over het "buzzwoordje" AJAX...iedereen heeft het erover alsof het het ei van columbus is. Feit is dat de meeste nadelen van flash net zo hard aan ajax technieken kleven.

De vergelijking tussen php en flash gaat al helemaal niet op. php is serverside en flash clientside. communicatie tussen flash en php is zeer goed mogelijk.(en ook veel gebruikt)

Flash heeft bij veel mensen nog steeds een slechte naam. In de replies hierboven zie je al een hoop vooroordelen niet nergens op gebaseerd zijn.
Hoezo zou ik geen applicatie voor een mobiele telefoon of pda kunnen maken? Het gaat zelfs makkelijk. flashplayer 7 voor pocketpc is net uit. en voor de mobieltjes hebben we flashlite.
het geschikt maken voor deze media heeft dan voornamelijk met schermgroote en input te maken. Alle vector images worden vanzelf gescaled. Ik hoef geen rekening te houden met god weet hoeveel verschillende resoluties. Als je je applicatie goed heb opgebouwd is het zelfs heel erg makkelijk te porten naar bijvoorbeeld een pda.

Is het je opgevallen hoeveel sites met video tegenwoordig gebruik maken van flash? er is geen makkelijkere implementatie mogelijk van video binnen je site dan dat. goeie compressie, maar een videoplayer die je helemaal naar je eigen hand kan zetten geintegreerd in je site.. in tegenstelling tot windowsmediaplayer of quicktime players.
Hetzelfde geldt voor geluid. Voor velen van ons bestaat het web uit text en images. informatie zoeken is belangrijk, en dus moet die informatie snel zichtbaar zijn en snel te doorzoeken zijn.
Internet is echter meer dan informatie. het is ook entertainment.
jaren geleden waren images nog zeldzaam op internet. mensen hadden de bandbreedte daar niet eens voor. Nu zie je internet steeds multimedialer worden. Een webpagina bezoek je niet alleen voor de informatie die er op staat, maar ook voor het plezier dat je eraan beleeft. De beleving is soms belangrijker dan de informatie. met websafe color gifs hoef je niet meer aan te komen.

De fout die veel mensen met flash gemaakt hebben, is dat ze het gingen gebruiken voor doeleinden waar het (zeker op dat moment) niet geschikt voor was.
Hetzelfde zie je nu gebeuren met ajax. Soms kan het echt superhandig zijn. Vaak streeft het het doel voorbij.

Als ik op live.com op een link klik met mijn middelste muisknop, dan wil ik dat die (zoals ik gewend ben) in mijn firefox een nieuwe tab opent met die pagina. Helaas werkt dat niet.
Voor mij zal live dus al nooit een alternatief voor google kunnen worden...zolang dat ene kleine dingetje niet werkt.

Usability issues spelen dus net zo hard voor ajax als voor flash.
Eigenlijk kun je er heel kort over zijn. Gebruik de juiste techniek voor de juiste doeleinden.
Je kan ook wel alle webpagina's in pdf online zetten. Ziet er ook overal hetzelfde uit. Is makkelijk te printen, schaalbaar, doorzoekbaar enz.... prettig werkt het echter niet.

[Verwijderd]

Een paar goeie argumenten heb ik gehoord, dank daarvoor, maar ben nog niet overtuigd Ik denk dat de structuur waar T-MOB het over heeft van cloakpagina's niet veel meer hoeft te zijn dan <h1><h2><a><p>...als je eenmalig een template maakt, dan kun je die voor elke website vullen met een XML-bestand die je vervolgens aan je flash app koppelt. Bovendien is het gifjes knippen, css'en, bugoplossen, browsercompatible maken dusdanig tijdrovend dat een ervaren flasher in die tijd vijf flashsites kan maken (bij wijze van).

Het gedrag van je toetsenbord is beter ondersteund in Flash dan in javascript. Natuurlijk spreek je niet direct de browser aan..tenminste..die kan de flash site niet meer manipuleren... maar so what? Je maakt een keer een framework waarin alle toetsen gedefineerd zijn als je dat al zou willen. Mensen die backslash willen gebruiken zijn dusdanig it-ontwikkelt dat ze hun eigen scripts kunnen schrijven die daar een ctr-f van maken. Ik heb het dus niet over die 0.1% van de internetpopulatie die anders wilt zijn.

Betreft de bookmarks... daar moeten we toch een keer vanaf... we willen dynamische content.. en dat dan bookmarken.. vervolgens bedenken we RSS feeds... uiteindelijk zijn we het cirkeltje rond en komen we toch weer uit op de home opslaan en dat je browser die combineert met je cookies. Als je vandaag een bookmark maakt, dan is deze morgen "expired".

Usability: Flash biedt meer mogelijkheden tot inzoomen en de mogelijkheid om kleurtjes te veranderen a la minute, lettergrootte, de geur, de smaak.. en mocht je dus geen flash template voor ogen hebben zoals ik me dat bedenk.. dan kun je standaard.. al met rechtermuisknop inzoomen. In html veroorzaakt dit in meeste gevallen van "verneuking" van de layout. Ik denk dat flash en html hier ongeveer gelijk lopen. Ik heb er geen sjoege van maar wat gebeurd er als de breedbeeld monitoren oprukken? mijn 'zorgvuldig' opgezette website is nu al niet meer om aan te zien in IE 7. Dat beloofd wat.

En het klopt inderdaad dat je bij wijze van spreke een nieuwe flash site moet maken om het ook voor je mobiel beschikbaar te stellen. Alleen flash maakt het, zoals Sander al stelt, mogelijk om games te maken, 3d omgevingen, geluid te combineren, film/animatie, realtime manipulatie, combinaties van broadcasting, streaming en andere grapjes. Straks als we geen muis en toetsenbord meer hebben zoals T-MOB zelf al stelt, zullen we de CTRL+F niet meer nodig hebben, het slepen van een grijs balkje naast je pagina dat 'scrollbalk' heet. Juist in termen van usability snapt een gebruik iets beter als diegene visuele waarnemingen doet, die herkenbaar zijn... animatie, real-time manipulatie e.d. maken alles "tastbaarder"

Trouwens Sander.. ik weet dat php serverside is. Ik vroeg me alleen af, of dat nog nodig was met flash. Ik zie het voor me dat flash hun eigen oplossingen daar voor hebben. Maar ik hoor alleen bellen luiden, en zie geen klepels.. ik ben alleen op de hoogte van php/html/etc/etc.

[Verwijderd]

BTW: als je willekeurig de rubrieken bekijkt zoals hier in tweakers.. dan is het toch makkelijk rekenen dat mensen veel meer problemen hebben met javascript, css en html... dan met flash.. 1 op 100 ofzo? ...

[Verwijderd]

Het maken van een webapplicatie in flash is prima. Het decoreren van een pagina met wat flashanimaties is prima. Het maken van een volledige website in flash is niet prima.

Flash is een hulpmiddel, geen totaaloplossing.

[Verwijderd]

Jero schreef op vrijdag 21 april 2006 @ 14:21:
Ondanks wat je net zei is "ouderwetse" HTML nog steeds veel gebruiksvriendelijker. Je hebt bijv. geen plugin nodig. Zonder plugin kan je dus niks. Denk ook aan zoekmachines. Kunnen die alle content in de Flash app zien? Ik dacht het niet.

Een ander nadeel van Flash is de snelheid. Het is zooo langzaam en aangezien bandwidth nog steeds schaars is, is het dus van groot belang dat bestanden op het internet zo klein mogelijk zijn.

Een derde nadeel noemde je zelf al: het is geen standaard. HTML is een open standaard waardoor werken met deze taal een stuk makkelijker is. Je hebt geen enorme Macromedia Suite nodig om je website te bouwen. Je gebruikt gewoon je favo tekstbewerker. Werkt ook nog een stuk sneller.

tja.. 90% heeft een plugin zoals ik al zei... dat is best hoog voor een programma die slechts voor een heeeeel klein deel van het web gebruikt wordt.. beetje kip of het ei.. als we met onze websites rekening zouden houden met flashgebruikers zoals we nu doen met firefox..als je het geen ruimte geeft, dan gaan mensen dus ook geen plugin voor downloaden... developers bepalen indirect wat de gebruikers op hun machine zetten uitiendelijk. Zet vandaag..google om in een flashwebsite.. dan heeft morgen iedereen een flashplugin..

[Verwijderd]

Verwijderd schreef op vrijdag 21 april 2006 @ 17:16:
Het maken van een webapplicatie in flash is prima. Het decoreren van een pagina met wat flashanimaties is prima. Het maken van een volledige website in flash is niet prima.

Flash is een hulpmiddel, geen totaaloplossing.

Met je eens... ik weet alleen niet waarom. Kan het niet verkopen als de examencommissie vraagt.. "maar waarom dan?"

[crisp]

Verwijderd schreef op vrijdag 21 april 2006 @ 17:21:
[...]


tja.. 90% heeft een plugin zoals ik al zei... dat is best hoog voor een programma die slechts voor een heeeeel klein deel van het web gebruikt wordt.. beetje kip of het ei.. als we met onze websites rekening zouden houden met flashgebruikers zoals we nu doen met firefox..als je het geen ruimte geeft, dan gaan mensen dus ook geen plugin voor downloaden... developers bepalen indirect wat de gebruikers op hun machine zetten uitiendelijk. Zet vandaag..google om in een flashwebsite.. dan heeft morgen iedereen een flashplugin..

Maar diezelfde google kan nog steeds niet jouw flashsite indexeren. Cloakpagina's zijn een vorm van bedrog: je schotelt de zoekmachine andere content voor dan je gebruikers.
HTML kent semantiek en is machine-readable, dat is voor mij voordeel genoeg...

[sanderb]

Verwijderd schreef op vrijdag 21 april 2006 @ 17:16:
Het maken van een webapplicatie in flash is prima. Het decoreren van een pagina met wat flashanimaties is prima. Het maken van een volledige website in flash is niet prima.

Flash is een hulpmiddel, geen totaaloplossing.

Niet per definitie. Flash is gegroeid in de afgelopen jaren. Het is veel meer dan een teken/ animatie pakket voor internet.
Het internet is ook gegroeid. Mensen weten dat er meer mogelijk is en willen dus ook meer. Dat is de hele reden dat een techniek als ajax nu in opkomst is.
soms heb je een probleem waarbij de "normale/gangbare" technieken niet voor een oplossing kunnen zorgen.

Data en informatie zijn veranderlijker dan ooit. Zoals vasili al zei is een bookmark al verouderd op het moment dat jij hem aanmaakt.

_{waarom denk je dat je in een literatuurlijst een datum moet opnemen als je refereert naar een webpagina...printen en in je bijlages stoppen heeft meer nut. Als iemand je artikel/paper een jaar later leest is die informatie op het web misschien al weg}

Een voorbeeldje van een applicatie waar flash bijvoorbeeld voor geschikt is om zijn technische mogelijkheden, en niet vanwege de grafische mogelijkheden:

Vroeger moest je je foto's uploaden naar het kruidvat met een java applet.
Van te voren zou je misschien een crop willen maken, of de kleuren iets veranderen...klein tekstje erop zetten of noem maar op. Dat zou je dan in photoshop of een wat minder geavanceerd bewerkingsprogramma moeten doen. Voor de "gewone" mensen is dat teveel werk of te moeilijk.

Met flash zou je in notime een applicatie kunnen bouwen, waarin de gebruiker zijn foto's upload.
Vervolgens het gebied definieert dat ie afgedrukt wil hebben. Roteren, tekst toevoegen..noem maar op. Je zou ze een hele kerstkaart kunnen laten maken voor mijn part.
En dat alles zonder zijn browser te verlaten.

Met ajax zou je hetzelfde kunnen bereiken wellicht, op een omslachtigere manier. En als je echt los wil gaan (kleurtransformaties e.d.) komt je tekort met ajax.
Met puur html/css gaat dit je niet lukken.

Een ander voorbeeld is de googlesuggest. Die techiek wordt ook al toegepast op de site van de ns, hoewel het daar botst met de auto invullen functie van je browser...
met ajax en flash is dit mogelijk. En ja, dit vinden veel gebruikers een prettige functie
probeer googlesuggest in het engels
Ik heb dezelfde techniek gebruikt in een flash applicatie, en dat was geen probleem.

crisp schreef op vrijdag 21 april 2006 @ 17:35:
[...]

Maar diezelfde google kan nog steeds niet jouw flashsite indexeren. Cloakpagina's zijn een vorm van bedrog: je schotelt de zoekmachine andere content voor dan je gebruikers.
HTML kent semantiek en is machine-readable, dat is voor mij voordeel genoeg...

Ik ben het met je eens dat cloakpagina's geen goeie optie zijn.
ajax is voor google ook moeilijker de indexeren overigens.
Je hebt helemaal gelijk waar het informatieve webpagina's betrefd! Ik probeer alleen duidelijk te maken dat het web niet meer alleen een bron van informatie is voor researchers,professoren,studenten en consumenten. Het is ook, en misschien wel vooral, een bron van entertainement voor jan met de pet.

[ Voor 5% gewijzigd door sanderb op 21-04-2006 17:57 ]

[crisp]

Ik denk dat het handig is in deze discussie om een onderscheid te maken tussen webapplicaties en webpagina's

[sanderb]

crisp schreef op vrijdag 21 april 2006 @ 18:02:
Ik denk dat het handig is in deze discussie om een onderscheid te maken tussen webapplicaties en webpagina's

Daarom maakte ik het onderscheid tussen informatie en entertainment..hoewel dat ook de lading niet dekt.. dus jouw voorstel is beter

Helaas is ook het onderscheid tussen een webapplicatie en een webpagina niet heel erg duidelijk...Ben benieuwd waar jij de grens trekt.

[Mithrandir]

Ik denk dat er een goede tweedeling moet worden gemaakt in deze discussie in wat je wilt bereiken.
Er zijn twee mogelijkheden: de website of een applicatie.

Website
Flash/Ajax is een versiering van de pagina. Formuliertjes invullen gaat sneller, je wordt geholpen met de keuzes voor een formulier, soms hoeft niet de hele pagina opnieuw ingeladen te worden maar refreshen kleine stukjes zonder probleem apart.
Alle pagina's met een eigen bestaansrecht zijn ook echt pagina's, die ieder te bookmarken zijn. Pagina's met content worden op de 'oude' manier geladen, zonder fancy stuff; als 80% van je pagina content is maakt het refreshen van de laatste 20% niet meer uit.
De website is nog te gebruiken zonder javascript/flash, omdat alles ook nog op de 'oude' manier met gewone postbacks kan. Alle content die je doorzoekbaar wilt hebben wordt absoluut niet geladen.
Het voordeel van deze methode is dat een zoekmachine de pagina's nog gewoon kan spideren, en alle gebruikers soms een snellere respons hebben dan met het 'oude' web, maar vooral geholpen zijn qua usability.

Applicatie
De website bestaat uit 1 pagina, waarin alle content dynamisch wordt geladen dmv ajax of flash. Subpagina's hebben geen bestaansrecht an sich; ze zijn alleen relevant in een groter kader. De 'pagina's' zijn ook niet te bookmarken. De back en forward buttons doen het niet. Als de pagina eenmaal geladen is werkt alles supervlot, maar er hoeft weinig content gelezen te worden. Het doel is creëren of bewerken van dingen, geen informatievoorziening.


Op- of aanmerkingen anyone?

[marcieking]

Hoewel ik zelf (nog?) geen webdesigner ben wil ik toch even wat zeggen uit het oogpunt van de gebruiker (dat ben ik dan weer wel ):
De penetratie van de flash-plugin mag dan redelijk hoog zijn, het zijn juist de plaatsen waar die nog niet is doorgedrongen waar problemen kunnen onstaan, even wat voorbeeldjes:
Bij ons op school zijn er twee images (en twee soorten computers) die bij elke reboot worden teruggezet (reborn kaart). Wanneer in zo'n image de flash player vergeten is, pech, dan heeft die pc geen flash. Als er dan informatie van vandaan moet worden gehaald, dan kan een leraar die opdracht leuk thuis hebben voorbereid, maar gaat het op school niet lukken. Installeren is ook geen optie, geen rechten en bij de volgende reboot is het weer weg

Trage PC's, ze zijn er helaas nog; computers van 200 Mhz waarop oma nog eens een mailtje kan sturen naar de kleinkinderen. Flash sites doen het daar niet altijd op, omdat het toch net wat te traag is, en het installeren lukt ook niet altijd, in het geval van de oma kan zelfs paniek onstaan door allerlei vage meldingen, met als resultaat dat de site gewoon niet meer bezocht zal worden.

Daarnaast heb ik ook gewoon slechte ervaringen met flashsites, de sites die ik heb gezien zagen er onprofessioneel uit, waren traag, hadden laadbalkjes over en weer. Misschien heb ik de verkeerde sites gezien (Een van de opvolgers van die sites was weer in HTML, maar dat was echt waardeloze code), dus als iemand een goede flashsite heeft om te laten zien dat het wel werkt sta ik natuurlijk altijd open

[Not Pingu]

crisp schreef op vrijdag 21 april 2006 @ 17:35:
[...]

Maar diezelfde google kan nog steeds niet jouw flashsite indexeren.

Bwuh? Google indexeert Flashpagina's al inhoudelijk sinds 2004.

De toepassing daarvan binnen Google verschilt echter nog wel danig.

http://www.google.com/support/bin/answer.py?answer=4302

Does Google index sites that use Macromedia Flash?

Google does index pages that use Macromedia Flash. However, our crawlers may experience problems indexing Flash pages. If you're concerned that Flash content on your pages may be inhibiting Google's ability to crawl your site, you may want to consider using a text browser such as Lynx to examine your site. If features such as Flash keep you from seeing all of your site in a text browser, then search engine spiders may have trouble crawling your site.

Verder verwijs ik nog even naar dit onderzoeksrapport over RIA (wat wel alweer bijna een jaar oud is, de tijd vliegt!).
Wij concludeerden vorig jaar al dat Flash op dit moment de enige echte RIA-tool is en dat AJAX en andere RIA-tools toch teveel het klassieke webmodel vasthouden.

Mind you, dat is erg voor een webapplicatie, niet voor een website of voor een website/applicatie hybride. Maar je ziet steeds vaker dat Flash binnen websites toegepast wordt voor zaken waar AJAX net tekortschiet. Niet als vervanging van websites, maar als onderdeel ervan.

Boss schreef op vrijdag 21 april 2006 @ 14:20:
Ik denk dat er maar 1 groot probleem is: Flash is een commercieel formaat, is dat niet van Macromedia? Zij bepalen de ontwikkelingen en de standaarden. Daar houdt men niet zo van bij het opstellen van standaarden.

AJAX etc. is allemaal open standaarden.

Het SWF formaat is een open standaard (vandaar dat applicaties zoals Swish of OpenOffice het ook kunnen uitlezen en opslaan), het FLA formaat (met de ruwe designinformatie zoals die door de Macromedia Flash designer wordt opgeslagen) is idd. proprietary.

Bovendien zal 90% van de designers op deze aarde het echt een worst wezen of het formaat open is proprietary. Macromedia Adobe doet goed zijn best om de Flash player wijdverspreid te maken en zorgt dat er voor alle platformen een uniforme Flash player is.

[ Voor 22% gewijzigd door Not Pingu op 21-04-2006 21:56 ]

[killercow]

Alle voordelen van flash zijn net zo gemakkelijk op te lossen met SVG + javascript bindings, wat er nu met dhtml kan, kan straks ook met DSVG, (oke nu heb je nog een plugin nodig, maar die heb je voor flash ook nodig)

Daarnaast is het internet grotendeels als HTTP systeem bekend geworden .hyperTEXTtransportprotocol.
Niet als hyperImagetransportprotocol toch?
Je kunt in flash niet gemakkelijk schalen/selecteren/printen, daarnaast zijn er helemaal geen goede players voor flash buiten het windows platform, er is geen 64bits player, er is geen 8.0 player voor linux. Er is geen goede fallback want 8.0 meuk draait niet op 7.5 players, etc etc etc.

Juiste de reden dat het flash formaat gesloten is, en de inhoud van flash filmpjes nooit het zelfde zijn maakt het bijzonder lastig voor derden om er een goede parser voor de bouwen, laat staan een player voor de systemen die adobe vergeten is.

bij html bestanden zoek je gewoon naar alle a elementen om de linkjes te vinden, maar in flash zou je dan alle buttons moeten doorlopen, en ook alle andeer vage events die tot data retreival kunnen lijden?

Ik denk trouwens dat mensen die naar flash grijpen omdat ajax te kort schiet gewoon niet weten wat ze aan het doen zijn, en dus maar weer een kant en klaar .fla bestandje downloaden om dat kleine stukje dhtml te vervangen. Jammer voor de 10% die de site dan niet meer gebruiken kan, want kennelijk gaat het om een belangrijk stukje code. (wat nu zonder failover opties in de html staat, die zit namenlijk vaak niet bij de .fla gebundeld)

[OzBoz]

killercow schreef op zaterdag 22 april 2006 @ 15:57:
Jammer voor de 10% die de site dan niet meer gebruiken kan

10% en die is gebasseerd op... je fantasie of op 1998?

[killercow]

10% is mischien inderdaad wat veel, maar laten we vooral de pda's en dergelijke waar juist web-apps veelal op gelezen worden niet vergeten.

Vergeet daarnaast niet dat er voor ilnux uberhaupt geen 8.0 player is, en dat (bijna) alle nieuwe flash sites hoe dan ook voor 8 gecompileerd worden (of er nou features uit 8 gebruikt worden of niet)

[Verwijderd]

OzBoz schreef op zaterdag 22 april 2006 @ 17:08:
[...]

10% en die is gebasseerd op... je fantasie of op 1998?

sterker nog jouw eigen site doet het hier ook niet met IE (laatste eolas patent update zit er bij mij in), ook niet na het verplichte klikken

[ Voor 11% gewijzigd door Verwijderd op 22-04-2006 21:22 ]

[Verwijderd]

Als je flash gebruikt ontzeg je de gebruiker controle over de webpagina - en de gebruiker is waar je de pagina voor maakt toch? Flash geeft je absoluut geen controle over de inhoud en opmaak.

Ik vind het verschrikkelijk irritant om een seconde te moeten wachten op nieuwe content na het klikken, omdat dat flash ding een animatietje af moet maken Animaties in een website kan ik uberhaupt nauwelijks waarderen. Waar is mijn 'turn off animations' optie? En hoe kom ik aan een printbare versie? Het werkt natuurlijk ook niet als je je window niet groot genoeg hebt staan voor de flash-pagina.

Het enige dat ik bij flash te vertellen heb is of ik het wel of niet wil zien op de pagina (flashblock).

Stel de flash plugin zou bestaan voor telefoons en pda's, dan is nog 99,9% van de websites die in het geheel opgebouwd zijn in flash niet te gebruiken omdat het veel te klein is, en niet mee doet aan aparte styles voor clients. En ik denk ook niet dat hier iets van een stijl-omzetter voor gemaakt kan worden: daar is html + css al voor uitgevonden, wat echt geen achterhaalde techniek is.

[flowerp]

Ik vind ook dat voor Web 2.0 toepassingen AJAX (Javascript + DHTML) eigenlijk achterhaald zijn. Vanuit de ogen van een programmeur is javascript natuurlijk een ruk taaltje. Technisch gezien kun je een complete applicatie in javascript client-side laten draaien met af en toe een interactie met een server via XMLHttpRequest. Alleen begeef je je dan wel in complete hel, zowel kwa onderhoud als kwa cross-browser support.

Javascript is in z'n geheel niet bedoeld voor grotere lappen code, waardoor de onderhoud gewoon erg slecht is. Tools zoals debuggers, refactorings, code analyse, profilers etc zijn of niet bestaand voor javascript of van een dergelijke kwaliteit dat geen enkele serieuze developper ze zou willen gebruiken.

Het enigste waarvoor je AJAX nog een beetje 'sensible' kan gebruiken is als doorgeef luikje voor server side gegenereerde content. Op de server kun je je business logic en state-management in serieuze talen als Java, C# of C++ bouwen. Dan heb je ook meteen de gehele toolset tot je beschikking, een volwassen OOP model en echte web components / controls.

Het zou veel beter zijn voor rich internet applications als de standaard voor client-side rendering XUL zou worden icm SVG. Dit zijn gewoon veel beter doordachte technieken en beiden worden uitgedrukt in gewone tekst. Hoewel XUL al langer bestaat, is het nog steeds alleen beschikbaar voor de Mozilla browsers. Microsoft gaat ook XUL gebruiken, maar is het aanzichzelf verplicht om hier een incompatible variant op te bedenken (XAML). Mischien dat de OS cummunity zo ver gaat om dan ook weer Microsoft's variant te supporten onder het motto van "alles beter dan antiek Javascript + DHTML" en "het origineel komt toch ook al van ons vandaan; we kunnen MS' aanpassingen accepteren zonder gezichtsverlies", maar persoonlijk ben ik er niet zeker van dat dat gaat gebeuren.

Daarnaast blijft er nog SVG over. Volgens mij zijn er nog geen plannen van Microsoft's kant om dit te gaan supporten. Helaas, want de techniek bestaat al redelijk lang en het kan alles kwa vectors wat flash ook zou kunnen.

[crisp]

Vanuit de ogen van een programmeur is javascript natuurlijk een ruk taaltje.

Dat zijn meestal programmeurs die zich er niet serieus in verdiept hebben

[kamerplant]

OzBoz schreef op zaterdag 22 april 2006 @ 17:08:
[...]

10% en die is gebasseerd op... je fantasie of op 1998?

Als ik het juist heb is er voor Linux 64bit nogsteeds geen Flashplayer. Linux 32bit heeft Flashplayer v7, terwijl Windows v8 heeft. Het lijkt mij zeer onverstandig om het SWF formaat, wat volledig afhankelijk is van deze plugin, op een nog grotere schaal te gebruiken dan nu gebeurd. Stel dat iedere website op Flash zou draaien, dan heeft één enkel commercieel bedrijf de macht een groep gebruikers uit te sluiten om gebruik te maken van internet, dat is een situatie die altijd moet worden voorkomen.

Toevallig las ik van de week dat er een open SWF player bestaat, OpenSWF, maar dat project lijkt behoorlijk dood te zijn.

[flowerp]

crisp schreef op zondag 23 april 2006 @ 12:43:
[...]
Dat zijn meestal programmeurs die zich er niet serieus in verdiept hebben

Dat valt best mee. Ik zie de knipoog wel, en ik snap dat er hier deels sprake is van het "microsoft symdroon"^*, maar toch heb ik gegronde redenen om het bovenstaande te ondersteunen.

Zowel kwa taal als kwa platform mist javascript veel zaken. Kwa taal heb je dingen die in grotere projecten erg veel ergenis gaan opleveren.

Neem iets als:

JavaScript:

var foo = new Array()

Er is -zoveel- inherent evil hieraan, dat ik waarschijnlijk een halve thesis over zou kunnen schrijven, maar om met de grootste dingen te beginnen:

1) Een array van -wat-? Wat voor dingen gaan hier in? Chars? Integers? Complete XMLHttpRequest object? Je weet het niet, en als je er perongeluk iets verkeerds in stopt zal ook niemand je waarschuwen.

2) Wat is de index? Is het op volgorde (dwz index is een nummer) of op naam? In Javascript kan ik nu zowel het volgende doen:

JavaScript:

foo[foo.length] = "bar";

Alswel dit:

JavaScript:

foo["kaz"] = "bar";

Wat is het nu? Waarom heet dat ding Array als ik hem ook als een hashmap kan gebruiken? Sommige mensen zullen mischien zeggen "ah, lekker makkelijk", maar de profesionele developper weet dat te veel verschillende soorten functionaliteiten in 1 'ding' een enorme grote potentiele bron voor bugs is.

3) Wat zijn de vaste properties van dit object in wat zijn entries? In Javascript kun je nu schrijven:

JavaScript:

foo.kaz = "bar";
foo.rar = "bar";
// etc...

Voor een scripting taaltje, om snel wat kleine dingetjes te doen, is dit mischien geen ramp, maar voor grotere applicaties (denk aan minimaal zo'n 50.000 regels) neemt de onderhouds hel door allemaal van dergelijke kleine dingetjes astronomisch toe. Dit is maar 1 voorbeeld, maar er zijn er veel meer. Ik denk dat de overgrote meerderheid van de mensheid toch wel erkent dat javascript niet de weg is om grote lappen code mee te schrijven.

Behalve de taal zelf heb je dan nog het platform waar het op draait. De objecten die je standaard tot je beschikking hebt en de properties die die objecten hebben willen nogal eens verschillen per browser. Zelfs al heb je dezelfde objecten en properties, dan wil zelfs het gedrag nog wel eens verschillen. Ook hier zijn weer talloze voorbeelden te bedenken, maar die ken je waarschijnlijk zelf wel beter als ik. Als voorbeelden noem ik dingen als het gedrag van abort() op een XMLHttpRequest object en de readyState codes hoger dan 4. Als ik af en toe het geklaag hoor van onze javascript scripters dan ben ik er van overtuigd dat er nog veel... veel meer dingen niet standaard zijn kwa platform.


*
Gebruiker is gewend aan Windows, Word, etc. Probeerd een keertje Linux, OpenOffice, etc. Zodra er ook maar 1 dingetje niet zoals Windows, Word, etc werkt is het meteen k*t, want... het werkt niet zoals in Windows, Word, etc... dwz; wat men kent is automatisch 'goed' en al het andere is automatisch 'slecht'.

[Not Pingu]

@flowerp

Javascript is dan ook een scripttaal. Weak typing enz. zijn inherent aan scriptingtalen. Wel ben ik het met je eens dat Javascript erg lastig is om in te komen, vanwege het gebrek aan goede debuggers (tenminste van het niveau dat ik gewend ben van Visual Studio) en vanwege soms moeilijk overkoombare crossbrowser incompatibiliteiten.

Dat het uiteindelijk te leren is, ben ik met crisp eens, maar de vraag is of je niet gewoon liever een eenduidiger platform hebt dan veel expertise te besteden aan de nukken van een scriptingtaal.

[crisp]

flowerp schreef op zondag 23 april 2006 @ 14:48:
[...]

Dat valt best mee. Ik zie de knipoog wel, en ik snap dat er hier deels sprake is van het "microsoft symdroon"^*, maar toch heb ik gegronde redenen om het bovenstaande te ondersteunen.

Je maakt hier al de fout om een taal af te rekenen op slechte of onvolkomen implementaties (ja, eentje in het bijzonder ) en/of de bestaande (of niet-bestaande) interfaces die op zich weinig met de taal zelf te maken hebben (zoals de brakke non-native DOM-implementatie in IE).

Zowel kwa taal als kwa platform mist javascript veel zaken. Kwa taal heb je dingen die in grotere projecten erg veel ergenis gaan opleveren.

Zoals? De kracht van javascript zit 'm in de flexibiliteit van de taal die het mogelijk maakt om echt bijna alles wat er niet standaard inzit zelf te definieren. Als je wilt kan je heel javascript herdefinieren in javascript zelf. Wat dat betreft is de taal in mijn ogen 'puurder' dan ander talen waar ik toch vaak een gevoel krijg dat eea nogal 'bloated' is door de vele methods en properties die gezien de mogelijkheden van de taal zelf eigenlijk overbodig zijn.

Neem iets als:

JavaScript:

var foo = new Array()

[...]

Je weet dat de primitive van Array gewoon object is? Daarmee heeft een array inderdaad de mogelijkheden van een native object in javascript en is het dus inderdaad heel geschikt om te gebruiken als een hashmap (hoewel ik daar eerder een Object voor zou gebruiken).
Javascript biedt native methods zoals hasOwnProperty om te bepalen of iets een native method of property is of een expando; de problemen die jij omschrijft zie ik niet als problemen maar als flexibiliteit, en als je goed thuis bent in de taal dan zijn de nadelen ook makkelijk te ondervangen...

Voor een scripting taaltje, om snel wat kleine dingetjes te doen, is dit mischien geen ramp, maar voor grotere applicaties (denk aan minimaal zo'n 50.000 regels) neemt de onderhouds hel door allemaal van dergelijke kleine dingetjes astronomisch toe. Dit is maar 1 voorbeeld, maar er zijn er veel meer. Ik denk dat de overgrote meerderheid van de mensheid toch wel erkent dat javascript niet de weg is om grote lappen code mee te schrijven.

Je kunt een taal ook niet afrekenen op het gebrek aan IDE's and the likes die het hier genoemde nadeel waarschijnlijk grotendeels al op zou lossen. In zie niet waarom sec gezien 50.000 regels javascript code moeilijker onderhoudbaar zou zijn dan 50.000 regels code in welke andere taal dan ook...

Behalve de taal zelf heb je dan nog het platform waar het op draait. De objecten die je standaard tot je beschikking hebt en de properties die die objecten hebben willen nogal eens verschillen per browser. Zelfs al heb je dezelfde objecten en properties, dan wil zelfs het gedrag nog wel eens verschillen. Ook hier zijn weer talloze voorbeelden te bedenken, maar die ken je waarschijnlijk zelf wel beter als ik.

Nogmaals: een taal afrekenen op (een) brakke implementatie(s) is niet bepaald eerlijk

Als voorbeelden noem ik dingen als het gedrag van abort() op een XMLHttpRequest object en de readyState codes hoger dan 4. Als ik af en toe het geklaag hoor van onze javascript scripters dan ben ik er van overtuigd dat er nog veel... veel meer dingen niet standaard zijn kwa platform.

En hier noem je dan vervolgens een interface die (nog) niet eens gestandaardiseerd is maar in feite (nog) MS-propriety is en door andere browsermakers dmv reverse-engineering geimplementeerd is - dat is uiteraard een recept voor incompatibilities (vandaar dat deze interface door w3c ook gestandaardiseerd gaat worden).

Gunp01nt: wat maakt het uit op welk moment de sourcecode van een willekeurige taal wordt gecompileerd? Zegt dat iets over de mogelijkheden van een taal?
Weak typing is ook helemaal niet per-sé inherent aan scriptingtalen en is niet enkel een nadeel (en al helemaal geen 'nuk')

[Not Pingu]

crisp schreef op zondag 23 april 2006 @ 23:30:

Je kunt een taal ook niet afrekenen op het gebrek aan IDE's and the likes die het hier genoemde nadeel waarschijnlijk grotendeels al op zou lossen. In zie niet waarom sec gezien 50.000 regels javascript code moeilijker onderhoudbaar zou zijn dan 50.000 regels code in welke andere taal dan ook...

Het is een nadeel van Javascript als ontwikkelplatform. Op het moment dat concurrenten minder expertise nodig hebben en sneller een applicatie kunnen uitrollen omdat ze gebruikmaken van een taal/platform waarvoor goede IDE's, debuggers etc. beschikbaar zijn, heeft Javascript zakelijk gezien een probleem.

Dat je dat makkelijk afdoet als gebrek aan kennis van javascript vind ik erg zwak.

Gunp01nt: wat maakt het uit op welk moment de sourcecode van een willekeurige taal wordt gecompileerd? Zegt dat iets over de mogelijkheden van een taal?

Het zegt iets over de debugbaarheid van een taal, iets wat zeker niet onbelangrijk is op het moment dat je dezelfde code voor meerde, sterk afwijkende platformen (IE en FF bijv.) wilt gebruiken.

Weak typing is ook helemaal niet per-sé inherent aan scriptingtalen en is niet enkel een nadeel (en al helemaal geen 'nuk')

Ok, lang niet alle scriptingtalen zijn weak-typed. Javascript, PHP, VBScript, etc. echter wel en dat zijn op webgebied de meestgebruikte talen.

Wat ben jij defensief naar JS toe zeg. Je snapt ongetwijfeld dat het gebrek aan IDE's, debuggers en eenduidige implementaties, een grote horde is voor de acceptatie van javascript, maar je kiest er vervolgens voor om de taal zelf te verdedigen door te zeggen dat deze nadelen niet inherent zijn aan de taal?

C# (om maar iets te noemen) was ook niet half zo effectief en populair geweest als er niks beters dan notepad was om het mee te schrijven.

[crisp]

Gunp01nt schreef op zondag 23 april 2006 @ 23:51:
[...]
Wat ben jij defensief naar JS toe zeg. Je snapt ongetwijfeld dat het gebrek aan IDE's, debuggers en eenduidige implementaties, een grote horde is voor de acceptatie van javascript, maar je kiest er vervolgens voor om de taal zelf te verdedigen door te zeggen dat deze nadelen niet inherent zijn aan de taal?

Ik reageerde uiteraard in eerste instantie primair op jouw uitspraak dat javascript een 'ruk taaltje' zou zijn. Uiteraard zou de beschikbaarheid van goede IDE's en debuggers een heleboel goed doen aan de acceptatie van javascript als volwaardige taal, maar dat wil niet zeggen dat het geen volwaardige taal is

Nu Ajax en dergelijke technieken een hoogvlucht nemen verwacht ik toch binnen afzienbare tijd wel betere IDE's en debuggers te zien dan hetgeen er nu sporadisch beschikbaar is.
Ik ben het overigens wel met je eens dat met de huidige tools een grote javascript app lastiger te onderhouden is dan een app geschreven in een taal waarvoor wel de(r)gelijke tools beschikbaar zijn, maar een taal blijft een taal met z'n voordelen en nadelen, en ik zie in javascript an sich geen grotere voordelen of nadelen tov andere talen (afgezien van het platform waar het op draait).

[ Voor 29% gewijzigd door crisp op 24-04-2006 00:01 ]

[flowerp]

Gunp01nt schreef op zondag 23 april 2006 @ 22:22:
@flowerp

Javascript is dan ook een scripttaal. Weak typing enz. zijn inherent aan scriptingtalen.

Uhm, maar dat zeg ik toch ook, dat het voor scripten alleen niet slecht is? Je hebt bijvoorbeeld in Java EE ook een subtaaltje dat voornamelijk voor databindings gebruikt wordt en soms voor simpele conditities in de GUI layer. Dit sub-taaltje heet EL (Expression Language) en valt ook onder de scriptalen. Het is weakbinding, en 'unificeerd' ook velden (properties) van een class en entries in een map.

Echter, mijn hele punt was dus niet dat scripting slecht is, maar dat je in een script taal niet een complete business applicatie moet gaan schrijven. Voor kleine behaviours op een web pagina (dwz het aansturen van de browser 'container') is het natuurlijk uitstekend geschikt.

Aangezwengeld door de AJAX hype is er echter een groep mensen ontstaan die er op aan stuurt om maar meteen de hele applicatie client-side in javascript te bouwen (dus inclusief business logic en het hele navigatie systeem van je applicatie, etc). -dat- lijkt me dus een bijzonder slecht idee en met mij velen anderen.

[crisp]

flowerp schreef op zondag 23 april 2006 @ 23:58:
[...]

Echter, mijn hele punt was dus niet dat scripting slecht is, maar dat je in een script taal niet een complete business applicatie moet gaan schrijven. Voor kleine behaviours op een web pagina (dwz het aansturen van de browser 'container') is het natuurlijk uitstekend geschikt.

Aangezwengeld door de AJAX hype is er echter een groep mensen ontstaan die er op aan stuurt om maar meteen de hele applicatie client-side in javascript te bouwen (dus inclusief business logic en het hele navigatie systeem van je applicatie, etc). -dat- lijkt me dus een bijzonder slecht idee en met mij velen anderen.

Ook wel mee eens trouwens, maar in dat geval is het eigenlijk meer het platform waar de applicatie op/in draait (een browser) waardoor het minder geschikt is voor complete/complexe applicaties dan de gebruikte taal. De interface met HTML is ackward, zeker bekeken vanuit de ogen van een non-web programmeur, en gecombineerd met de statelessness van HTTP als protocol is het soms lastig manouvreren...

[flowerp]

crisp schreef op zondag 23 april 2006 @ 23:30:
[...]
Je maakt hier al de fout om een taal af te rekenen op slechte of onvolkomen implementaties (ja, eentje in het bijzonder )

Ben ik niet met je eens dat dat een fout is. Een taal staat of valt toch met de implementaties die er voor zijn. Met alleen een mooie spec bereik je niet veel. (hoewel een mooie spec zeker een begin is, zoals al velen zeggen: als javascript 100% eenduidig op elke browser zou werken, dan zou dit al heel wat schelen).

de problemen die jij omschrijft zie ik niet als problemen maar als flexibiliteit, en als je goed thuis bent in de taal dan zijn de nadelen ook makkelijk te ondervangen...

Mischien zie -jij- het niet als problemen, maar als je applicaties van ~400.000 regels moet onderhouden dan leer je snel dat 'flexibiliteit' op een dergelijke schaal alleen maar tegen je werkt. Het is geen kwestie van een taal snappen of niet. Ik heb vroeger ook in assembly geprogrammeerd en moest daar met complexe dingen als de relatieve snelheid tussen chips rekening houden etc. Het is dus niet zo dat ik javascript niet 'snap' en gewoon even wat meer moeite moet doen.

Het punt is, zoals je dat zelf als zo mooi zegt, de flexibiliteit. In Javascript kunnen teveel dingen 'zomaar' aangepast worden en 'dynamisch' bepaald worden. In een enterprise systeem (of grote desktop applicatie) wil je juist dat dingen strak en rigide gedefineerd worden en door tools te controleren zijn. Te veel vrijheid voor de progammeur leverd alleen maar onmogelijk op te lossen bugs op en moeilijk te onderhouden code.

Veelal geldt hier: less is more. Neem nou bijvoorbeeld de PHP/JSP werkwijze om serverside code en html dwars door elkaar op een pagina te mixen. De flexibiliteit die je hierdoor krijgt is werkelijk enorm. Een creatieve programmeur kan echt helemaal los gaan. 'klein' nadeel is echter dat al na enkele generaties van de pagina de code een complete spaghetti mix wordt. Hergebruik is bijna onmogelijk en vervalt tot copy-pasten, en je ziet absoluut niet meer welke parameters die uit de request getrokken worden bij welk stukje code op de page horen.

Neem dan een strak MVC model. Dit houdt de 3 hoofdcomponenten van je app strak gescheiden. In het begin komt dit voor menig PHP/JSP programmeur heel beperkend over, en dat is het ook. Je kunt niet meer zomaar los gaan, maar je design moet binnen dit model passen. Op een pagina kun je niet zomaar even wat logica zetten, maar je kunt eigenlijk alleen weergeven wat de controller heeft klaar gezet. Bekijk je dit echter op een groter project dan zie je opeens enorme voordelen. Bugs zijn opeens makkelijker op te lossen (want beter gelocaliseerd) en je herbruikbaarheid van code is veel groter. Door jezelf te beperken wordt je uiteindelijk vrijer in wat je kunt doen.

[crisp]

flowerp schreef op maandag 24 april 2006 @ 00:30:
[...]


Ben ik niet met je eens dat dat een fout is. Een taal staat of valt toch met de implementaties die er voor zijn. Met alleen een mooie spec bereik je niet veel. (hoewel een mooie spec zeker een begin is, zoals al velen zeggen: als javascript 100% eenduidig op elke browser zou werken, dan zou dit al heel wat schelen).

Core javascript werkt vziw in bijna alle browsers hetzelfde (alleen IE heeft zelfs daar nog bugjes in zitten), enkel interfaces (niet dat die niet belangrijk zijn) zijn niet eenduidig/volledig geimplementeerd (waarbij IE eigenlijk weer de grootste boosdoener is, vooral mbt DOM).

[...]

De mogelijkheden/flexibiliteit van een taal moet je niet verwarren met misbruik door het leeuwendeel van de copy-paste cowboys op het web. Het afwezig zijn van een strak keurslijf dat je dwingt om volgens een bepaald model te werken wil niet zeggen dat er geen 'best practices' zijn - het is alleen wat lastiger om 'bad practices' van 'good practices' te onderscheiden als je niet voldoende thuis bent in de taal

Maar goed, we dwalen af - hoewel we het wel over de implementatie van dezelfde taal hebben die voor 'web 2.0' - toepassingen wordt gebruikt alsmede in Flash

[ Voor 7% gewijzigd door crisp op 24-04-2006 00:57 ]

[Not Pingu]

crisp schreef op zondag 23 april 2006 @ 23:55:
[...]

Ik reageerde uiteraard in eerste instantie primair op jouw uitspraak dat javascript een 'ruk taaltje' zou zijn.

Huh?


'nukken' is niet hetzelfde als 'rukken' ik heb nooit gezegd dat javascript een ruktaaltje is, alleen dat bepaalde factoren ertoe bijdragen dat het als ontwikkeltool imho zwak staat tegenover Flash

[Clay]

De toegankelijkheid van javascript - elke randdebiel kan in notepad een scriptje in elkaar fietsen en met wat html eromheen uitvoeren - heeft natuurlijk mede bijgedragen aan het aanzicht van de taal. Ook de jarenlange oerwouden aan dhtml scripts die rekening moesten houden met 3 verschillende implementaties en iets deden wat nu met 3 regels CSS kan deden het geen goed

Het heeft inderdaad z'n eigenaardigheden vergeleken met "echte" talen, maar het is dan ook niet object oriented noch strong typed. Dat je een array als hashmap gebruiken kan heeft ook niets met die array te maken; window["alert"]("hoi"); werkt ook. Dat je er troep mee kan coden is echter een overeenkomst met die echte talen, niet een verschil. Als je er een architect opzet en er mooie designpatterns tegenaangooit kan je prima een onderhoudbaar geheel van 50.000 regels schrijven, maar of je dat ook wil is idd de vraag.

In een webapplicatie kan je er prima de interface mee aansturen, in een website zou het een ondersteunende laag moeten zijn die de hele zwik niet op z'n gat legt als die wegvalt; in beide gevallen kan je er niet van op aan dat wat er doorgegeven wordt aan de server ook te vetrouwen is. Clientside formvalidatie schrijf je b.v. voor de gebruiker z'n gemak, serverside validatie voor de integriteit. Zo zou de js in een webapp alleen maar commando's door moeten sluizen naar de server, waarna die het betrouwbaar verwerkt en al dan niet via ajax een seintje teruggeeft naar de client.

Wbt flash, waar dit topic geloof ik over ging , zie ik nog steeds een platform dat gericht is op de presentatie van de boodschap in 1 medium, waartegenover html de boodschap zelf zo toegankelijk mogelijk presenteren kan op meerdere media. Iets als een document flow, die inherent is aan html, is dan een voorbeeld van iets wat ik het meeste mis aan flash. Maar uiteindelijk hebben beide hun voor- en nadelen en kan je niet volhouden dat het een het ander overbodig zou kunnen maken.

[crisp]

Gunp01nt schreef op maandag 24 april 2006 @ 09:02:
[...]


Huh?


'nukken' is niet hetzelfde als 'rukken' ik heb nooit gezegd dat javascript een ruktaaltje is, alleen dat bepaalde factoren ertoe bijdragen dat het als ontwikkeltool imho zwak staat tegenover Flash

offtopic:
sorry, het was flowerp die die uitspraak deed

[Verwijderd]

Javascript kan alles wat je van een webapplicatie zou willen. Ik ben het er niet mee eens dat je daarvoor ....C moet gebruiken.. trouwens.. C kan toch alleen serverside? tenzij ik een exe zou installeren? je hebt het dan niet meer over webpagina's en webapplicaties..

Wat betreft open standaarden voor vectoren.. Leuk en aardig. Ik zie het niet ontpoppen. Ik denk dat de beperkingen die ik hier vooral hoor, liggen aan het onvermogen van de flashdesigner om een gebruiksvriendelijke, compatible webpagina te maken in een flashomgeving. Geen animaties als je dat niet wilt. (of misschien uberhaupt geen animatie). En je kunt je fla volgens mij ook comp. maken voor oudere players. En zoals ik al eerder zei in mijn vorige posts.. Als flash zo weinig aanwezig is, staat niemand te springen om een player update. Ondanks de versieverschillen, denk ik dat flash net wat populairder is dan SWG (of hoe dat ding mag heten).

Lijkt me opzich kicken om een keer een website te maken, waarvan iedereen in eerste instantie denkt dat het html is. Totdat iemand probeerd de bron te lezen. "heej wtf??..het is flash...ik ben geflashed"

En dat http voor text bedoeld is..tja.. internet was zoiezo niet bedoeld voor waar het nu voor dient. Begon als een militair netwerk, werd toen een luxe bibliotheek voor universiteiten.. en pas later kwamen de 'normale' mensen er mee in aanraking.. ook als was het er niet voor bedoeld.

[LB Back]

Een niet al te grote site helemaal in Flash maken kan prima, voor een grote site zou ik een html-basis gebruiken met eventueel FLash elementen.

Het grote voordeel van html-basis blijft toch functionaliteiten als specifieke pagina's bookmarken, vindbaarheid door zoekmachines en de standaard browser functionaliteiten zoals backspace, control+f etc. Je kunt weliswaar named anchors gebruiken in Flash om te tabben backspacen maar dat werkt dan weer niet goed op Mac.

Ik denk dat Ajax en Flash voor verschillende dingen gebruikt moeten worden, Ajax blijft toch functioneler in een browser terwijl je met Javascript redelijk veel dingen kunt doen die Flash ook kan, Flash kun je gebruiken voor wat ik hieronder noem. Ik zou liefst ook een site niet helemaal met Ajax maken maar Ajax elementen gebruiken, alleen al voor indexeerbaarheid en crossplatform ontwikkelingskosten.

Voor meerdere grotere websites heb ik een html-basis gebruikt met FLash elementen. Ik heb Communication Servers gebruikt voor streaming video/audio met op maat gemaakte players en chatapplicaties. Ook heb ik meerdere navigaties in Flash gemaakt die bijvoorbeeld mbv databases of simpele xml-bestanden worden gevuld cq, gegenereerd. Of voor kopjes met dynamische tekstVelden zodat je niet-standaard fonts kunt gebruiken, een stuk flexibeler dan statische gifjes.

Als je naar de echt grote corporate sites (Volvo, Adidas, Nike, Volkswagen, Ikea, Mercedes en ga zo maar door, typ een grote naam in je browser en 95% kans dat er Flash video of andere elementen wordt gebruikt) kijkt zie je dat ze allemaal Flash gebruiken voor met name interactieve Rich Media. De penetratie van de Flash plugin is een stuk groter dan bvb Media Player, Real of Quicktime. Met de laatste codec, On2 VP6, is de kwaliteit van Flv ongeveer even goed als Quicktime, zelfs bij high-motion. En ook wordt Flash steeds meer gebruikt voor navigatiedoeleinden, zoals bij KPN.

Ik heb wel eens een site helemaal in Flash gemaakt voor een jaarlijkse
kunstbeurs waarbij je kunt zoeken naar kunstenaars en deelnemende galerieen. Er worden twee Excel bestanden ingeladen met in totaal zo'n 700 recordsets. De snelheid waarmee Flash dat doorzoekt en aan de hand van de resultaten knoppen genereert waarmee je de content kunt bekijken is indrukwekkend. Eigenlijk worden er twee "databasetabellen" ingeladen die lokaal gebruikt kunnen worden, Geen heen-en-weer gepingel met query, data terugsturen, renderen van content etc. ook al werkt Flash uitstekend met PHP, ASP, CFM om maar wat te noemen.

Boss schreef op vrijdag 21 april 2006 @ 14:20:
Ik denk dat er maar 1 groot probleem is: Flash is een commercieel formaat, is dat niet van Macromedia? Zij bepalen de ontwikkelingen en de standaarden. Daar houdt men niet zo van bij het opstellen van standaarden.

AJAX etc. is allemaal open standaarden.

Er is een grote OpenSource FLash community (osflash.org)en er zijn meerdere gratis swf-compilers te krijgen, je zou een swf ook in Kladblok kunnen typen maar dan werkt een (commmerciele) authoring omgeving van Macromedia net iets sneller.

Jero schreef op vrijdag 21 april 2006 @ 14:21:
Ondanks wat je net zei is "ouderwetse" HTML nog steeds veel gebruiksvriendelijker. Je hebt bijv. geen plugin nodig. Zonder plugin kan je dus niks. Denk ook aan zoekmachines. Kunnen die alle content in de Flash app zien? Ik dacht het niet.

Een ander nadeel van Flash is de snelheid. Het is zooo langzaam en aangezien bandwidth nog steeds schaars is, is het dus van groot belang dat bestanden op het internet zo klein mogelijk zijn.

Een derde nadeel noemde je zelf al: het is geen standaard. HTML is een open standaard waardoor werken met deze taal een stuk makkelijker is. Je hebt geen enorme Macromedia Suite nodig om je website te bouwen. Je gebruikt gewoon je favo tekstbewerker. Werkt ook nog een stuk sneller.

Flash heeft nog steeds een slechte naam uit de tijd dat mensen animaties van 2MB maakten, zonder slimme preloaders die je toen nog met een 56K modem moest binnenhalen. Bandwidth is trouwens steeds minder schaars als je de enorme toename van breedband-ontwikkelaars ziet.

@T_MOB:
1 t/m 3 ben ik met je eens, maar qua 4: een Flash site hoeft niet star te zijn, accessibility kun je zo goed maken als je wilt, tekst kun je erg goed inzoomen (standaard functie van de player). Flash voor handhelds is juist booming.

Gunp01nt schreef op vrijdag 21 april 2006 @ 21:50:
Verder verwijs ik nog even naar dit onderzoeksrapport over RIA (wat wel alweer bijna een jaar oud is, de tijd vliegt!).
Wij concludeerden vorig jaar al dat Flash op dit moment de enige echte RIA-tool is en dat AJAX en andere RIA-tools toch teveel het klassieke webmodel vasthouden.

Mind you, dat is erg voor een webapplicatie, niet voor een website of voor een website/applicatie hybride. Maar je ziet steeds vaker dat Flash binnen websites toegepast wordt voor zaken waar AJAX net tekortschiet. Niet als vervanging van websites, maar als onderdeel ervan.


[...]


Het SWF formaat is een open standaard (vandaar dat applicaties zoals Swish of OpenOffice het ook kunnen uitlezen en opslaan), het FLA formaat (met de ruwe designinformatie zoals die door de Macromedia Flash designer wordt opgeslagen) is idd. proprietary.

Bovendien zal 90% van de designers op deze aarde het echt een worst wezen of het formaat open is proprietary. Macromedia Adobe doet goed zijn best om de Flash player wijdverspreid te maken en zorgt dat er voor alle platformen een uniforme Flash player is.

Helemaal mee eens.

Samengevat Vasili, zou ik je vraag niet of/of stellen maar en/en. Gebruik html, javascript, ajax of flash waar het echt handig voor is, combinaties kunnen prima maar probeer niet alles met 1 gereedschap te realiseren. Met een hamer krijg je een stuk hout uitendelijk wel doormidden of een gat in de muur maar een zaag en een boor zijn er niet voor niets.

[Verwijderd]

Ik denk dat idd dat, (zeker voorlopig), de juiste aanpak is.. Ik denk wel dat ik in afzienbare tijd Flash er bij moet leren.. Flashsites hebben nu nog hun nare nasmaak van de langdurige animaties.. maar het is denk ik een matter of time tot er flash apps komen die net zo veel en net zo goed hun doel bereiken als html pagina's. In elk geval kan flash tijd, en bugs besparen..

LB Back schreef op woensdag 26 april 2006 @ 15:39:


Als je naar de echt grote corporate sites (Volvo, Adidas, Nike, Volkswagen, Ikea, Mercedes en ga zo maar door, typ een grote naam in je browser en 95% kans dat er Flash video of andere elementen wordt gebruikt) kijkt zie je dat ze allemaal Flash gebruiken voor met name interactieve Rich Media. De penetratie van de Flash plugin is een stuk groter dan bvb Media Player, Real of Quicktime. Met de laatste codec, On2 VP6, is de kwaliteit van Flv ongeveer even goed als Quicktime, zelfs bij high-motion. En ook wordt Flash steeds meer gebruikt voor navigatiedoeleinden, zoals bij KPN.
.

Lost Boys (die mercedes en volkswagen heeft gedaan uit jouw lijstje) en talloze andere sites heeft ontwikkelt, is zich ook bewust van RIA. Tijdens mijn stage daar was er veel om te doen. Ik heb per slot van rekening het drukwerk voor een groot deel gedaan voor een RIA congres waar lost boys, macromedia, backbase en anmi aan meededen. HELAAS kon ik daar niet bij zijn zelf. Wat ik zelf een knap staaltje RIA vind is een product van Lost Boys: http://www.vaya.nl
Een reisorganisatie waar je online kunt boeken. Eerlijk gezegd heb ik nog niet gekeken of ze ook ajax gebruiken.

[Orphix]

Ik denk persoonlijk dat Flash een heel mooi product is. Voor veel (interne) online applicaties mag je best eisen stellen aan de klant, dus ook dat Flash geinstalleerd is. Beschikbaarheid is voor mij in dat geval een non-issue. Ook vindbaarheid door zoekmachines is voor veel online applicaties niet interessant.

Waarom hou ik me dan nog maar nauwelijks met Flash bezig? Ik denk dat het komt omdat ik een developer pur-sang ben. Ik heb qua design veel verstand van HTML, CSS. Maar mijn creatieve kanten in Flash is niet om over naar huis te schrijven. Veel Flash wordt gemaakt door juist die andere groep mensen: de designers.

Maar nu, om een echte applicatie te bouwen heb je beide mensen nodig. En misschien dat het daar spaak loopt. De laatste keer dat ik naar Flash heb gekeken (alweer jaar geleden) vond ik ActionScript niet prettig om in te programmeren. Daarnaast had ik het gevoel direct heel dicht bij het design te zitten. Designers vinden het makkelijk ontwerpen en werken in Flash, maar het programmeren en communiceren met een applicatie op een externe server is weer een vak apart.

Het is mij tot op de dag van vandaag niet duidelijk hoe en of ik makkelijk vanuit Flash kan communiceren met bijvoorbeeld een ASP.NET applicatie. En is dit eenvoudig te doen door een designer? Kan ik de code van een Flash object los bijhouden in mijn eigen versiebeheer? Mijn eigen editor gebruiken?

Daarnaast bieden bestaande platforms zoals ASP.NET, Java, maar ook PHP goede dynamische control mogelijkheden. Al dan niet via 3rd party controls. Het blijft eenvoudiger om volgens het paradigma van het platform te werken dan je eigen truukjes uithalen in combinatie met flash.

[Verwijderd]

My words exactly... het weeskind spreekt mijn gedachten. Ik heb flash ook 'uitgeprobeerd' en ik heb inderdaad het idee dat ik niet de doelgroep ben.

Is de kloof tussen Flash en Web 1.0/2.0 nu werkelijk een gebruiksvriendelijkheid en ondersteunings issue. Ik denk het niet. Het zijn eerder argumenten om je eigen kindje te beschermen. Waar niks mis mee is. Ik spreek het in elk geval uit. Ik hou van dat mysterieuse nerdtalk onder elkaar.. De uitdagingen en dat je met redelijk low basic tools, vanaf scratch de wereld op zet. (er van uitgaande dat de lezers hier al weten dat het web meer is dan informatie en entertainment.. het web is de nieuwe wereld.) Bijna dezelfde discussie waar ik naartoe neig is code versus WYSIWYG.. voordat de hell los breekt.. WYSIWYG is bij lange na niet wat je kunt met coden.. maar laat ik voorzichtig zeggen, dat veel standaard code tegenwoordig heel netjes opgemaakt kan worden door bepaalde programma's. (dan heb ik het niet over Frontpagina van MS...) En dat het een kwestie van het juiste programma uitkiezen en de meta-tags aanpassen is om het onderscheid niet meer te kunnen zien. Stramien in een WYSIWYG maken, CSS kan ook prima in WYSIWYG..niet? misschien een uitdaging voor nieuw project.. zal vast wel bestaan. Ik denk dat als we de ogen sluiten voor 'het oog wil ook wat' dat we bedrogen uitkomen.. techniek is iets wat mensen vereenvoudigd, sneller, beter, betrouwbaarder maar vooral ook gestandaardiseerd willen...

Modbreak:

Ik heb je flame over Frontpage weggehaald, volgende keer bij dit soort taalgebruik krijg je een OW, het is nergens voor nodig.

[ Voor 7% gewijzigd door André op 27-04-2006 08:51 ]

[sanderb]

Verwijderd schreef op woensdag 26 april 2006 @ 21:47:
My words exactly... het weeskind spreekt mijn gedachten. Ik heb flash ook 'uitgeprobeerd' en ik heb inderdaad het idee dat ik niet de doelgroep ben.

Als jij de Vasili bent die ik denk dat je bent, dan zou je juist wel tot de doelgroep behoren. Je hebt dan nml geen die-hard informatica gedaan en bent geen die-hard coder. Bij ID heb je leren werken met vormgevers...en ook leren omgaan met hun af en toe in jouw ogen rare manier van denken.

Het probleem van flash is dat het ooit is begonnen als een puur grafische tool. Nu flash met as2 een beetje volwassen begint te worden zie je een duidelijke scheiding tussen flash-vormgevers en flash-coders ontstaan.

Helaas merk ik vaak dat op dit forum een handjevol echte flashcoders zit, en een paar handen vol mensen die iets over een klok en een klepel hebben gehoord, maar geen idee hebben welke bel al dat geluid maakt.....

Zeker met flash 8 (en straks met as3 nog meer) zijn er een heleboel mogelijkheden bijgekomen in flash, die dingen mogelijk maken die met andere clientside scripting simpelweg niet kunnen.

Zoals een paar wijze mensen voor mij al gezegd hebben, gebruik een tool (taal) waarvoor ie bedoeld is.

Orphix schreef op woensdag 26 april 2006 @ 21:18:
1. Het is mij tot op de dag van vandaag niet duidelijk hoe en of ik makkelijk vanuit Flash kan communiceren met bijvoorbeeld een ASP.NET applicatie.
2. En is dit eenvoudig te doen door een designer?
3. Kan ik de code van een Flash object los bijhouden in mijn eigen versiebeheer?
4. Mijn eigen editor gebruiken?

1. Ja, dat kan makkelijk. communicatie via xml (al hoeft dat niet) met serverside scripts is eenvoudig te doen. ook zijn er aparte oplossingen als amfphp bedacht.
2. Wil je dat een designer dat doet? en wil die designer dat uberhaupt wel? Als een designer een beetje kan scripten, dan kan ie dat ja
3. Ja
4. Ja

Overigens is RIA een door Macromedia bedachte term. Ik geloof dat de definitie van een rich internet application hier ook nogal uiteen loopt.
Het voorbeeld van lost boys dat Vasili een RIA noemt, noem ik geen RIA. Waar vind ik daar de R terug?

[Verwijderd]

Hoi Sander.. Das gek he.. dat ik meer kan dan wat ik heb geleerd tijdens de opleiding? Best opvallend dat mensen van de opleiding INTERACTION design.. zich vooral bezig houden met dat laatste woord. :-p.. techniek is inderdaad helaas een ondergeschoven kindje. Terwijl interactie ZEER afhankelijk is van techniek.(inherent aan elkaar) In ieder geval heb ik het licht gezien. Mensen van de opleiding achtervolgen me nu blijkbaar ook met de stempel: "jij bent géén techneut".

ik weet dat macromedia mij probeert als doelgroep te zien. Ik zeg er ook bij dat ik er niet genoeg kaas van heb gegeten. Maar eerste indruk van de taal is dat het voor 90% is gericht op puur visuele functies, atributen,...

http://www.macromedia.com.../actionscript_dictionary/

Zie deze lijst aan 'dingen' maar.. I think you get my point. Ik heb gewoon echt het idee dat ik in het engels zou schrijven, wat ik in de WYSIWYG zie/doe.

Anyway Sander. Ik ben het wél met je eens dat Flash een zeer complete tool is, en dat de tegenargumenten vaak zijn bedoeld omwille van het...'tegen zijn'. geneuzel over gebruiksvriendelijkheid, het gebruik van shortcuts, compatibiliteit en bookmarks. Zijn problemen die mettertijd op te lossen zijn, of gewoon incompetentie van de flashers.

Een goeie Flasher kan ook corporate websites maken die gewoon rustig ogen, zakelijk, en die ook net als 'normale websites' geld in het laatje brengt in waarschijnlijk minder tijd en ergenis dan een webdeveloper. Je moet als webdeveloper 1000 dingen in de gaten houden, verschillende talen toepassen, hacks inzetten (waarvan sommige niet meer werken bij nieuwe browsers) Het is mij om het even.. als ik nu aan de voet van de berg zou staan, zou ik kiezen voor Flash instead. Des te meer reden om te bewijzen dat de vooroordelen over Flash niet kloppen.

Maarja eigenlijk wil ik gewoon verder met web2.0

[ Voor 3% gewijzigd door André op 27-04-2006 14:24 ]

[Emielio]

Datafeest schreef op zondag 23 april 2006 @ 13:21:
[...]

Als ik het juist heb is er voor Linux 64bit nogsteeds geen Flashplayer. Linux 32bit heeft Flashplayer v7, terwijl Windows v8 heeft. Het lijkt mij zeer onverstandig om het SWF formaat, wat volledig afhankelijk is van deze plugin, op een nog grotere schaal te gebruiken dan nu gebeurd. Stel dat iedere website op Flash zou draaien, dan heeft één enkel commercieel bedrijf de macht een groep gebruikers uit te sluiten om gebruik te maken van internet, dat is een situatie die altijd moet worden voorkomen.

Hier ben ik het volledig mee eens. Door flash toe te passen Verplicht jij je publiek een product af te nemen van 1 bedrijf. Hetgeen een monopoliepositie creeerd. Omdat het bedrijf in sommige markten geen brood ziet zal deze doelgroep genegeerd worden en buiten de boot vallen. NIET IN STAAT ZIJN JOU WEBSITE TE BEZOEKEN. Dit is een heel kwalijke zaak. Dus op het gebied van internet vind ik dat we ten allen tijden voor open standaarden moeten gaan.

[Verwijderd]

Modbreak:

Een OW is een Openbare Waarschuwing, de eerste heb je nu te pakken, check je mail

[ Voor 92% gewijzigd door André op 27-04-2006 14:29 ]

[Verwijderd]

sanderb schreef op donderdag 27 april 2006 @ 01:26:
Overigens is RIA een door Macromedia bedachte term. Ik geloof dat de definitie van een rich internet application hier ook nogal uiteen loopt.
Het voorbeeld van lost boys dat Vasili een RIA noemt, noem ik geen RIA. Waar vind ik daar de R terug?

overdaad schaadt.. goed zoeken (lees uitproberen) en gij zult vinden..

[T-MOB]

Verwijderd schreef op donderdag 27 april 2006 @ 11:30:
Er zijn open source plug-ins voor.. dont worry..

Jup, ik draai hier met GPL flash plugin voor mozilla. Die laat regelmatig mijn hele browser crashen. Als je als developer rekening wil gaan houden met dit soort nukken heb je dezelfde situatie als met javascript: Je moet dan van alle mogelijke clients weten wat de nukken zijn en daar omheen werken.

offtopic:
Ow, en "OW" staat voor Officiele Waarschuwing.

[ Voor 10% gewijzigd door T-MOB op 27-04-2006 11:55 ]

[Tsjilp]

Actionscript was ook een designertaaltje, vergeet niet dat flash ooit is begonnen als medium om simpele animaties mee te maken, pas vanaf flash MX is het hele actionscript gebeuren echt opgekomen. Flash8 biedt een heel scala aan nieuwe mogelijkheden, maar heb op het gebied van AS nog geen grote verbeteringen mogen zien (heb er dan ook nog niet zoveel mee gewerkt, werk nog steeds met MX04). Al die argumenten over het niet kunnen doorspoelen van een animatie: dat ligt aan de designer/developer, niet aan flash. Ik kan ook in JS/DHTML een animatie maken waar je op moet wachten voordat je de content te zien krijgt.
En wat betreft de plugin die van 1 bedrijf is: dat is quicktime / real / wmv toch ook?
De enige nadelen aan flash vind ik:
-Backbutton
-Zoeken in tekst
-Favorieten
Maar deze nadelen zijn allemaal te ondervangen, kost alleen wat meer tijd.

[Verwijderd]

good point.. niks aan toe te voegen

[Pendaco]

Emielio schreef op donderdag 27 april 2006 @ 11:03:
[...]


Hier ben ik het volledig mee eens. Door flash toe te passen Verplicht jij je publiek een product af te nemen van 1 bedrijf. Hetgeen een monopoliepositie creeerd. Omdat het bedrijf in sommige markten geen brood ziet zal deze doelgroep genegeerd worden en buiten de boot vallen. NIET IN STAAT ZIJN JOU WEBSITE TE BEZOEKEN. Dit is een heel kwalijke zaak. Dus op het gebied van internet vind ik dat we ten allen tijden voor open standaarden moeten gaan.

Ik vind dit eerlijk gezegt wel een vrij egocentrisch uitgangspunt/argument.
Vrijwel alle (professionele) websites doen eerst wat vooronderzoek (of laten dit doen), waar onderzoek naar de doelgroep een vrij belangrijk onderdeel van is.

Als die bekend is bekijk je welke aanpak (html/css of flash of ajax etc.) het meest geschikt is voor de doelgroep van de website.

Ik zie een website van de overheid nou niet zo snel flash/ajax gaan gebruiken aangezien zij zo'n grote doelgroep hebben (d.w.z. iedereen).

[alienfruit]

Ach, of je nou afhankelijk bent van browsers maken in het implementeren van de standaarden, of dat je afhankelijk bent van een maker en zijn ondersteuning. Tja, ik zie het verschil niet. Als je wil kan je ook je eigen flash player maken. Geen probleem.

Maar ja, zelf vind ik het gebruik Flash voor video op website heerlijk, geen extra plugins e.d. nodig om films te bekijken. Geen irritante quicktime, of realplayer maar gewoon alles in één.

[ Voor 28% gewijzigd door alienfruit op 27-04-2006 15:36 ]

[MarkvE]

Flash is leuk voor een extra touch aan een website, een kleine webgame, of iets anders waarbij het geen must is dat het speeltje door iedereen gebruikt kan worden. Flash is namelijk zo ontoegankelijk als wat voor gebruikers, want gebruikers vertrouwen op het standaard gedrag van het systeem dat ze draaien. Zodra je Flash gebruikt ontbreken deze, en wil je deze toch beschikbaar maken moet je die systeemfuncties gaan nabouwen en dat is altijd minder dan het origineel.

Zo geldt het net zo goed dat je geen complete website op Ajax moet laten rusten, ook dit is bedoeld voor de kleine extra's van een website.

Tot op heden bestaat een toegankelijke website nog altijd uit HTML, CSS en hooguit een foefje Flash/Ajax/whatever.

[alienfruit]

Natuurlijk, het gebruik van html en css het belangrijkste. Maar ik zie niet veel in het online beschikbaar stellen van services zoals een online tekstverwerker. Ik echt niet fatsoenlijk werken met die online tekstverwerker Writely. Ik vind zoiets nou niet echt gebruikersvriendelijk, het is nog erger dan Word lol.

[BCC]

Wat mis in deze discussie is een blik naar de toekomst. Je kunt met je PSP en je telefoon tegenwoordig al internetten en dat soort toepassingen zullen volgens mij alleen maar groeien.

Ga je op dit soort devices makkelijk HTML / CSS laten zien? Ja, want de content en de grafische weergave zijn volledig gescheiden.

Voor flash zie ik een heleboel problemen. Naast het feit dat de groote van 't bestand zeker een issue wordt (ivm krappe bandbreedte) Gaat een prachtige flash site van zeg 800*600 nooit op je mobieltje passen.

Daarnaast vind ik ook de features waarop hier gedoeld worden nuttiger zijn voor webapplicaties dan voor websites. Voor het maken van webapplicaties zijn de afgelopen jaren al een paar grote frameworks ontstaan webapplicaties ondersteunen (Ruby on Rails, J2EE, ASP.NET). Deze gebruiken vooral Javascript, HTML en CSS, wat dus blijkbaar de way to go is? Voor flash heb ik dat soort dingen nog niet gezien hoewel dit met Flash MX prima mogelijk moet zijn.

[ Voor 5% gewijzigd door BCC op 27-04-2006 17:36 ]

[Verwijderd]

Verwijderd schreef op donderdag 27 april 2006 @ 11:30:
[modbreak]Een OW is een Openbare Waarschuwing, de eerste heb je nu te pakken, check je mail :/[/modbreak]

Wat ik nou niet snap:

"Ik heb je flame over Frontpage weggehaald, volgende keer bij dit soort taalgebruik krijg je een OW, het is nergens voor nodig."
dit heb ik ten harte genomen.. er van uitgaande dat een "flame" stoute woordjes zijn... ik vraag op het forum wat een ow is.. en dat flame niet in het woordenboek voorkomt:

"Ik heb je flame over Frontpage weggehaald, volgende keer bij dit soort taalgebruik krijg je een OW, het is nergens voor nodig." en dan krijg ik spam van deze goede meneer.. niet erg consequent....

Modbreak:

Klagen mag je doen bij dezelfde meneer die je de spamfanmail heeft gestuurd, het is niet de bedoeling dit topic daarmee te vervuilen.

[ Voor 14% gewijzigd door crisp op 27-04-2006 22:47 ]

[E-Mile]

Wat mij wel opvalt is dat in het kader van deze discussie nog niet een maal het woord Flex gevallen is. Flex is in een beta versie van een formaat van Macromedia dat zonder de oude Flex Builder (wat in eerdere versies noodzakelijk was) geprogrammeerd kan worden. Hiermee wordt dus welliswaar op basis van het swf formaat, aan developers een mogelijkheid geboden om in een open platform software te ontwikkelen, zonder dat daar licenties voor vereist zijn.

[Verwijderd]

Verwijderd schreef op woensdag 26 april 2006 @ 13:23:
En dat http voor text bedoeld is..tja.. internet was zoiezo niet bedoeld voor waar het nu voor dient. Begon als een militair netwerk, werd toen een luxe bibliotheek voor universiteiten.. en pas later kwamen de 'normale' mensen er mee in aanraking.. ook als was het er niet voor bedoeld.

Hmmmm, volgens mij snap jij het verschil niet tussen Internet en Het Web. Nu is dat voor heel mensen hetzelfde, dus zo vreemd is die vergissing natuurlijk niet. Het Internet is kort door de bocht 'gewoon' een netwerk; in essentie een data-brug tussen N systemen. Wat je daarover heen stuurt en volgens welke protocollen is een hele andere kwestie.

Het Internet is 'bedoeld' voor data communicatie in de breedste zin van het woord. Het Web echter is een zeer specificiek gebruik hiervan: stateless connections, text based, en bedoeld om grotendeels statische informatie bronnen door te bladeren met af en toe een beperkte mogelijkheid tot dynamische generatie van data.

Neem je zoiets als het X Window protocol, dan kan dit OOK lopen via het Internet, maar de opzet en het protocol is zo compleet anders dat je nog niet eens kan beginnen met het technisch te vergelijken.

Beiden renderen echter wel remote een user interface voor een applicatie die ergens anders draait. Nu proberen we met de "Web 2.0" hype de mogelijkheden zoals het X protocol dat biedt te proppen in een protocol wat daar in essentie nooit voor ontworpen was. Aan de andere zou je zeggen waarom er dan geen beweging is om X te gaan gebruiken voor 'web applicaties'. Helaas gaat dit ook weer niet zo makkelijk. X loopt dan wel via het Internet (omdat het in essentie netwerk agnostic ontworpen is; dwz het draait net zo goed lokaal, op een lan, of op een wan), maar het vereist stiekum toch wel een bepaalde minimale bandbreedte en latency. Beiden zijn iets wat het Internet nog steeds niet (gegarandeerd) kan bieden. Tevens is X veel te zwaar voor 100'en gebruikers op 1 servertje; iets wat voor een Web app toch altijd een vereiste zal blijven.

Zelf denk ik toch dat een ASP.NET achtige techniek voor web controls die XAML renderen het meeste toekomst heeft. JSF en XUL zijn hiervan de directe tegenhangers die eigenlijk exact hetzelfde doen kwa aanpak en implementatie.

[alienfruit]

Voor flash zie ik een heleboel problemen. Naast het feit dat de groote van 't bestand zeker een issue wordt (ivm krappe bandbreedte) Gaat een prachtige flash site van zeg 800*600 nooit op je mobieltje passen.

Hetzelfde geld niet voor een website op mobiele toestellen dan? Het maakt niet veel uit of je nou een aangepaste versie van de css moet maken voor mobiele telefoons, of die van een flash site. Het probleem blijft staan dat je te maken hebt met de beschikbaar geheugen en cpu power van het toestel. Daarom worden ook aparte css en/of html pagina's gemaakt voor mobiele toestellen omdat je gewoon niet de ruimte hebt om alle informatie weer geven op de kleine schermen.

Overigens denk ik ook niet dat je zo snel Flash websites wil bekijken op mobiele toestellen, wat ook nagenoeg niet mogelijk -- omdat met name de cpu de bottleneck is. Maar dit valt bij de scope van deze topic. Flash (Lite) wordt dan ook met name gebruikt om simpele toepassingen te maken voor mobiele telefoons, zoals spelletjes e.d. Als je kijkt naar Flash Cast, of i-mode in Japan kan je zien dat er een aardige potentieel is voor html/css en flash op mobiele telefoons. Verder zijn verschillende mobiele toestellen (iriver u10, vivl p10 etc.) waaronder een paar Samsung telefoons al Flash based, de zogenoemde MMI/FLUI versie van Flash Lite, waarbij de GUI wordt gemaakt dmv. Flash.

Maar ja, het blijft dat je altijd toch een versimpelde versie van je site moet maken voor mobiele toestellen, omdat je gewoon de frontpage zoals die tweakers.net handig kan lezen op je kleine scherm van 178x208px (ofzo). Je wilt namelijk niet gegevens over de lijn sturen die vervolgens door de CSS onzichtbaar worden gemaakt, een beetje nutteloos

[Verwijderd]

Henk...de man.. Ik bedoelde het eigenlijk anders.. Ik snap allang het verschil tussen het internet en de protocollen die gebruik maken van die hardware. Waar ik eigenlijk op doelde was dat als een protocol ooit in een grijs verleden genoemd is naar de toepassing (hyper text transfer protocol) dit niet wil zeggen dat je er geen andere geintjes mee mag doen...net als het voorbeeld
namenlijk..... internet... dat is ook iets wat in de eerste instantie niet bedoeld was, voor waar het nu voor gebruikt wordt. Staat dus los van het protocol. Ik stelde er een voorbeeld mee.

[BCC]

alienfruit schreef op vrijdag 28 april 2006 @ 01:00:
[...]
Maar ja, het blijft dat je altijd toch een versimpelde versie van je site moet maken voor mobiele toestellen, omdat je gewoon de frontpage zoals die tweakers.net handig kan lezen op je kleine scherm van 178x208px (ofzo). Je wilt namelijk niet gegevens over de lijn sturen die vervolgens door de CSS onzichtbaar worden gemaakt, een beetje nutteloos

Juist. De basis van internet blijft voor mij het oversturen van data in een simpele vorm (HTML/XML oid). De vormgeving van deze data is punt 2. Daarom lijkt mij het essentieel dat je deze twee altijd strikt gescheiden houdt en bij Flash is dat (tot nu toe) onmogelijk.

[alienfruit]

Tja, Web2.0 is nou ook niet iets simpels ofzo Maar ja, je kan behoorlijk wat leuke dingen doen met Flash Lite op mobiele toestellen, maar ja dat lees je binnenkort wel

[Verwijderd]

Verwijderd schreef op vrijdag 28 april 2006 @ 01:45:
namenlijk..... internet... dat is ook iets wat in de eerste instantie niet bedoeld was, voor waar het nu voor gebruikt wordt. Staat dus los van het protocol. Ik stelde er een voorbeeld mee.

Ik snap wat je bedoeld, maar eigenlijk toch ook weer niet Wat ik eigenlijk probeerde uit te leggen is dat *toepassingen* binnen de geest van een medium natuurlijk altijd inovatief kunnen zijn. Een heel flauw voorbeeld is dat van papier. Papier was oorspronkelijk uitgevonden om gewichtige dingen te noteren (wetten, filosofische overdenkingen, etc). Het 'volk' had niet de beschikking over papier. Vandaag de dag gebruikt men papier voor kassa-bonnetjes, reclame folders, en flut rommantjes.

Echter *de aard* van de informatie zelf maakt niet dat het papier feitelijk oneigenlijk gebruikt wordt. Ga je nu opeens gewoon papier gebruiken als constuctie materiaal voor auto's, dan is dat duidelijk niet de bedoeling van het oorspronkelijke 'papier'.

Vergelijk dit nu met het Internet. Dit is, zoals gezegd, een netwerk voor datacommunicatie. Welke data je eroverheen stuurd, of wie dat doet maakt weinig uit. Zo was het eerst het leger, toen de academische wereld, daarna de liefhebbers, en vandaag de pubermeisjes die het net gebruiken. Allemaal sturen ze informatie (of in het geval van de pubermeisjes, non-informatie ), maar al het gebruikt valt nog steeds binnen het oorsponkelijke ontwerp.

Neem nu HTTP. Dat is ontworpen om hyper tekst weer te geven, en dan met name HTML. Eigenlijk niet meer dan wat platte tekst met enkele opmaak tags waarbij de hyperlink en de back button centraal staan. Zelfs de img tag is er op een gegeven moment door Netscape hard doorheen gedrukt (ik kan me nog een usenet post herinneren waarin er melding wordt gemaakt dat Netscape zo zonder overleggen met wie dan ook een img tag ging supporten).

Nu kun je innoveren tot je een ons weegt, maar dit model is in essentie niet geschikt voor statefull rich interfaces. Daarom komen er allemaal truukjes. Een apart 2de taaltje binnen je gewone applicatie dat je naar de client toe stuurt om daar de wensbare gang van zaken enigzins te emuleren. Dat is geen vereiking noch een innovatie; dat is een gedwongen workaround.

Vanwege de aard van het HTTP protocol is het door zo velen gewenste MVC ook niet echt mogelijk binnen het web. Frameworks als JSF of ASP.NET proberen dit wel enigzins te emuleren, maar niet volledig. Dit worden dan ook zogenaamde Model 2 frameworks genoemt; een variant op het eigenlijk pattern waarbij het model niet in staat is om de view zelfstandig up te daten (dit is eigenlijk een essentieel onderdeel van het pattern).

Veel andere zaken botsen ook; zo geeft in web applicatie de browser address bar niet altijd de juiste URL weer overeenkomstig met de pagina die je ziet. Sommige applicaties hebben ook helemaal niet echt pagina's, maar het web dwingt developpers wel om daarin te gaan denken, en gebruikers eisen ze ook.

Technisch zit je bijvoorbeeld vaak met het feit dat een controller aan de hand van state bepaald welke view er getoont gaat worden. De browser 'merkt' daar echter niets van; je POST naar url A, en de controller beslists aan de hand van code die runt dat de view pagina B wordt. Daarna post je weer wat en de controller besluit dat de view pagina C wordt. De URL die je browser laat zien loopt dus telkens 1'tje achter. Je kunt dit 'oplossen' door een redirect te sturen naar je client, maar dan kun je weer geen POST parameters mee geven.

Een oplossing is om de state in een sessie bij te houden, maar dan loop je weer het risico dat je sessie vol staat met dingen voor users die er allang niet meer zijn. In een normale applicatie ondervang je zoiets weer doordat je 'weet' wanneer je client weggaat (jouw remote app afsluit). In het web sluit de gebruiker gewoon de pagina of surft ergens anders heen; maar dat krijg jij aan de server kant niet te zien.

Een ander direct gerelateerd probleem is het feit dat een gebruiker een zelfde URL meerdere keren kan openen; in verschillende tabs of in verschillende windows. Er bestaat niet zoiets als een "window" scope; het protocol heeft niet de mogelijkheden om een 'window-ID' mee te sturen.

Laat ik tevens maar niet beginnen over het gebruik van de backbutton en webapplications en state. Daar zijn complete boeken van geschreven over alle problemen die daar mee samen hangen.

Nu zijn er bijna overal wel op de een of andere manier workarounds voor te bedenken. Zo kun je een javascript OnUnload handler op je pagina zetten zodat je weet wanneer de gebruiker weggaat, en je kunt hidden input elementen neerzetten die een 'sub-session' ID bij houden.

Allemaal zijn het echter precies hoe je het noemt: workarounds, workaround en nog eens workarounds. Veel developpers worden daar heel erg moe van af en toe, zeker als je al -jaren- met web apps bezig bent. Vandaar dus dat mensen terecht klagen over het feit dat AJAX wel leuk is, maar alleen maar mogelijkheden tot meer workarounds biedt. Velen voelen dat het tijd is voor een fundamentele update die het probleem met HTTP en web apps wat fundamenteler aanpakt dan alleen wat client-side scripting truukjes.

[Verwijderd]

En wat als die workarounds nu opgelost worden? Als je het goed en structureel programmeerd (zoals ik heb gedaan) werkt het ontzettend goed, geen rare errors, het werkt in Firefox en IE en het is niet met flash gedaan.

Het probleem is denk ik ook dat mensen niet ruimer willen denken, AJAX is op zich iets raars, je kunt ineens (nouja, ineens.. je kon het al langer) veel meer en het probleem is dat je bij de oude "denkwijze" blijft hangen.


Ook de flames over dat Javascript geen volledige taal oid is, vind ik erg stom... Ik bedoel, Live.com werkt hier inderdaad op dit moment voor geen meter, maar kijk eens naar bijvoorbeeld deze:

http://www.netvibes.com/

En binnenkort komt er Gulst, waar ook allemaal geen gebruik van Flash is gemaakt, wat ook ontzettend goed werkt in elke browser.

Waar zit dan het probleem? Debuggers voor Javascript? Denk het niet... Gewoon goed gestructureerd coden, logisch nadenken en dingen op een verstandige en gestructureerde manier aanpakken. En begin niet in het wilde weg iets in javascript te doen, dan kom je inderdaad in de problemen.

[SilentSimon]

Maar de plugin voor Flash is toch in no-time te downloaden als je m niet hebt? Als je de plugin niet hebt heb je m wel in 5 seconden zo klein is de plugin.
Verder ben ik zelf ook veel bezig met RIA's en ik denk dat het toch de toekomst is.
Vooral omdat de grafische mogelijkheden bij flash in samenwerking met database's bijna schier eindeloos is. Het staat allemaal nog in de kinderschoenen, ik denk dat Flex de echte toekomst heeft.