maledetti frames
john
sono nuovo qui e molto speranzoso di trovare risposte alle mie domande.
Comincio col dire che non sono un webmaster professionista, anche se
l'HTML lo mastico giá da oltre dieci anni. ma non sono mai andato oltre
le istruzioni elementari, cioé non mi sono mai 'evoluto' da seguire
lo 'state of the art'.
Io ho sempre usato i framesets, che mi sembravano il modo più comodo per
trattare una parte a sinistra coi links' alle varie pagine,
e l'altra parte, a destra, per i contenuti. La parte destra puo'
scrollarsi a vicenda, quella sinistra invece no.
Fino ad ieri tutto OK, fino a che improvvisamente il Google Chrome (il
mio browser standard perchè é molto veloce a caricare, e per me questo è
un importante punto a favore) comincia a dare in balle e a non farmi più
vedere il contenuto di destra come era specificato nel 'target', bensì
mi crea un tab nuovo.
Da notare che Chrome, Firefox e Internet Explorer 8 danno tutti una
schermata diversa.
Quella che sembra funzioni meglio (strano ma vero) è Internet Explorer.
Firefox invece mi dà gli scroll dappertutto, anche se è specificato
scroll="no".
Io ultimamente creo le mie pagine con Frontpage, perchè lo scrivere
unicamente l'HTML con Notepad, risultava essere troppo primitivo,
appunto per via dei CSS che non conosco, ancora oggi, troppo bene.
Cercando consigli qua e là, mi sono sentito dare sempre la stessa
risposta : abbandona i frames ! Assolutamente.
Io cercando qua e là in rete sono arrivato a vedere qualche alternativa :
- SSI (ma bisogna configurare il server apache che parsi' anche i files
html e questo non è in mio potere)
- javascript (non lo conosco)
- php (cioé dovrei cambiare l'estensione di tutte le mie pagine in .php
e usare l'include)
- IFRAMES
quest'ultima soluzione a me sembra che soffra delle stesse malattie
congenite dei FRAMES, perchè anche qui bisogna stare attento ai target e
ad altre cose. In più il codice dell'esempio era assolutamente complesso
e non-intuitivo, perchè c'erano molti riferimenti a pagine proprietarie
di cui si sapeva solo l'URL senza vedere cosa c'era scritto dentro.
Insomma mi ha scoraggiato.
In sostanza sono più depresso di prima e spero tanto che qualcuno mi
possa indicare una soluzione che sia :
a) facile abbstanza da poterla implementare anch'io, che non sono un
webmaster professionista
b) che non sia quella di 'scrollare' su e giù la pagina intera, come
sembra che sia 'lo stile moderno' di oggigiorno, e che io aborro
d) possibilmente restando nell'ambito dell' HTML
anche se dovrò impararmi a fondo gli style sheets
( a proposito ho letto che il tag 'OBJECT' non é supportato da tutti i
browsers, quindi c'è un problema)
e) se possibile senza usare javascript.
Insomma, esiste una soluzione SEMPLICE e supportata da quasi tutti i
browser per dividere lo schermo in due parti, una a destra ed una a
sinistra ed includerci due frames diverse, come si poteva fare coi
FRAMESET ?
Mi domando anche perchè tutti siano così contro i FRAMESET che sono così
comodi. Non era più logico insistere affinchè TUTTI i browsers accettino
'sti ka§§o di frameset, invece di obbligare il mondo intero a trovare
una alternativa ?
Evidentemente c'è qualcosa (molte cose anzi) che mi sfugge.
Grazie delle risposte.
John.
Alessandro Pellizzari
> b) che non sia quella di 'scrollare' su e giù la pagina intera, come
> sembra che sia 'lo stile moderno' di oggigiorno, e che io aborro
C'e` un motivo per cui e` cosi`, non e` semplice moda...
> Insomma, esiste una soluzione SEMPLICE e supportata da quasi tutti i
> browser per dividere lo schermo in due parti, una a destra ed una a
> sinistra ed includerci due frames diverse, come si poteva fare coi
> FRAMESET ?
I frameset.
Sono ancora supportati, ma deprecati.
Come mi pare ti abbiano gia` scritto, si tratta di un bug di Chrome.
> Mi domando anche perchè tutti siano così contro i FRAMESET che sono così
> comodi. Non era più logico insistere affinchè TUTTI i browsers accettino
> 'sti ka§§o di frameset, invece di obbligare il mondo intero a trovare
> una alternativa ?
I frame hanno diversi difetti, tra cui il piu` grosso e` la rottura della
biunivocita` url<->pagina.
Rompono il flusso di navigazione, rendendola caotica.
Sono brutti da vedere (non puoi usare i css per modificare lo stile delle
barre di divisione e di scorrimento)
Rendono difficile la vita ai programmatori lato server.
Sono difficili da gestire per siti medio-grandi (basta un target messo
male per sballare tutto il layout).
Piu` altre ed eventuali che ora non mi vengono in mente.
Insomma, se ti hanno detto tutti che i frame sono il male, non sono loro
contromano in autostrada. ;)
Bye.
john
> C'e` un motivo per cui e` cosi`, non e` semplice moda...
>
pensavo che la 'user friendliness' e non la 'webmaster friendliness'
fosse prioritaria.
Ma forse mi sbaglio.
Esiste un compromesso che faccia contenti sia gli utilizzatori e i
client-programmers (che devono farli contenti) che i webmasters ?
:-))
Io come user aborro le pagine che si devono scrollare interamente e
quando si deve andare a trovare un link bisogna sempre andare al top
della pagina.
Le considero un passo indietro nella web user-interface.
Leonardo Serni
>Io come user aborro le pagine che si devono scrollare interamente e
>quando si deve andare a trovare un link bisogna sempre andare al top
>della pagina.
>Le considero un passo indietro nella web user-interface.
Be', nessuno ti vieta di mettere due DIV affiancati, uno dei quali
con scrolling overflow. Dovrebbe fare lo stesso identico effetto -
almeno credo.
A quel punto l'unica differenza reale e' che il reload bisogna che
tu lo faccia con AJAX.
Leonardo
--
The thoughts of others were light and fleeting,
Of lovers' meeting, or luck, or fame.
Mine were of trouble, and mine were steady:
So I was ready when trouble came.
john
dovere di informare che ho trovato l'inghippo :
stavolta non è colpa del browser (Chrome) bensì di Frontpage, che
chissà per quale oscuro motivo, rieditando un file HTML ha 'cancellato'
nelll'hiperlink l'attributo 'target'.
Corretto il tutto a mano, è ritornato tutto come prima.
Grazie ancora per il feedback.
PS - Qualcuno puo' consigliare un prodotto migliore del Frontpage che
pur occupandosi dello styling, non genera centinaia di righe inutili (e
difficilmente leggibili) di codice HTML ??
l...@email.it
> Io come user aborro le pagine che si devono scrollare interamente e
> quando si deve andare a trovare un link bisogna sempre andare al top
> della pagina.
>
> Le considero un passo indietro nella web user-interface.
invece è un bene. in questo modo l'evoluzione seleziona solo gli
utenti più intelligenti e tenaci. gli altri muoiono e la razza
migliora.
l...@email.it
> PS - Qualcuno puo' consigliare un prodotto migliore del Frontpage che
> pur occupandosi dello styling, non genera centinaia di righe inutili (e
> difficilmente leggibili) di codice HTML ??
a parte dreamweaver, che costa 5-600 euro, non conosco altri editor
visuali, e dw di righe diciamo così inutili ne genera qualcuna.
una volta che hai smanettato un po' con i css la cosa più economica in
termini di righe scritte e più veloce quando occorre modificare
qualcosa è proprio scrivere tutto a mano.
se no uno può sempre fare un bel jpeg 1024x768 e modificarlo con
photoshop, quella è la cosa che davvero si fa prima.
john
>
>>
>> Le considero un passo indietro nella web user-interface.
>
> utenti piů intelligenti e tenaci. gli altri muoiono e la razza
> migliora.
...hai mai dovuto sviluppare per degli utenti tenaci ma ignoranti e
pigri, che sprizzano miliardi da tutti i pori, e che ti pagano qualsiasi
prezzo purchč gli dai *quello che vogliono loro* senza discutere ?
Sono quelli che danno lavoro a tutti noi.
(Per non parlare dei medici poi....)
l...@email.it
> l...@email.it schrieb:
>
>
>
> >> Le considero un passo indietro nella web user-interface.
>
> > utenti più intelligenti e tenaci. gli altri muoiono e la razza
> > migliora.
>
> ...hai mai dovuto sviluppare per degli utenti tenaci ma ignoranti e
> pigri, che sprizzano miliardi da tutti i pori, e che ti pagano qualsiasi
>
> Sono quelli che danno lavoro a tutti noi.
forse daranno lavoro a te, ti faccio i miei rallegramenti e se tu
fossi disposto a condividere il qualsiasi prezzo sarei anche contento
di essere coinvolto.
generalmente gli utenti tenaci ma ignoranti e pigri che conosco io
sono anche dei poveracci spilorci con i quali non conviene perdere
tempo, né con loro né con i loro capricci autoreferenziali e
solipsisti.
ngw
> Alessandro Pellizzari schrieb:
>
>> C'e` un motivo per cui e` cosi`, non e` semplice moda...
>>
>
> pensavo che la 'user friendliness' e non la 'webmaster friendliness'
> fosse prioritaria.
>
> Ma forse mi sbaglio.
>
> Esiste un compromesso che faccia contenti sia gli utilizzatori e i
> client-programmers (che devono farli contenti) che i webmasters ?
> :-))
Si, uscire dagli anni '90 e non usare i frame, che con la "user
friendliness" certamente c'entrano, essendo completamente inusabili.
http://www.useit.com/alertbox/9612.html
Parliamo appunto di 1996.
> Io come user aborro le pagine che si devono scrollare interamente e
> quando si deve andare a trovare un link bisogna sempre andare al top
> della pagina.
>
> Le considero un passo indietro nella web user-interface.
Tenteremo di sopravvivere ascoltando solo Nielsen e non un'occhiometro
a caso :-)
ngw
--
Nicholas Wieland (ngw)
Zooppa CTO
911 Western Avenue, Suite 420
Seattle, WA 98104 US
john
>
> forse daranno lavoro a te, ti faccio i miei rallegramenti e se tu
> fossi disposto a condividere il qualsiasi prezzo sarei anche contento
> di essere coinvolto.
>
...se vieni in Germania te li presento.. :-)
D.Campagna
> Salve,
>
> sono nuovo qui e molto speranzoso di trovare risposte alle mie domande.
>
> Comincio col dire che non sono un webmaster professionista, anche se
> l'HTML lo mastico giá da oltre dieci anni. ma non sono mai andato oltre
> le istruzioni elementari, cioé non mi sono mai 'evoluto' da seguire
> lo 'state of the art'.
> Io ho sempre usato i framesets, che mi sembravano il modo più comodo per
> trattare una parte a sinistra coi links' alle varie pagine,
> e l'altra parte, a destra, per i contenuti. La parte destra puo'
> scrollarsi a vicenda, quella sinistra invece no.
Caro john siamo almeno in due a prediligere le frames.
Ti dirò di più, io un sito senza frames lo faccio solo se espressamente
richiesto o se il cliente è un rompiglione e sospetto che mi possa
venire a dire "Eh! Ma lei mi ha usato le frames...".
Personalmente le trovo comodissime perché sono indipendenti e quindi
consentono:
a) di essere ricaricate in tempi brevi senza dover ricaricare tutta la
pagina, velocizzando la navigazione.
b) di isolare il menu dei comandi, il logo, l'intestazione ecc. che non
serve ricaricare ogni volta che si cambia il contenuto della pagina.
c) di fare dei giochetti con javascript, programmazione lato server ecc.
che neanche ci si può immaginare. Avevo 'inventato' una tecnica che mi
permetteva di scambiare dati col server con grandissima efficienza
(tramite una frame invisibile che usavo come buffer per i dati e un po'
di javascript), ma poi sono arrivati XMLHttpRequest e Ajax ecc. ecc. e
questo forse davvero è un po' superato.
>
> Da notare che Chrome, Firefox e Internet Explorer 8 danno tutti una
> schermata diversa.
Si, ciao, dovresti provare a programmare in javascript, allora lì si che
ti divertiresti per ottenere lo stesso effetto almeno sui 4-5 browser
'più diffusi'.
> Io ultimamente creo le mie pagine con Frontpage, perchè lo scrivere
> unicamente l'HTML con Notepad, risultava essere troppo primitivo,
> appunto per via dei CSS che non conosco, ancora oggi, troppo bene.
Credo che Frontpage sia un po' da dilettanti, ma sono rimasto alle
versioni paleolitiche per cui non sono sicuro. Prova a scaricarti
stylemaster (che io uso come un manuale di css), e ACEHtml (la versione
free), credo che siano un punto di partenza un po' più istruttivo.
> Cercando consigli qua e là, mi sono sentito dare sempre la stessa
> risposta : abbandona i frames ! Assolutamente.
Eh, come ti capisco!
>
> - IFRAMES
> quest'ultima soluzione a me sembra che soffra delle stesse malattie
> congenite dei FRAMES, perchè anche qui bisogna stare attento ai target e
> ad altre cose. In più il codice dell'esempio era assolutamente complesso
> e non-intuitivo, perchè c'erano molti riferimenti a pagine proprietarie
> di cui si sapeva solo l'URL senza vedere cosa c'era scritto dentro.
> Insomma mi ha scoraggiato.
Le Iframes sono ancora meno standard delle frames. Qualche mese fa sono
uscito pazzo per cercare di usarle in un mio sito di test ma ho dovuto
abbandonare perché Opera 9.24 le gestiva in modo fantasioso, mentre IE e
Firefox richiedevano diverse istruzioni per ottenere lo scopo che mi ero
prefisso... parlo sempre di javascript. Magari adesso la situazione è
migliorata.
>
> In sostanza sono più depresso di prima e spero tanto che qualcuno mi
> possa indicare una soluzione che sia :
>
> a) facile abbstanza da poterla implementare anch'io, che non sono un
> webmaster professionista
>
> b) che non sia quella di 'scrollare' su e giù la pagina intera, come
> sembra che sia 'lo stile moderno' di oggigiorno, e che io aborro
>
> d) possibilmente restando nell'ambito dell' HTML
> anche se dovrò impararmi a fondo gli style sheets
> ( a proposito ho letto che il tag 'OBJECT' non é supportato da tutti i
> browsers, quindi c'è un problema)
>
> e) se possibile senza usare javascript.
> Insomma, esiste una soluzione SEMPLICE e supportata da quasi tutti i
> browser per dividere lo schermo in due parti, una a destra ed una a
> sinistra ed includerci due frames diverse, come si poteva fare coi
> FRAMESET ?
Forse puoi usare i DIV, con CSS lo definisci a posizione assoluta e
bloccato sulla pagina come una frame... il resto della pagina scrolla ma
il DIV no.
> Mi domando anche perchè tutti siano così contro i FRAMESET che sono così
> comodi. Non era più logico insistere affinchè TUTTI i browsers accettino
> 'sti ka§§o di frameset, invece di obbligare il mondo intero a trovare
> una alternativa ?
>
> Evidentemente c'è qualcosa (molte cose anzi) che mi sfugge.
Ma perché non aspetti che correggano il bug di Chrome e intanto usi
Opera o Firefox? Di bug si tratta, no? Anzi lo stesso bug c'era su una
vecchia versione di Opera (forse 8.54). Le frames per ora sono
supportate. Se il sito è progettato con attenzione e non dovrebbero dare
problemi...
Comunque tienici informati...
Dan
john
>
> Si, uscire dagli anni '90 e non usare i frame, che con la "user
> friendliness" certamente c'entrano, essendo completamente inusabili.
>
> http://www.useit.com/alertbox/9612.html
>
letto. Molto interessante, ma appunto è del 1996.
Inoltre :
1) il principale punto di 'svantaggio' che Nielsen menziona sembra
essere quello che é impossibile 'marcare' l'URL della pagina, perchè
ovviamente l'URL che appare è sempre solo quella della FRameset generale
e non quella della pagina singola.
Okay. Ma cosa c'é di male 'marcare' la pagina generale e andare a
'navigare' ogni volta per ritrovare la pagina che interessa ?
Soprattutto se la pagina che interessa sará senzaltro già 'marcata'
attraverso un link sulla colonna appropriata, che riporta i links ??
E la navigazione attraverso una colonna dedicata, non è forse più
agevole che scrollare tutte le pagine fino all'inizio pagina, o alla
fine pagina, per trovare i links che interessano ??
Il progetto che ho io è piccolo e molto semplice e i Frameset
rispondono egregiamente al mio bisogno.
2) Altro svantaggio menzionato é che le frames 'oscurano' ai motori di
ricerca le parole chiave che potrebbero essere interessanti per chi
vuole trovare qualcosa (ekkekakkio servono allora i <META> statements ???>
3) Nielsen dice (nel 1996) che 'i problemi saranno senzaltro risolti per
quanto
riguarda imaggiori browsers.
La mia pagina ha funzionato fino a ieri con Firefox, Internet Explorer,
Opera, KDE explorer (o come si chiama quello su Linux).
Che si vuole di più ?
Nel frattempo TUTTI i browsers accettano i Frameset. L'errore che Google
Chrome (è ritornato di nuovo stasera, dopo il mio post) presenta (quello
di aprire un nuovo tab invece di mostrare la pagina nella target frame)
è scocciante ma non devastante.
Cioé, visto che è l'unico browser a dare problemi, e il problema è
puramente 'estetico' sto seriamente pensando se, dato che ho premura di
andare sul mercato prima della fine del mese, non è meglio per me
lasciare le cose come stanno e cambiarle per la prossima versione, tra
qualche mese, quando convertirò il tutto con metodica CSS. Nel frattempo
me la imparo e ringrazio per i suggerimenti in proposito.
Per il momento ho cose più importanti alle quali dedicare il mio tempo
che correggere un 'bug' estetico sulla web page.
3) Un professionista (server provider) stasera mi ha detto che lui ha
sempre usato i frames e continuerà a farlo.
In sostanza, nell'articolo di Nielsen non trovo ragioni così
determinanti da giustificare l'assoluto abbandono dei frames.
Lui dà la 'colpa' a Tim Benners, dicendo che è stato un 'peccato di
gioventù' disegnare i frames perchè 'sconvolgono' il link 'una pagina-un
URL'.
Ma dove sta scritto che DEVE esserci una corrispondenza così esatta tra
UNA pagina ed un URL ?
Specialmente nella complessità delle pagine web di oggi ? dove anche
nelle metodiche 'a scrollaggio unico' anche là ci sono 'quadri'
contenenti oggetti diversi ?? Dei quali spesso l'URL non é visibile
immediatamente, meno che non si vada a rompersi l'anima ad analizzare
dal browser le kilometriche 'source pages', nella selva di CSS e
javascripts e HTML tutti mischiati insieme ?
Sorry, ma anche se le frames sono deprecated, io rimango della mia
opinione che non esiste una alternativa paragonabile, in senso di
'programmer friendliness' e semplicitá di programmazione HTML,
per ottenere lo stesso risultato.
Voglio anche specificare che il mio post non vuole essere assolutamente
polemico (anzi sono contento di aver trovato questo NG e rinrazio gli
interlocutori) ma la mia 'foga' è unicamente una foga di 'scambio di
vedute' e sono contento di sentire anche i pareri degli altri.
Sono un po' duro a cambiare opinione (sará l'età), ma quando leggo
ragioni che mi convincono sono sempre pronto a cambiarla.
Grazie ancora per i feedback.
John.
ngw
> ngw schrieb:
>>
>> Si, uscire dagli anni '90 e non usare i frame, che con la "user
>> friendliness" certamente c'entrano, essendo completamente inusabili.
>>
>> http://www.useit.com/alertbox/9612.html
>>
>
> letto. Molto interessante, ma appunto è del 1996.
Si, già nel 1996 i frame erano obsoleti. Ora, nel 2010, fa specie
doverlo ancora discutere, ma si sa, noi italiani siamo troppo avanti.
Speriamo in una riabilitazioni di <blink> e nella riapertura di
Geocities a questo punto.
> Inoltre :
>
> 1) il principale punto di 'svantaggio' che Nielsen menziona sembra
> essere quello che é impossibile 'marcare' l'URL della pagina, perchè
> ovviamente l'URL che appare è sempre solo quella della FRameset
> generale e non quella della pagina singola.
> Okay. Ma cosa c'é di male 'marcare' la pagina generale e andare a
> 'navigare' ogni volta per ritrovare la pagina che interessa ?
Navigare ogni volta per ritrovare la pagina che interessa. Per fortuna
che teniamo all'usabilità.
> Soprattutto se la pagina che interessa sará senzaltro già 'marcata'
> attraverso un link sulla colonna appropriata, che riporta i links ??
>
> E la navigazione attraverso una colonna dedicata, non è forse più
> agevole che scrollare tutte le pagine fino all'inizio pagina, o alla
> fine pagina, per trovare i links che interessano ??
C'entra niente, impara ad implementare la navigazione correttamente. Ti
stai tra l'altro contraddicendo un tantino, è accettabile far navigare
l'utente ogni volta per solo dio sa che navigazione ma non puo'
scrollare ? :D
> Il progetto che ho io è piccolo e molto semplice e i Frameset
> rispondono egregiamente al mio bisogno.
Quindi qual'è il problema ?
> 2) Altro svantaggio menzionato é che le frames 'oscurano' ai motori di
> ricerca le parole chiave che potrebbero essere interessanti per chi
> vuole trovare qualcosa (ekkekakkio servono allora i <META> statements
> ???>
Al di la che i meta "statements" non servono ad un cazzo da anni, se
non titolo e descrizione, non c'entrano niente con i frame, visto che
ovviamente non imposti meta per ogni singolo frame.
> 3) Nielsen dice (nel 1996) che 'i problemi saranno senzaltro risolti per quanto
> riguarda imaggiori browsers.
> La mia pagina ha funzionato fino a ieri con Firefox, Internet Explorer,
> Opera, KDE explorer (o come si chiama quello su Linux).
> Che si vuole di più ?
>
> Nel frattempo TUTTI i browsers accettano i Frameset. L'errore che
> Google Chrome (è ritornato di nuovo stasera, dopo il mio post) presenta
> (quello di aprire un nuovo tab invece di mostrare la pagina nella
> target frame) è scocciante ma non devastante.
Tutti i browser accettano i frames, come accettano innumerevoli altre
vaccate deprecate da 15 anni, appunto perchè non tutti sanno sviluppare
una pagina web correttamente.
Ora, se vuoi saltiamo su una DeLorean, facciamo tornare di moda i Take
That, e ci rilanciamo in una discussione il cui interesse generale è,
spero, uno zero barrato, in quanto a meno che tu non sia Zeldman,
Clarke o appunto Nielsen, non importa granchè se a te i frames
piacciono o meno, che siano dannosi è assolutamente conoscienza comune,
nel caso in cui tu in effetti sia Zeldman, Clarke o Nielsen, sarebbe
interessante più che altro a livello di sostanze psicotrope assunte.
Se vuoi che il tuo sito non sia bookmarkabile, accessibile e
indicizzato, hai trovato il modo giusto, mettere n scrollbar appese a
cazzo per la pagina. Siccome sei venuto su
it.lavoro.*professioni*.webmaster ti si da l'unica indicazione sensata
da uno che fa siti web per professione: i frame sono il male.
> 3) Un professionista (server provider) stasera mi ha detto che lui ha
> sempre usato i frames e continuerà a farlo.
Buon per lui, speriamo che sia più bravo a mantenere server che a fare
pagine, altrimenti sarebbe interessante sapere il nome del luminare in
modo di stargli alla larga.
> In sostanza, nell'articolo di Nielsen non trovo ragioni così
> determinanti da giustificare l'assoluto abbandono dei frames.
>
> Lui dà la 'colpa' a Tim Benners, dicendo che è stato un 'peccato di
> gioventù' disegnare i frames perchè 'sconvolgono' il link 'una
> pagina-un URL'.
Certamente Berners non ha introdotto i frame. Nielsen non da la colpa a
nessuno, studia da 20 anni l'utilizzo del web, e produce alert.
> Ma dove sta scritto che DEVE esserci una corrispondenza così esatta tra
> UNA pagina ed un URL ?
> Specialmente nella complessità delle pagine web di oggi ? dove anche
> nelle metodiche 'a scrollaggio unico' anche là ci sono 'quadri'
> contenenti oggetti diversi ?? Dei quali spesso l'URL non é visibile
> immediatamente, meno che non si vada a rompersi l'anima ad analizzare
> dal browser le kilometriche 'source pages', nella selva di CSS e
> javascripts e HTML tutti mischiati insieme ?
Madonna zio, che casino che fai :D A che pro dare opinioni così
dettagliatamente errate se si ha un'unghia di consapevolezza di non
sapere di cosa si sta parlando ?
Ma che pagine guardi per vedere javascript e css tutti mischiati
insieme ? Guarda che spesso quello che vedi in produzione è molto
lontano da quello che lo sviluppatore ha sul computer eh.
> Sorry, ma anche se le frames sono deprecated, io rimango della mia
> opinione che non esiste una alternativa paragonabile, in senso di
> 'programmer friendliness' e semplicitá di programmazione HTML, per
> ottenere lo stesso risultato.
Per uno che 2 post fa diceva "pensavo che la 'user friendliness' e non
la 'webmaster friendliness'
fosse prioritaria" è un cambiamento molto veloce.
> Voglio anche specificare che il mio post non vuole essere assolutamente
> polemico (anzi sono contento di aver trovato questo NG e rinrazio gli
> interlocutori) ma la mia 'foga' è unicamente una foga di 'scambio di
> vedute' e sono contento di sentire anche i pareri degli altri.
Figurati, polemiche sui frame è difficile farne, di opinioni possibili
ce ne sono molto poche, il fatto è che sono principalmente usate da
newbie e che vengono tipicamente considerati un errore da newbie. Visto
che presumo tu non faccia sta roba di lavoro è comprensibile che non si
voglia spendere tempo su qualcosa di poco interesse.
L'importante è che capisci il costo: frame = niente indicizzazione,
design mediocre, niente bookmark, navigazione mediocre, niente stampa,
niente caching. Se ti va bene usa i frames. Se non ti va bene non
usarli.
Gabriele - onenet
Ah interessante :)
che tipo di clientela è? ossia che tipo di lavori fai?
ciao,
Gabriele
john
> L'importante è che capisci il costo: frame = niente indicizzazione,
> design mediocre, niente bookmark, navigazione mediocre, niente stampa,
> niente caching. Se ti va bene usa i frames. Se non ti va bene non usarli.
>
Se tutte le argomentazioni nella tua requisitoria contro i frames sono
vere (e non ne dubito assolutamente) allora perchè non si eliminano del
tutto, così almeno non si ha l'opzione di usarli o meno ?
Perchè lasciare una 'libertà' che provoca solo danni ?
Li si leva completamente dagli standard ed è finita.
Perchè, come si vede, se esistono, la gente (newbie come me) li usa
perchè sono più 'intuitivi' e facili da usare.
Perpetuando così il problema.
Se sono dannosi ed esecrabili sotto tutti i punti di vista, IMHO
dovrebbero sparire completamente.
Essere 'deprecati' non basta. E' come mettere in vetrina un oggetto con
la etichetta 'non compratelo'.
Paolo De Dionigi
> Figurati, polemiche sui frame è difficile farne, di opinioni possibili
> ce ne sono molto poche, il fatto è che sono principalmente usate da
> newbie e che vengono tipicamente considerati un errore da newbie. Visto
> che presumo tu non faccia sta roba di lavoro è comprensibile che non si
> voglia spendere tempo su qualcosa di poco interesse.
> L'importante è che capisci il costo: frame = niente indicizzazione,
> design mediocre, niente bookmark, navigazione mediocre, niente stampa,
> niente caching. Se ti va bene usa i frames. Se non ti va bene non usarli.
>
> ngw
>
Io pensavo fosse un troll.
Sono lampanti i motivi per cui i frameset non sono accettabili e lo sono
appunto da almeno quindici anni.
I motivi sono ben riassunti da Nicholas e li ripeto così giusto per
evidenziare:
niente indicizzazione, design mediocre, niente bookmark, navigazione
mediocre, niente stampa, niente caching
Per quanto riguarda il punto di forza della navigazione facilitata, che
meraviglia quando si arrivava su pagine indicizzate miracolosamente
prive del frame di navigazione.
john
Io personalmente i siti web li ho sempre fatti gratis per gli amici.
Mo' il mio me lo faccio io personalmente perchè non posso permettermi di
pagare un webmaster.
Però ti giuro che come clienti (scrivo applicazioni di ogni genere in VB
.NET e C# e C/C++) di teste di pera, (cioè che non sanno una pippa di
programmazione e tanto meno di programmazione web) con tanti soldi ne
conosco a josa. E quelli che conosco io si sono lamentati della nuova
'moda' di far scrollare tutta la pagina su e giù.
Forse ciò non avrà a che fare strettamente coi frames, ma a me quello
'scrollaggio totale' moderno fa schifo, e per evitare ciò, fino ad ora
conoscevo solo i frames.
Personalmente mi ritengo un professionista dell'informatica con un
ottimo senso dell'estetica.
E l'estetica e l'ergonomia nel web sono vitali come l'orzo per la birra
o la farina per il pane.
john
.
>
> Sono lampanti i motivi per cui i frameset non sono accettabili e lo sono
> appunto da almeno quindici anni.
>
forse per voi. Non per gli end-user. E il tipo di user-interface che si
usa č diretto proprio all'*user*.
> I motivi sono ben riassunti da Nicholas e li ripeto cosě giusto per
> evidenziare:
>
> niente indicizzazione, design mediocre, niente bookmark, navigazione
> mediocre, niente stampa, niente caching
>
Quante di queste cose sono 'evidenti' all'user ?
Mi sa che, come in ogni professione, si pecchi di 'deformazione
professionale' nel giudicare il prodotto finale dal punto di vista di
'chi deve costruirlo' e non da chi 'lo usa'.
> Per quanto riguarda il punto di forza della navigazione facilitata, che
> meraviglia quando si arrivava su pagine indicizzate miracolosamente
> prive del frame di navigazione.
>
L'utilizzatore finale era cosciente di tutto ciň ?
john
>> 3) Un professionista (server provider) stasera mi ha detto che lui ha
>> sempre usato i frames e continuerà a farlo.
>
> Buon per lui, speriamo che sia più bravo a mantenere server che a fare
> pagine, altrimenti sarebbe interessante sapere il nome del luminare in
> modo di stargli alla larga.
>
Gli ho parlato di questo NG e penso abbia l'intenzione di farvi una
visita. :-))
E' bello sentire più campane.
l...@email.it
> >http://www.useit.com/alertbox/9612.html
>
> letto. Molto interessante, ma appunto è del 1996.
ehm, il discorso è che nel 1996 già non andavano più bene...
> Okay. Ma cosa c'é di male 'marcare' la pagina generale e andare a
> 'navigare' ogni volta per ritrovare la pagina che interessa ?
che devi dare istruzioni da seguire invece che un link. devi dire
"clicca qui, poi guarda a destra (o sinistra), c'è un menu, cerca nel
menu la voce tale e clicca ecc. ecc.".
un bel casino, no, comparato al concetto di permalink? (un link per
ogni contenuto).
> 2) Altro svantaggio menzionato é che le frames 'oscurano' ai motori di
> ricerca le parole chiave che potrebbero essere interessanti per chi
> vuole trovare qualcosa (ekkekakkio servono allora i <META> statements ???>
i meta vengono ignorati dai motori di ricerca seri proprio perché il
realizzatore della pagina ci può scrivere dentro quello che vuole per
ingannare il motore. il motore invece vuole vedere fisicamente che
c'è scritto nella pagina per farsi lui un'idea indipendentemente da
quello che gli vuol far credere il realizzatore della pagina.
è come se ad un esame il prof chiedesse allo studente: "hai studiato?"
e lo studente rispondesse "sì, ho studiato molto e merito 30" e il
prof rispondesse "bene, allora ti segno 30". invece il motore di
ricerca dice "hai studiato? sì? e mo' ti interrogo".
> Cioé, visto che è l'unico browser a dare problemi, e il problema è
> puramente 'estetico' sto seriamente pensando se, dato che ho premura di
> andare sul mercato prima della fine del mese, non è meglio per me
> lasciare le cose come stanno e cambiarle per la prossima versione, tra
ah be', se il problema è questo tranquillo, non sarai né il primo né
l'ultimo che nelle specifiche della sua applicazione web commerciale
impone all'utente di usare un determinato browser, o ci scrive
"ottimizzato per..." e fine dei giochi.
il tuo problema forse è un altro, ma personalmente io faccio sempre
presente ai miei clienti che se ci sono problemi non macroscopici con
ie o se li tengono o cambiano browser che è meglio anche per loro.
> 3) Un professionista (server provider) stasera mi ha detto che lui ha
> sempre usato i frames e continuerà a farlo.
buoni quelli...
> Ma dove sta scritto che DEVE esserci una corrispondenza così esatta tra
> UNA pagina ed un URL ?
vedi sopra, istruzioni da dare "a voce" all'utente per trovare un
contenuto invece di un clic.
> Specialmente nella complessità delle pagine web di oggi ? dove anche
a dire il vero si sta andando sempre più verso una semplificazione
delle pagine web, almeno per gli utenti.
credo che il tuo modo di ragionare derivi proprio dallo sviluppo di
applicativi (ho cominciato anche io così) per i quali lo schermo
andava sfruttato il più possibile ficcandoci dentro più cose
possibili, a costo di renderlo pieno di roba scritta in piccolo. cioè
si dovevano fare pannelli di controllo tipo cruscotto di un'automobile
ma molto più complessi.
ora, il discorso del cruscotto di un'automobile ha un senso perché
l'utente sta con tutte e due le mani sul volante o cose del genere,
quindi chiaro che non ha modo per scrollare. ma un utente di una
pagina web non ha le mani legate dietro la schiena, e può fare su e
giù col mouse. voglio dire, non sta guardando un quadro al museo in
cerca dell'ispirazione. deve interagire con la pagina, toccarla e
manipolarla, così come tocca e manipola un libro di cui gira le pagine
(mmmh... metafora pericolosissima ma altre non me ne vengono).
> nelle metodiche 'a scrollaggio unico' anche là ci sono 'quadri'
> contenenti oggetti diversi ?? Dei quali spesso l'URL non é visibile
> immediatamente, meno che non si vada a rompersi l'anima ad analizzare
no no , aspè, l'url lo si vede sempre e subito, sta nella barra degli
url del browser.
> Sorry, ma anche se le frames sono deprecated, io rimango della mia
> opinione che non esiste una alternativa paragonabile, in senso di
> 'programmer friendliness' e semplicitá di programmazione HTML,
> per ottenere lo stesso risultato.
un div position fixed è molto più semplice di un frame.
> Sono un po' duro a cambiare opinione (sará l'età), ma quando leggo
> ragioni che mi convincono sono sempre pronto a cambiarla.
prova appunto a scrivere un div position fixed, vedrai quant'è più
comodo e veloce di scrivere frames, e come fai prima a passargli
parametri get se serve.
l...@email.it
> Se tutte le argomentazioni nella tua requisitoria contro i frames sono
> vere (e non ne dubito assolutamente) allora perchè non si eliminano del
> tutto, così almeno non si ha l'opzione di usarli o meno ?
>
> Perchè lasciare una 'libertà' che provoca solo danni ?
1. perché è più faticoso togliere che lasciare, 2. perché chi è che
dovrebbe ordinare a chi cosa togliere? gli standard sono come i
semafori a napoli: un consiglio..., 3. perché bene o male non sarebbe
carino fare in modo che delle pagine per quanto obsolete non si vedano
più, insomma i motivi sono vari. certo, sarebbe bello a volte che ci
fosse un'autorità centrale che dica "da oggi questo non si usa più" e
che la cosa funzioni davvero, ma ahimè, forse sarebbe un po'
totalitario come approccio al web.
> Li si leva completamente dagli standard ed è finita.
sapessi quante cose fuori standard ancora girano... :-)
> Perchè, come si vede, se esistono, la gente (newbie come me) li usa
> perchè sono più 'intuitivi' e facili da usare.
>
> Perpetuando così il problema.
ma voi niubi dovreste invece studiarvi le best practices, che non solo
sono più "moderne" (il che potrebbe non essere determinante) ma vi
fanno fare meno fatica adesso, nella realizzazione, e in futuro, nella
manutenzione e nel porting verso altre tecnologie e sistemi.
chiaro che se hai fatto la fatica di imparare i frames adesso devi
fare la fatica di disimpararli e imparare i css, cioè devi fare altre
due fatiche che tutto sommato pensi di poterti evitare, ma nel medio
lungo periodo fare queste due fatiche ti conviene. purtroppo non hai
scelto da subito il metodo migliore.
> Se sono dannosi ed esecrabili sotto tutti i punti di vista, IMHO
> dovrebbero sparire completamente.
>
> Essere 'deprecati' non basta. E' come mettere in vetrina un oggetto con
> la etichetta 'non compratelo'.
il discorso è diverso: non c'è un'"autorità" che possa costringere
tutti a seguire certe regole. purtroppo è qualcosa di non sempre
facile da afferrare. il w3c dà le sue indicazioni ma poi i produttori
dei browser fanno come gli pare (ad esempio microsoft ha sempre fatto
browser che si comportano fuori standard, probabilmente proprio per
fare in modo che il codice scritto "per" ie non funzionasse su altri
browser, così l'utonto diceva "mah, in fondo mi tengo ie e non
installo un altro browser"). non è come il parlamento europeo che fa
le sue direttive e poi gli stati membri *devono* attenervisi.
l...@email.it
>
> Sono lampanti i motivi per cui i frameset non sono accettabili e lo sono
> appunto da almeno quindici anni.
>
> I motivi sono ben riassunti da Nicholas e li ripeto così giusto per
> evidenziare:
>
> niente indicizzazione, design mediocre, niente bookmark, navigazione
> mediocre, niente stampa, niente caching
d'altro canto, se si tratta di applicazioni diciamo così intranet, ad
uso interno aziendale, diciamo che l'indicizzazione tutto sommato non
è fondamentale, la navigazione la imponi come tale ai dipendenti, per
la stampa ti inventi qualcosa...
l...@email.it
wrote:
> Caro john siamo almeno in due a prediligere le frames.
vi prego, già non è bello sentire parlare di frames, almeno cerchiamo
di nominarli correttamente al maschile, vi va?
Alessandro Pellizzari
> Se tutte le argomentazioni nella tua requisitoria contro i frames sono
> vere (e non ne dubito assolutamente) allora perchè non si eliminano del
> tutto, così almeno non si ha l'opzione di usarli o meno ?
"Deprecato" nello standard significa "non devi usarlo per nuovi progetti,
e devi adattare prima possibile i vecchi".
> Perchè lasciare una 'libertà' che provoca solo danni ?
Perche` ci sono milioni di siti che usano i frame, ed eliminandoli da un
giorno all'altro metti nella merda milioni di persone, che devono rifare
i siti.
E perche` il 30% dei navigatori usa ancora Explorer 6 (un browser del
2001), rallentando l'adozione degli standard.
Ad oggi non puoi usare in sicurezza nemmeno i CSS 2.1 e le PNG trasparenti
(che hanno sui 15-20 anni, come standard, se non ricordo male), perche`
quel 30% di persone non li supporta completamente.
Non puoi usare MathML, SVG. Devi usare dei framework js con browser
detection, ecc.
Tutto per quel 30% (e un'altro 30% di IE7 e 8, che sono ancora lontani
dal supportare standard del '95...)
> Li si leva completamente dagli standard ed è finita.
Infatti in HTML4/XHTML1 strict (1999) non li puoi usare. Non ci sono
nello standard. La prima riga della dtd e`
<!ENTITY % HTML.Frameset "IGNORE">
Se tu continui a fare siti in HTML3 o in HTML4 Frameset, li puoi usare.
Ma sei tu che non rispetti lo standard.
Bye.
Alessandro Pellizzari
> Alessandro Pellizzari schrieb:
>
>> C'e` un motivo per cui e` cosi`, non e` semplice moda...
>>
>>
> pensavo che la 'user friendliness' e non la 'webmaster friendliness'
> fosse prioritaria.
E lo e`.
> Ma forse mi sbaglio.
Direi di si`.
Pensa a me che devo vedere il tuo sito basato su frameset con un
cellulare da 480x320, con magari il frame di sinistra largo 400 pixel.
4-5 pixel di bordo e vedo 70 pixel di contenuto, costringendomi a
scrollare a destra e sinistra.
> Esiste un compromesso che faccia contenti sia gli utilizzatori e i
> client-programmers (che devono farli contenti) che i webmasters ? :-))
Rispettare gli standard web, sia di codice che di usabilita`.
> Io come user aborro le pagine che si devono scrollare interamente e
> quando si deve andare a trovare un link bisogna sempre andare al top
> della pagina.
display:fixed;
Mi pare te l'avessero gia` indicato.
Bye.
john
>
>> Okay. Ma cosa c'é di male 'marcare' la pagina generale e andare a
>> 'navigare' ogni volta per ritrovare la pagina che interessa ?
>
> che devi dare istruzioni da seguire invece che un link. devi dire
> "clicca qui, poi guarda a destra (o sinistra), c'è un menu, cerca nel
> menu la voce tale e clicca ecc. ecc.".
>
...cose che succedono normalmente (istruzioni per telefono) quando vuoi
trovare qualcosa sul sito dell'università, o perfino sul sito di
Matlab... :-)))
> i meta vengono ignorati dai motori di ricerca seri proprio perché il
> realizzatore della pagina ci può scrivere dentro quello che vuole per
> ingannare il motore. il motore invece vuole vedere fisicamente che
> c'è scritto nella pagina per farsi lui un'idea indipendentemente da
> quello che gli vuol far credere il realizzatore della pagina.
>
D'altro canto però meglio lasciare che l'utente 'decida lui' in quale
categoria esssere classificcato, piuttosto che andare a spulciare ogni
pagina per vedere 'veramente' cosa fa lui, no ? Anche perchè certe
classificazioni sono difficili da decidere.
Comunque questa è una pura faccenda di opinioni.
Io sono del parere che se una cosa 'non è buona e giusta' bisogna
eliminarla tout-court.
Invece di 'deprecare' le cose, bisognerebbe non lasciare la scelta ed il
problema è eliminato.
> è come se ad un esame il prof chiedesse allo studente: "hai studiato?"
> e lo studente rispondesse "sì, ho studiato molto e merito 30" e il
> prof rispondesse "bene, allora ti segno 30". invece il motore di
> ricerca dice "hai studiato? sì? e mo' ti interrogo".
>
Perdita di tempo assoluta. Cosa che un motore di ricerca non si puo'
permettere.
> credo che il tuo modo di ragionare derivi proprio dallo sviluppo di
> applicativi (ho cominciato anche io così) per i quali lo schermo
> andava sfruttato il più possibile ficcandoci dentro più cose
> possibili, a costo di renderlo pieno di roba scritta in piccolo. cioè
> si dovevano fare pannelli di controllo tipo cruscotto di un'automobile
> ma molto più complessi.
>
Nel mio caso invece sto cercando l'eleganza nella semplicità.
E per me uno sfondo totalmente bianco, con tre o quattro link a
sinistra, fissi, che non scrollano, ed una 'parte destra' che scrolla su
e giù, mantenendo appunto lo stesso colore di background (nel mio caso
bianco) sono il non plus ultra della semplicità e dell'eleganza.
Senza dover scrollare fino in fondo o fino al top per cercare la pagina
dove vuoi andare.
>
> un div position fixed è molto più semplice di un frame.
>
però qualcuno qui parlava che il 'refresh' lo potevi fare solo con Ajax.
E qui entriamo in un altra cosa di cui non ho esperienza.
Cioé, non è *immediato* come fare i frames.
Vabbé, adesso conosco l'alternativa del CSS e penso di impararmi bene
quella. Così eliminerò i frames.
Ma per me significa dover cambiare circa un centinaio di pagine.
E sinceramente non ho voglia di farlo *adesso* perchè non ne ho il tempo.
>> Sono un po' duro a cambiare opinione (sará l'età), ma quando leggo
>> ragioni che mi convincono sono sempre pronto a cambiarla.
>
> prova appunto a scrivere un div position fixed, vedrai quant'è più
> comodo e veloce di scrivere frames, e come fai prima a passargli
> parametri get se serve.
Sì, ma come dico a un div di 'spostarsi a destra' e all'altro di
'spostzarsi a sinistra' sullo stesso piano ???
E cos'è esattamente questa storia del 'refresh' ??
Ci sono molto cose che ancora devo imparare.
(Cose come il 'div' e 'ul' 'li' le avevo viste fin dal 1997 sul manuale
del HTML 3 ma non avevo mai visto applicarle)
john
> Avevo 'inventato' una tecnica che mi
> permetteva di scambiare dati col server con grandissima efficienza
> (tramite una frame invisibile che usavo come buffer per i dati
toh, *esattamente* quello che mi ha detto ieri sera il mio amico 'server
provider'...un momento...sarai mica tu in incognito ??? Alessandro ???
<hahahahaha>
>>
>> Da notare che Chrome, Firefox e Internet Explorer 8 danno tutti una
>> schermata diversa.
>
> Si, ciao, dovresti provare a programmare in javascript, allora lì si che
> ti divertiresti per ottenere lo stesso effetto almeno sui 4-5 browser
> 'più diffusi'.
>
Purtroppo non mastico il javascript ! E' difficile mantenere lo 'state
of the Art in VB. NET, nei Design Patterns, nel Relational Database
Design, nei nuovi linguaggi di programmazione ad alto livello che
nascono come i funghi ogni giorno...ekkekakkkio...sono un semplice
informatico, mica Gesù Cristo.. :-))))
Vabbé, lo so, javascript è una della 'basi' del web, ma non ho mai avuto
il tempo (e la voglia) di approfondire. Così come gli Applet e Java.
L'unico a cui mi sono dedicato è il PHP per necessità (POS virtuale).
> > Io ultimamente creo le mie pagine con Frontpage, perchè lo scrivere
>> unicamente l'HTML con Notepad, risultava essere troppo primitivo,
>> appunto per via dei CSS che non conosco, ancora oggi, troppo bene.
>
> Credo che Frontpage sia un po' da dilettanti, ma sono rimasto alle
> versioni paleolitiche per cui non sono sicuro. Prova a scaricarti
> stylemaster (che io uso come un manuale di css), e ACEHtml (la versione
> free), credo che siano un punto di partenza un po' più istruttivo.
>
>> Cercando consigli qua e là, mi sono sentito dare sempre la stessa
>> risposta : abbandona i frames ! Assolutamente.
>
> Eh, come ti capisco!
>
>
> Forse puoi usare i DIV, con CSS lo definisci a posizione assoluta e
> bloccato sulla pagina come una frame... il resto della pagina scrolla ma
> il DIV no.
>
Questa è la strada che imboccherò senzaltro.
>
> Ma perché non aspetti che correggano il bug di Chrome e intanto usi
> Opera o Firefox? Di bug si tratta, no? Anzi lo stesso bug c'era su una
> vecchia versione di Opera (forse 8.54). Le frames per ora sono
> supportate. Se il sito è progettato con attenzione e non dovrebbero dare
> problemi...
>
> Comunque tienici informati...
> Dan
Senzaltro. Ormai sono qui nel 'club'. :-))
E grazie del feedback !
john
>> Io come user aborro le pagine che si devono scrollare interamente e
>> quando si deve andare a trovare un link bisogna sempre andare al top
>> della pagina.
>
> display:fixed;
>
> Mi pare te l'avessero gia` indicato.
>
Recepito completamente !
I CSS sonola prima cosa a cui mi dedicherò prossimamente !
Grazie anche a te del feedback !
filippo
>> è come se ad un esame il prof chiedesse allo studente: "hai studiato?"
>> e lo studente rispondesse "sì, ho studiato molto e merito 30" e il prof
>> rispondesse "bene, allora ti segno 30". invece il motore di ricerca
>> dice "hai studiato? sì? e mo' ti interrogo".
>>
>>
> Perdita di tempo assoluta. Cosa che un motore di ricerca non si puo'
> permettere.
Ma anche no.
Perchè perdere tempo a ottimizzare codice e testo nelle pagine, scrivere
e non copincollare, mettere gli alt in tutte le immagini?
Un bel META con "'azzo, 'iga, 'ulo, 'onache_che_trombano' e i motori di
ricerca schiafferano il mio sito in cima alle ricerche ('chè tanto si sa
che l'utente non può usare il mouse per scrollare perchè la mano la sta
usando ...per scrollare qualcos'altro)
> però qualcuno qui parlava che il 'refresh' lo potevi fare solo con Ajax.
> E qui entriamo in un altra cosa di cui non ho esperienza.
>
> Cioé, non è *immediato* come fare i frames.
Il fatto che *tu* non lo sappia fare non significa che non sia immediato
per me o per un altro.
> Ma per me significa dover cambiare circa un centinaio di pagine. E
> sinceramente non ho voglia di farlo *adesso* perchè non ne ho il tempo.
Cattiva pianificazione del sito. Separando la logica dalla presentazione
ed utilizzando i CSS (che si chiamano così proprio perchè ereditano in
cascata le proprietà), modificare anche qualche migliaio di pagine è una
bazzecola.
> (Cose come il 'div' e 'ul' 'li' le avevo viste fin dal 1997 sul manuale
> del HTML 3 ma non avevo mai visto applicarle)
Eh già. Certo, usare editor visuali del calibro di frontpage non aiuta a
migliorare le proprie competenze.
ciao
Filippo B.
--
http://www.danzainsieme.it
http://www.boschetti.info
D.Campagna
Può darsi che frame in inglese sia maschile (non ci ho mai fatto caso)
ma in italiano cornice è femminile, quindi non è così fuor di luogo
usare il termine originale ma nel genere che avrebbe nella lingua in cui
ci si sta esprimendo. Per esempio potrei dire "la 'madchen' era bella",
quando in tedesco madchen(ragazza) è neutro...
Va be', userò il maschile, mi adeguerò...
Cooper
"john" <du...@agdp.de> ha scritto nel messaggio
news:hvb9th$dv$1...@nnrp.linuxfan.it...
> Nel ringraziare tutti quelli che hanno risposto al mio post, mi sento in
> dovere di informare che ho trovato l'inghippo :
> stavolta non è colpa del browser (Chrome) bensì di Frontpage, che
> chissà per quale oscuro motivo, rieditando un file HTML ha 'cancellato'
> nelll'hiperlink l'attributo 'target'.
>
Per quanto superato frontpage... esso non cancella nulla senza che nulla
l'utente che lo usa chiede di fare al programma.
> PS - Qualcuno puo' consigliare un prodotto migliore del Frontpage che
> pur occupandosi dello styling, non genera centinaia di righe inutili (e
> difficilmente leggibili) di codice HTML ??
>
Notepad (o blocco note) gratuito ed incluso nel tuo so, oppure Adobe
Dreamweaver in modalità editor testuale (a pagamento).
--
http://www.blueware.it
bluewarewebstudio (skype)
Cooper
<l...@email.it> ha scritto nel messaggio
news:de1c0643-40e3-415d...@w12g2000yqj.googlegroups.com...
> se no uno pu� sempre fare un bel jpeg 1024x768 e modificarlo con
> photoshop, quella � la cosa che davvero si fa prima.
>
lol
Cooper
> invece è un bene. in questo modo l'evoluzione seleziona solo gli
> utenti più intelligenti e tenaci. gli altri muoiono e la razza
> migliora.
>
john
> Ma anche no.
> Perchè perdere tempo a ottimizzare codice e testo nelle pagine, scrivere
> e non copincollare, mettere gli alt in tutte le immagini?
> Un bel META con "'azzo, 'iga, 'ulo, 'onache_che_trombano' e i motori di
> ricerca schiafferano il mio sito in cima alle ricerche ('chè tanto si sa
> che l'utente non può usare il mouse per scrollare perchè la mano la sta
> usando ...per scrollare qualcos'altro)
>
Allora hai confermato che i META sono una ca§§ata che dovrebbe essere
eliminata.
Se il motore di ricerca *in ogni modo* investiga il tuo sito, perchè
permettere l'esistenza dei META ?? No ne vedo la ragione.
Se il professore ha intenzione di interrogarti in ogni modo stamattina,
a che pro chiederti se sei preparato? Solo per 'beccarti' se dici la
verità ?
Non è compito di un motore di ricerca fare il detective e vedere se tu
dici la verità.
>>
>> Cioé, non è *immediato* come fare i frames.
>
> Il fatto che *tu* non lo sappia fare non significa che non sia immediato
> per me o per un altro.
>
Certo, l'immediatezza è relativa all'esperienza.
Ma l'esperienza è anche relativa all'immmediatezza in cui si recepiscono
le cose, se sono difficili o facili da imparare.
> Eh già. Certo, usare editor visuali del calibro di frontpage non aiuta a
> migliorare le proprie competenze.
>
prima di Frontpage usavo due software in parallelo : Notepad e un browser.
Dovevo editare con Notepad, salvare, passare al browser, cliccare sul
refresh (che non funziona mai alla prima per via del cache che mantiene
la pagina precedente).
Se questo è 'lavorare professionalmente' io sono un cinese.
Con Frontpage almeno tutto diventa più veloce. Salvo purtroppo le
centinaia di codice generato (spesso alla Membro di Segugio, va detto
onestamente).
Ma purtroppo non conosco nessun altro modo per produrre pagine web in
modo efficiente.
Un giorno provai Dreamweaver, ma non era quello che pensavo.
Forse ero troppo pigro per rimpararlo e farci la mano.
Allora sono rimasto con Frontpage.
Addirittura per un breve periodo usai MS Word !
Poi mi resi conto che con Frontpage avevo lo stesso risultato, con in
più il vantaggio di poter editare l'HTML.
Ciao.
John.
Cooper
news:hvbfbn$44q$1...@nnrp.linuxfan.it...
> ...hai mai dovuto sviluppare per degli utenti tenaci ma ignoranti e pigri,
> che sprizzano miliardi da tutti i pori, e che ti pagano qualsiasi prezzo
> purchè gli dai *quello che vogliono loro* senza discutere ?
>
> Sono quelli che danno lavoro a tutti noi.
>
E' vero, sono quelli che danno lavoro... ma è anche vero che un
professionista che fa solo quello che viene detto senza spiegare loro pro e
contro delle loro scelte in verità non è affatto un professionista, ma un
mero esecutore di ordini, una macchina umana.
Il professionista tende a offrire soprattutto un servizio di consulenza
mirato a far capire che sulla base di elementi oggettivi, nell'interesse del
cliente medesimo (e non nell'interesse di chi deve accaparrarsi i soldini) è
preferibile seguire una strada piuttosto che un altra.
Se ho capito bene, tu realizzi siti con i frames.... solo perchè il cliente
ti chiede ciò... probabilmente il cliente è rimasto indietro... e non sa
delle novità.... e può essere giustificato... ma tu che conosci le novità
certamente no.
Il cliente a un certo punto può benissimo informarsi da un altra persona, o
pure casualmente parlando con un altra persona può saltare fuori il discorso
del web.... e quell'altra persona dice: ti sei fatto fare un sito con i
frames? ma ormai sono superati etc etc... ebbene il cliente dirà: cazzo,
perchè il mio webmaster non me l'ha detto??? insomma mi ha preso per il
culo... mi ha fregato... e mo adesso ci penso io.
Ciò premesso il consiglio che posso darti è: informa il cliente di tutti i
pro e contro... dopo gli fai firmare un documento in cui dichiara di essere
stato informato delle conseguenze delle sue scelte e quindi ti esoneri da
ogni eventuale responsabilità... e quindi te ne lavi le mani. Se il cliente
le cose le vuole in quel modo, tu hai fatto il tuo dovere di informarlo, e
lui al tempo stesso non potrà giustificarsi in alcun modo su di te...
john
>
> <l...@email.it> ha scritto nel messaggio
> news:de1c0643-40e3-415d...@w12g2000yqj.googlegroups.com...
>> photoshop, quella è la cosa che davvero si fa prima.
>>
> lol
>
per una 'dimostrazione' in occasione della visita del presidente della
repubblica penso che sia la prassi normale...
:-)
Cooper
news:hvcjkj$23t$1...@nnrp.linuxfan.it...
> Personalmente mi ritengo un professionista dell'informatica con un ottimo
> senso dell'estetica.
>
professionista informatico per quanto riguarda la programmazione di
applicativi server/desktop... ma per quanto riguarda il web non puoi
definirti un professionista web.
> E l'estetica e l'ergonomia nel web sono vitali come l'orzo per la birra o
> la farina per il pane.
>
L'estetica nel web non è affatto vitale. Tu confondi una pagina web con una
presentazione cartacea. Sulla carta quello che dici tu è vero; sul web
purtroppo per te, non è cosi.
Quello che tu definisci ergonomia in realtà consiste nella realizzazione di
pagine web semplici, conformi agli standard w3c, usabili e accessibili; ma
tutto questo spesso richiede dei sacrifici in termini di estetica.
Dunque estetica ed ergonomia non possono andare al 100% a braccetto.
Io ti invito a non confondere una presentazione cartacea (dove la grafica e
l'impatto visivo sono fondamentali) con una pagina web, dove invece è
fondamentale l'informazione contenuta nella pagina e non il modo in cui essa
viene mostrata.
Chi si orienta di più sulla estetica che sul contenuto di una pagina
normalmente è un webmastella, uno che è tutto meno che un professionista del
web.
Cooper
> Sono un po' duro a cambiare opinione (sará l'età), ma quando leggo ragioni
> che mi convincono sono sempre pronto a cambiarla.
>
utilizzare l'oggetto TPANEL per definire le aree della finestra della
applicazione che stai sviluppando e ti viene naturale quanto spontaneo
applicare il medesimo principio ad una pagina web.
Purtroppo però una pagina web (non il browser) non è una applicazione desk e
va guardata in una ottica diversa.
Cooper
> Se tutte le argomentazioni nella tua requisitoria contro i frames sono
> vere (e non ne dubito assolutamente) allora perchè non si eliminano del
> tutto, così almeno non si ha l'opzione di usarli o meno ?
>
> Perchè lasciare una 'libertà' che provoca solo danni ?
>
> Li si leva completamente dagli standard ed è finita.
>
programmazione a oggetti è stato introdotto il concetto di ereditarietà?
Forse per mantenere una compatibilità verso il basso fra applicazioni non
credi? In altre parole (lo spiego per chi non lo sa), l'oggetto T1 nasce in
un modo, quando si aggiungono nuove caratteristiche a T1 si crea un nuovo
oggetto chiamato T2 che eredita tutte le caratteristiche di T1 e che ha
implementate le nuove funzionalità. In tal modo chi usa l'oggetto T1 potrà
continuarlo a usare (versione vecchie) e chi usa l'oggetto T2 potrà accedere
alle nuove funzionalità che non sono presenti in T1.
Se tu apportassi le tue modifiche sempre su T1 tutte quelle applicazioni che
fanno ricorso all'oggetto T1 verrebbeo compromesse, invece creando un
oggetto T2 ereditato da T1 questo problema non si pone.
In termini pratici, è vero che i frame sono deprecati e non più utilizzati,
ma è anche vero che ci sono siti vecchi che (non aggiornati) fanno uso dei
frames.
Se fosse tolto il supporto ai frames, quei siti internet non si vedrebbero
più e verrebbe meno la compatibilità verso il basso con i siti internet piu
vecchi.
Perchè complicarsi la vita in questo modo? Dal momento che il web si evolve,
quello che è stato non ha motivo di essere cancellato, basta semplicemente
non ricorrere più al vecchio metodo, ma abituarsi a usare il nuovo.
> Perchè, come si vede, se esistono, la gente (newbie come me) li usa perchè
> sono più 'intuitivi' e facili da usare.
>
Nessuno ti impedisce di usarli, ma i browser avessero rimosso il supporto ai
frames, adesso tu saresti nei casini perchè non sapresti come realizzare la
tua paginetta e ti sentiresti perso almeno all'inizio.... poi facendo un po'
di pratica (obbligata) impareresti le nuove metodologie.
Io sarei perfettamente d'accordo sul fatto che venga rimosso per intero il
supporto ai frames dai browser, cosi si costringe la gente a evitare di
usarli.
> Se sono dannosi ed esecrabili sotto tutti i punti di vista, IMHO
> dovrebbero sparire completamente.
>
Non sono dannosi, sono inutili è diverso, perchè puoi raggiungere i medesimi
risultati utilizzando solo una pagina anzichè doverne coinvolgere almeno 2.
> Essere 'deprecati' non basta. E' come mettere in vetrina un oggetto con la
> etichetta 'non compratelo'.
>
Su questo siamo d'accordo, ma non ti scordare la compatibilità verso il
basso che nel caso dei vestiti non esiste e quindi il tuo paragone è privo
di senso nel caso specifico.
john
>
> E' vero, sono quelli che danno lavoro... ma è anche vero che un
> professionista che fa solo quello che viene detto senza spiegare loro
> pro e contro delle loro scelte in verità non è affatto un
> professionista, ma un mero esecutore di ordini, una macchina umana.
Benvenuto nella reltà umana.
> Il professionista tende a offrire soprattutto un servizio di consulenza
> mirato a far capire che sulla base di elementi oggettivi, nell'interesse
> del cliente medesimo (e non nell'interesse di chi deve accaparrarsi i
> soldini) è preferibile seguire una strada piuttosto che un altra.
Questo in un mondo ideale dove il consulente decide come fare i ca§§i
suoi perchè sa come farli professionalmente.
Tanto per rispondere alla tua prossima questione : non ho mai visto un
cliente che 'obbliga' il programmatore ad usare o non usare i frames.
A meno che il cliente non sia anche lui un pofessionista del web.
I frames li ho usati fin dall'inizio solo perchè non conoscevo nessuna
alternativa. Ho cominciato a 'giocare' con HTML nel 1997 e mi considero
senzaltro tuttora un newbie perchè non sono allo 'state of the art' del
web developing. Forse un giorno, leggendo e sbattendomi le corna e
confrontandomi con gli altri, ci arriverò.
Nel frattempo, fin d'ora ho usato i frames semplicemente per ignortanza.
Non ho mai applicato i div, e non ho mai trovato il tempo o la
motivazione di impararmi i CSS.
Ora le cose cambieranno.
> Se ho capito bene, tu realizzi siti con i frames.... solo perchè il
> cliente ti chiede ciò... probabilmente il cliente è rimasto indietro...
> e non sa delle novità.... e può essere giustificato... ma tu che conosci
> le novità certamente no.
No no. Io ho sempre costruito siti PER HOBBY E GRATIS per la parrocchia,
per i miei amici che avevano piccole aziende, per profesionisti dello
spettacolo, insomma per tutti quelli (amici miei) che mi rompevano le
scatole.
E' diverso dall'essere un professionista.
Per professione io sviluppo applicazioni, in linguaggi di alto livello
(Visual Basic, VB .NET C#) e di basso livello (C/C++)
> Il cliente a un certo punto può benissimo informarsi da un altra
> persona, o pure casualmente parlando con un altra persona può saltare
> fuori il discorso del web.... e quell'altra persona dice: ti sei fatto
> fare un sito con i frames? ma ormai sono superati etc etc... ebbene il
> cliente dirà: cazzo, perchè il mio webmaster non me l'ha detto???
Perché non è il compito del webmaster educare il popolo.
Per quello ci sono gli insegnanti e i libri.
> insomma mi ha preso per il culo... mi ha fregato... e mo adesso ci penso
> io.
Non penso che quello che dscrivi sia realistico. Non ho MAI inconttrato
un tizio che commissiona un sito web e SA CHE COSA SONO i frames.
> Ciò premesso il consiglio che posso darti è: informa il cliente di tutti
> i pro e contro... dopo gli fai firmare un documento in cui dichiara di
> essere stato informato delle conseguenze delle sue scelte e quindi ti
> esoneri da ogni eventuale responsabilità... e quindi te ne lavi le mani.
Evidentemente sei un professionista serio e con le palle : conosci i
rischi del mestiere e ti preoccupi giustamente di proteggerti le
chiappe. Bravo.
Io, grazie al cielo, non mi trovo in quella situazione. Questo sito che
sto facendo è il mio personale e lo faccio, (per la prima volta da
quando programmo web) con l'intenzione di *vendere* qualcosa.
Ciao.
john.
Cooper
> Paolo De Dionigi schrieb:
> .
>
Sul piano visivo ed estetico, si possono ottenere gli stessi risultati di
una struttura a frames senza farne uso; ma semplicemente ricorrendo all'uso
di css.
Il vantaggio è che anzichè avere a che fare con 4-5 pagine distinte (header,
footer, colonna sx, colonna dx e cosi via) puoi fare tutto in una sola
pagina.
In più i css possono essere esportati in un altro file e richiamati su
ciascuna pagina con 1 riga di codice, senza doverli ogni volta ripetere.
In un linguaggio a te più comodo da comprendere è come se avessi tanti
moduli. Una procedura comune a tutti i moduli, è piu comoda per te ripeterla
ogni volta per ogni modulo oppure inserirla in un modulo e richiamarla dagli
altri moduli?
Io penso la seconda. Perchè nel primo caso se cambi qualche funzione dentro
la procedura le modifiche le devi fare su tutti i moduli del tuo
applicativo, nel secondo caso le fai solo sul modulo della procedura e
automaticamente l'aggiornamento si applica a tutti gli altri moduli.
> Quante di queste cose sono 'evidenti' all'user ?
>
TUTTE.
> Mi sa che, come in ogni professione, si pecchi di 'deformazione
> professionale' nel giudicare il prodotto finale dal punto di vista di
> 'chi deve costruirlo' e non da chi 'lo usa'.
>
Falso.
> L'utilizzatore finale era cosciente di tutto ciò ?
>
Si
Cooper
<l...@email.it> ha scritto nel messaggio
news:4d9c4a1b-4d27-4b88...@g19g2000yqc.googlegroups.com...
non è specificato... quindi andrebbe usato in senso neutro (che per default
in italiano è il genere maschile).
john
> L'informatica si compone di diverse branche... sicuramente sarai un
> professionista informatico per quanto riguarda la programmazione di
> applicativi server/desktop... ma per quanto riguarda il web non puoi
> definirti un professionista web.
>
non ci penso nemmeno. :-))
Ma, come dicevo, spero che le cose cambino presto.
>>
> Dunque estetica ed ergonomia non possono andare al 100% a braccetto.
> Io ti invito a non confondere una presentazione cartacea (dove la
> grafica e l'impatto visivo sono fondamentali) con una pagina web, dove
> invece � fondamentale l'informazione contenuta nella pagina e non il
> modo in cui essa viene mostrata.
Mi permetto di dissentire.
Appunto perch� il web � ormi pi� diffuso del cartaceo, e importante la
presentazione.
Macromedia se ne era reso conto subito ed invent� Flash. E poi Director.
> Chi si orienta di pi� sulla estetica che sul contenuto di una pagina
> normalmente � un webmastella, uno che � tutto meno che un professionista
> del web.
No. E' un 'commerciale' che vuole 'impressionare' colui che si attacca
al PC per 'comprare' la merce che vuole vendere.
E' uno che si occupa della 'psicologia' di colui che sta al computer e
prevede come reagisce.
Tutte cose che il webmaster non puo' sapere altrimenti farebbe lo
psicologo e non il webmaster.
E' per questo che bisogna trovare un mezzo per coordinare le 'necessit�'.
In pratica il webmaster � l'ultimo anello della catena :
compratore-->esperto di mercato-->venditore che vuol
vendere--->programmatore web--->webmaster.
Cio� e' quello che dice al committente di pagina web : 'questo si puo'
fare', questo non si puo' fare' e 'questo richiede compromessi'.
(io identifico webmaster come colui che si occupa del server, per quello
scindo le due funzioni.
Ma non � detto che un programmatore web non sia anche webmaster).
Daniele Orlandi
>
> toh, *esattamente* quello che mi ha detto ieri sera il mio amico 'server
> provider'
Cos'è un 'server provider' ?
> Purtroppo non mastico il javascript ! E' difficile mantenere lo 'state
> of the Art in VB. NET, nei Design Patterns, nel Relational Database
> Design, nei nuovi linguaggi di programmazione ad alto livello che
> nascono come i funghi ogni giorno...ekkekakkkio...sono un semplice
> informatico, mica Gesù Cristo.. :-))))
/me vomita
> Vabbé, lo so, javascript è una della 'basi' del web, ma non ho mai avuto
> il tempo (e la voglia) di approfondire. Così come gli Applet e Java.
> L'unico a cui mi sono dedicato è il PHP per necessità (POS virtuale).
/me vomita il suo stesso stomaco
--
Daniele Orlandi つづく
john
> Daccordo, però io ti consiglio di aggiornarti anche solo per passione,
> lasciando ciò che appartiene al passato e guardando soprattutto a ciò
> che sono gli strumenti adesso.
> Adesso c'è vb 2010... sicuramente ha molte novità rispetto al vb6 o
> perchè no rispetto al vb4, vb5. Dovendo scegliere fra vb1 e vb6 quale
> scegli? io credo vb6 o sbaglio? :)
Qui mi permetto io di darti un consiglio : nessuno al giorno d'oggi
comincerebbe un progetto in VB6. Sarebbe un suidicio professionale. Oggi
esiste il .NET. Quindi : VB .NET e C#. :-)))
> la stessa cosa è qui :)
è per questzo che sono venuto qui, ad aggiornarmi sullo 'state of the
art' e ad avere suggerimenti.
Pnso che le cose cambieranno molto presto anche da me, (grazie a voi...)
> perchè
> utilizzare degli strumenti superati quando sono stati posti in essere
> nuovi strumenti, più flessibili e più efficienti? :) un po' di pazienza
> e si imparano anche quelli e ti assicuro che dopo anche tu dirai: cazzo,
> ma questi css sono davvero una cagata pazzesca..... ho perso tanto tempo
> con i frames, quando questi mi offrono qualcosa di veramente eccezionale :)
>
Sono sicuro che sará così. Grazie infinite del feedback !
Daniele Orlandi
>
> Definire C/C++ un linguaggio di basso livello mi sembra un po' azzardato
> eh. Per definizione un linguaggio di basso livello è l'Assembly.
> Certamente C/C++ rispetto a visual basic o delphi
Non confrontare linguaggi di basso livello con linguaggi di livello basso :)
--
Daniele Orlandi つづく
Cooper
> Io, grazie al cielo, non mi trovo in quella situazione. Questo sito che
> sto facendo è il mio personale e lo faccio, (per la prima volta da quando
> programmo web) con l'intenzione di *vendere* qualcosa.
>
lasciando ciò che appartiene al passato e guardando soprattutto a ciò che
sono gli strumenti adesso.
Adesso c'è vb 2010... sicuramente ha molte novità rispetto al vb6 o perchè
no rispetto al vb4, vb5. Dovendo scegliere fra vb1 e vb6 quale scegli? io
flessibili e più efficienti? :) un po' di pazienza e si imparano anche
quelli e ti assicuro che dopo anche tu dirai: cazzo, ma questi css sono
davvero una cagata pazzesca..... ho perso tanto tempo con i frames, quando
questi mi offrono qualcosa di veramente eccezionale :)
--
http://www.blueware.it
bluewarewebstudio (skype)
john
..era per la parte C. Ma oggi lo si usa in coppia con C/C++...a mi sono
adeguato.
Penso che solo uno schizofrenico potrebbe programmare in assembler al
giorno d'oggi.
Quello lo si usa solo ancora (forse) negli embedded system.
Cooper
> Per professione io sviluppo applicazioni, in linguaggi di alto livello
> (Visual Basic, VB .NET C#) e di basso livello (C/C++)
>
Per definizione un linguaggio di basso livello è l'Assembly.
livello essendo meno astratto ma rispetto all'assembly è piu astratto eccome
e quindi di alto livello.
Dipende da come guardi la cosa.
john
> john wrote:
>> toh, *esattamente* quello che mi ha detto ieri sera il mio amico 'server
>> provider'
>
> Cos'è un 'server provider' ?
è uno che ha una ditta che ospita molti server sui quali ci sviluppa
sistemi PHP-based
>
>> Purtroppo non mastico il javascript ! E' difficile mantenere lo 'state
>> of the Art in VB. NET, nei Design Patterns, nel Relational Database
>> Design, nei nuovi linguaggi di programmazione ad alto livello che
>> nascono come i funghi ogni giorno...ekkekakkkio...sono un semplice
>> informatico, mica Gesù Cristo.. :-))))
>
> /me vomita
>
dovresti mangiare cose più sane....
>> Vabbé, lo so, javascript è una della 'basi' del web, ma non ho mai avuto
>> il tempo (e la voglia) di approfondire. Così come gli Applet e Java.
>> L'unico a cui mi sono dedicato è il PHP per necessità (POS virtuale).
>
> /me vomita il suo stesso stomaco
>
chissà cosa mastichi tu....
Cooper
> Daniele Orlandi schrieb:
>> john wrote:
>>> toh, *esattamente* quello che mi ha detto ieri sera il mio amico 'server
>>> provider'
>>
>> Cos'è un 'server provider' ?
>
> è uno che ha una ditta che ospita molti server sui quali ci sviluppa
> sistemi PHP-based
>
web :)
Daniele Orlandi
>
> ..era per la parte C. Ma oggi lo si usa in coppia con C/C++...a mi sono
> adeguato.
Il C++ per me non esiste, è un ibrido con tutti i difetti del C e un
qualcosa che vuole assomigliare ad estensioni OO.
> Penso che solo uno schizofrenico potrebbe programmare in assembler al
> giorno d'oggi.
Dipende sempre dal contesto e dalla specifica esigenza. Esistono ancora
situazioni un cui ha molto senso.
--
Daniele Orlandi つづく
Daniele Orlandi
>
>> Cos'è un 'server provider' ?
>
> è uno che ha una ditta che ospita molti server sui quali ci sviluppa
> sistemi PHP-based
Allora usa le definizioni che già esistono, invece che inventarne di nuove
:)
> dovresti mangiare cose più sane....
La mia alimentazione informatica è estremamente sana, proprio per questo
solo l'odore di certe cose causa conati.
--
Daniele Orlandi つづく
Paolo De Dionigi
> Paolo De Dionigi schrieb:
> .
>>
>> sono appunto da almeno quindici anni.
>>
>
> forse per voi. Non per gli end-user. E il tipo di user-interface che si
> usa è diretto proprio all'*user*.
Ma tu ti qualifichi come utente finale? Perchè allora capisco tutto. La
tua esperienza con *un sito* con i frameset è positiva e quindi
categorizzi il fatto che i frameset sono perfetti.
Peccato che ci siano ennemila altre situazioni, cirscostanze, siti,
utenti, utonti, per i quali i frameset non vanno bene. In realtà non
vanno bene nemmeno per la tua situazione, solo che tu non hai le
competenze adeguate per valutare la cosa e quindi non te ne accorgi.
Ciò che tu consideri come aspetto positivo dei frameset può essere
benissimo replicato con altre 'tecnologie' che però non si portano
dietro i problemi (che tu ti ostini a non vedere, nonostante ti siano
stati indicati) dei frameset.
>> I motivi sono ben riassunti da Nicholas e li ripeto così giusto per
>> evidenziare:
>>
>> niente indicizzazione, design mediocre, niente bookmark, navigazione
>> mediocre, niente stampa, niente caching
>>
>
> Quante di queste cose sono 'evidenti' all'user ?
> Mi sa che, come in ogni professione, si pecchi di 'deformazione
> professionale' nel giudicare il prodotto finale dal punto di vista di
> 'chi deve costruirlo' e non da chi 'lo usa'.
Mi sa che non hai capito proprio il concetto di base. I frameset sono
controproducenti proprio per l'utente finale, oltre che per il
proprietario del sito. Per lo sviluppatore sono (erano) solo una rogna
da 'manutenere', nemmeno più di tanto.
>> Per quanto riguarda il punto di forza della navigazione facilitata,
>> che meraviglia quando si arrivava su pagine indicizzate
>> miracolosamente prive del frame di navigazione.
>>
> L'utilizzatore finale era cosciente di tutto ciò ?
>
Prego? Ho fatto un'esempio di usabilità zero dovuto all'utilizzo dei
frameset, che porta l'utente ad arrivare ad una pagina e non sapere come
navigare nel resto del sito perchè grazie ai frameset il frame di
navigazione non c'è!
Se non lo capisci, amen, continua pure ad usare i frame.
Cooper
"Daniele Orlandi" <dan...@orlandi.com> ha scritto nel messaggio
news:QqWdnVgbN-UPmIfR...@kpnqwest.it...
>> Penso che solo uno schizofrenico potrebbe programmare in assembler al
>> giorno d'oggi.
>
> Dipende sempre dal contesto e dalla specifica esigenza. Esistono ancora
> situazioni un cui ha molto senso.
>
casi quando si tratta di interagire direttamente a livello di processore,
risulta essere più comodo utilizzare istruzioni assembly che istruzioni di
alto livello; in ogni caso, tutto dipende dal contesto.
Paolo De Dionigi
> On 17 Giu, 09:35, Paolo De Dionigi<PaoloDeDion...@gmail.com> wrote:
>>
>> Sono lampanti i motivi per cui i frameset non sono accettabili e lo sono
>> appunto da almeno quindici anni.
>>
>> evidenziare:
>>
>> niente indicizzazione, design mediocre, niente bookmark, navigazione
>> mediocre, niente stampa, niente caching
>
> uso interno aziendale, diciamo che l'indicizzazione tutto sommato non
> č fondamentale, la navigazione la imponi come tale ai dipendenti, per
> la stampa ti inventi qualcosa...
>
Ma qual'č il vantaggio? E comunque per un sito web generico non č
ammissibile.
john
>
> Ma tu ti qualifichi come utente finale? Perchč allora capisco tutto. La
> tua esperienza con *un sito* con i frameset č positiva e quindi
> categorizzi il fatto che i frameset sono perfetti.
>
in una discussione su un thread si scrivono tante parole che messe tutte
assieme, anche se rappesentano risposte a persone diverse, potrebbero
dare una idea sbagliata nel complesso.
- io in quello che sto facendo adesso 'DEVO' immedesimarmi nell'utente
finale. Perchč in ogni pagina che produco penso immediatamente
all'impatto visivo ceh dá all'utente.
Io voglio vendere un prodotto. Voglio che la mia pagina 'stimoli'
l'osservatore e lo invogli a proseguire nella navigazione del mio sito.
Per combinazione programmo anche web (anche se da principiante che
conosce solo le cose basilari).
Quindi sono 'user' e 'programmer' allo stesso tempo.
> Peccato che ci siano ennemila altre situazioni, cirscostanze, siti,
> utenti, utonti, per i quali i frameset non vanno bene.
Io penso che milioni di 'utenti' non siano nemmeno coscienti se uno usa
frames o CSS. Solo chi programma web potrebbe farlo.
>
> Ciň che tu consideri come aspetto positivo dei frameset puň essere
> benissimo replicato con altre 'tecnologie' che perň non si portano
> dietro i problemi (che tu ti ostini a non vedere, nonostante ti siano
> stati indicati) dei frameset.
>
Sě, sě, ci credo. Ho accettato l'idea. Non č piů in discussione la
faccenda frames.
Ora che sono informato che esistono altre cose che permettono di fare la
stessa cosa e che non sono cosě controverse come i frames, mi convertirň
senzaltro a quelle.
Non ho certamente l'intenzione di fare una crociata 'pro' frames, quando
tutta la categoria dei professionisti č contro.
Ci mancherebbe. Basta solo conoscerle le cose, e poi ci si sa regolare.
Paolo De Dionigi
> filippo schrieb:
>
>> Ma anche no.
>> Perchè perdere tempo a ottimizzare codice e testo nelle pagine,
>> scrivere e non copincollare, mettere gli alt in tutte le immagini?
>> Un bel META con "'azzo, 'iga, 'ulo, 'onache_che_trombano' e i motori
>> di ricerca schiafferano il mio sito in cima alle ricerche ('chè tanto
>> si sa che l'utente non può usare il mouse per scrollare perchè la mano
>> la sta usando ...per scrollare qualcos'altro)
>>
>
> Allora hai confermato che i META sono una ca§§ata che dovrebbe essere
> eliminata.
> Se il motore di ricerca *in ogni modo* investiga il tuo sito, perchè
> permettere l'esistenza dei META ?? No ne vedo la ragione.
Perchè non esiste un solo motore, perchè ogni motore opera in modo più o
meno diverso, perchè *il* motore ieri le considerava, oggi no, domani
chissà, perchè oltre all'indicizzazione esiste anche la SERP e title
(sempre) e description (quasi sempre in home, così così nelle
sottopagine) vengono usate appunto nella SERP.
Diciamo che le keywords servono un po' a poco (per google) però non sono
completamente ignorate, perchè vengono valutate per capire se chi ha
creato la pagina è un idiota che sta cercando di fregare Google.
Inoltre, fortunatamente, non esiste nessuno che possa impedire di usare
i META, sta a chi sviluppa capire come evolvono gli strumenti che usa
per il proprio lavoro.
P.S. in genere in informatica per questioni di retrocompatibilità non si
cassa nulla di punto in bianco, ma si tende a deprecare, così persone (e
applicazioni) hanno tempo e modo di adeguarsi senza grossi traumi.
john
>> Penso che solo uno schizofrenico potrebbe programmare in assembler al
>> giorno d'oggi.
>
> Dipende sempre dal contesto e dalla specifica esigenza. Esistono ancora
> situazioni un cui ha molto senso.
Forse sbaglio, ma visto che anche per gli embedde system si usa
comunemente il C/C++ (oggi si chiama così) non riesco ad immaginarmi
una situazione in cui uno abbia assolutamente la necessitá di
programmare in assembler.
Forse per cose sperimentali, magari un test-bench di un nuovo
processore...boh....
l...@email.it
> ...cose che succedono normalmente (istruzioni per telefono) quando vuoi
> trovare qualcosa sul sito dell'università, o perfino sul sito di
> Matlab... :-)))
eh, vuol dire che non sono siti fatti tanto bene...
> D'altro canto però meglio lasciare che l'utente 'decida lui' in quale
> categoria esssere classificcato, piuttosto che andare a spulciare ogni
> pagina per vedere 'veramente' cosa fa lui, no ? Anche perchè certe
> classificazioni sono difficili da decidere.
no: si parte dal presupposto (giustificatissimo) che il realizzatore
della pagina sia in malafede, perché il posizionamento e il
cliccamento di una pagina sono soldi. se il realizzatore della pagina
è in buona fede, deve fidarsi che il motore di ricerca classifichi e
faccia lui una "spettrografia" (chiamiamola così) del contenuto della
pagina secondo i suoi criteri oggettivi, non secondo i desiderata del
realizzatore.
il motore di ricerca deve tutelare coloro i quali lo usano per trovare
davvero quello che cercano, non per farsi ingannare dalle finte
promesse di un realizzatore. se il motore di ricerca tradisse le
aspettative dei suoi utilizzatori fidandosi dei realizzatori,
perderebbe utilizzatori, i quali lo usano per cercare una cosa ma
magari ne troverebbero un'altra prché lo sviluppatore fa il furbo coi
meta. quindi nel dubbio non si fida e fa bene.
> Comunque questa è una pura faccenda di opinioni.
> Io sono del parere che se una cosa 'non è buona e giusta' bisogna
> eliminarla tout-court.
> Invece di 'deprecare' le cose, bisognerebbe non lasciare la scelta ed il
> problema è eliminato.
eh, ma materialmente come fai a non lasciare scelta? voglio dire, un
bel giorno lo stato italiano ha deciso che non si fuma nei ristoranti
(non attrezzati ecc.). se uno fuma in un ristorante si chiama la
polizia. ma se anche il w3c volesse vietare davvero qualcosa invece
che deprecarlo, che strumenti coercitivi avrebbe?
> > è come se ad un esame il prof chiedesse allo studente: "hai studiato?"
> > e lo studente rispondesse "sì, ho studiato molto e merito 30" e il
> > prof rispondesse "bene, allora ti segno 30". invece il motore di
> > ricerca dice "hai studiato? sì? e mo' ti interrogo".
>
> Perdita di tempo assoluta. Cosa che un motore di ricerca non si puo'
> permettere.
non è per nulla una perdita di tempo: è quello che serve al motore, ma
soprattutto ai suoi utenti (i quali abbandonerebbero il motore se non
ricevessero informazioni corrette provocando una perdita commerciale),
per catalogare davvero il contenuto di una pagina.
quanto al tempo, ormai è chi si vuole far catalogare che si mette in
coda e pazientemente aspetta che il motore di ricerca gli faccia il
favore di visitarlo. e quando il motore arriva farà anche bene a
fargli trovare dei percorsi chiari e puliti che gli permettano di
farsi un giro completo.
> > un div position fixed è molto più semplice di un frame.
>
> però qualcuno qui parlava che il 'refresh' lo potevi fare solo con Ajax.
> E qui entriamo in un altra cosa di cui non ho esperienza.
ma se il problema è ricaricare solo certe parti della pagina,
figuriamoci, su... mica stiamo ancora ai tempi delle connessioni a
300 baud che ricaricare tutta una pagina o ricaricarne solo metà
faceva differenza... a parte il fatto che c'è la cache che sveltisce
ulteriormente le operazioni.
ajax lasciamolo per gli aggiornamenti in tempo reale e cose del
genere.
> Vabbé, adesso conosco l'alternativa del CSS e penso di impararmi bene
> quella. Così eliminerò i frames.
bravo! that's the spirit! :-)
> Ma per me significa dover cambiare circa un centinaio di pagine.
> E sinceramente non ho voglia di farlo *adesso* perchè non ne ho il tempo.
per carità, capisco benissimo. (pensa se adesso il w3c e produttori
di browser si mettono d'accordo e dicono "mmmh, questo john ha avuto
una buona idea... sai che c'è? vietiamo *davvero* i frame!" :-) ).
ma ora dimmi una cosa: sono tutte pagine statiche? non prendono i
loro contenuti da un db? perché qui si aprirebbe un altro
bell'argomento...
> Sì, ma come dico a un div di 'spostarsi a destra' e all'altro di
> 'spostzarsi a sinistra' sullo stesso piano ???
position: relative; right: [di quanto si deve spostare]px;
position: relative; left: [di quanto si deve spostare]px;
> E cos'è esattamente questa storia del 'refresh' ??
mah! questa non l'ho capita.
filippo
> Non è compito di un motore di ricerca fare il detective e vedere se tu
> dici la verità.
http://googleitalia.blogspot.com/2009/04/guida-introduttiva-di-google.html
Scarica il pdf e dagli un'occhiata.
> Certo, l'immediatezza è relativa all'esperienza. Ma l'esperienza è anche
> relativa all'immmediatezza in cui si recepiscono le cose, se sono
> difficili o facili da imparare.
Le "cose" nel caso siano specifiche e/o linguaggi, best pratice e altro
inerente il proprio lavoro, sono da imparare e basta. "Facile" e
"difficile" dipende dal background di ciascuno di noi.
Immediato è ciò che sai, che conosci, che hai acquisito.
> prima di Frontpage usavo due software in parallelo : Notepad e un
> browser. Dovevo editare con Notepad, salvare, passare al browser,
> cliccare sul refresh (che non funziona mai alla prima per via del cache
> che mantiene la pagina precedente).
>
> Se questo è 'lavorare professionalmente' io sono un cinese.
>
> Con Frontpage almeno tutto diventa più veloce. Salvo purtroppo le
> centinaia di codice generato (spesso alla Membro di Segugio, va detto
> onestamente).
Dover riscrivere centinaia di pagine perchè si è progettato male il sito,
ri-controllare decine e decine di link, pagine malformate e/o non valide,
lontananza (eufemismo) dalle indicazioni di accessibilità (importante se
lavori per la PA), ecco alcuni motivi per cui frontpage non è deprecato,
fa proprio schifo.
Ribadisco: gli editor visuali con l'html mi hanno sempre convinto poco,
per lavorare e avere il controllo del proprio codice preferisco usare
editor di tipo testuale.
Io uso Quanta plus, un ottimo editor che integra un visualizzatore di
anteprima, il completamento automatico dei tag, il controllo sintattico
automatico, supporto ai linguaggi di markup da asp a xlm passando per
ruby, l'autocomposizione di tabelle, form, dei DTD, ecc.
Poi, una rapida ricerca con google porta a questi risultati, per windows:
UltraEdit Shareware Editor avanzato ideale per creare e modificare file
nei formati HTML e HEX
PilotEdit Lite Freeware File editor gratuito
Notepad++ Portable Open source Versione portable dell'editor testuale con
funzionalità avanzate per lo sviluppo di pagine web nel formato HTML
OmegaEdit Editor testuale che permette di creare e modificare pagine web
nei linguaggi HTML e PHP o di realizzare fogli di stile
CoffeeCup Free HTML Editor Freeware Editor visuale gratuito con integrato
un client FTP per l'upload delle pagine sul server
Crimson Editor Freeware .....
Mi fermo alla lettera "C".
Se si conosce il linguaggio, una volta appreso ad utilizzare l'editor
(mezza giornata?), si diventa molto, molto produttivi.
ciao
Filippo B.
--
http://www.danzainsieme.it
http://www.boschetti.info
l...@email.it
wrote:
> Può darsi che frame in inglese sia maschile (non ci ho mai fatto caso)
> ma in italiano cornice è femminile, quindi non è così fuor di luogo
mettiamola così: frame vuol dire anche telaio, e frameset è un insieme
di telai...
john
>
> no: si parte dal presupposto (giustificatissimo) che il realizzatore
> della pagina sia in malafede, perch� il posizionamento e il
> cliccamento di una pagina sono soldi. se il realizzatore della pagina
> � in buona fede, deve fidarsi che il motore di ricerca classifichi e
> faccia lui una "spettrografia" (chiamiamola cos�) del contenuto della
> pagina secondo i suoi criteri oggettivi, non secondo i desiderata del
> realizzatore.
>
Perfetto. Dopo tutte queste buone ragioni mai pi� spender� il mio tempo
a includere META statements. Lascer� che Google mi 'classifichi' lui.
(Mi chiedo solo perch� Frontpage continua a farlo...)
>
>
>> Vabb�, adesso conosco l'alternativa del CSS e penso di impararmi bene
>> quella. Cos� eliminer� i frames.
>
> bravo! that's the spirit! :-)
>
>> Ma per me significa dover cambiare circa un centinaio di pagine.
>> E sinceramente non ho voglia di farlo *adesso* perch� non ne ho il tempo.
>
> ma ora dimmi una cosa: sono tutte pagine statiche? non prendono i
> loro contenuti da un db? perch� qui si aprirebbe un altro
> bell'argomento...
>
No, sono pagine statiche.
Moltiplicate per quattro perch� in quattro lingue diverse.
Ma sempre statiche sono.
Quindi un PHP+MySQL non mi aiuterebbe.
Ciao.
John.
Cooper
news:hvd1t8$cvr$1...@nnrp.linuxfan.it...
> - io in quello che sto facendo adesso 'DEVO' immedesimarmi nell'utente
>
> Io voglio vendere un prodotto. Voglio che la mia pagina 'stimoli'
> l'osservatore e lo invogli a proseguire nella navigazione del mio sito.
>
questione meramente pratica trova maggiore spazio in un newsgroup di
marketing dove come hai anche tu detto poc'anzi... si cerca di stimolare il
cliente finale ad acquistare il prodotto.
Avendo questo newsgroup una natura tecnica e non commerciale è chiaro che
chi sviluppa non si occupa anche di marketing, quindi ha una visione
giustamente più competente al ruolo che egli ricopre come sviluppatore e non
come promotore :) Ragion per cui, in questo newsgroup come hai notato
l'aspetto estetico assume una rilevanza marginale rispetto a quello tecnico.
Leggendo più avanti ho preso atto che hai "corretto il tiro" e questo è un
passo avanti sicuramente :)
> Io penso che milioni di 'utenti' non siano nemmeno coscienti se uno usa
> frames o CSS. Solo chi programma web potrebbe farlo.
>
Infatti è cosi esattamente come hai detto; ma ciò non toglie che uno debba
lavorare usando una metodologia vecchia piuttosto una nuova :) è un po' come
dire.... io programmo in visual basic... però uso vb1 perchè mi sono sempre
trovato bene con vb1 e quindi non voglio usare vb6 :-)
Qui chiaro, io estremizzo un po', però l'idea in qualche modo rende; se vb1
= frame e vb6 = css è un po' come dire... che si preferisce usare vb1 a vb6
:) però sappiamo tutti che vb6 è "superiore" a vb1. Chiaramente adesso ci
sono prodotti migliori di vb6 ma questo è un altro discorso eppure ancora
oggi ci sono soggetti che vogliono continuare a usare vb6.... perchè lo
trovano migliore etc e tu questo lo sai molto bene credo eheh :) non altro
perchè sono convinti che vb6 compilando in codice macchina nativo sia più
sicuro rispetto a .net che meta-compila... e quindi con poca fatica si può
decompilare il tutto.
Ma questa è un altra storia, andiamo troppo ot.
john
>
> Se si conosce il linguaggio, una volta appreso ad utilizzare l'editor
> (mezza giornata?), si diventa molto, molto produttivi.
>
beh, vedo che è ora di uscire dal torpore in cui sono vissuto finora
ed uscire a conoscere e provare cose nuove... :-)))
Cooper
> (Mi chiedo solo perchè Frontpage continua a farlo...)
>
Forse perchè è ancora aggiornato a una ventina di anni fa? :)
> No, sono pagine statiche.
> Moltiplicate per quattro perché in quattro lingue diverse.
> Ma sempre statiche sono.
>
> Quindi un PHP+MySQL non mi aiuterebbe.
>
Io penso che ti aiuterebbe molto. Perchè potresti tranquillamente mettere i
contenuti dentro il db e fare una unica pagina (template) dove a seconda
della lingua selezionata, viene caricata dal db dinamicamente tramite php la
traduzione corrispondente del testo.
E come vedi questo principio lo si può applicare anche a N lingue diverse,
senza modificare il contenuto della pagina base e soprattutto senza
interferire con il codice php; tutto semplicemente facendo delle semplici
query al db.
Cooper
news:f4f8dd48-b484-4dd8...@k39g2000yqd.googlegroups.com...>> Puň darsi che frame in inglese sia maschile (non ci ho mai fatto caso)
>> ma in italiano cornice č femminile, quindi non č cosě fuor di luogo
>
> mettiamola cosě: frame vuol dire anche telaio, e frameset č un insieme
> di telai...
>
Io sarei piů propenso a tradurre frame come "struttura" e frameset come
"layout, template" in gergo moderno; infatti un frameset che ha una pagina
per l'header, una per il footer, una per le colonne sx e dx si avvicina di
piů a quello che noi chiamiamo oggi il layout della pagina web o template.
john
> Io penso che ti aiuterebbe molto. Perchè potresti tranquillamente
> mettere i contenuti dentro il db e fare una unica pagina (template) dove
> a seconda della lingua selezionata, viene caricata dal db dinamicamente
> tramite php la traduzione corrispondente del testo.
> E come vedi questo principio lo si può applicare anche a N lingue
> diverse, senza modificare il contenuto della pagina base e soprattutto
> senza interferire con il codice php; tutto semplicemente facendo delle
> semplici query al db.
>
Analizziamo esattamente la sequenza del processo :
attualmente ho un index.html che mi mostra una prima pagina
1) questa pagina dà l'opzione di continuare in quattro lingue, cioè
quattro siti diversi.
2) cliccando su una lingua, viene indirizzato ad un thread (ad es.
'inglese')
3) da lì continua la navigazione.
CHE COSA risparmio trasportando il tutto in PHP + MySQL ??
Solamente il passaggio dal 2) al 3).
Il numero di pagine resta sempre lo stesso. Lo sforzo per crearle lo
stesso. Quindi lo spazio sul server resterebbe lo stesso.
Da considerare che ogli lingua ha la sua 'versione speciale' della
pagina. Non sono tutte 'esattamente' uguali.
Su una lingua potrei voler mettere una foto in più, un commento diveso,
più lungo.
Quindi il lavoro per la creazione del sito sarebbe lo stesso dal punto
di vista delle pagine. PERÒ :
- mi costerebbe di più, perchè per l'affitto di un MySQL mi costa di più
al webspace provider
- sarebbe più lento per lo user, per il lavoro di 'assemblamento' delle
pagine fatte in PHP (o asp, o jsp, o altro)
Quindi mi sconvolgerebbe tutto il sistema presente, senza apportare
nessun vantaggio 'tangibile', una volta fatto illavoro.
Dovessi cominciare oggi a fare il lavoro di planning, probabilmente
opterei per questa soluzione. Senzaltro, quando avrò imparato di più in
materia, mi sentirò abbastanza sicuro da pianificare dall'inizio
un sito inquesto modo.
Daniele Orlandi
>
> Forse sbaglio, ma visto che anche per gli embedde system si usa
> comunemente il C/C++ (oggi si chiama così)
Cosa si chiama così?
C e C++ sono due linguaggi diversi. Il primo è un bel linguaggio, il secondo
no. IMO ovviamente.
> non riesco ad immaginarmi
> una situazione in cui uno abbia assolutamente la necessitá di
> programmare in assembler.
A parte che si chiama assembly il linguaggio. Se guardi il sorgente di un
kernel trovi una moderata quantità di assembly.
In alcuni punti è solo un'ottimizzazione per fare velocemente operazioni
critiche, in altri è indispensabile (locking, gestione della vm, etc..).
In userland serve principalmente per scrivere codice veloce e per usare
istruzioni che un compilatore non userebbe e cose del genere.
Ciao,
--
Daniele Orlandi つづく
D.Campagna
> Il 17/06/2010 10.36, l...@email.it ha scritto:
>> On 17 Giu, 09:35, Paolo De Dionigi<PaoloDeDion...@gmail.com> wrote:
>>>
>>> Sono lampanti i motivi per cui i frameset non sono accettabili e lo sono
>>> appunto da almeno quindici anni.
>>>
>>> evidenziare:
>>>
>>> niente indicizzazione, design mediocre, niente bookmark, navigazione
>>> mediocre, niente stampa, niente caching
>>
>> uso interno aziendale, diciamo che l'indicizzazione tutto sommato non
>> la stampa ti inventi qualcosa...
>>
>
> ammissibile.
In effetti mi ero dimenticato di precisare che trovo comodissimi i
frames, sì, ma soprattutto nell'ambito di applicazioni intranet, dove
non esiste nessuno dei problemi che sono stati qui citati - veri o
presunti, vorrei dire - e dove ho il controllo sul server, sulle pagine
HTML e anche volendo sul browser che gli utenti utilizzano (anche se qui
cerco di fare le cose per bene e di realizzare pagine compatibili).
Per quanto riguarda quei pochi siti che ho realizzato e/o sto
realizzando, come detto aderisco al prudente costume italico di
adeguarmi a quello che fanno gli altri, anche dove non sono molto
d'accordo. Ma in questo thread, che poi si è ampliato, sono state dette
un bel po' di sciocchezze sull'estetica e sull'usabilità che c'entrano
poco o nulla con la scelta tecnica di usare o non usare i frames.
Sto realizzando una web-application in cui l'approccio frame-centrico è
secondo me essenziale per ottenere efficienza e rapidità di utilizzo.
Ho l'impressione che qui molti ripetano a pappagallo quello che i
cosiddetti guru ci elargiscono, ma senza metterci molto pensiero
originale. Del resto è più facile avere la libertà di parola che la
libertà di pensiero!
Vorrei che qualcuno mi spiegasse per esempio nel caso di un piccolo sito
di poche pagine di una aziendina che intende semplicemente presentare i
suoi prodotti o servizi e fornire le informazioni di contatto qual è il
problema per l'utente: mette nei preferiti la pagina iniziale e poi
eventualmente clicca sul bottone "contatti". Embe'?
Qualcuno qui dice che i contenuti prevalgono sull'estetica, che è una
colossale scemenza, altrimenti perché mai ci sarebbero quei mostruosi
filmati flash da decine di Mb in certi siti, alcuni dei quali privi
anche del bottone "salta l'introduzione" (il link più cliccato su
Internet, scommetto) e i CSS e tutto il resto che serve solo per
migliorare l'estetica e l'impatto visivo delle pagine?
Qualcun altro obbietta parlando di PDA con schermino 320X200... ma che
stiamo scherzando? Se si vuole raggiungere questa utenza si progettano
pagine apposite per questi dispositivi, non vedo perché uno dovrebbe
pretendere di vedere una pagina web concepita per un moderno computer su
un aggeggino con schermo da 3 pollici. E se lo fa sono fatti suoi.
E quanti allora pevedono l'accesso da parte di portatori di handicap,
stranieri dei più svariati idiomi, o anche solo da chi ha javascript
disabilitato, schermi monocromatici, flash o quicktime non installato,
PDA, cellulari ecc.? Alzi la mano chi realizza siti tenendo presenti
TUTTE le possibilità! Mica siamo tutti Google o Facebook, no? E poi i
costi dove li mettiamo? Se per mettere in linea quattro paginette che
saranno viste da un po' di gente nel mio paese dovessi prevedere cosa ne
penserà il coreano sordo che accede con un telefonino, stiamo freschi.
Mi immagino già un listino: quattro paginette: 8000 euro.
Ma ci rendiamo conto che un sacco di siti "istituzionali" (banche in
primis)usano jQuery e ti fanno caricare 70 Kb di script + immagini jpeg
+ filmati flash + chissà cos'altro, e poi il loro sito fa schifo da
quanto è lento, e sono più i giorni che è in manutenzione di quelli in
cui funziona (male)?
Ah ma loro sono in linea con le ultime direttive dell'industria web.
Dimenticavo.
Parliamo della vita reale, mica di futili argomentazioni che non
significano un tubo!
Il vero criterio essenziale è l'usabilità, cosa di cui si sono accorti
già negli US dove questo argomento è trattato da psicologi, non da
tecnici o programmatori, e questi ultimi vanno a seguire le conferenze
di usability per migliorare i loro siti. Quanti di voi si sono
documentati seriamente su questo argomento?
Probabilmente qui c'è gente che lavora per chi ha dei siti con centinaia
di pagine e deve raggiungere tutto il mondo con qualsiasi browser e
qualsiasi dispositivo e in qualsiasi lingua. Di sicuro non si possono
applicare gli stessi concetti per realtà completamente diverse.
Ma vi rendete conto che basta che l'utente ingrandisca i caratteri e una
buona metà delle pagine esistenti perde l'impaginazione come era stata
concepita dal web designer?
I frames sono l'ultimo dei problemi. Scusate lo sfogo.
Dan
Andrea
> - io in quello che sto facendo adesso 'DEVO' immedesimarmi nell'utente
> finale. Perchè in ogni pagina che produco penso immediatamente
> all'impatto visivo ceh dá all'utente.
Mi pare che tu ti stia immedesimando nel tuo utente finale ideale, che
potrebbe non coincidere con quello reale.
Hai fatto dei test di usabilità per stabilire che alla gente dà fastidio
scrollare le pagine? Se sì, su quanti casi ti basi? Su che device e a
che risoluzioni hai testato la tua soluzione?
Io posso essere d'accordo che scrollare una pagina con contenuto
chilometrico non sia il massimo, ma qui il problema è il contenuto, non
lo scrolling in se.
> Io voglio vendere un prodotto. Voglio che la mia pagina 'stimoli'
> l'osservatore e lo invogli a proseguire nella navigazione del mio sito.
Un po' quello che vogliono tutti. Fammi capire perché allora gli altri
non usano i frame e non sono tanto prevenuti con lo scrolling... o non
hanno capito niente, oppure quello che ritieni tu importante non lo è
poi così tanto.
--
MySQL and PHP are popular not because of their quality, but despite it.
john
>
> Cosa si chiama così?
> C e C++ sono due linguaggi diversi.
Il primo è un bel linguaggio, il secondo
> no. IMO ovviamente.
>
Il secondo è stato un tentativo di Bjarne Stroustrup di 'allargare' il C
per poterlo usare nell'object oriented programming.
Qualcosa di positivo il C++ lo deve avere se :
- é tuttora usato per grandi sistemi public domain (ad esempio in campo
di image processing per chirurgia ITK, VTK, IGSTK)
- è tuttora insegnato nelle università. Nelle lezioni di Software
engineering è universalmente usato per gli esercizi
- se fa scrivere "...molta gente sta riconvertendosi al C/C++
proveniente da Java..." (Jesse Liberty, "Teach Yourself C++ in 21 Days",
German Edition, 2005)
> A parte che si chiama assembly il linguaggio. Se guardi il sorgente di un
> kernel trovi una moderata quantità di assembly.
>
Ho imparato qualcosa di nuovo.
Io il linguaggio l'ho sempre visto riferito come 'Assembler',
descrivendo la parte 'mnemonica' del linguaggio macchina, di qualsiasi
hardware.
Assembly invece ad esempio è un nome che Visual Studio .NET dà
all'insieme dei parametri configurativi di un progetto.
Ma si impara sempre qualcosa di nuovo, vedo.
Daniele Orlandi
>
> Qualcosa di positivo il C++ lo deve avere se :
>
> - é tuttora usato per grandi sistemi public domain (ad esempio in campo
> di image processing per chirurgia ITK, VTK, IGSTK)
Questi argomenti non reggono. La qualità di un linguaggio (o di un alimenti,
vedi miliardi di mosche) non si giudica in funzione di quanti lo usano.
> - è tuttora insegnato nelle università. Nelle lezioni di Software
> engineering è universalmente usato per gli esercizi
E le università sono universalmente note per essere tutto fuorché vicine
allo stato dell'arte, eccetto forse in qualche piccola nicchia :)
> - se fa scrivere "...molta gente sta riconvertendosi al C/C++
> proveniente da Java..." (Jesse Liberty, "Teach Yourself C++ in 21 Days",
> German Edition, 2005)
Idem come sopra, il fatto che qualcuno ci scriva un libro non dimostra
nulla. Ci sono centinaia di libri su omeopatia, riflessologia plantare,
cristalloterapia... vado avanti?
--
Daniele Orlandi つづく
john
>
> Io posso essere d'accordo che scrollare una pagina con contenuto
> chilometrico non sia il massimo, ma qui il problema è il contenuto, non
> lo scrolling in se.
>
Veramente all'inizio del thread il problema erano i frames che non
venivano giustamente interpetati da Google Chrome.
Poi il discorso si è evoluto e fatto più interessante.
Alla fine, ora accetto l'idea che i frames sono obsoleti e non si devono
più usare, e vedrò quanto prima di adeguarmi con CSS.
> Un po' quello che vogliono tutti. Fammi capire perché allora gli altri
> non usano i frame e non sono tanto prevenuti con lo scrolling... o non
> hanno capito niente, oppure quello che ritieni tu importante non lo è
> poi così tanto.
>
Come dicevo, io usavo i frames per 'ignoranza', cioé per non conoscere
nessun'altra alternativa che mi facesse ottenere lo stesso effetto.
Per quanto riguarda lo scrolling : in effetti un file chilometrico dà
molto fastidio quando per tovare ove si deve andare a cliccar bisogna
scrollare alla fine del documento. In alto o in basso. Molto più comodo
avere dei link fissi a lato.
Detto questo, l'utente finale 'accetta tutto quello che gli si propina'
senza osteggiarlo o essere critico : lui non sa unaa pippa di quello che
c'é 'sotto'.
Lo sanno solo i webmaster.
Ecco perchè sono venuto qui :-)))
john
>
> Idem come sopra, il fatto che qualcuno ci scriva un libro non dimostra
> nulla. Ci sono centinaia di libri su omeopatia, riflessologia plantare,
> cristalloterapia... vado avanti?
>
Certo, C'EST LA VIE. È la vita. :-))
Come quando Windows NT la vinse su OS/2 dell'IBM sebbene OS/2 fosse
molto migliore.
Come quando il VHS della JVC si guadagnò il monopolio del mercato video
mondiale, sebbene Beta della Sony e Video2000 della Philips/Telefunken
fossero di gran lunga migliori..
vado avanti ?? :-))))
E allora questo cosa ci insegna ?
filippo
> Vorrei che qualcuno mi spiegasse per esempio nel caso di un piccolo sito
> di poche pagine di una aziendina che intende semplicemente presentare i
> suoi prodotti o servizi e fornire le informazioni di contatto qual è il
> problema per l'utente: mette nei preferiti la pagina iniziale e poi
> eventualmente clicca sul bottone "contatti". Embe'?
Cerca con google "CRISTOF BHUNM".
La 1° voce ti rimanda a una pagina
http://www.emilianabiliardi.com/biliardi_htm/antichi_htm/cristof_bhunm.htm
che è un frame.
Se clicchi su "torna indietro" che succede?
Ecco, questo è uno degli effetti dei frames.
(PS, 'sto sito lo conosco bene, è stato uno dei miei primi lavori sul
web, una decina d'anni fa, quindi accetto _ogni_ tipo di critica, perchè
fa abbastanza schifo - ma al cliente piace, musichetta inclusa).
> Qualcuno qui dice che i contenuti prevalgono sull'estetica, che è una
> colossale scemenza, altrimenti perché mai ci sarebbero quei mostruosi
> filmati flash da decine di Mb in certi siti, alcuni dei quali privi
> anche del bottone "salta l'introduzione" (il link più cliccato su
> Internet, scommetto) e i CSS e tutto il resto che serve solo per
> migliorare l'estetica e l'impatto visivo delle pagine?
Perchè ci sono un sacco di clienti imbecilli, mi sembra evidente. E
programmatori che li assecondano, ovviamente. Me incluso eh, non mi tiro
mica indietro (anche perchè le bollette non me le paga il W3C).
Tuttavia si cerca di spiegare, di far vedere le differenze, di evolvere
verso gli standard, verso la compatibilità, verso l'accessibilità (mai
provato a navigare un sito con i frames con un browser testuale, tipo
Lynx?)
> Qualcun altro obbietta parlando di PDA con schermino 320X200... ma che
> stiamo scherzando? Se si vuole raggiungere questa utenza si progettano
> pagine apposite per questi dispositivi, non vedo perché uno dovrebbe
> pretendere di vedere una pagina web concepita per un moderno computer su
> un aggeggino con schermo da 3 pollici. E se lo fa sono fatti suoi.
>
> E quanti allora pevedono l'accesso da parte di portatori di handicap,
Beh, c'è chi ci lavora con aziende/enti che _devono_ dare accesso alle
disabilità visive/uditive, per esempio.
> stranieri dei più svariati idiomi,
Parlo tre lingue, ho clienti in Spagna, Francia, Austria. E mica sono il
solo.
> o anche solo da chi ha javascript
> disabilitato, schermi monocromatici, flash o quicktime non installato,
> PDA, cellulari ecc.? Alzi la mano chi realizza siti tenendo presenti
> TUTTE le possibilità! Mica siamo tutti Google o Facebook, no? E poi i
> costi dove li mettiamo? Se per mettere in linea quattro paginette che
> saranno viste da un po' di gente nel mio paese dovessi prevedere cosa ne
> penserà il coreano sordo che accede con un telefonino, stiamo freschi.
> Mi immagino già un listino: quattro paginette: 8000 euro.
Stai facendo confusione. In generale, *SE* le esigenze sono queste, sì, i
costi ci sono, ovviamente. Solo i webmastella fanno siti completi con
frontpage a 200 euro tutto incluso.
Tuttavia, si può adeguare alla maggioranza dei casi "semplici" una
programmazione il più possibile "pulita", definendo un proprio framework
o utilizzando strumenti come i CMS (che per una grandissima parte di
utenza sono più che sufficienti), dedicando magari il proprio tempo alla
personalizzazione/sviluppo di moduli complementari o alla grafica
(=estetica) del sito stesso.
Molti CMS inoltre, oltre a essere tableless, frameless, rispettosi degli
standard, offrono un modello di template piuttosto facile da
personalizzare, oltre ad una certa elasticità grazie ai molti moduli
opzionali (o alla possibilità di implementarne facilmente dei nuovi, se
necessario).
> Ma ci rendiamo conto che un sacco di siti "istituzionali"
Per la PA è obbligatorio seguire le indicazioni per l'accessibilità.
> Il vero criterio essenziale è l'usabilità, cosa di cui si sono accorti
> già negli US dove questo argomento è trattato da psicologi, non da
> tecnici o programmatori, e questi ultimi vanno a seguire le conferenze
> di usability per migliorare i loro siti. Quanti di voi si sono
> documentati seriamente su questo argomento?
Mi interessa, cerco di leggere quanto trovo in e off line.
E ascolto le opinioni degli altri, sempre utili.
> Ma vi rendete conto che basta che l'utente ingrandisca i caratteri e una
> buona metà delle pagine esistenti perde l'impaginazione come era stata
> concepita dal web designer?
Certo che sì. Ed è uno dei motivi per cui bisognerebbe separare la logica
dalla presentazione... ma mi sembra di averlo già scritto, qualche ora
fa, in un altro post.
> I frames sono l'ultimo dei problemi. Scusate lo sfogo.
I frames fanno parte dei problemi.
Paolo De Dionigi
> Paolo De Dionigi ha scritto:
>> Il 17/06/2010 10.36, l...@email.it ha scritto:
>>> On 17 Giu, 09:35, Paolo De Dionigi<PaoloDeDion...@gmail.com> wrote:
>>>>
>>>> Sono lampanti i motivi per cui i frameset non sono accettabili e lo
>>>> sono
>>>> appunto da almeno quindici anni.
>>>>
>>>> I motivi sono ben riassunti da Nicholas e li ripeto così giusto per
>>>> evidenziare:
>>>>
>>>> niente indicizzazione, design mediocre, niente bookmark, navigazione
>>>> mediocre, niente stampa, niente caching
>>>
>>> d'altro canto, se si tratta di applicazioni diciamo così intranet, ad
>>> uso interno aziendale, diciamo che l'indicizzazione tutto sommato non
>>> è fondamentale, la navigazione la imponi come tale ai dipendenti, per
>>> la stampa ti inventi qualcosa...
>>>
>>
>> Ma qual'è il vantaggio? E comunque per un sito web generico non è
>> ammissibile.
>
> In effetti mi ero dimenticato di precisare che trovo comodissimi i
> frames, sì, ma soprattutto nell'ambito di applicazioni intranet, dove
> non esiste nessuno dei problemi che sono stati qui citati - veri o
> presunti, vorrei dire - e dove ho il controllo sul server, sulle pagine
> HTML e anche volendo sul browser che gli utenti utilizzano (anche se qui
> cerco di fare le cose per bene e di realizzare pagine compatibili).
Beh, si parlava di sito web, non di applicazione che deve girare su una
intranet.
> Per quanto riguarda quei pochi siti che ho realizzato e/o sto
> realizzando, come detto aderisco al prudente costume italico di
> adeguarmi a quello che fanno gli altri, anche dove non sono molto
> d'accordo. Ma in questo thread, che poi si è ampliato, sono state dette
> un bel po' di sciocchezze sull'estetica e sull'usabilità che c'entrano
> poco o nulla con la scelta tecnica di usare o non usare i frames.
I frames hanno effetti negativi sull'estetica (già hanno spiegato ad
esempio che le barre di scorrimento non sono gestibili e aggiungo io che
vorrei vederti a far passare agevolmente un qualsiasi 'oggetto estetico'
(un'immagine ad esempio) da un frame all'altro (niente movimento, chessò
un banale margin-left:-100.)
Sull'usabilità zero dei frameset poi, gli esempi si sprecano e ne ho già
scritto io e altri in questo thread.
Quali sono le sciocchezze?
> Sto realizzando una web-application in cui l'approccio frame-centrico è
> secondo me essenziale per ottenere efficienza e rapidità di utilizzo.
> Ho l'impressione che qui molti ripetano a pappagallo quello che i
> cosiddetti guru ci elargiscono, ma senza metterci molto pensiero
> originale. Del resto è più facile avere la libertà di parola che la
> libertà di pensiero!
Certo, come è più facile pure pensare che ciò che vale per se stessi
valga per tutto il mondo. Tipico concetto di chi ha una mente aperta e
una buona esperienza, già.
> Vorrei che qualcuno mi spiegasse per esempio nel caso di un piccolo sito
> di poche pagine di una aziendina che intende semplicemente presentare i
> suoi prodotti o servizi e fornire le informazioni di contatto qual è il
> problema per l'utente: mette nei preferiti la pagina iniziale e poi
> eventualmente clicca sul bottone "contatti". Embe'?
Posso dirne solo una? A google non piacciono i frames. Punto. Motivo più
che sufficiente per abbandonarli.
> Qualcuno qui dice che i contenuti prevalgono sull'estetica, che è una
> colossale scemenza, altrimenti perché mai ci sarebbero quei mostruosi
> filmati flash da decine di Mb in certi siti, alcuni dei quali privi
> anche del bottone "salta l'introduzione" (il link più cliccato su
> Internet, scommetto) e i CSS e tutto il resto che serve solo per
> migliorare l'estetica e l'impatto visivo delle pagine?
Cioè? Il fatto che esistano degli idioti non significa che la natura
prediliga lo sviluppo degli idioti, anzi...
> Ma ci rendiamo conto che un sacco di siti "istituzionali" (banche in
> primis)usano jQuery e ti fanno caricare 70 Kb di script + immagini jpeg
> + filmati flash + chissà cos'altro, e poi il loro sito fa schifo da
> quanto è lento, e sono più i giorni che è in manutenzione di quelli in
> cui funziona (male)?
> Ah ma loro sono in linea con le ultime direttive dell'industria web.
> Dimenticavo.
Ma questo cosa diavolo significa?
Usare jquery non significa mica essere in linea (ecc..) e se il sito non
ha ragioni sufficienti per essere lento allora significa semplicemente
che è fatto male.
Poi come esempio hai scelto proprio il settore che notoriamente è un
burosauro nei confronti dell'informatica.
> Probabilmente qui c'è gente che lavora per chi ha dei siti con centinaia
> di pagine e deve raggiungere tutto il mondo con qualsiasi browser e
> qualsiasi dispositivo e in qualsiasi lingua. Di sicuro non si possono
> applicare gli stessi concetti per realtà completamente diverse.
Io lavoro su siti di 10 pagine e su siti su cui non ha senso (e non si
sa nemmeno) contare il numero di pagine, mono / multilingua, poco /
molto interessati ai devices utilizzati.
Ciò che imparo lavorando sui siti più esigenti mi è molto utile nel
semplificare il lavoro e migliorare i risultati anche per i siti minori.
> Ma vi rendete conto che basta che l'utente ingrandisca i caratteri e una
> buona metà delle pagine esistenti perde l'impaginazione come era stata
> concepita dal web designer?
> I frames sono l'ultimo dei problemi. Scusate lo sfogo.
E' evidente che abbiamo un'idea diversa del web.
Cooper
> Cooper schrieb:
>
>> Io penso che ti aiuterebbe molto. Perchè potresti tranquillamente mettere
>> i contenuti dentro il db e fare una unica pagina (template) dove a
>> seconda della lingua selezionata, viene caricata dal db dinamicamente
>> tramite php la traduzione corrispondente del testo.
>> E come vedi questo principio lo si può applicare anche a N lingue
>> diverse, senza modificare il contenuto della pagina base e soprattutto
>> senza interferire con il codice php; tutto semplicemente facendo delle
>> semplici query al db.
>>
>
> Analizziamo esattamente la sequenza del processo :
>
> attualmente ho un index.html che mi mostra una prima pagina
>
> 1) questa pagina dà l'opzione di continuare in quattro lingue, cioè
> quattro siti diversi.
>
> 2) cliccando su una lingua, viene indirizzato ad un thread (ad es.
> 'inglese')
>
> 3) da lì continua la navigazione.
>
> CHE COSA risparmio trasportando il tutto in PHP + MySQL ??
>
> Solamente il passaggio dal 2) al 3).
> Il numero di pagine resta sempre lo stesso. Lo sforzo per crearle lo
> stesso. Quindi lo spazio sul server resterebbe lo stesso.
>
1) Hai una unica pagina INDEX.PHP; per default carichi la pagina ad esempio
in lingua italiana.
In questa pagina puoi scegliere se usare tanti button quante le lingue
magari con la gif di una bandierina; oppure nel caso più generico un form
composto da due oggetti: una tlistbox dove elenchi le tue N lingue e un
tbutton.
Quando clicchi sul button ricarichi la tua pagina index.php e al reload
della pagina passi una querystring ad esempio: index.php?lang=en lato server
assegni hai la lingua selezionata quindi interroghi il db il quale ti
restituisce tutto il testo della pagina nella lingua selezionata.
Il vantaggio è che tu sfrutti soltanto una pagina per N lingue; e non hai
bisogno di ricorrere a N pagine per N lingue.
Il discorso si può estendere anche alle immagini; puoi benissimo caricare
nel tuo db anche le immagini e quindi differenziarle per lingua.
Per questioni pratiche è chiaro che però ti conviene mettere le immagini in
file separati, altrimenti il db diventa piuttosto pesantuccio in termini di
kilobytes.
> Da considerare che ogli lingua ha la sua 'versione speciale' della pagina.
> Non sono tutte 'esattamente' uguali.
> Su una lingua potrei voler mettere una foto in più, un commento diveso,
> più lungo.
>
Leggi sopra, ti ho anticipato anche questo; nel db puoi inserire tutto il
contenuto della pagina: testi e immagini. e perchè no; puoi anche inserire
il tuo css e quindi agendo sulla medesima pagina puoi anche cambiarne la
struttura grafica.
> Quindi il lavoro per la creazione del sito sarebbe lo stesso dal punto di
> vista delle pagine. PERÒ :
>
Come puoi vedere da quello che ti ho detto, non è cosi :)
> - mi costerebbe di più, perchè per l'affitto di un MySQL mi costa di più
> al webspace provider
>
Assolutamente falso; giusto per citare un esempio ogni fornitore di hosting
fornisce il supporto php+mysql a prezzi ridicoli e con una buona
performance. A titolo esemplificativo TOPHOST ti da 500 mb che puoi
ripartire come vuoi fra posta elettronica, spazio web, database mysql e ti
fornisce il supporto php; il tutto a 8,99 euro + iva; ci sono altri
fornitori con prezzi piu o meno alti, ma la differenza di costo non la fa
diciamo le caratteristiche del db, o la quota disco, ma piuttosto il
traffico e la banda a disposizione che ti forniscono.
Ma per un sito normalissimo che usa php e mysql con 500-700 visitatori
distribuiti in 24 ore un hosting tipo tophost a 10 euro l'anno va piu che
bene.
> - sarebbe più lento per lo user, per il lavoro di 'assemblamento' delle
> pagine fatte in PHP (o asp, o jsp, o altro)
>
> Quindi mi sconvolgerebbe tutto il sistema presente, senza apportare nessun
> vantaggio 'tangibile', una volta fatto illavoro.
>
Falso almeno per l'esempio di cui sopra delle lingue straniere. Quello che
dici è vero per delle applicazioni web più complesse come forum, chat, blog
etc. Ma nel tuo caso si parla di semplici script.
> Dovessi cominciare oggi a fare il lavoro di planning, probabilmente
> opterei per questa soluzione. Senzaltro, quando avrò imparato di più in
> materia, mi sentirò abbastanza sicuro da pianificare dall'inizio
> un sito inquesto modo.
>
Qui entriamo nei gusti personali, per cui non mi esprimo :)
john
> Se fosse tolto il supporto ai frames, quei siti internet non si
> vedrebbero pi� e verrebbe meno la compatibilit� verso il basso con i
> siti internet piu vecchi.
> Perch� complicarsi la vita in questo modo? Dal momento che il web si
> evolve, quello che � stato non ha motivo di essere cancellato, basta
> semplicemente non ricorrere pi� al vecchio metodo, ma abituarsi a usare
> il nuovo.
>
capisco quello che vuoi dire, ma questa metodica ha uno svantaggio :
c'� il pericolo che qualcuno USI le vecchie opzioni deprecate perch� magari
erano pi� facili da imparare, ignaro di tutti buoni motivi che vi erano
per deprecarle, o peggio, non sapendo che sono deprecate.
Le frames e questo thread sono un esempio.
Uno che si avvicina con entusiasmo ingenuo da principiante all'HTML e
compra il libro HTML 4.0, trova le frames e gli esempi e NON STA SCRITTO
da nessuna parte (sul libro) che sono sconsigliate.
Quindi lui le usa, magari fino a che non trova un browser come Google
Chrome che le 'maltratta'.
Ecco cosa succede.
Allora � meglio fare come Microsoft : in virt� del tuo esempio
dell'ereditariet�, prova a far leggere un progetto .vbproj VB6 su Visual
Studio .NET. e vedi se � cos� tollerante e compatibile 'backwards'.
Col ka��o.
Ti d� tanti di quegli errori che ti passa la voglia. Ha molto pi� senso
'cominciare a giocare' direttamente in VB .NET, come ho fatto io, ed
abituarsi alla 'nuova vita'.
Se si fa cos�, vedi che le cattive abitudini non si perpetuano.
> Su questo siamo d'accordo, ma non ti scordare la compatibilit� verso il
> basso che nel caso dei vestiti non esiste e quindi il tuo paragone �
> privo di senso nel caso specifico.
>
Pensierino cattivo : se di colpo sparisse la compatibilit� verso il
basso, ecco che migliaia di webmaster disoccupati avrebbero ancora per
qualche tempo una occupazione... :-)))
Mi ricorda un presentatore di una TV in Germania
che stava intervistando un riparatore di lavatrici, il quale
consigliava di usare il Calgon, perch� 'allungava la vita delle
lavatrici'. Ad un certo punto gli fa la domanda da un milione di dollari :
'Ma se non vado errato, lei 'vive' perch� le lavatrici si rompono,
vero ? Se l'immagina se non si rompono pi�' ???
Quello rest� l� rimbambito e non sapeva pi� cosa rispondere. :-)))
john
>>
> Sul piano visivo ed estetico, si possono ottenere gli stessi risultati
> di una struttura a frames senza farne uso; ma semplicemente ricorrendo
> all'uso di css.
Ottima cosa. Mi c'� voluto un thread e due giorni per capirlo, ma mo'
sono convertito :-))
Daniele Orlandi
>
> Allora è meglio fare come Microsoft
Microsoft quale? Quella che ha IMPEDITO l'evoluzione del web con IE bacato e
ignorante di tutte le nuove tecnologie?
Per non citare tutto il resto!
john, se sei un troll sei bravo, ma attento che porta male :)
--
Daniele Orlandi つづく
Gabriele - onenet
> ngw schrieb:
>
> > L'importante è che capisci il costo: frame = niente indicizzazione,
> > design mediocre, niente bookmark, navigazione mediocre, niente stampa,
>
> Se tutte le argomentazioni nella tua requisitoria contro i frames sono
> vere (e non ne dubito assolutamente) allora perchè non si eliminano del
> tutto, così almeno non si ha l'opzione di usarli o meno ?
>
> Perchè lasciare una 'libertà' che provoca solo danni ?
Per una sorta di retrocompatibilità, penso.
>
> Li si leva completamente dagli standard ed è finita.
>
> Perchè, come si vede, se esistono, la gente (newbie come me) li usa
> perchè sono più 'intuitivi' e facili da usare.
Falso. Se uno inizia a creare pagine web nel 2010, non troverà alcuna
guida sui frame e quindi non li userà :)
ciao,
Gabriele
Cooper
"D.Campagna" <retsa...@danielecampagna.co.cc> ha scritto nel messaggio
news:hvd75d$orq$1...@nnrp-beta.newsland.it...
> In effetti mi ero dimenticato di precisare che trovo comodissimi i frames,
> sì, ma soprattutto nell'ambito di applicazioni intranet, dove non esiste
> nessuno dei problemi che sono stati qui citati - veri o presunti, vorrei
> dire - e dove ho il controllo sul server, sulle pagine HTML e anche
> volendo sul browser che gli utenti utilizzano (anche se qui cerco di fare
> le cose per bene e di realizzare pagine compatibili).
>
Caro collega, il problema non è se usare o meno i frames. Nessuno ti vieta
di usarli. Vuoi usarli? usali, nessuno ti dice che non puoi usarli.
Però sappi che l'uso dei frames è ormai superato da "strumenti" più
performanti e qualitativamente migliori, come appunto i fogli di stile.
Oggi a differenza di 10-20 anni fa, tutti i siti vengono realizzati
utilizzando xhtml o html5 (ancora nuovo e poco usato) accompagnati dai fogli
di stile (css) ed eventualmente AJAX (che alla fine non è altro che
javascript con "qualcosina" in più).
Ragione per cui se vuoi essere al passo con i tempi ti dovresti adattare a
questa nuova tendenza, altrimenti rimani pure al "vecchio stile", nessuno ti
dice nulla; semplicemente ti perdi qualcosa di veramente comodo; ma se di
questo, te ne frega ben poco, allora non ci perdi nulla, ma rimani ancorato
a quello che era il web di 15-20 anni fa, non a quello che è il web adesso.
> Per quanto riguarda quei pochi siti che ho realizzato e/o sto realizzando,
> come detto aderisco al prudente costume italico di adeguarmi a quello che
> fanno gli altri, anche dove non sono molto d'accordo. Ma in questo thread,
> che poi si è ampliato, sono state dette un bel po' di sciocchezze
> sull'estetica e sull'usabilità che c'entrano poco o nulla con la scelta
> tecnica di usare o non usare i frames.
>
Come detto sopra. Nessuno ti obbliga a cambiare le tue abitudini... se vuoi
continuare sul vecchio stile fai pure.
> Sto realizzando una web-application in cui l'approccio frame-centrico è
> secondo me essenziale per ottenere efficienza e rapidità di utilizzo.
> Ho l'impressione che qui molti ripetano a pappagallo quello che i
> cosiddetti guru ci elargiscono, ma senza metterci molto pensiero
> originale. Del resto è più facile avere la libertà di parola che la
> libertà di pensiero!
>
Purtroppo la tua impressione è sbagliata; ciascuno di noi parla sulla base
delle proprie esperienze, e non di quelle altrui.
A differenza dei linguaggi di programmazione vb, delphi, c, etc... il web si
evolve molto più rapidamente di quanto possiate credere.
> Vorrei che qualcuno mi spiegasse per esempio nel caso di un piccolo sito
> di poche pagine di una aziendina che intende semplicemente presentare i
> suoi prodotti o servizi e fornire le informazioni di contatto qual è il
> problema per l'utente: mette nei preferiti la pagina iniziale e poi
> eventualmente clicca sul bottone "contatti". Embe'?
>
Chi ha parlato di problemi? Io non vedo nessun problema. Ma se quella
piccola aziendina vuole essere trovata sul web... il motore di ricerca cosa
leggerà? leggerà la pagina contenitore dove è definito il frameset e non le
pagine che sono caricate nel frameset. Morale: il motore di ricerca non
troverà contenuti.
I meta-tag erano un ottimo strumento in passato, adesso non vengono più
usati; adesso hanno altre finalità rispetto a quello che era 15-20 anni fa.
> Qualcuno qui dice che i contenuti prevalgono sull'estetica, che è una
> colossale scemenza,
Punti di vista. Io distinguo una pagina web da una presentazione cartacea.
Tu probabilmente no. Ma sono gusti personali. non entro nel merito.
>altrimenti perché mai ci sarebbero quei mostruosi filmati flash da decine
>di Mb in certi siti, alcuni dei quali privi anche del bottone "salta
>l'introduzione" (il link più cliccato su Internet, scommetto) e i CSS e
>tutto il resto che serve solo per migliorare l'estetica e l'impatto visivo
>delle pagine?
>
Ottima osservazione: perchè chi ha fatto quelle porcherie evidentemente è
qualcuno che non capisce nulla di siti web.
Puoi realizzare delle piccole parti in flash per il sito, ma realizzare un
intero sito in flash è una porcheria punto.
E' chiaro che se il cliente vuole un sito in flash, chi se ne deve occupare
lo fa, io personalmente con chi mi è capitato l'ho messo al corrente dei pro
e contro che comporta l'uso di flash specie per un sito di natura aziendale;
poi l'ultima parola spetta a loro; ma nel frattempo almeno io ho la
coscienza a posto.
Poi attenzione, bisogna anche guardare la tipologia di target a cui si
riferisce un sito... per certi target di utenti un sito in flash può andare
bene, per altri no... quindi generalizzare sarebbe anche troppo azzardato.
Ma in linea di principio flash non è uno strumento per realizzare un sito
internet, o per lo meno non è stato concepito con questo intento.... che poi
permetta di farlo è un altro discorso.
> Qualcun altro obbietta parlando di PDA con schermino 320X200... ma che
> stiamo scherzando? Se si vuole raggiungere questa utenza si progettano
> pagine apposite per questi dispositivi, non vedo perché uno dovrebbe
> pretendere di vedere una pagina web concepita per un moderno computer su
> un aggeggino con schermo da 3 pollici. E se lo fa sono fatti suoi.
>
Progettando una pagina web secondo gli standard w3c quella medesima
paginetta la si può adattare perfettamente a qualsiasi dispositivo (pda
compreso), semplicemente modificando il css e lasciando inalterato tutto il
resto.
Con i frames questo non è possibile.
> E quanti allora pevedono l'accesso da parte di portatori di handicap,
> stranieri dei più svariati idiomi, o anche solo da chi ha javascript
> disabilitato, schermi monocromatici, flash o quicktime non installato,
> PDA, cellulari ecc.? Alzi la mano chi realizza siti tenendo presenti TUTTE
> le possibilità! Mica siamo tutti Google o Facebook, no? E poi i costi dove
> li mettiamo? Se per mettere in linea quattro paginette che saranno viste
> da un po' di gente nel mio paese dovessi prevedere cosa ne penserà il
> coreano sordo che accede con un telefonino, stiamo freschi.
> Mi immagino già un listino: quattro paginette: 8000 euro.
>
Un professionista del settore riesce a tenere conto di tutto questo senza
grossa fatica. Ti ripeto, rispettando gli standard w3c il 90% dei problemi
che hai citato sono già risolti.
> Ma ci rendiamo conto che un sacco di siti "istituzionali" (banche in
> primis)usano jQuery e ti fanno caricare 70 Kb di script + immagini jpeg +
> filmati flash + chissà cos'altro, e poi il loro sito fa schifo da quanto è
> lento, e sono più i giorni che è in manutenzione di quelli in cui funziona
> (male)?
>
E la colpa di chi è? della banca o delle istituzioni? NO la colpa è di
alcuni imbecilli che si fanno passare per professionisti del web facendosi
pagare due caffe e realizzando soltanto porcherie; poi come è stato ribadito
prima, l'utente finale è piu utonto che utente e per lui tutto fa brodo.
> Il vero criterio essenziale è l'usabilità, cosa di cui si sono accorti già
> negli US dove questo argomento è trattato da psicologi, non da tecnici o
> programmatori, e questi ultimi vanno a seguire le conferenze di usability
> per migliorare i loro siti. Quanti di voi si sono documentati seriamente
> su questo argomento?
>
parecchi.
> Probabilmente qui c'è gente che lavora per chi ha dei siti con centinaia
> di pagine e deve raggiungere tutto il mondo con qualsiasi browser e
> qualsiasi dispositivo e in qualsiasi lingua. Di sicuro non si possono
> applicare gli stessi concetti per realtà completamente diverse.
>
Ma chi te lo dice???? Se è necessario e se il cliente è disposto a pagare il
giusto per il lavoro niente è impossibile fatto salvo impedimenti di natura
tecnica ovviamente.
> Ma vi rendete conto che basta che l'utente ingrandisca i caratteri e una
> buona metà delle pagine esistenti perde l'impaginazione come era stata
> concepita dal web designer?
> I frames sono l'ultimo dei problemi. Scusate lo sfogo.
>
E la colpa del "professionista imbecille" che ha progettato male quella
pagina, non di altri.
john
>
>>
> E' l'impostazione di base che hai dato che è errata. Mettiamola cosi:
>
> 1) Hai una unica pagina INDEX.PHP; per default carichi la pagina ad
> esempio in lingua italiana.
> In questa pagina puoi scegliere se usare tanti button quante le lingue
> magari con la gif di una bandierina; oppure nel caso più generico un
> form composto da due oggetti: una tlistbox dove elenchi le tue N lingue
> e un tbutton.
> Quando clicchi sul button ricarichi la tua pagina index.php e al reload
> della pagina passi una querystring ad esempio: index.php?lang=en lato
> server assegni hai la lingua selezionata quindi interroghi il db il
> quale ti restituisce tutto il testo della pagina nella lingua selezionata.
> Il vantaggio è che tu sfrutti soltanto una pagina per N lingue; e non
> hai bisogno di ricorrere a N pagine per N lingue.
Ma 'il materiale' che forma la pagina è esistente e prende lo stesso spazio.
E' solo la struttua HTML per ogni pagina che verrebbe a mancar, ma
quella è minima rispetto al testo. Cioé i testi nelle varie lingue
devono esistere, le foto devono esistere, i layout differente deve esistere.
Se non erro, questa è la filosofia di 'content management system'
appunto solitamente basata su php+MySQL (o altro linguaggio di server
pages).
Comunque, resta il fatto che per me cambiare tutta la filosofia sarebbe
molto 'time comsuming e non mi permetterebbe di rispettare la deadline
di fine giugno per entrare sul merecato.
Ma lo farò senzaltro 'in parallelo' in modo da sostituire il vecchio
quando il nuovo è pronto, in modo 'trasparente' per gli user.
>>
> Assolutamente falso; giusto per citare un esempio ogni fornitore di
> hosting fornisce il supporto php+mysql a prezzi ridicoli e con una buona
> performance. A titolo esemplificativo TOPHOST ti da 500 mb che puoi
> ripartire come vuoi fra posta elettronica, spazio web, database mysql e
> ti fornisce il supporto php; il tutto a 8,99 euro + iva; ci sono altri
> fornitori con prezzi piu o meno alti, ma la differenza di costo non la
> fa diciamo le caratteristiche del db, o la quota disco, ma piuttosto il
> traffico e la banda a disposizione che ti forniscono.
Io sono da anni su un server tedesco, gestito da un conoscente. Ho
prezzi speciali, anche se più cari di quelli che hai menzionato.
ma finora mi sono trovato bene.
(Anche perchè se qualcosa non va lo raggiungo al cellulare anche al
sabato, e comincio a bestemmiare. E questo è un privilegio impagabile a
cui non intendo rinunciare e che non hanno tutti i clienti di
web-hosters <hahahahaha>)
> Ma per un sito normalissimo che usa php e mysql con 500-700 visitatori
> distribuiti in 24 ore un hosting tipo tophost a 10 euro l'anno va piu
> che bene.
>
senzaltro attraente. Devo farci un pensierino se resto in Italia in modo
permanente. Ma non lo so ancora.
john
> john wrote:
>> Allora è meglio fare come Microsoft
>
> Microsoft quale? Quella che ha IMPEDITO l'evoluzione del web con IE bacato e
> ignorante di tutte le nuove tecnologie?
>
Viviamo in un mondo di peccatori e ognuno fa i propri interessi... :-))
>
> john, se sei un troll sei bravo, ma attento che porta male :)
>
Lungi da me l'essere un troll. Ma devo ammettere che se qualcuno a me mi
darà da mangiare sarà Microsoft. :-))
Infatti su Linux posso solo farci la ricerca.....ma guadagnarci...ahimé....
Quando avrò racimolato un po' di soldi vendendo SW che gira su Windows,
allora mi comprerò un Apple e trasportertò il tutto.
Ma col tempo...con calma...
Cooper
news:<4c1a4389$0$31382$4faf...@reader1.news.tin.it>...
> Cerca con google "CRISTOF BHUNM".
> La 1° voce ti rimanda a una pagina
>
> http://www.emilianabiliardi.com/biliardi_htm/antichi_htm/cristof_bhunm.htm
>
> che è un frame.
> Se clicchi su "torna indietro" che succede?
> Ecco, questo è uno degli effetti dei frames.
> (PS, 'sto sito lo conosco bene, è stato uno dei miei primi lavori sul
> web, una decina d'anni fa, quindi accetto _ogni_ tipo di critica, perchè
> fa abbastanza schifo - ma al cliente piace, musichetta inclusa).
>
quelli che lo coloravano a destra e a sinistra per distinguere un frame
dall'altro.
> Perchè ci sono un sacco di clienti imbecilli, mi sembra evidente.
>
Ehi filippo calma :) non è il cliente a essere imbecille ma chi ci va dietro
pur di accaparrarsi la pagnotta, il cliente del resto non è tenuto a
conoscere tutto sul web. E' però tenuto ad essere informato di ciò che il
web offre, e questo lo può fare solo un bravo professionista.
>E
> programmatori che li assecondano, ovviamente.
>
Ecco appunto.
> Me incluso eh, non mi tiro
> mica indietro (anche perchè le bollette non me le paga il W3C).
>
Questo però è un altro discorso :)
> Tuttavia si cerca di spiegare, di far vedere le differenze, di evolvere
> verso gli standard, verso la compatibilità, verso l'accessibilità (mai
> provato a navigare un sito con i frames con un browser testuale, tipo
> Lynx?)
>
> Beh, c'è chi ci lavora con aziende/enti che _devono_ dare accesso alle
> disabilità visive/uditive, per esempio.
>
> > stranieri dei più svariati idiomi,
>
Stiamo dimenticando una cosa: i siti internet istituzionali sono obbligati a
rispettare la legge in materia (4/2004 se non ricordo male).
> Stai facendo confusione. In generale, *SE* le esigenze sono queste, sì, i
> costi ci sono, ovviamente. Solo i webmastella fanno siti completi con
> frontpage a 200 euro tutto incluso.
>
hahahahah, quoto.
> Tuttavia, si può adeguare alla maggioranza dei casi "semplici" una
> programmazione il più possibile "pulita", definendo un proprio framework
> o utilizzando strumenti come i CMS (che per una grandissima parte di
> utenza sono più che sufficienti), dedicando magari il proprio tempo alla
> personalizzazione/sviluppo di moduli complementari o alla grafica
> (=estetica) del sito stesso.
> Molti CMS inoltre, oltre a essere tableless, frameless, rispettosi degli
> standard, offrono un modello di template piuttosto facile da
> personalizzare, oltre ad una certa elasticità grazie ai molti moduli
> opzionali (o alla possibilità di implementarne facilmente dei nuovi, se
> necessario).
>
Appunto. Ma difficilmente chi si occupa di una agenzia immobiliare potrà
capire qualcosa di odontoiatria. Cosi pure chi si occupa di informatica
potrà capire qualcosa di cucina; fatto salvo per eventuali passioni
personali.
> Certo che sì. Ed è uno dei motivi per cui bisognerebbe separare la logica
> dalla presentazione... ma mi sembra di averlo già scritto, qualche ora
> fa, in un altro post.
>
Appunto.
john
>
> Falso. Se uno inizia a creare pagine web nel 2010, non troverà alcuna
> guida sui frame e quindi non li userà :)
>
>
Mi oppongo vostro onore !
Un libro comprato 2 mesi fa, libreria Feltrinelli, Genova
"HTML"
Collana I portatili
Mondadori.
Autore : Molly E. Holzschlag
Febbraio 2010
</START citazione>
Capitolo 9 : FRAME
I frame, nonostante la loro reputazione di instabilitá, possono
garantire un controllo preciso agli sviluppatori interessati a creare
strutture e sistemi di esplorazione precisi.
Gli sviluppatori di codice possono strutturare e bloccare diverse
sezioni di una pagina mentre utilizzano altre parti della stessa pagina
per visualizzare documenti collegati.
etc etc etc.
</END citazione>
Ci sono due pagine di 'apologia' dei frame. Altro che 'deprecati' !
E mo' dimmi che sono un troll.
Daniele Orlandi
>
> Lungi da me l'essere un troll. Ma devo ammettere che se qualcuno a me mi
> darà da mangiare sarà Microsoft. :-))
Non si era capito :)
> Infatti su Linux posso solo farci la ricerca.....ma
> guadagnarci...ahimé....
Vorrei dire una cattiveria ma mi astengo. Comunque io, su Linux, ci
guadagno.
> Quando avrò racimolato un po' di soldi vendendo SW che gira su Windows,
> allora mi comprerò un Apple e trasportertò il tutto.
Ah beh, dalla padella....
--
Daniele Orlandi つづく
Cooper
"john" <du...@agdp.de> ha scritto nel messaggio
news:hvdlkg$rtk$1...@nnrp.linuxfan.it...
> capisco quello che vuoi dire, ma questa metodica ha uno svantaggio :
> magari
> erano più facili da imparare, ignaro di tutti buoni motivi che vi erano
> per deprecarle, o peggio, non sapendo che sono deprecate.
>
> Uno che si avvicina con entusiasmo ingenuo da principiante all'HTML e
> compra il libro HTML 4.0, trova le frames e gli esempi e NON STA SCRITTO
> da nessuna parte (sul libro) che sono sconsigliate.
> Quindi lui le usa, magari fino a che non trova un browser come Google
> Chrome che le 'maltratta'.
>
Ma tu parli di un libro HTML 4.0 aggiornato a 15 anni fa :) heheeh è normale
che il libro ti parla dei frames... a quei tempi manco i css esistevano :)
> Allora è meglio fare come Microsoft : in virtù del tuo esempio
> dell'ereditarietà, prova a far leggere un progetto .vbproj VB6 su Visual
> Studio .NET. e vedi se è così tollerante e compatibile 'backwards'.
>
> Col ka§§o.
>
> Ti dà tanti di quegli errori che ti passa la voglia. Ha molto piú senso
> 'cominciare a giocare' direttamente in VB .NET, come ho fatto io, ed
> abituarsi alla 'nuova vita'.
>
> Se si fa così, vedi che le cattive abitudini non si perpetuano.
>
Hahaha vero, però non dimentichiamo una cosa che VB6 E VB.NET (ma in
generale un qualsiasi linguaggio .NET) è fondato su principi ben diversi da
quelli che erano in origina con VB6.
Di fatto ai tempi di vb6 concetti come programmazione a oggetti,
ereditarietà, polimorfismo erano alle origini ancora... quindi è
normalissimo che i progetti vb6 non fossero compatibili con vb.net tuttavia,
microsoft ricordo che ha incluso nel framework una libreria per rendere
compatibili anche i progetti vb6 con nuovo framework.
Prendendo .net come nuovo modello devi cambiare il tuo modo di ragionare di
sana pianta rispetto a ciò che era prima.
> Pensierino cattivo : se di colpo sparisse la compatibilità verso il basso,
> ecco che migliaia di webmaster disoccupati avrebbero ancora per qualche
> tempo una occupazione... :-)))
>
:-) infatti.
> Mi ricorda un presentatore di una TV in Germania
> che stava intervistando un riparatore di lavatrici, il quale consigliava
> di usare il Calgon, perchè 'allungava la vita delle lavatrici'. Ad un
> certo punto gli fa la domanda da un milione di dollari :
> 'Ma se non vado errato, lei 'vive' perchè le lavatrici si rompono,
> vero ? Se l'immagina se non si rompono più' ???
> Quello restò lì rimbambito e non sapeva più cosa rispondere. :-)))
>
:-) Non era calfort? o ricordo male io? Io di lavatrici e detersivi non me
ne intendo :D
Cooper
"Daniele Orlandi" <dan...@orlandi.com> ha scritto nel messaggio
news:prGdnYmIRdngxofR...@kpnqwest.it...
può essere realmente di trollaggine. E' un po' come dover parlare di ASP o
PHP oppure di LINUX e MICROSOFT... su chi è migliore e peggiore di questi
etc etc.
Evitiamo appunto di addentrarci in questo perchè non ha senso e perchè
andiamo fuori dall'argomento del thread :)
Alessandro Pellizzari
> Uno che si avvicina con entusiasmo ingenuo da principiante all'HTML e
> compra il libro HTML 4.0, trova le frames e gli esempi e NON STA SCRITTO
> da nessuna parte (sul libro) che sono sconsigliate. Quindi lui le usa,
> magari fino a che non trova un browser come Google Chrome che le
> 'maltratta'.
Quel libro e` scritto male, semplicemente.
Non e` che perche` e` su un libro qualsiasi vuol dire che va bene.
> Allora è meglio fare come Microsoft : in virtù del tuo esempio
> dell'ereditarietà, prova a far leggere un progetto .vbproj VB6 su Visual
> Studio .NET. e vedi se è così tollerante e compatibile 'backwards'.
>
> Col ka§§o.
Fai l'esempio sbagliato.
Prova a installarti VB6, svilupparci e fare un eseguibile.
Gira anche su Windows 95.
Anche se lo fai con VS.Net, a patto di installare .Net su Win95 (se
esiste...).
Ecco, siccome HTML non e` compilato, non esistono tool che ti mandano a
quel paese se usi i frame.
E non devono nemmeno esistere, IMHO. Fosse per me Frontpage e Dreamweaver
non dovrebbero esistere, semplicemente perche` poi creano "quelli come
te" (senza offesa ;) che non sanno che i frame sono deprecati, e tanto
basta trascinare un'iconcina sulla pagina per fare le peggiori porcherie.
Cosi` come in VB.Net non basta trascinare iconcine su un canvas per
creare un software di raytracing, sul web non basta trascinare iconcine
per fare un sito fatto bene.
Con Access ti puoi fare la tua applicazione per gestirti la biblioteca
personale, cosi` come in FP/DW puoi farti il sitarello personale, ma
appena fai qualcosa di piu` complesso dell'Hello World devi mettere mano
al codice, e a quel punto FP/DW diventa un ostacolo, non un vantaggio,
perche` genera codice che e` difficile personalizzare o modificare a mano.
> Ti dà tanti di quegli errori che ti passa la voglia. Ha molto piú senso
> 'cominciare a giocare' direttamente in VB .NET, come ho fatto io, ed
> abituarsi alla 'nuova vita'.
Ecco, allora butta FP, prenditi Notepad++, Eclipse/Netbeans o qualche
altro editor evoluto (NON Notepad e basta) e scrivi siti a mano.
Nihao! ;P
ngw
LOL, scrivi la data di pubblicazione (2002, 8 anni fa), non quando
l'hai comprato tu.
Se prendi libri antichi non è colpa di nessuno, se poi prendi anche le
cazzate che pubblicano in italia tanto per spillare 10 euro a qualche
pollo, cavoli tuoi di nuovo.
ngw
--
Nicholas Wieland (ngw)
Zooppa CTO
911 Western Avenue, Suite 420
Seattle, WA 98104 US
ngw
> l...@email.it schrieb:
>
>>
>> no: si parte dal presupposto (giustificatissimo) che il realizzatore
>> della pagina sia in malafede, perché il posizionamento e il
>> cliccamento di una pagina sono soldi. se il realizzatore della pagina
>> è in buona fede, deve fidarsi che il motore di ricerca classifichi e
>> faccia lui una "spettrografia" (chiamiamola così) del contenuto della
>> pagina secondo i suoi criteri oggettivi, non secondo i desiderata del
>> realizzatore.
>>
>
> Perfetto. Dopo tutte queste buone ragioni mai più spenderò il mio tempo
> a includere META statements. Lascerò che Google mi 'classifichi' lui.
>
> (Mi chiedo solo perchè Frontpage continua a farlo...)
Title e description sono usate dai motori di ricerca per titolo e
descrizione del risultato. Title è molto influente per il SEO,
description no.
>> ma ora dimmi una cosa: sono tutte pagine statiche? non prendono i
>> loro contenuti da un db? perché qui si aprirebbe un altro
>> bell'argomento...
>>
>
> No, sono pagine statiche.
> Moltiplicate per quattro perché in quattro lingue diverse.
> Ma sempre statiche sono.
>
> Quindi un PHP+MySQL non mi aiuterebbe.
In realtà un qualsiasi linguaggio ti aiuta a livello di localizzazione,
in modo da non dover cambiare 4 pagine ogni volta che muovi una virgola.
john
>
> Ecco, allora butta FP, prenditi Notepad++, Eclipse/Netbeans o qualche
> altro editor evoluto (NON Notepad e basta) e scrivi siti a mano.
>
> Nihao! ;P
Hen Hao, Hsie Hsie... :-))
john
>
>
> LOL, scrivi la data di pubblicazione (2002, 8 anni fa), non quando l'hai
> comprato tu.
La data del fbbraio 2010 e' la data dell'ultima ristampa. Io l'ho
comprato un paio di mesi più tardi.
> Se prendi libri antichi non è colpa di nessuno, se poi prendi anche le
> cazzate che pubblicano in italia tanto per spillare 10 euro a qualche
> pollo, cavoli tuoi di nuovo.
>
Ma se questi 'maledetti frames' sono stati cazziati già nel secolo
scorso, non sarebbe ora che le pubblicazioni a paretie almenoi dal 2000
lo menzionassero e non li descrivessero proprio per niente ?
A proposito, sullo stesso libro c'è anche IFRAME
Comunque per quel che mi riguarda ho capito ilconcetto.
Soplo che ripeto : uno che si avvicina al HTML oggi, non ha tutte queste
informazioni.
Deve venire su un NG di webmaster per averle... :-)))
l...@email.it
> E mo' dimmi che sono un troll.
Molly Holzschlag è una troll! :-)
john
> On 17 Giu, 19:51, john <du...@agdp.de> wrote:
>
>> E mo' dimmi che sono un troll.
>
> Molly Holzschlag è una troll! :-)
dovrò farmi rimborsare, penso... :-)
ngw
> Comunque per quel che mi riguarda ho capito ilconcetto.
> Soplo che ripeto : uno che si avvicina al HTML oggi, non ha tutte
> queste informazioni.
>
> Deve venire su un NG di webmaster per averle... :-)))
Ma non prendere libri italiani, te lo dico io che ne ho scritto uno per Apogeo.
Lascia proprio perdere.
ngw
La Molly è una grande, è il libro che è vecchio. Bravi quelli della
Mondadori a ristampare un libro del 2002 che parla di tecnologia. Sono
vecchi quelli del 2009.