Webapplicaties met frames

[rogierslag]

Al enkele jaren ontwikkel ik websites en dergelijke. Altijd heb ik me verre van frames gehouden door de redenen die jullie allemaal vast welbekend zijn. Voor diegenen die het niet kennen:

• Slecht indexeerbaar
• Onmogelijk te bookmarken
• etc, etc, etc

Echter ga ik nu een webapplicatie ontwikkelen voor een bedrijf. Hun personeel werkt enkele uren per dag in het systeem. En dit keer wil ik wél de navigatie ed altijd in beeld houden wegens de gebruiksvriendelijkheid. Indexeerhaarheid van zoekmachines is ongewenst, net als bookmarken van pagina's. Nog wat andere eisen erbij en de nadelen van frames zijn zo'n beetje verdwenen.

Nou zit ik met het dilemma. Is het in zo'n geval goed om toch frames te gebruiken?

[ieperlingetje]

Navigatie in beeld houden is niet de reden waarvoor je frames wil gebruiken.

[Makkelijk]

Je kunt toch vrij makkelijk hetzelfde bereiken met CSS, waarom zou je frames gebruiken?

[Verwijderd]

Dit is een situatie waarin je inderdaad prima gebruik kunt maken van frames.
Je hebt het zelf al aardig opgesomd.

[frickY]

Inderdaad, geen enkele reden om het niet te doen.

[Makkelijk]

frickY schreef op zondag 08 mei 2011 @ 11:07:
Inderdaad, geen enkele reden om het niet te doen.

Maar ook niet echt een reden om het wel te doen.
Het maakt dus eigenlijk niet uit wat hij doet

[Onbekend]

Ik zou geen frames gebruiken en in HTML5 wordt dat trouwens officieel niet meer ondersteunt.
Gewoon CSS gebruiken en i.p.v. frames gewoon <div> gebruiken. Je zou evt. met Ajax het dataverkeer verlagen.

[Verwijderd]

Onbekend schreef op zondag 08 mei 2011 @ 11:09:
Ik zou geen frames gebruiken en in HTML5 wordt dat trouwens officieel niet meer ondersteunt.
Gewoon CSS gebruiken en i.p.v. frames gewoon <div> gebruiken. Je zou evt. met Ajax het dataverkeer verlagen.

Ik zou gewoon naar de wensen en eisen kijken en dan bepalen wat de makkelijkste oplossing is. Ik snap niet wat HTML5, CSS en Ajax daar direct mee te maken hebben. Ook met frames gebruik je CSS en kun je Ajax of vergelijkbare technieken gebruiken. Het een sluit het ander niet uit.

[IStealYourGun]

Binnen en intranet is het niet ongebruikelijk dat er eens frames gebruikt worden, maar je ziet die trend toch ook verdwijnen en er word eerder gekozen voor een combinatie van MVC en AJAX.

Vooral dat laatste is interessant als je met interactieve navigatie werkt zoals een tree.
Je moet de kosten baten afwegen. MVC/AJAX kost meer (in tijd en dus geld), maar eenmaal opgezet is het uitbreidbaar en onderhoudsvriendelijker. Voor kleine applicaties is het echter al minder interessant.

[Onbekend]

Verwijderd schreef op zondag 08 mei 2011 @ 11:13:
Ik zou gewoon naar de wensen en eisen kijken en dan bepalen wat de makkelijkste oplossing is.

Je kan natuurlijk de inhoud en argumenten mijn reactie volledig negeren, maar technieken van ruim 10 jaar oud die in de nieuwe standaarden niet meer worden ondersteund zou ik bij een nieuw project niet gaan gebruiken.

[frickY]

Makkelijk schreef op zondag 08 mei 2011 @ 11:08:
Maar ook niet echt een reden om het wel te doen.
Het maakt dus eigenlijk niet uit wat hij doet

Dat ligt maar net aan het ontwerp van de GUI.
Alles wat je met frames kunt kun je ook met ajax, maar dat is niet altijd even eenvoudig.

Als de redenen om geen framesets of iframes te gebruiken niet van toepassing zijn, dan kun je ze gewoon toepassen.

Onbekend schreef op zondag 08 mei 2011 @ 11:09:
Ik zou geen frames gebruiken en in HTML5 wordt dat trouwens officieel niet meer ondersteunt.

Onbekend schreef op zondag 08 mei 2011 @ 11:24:
Je kan natuurlijk de inhoud en argumenten mijn reactie volledig negeren, maar technieken van ruim 10 jaar oud die in de nieuwe standaarden niet meer worden ondersteund zou ik bij een nieuw project niet gaan gebruiken.

Een volledige frameset is inderdaad deprecated, en zou ik in geen geval hebben gebruikt. De <iframe> bestaat echter gewoon nog steeds (en is zelfs uitgebreid).

Frames are not supported in HTML 5 due to the usability issues that they have caused. Despite this, HTML 5 still allows the <iframe> tag.

[ Voor 34% gewijzigd door frickY op 08-05-2011 11:29 ]

[Ramon]

Nog steeds heb ik geen overtuigende reden gezien om frames te gebruiken. Als je navigatie altijd in beeld wil houden kan je deze gewoon dmv een herbruikbaar element op al je pagina's zetten en met css zorgen dat ze altijd in beeld staan, daar heb je geen frames voor nodig.

[Beatboxx]

Ik zie geen reden om geen frames te gebruiken, maar ook geen om het wel te doen..

[Gomez12]

Wat ik me eigenlijk afvraag, waarom zou je frames willen gebruiken?

Je zegt dat je er al jarenlang weg van bent gebleven, dus ik neem aan dat je beter bent in alle technieken die geen gebruik maken van frames.
Als je nu zou zeggen dat je altijd met frames hebt gewerkt dan zou het in dit geval niet erg zijn, maar als je bekender bent met de "nettere" technieken waarom die dan niet gebruiken?

Wat is de reden dat je af wilt wijken van je standaard werkmanier?

[RaZ]

Ramon schreef op zondag 08 mei 2011 @ 11:36:
Nog steeds heb ik geen overtuigende reden gezien om frames te gebruiken. Als je navigatie altijd in beeld wil houden kan je deze gewoon dmv een herbruikbaar element op al je pagina's zetten en met css zorgen dat ze altijd in beeld staan, daar heb je geen frames voor nodig.

Bij het gebruik van frames, heb je altijd maar 1 URL in de adresbalk, waardoor je enkel de homepage kan bookmarken. Zonder frames heb je dus wel altijd unieke URL's in de adresbalk, waardoor je wel alles appart kan bookmarken.

Dat is dus de voornaamste reden om hier voor frames te kiezen.

Of je moet alles met AJAX gaan doen, maar dan is het kiezen voor frames toch makkelijker.

Dat frames de usability vermindert, houd niet in dat dat juist hier een punt is wat men dus bewust voor kiest.

Dat vind ik toch een prima overtuigende reden om dan voor frames te gaan hoor.

Gomez12 schreef op zondag 08 mei 2011 @ 11:42:
[..]

Wat is de reden dat je af wilt wijken van je standaard werkmanier?

Omdat er gewoon om gevraagd wordt door de klant. Het kan natuurlijk wel met AJAX, maar waarom moeilijk doen als het makkelijk kan, waardoor de prijs voor de klant ook lager ligt (frames draai je sneller in elkaar dan AJAX).

[ Voor 40% gewijzigd door RaZ op 08-05-2011 11:47 ]

[Gomez12]

RaZ schreef op zondag 08 mei 2011 @ 11:44:
Bij het gebruik van frames, heb je altijd maar 1 URL in de adresbalk, waardoor je enkel de homepage kan bookmarken. Zonder frames heb je dus wel altijd unieke URL's in de adresbalk, waardoor je wel alles appart kan bookmarken.

Dat is dus de voornaamste reden om hier voor frames te kiezen.

Imho onzinreden.
Of je moet er echt voorzieningen voor gaan treffen, maar elke browser kan open link in new tab etc doen waardoor je je ene url al verliest.

Die ene url is een schoonheidsdingetje, geen beveiliging die ervoor zorgt dat men niet meer alles kan bookmarken.

Persoonlijk zou ik het juist voor een intern systeem juist niet in frames doen, ik vind het altijd hardstikke relaxed om even een paar verschillende tabbladen open te hebben staan met verschillende functionaliteiten (tabblad 1 voer ik een verkooporder in, tabblad 2 kijk ik naar de historie van de klant om te zien of ik nog wat extra korting kan weggeven) Dat soort dingen werkt wmb niet lekker als ik telkens als ik een nieuwe tab wil hebben helemaal vanaf scratch moet beginnen.
Met frames kan ik dit nog steeds doen (rechtermuisknop en open in new tab) enkel kan ik daarna voor de rest niets meer met die tabs doen.

Of je moet alles met AJAX gaan doen, maar dan is het kiezen voor frames toch makkelijker.

Dat vraag ik me toch echt ten zeerste af. Ik ga bij jarenlang geen frame-gebruik ervanuit dat je een eigen framework oid hebt waar dit al helemaal in geregeld is, in dat framework ben je bekender dan met frames opzich (ok, het is geen rocket science).
Voor mij zou het bijv makkelijker zijn om het zonder frames te doen dan met. Ik heb gewoon te lang niets meer met frames gedaan.

RaZ schreef op zondag 08 mei 2011 @ 11:44:
[...]
Omdat er gewoon om gevraagd wordt door de klant. Het kan natuurlijk wel met AJAX, maar waarom moeilijk doen als het makkelijk kan, waardoor de prijs voor de klant ook lager ligt (frames draai je sneller in elkaar dan AJAX).

Ik zie de klant helemaal nergens om vragen... De klant wil veelal enkel functionaliteit, techniek zal hem niet zoveel uitmaken.
En als je jarenlang om frames heen hebt gewerkt dan vraag ik me af of je met frames wel sneller bent.
Of je moet nog nooit een site met een vaste navigatie structuur oid hebben gemaakt, dan zou het kunnen dat frames sneller is dan iets heel nieuws in ajax bouwen.

[ Voor 16% gewijzigd door Gomez12 op 08-05-2011 12:04 ]

[RaZ]

Tuurlijk kan je links openen in een nieuw tabblad, of in een nieuw venster. Dat is een feature van de browser, net als bookmarken, waar je als websitebouwer totaal geen invloed op hebt.

Javascript kan uitgezet worden, waardoor AJAX gelijk faalt. Frames kan je niet uitzetten, en lijkt me een logische keuze. En gezien frames een ei'tje is om op te zetten, lijkt mij dat de meest voor de hand liggende keuze.

Ander optie is om het in Flash te maken, maar ook dat zal ongetwijfeld z'n nadelen hebben.

[Voutloos]

En waarom is het bookmarken van pagina's ongewenst? Ben je bang dat mensen in 1x met hun taak aan de slag kunnen?

Waarom is het ongewenst? Lijkt het je eenvoudiger als je altijd op een vast punt begint? Als je een vast beginpunt als aannname hebt, gaat je systeem geheid een keer goed op z'n bek als iemand een direct linkje ontdekt...

RaZ schreef op zondag 08 mei 2011 @ 12:05:
Frames kan je niet uitzetten, en lijkt me een logische keuze. En gezien frames een ei'tje is om op te zetten, lijkt mij dat de meest voor de hand liggende keuze.

Ander optie is om het in Flash te maken, maar ook dat zal ongetwijfeld z'n nadelen hebben.

Doe je altijd braaf wat je gevraagd wordt, zonder zelf na te denken of de vraag verkeerd is en/of het beter kan?

[Gomez12]

RaZ schreef op zondag 08 mei 2011 @ 12:05:
Tuurlijk kan je links openen in een nieuw tabblad, of in een nieuw venster. Dat is een feature van de browser, net als bookmarken, waar je als websitebouwer totaal geen invloed op hebt.

Javascript kan uitgezet worden, waardoor AJAX gelijk faalt. Frames kan je niet uitzetten, en lijkt me een logische keuze. En gezien frames een ei'tje is om op te zetten, lijkt mij dat de meest voor de hand liggende keuze.

We hebben het hier toch nog steeds over een interne webapp?
Daar kan je best wat requirements voor op tafel leggen hoor. Oftewel JS-support kan je gewoon eisen.

Ander optie is om het in Flash te maken, maar ook dat zal ongetwijfeld z'n nadelen hebben.

Heb jij inside kennis ofzo? Dat je weet wat de requirements zijn (niet kunnen bookmarken is er blijkbaar 1 volgens jou?)
Het enige wat ik lees is dat voor TS de nadelen van frames niet meer meetellen in dit specifieke geval, nergens lees ik dat er requirements zijn die bookmarken verbieden...
Tiedeldiedie, toedeldoedoe, ik zei niets

[Voutloos]

Dat bookmarken ongewenst is staat wel in de topicstart, opvallend genoeg direct na een opmerking over gebruiksvriendelijkheid.

[Makkelijk]

RaZ schreef op zondag 08 mei 2011 @ 11:44:
[...]
Of je moet alles met AJAX gaan doen, maar dan is het kiezen voor frames toch makkelijker.
[...]

Een stukje javascript wat alle links in het menu 'frame' uitvoert als ajax calls op het content 'frame' zal echt extreem eenvoudig zijn

[RaZ]

@Voutloos:
Tuurlijk moet je met je klant meedenken, en die adviseren. Maar als een 15 jaar oude techniek de meeste wensen eigenlijk wel dekt, dan volstaat dat toch gewoon.

@Gomez12: Er staat in de OP toch echt dat bookmarken onwenselijk is. Dus dan moet je zorgen dat de URL in de adresbalk niet verandert.

---

Goed, ik zou zelf niet snel een site in frames maken, maar gezien de wensen van de klant: Niet bookmarken, geen zoekmachines (je breekt dus ook nooit de site als je op een landingspagina komt), zie ik niet in waarom je niet voor frames zou kiezen.

De nadelen van frames is in deze situatie dus een pluspunt.

[Voutloos]

RaZ schreef op zondag 08 mei 2011 @ 12:32:
@Voutloos:
Tuurlijk moet je met je klant meedenken, en die adviseren. Maar als een 15 jaar oude techniek de meeste wensen eigenlijk wel dekt, dan volstaat dat toch gewoon.

Als je nooit opbouwende kritiek durft te uiten op een gekke wens degradeer je jezelf tot typkip. Klant heeft een idee, maar wij zijn de experts. En dan moet je er samen uit kunnen komen, maar zelf kies ik niet zonder overleg voor een slecht idee waar toevallig een implemntatie voor bestaat die 'volstaat'.

De nadelen van frames is in deze situatie dus een pluspunt.

Het is maar net hoe je op frames uitkomt. Zoals het in de topicstart staat, komt het bij mij over als dat de ts gewoon frames wilt gebruiken en dan toevallig maar de nadelen goed praat. Prima hoor, maar laat dit topic dan maar achterwege.
[/mijn mogelijk te cynische visie]

[ieperlingetje]

Voor de TS is frames niet de goede keuze, omdat hij met zijn frames het volgende wil bereiken:

En dit keer wil ik wél de navigatie ed altijd in beeld houden wegens de gebruiksvriendelijkheid.

Als je een element in beeld wil houden is dat nog geen reden om frames te gebruiken

[RaZ]

@Voutloos: Je moet natuurlijk wel je zegje kunnen doen. De klant wil een eindproduct. Dus moet je dan opzoek naar de juiste tool voor de job. Als dat met frames kan, prima toch. Kan het niet, dan valt het eigenlijk gewoon af.

Je hebt natuurlijk ook de onderscheid of je een site maakt als paradepaardje, het online visitekaartje van je bedrijf, of een interne site waarbij functionaliteit het belangrijkste is.

Als het bookmarken echt een harde eis, en geen pre, dan valt frames natuurlijk af, gezien de rechtermuisknop die alle browsers hebben.

Maar om direct frames in het verdomhoekje te schuiven als not-done, ben ik het niet mee eens.

[Boelie-Boelie]

Eigenlijk zou je moeten weten waarom dat bookmarken ongewenst is.. Wie weet is deze frames-discussie overbodig omdat er achter het non-bookmark-idee een gedachtegang zit die meer uit gewoonte voortkomt dan uit nut voor bedrijfsprocessen?

[Gomez12]

RaZ schreef op zondag 08 mei 2011 @ 13:46:
Maar om direct frames in het verdomhoekje te schuiven als not-done, ben ik het niet mee eens.

Waar ik nog steeds veel benieuwder naar ben is hoe frames uit het verdomhoekje vandaan zijn gekomen?

TS geeft aan dat hij jarenlang geen frames gebruikt (=in het verdomhoekje heeft zitten).
Dan ga ik ervanuit dat hij in zijn dagelijkse toolkit alles heeft zitten om frames te vervangen en die toolkit kent hij en gebruikt hij... Waarom dan opeens naar iets totaal anders grijpen? Waarvan het nut zwaar ter discussie staat.

[ID-College]

Ik zie even niet in waarom div's in combinatie met jQuery niet zou volstaan? Dit doet toch ook perfect aan de wensen van TS en is van de huidige tijd. De recente browsers ondersteunen dit..

[Juup]

Het lijkt wel een religieuze discussie zo.
Zullen we deze toevoegen aan het rijtje Vi vs. Emacs, Tabs vs. Spaties, Atheisme vs. Geloof X, PVV vs. GroenLinks etc?

[CH4OS]

Ik ben eerder benieuwd naar de onderbouwing van de klant: wáárom mag de (web)applicatie niet gebookmarked worden?

[Gomez12]

CptChaos schreef op maandag 09 mei 2011 @ 01:18:
Ik ben eerder benieuwd naar de onderbouwing van de klant: wáárom mag de (web)applicatie niet gebookmarked worden?

Ik vermoed dat niet een echte req is, enkel een reden om toch voor frames te kunnen gaan. Ik lees het dan ook meer als : Het is niet verplicht om bookmarks te kunnen maken.

Anders zou je het volgende ook als req moeten zien : Indexeerhaarheid van zoekmachines is ongewenst.
Lijkt me opzich wel speciaal, een pagina maken die zo slecht mogelijk indexeerbaar is.
Zou je nog specifiek de grote zoekmachines noemen, dan kan je het met een robots.txt redden. Maar zonder specificatie moet je ook rekening houden met degene die robots.txt negeren.
Je kan natuurlijk heel creatief worden en tussen alle letters onregelmatige garbage teksten zetten, dan met JS die garbage teksten een css klasse geven die normaal gesproken kan (h1 bijv) en dan in je css die h1 definieren als hidden text, technisch kan het.
Maar je kunt het ook gewoon lezen als dat het niet een req is dat het mogelijk is

[Bosmonster]

Ipv frames kun je eenvoudig position: fixed gebruiken en voor performance wat mixen met Ajax-technieken. Tegenwoordig heb je frames ook eigenlijk niet meer nodig, zelfs voor applicaties.

Frames zijn ook geen onderdeel meer van moderne html-specs (html5).

De enige echte reden die ik me zo kan bedenken om het toch te gebruiken, is kosten. Als je niet zoveel ervaring hebt met complexere (html5-)applicaties bouwen en bijhorende benodigde performance-optimalisaties (zowel server- als clientside), dan is het waarschijnlijk een stuk sneller om maar een paar frames te pakken.

Uiteindelijk is het dus meer een keuze die afhangt van je persoonlijke mogelijkheden en wat verder de wensen van de klant zijn mbt complexiteit.

[ Voor 11% gewijzigd door Bosmonster op 09-05-2011 08:40 ]

[Bramboos]

ieperlingetje schreef op zondag 08 mei 2011 @ 13:35:
Voor de TS is frames niet de goede keuze, omdat hij met zijn frames het volgende wil bereiken:
[...]
Als je een element in beeld wil houden is dat nog geen reden om frames te gebruiken

Om een voorbeeld te noemen: Twitter heeft ook de menubalk hele tijd in het beeld zonder gebruik te maken van frames.

Nou is Twitter wel heel iets anders dan een interne webapplicatie maar qua performance heeft Twitter wel een voorsprong.

[Verwijderd]

Je kan via een include het menu bouwen, deze elke pagina includen.

[Tarilo]

In zo'n beetje elke framework dat ik ken is het kinderspel om bijvoorbeeld hetzelfde menu te integreren in elke pagina. Even uitgaande van de meest gebruikte taal op het web(php), hebben frameworks zoals symfony een uitgebreide templating engine waarin zulke dingen kinderlijk eenvoudig zijn. Voor andere talen is dit precies hetzelfde.

Ik snap dan ook niet waarom continu over AJAX en andere technieken gepraat wordt om frames na te doen? Wat is er mis met gewoon telkens de hele pagina opnieuw laden? Het is niet dat een menu, zoveel dataverkeer met zich mee brengt.

Daarnaast zijn frames gewoon weggelaten uit de HTML5 spec, dus in principe kan je ze helemaal niet meer gebruiken.(hoewel browsers helaas nog een tijd ondersteuning zullen bieden) En een <iframe> is heel wat anders dan frames gebruiken voor het door de TS aangedragen doel.

[Cyphax]

Om de één of andere reden vermoed ik dat rogierslag het intussen wel voor elkaar heeft.

[RobIII]

Hoi en welkom op GoT joeribijl

Het is misschien handig om te weten dat 't uit de sloot trekken van oude koeien niet helemaal de bedoeling is hier. Die waarschuwing staat er dan ook niet voor niets

Let op! De laatste reactie in deze discussie is meer dan 2 weken oud!

[ Voor 26% gewijzigd door RobIII op 19-03-2013 11:06 ]