Waarom geen frames..?

[Obi]

Yo Tweakers en tweakerinnen,

Ik ben bezig een nieuwe corporate site te maken. Nu vind ik dat er geen frames in moeten komen, maar mijn collega is het niet met mij eens.
Ik zeg dan nog dat elke goede grote site geen gebruik maakt van frames, en hij zegt dan weer: "macromedia.com wel". Ik weet verder eigenlijk de redenen ook niet echt, maar wel vind ik het mooier zonder frames, hij niet.

Nu vraag ik mij af wat nou de reden is dat 'frames niet (meer) kunnen'.

[bekkel]

is makkelijker met gebruik van php en dergelijke

[Obi]

Op dinsdag 17 juli 2001 10:14 schreef bekkel het volgende:
is makkelijker met gebruik van php en dergelijke

Hmz, da's wel interessant. Ben geen programmeur, maar wel geinteresseerd. Kan je dit misschien toelichten..? Lijkt mij persoonlijk niet veel verschil uitmaken, maar zoals gezegd; ik ben geen programmeur. (ik moet nou toch echt 's aan de PHP... maar heb er steeds geen tijd voor..

[edwinistrator]

plus je kan makkelijker in je navigatie laten zien waar je zit zonder dat de back toets niet meer werkt, ik bedoel als je op back drukt dat je ook in je navigatie back gaat. anders moet je dat weer met images swappen of zo gaan oplossen. En verder hoef je dan ook geen framejammer er in te bouwen.
want je hebt geen gezeur meer met crosslinkjes dan.

[Verwijderd]

Op dinsdag 17 juli 2001 10:14 schreef bekkel het volgende:
is makkelijker met gebruik van php en dergelijke

Das bullshit

Ik kan niet anders concluderen dat iedereen als kippen zonder kop achter elkaar aantokt, en "tables roeleren, frames zuigen", schreeuwen.

Frames kunnen nog steeds voor een decrease van je load zorgen. Waarom navigatie elke keer herladen bij het klikken van een link?

Enige voordeel wat ik kan bedenken is dat je JavaScript niet meer framesgeorienteerd hoeft te zijn.

[Coyote]

Een andere reden waarom ik meestal geen frames gebruik is omdat mensen die via een zoekmachine op internet op je pagina komen nooit op je frames-pagina binnenkomen.

Hierdoor missen ze vaak het menu van je site in beeld en hierdoor dus ook de rest van de site.

ok, dit is wel weer op te lossen met een javascrippie.. maar toch..

[Verwijderd]

Op dinsdag 17 juli 2001 10:25 schreef Coyote het volgende:
Een andere reden waarom ik meestal geen frames gebruik is omdat mensen die via een zoekmachine op internet op je pagina komen nooit op je frames-pagina binnenkomen.

Hierdoor missen ze vaak het menu van je site in beeld en hierdoor dus ook de rest van de site.

ok, dit is wel weer op te lossen met een javascrippie.. maar toch..

Daarvoor hebben we een robots.txt

Tevens kun je in je frameset gewoon metatags gebruiken, en zal een spider de pagina's hangende aan je frameset gewoon ook doorzoeken.

[RM-rf]

'mooier' is inderdaad niet zo'n duidelijke reden, als dat alles is kun je lang gaan delibreren.
'mooi' is namelijk enkel toegestaan voor gebruik in combinatie met wordart en comic sans.

wat je wel kunt doen is de structuur van de informatie eens bekijken, hoe wil je dat mensen gebruik maken van de site en hoe dient de laadtijd verdeelt te worden.

als je met uitgebreidde uitklapbare menuutjes zit tot 5 levels diep die iedere keer een korte pagina oproepen kan een frameset veel voordeel hebben.

uiteindelijk is het zo dat een frameset toegevoegd wordt aan een pagina, dus het is zo dat met die frameset een bepaald doel gediend dient te worden, vooral op het gebied van navigatie.
de frameset deelte je venster op in meerdere venster (vergelijk het met een mail-agent, een venster voor de hoofd-dirs; inbox, outbox, etc., een venster voor lijst met ontvangen mails en een venster voor het vertonen van de tekst van de mail zelf; deze dienen het gebruiksgemak, je hebt nu eenmaal overzicht nodig over alle informatie)

enkel een frameset voor layout technische overwegingen is minder slim, dit is vaak ook al met layer-positioning te bereiken, vanuit layout-overwegingen framesets gebruiken leidt tot veel problemen met je scripting (document.frames-model: alles gaat via parent- of top.window.-blah) en geeft problemen met searchengines

[Obi]

Ik zal even het adres geven zodat jullie weten waar het over gaat: id-t.com

Nu werken we wel met een frameset, m'n collega wil het graag zo houden, maar ik zit te denken om het er uit te slopen. (we zijn met een restyle bezig, daar komt de discussie uit.)

Het gaat een PHP driven site worden, met veel content (alle afdelingen van het bedrijf, bijvoorbeeld ID&T Radio, ID&T Music, Events enz. Tevens een community gedeelte met online aanschafmogelijkheden van allerlei shit, forum, streams van evenementen enz.).

[DeFeCt]

Ik ben het helemaal met gordijnstok eens (en dat is wel eens anders geweest ).
Probeer voor jezelf dan tenminste drie redenen te bedenken waarom je geen frames meer wil en dat het mooier is... waarom in godsnaam
Omdat je scrollbalk doorloopt naar boven
Omdat je je navigatie kwijt bent zodra je gaat scrollen

Jaren lang is het geen enkel probleem om frames te gebruiken en hier en daar een parent neer te kwakken en opeens is het allemaal not done, ik snap dat niet helemaal.
Netzo als dat ik niet snap wat comic sans met mooi te maken heeft

En ik heb zo het idee dat je doelgroep je toch wel weet te vinden, daar hebben ze geen search-enigne voor nodig.

Mijn grote argument voor frames is dat je sommige elementen niet telkens opnieuw hoeft te laden en dat je interface ten alle tijden zichtbaar blijft.

Opmerking over de huidige site:
Ik vind dat je erg veel ruimte reserveert voor drie knopjes...

[Obi]

Opmerking over de huidige site:
Ik vind dat je erg veel ruimte reserveert voor drie knopjes...

Haha, dat is het resultaat van de afdelingen die zich gaat bemoeien met de vormgeving
Alles moet GROTER
Eerest had ik alles in pixelfontjes gedaan, maar dat was toch wel iets te klrin. Ben nu met een nieuw concept bezig.
Wordt allemaal wat netter..

[cutter]

Als je met php gaat werken is een verdeling in frames voor het technische gedeelte van de navigatie niet nodig.

Je kunt er hooguit voor kiezen omdat het de usability van de site ten goede komt. Zo zou je aan de bovenkant een hele smalle frame kunnen maken met de directe links naar de bedrijfsonderdelen. Bij een bezoeker is die informatie dan altijd aanwezig. Misschien handig om de shop altijd naar voren te laten komen.

[cutter]

Op dinsdag 17 juli 2001 11:02 schreef DeFeCt het volgende:

Mijn grote argument voor frames is dat je sommige elementen niet telkens opnieuw hoeft te laden en dat je interface ten alle tijden zichtbaar blijft.

Is het niet zo dat dat eigenlijk niet uitmaakt omdat de vaste elementen uit je template toch wel uit je cache gevist worden.

[OzBoz]

Het is al gezegd maar het feit dat ik regelmatig frames gebruik is inderdaad het feit dat je de navigatie dan altijd in het zicht van de gebruiker houdt. Usability dus.
Tweakers.net + GoT vind ik wat dat betreft ook niet vriendelijk, zeker omdat je nogal afstanden moet scrollen en als modje zou ik het heerlijk vinden als meer mensen die search knop zagen zitten

[cutter]

Op dinsdag 17 juli 2001 11:19 schreef OzBoz het volgende:
Tweakers.net + GoT vind ik wat dat betreft ook niet vriendelijk, zeker omdat je nogal afstanden moet scrollen en als modje zou ik het heerlijk vinden als meer mensen die search knop zagen zitten

Maar dat lijkt me op te lossen met een hele mooi dhtml div ala geocities. Zo'n mooie jongen die altijd heel groot met je meescrolled. Of gebruik een mooi http://www.boston.com/mediakit/shosh_atbat.htm achtig iets

PHP:

<?
;if ($userposts) < 10 {    include('UTFS-Flash-Movie.inc');}
?>

Iedereen die nog geen tien posts heeft krijgt een prachtige flashmercial te zijn met UTFS of zoiets.

[Verwijderd]

Op dinsdag 17 juli 2001 11:02 schreef DeFeCt het volgende:
Ik ben het helemaal met gordijnstok eens (en dat is wel eens anders geweest ).

Huh Noem eens een voorbeeld

Maar gelukkig ben ik de enige niet die er zo over denkt ...

[Bosmonster]

Even zoeken op frames had je waarshcijnlijk een 200 itemlange topic opgeleverd ofzo, maar goed:

- Frames zorgen voor MEER load, aangezien je een server-connectie moet maken voor iedere page die je laadt. Images e.d. hoeven nooit opnieuw geladen te worden, aangezien we tegenwoordig browsers hebben die dit soort dingen cachen.

- Frames zijn een ramp met dynamische content. Vaak moet je als je een pagina in wilt laden al je framses vernieuwen (zie boven) om weer tot een up-to-date content te komen.

- Frames maken een goeie zoek-optie rete irritant. Wederom moet je ipv 1 pagina, nu elke keer een frameset genereren die wer pagina's genreert etc.

- Frames maken websites lastig onderhoudbaar. I.p.v. 1 template per pagina heb je nu tig pagina's nodig om tot 1 scherm te komen.

- Frames maken de back-button (de meest gebruikte optie in de browser) onbruikbaar.

- Frames worden niet goed weergegeven in Netscape, waardoor je beperkt bent in je layout.

- Frames zorgen ervoor dat je Javascriptjes moet gaan gebruiken voor bijna ALLES. Als je je back-button weer wilt laten werken, voor resize dingen (Netscape), voor frame-generatie (Netscape), plaatjes laten switchen tussen frames, meerdere frames verversen (zie ook punt 1). etc etc.. ramp dus en strop op de productiekosten.

- Frames zorgen voor minder reloads en dus minder inkomsten in geval van banners. Tenzij je de banners net als je scrollbalken midden in je page wilt zetten natuurlijk. Frames zijn daardoor voor portals/commerciele sites sowieso al taboe.

- Scrollbalken midden in je site-ontwerp zijn lelijk en onnatuurlijk (wat? frames zijn goed voor usability?? welke opleiding heb jij gevolgd??)

-- Met frames ben ej een stuk beperkter in je vormgeving aangezien je ook geen Flash/DHTML over de randen heen kunt laten vallen.

Zal er nog wel een zooi vergeten zijn, maar goed..

Frames hebben heel af en toe nut (bijvoorbeeld als je een enorme lijst items hebt, bijvoorbeeld images ofzo), maar vaak is het te voorkomen.

[Verwijderd]

[b]Op dinsdag 17 juli 2001 11:30 schreef cutter het volgende:[/b}
Maar dat lijkt me op te lossen met een hele mooi dhtml div ala geocities.

Dat is IMHO het paard achter de wagen spannen, onder het mom van "waarom makkelijk doen als het moeilijk kan". Frames kunnen erg handig zijn bij het indelen van je site zoals Rm-rf al aangaf, verder kan je de empty.htm pagina's volgooien met H1-keyword tags, wat je ranking bij de search engines ook weer ten goede komt.

Gooi dit in je lege pagina's en je probleem, dat mensen niet op de pagina komen die jij bedoelde, is ook verholpen.

code:

<script language="javascript">
<!--//

function inframe()
{
  if(top==self) 
  {self.location.href='http://www.whatever.xx';}
}

//-->
</script>

Verder, dat het gebruik van frames lijdt tot een minder mooie site is natuurlijk de grootste onzin, probeer eens;

code:

border=0 frameborder="no"

je zal zien dat je de frames niet meer terugvindt

[Verwijderd]

Op dinsdag 17 juli 2001 11:39 schreef Bosmonster het volgende:
Even zoeken op frames had je waarshcijnlijk een 200 itemlange topic opgeleverd ofzo, maar goed:

- Frames zorgen voor MEER load, aangezien je een server-connectie moet maken voor iedere page die je laadt. Images e.d. hoeven nooit opnieuw geladen te worden, aangezien we tegenwoordig browsers hebben die dit soort dingen cachen.

Ok stelling:

Ik heb eem frameset met 3 pagina's, waaronder navigatie.html, content.html, nogiets.html.

Als ik in de content klik, ga ik naar een andere pagina toe, zonder dat de andere 2 frames herladen

Met tables ga ik telkens de 3 bestanden in 1 bestand includen.. Voila, daar gaat je load.

Oftewel, frames = minder load.

- Frames zijn een ramp met dynamische content. Vaak moet je als je een pagina in wilt laden al je framses vernieuwen (zie boven) om weer tot een up-to-date content te komen.

Is niets anders als luiheid. Wat is het verschil tussen 3 templates telkens includen of framepje.location.replace te doen.

Juist: Dat je de templates dus altijd included, en dat is met frames niet nodig.

- Frames maken een goeie zoek-optie rete irritant. Wederom moet je ipv 1 pagina, nu elke keer een frameset genereren die wer pagina's genreert etc.

target="zoekresultaten"

- Frames maken websites lastig onderhoudbaar. I.p.v. 1 template per pagina heb je nu tig pagina's nodig om tot 1 scherm te komen.

Daar hebben we CSS voor en/of serverside templates.. volgende stelling graag..

- Frames maken de back-button (de meest gebruikte optie in de browser) onbruikbaar.

Wel bruikbaar alleen niet erg consequent. Dit is niet bepaald een reden om Frames te verbannen.

- Frames worden niet goed weergegeven in Netscape, waardoor je beperkt bent in je layout.

Als je met Netscape werkt ben je helaas al beperkt in je layout Overigens gaat Netscape 6 er wel goed mee om. Dus zie ik dit niet meer als een probleem.

- Frames zorgen ervoor dat je Javascriptjes moet gaan gebruiken voor bijna ALLES. Als je je back-button weer wilt laten werken, voor resize dingen (Netscape), voor frame-generatie (Netscape), plaatjes laten switchen tussen frames, meerdere frames verversen (zie ook punt 1). etc etc.. ramp dus en strop op de productiekosten.

Dit is gewoon luiheid. Bedrijven die zich zorgen maken om productiekosten moeten meer gaan documenteren, en snel herbruikbare scripting archiveren.

- Frames zorgen voor minder reloads en dus minder inkomsten in geval van banners. Tenzij je de banners net als je scrollbalken midden in je page wilt zetten natuurlijk. Frames zijn daardoor voor portals/commerciele sites sowieso al taboe.

Er zijn genoeg andere manieren behalve tables om dit op te vangen, ik vindt dit een slap argument.

- Scrollbalken midden in je site-ontwerp zijn lelijk en onnatuurlijk (wat? frames zijn goed voor usability?? welke opleiding heb jij gevolgd??)

Dat zijn persoonlijke meningen. Scrollbars in het hart van je content zijn dikwijls nodig bij bepaalde applicaties. Ga je ook nog vallen over de scrollbar van de select

Scrollbars zijn zowiezo onnatuurlijk, ze worden door je browser gegenereerd en hebben geen groeiprocess

Zal er nog wel een zooi vergeten zijn, maar goed..

komt u maar

Frames hebben heel af en toe nut (bijvoorbeeld als je een enorme lijst items hebt, bijvoorbeeld images ofzo), maar vaak is het te voorkomen.

Waarom voorkomen, frames zijn prachtig om te gebruiken.

[Bosmonster]

lol, wat een bullshit. Heb je wel eens grote portal-sites gezien met frames? Die overwegingen zjin niet zomaar genomen, die zijn genomen na bovenstaande 'slappe' argumenten Als er geld te verdienen was met een frame-layout met banners bijvoorbeeld dan had misschien een ENKEL groot bedrijf ervoor gekozen, helaas... niemand die je stelling daar durft verdedigen.

En tuurlijk kun je minder 'lui' zijn en alles met frames oplossen. En vervolgens alle problemen met frames weer met half-werkende Javascriptjes op gaan lossen. Dit heeft niets met een goeie bibliotheek te maken, dit is domweg problemen veroorzaken en vervolgens weer oplossen. Ik spreek ook niet iemand na, maar uit eigen ervaring.

Frames zijn hopeloos verouderd en ooit ontstaan uit de wens een index te kunnen hebben en rechts je text, aangezien het internet vroeger niets ander was dan dit. De toekomst is echter (en ga nu niet alles tegenspreken) Flash en DHTML. Mogelijk is er wel on the fly content op te halen in de iframe, wat een goede vinding is, maar nog niet helemaal bruikbaar.

Wat bedoel je met die includes trouwens? Wat heeft back-end hier met server-connecties te maken? Een include is het inlezen van een filetje op de server door een applicatie op de server zelf. Das like 0,1% de 'load' van een nieuwe HTTP-serverconnectie die je browser nodig heeft om een document in een frame op te halen (waar vervolgens WEER DB-connecties voor moeten worden gemaakt etc)!

Frames... das pas luiheid.

Moest laatst nog lachen om een site die we notabene zelf gemaakt hadden, vroeger, in ons frames-tijdperk. We moesten hem gaan onderhouden.. Maar jah.. hoe he?

Grofweg telde de site bijna 150 pagina's, allemaal losse frames etc. En dan heb ik het dus nog niet eens over een DB-generated site. Voor de site waren allereerst scripts gebruikt die de frameset goed zetten voor Netscape4 (die dus nog 10x meer gebruikt wordt dan NS6). Vervolgens wilden ze bij de klant wel dat de titel van ieder scherm ergens ander kwam te staan. Hier was niks meer aan te doen, anders moesten we de volledige frameset dus opnieuw ontwerpen.. lang leve de flexibiliteit.. Zonder frames was het 5 minuten werk geweest en de klant tevreden.

Er moest een plaatje in een ander frame aangepast worden dus, bij het inladen van een nieuw frame, bovendien moesten er ook nog meerdere frames tegelijk ververst worden. Daarbij moest het menu zich nog aanpassen aan de content waar je was. Maar niet alleen bij menukliks zelf, maar ook bij inline kliks die de klant zelf erin kon zetten. Onmogelijk dus... En een enorme berg javascripts overal, voor de meest simpele dingen.

Dit is een van die scenario's die ons heeft doen besloten nooit meer frames te gebruiken... Een scenario wat jullie nog mee moeten maken blijkbaar.

[Dennis]

Op dinsdag 17 juli 2001 11:53 schreef Gordijnstok het volgende:
Ok stelling:

Ik heb eem frameset met 3 pagina's, waaronder navigatie.html, content.html, nogiets.html.

Als ik in de content klik, ga ik naar een andere pagina toe, zonder dat de andere 2 frames herladen

Met tables ga ik telkens de 3 bestanden in 1 bestand includen.. Voila, daar gaat je load.

Oftewel, frames = minder load.

Ja, hier heb je 100% gelijk, die opmerking van Bosmonster was precies verkeerd om.

Is niets anders als luiheid. Wat is het verschil tussen 3 templates telkens includen of framepje.location.replace te doen.

Juist: Dat je de templates dus altijd included, en dat is met frames niet nodig.

FOUT!!! Als jij een super dynamische site hebt (zoals tweakers, die linker bar op de FP wordt elke seconde wel weer anders omdat er zoveel verandert in de database) en je gebruikt een leftframe met DB content, dan zou je die steeds moeten refreshen om even actueel te blijven als een NIET-frames pagina. En nu niet gaan zeggen dat je dat dan maar moet doen, dat refreshen, want dan zit je weer met de back-knop problemen (zie verderop)

target="zoekresultaten"

Mwah, je hebt wel gelijk

Daar hebben we CSS voor en/of serverside templates.. volgende stelling graag..

CSS en/of serversides templates zijn beperkter, bovendien moet je bedenken dat je dat OOK krijgt als je géén frames gebruikt.

Wel bruikbaar alleen niet erg consequent. Dit is niet bepaald een reden om Frames te verbannen.

Dus wel. Neem bijvoorbeeld de site van informatique. Dit is een webshop die werkt met frames. Alleen elke keer als jij in het shop gedeelte een link aanklikt, wordt met een JS-scriptje het bovenste frame ook veranderd. Als je dus 1 pagina terug wilt, moet je dus 2x op vorige klikken. Ook al ga je hier niet dood van: het is slordig!

Als je met Netscape werkt ben je helaas al beperkt in je layout Overigens gaat Netscape 6 er wel goed mee om. Dus zie ik dit niet meer als een probleem.

Eens

Dit is gewoon luiheid. Bedrijven die zich zorgen maken om productiekosten moeten meer gaan documenteren, en snel herbruikbare scripting archiveren.

Ook in dit geval is het zo dat de ander wel een punt heeft, hoe meer javascriptjes jij op meerdere pages moet includen, hoe langzamer het wordt. Ook al cache je nog zoveel, 3x 1 zin is toch meer load dan 1x 1 zin.

Bovendien, veel bedrijven vinden kosten nog steeds belangrijk (logisch uiteraard).

Er zijn genoeg andere manieren behalve tables om dit op te vangen, ik vindt dit een slap argument.

Ook al vind jij dat, het is wel waar.

Dat zijn persoonlijke meningen. Scrollbars in het hart van je content zijn dikwijls nodig bij bepaalde applicaties. Ga je ook nog vallen over de scrollbar van de select

Scrollbars zijn zowiezo onnatuurlijk, ze worden door je browser gegenereerd en hebben geen groeiprocess

Als veel mensen die persoonlijke mening hebben. Internet == massamedia...

komt u maar

Bij deze

Waarom voorkomen, frames zijn prachtig om te gebruiken.

En toch houd ik niet van frames

[Verwijderd]

Op dinsdag 17 juli 2001 12:11 schreef Bosmonster het volgende:
lol, wat een bullshit. Heb je wel eens grote portal-sites gezien met frames? Die overwegingen zjin niet zomaar genomen, die zijn genomen na bovenstaande 'slappe' argumenten Als er geld te verdienen was met een frame-layout met banners bijvoorbeeld dan had misschien een ENKEL groot bedrijf ervoor gekozen, helaas... niemand die je stelling daar durft verdedigen.

Wat betreft banners, de banners staan ondanks wat vele denken ook gewoon in je cache De meeste sites gebruiken ivm snelheid nog steeds geen cachetags wat resulteerd in dat de hits qua banners die bij doubleclick worden opgehaald gewoon hetzelfde blijft

Dat zou overigens wel erg tof zijn. Maak ik een scriptje dat mijn pagina met mijn banner erin, gewoon 50x reload.. $$$$ Want dat gebeurt er plat gezegd.

En tuurlijk kun je minder 'lui' zijn en alles met frames oplossen. En vervolgens alle problemen met frames weer met half-werkende Javascriptjes op gaan lossen. Dit heeft niets met een goeie bibliotheek te maken, dit is domweg problemen veroorzaken en vervolgens weer oplossen. Ik spreek ook niet iemand na, maar uit eigen ervaring.

Iemand die hier dagelijks mee werkt heeft geen moeite met dit soort zaken Je weet vantevoren wat je kunt verwachten, en dara kun je gewoon op anticiperen.

Frames zijn hopeloos verouderd en ooit ontstaan uit de wens een index te kunnen hebben en rechts je text, aangezien het internet vroeger niets ander was dan dit. De toekomst is echter (en ga nu niet alles tegenspreken) Flash en DHTML.

Frames zijn inderdaad oud, maar dwnz dat ze daarom slecht zijn, of slechter als tables.

Bovendien, niemand weet wat de toekomst brengt. Het kan best zijn dat Flash over 2 jaar history is door een moderne vernieuwende techniek.

Mogelijk is er wel on the fly content op te halen in de iframe, wat een goede vinding is, maar nog niet helemaal bruikbaar.

Is een geweldige uitvinding. Maarja, je houdt niet van scrollbars.

Wat bedoel je met die includes trouwens? Wat heeft back-end hier met server-connecties te maken? Een include is het inlezen van een filetje op de server door een applicatie op de server zelf. Das like 0,1% de 'load' van een nieuwe HTTP-serverconnectie die je browser nodig heeft om een document in een frame op te halen (waar vervolgens WEER DB-connecties voor moeten worden gemaakt etc)!

Frames... das pas luiheid.

Die includes voer je altijd uit. Een request voor een Frame niet. Dat betekent dat in verhouding je met Frames veel minder load hebt.

[Bosmonster]

Ja, hier heb je 100% gelijk, die opmerking van Bosmonster was precies verkeerd om.

Wel eens een pagina met frames zien opbouwen en een pagina zonder frames? Wat is er dan sneller? Precies.. De server-connecties zorgen voor 'load'. Een site als T.NET/GoT is retesnel, omdat het maar 1 connectie nodig heeft en direct aan het werk kan.

[Verwijderd]

Op dinsdag 17 juli 2001 12:24 schreef Bosmonster het volgende:

[..]

Wel eens een pagina met frames zien opbouwen en een pagina zonder frames? Wat is er dan sneller? Precies.. De server-connecties zorgen voor 'load'. Een site als T.NET/GoT is retesnel, omdat het maar 1 connectie nodig heeft en direct aan het werk kan.

Je laad maar 1x de frameset

[Bosmonster]

Iemand die hier dagelijks mee werkt heeft geen moeite met dit soort zaken Je weet vantevoren wat je kunt verwachten, en dara kun je gewoon op anticiperen.

Precies.. Nu snap je hem. Geen frames dus.

[Bosmonster]

Je laad maar 1x de frameset

huh? 1x? Maar dan krijg je een nogal statische site zonder enige interactie in menu/etc!

Misschien kun je het beter bij programmeren houden en een interactiondesigner de pagina laten ontwerpen?

[Bosmonster]

Dat zou overigens wel erg tof zijn. Maak ik een scriptje dat mijn pagina met mijn banner erin, gewoon 50x reload.. $$$$ Want dat gebeurt er plat gezegd.

Uhh als techie moet je toch weten dat dupes deruit gefilterd worden. En er meestal alleen betaald wordt per klik? En dat dit soort bijzonderheden best genegeerd kunnen worden als het gaat om 1.000.000 pageviews per dag?

[Dennis]

Op dinsdag 17 juli 2001 12:32 schreef Bosmonster het volgende:
Uhh als techie moet je toch weten dat dupes deruit gefilterd worden. En er meestal alleen betaald wordt per klik? En dat dit soort bijzonderheden best genegeerd kunnen worden als het gaat om 1.000.000 pageviews per dag?

Het is tegenwoordig niet meer per klik maar per CPM. Cents per mille (centen per 1000 views dus).

[RM-rf]

Op dinsdag 17 juli 2001 12:11 schreef Bosmonster het volgende:
lol, wat een bullshit. Heb je wel eens grote portal-sites gezien met frames?

http://msdn.microsoft.com/
en moet zeggen dat het daar goed en bewust is toegepast

Frames zijn hopeloos verouderd en ooit ontstaan uit de wens een index te kunnen hebben en rechts je text, aangezien het internet vroeger niets ander was dan dit. De toekomst is echter (en ga nu niet alles tegenspreken) Flash en DHTML. Mogelijk is er wel on the fly content op te halen in de iframe, wat een goede vinding is, maar nog niet helemaal bruikbaar.

pffrt , nee begin jij asjeblieft er niet over dat het internet nu niet meer bdedoeld is om overzichtelijk informatie op te vragen, maar dat alles nu DHTML en Flash moet zijn ...

frames is een techniek en iedere techniek heeft zo zn voordelen alswel nadelen binnen een toepassing.

zaak is m te kijken welke winst je ermee boekt en welk nadeel dat kan hebben binnen het geheel.
frames is één methode om tot een simpele overzichtelijke navigatie te komen, natuurlijk zijn er meerdere.

de keuze om een bepaalde techniek toe te passen kan je enkel doen als je weet wàt je er nu eigenlijk mee gaat doen, bekijk eerst de data-structuur, denk na over de routing van je bezoekers over de site.
mn eerder gegeven voorbeeld van een mail-agent als outlook en de msdn-site kent dudielijke overeenkomsten qua structuuur van de data
links een uitgebreid contextueel menu, rechts korte brokken informatie, nooit verder scrollend dan twee ã drie volle pagina-hoogtes.

als je daarentegen tweakers.net neemt dan is dat bewust een pagina zonder frames, aangezien de pagina's ellenlang zijn en ook de informatie links constant wordt aangepast.

vanuit zulke uitgangspunten kun je voor iedere data-structuur afwegen waarom je wel of niet frames moet gebruiken, dar bestaat geen vaste waarheid voor.

[terzijde]en over de IFRAME, waarom is die nu opeens zo fantastisch, persoonlijk vind ik de ILAYER dan eigenlijk prettiger, kon ook SRC aan, overflow was gewoon uit te zetten en direct aan te spreken vanuit pagina, om al niet te spreken over het ide dat ik heb dat het zelfs voor ms een 'work in progress' is volop bugs en veranderingen in de implementatie in toekomstige browsers.

vreemd dat al die types die document.layers verketteren (hoor ik ook bij) de IFRAME wel fantastisch vinden

[Verwijderd]

Op dinsdag 17 juli 2001 12:27 schreef Bosmonster het volgende:

[..]

Precies.. Nu snap je hem. Geen frames dus.

Nee, frames gebruiken en weten hoe je ermee om moet gaan. Ipv tables gebruiken omdat frames te moeilijk zijn.

huh? 1x? Maar dan krijg je een nogal statische site zonder enige interactie in menu/etc!

Even meedenken svp.

Misschien kun je het beter bij programmeren houden en een interactiondesigner de pagina laten ontwerpen?

Ik beschouw dat maar als een troll, en reageer verder niet op zulke onnozele opmerkingen.

[Verwijderd]

een frame van 1 pixel breed om gewoon je index.html te kunnen openen (iets anders pikt die kl*teserver niet), verder alles met tables... ik haat navigatie die op een plek blijft staan, terwijl de rest van je pagina scrollt... en die halve scrollbars:

[Verwijderd]

Frames is ook altijd goed voor de centralisering. Dat is waarom ik het vroeger altijd gebruikte. Gebruikte je namelijk geen frames, maar een soort van index tabel op elke pagina, en je voegde een nieuwe pagina aan je site toe, moest je dat op iedere pagina veranderen.

Tegenwoordig pleur je alles in een databeest en blaat je wat php. Dan op iedere pagina include(header.inc) en je centraliseringsproblemen zijn ook weer opgelost.

Frames is makkelijk, maar niet meer nodig...

[Pelle]

Aaaargh... heb je een keertje een vrije dag en slaap je uit tot 1 uur, komt er weer een leuk topic voorbij waarin de meeste argumenten al voorbij zijn gekomen

Nah, ik zal 't voor mezelf ook nog even proberen te verwoorden:

Frames
voordelen
• Bij een navigatie die niet (of nauwelijks) aan verandering onderhevig is, is het, zoals OzBoz ook al zei, vanuit usability-oogpunt erg goed om je navigatie altijd in beeld te hebben. Het zorgt voor een eenduidig beeld in je hele site, en zal altijd als dusdanig herkend worden.
Tuurlijk, er zijn zat sites zonder frames waar de kleurstellingen en stijlkenmerken zo ver zijn doorgevoerd dat dat ook altijd duidelijk is, maar ik vind het echt geen schande om je logo altijd boven in beeld te hebben.
Bij een site waarvan je je navigatie niet meer in één frame gepropt krijgt, is het natuurlijk heel makkelijk om subnavigatie te gaan gebruiken, waar je ook een apart frame voor inruimt. Je kan er natuurlijk ook voor kiezen om de subnav in je contentframe op te nemen, een soort tussenoplossing dus.

nadelen
• Bij gebruik maken van frames, en zeker van geneste framesets, kan het soms lastig zijn om het overzicht te bewaren en je links naar het goeie target sturen. Een beetje webdesigner heeft daar geen moeite mee, maar het blijft een feit dat target="_top" makkelijker is dan een target="content" waar je frameset.php?menu=blaat&submenu=blaatsub&content=tekst in moet gooien.
Het gebruik van javascript komt hier inderdaad ook om de hoek kijken; zeker met geneste framesets gaan IE en NS anders om met frame-aanroepingen. Heb je daar geen ervaring mee, dan is het best lastig om daar wat bruikbaars uit te krijgen.

• Netscape doet wat raar met framesets. Pixels worden eerst omrekend naar percentages, en daarna worden je frames pas gerenderd. Beetje jammer, maar het is niet anders. Dit beperkt je enigszins in het bouwen van een frameset, want je kan een kromming of gradient zo moeilijk over 2 frames verdelen.
Persoonlijk houd ik er in mijn ontwerpen ten alle tijden rekening mee, en mijn framesets zien er zowel in NS als in IE dus hetzelfde uit. Mocht je nou zelf geen designer zijn, maar een ontwerp aangeleverd krijgen, dan is er met een beetje gezond verstand toch nog een cross-browser frameset van te bouwen, en lukt het echt niet dan heb je een goed argument om het design wat aan te passen.
Je kan dus niet alles, maar een goeie webdesigner kan wel veel (en dat is imho genoeg).

Tables/layers
voordelen
• Je kunt je pagina designtechnisch zo moeilijk maken als je zelf wilt. Alles kan.
• Je hoeft geen rekening meer te houden met frameborders, waar je je layers niet overheen kunt gooien. Met name voor navigatie is dat erg handig, je kunt gewoon lekker zonder zorgen een DHTML-menutje in elkaar draaien.
• Heb je veel dynamische content, dan zijn layers of tables ook veel makkelijker. Je hebt 1 document, waar je steeds wat verschillende zaken in kan includen. (Sub)navigatie, content, nieuws, header, etc.
• Je hoeft je nooit ongerust te maken dat iets niet in een frame past. Een navigatie-frame met een scrollbar is imho niet mooi, en daar heb je met tables geen last van.

nadelen
• Hoge serverload. Elke keer dat je een pagina binnen trekt, haal je meteen je navigatie en andere vaste dingen in je ontwerp binnen. In plaats van 20k voor content, haal je nu ook elke keer (bij een enigszins volwassen site) 50k aan andere HTML-meuk binnen, die je met frames anders maar één keer binnen had hoeven te halen.
• Bij gebruik van tables en grote pagina's moeten de bezoekers onnodig lang wachten tot je site binnen is. Met een breedband-verbinding is dat natuurlijk geen probleem, maar als je een pagina hebt van 70k en dat ben je met je 33k6 aan het binnenhalen, dan zul je toch echt moeten wachten tot de laatste </table> binnen is voor er iets gerenderd wordt. En dat zuigt.
• Je navigatie & logo verdwijnen bij te ver scrollen uit beeld. En dat is dus niet fijn, want dan moeten mensen meer moeite doen om weer bij een menu terecht te komen.
Ja, ik weet het, je kan van die irritante geocities-like meescrollende layers bouwen, maar dat kom je design vrijwel nooit ten goede. Moet je zoiets trouwens eens proberen op een P120 ofzo... echt zo traag als de neten...
• 'Alle grote sites werken ook niet met frames' is echt een kutexcuus. Je hebt toch zelf hersens? Nou dan, dan kan je ook zelf wel nadenken of frames handig zijn of niet.

Pffff er zijn nog veel meer voor- en nadelen te bedenken, maar daar waag ik me nu even niet meer aan

Frames kunnen handig zijn, tables/layers kunnen handig zijn. Het hangt helemaal af van je specifieke situatie.
Hoe dynamisch moet je navigatie zijn? Uit hoeveel onderdelen moet de bezoeker in een menu kunnen kiezen? Wil je submenu's gebruiken? Gaat het ontwerp van je site boven usability? Wil je cross-browser bezig zijn? Heb je richtlijnen van download-tijden voor 1 pagina? Hoe prominent moet duidelijk zijn dat het om jouw site gaat? Hoe moeilijk/makkelijk wil je het jezelf maken? Etcetera, etcetera, etcetera

Ik denk dat een goeie, ervaren webdesigner al na akkoordering van de offerte of opdrachtbevestiging al een goeie indicatie heeft op wat voor manier de site opgebouwd moet worden.
Het heeft zoals gezegd allebei z'n voors en tegens, en het ene is niet beter dan het andere omdat het gewoon situatie-afhankelijk is. En een goeie webdesigner moet dus een afweging kunnen maken van de voor- en nadelen van beide manieren, en op grond daarvan een beslissing kunnen nemen over de definitieve structuur.

[Verwijderd]

Ik gebruik wel frames..
Gewoon omdat de naviagtie dan een stuk duidelijker is.

Betreft die nadelen kun je er meestal wel wat op verzinnen..
Ik vind het trouwens een beetje een newbie hype;
Wooh tables roeleren en frames zuigen...

[Pelle]

Op dinsdag 17 juli 2001 14:15 schreef Tizzwat het volgende:
Betreft die nadelen kun je er meestal wel wat op verzinnen..
Ik vind het trouwens een beetje een newbie hype;
Wooh tables roeleren en frames zuigen...

Ik vind dit persoonlijk geen newbie-hype hoor... en ik hoor hier ook niet iedereen roepen dat tables roeleren en frames zuigen, of andersom.
Zoals gezegd: allebei heeft voor- en nadelen, en het hangt van de site en het inzicht van de webdesigner af wat het uiteindelijk gaat worden.

[Verwijderd]

Op dinsdag 17 juli 2001 14:19 schreef Pelle het volgende:

[..]

Ik vind dit persoonlijk geen newbie-hype hoor... en ik hoor hier ook niet newbie's !! iedereen roepen dat tables roeleren en frames zuigen, of andersom.

Let maar op...

[Verwijderd]

Op dinsdag 17 juli 2001 12:41 schreef Gordijnstok het volgende:
Ik beschouw dat maar als een troll, en reageer verder niet op zulke onnozele opmerkingen.

idd niet erg kewl, kom op Bosmonster je kan beter dan zulke opmerkingen!! Hier schiet je geen moer mee op.

[OzBoz]

Hierbij het dringende verzoek aan Bosmonster aan de rem te trekken. Ongenuanceerde uitspraken/trolls e.d. daar zitten we hier niet op te wachten.

[Bosmonster]

Sorry liet me even gaan gister..

Ik moet niet meedoen aan frames-discussies, ook al laaien ze elke zoveel weken weer op... Maar kan het niet laten

[Verwijderd]

Op woensdag 18 juli 2001 09:36 schreef Bosmonster het volgende:
Sorry liet me even gaan gister..

Ik moet niet meedoen aan frames-discussies, ook al laaien ze elke zoveel weken weer op... Maar kan het niet laten

Ik vergeef je

[drm]

[spreekwoordelijk]
Ik vind een appel mooier dan een peer, want de appel heeft namelijk het voordeel dat'ie rond is, en de peer is daarvoor veel te zoet.
[/spreekwoordelijk]

[Verwijderd]

[nightmare]
Je zit 's nachts in een bos.
Je bier is op.
Je pakt je laptop.
Je logt in op GoT.
Je begint te discuseren over frames.
Jij bent voor frames.
2 Seconden later wordt je opgegeten.
Door het Bosmonster.
Het laatste wat je ziet zijn frames van je leven.
Bosmonster vreet je frames op.
Je leven wordt in 1 HTML pagina geparsed.
Je scrollt je suf in je voorbijvliegende leven.
Je redt het niet.
Frameless you end.....
[/nightmare]

Yikes!!!!!!!!!!!!!!!!! Oef, weer wakker...

PS. Ik mis eigenlijk een "schrik" smiley.

[Verwijderd]

Gelukkig vind ik frames en tables beide wel ok..
Blijft het bosmonster bij mij uit de buurt

[Verwijderd]

LOL aleph

ik vond frames altijd sucken, maar dat was meer meeloperij denk ik, want eigenlijk zie ik de nadelen niet echt meer

mooie site met frames trouwens: www.k10k.net

[cutter]

eeejjj, doe's niet schoppen...