☺
Scritto da: avvelentani
> Scritto da: Daisuke Niwa
> > Scritto da: Giambo
> > > Scritto da: Daisuke Niwa
> > >
> > > > A sinistra invece di avere un elenco di forum si potrebbe avere un tag-cloud
> > >
> > > Ho provato a implementare qualcosa, ma non ci siamo.
> > > Il problema e' la disparita' di numero di post nei vari forum. Per esempio, prima della morte del FdT (28.12.2011), i messaggi senza forum erano 879429. Seguiva la Proc di Catania, con 32824 (25 volte di meno) e staccatissimi "_______________" (1548), Verdurin (1442), "Sesso" (1432) e "Forum Deserto" (1371).
> > >
> > > Se definissimo quindi il font massimo "25px" e il minimo "8px", tralasciano i messaggi senza forum avremmo Proc di Catania a 25px e tutti gli altri attorno agli 8px
...
> > >
> >
> > Perché tu cerchi di implementare la cosa a pixel.
> > Implementala invece a categorie e classi, poi mi arrangio io con il CSS.
> > Definiamo, chessò 5 categorie.
> > la prima categoria è quella più grossa.
> > La seconda quella che ha almeno tot messaggi ma meno di tot...
> > e via avanti.
> > In pratica tu nel tag-cloud non dici quanti pixel deve essere grande la scritta, ma a che categoria appartiene. Poi le regole di chi rientra in quale categoria sono razzi tuoi, a me interessano solo i nomi delle 5 categorie da definire nel CSS.
>
> Mi sembra palese che sia necessaria una scala logaritmica.
Chi rientra in quale categoria lo decide il codice java, si può fare logaritmico volendo, oppure con altre tecniche. IMO si può anche fare lineare e aspettare che con il nuovo sistema le cose si normalizzino da sole con l'andare del tempo.
Quello che vedo io sono solo etichette tipo
<span class="cloudCat1">Forum dei Troll</span>
<span class="cloudCat2">Proc di Catania</span>
<span class="cloudCat3">__________</span>
<span class="cloudCat3">Verdurin</span>
<span class="cloudCat3">Sesso</span>
<span class="cloudCat4">Forum deserto</span>
e via avanti.
Le categorie possono essere 5 o 10, direi non di più.
> Scritto da: Daisuke Niwa
> > Scritto da: Giambo
> > > Scritto da: Daisuke Niwa
> > >
> > > > A sinistra invece di avere un elenco di forum si potrebbe avere un tag-cloud
> > >
> > > Ho provato a implementare qualcosa, ma non ci siamo.
> > > Il problema e' la disparita' di numero di post nei vari forum. Per esempio, prima della morte del FdT (28.12.2011), i messaggi senza forum erano 879429. Seguiva la Proc di Catania, con 32824 (25 volte di meno) e staccatissimi "_______________" (1548), Verdurin (1442), "Sesso" (1432) e "Forum Deserto" (1371).
> > >
> > > Se definissimo quindi il font massimo "25px" e il minimo "8px", tralasciano i messaggi senza forum avremmo Proc di Catania a 25px e tutti gli altri attorno agli 8px
...> > >
> >
> > Perché tu cerchi di implementare la cosa a pixel.
> > Implementala invece a categorie e classi, poi mi arrangio io con il CSS.
> > Definiamo, chessò 5 categorie.
> > la prima categoria è quella più grossa.
> > La seconda quella che ha almeno tot messaggi ma meno di tot...
> > e via avanti.
> > In pratica tu nel tag-cloud non dici quanti pixel deve essere grande la scritta, ma a che categoria appartiene. Poi le regole di chi rientra in quale categoria sono razzi tuoi, a me interessano solo i nomi delle 5 categorie da definire nel CSS.
>
> Mi sembra palese che sia necessaria una scala logaritmica.
Chi rientra in quale categoria lo decide il codice java, si può fare logaritmico volendo, oppure con altre tecniche. IMO si può anche fare lineare e aspettare che con il nuovo sistema le cose si normalizzino da sole con l'andare del tempo.
Quello che vedo io sono solo etichette tipo
<span class="cloudCat1">Forum dei Troll</span>
<span class="cloudCat2">Proc di Catania</span>
<span class="cloudCat3">__________</span>
<span class="cloudCat3">Verdurin</span>
<span class="cloudCat3">Sesso</span>
<span class="cloudCat4">Forum deserto</span>
e via avanti.
Le categorie possono essere 5 o 10, direi non di più.
NON DIRMELO SE LO SAI MA SE NON LO SAI SAPPILO
Ad
http://sallo.it
LO SAI? Allora NON fa per te. NON LO SAI? Allora non ti serve.
☺
Scritto da: utente fasullo
> Scritto da: avvelentani
> > c'e` qualcosa che dovrei sapere?
>
> abbiamo trovato frenchi e lichene che si toccavano a vicenda,
Lo sapevo... passavano troppo tempo da soli in ciat quei due...
> la suora è passata ai cani di taglia medio-grande
Lo sapevo... ha passato troppo tempo assieme a Goddamn...
> e wakko è frocio
Questa non me l'aspettavo...
> Scritto da: avvelentani
> > c'e` qualcosa che dovrei sapere?
>
> abbiamo trovato frenchi e lichene che si toccavano a vicenda,
Lo sapevo... passavano troppo tempo da soli in ciat quei due...
> la suora è passata ai cani di taglia medio-grande
Lo sapevo... ha passato troppo tempo assieme a Goddamn...
> e wakko è frocio
Questa non me l'aspettavo...
☺
Scritto da: Giambo
> Scritto da: Daisuke Niwa
>
> > A sinistra invece di avere un elenco di forum si potrebbe avere un tag-cloud
>
> Ho provato a implementare qualcosa, ma non ci siamo.
> Il problema e' la disparita' di numero di post nei vari forum. Per esempio, prima della morte del FdT (28.12.2011), i messaggi senza forum erano 879429. Seguiva la Proc di Catania, con 32824 (25 volte di meno) e staccatissimi "_______________" (1548), Verdurin (1442), "Sesso" (1432) e "Forum Deserto" (1371).
>
> Se definissimo quindi il font massimo "25px" e il minimo "8px", tralasciano i messaggi senza forum avremmo Proc di Catania a 25px e tutti gli altri attorno agli 8px ...
>
Perché tu cerchi di implementare la cosa a pixel.
Implementala invece a categorie e classi, poi mi arrangio io con il CSS.
Definiamo, chessò 5 categorie.
la prima categoria è quella più grossa.
La seconda quella che ha almeno tot messaggi ma meno di tot...
e via avanti.
In pratica tu nel tag-cloud non dici quanti pixel deve essere grande la scritta, ma a che categoria appartiene. Poi le regole di chi rientra in quale categoria sono razzi tuoi, a me interessano solo i nomi delle 5 categorie da definire nel CSS.
> Scritto da: Daisuke Niwa
>
> > A sinistra invece di avere un elenco di forum si potrebbe avere un tag-cloud
>
> Ho provato a implementare qualcosa, ma non ci siamo.
> Il problema e' la disparita' di numero di post nei vari forum. Per esempio, prima della morte del FdT (28.12.2011), i messaggi senza forum erano 879429. Seguiva la Proc di Catania, con 32824 (25 volte di meno) e staccatissimi "_______________" (1548), Verdurin (1442), "Sesso" (1432) e "Forum Deserto" (1371).
>
> Se definissimo quindi il font massimo "25px" e il minimo "8px", tralasciano i messaggi senza forum avremmo Proc di Catania a 25px e tutti gli altri attorno agli 8px
...>
Perché tu cerchi di implementare la cosa a pixel.
Implementala invece a categorie e classi, poi mi arrangio io con il CSS.
Definiamo, chessò 5 categorie.
la prima categoria è quella più grossa.
La seconda quella che ha almeno tot messaggi ma meno di tot...
e via avanti.
In pratica tu nel tag-cloud non dici quanti pixel deve essere grande la scritta, ma a che categoria appartiene. Poi le regole di chi rientra in quale categoria sono razzi tuoi, a me interessano solo i nomi delle 5 categorie da definire nel CSS.
☺
1) Forum
Io ne vorrei uno per gli Anime, ad altri piacerebbe averne altri... e se si trasformassero i forum in tag?
A sinistra invece di avere un elenco di forum si potrebbe avere un tag-cloud per quelli più usati e qualcosa che permetta di ricercare anche i tag usati poco non presenti in elenco. In questo modo non avremmo una struttua fissa, potremmo mantenere i forum attuali (sottoforma però di tag) per i vecchi messaggi e ognuno potrebbe aggiungere un tag nuovo che, se ha successo, potrebbe venire usato anche da altri. IMO i subforum sono qualcosa che non solo non serve ma da al forum una struttura rigida ed immodificabile che fa tanto da WEB 1990 ma che finisce per limitarci.
2) Destinatari in Posta
a) IMO è assurdo avere 5 campi per 5 destinatari diversi. E se ne voglio 6 invece? Devo ricopiare tutto in un nuovo messaggio...
Sarebbe meglio avere un campo unico, con autocomplete come suggeriva Giambo, ma che permettesse di inserire liberamente quanti destinatari si vogliono, magari separati da un carattere o qualcosa di simile.
Si potrebbe usare il ; come nelle email per destinatari multipli, il problema è che il ; è usato da diversi nick. Bisognerebbe trovare un carattere non permesso nei nickname... la virgola era permessa o no? Verrebbe una cosa tipo: To: Daisuke Niwa, Giambo, ::1, ....
Il programma riceve il campo, fa uno split sulla virgola, e per ogni riga dell'array risultante manda un messaggio.
Altra alternativa, forse più intelligente e bella da vedere, è un <div> che contiene i nomi "read-only" degli utenti già inseriti, e un campo input che ne prende di nuovi... ogni volta che premo invio nel campo di input lui mi aggiunge i destinatari in questo campo (stile tag) che posso eventualmente rimuovere. In questo modo non ho bisogno di limitare i caratteri dei nickname e ho un effetto davvero bello e moderno... il punto debole di questa soluzione è che richiede javascript.
b) Perché mostra al destinatario l'elenco delle persone riceventi? IMO è una violazione della privacy... magari voglio mandare quel messaggio a due persone, senza però rivelare alle due il fatto che il messaggio ha più destinatari... IMO ogni utente nel campo "destinatario" deve vedere il suo nick, e solo quello. Insomma, trattare il campo destinatario come fosse il BCC dell'email.
Io ne vorrei uno per gli Anime, ad altri piacerebbe averne altri... e se si trasformassero i forum in tag?
A sinistra invece di avere un elenco di forum si potrebbe avere un tag-cloud per quelli più usati e qualcosa che permetta di ricercare anche i tag usati poco non presenti in elenco. In questo modo non avremmo una struttua fissa, potremmo mantenere i forum attuali (sottoforma però di tag) per i vecchi messaggi e ognuno potrebbe aggiungere un tag nuovo che, se ha successo, potrebbe venire usato anche da altri. IMO i subforum sono qualcosa che non solo non serve ma da al forum una struttura rigida ed immodificabile che fa tanto da WEB 1990 ma che finisce per limitarci.
2) Destinatari in Posta
a) IMO è assurdo avere 5 campi per 5 destinatari diversi. E se ne voglio 6 invece? Devo ricopiare tutto in un nuovo messaggio...
Sarebbe meglio avere un campo unico, con autocomplete come suggeriva Giambo, ma che permettesse di inserire liberamente quanti destinatari si vogliono, magari separati da un carattere o qualcosa di simile.
Si potrebbe usare il ; come nelle email per destinatari multipli, il problema è che il ; è usato da diversi nick. Bisognerebbe trovare un carattere non permesso nei nickname... la virgola era permessa o no? Verrebbe una cosa tipo: To: Daisuke Niwa, Giambo, ::1, ....
Il programma riceve il campo, fa uno split sulla virgola, e per ogni riga dell'array risultante manda un messaggio.
Altra alternativa, forse più intelligente e bella da vedere, è un <div> che contiene i nomi "read-only" degli utenti già inseriti, e un campo input che ne prende di nuovi... ogni volta che premo invio nel campo di input lui mi aggiunge i destinatari in questo campo (stile tag) che posso eventualmente rimuovere. In questo modo non ho bisogno di limitare i caratteri dei nickname e ho un effetto davvero bello e moderno... il punto debole di questa soluzione è che richiede javascript.
b) Perché mostra al destinatario l'elenco delle persone riceventi? IMO è una violazione della privacy... magari voglio mandare quel messaggio a due persone, senza però rivelare alle due il fatto che il messaggio ha più destinatari... IMO ogni utente nel campo "destinatario" deve vedere il suo nick, e solo quello. Insomma, trattare il campo destinatario come fosse il BCC dell'email.
☺
Scritto da: Daisuke Niwa
> Scritto da: Giambo
> > Scritto da: Daisuke Niwa
> >
> > > La versione .min di jquery-ui a me occupava non meno di 160k, strippando diverse cose. Ora, non so quanto completa sia la versione di google... ma mi pare faccia tutto quello che per ora ci serve.
> >
> > Uhm-uhm ... Ma a cosa piffero serve jquery-ui
?
>
> Serve a molti effetti stile user-interface, io la uso per il momento solo per il resizing dei riquadri dei post con il mouse ma permette di implementare molte altre cose tipo i TAB e molto altro.
> Qui ci sono delle demo: http://jqueryui.com/demos/
Per esempio l'autocomplete: http://jqueryui.com/demos/autocomplete/
sarebbe perfetto per i tag...
> Scritto da: Giambo
> > Scritto da: Daisuke Niwa
> >
> > > La versione .min di jquery-ui a me occupava non meno di 160k, strippando diverse cose. Ora, non so quanto completa sia la versione di google... ma mi pare faccia tutto quello che per ora ci serve.
> >
> > Uhm-uhm ... Ma a cosa piffero serve jquery-ui
?>
> Serve a molti effetti stile user-interface, io la uso per il momento solo per il resizing dei riquadri dei post con il mouse ma permette di implementare molte altre cose tipo i TAB e molto altro.
> Qui ci sono delle demo: http://jqueryui.com/demos/
Per esempio l'autocomplete: http://jqueryui.com/demos/autocomplete/
sarebbe perfetto per i tag...
☺
Scritto da:
> > > > > che è? sto fòro si regge su roba fornita da Google?
> > > >
> > > > Si, per le ricerche incrociate IP e tutto il resto
> > >
> > >
> > >
> > > > Seriamente: Non so chi ha deciso che le librerie jQuery che vengono usate per gli effettini figosi non devono risiedere su questo server bensi' su quello di google
> > >
> > > Il problema è che spesso google alza i millisecondi necessari a comporre la pagina
> >
> > Dalle prove che ho fatto io risulta che collegarsi a googleapis ha un tempo iniziale di connessione (molto) più alto rispetto al server, tuttavia nel servire i contenuti è molto più veloce. Alla fine sembra che nonostante i tempi di connessione iniziale elevati la velocità di invio di jquery e jquery-ui ripaghi di questa attesa iniziale.
> > Comunque io mi collego dalla Svezia.
> >
> > Resta comunque il fatto che mantenere aggiornata la libreria con googleapis è decisamente più facile e immediato che doverlo fare a mano.
>
> Non è come google analytics che quando è down rende invisitabili pagine e pagine dell'internetto?
Purtroppo si.
> > > > > che è? sto fòro si regge su roba fornita da Google?
> > > >
> > > > Si, per le ricerche incrociate IP e tutto il resto
> > >
> > >
> > >
> > > > Seriamente: Non so chi ha deciso che le librerie jQuery che vengono usate per gli effettini figosi non devono risiedere su questo server bensi' su quello di google
> > >
> > > Il problema è che spesso google alza i millisecondi necessari a comporre la pagina
> >
> > Dalle prove che ho fatto io risulta che collegarsi a googleapis ha un tempo iniziale di connessione (molto) più alto rispetto al server, tuttavia nel servire i contenuti è molto più veloce. Alla fine sembra che nonostante i tempi di connessione iniziale elevati la velocità di invio di jquery e jquery-ui ripaghi di questa attesa iniziale.
> > Comunque io mi collego dalla Svezia.
> >
> > Resta comunque il fatto che mantenere aggiornata la libreria con googleapis è decisamente più facile e immediato che doverlo fare a mano.
>
> Non è come google analytics che quando è down rende invisitabili pagine e pagine dell'internetto?
Purtroppo si.
☺
Scritto da: Daisuke Niwa
> vi lascio che devo fare due esercizi di trigonometria con il vicino. _
Se ne è andato ora.
Quanto è coccoloso... ____
> vi lascio che devo fare due esercizi di trigonometria con il vicino. _
Se ne è andato ora.
Quanto è coccoloso... ____
☺
Scritto da: Giambo
> Scritto da: Daisuke Niwa
>
> > La versione .min di jquery-ui a me occupava non meno di 160k, strippando diverse cose. Ora, non so quanto completa sia la versione di google... ma mi pare faccia tutto quello che per ora ci serve.
>
> Uhm-uhm ... Ma a cosa piffero serve jquery-ui ?
Serve a molti effetti stile user-interface, io la uso per il momento solo per il resizing dei riquadri dei post con il mouse ma permette di implementare molte altre cose tipo i TAB e molto altro.
Qui ci sono delle demo: http://jqueryui.com/demos/
> Scritto da: Daisuke Niwa
>
> > La versione .min di jquery-ui a me occupava non meno di 160k, strippando diverse cose. Ora, non so quanto completa sia la versione di google... ma mi pare faccia tutto quello che per ora ci serve.
>
> Uhm-uhm ... Ma a cosa piffero serve jquery-ui
?Serve a molti effetti stile user-interface, io la uso per il momento solo per il resizing dei riquadri dei post con il mouse ma permette di implementare molte altre cose tipo i TAB e molto altro.
Qui ci sono delle demo: http://jqueryui.com/demos/
☺
Scritto da: Giambo
> Scritto da: Daisuke Niwa
>
> > Io lo trovo molto più veloce. Anche perché loro hanno una versione di jquery-ui che è circa 1/3 della dimensione minima sul sito ufficiale.
>
> Anche della versione "minified" ?
> Se FdT2.0 fosse stato piu' veloce di Google, mi sarei stupito !
Si, di quelle parlo.
La versione .min di jquery-ui a me occupava non meno di 160k, strippando diverse cose. Ora, non so quanto completa sia la versione di google... ma mi pare faccia tutto quello che per ora ci serve.
> Scritto da: Daisuke Niwa
>
> > Io lo trovo molto più veloce. Anche perché loro hanno una versione di jquery-ui che è circa 1/3 della dimensione minima sul sito ufficiale.
>
> Anche della versione "minified" ?
> Se FdT2.0 fosse stato piu' veloce di Google, mi sarei stupito
!Si, di quelle parlo.
La versione .min di jquery-ui a me occupava non meno di 160k, strippando diverse cose. Ora, non so quanto completa sia la versione di google... ma mi pare faccia tutto quello che per ora ci serve.
☺
Scritto da:
> > > che è? sto fòro si regge su roba fornita da Google?
> >
> > Si, per le ricerche incrociate IP e tutto il resto
>
>
>
> > Seriamente: Non so chi ha deciso che le librerie jQuery che vengono usate per gli effettini figosi non devono risiedere su questo server bensi' su quello di google
>
> Il problema è che spesso google alza i millisecondi necessari a comporre la pagina
Dalle prove che ho fatto io risulta che collegarsi a googleapis ha un tempo iniziale di connessione (molto) più alto rispetto al server, tuttavia nel servire i contenuti è molto più veloce. Alla fine sembra che nonostante i tempi di connessione iniziale elevati la velocità di invio di jquery e jquery-ui ripaghi di questa attesa iniziale.
Comunque io mi collego dalla Svezia.
Resta comunque il fatto che mantenere aggiornata la libreria con googleapis è decisamente più facile e immediato che doverlo fare a mano.
> > > che è? sto fòro si regge su roba fornita da Google?
> >
> > Si, per le ricerche incrociate IP e tutto il resto
>
>
>
> > Seriamente: Non so chi ha deciso che le librerie jQuery che vengono usate per gli effettini figosi non devono risiedere su questo server bensi' su quello di google
>
> Il problema è che spesso google alza i millisecondi necessari a comporre la pagina
Dalle prove che ho fatto io risulta che collegarsi a googleapis ha un tempo iniziale di connessione (molto) più alto rispetto al server, tuttavia nel servire i contenuti è molto più veloce. Alla fine sembra che nonostante i tempi di connessione iniziale elevati la velocità di invio di jquery e jquery-ui ripaghi di questa attesa iniziale.
Comunque io mi collego dalla Svezia.
Resta comunque il fatto che mantenere aggiornata la libreria con googleapis è decisamente più facile e immediato che doverlo fare a mano.
☺
Scritto da: avvelenato
> Scritto da: altg
> > Manca. Nun se po' responne senza JS.
O)
> >
> > Inoltre mancano gli alt per molte immagini e il validator s'incazza.
> > Che figura!
> >
> > [non fateci caso, sto fumando troppo poco e tendo a pigliare a stiaffi il primo che passa]
>
> secondo me è il sesso ad essere latente....
Da quando i suoi hanno scoperto che se ne faceva di quelle paghette a due zeri ha dovuto tornare ai vecchi metodi gratuiti
> Scritto da: altg
> > Manca. Nun se po' responne senza JS.
O) > >
> > Inoltre mancano gli alt per molte immagini e il validator s'incazza.
> > Che figura!
> >
> > [non fateci caso, sto fumando troppo poco e tendo a pigliare a stiaffi il primo che passa]
>
> secondo me è il sesso ad essere latente....
Da quando i suoi hanno scoperto che se ne faceva di quelle paghette a due zeri ha dovuto tornare ai vecchi metodi gratuiti
☺
Scritto da: Daisuke Niwa
> Scritto da: Giambo
> > Scritto da:
> > > che è? sto fòro si regge su roba fornita da Google?
> >
> > Si, per le ricerche incrociate IP e tutto il resto
> >
> > Seriamente: Non so chi ha deciso che le librerie jQuery che vengono usate per gli effettini figosi non devono risiedere su questo server bensi' su quello di google
>
> Io.
Ho preferito la versione di google perché:
1) in genere è molto più veloce a servire i contenuti di qualsiasi server tu possa avere
2) ha delle librerie a parità di versione (in particolare jquery-ui), più piccole di quelle che trovi sul sito di jquery (probabilmente le ricompilano loro)
3) se voglio aggiornare alla versione successiva non devo litigare con GIT per rimuovere la vecchia versione ed inserire quella nuova, mi basta cambiare una riga nell'header
> Scritto da: Giambo
> > Scritto da:
> > > che è? sto fòro si regge su roba fornita da Google?
> >
> > Si, per le ricerche incrociate IP e tutto il resto
> >
> > Seriamente: Non so chi ha deciso che le librerie jQuery che vengono usate per gli effettini figosi non devono risiedere su questo server bensi' su quello di google
>
> Io.
Ho preferito la versione di google perché:
1) in genere è molto più veloce a servire i contenuti di qualsiasi server tu possa avere
2) ha delle librerie a parità di versione (in particolare jquery-ui), più piccole di quelle che trovi sul sito di jquery (probabilmente le ricompilano loro)
3) se voglio aggiornare alla versione successiva non devo litigare con GIT per rimuovere la vecchia versione ed inserire quella nuova, mi basta cambiare una riga nell'header
☺
Scritto da: Daisuke Niwa
> Scritto da: altg
> > Manca. Nun se po' responne senza JS. O)
>
> Da aggiustare.
Qui bisogna che intervenga qualcuno che sa come funziona quell'archibugio di jsp. In effetti è un problema grave per chi usa il forum via Tor con JS disabilitati... IMO il forum dovrebbe usare Ajax se possibile, altrimenti fare un post normale... in questo modo si mantiene la struttura Ajax per "figate future", ma si riesce ad usare il forum anche in modo "standard".
> > Inoltre mancano gli alt per molte immagini e il validator s'incazza.
> > Che figura!
>
> Da aggiustare.
Ok, fatto, è solo da installare sul server.
> Scritto da: altg
> > Manca. Nun se po' responne senza JS.
O) >
> Da aggiustare.
Qui bisogna che intervenga qualcuno che sa come funziona quell'archibugio di jsp. In effetti è un problema grave per chi usa il forum via Tor con JS disabilitati... IMO il forum dovrebbe usare Ajax se possibile, altrimenti fare un post normale... in questo modo si mantiene la struttura Ajax per "figate future", ma si riesce ad usare il forum anche in modo "standard".
> > Inoltre mancano gli alt per molte immagini e il validator s'incazza.
> > Che figura!
>
> Da aggiustare.
Ok, fatto, è solo da installare sul server.
☺
Scritto da:
> Scritto da: Daisuke Niwa
> > Scritto da:
> > > come si chiama il tuo ebook reader?
> >
> > BeBook Club.
> >
> > > come si comporta nel caso di manuali con immagini?
> > >
> > > grazie
> >
> > Con i manuali non è granché. Diciamo che è utile nel caso tu non abbia a disposizione il manuale fisico o nel caso sei fuori e ti serve un particolare manuale (è chiaro che non puoi portarteli dietro tutti).
> >
> > Se i manuali sono ePub e/o altri formati "liquidi" non c'è problema perché tutto si adatterà allo schermo del tuo ebook reader, se invece sono PDF con tabelle/schemi/ecc allora o hai un display molto grande (e quindi anche molto scomodo/fragile da portarsi dietro) oppure ti troverai a fare "panning" (cioè spostare la visualizzazione a destra e sinistra, in alto e in basso) e su un ebook reader (quindi schermo e-ink) è molto scomodo per via degli alti tempi di risposta (sarebbe anche brutto da farsi su un display lcd normale ma almeno avresti tempi di risposta immediati).
> >
> > C'è anche un altro problema sia per gli ebook reader (e-ink) che con i tablet nel caso di manuali: non è come avere il libro fisico per le mani, nel senso che se hai un manuale e vuoi cercare velocemente una cosa (chessò, uno schema) allora ti basta scorrere le pagine velocemente finché non lo trovi... operazione che può impiegarti anche pochi secondi. Con un ebook reader o anche un tablet questa operazione è molto più lunga e scomoda.
> >
> > Comunque, se vuoi leggere manuali allora ti consiglio un ebook reader con un display grande, o sarai costretto a zoomare, ma questo significa anche che sarai costretto a fare panning con i formati che non sono "liquidi" (cioè la gran parte dei manuali).
> >
> > Poi, tralasciando questo... non ci sono grossi problemi. L'ebook reader è in grado di presentarti fedelmente qualsiasi immagine (la vedrai in scala di grigi ovviamente)... il problema grosso appunto ce l'hai quando devi fare il panning o passare velocemente le pagine per cercare qualcosa che non hai bookmarkato precedentemente o qualcosa che la ricerca testuale non ti può trovare (uno schema, un disegno, un grafico... o anche trovare un argomento che sai riconoscere visivamente ma non ricordi delle keyword di ricerca utili).
> >
> > Di buono, anzi, molto buono, di un ebook reader rispetto ad un tablet è che anche se ti trovi in condizioni di luci e riflessi (per esempio mentre sei all'aperto, anche in presenza di ombra) sull'ebook reader leggi perfettamente (proprio come fosse un pezzo di carta), su un tablet (e in genere qualsiasi dispositivo LCD) invece no.
> >
> > Riassunto:
> > - per i manuali il supporto migliore è ancora la carta
> > - se _sai_ che userai l'ebook reader principalmente per i manuali allora meglio se te lo scegli con un display abbastanza grande da contenere una pagina intera senza dover zoomare per leggere (resta comunque il problema dello scroll veloce delle pagine in caso di ricerche visive non bookmarkate)
> >
> > Comunque, c'è anche da dire che negli ebook reader, o almeno nel mio, c'è la possibilità di rendere forzatamente liquida la visualizzazione di un PDF (a meno che non sia una scansione), questo aiuta molto, però se hai codice nel mezzo rischi di perdere tabulazioni, le formattazioni e simili rendendoti molto più complicato capire le cose. Stessa cosa per le formule... nella visualizzazione "rigida" non ci sono problemi, nella visualizzazione "liquida" invece le troverai spezzate o peggio.
> >
> > Visualizzazione rigida:
> > - la pagina è esattamente come quella stampata
> > - se il display non è grande a sufficienza dovrai zoomare, quindi fare il panning
> > - ottima per i manuali, terribile se devi fare il panning ergo richiede un display grande per essere utilizzabile sui manuali
> >
> > Visualizzazione liquida forzata:
> > - la pagina viene riadattata per il tuo display, i font vengono resi grandi per permetterti di leggere senza panning e le righe vanno a capo
> > - non ci sono problemi di dimensione del display
> > - tabelle, codice e formule quasi sicuramente ne risentono negativamente
> > - ottima per i libri di racconti, poco adatta alla visualizzazione di manuali
> >
> > Visualizzazione liquida ePub:
> > - gli ePub, tranne quelli convertiti da PDF che vengono convertiti male, sono adatti alla visualizzazione liquida
> > - se hai manuali in ePub sei fortunato perché pur essendo una visualizzazione liquida è lo stesso autore che decide la formattazione quindi il codice resta leggibile, le tabelle anche, le formule pure, potresti avere problemi di panning con schemi grafici grandi
> >
> > In genere io faccio così... scarico i manuali e me li vedo sull'ebook reader. Se vedo che quel manuale mi serve spesso o devo leggermelo tutto compro la versione cartacea. Se invece devo consultarlo saltuariamente o a quel manuale non ci tengo granché allora me lo tengo così com'è e trovo un compromesso.
> >
> > Per i racconti invece il lettore di ebook è insuperabile.
>
> grazie mille
Mi farai conoscere tuo figlio quando compirà 12 anni?
> Scritto da: Daisuke Niwa
> > Scritto da:
> > > come si chiama il tuo ebook reader?
> >
> > BeBook Club.
> >
> > > come si comporta nel caso di manuali con immagini?
> > >
> > > grazie
> >
> > Con i manuali non è granché. Diciamo che è utile nel caso tu non abbia a disposizione il manuale fisico o nel caso sei fuori e ti serve un particolare manuale (è chiaro che non puoi portarteli dietro tutti).
> >
> > Se i manuali sono ePub e/o altri formati "liquidi" non c'è problema perché tutto si adatterà allo schermo del tuo ebook reader, se invece sono PDF con tabelle/schemi/ecc allora o hai un display molto grande (e quindi anche molto scomodo/fragile da portarsi dietro) oppure ti troverai a fare "panning" (cioè spostare la visualizzazione a destra e sinistra, in alto e in basso) e su un ebook reader (quindi schermo e-ink) è molto scomodo per via degli alti tempi di risposta (sarebbe anche brutto da farsi su un display lcd normale ma almeno avresti tempi di risposta immediati).
> >
> > C'è anche un altro problema sia per gli ebook reader (e-ink) che con i tablet nel caso di manuali: non è come avere il libro fisico per le mani, nel senso che se hai un manuale e vuoi cercare velocemente una cosa (chessò, uno schema) allora ti basta scorrere le pagine velocemente finché non lo trovi... operazione che può impiegarti anche pochi secondi. Con un ebook reader o anche un tablet questa operazione è molto più lunga e scomoda.
> >
> > Comunque, se vuoi leggere manuali allora ti consiglio un ebook reader con un display grande, o sarai costretto a zoomare, ma questo significa anche che sarai costretto a fare panning con i formati che non sono "liquidi" (cioè la gran parte dei manuali).
> >
> > Poi, tralasciando questo... non ci sono grossi problemi. L'ebook reader è in grado di presentarti fedelmente qualsiasi immagine (la vedrai in scala di grigi ovviamente)... il problema grosso appunto ce l'hai quando devi fare il panning o passare velocemente le pagine per cercare qualcosa che non hai bookmarkato precedentemente o qualcosa che la ricerca testuale non ti può trovare (uno schema, un disegno, un grafico... o anche trovare un argomento che sai riconoscere visivamente ma non ricordi delle keyword di ricerca utili).
> >
> > Di buono, anzi, molto buono, di un ebook reader rispetto ad un tablet è che anche se ti trovi in condizioni di luci e riflessi (per esempio mentre sei all'aperto, anche in presenza di ombra) sull'ebook reader leggi perfettamente (proprio come fosse un pezzo di carta), su un tablet (e in genere qualsiasi dispositivo LCD) invece no.
> >
> > Riassunto:
> > - per i manuali il supporto migliore è ancora la carta
> > - se _sai_ che userai l'ebook reader principalmente per i manuali allora meglio se te lo scegli con un display abbastanza grande da contenere una pagina intera senza dover zoomare per leggere (resta comunque il problema dello scroll veloce delle pagine in caso di ricerche visive non bookmarkate)
> >
> > Comunque, c'è anche da dire che negli ebook reader, o almeno nel mio, c'è la possibilità di rendere forzatamente liquida la visualizzazione di un PDF (a meno che non sia una scansione), questo aiuta molto, però se hai codice nel mezzo rischi di perdere tabulazioni, le formattazioni e simili rendendoti molto più complicato capire le cose. Stessa cosa per le formule... nella visualizzazione "rigida" non ci sono problemi, nella visualizzazione "liquida" invece le troverai spezzate o peggio.
> >
> > Visualizzazione rigida:
> > - la pagina è esattamente come quella stampata
> > - se il display non è grande a sufficienza dovrai zoomare, quindi fare il panning
> > - ottima per i manuali, terribile se devi fare il panning ergo richiede un display grande per essere utilizzabile sui manuali
> >
> > Visualizzazione liquida forzata:
> > - la pagina viene riadattata per il tuo display, i font vengono resi grandi per permetterti di leggere senza panning e le righe vanno a capo
> > - non ci sono problemi di dimensione del display
> > - tabelle, codice e formule quasi sicuramente ne risentono negativamente
> > - ottima per i libri di racconti, poco adatta alla visualizzazione di manuali
> >
> > Visualizzazione liquida ePub:
> > - gli ePub, tranne quelli convertiti da PDF che vengono convertiti male, sono adatti alla visualizzazione liquida
> > - se hai manuali in ePub sei fortunato perché pur essendo una visualizzazione liquida è lo stesso autore che decide la formattazione quindi il codice resta leggibile, le tabelle anche, le formule pure, potresti avere problemi di panning con schemi grafici grandi
> >
> > In genere io faccio così... scarico i manuali e me li vedo sull'ebook reader. Se vedo che quel manuale mi serve spesso o devo leggermelo tutto compro la versione cartacea. Se invece devo consultarlo saltuariamente o a quel manuale non ci tengo granché allora me lo tengo così com'è e trovo un compromesso.
> >
> > Per i racconti invece il lettore di ebook è insuperabile.
>
> grazie mille
Mi farai conoscere tuo figlio quando compirà 12 anni?
☺
Scritto da:
> > > che è? sto fòro si regge su roba fornita da Google?
> >
> > Si, per le ricerche incrociate IP e tutto il resto
>
>
>
> > Seriamente: Non so chi ha deciso che le librerie jQuery che vengono usate per gli effettini figosi non devono risiedere su questo server bensi' su quello di google
>
> Il problema è che spesso google alza i millisecondi necessari a comporre la pagina
Io lo trovo molto più veloce. Anche perché loro hanno una versione di jquery-ui che è circa 1/3 della dimensione minima sul sito ufficiale.
> > > che è? sto fòro si regge su roba fornita da Google?
> >
> > Si, per le ricerche incrociate IP e tutto il resto
>
>
>
> > Seriamente: Non so chi ha deciso che le librerie jQuery che vengono usate per gli effettini figosi non devono risiedere su questo server bensi' su quello di google
>
> Il problema è che spesso google alza i millisecondi necessari a comporre la pagina
Io lo trovo molto più veloce. Anche perché loro hanno una versione di jquery-ui che è circa 1/3 della dimensione minima sul sito ufficiale.
☺
Scritto da: Giambo
> Scritto da:
> > che è? sto fòro si regge su roba fornita da Google?
>
> Si, per le ricerche incrociate IP e tutto il resto
>
> Seriamente: Non so chi ha deciso che le librerie jQuery che vengono usate per gli effettini figosi non devono risiedere su questo server bensi' su quello di google
Io.
> Scritto da:
> > che è? sto fòro si regge su roba fornita da Google?
>
> Si, per le ricerche incrociate IP e tutto il resto
>
> Seriamente: Non so chi ha deciso che le librerie jQuery che vengono usate per gli effettini figosi non devono risiedere su questo server bensi' su quello di google
Io.
☺
Scritto da: altg
> Manca. Nun se po' responne senza JS. O)
Da aggiustare.
> Inoltre mancano gli alt per molte immagini e il validator s'incazza.
> Che figura!
Da aggiustare.
> Manca. Nun se po' responne senza JS.
O) Da aggiustare.
> Inoltre mancano gli alt per molte immagini e il validator s'incazza.
> Che figura!
Da aggiustare.
☺
Scritto da:
> come si chiama il tuo ebook reader?
BeBook Club.
> come si comporta nel caso di manuali con immagini?
>
> grazie
Con i manuali non è granché. Diciamo che è utile nel caso tu non abbia a disposizione il manuale fisico o nel caso sei fuori e ti serve un particolare manuale (è chiaro che non puoi portarteli dietro tutti).
Se i manuali sono ePub e/o altri formati "liquidi" non c'è problema perché tutto si adatterà allo schermo del tuo ebook reader, se invece sono PDF con tabelle/schemi/ecc allora o hai un display molto grande (e quindi anche molto scomodo/fragile da portarsi dietro) oppure ti troverai a fare "panning" (cioè spostare la visualizzazione a destra e sinistra, in alto e in basso) e su un ebook reader (quindi schermo e-ink) è molto scomodo per via degli alti tempi di risposta (sarebbe anche brutto da farsi su un display lcd normale ma almeno avresti tempi di risposta immediati).
C'è anche un altro problema sia per gli ebook reader (e-ink) che con i tablet nel caso di manuali: non è come avere il libro fisico per le mani, nel senso che se hai un manuale e vuoi cercare velocemente una cosa (chessò, uno schema) allora ti basta scorrere le pagine velocemente finché non lo trovi... operazione che può impiegarti anche pochi secondi. Con un ebook reader o anche un tablet questa operazione è molto più lunga e scomoda.
Comunque, se vuoi leggere manuali allora ti consiglio un ebook reader con un display grande, o sarai costretto a zoomare, ma questo significa anche che sarai costretto a fare panning con i formati che non sono "liquidi" (cioè la gran parte dei manuali).
Poi, tralasciando questo... non ci sono grossi problemi. L'ebook reader è in grado di presentarti fedelmente qualsiasi immagine (la vedrai in scala di grigi ovviamente)... il problema grosso appunto ce l'hai quando devi fare il panning o passare velocemente le pagine per cercare qualcosa che non hai bookmarkato precedentemente o qualcosa che la ricerca testuale non ti può trovare (uno schema, un disegno, un grafico... o anche trovare un argomento che sai riconoscere visivamente ma non ricordi delle keyword di ricerca utili).
Di buono, anzi, molto buono, di un ebook reader rispetto ad un tablet è che anche se ti trovi in condizioni di luci e riflessi (per esempio mentre sei all'aperto, anche in presenza di ombra) sull'ebook reader leggi perfettamente (proprio come fosse un pezzo di carta), su un tablet (e in genere qualsiasi dispositivo LCD) invece no.
Riassunto:
- per i manuali il supporto migliore è ancora la carta
- se _sai_ che userai l'ebook reader principalmente per i manuali allora meglio se te lo scegli con un display abbastanza grande da contenere una pagina intera senza dover zoomare per leggere (resta comunque il problema dello scroll veloce delle pagine in caso di ricerche visive non bookmarkate)
Comunque, c'è anche da dire che negli ebook reader, o almeno nel mio, c'è la possibilità di rendere forzatamente liquida la visualizzazione di un PDF (a meno che non sia una scansione), questo aiuta molto, però se hai codice nel mezzo rischi di perdere tabulazioni, le formattazioni e simili rendendoti molto più complicato capire le cose. Stessa cosa per le formule... nella visualizzazione "rigida" non ci sono problemi, nella visualizzazione "liquida" invece le troverai spezzate o peggio.
Visualizzazione rigida:
- la pagina è esattamente come quella stampata
- se il display non è grande a sufficienza dovrai zoomare, quindi fare il panning
- ottima per i manuali, terribile se devi fare il panning ergo richiede un display grande per essere utilizzabile sui manuali
Visualizzazione liquida forzata:
- la pagina viene riadattata per il tuo display, i font vengono resi grandi per permetterti di leggere senza panning e le righe vanno a capo
- non ci sono problemi di dimensione del display
- tabelle, codice e formule quasi sicuramente ne risentono negativamente
- ottima per i libri di racconti, poco adatta alla visualizzazione di manuali
Visualizzazione liquida ePub:
- gli ePub, tranne quelli convertiti da PDF che vengono convertiti male, sono adatti alla visualizzazione liquida
- se hai manuali in ePub sei fortunato perché pur essendo una visualizzazione liquida è lo stesso autore che decide la formattazione quindi il codice resta leggibile, le tabelle anche, le formule pure, potresti avere problemi di panning con schemi grafici grandi
In genere io faccio così... scarico i manuali e me li vedo sull'ebook reader. Se vedo che quel manuale mi serve spesso o devo leggermelo tutto compro la versione cartacea. Se invece devo consultarlo saltuariamente o a quel manuale non ci tengo granché allora me lo tengo così com'è e trovo un compromesso.
Per i racconti invece il lettore di ebook è insuperabile.
> come si chiama il tuo ebook reader?
BeBook Club.
> come si comporta nel caso di manuali con immagini?
>
> grazie
Con i manuali non è granché. Diciamo che è utile nel caso tu non abbia a disposizione il manuale fisico o nel caso sei fuori e ti serve un particolare manuale (è chiaro che non puoi portarteli dietro tutti).
Se i manuali sono ePub e/o altri formati "liquidi" non c'è problema perché tutto si adatterà allo schermo del tuo ebook reader, se invece sono PDF con tabelle/schemi/ecc allora o hai un display molto grande (e quindi anche molto scomodo/fragile da portarsi dietro) oppure ti troverai a fare "panning" (cioè spostare la visualizzazione a destra e sinistra, in alto e in basso) e su un ebook reader (quindi schermo e-ink) è molto scomodo per via degli alti tempi di risposta (sarebbe anche brutto da farsi su un display lcd normale ma almeno avresti tempi di risposta immediati).
C'è anche un altro problema sia per gli ebook reader (e-ink) che con i tablet nel caso di manuali: non è come avere il libro fisico per le mani, nel senso che se hai un manuale e vuoi cercare velocemente una cosa (chessò, uno schema) allora ti basta scorrere le pagine velocemente finché non lo trovi... operazione che può impiegarti anche pochi secondi. Con un ebook reader o anche un tablet questa operazione è molto più lunga e scomoda.
Comunque, se vuoi leggere manuali allora ti consiglio un ebook reader con un display grande, o sarai costretto a zoomare, ma questo significa anche che sarai costretto a fare panning con i formati che non sono "liquidi" (cioè la gran parte dei manuali).
Poi, tralasciando questo... non ci sono grossi problemi. L'ebook reader è in grado di presentarti fedelmente qualsiasi immagine (la vedrai in scala di grigi ovviamente)... il problema grosso appunto ce l'hai quando devi fare il panning o passare velocemente le pagine per cercare qualcosa che non hai bookmarkato precedentemente o qualcosa che la ricerca testuale non ti può trovare (uno schema, un disegno, un grafico... o anche trovare un argomento che sai riconoscere visivamente ma non ricordi delle keyword di ricerca utili).
Di buono, anzi, molto buono, di un ebook reader rispetto ad un tablet è che anche se ti trovi in condizioni di luci e riflessi (per esempio mentre sei all'aperto, anche in presenza di ombra) sull'ebook reader leggi perfettamente (proprio come fosse un pezzo di carta), su un tablet (e in genere qualsiasi dispositivo LCD) invece no.
Riassunto:
- per i manuali il supporto migliore è ancora la carta
- se _sai_ che userai l'ebook reader principalmente per i manuali allora meglio se te lo scegli con un display abbastanza grande da contenere una pagina intera senza dover zoomare per leggere (resta comunque il problema dello scroll veloce delle pagine in caso di ricerche visive non bookmarkate)
Comunque, c'è anche da dire che negli ebook reader, o almeno nel mio, c'è la possibilità di rendere forzatamente liquida la visualizzazione di un PDF (a meno che non sia una scansione), questo aiuta molto, però se hai codice nel mezzo rischi di perdere tabulazioni, le formattazioni e simili rendendoti molto più complicato capire le cose. Stessa cosa per le formule... nella visualizzazione "rigida" non ci sono problemi, nella visualizzazione "liquida" invece le troverai spezzate o peggio.
Visualizzazione rigida:
- la pagina è esattamente come quella stampata
- se il display non è grande a sufficienza dovrai zoomare, quindi fare il panning
- ottima per i manuali, terribile se devi fare il panning ergo richiede un display grande per essere utilizzabile sui manuali
Visualizzazione liquida forzata:
- la pagina viene riadattata per il tuo display, i font vengono resi grandi per permetterti di leggere senza panning e le righe vanno a capo
- non ci sono problemi di dimensione del display
- tabelle, codice e formule quasi sicuramente ne risentono negativamente
- ottima per i libri di racconti, poco adatta alla visualizzazione di manuali
Visualizzazione liquida ePub:
- gli ePub, tranne quelli convertiti da PDF che vengono convertiti male, sono adatti alla visualizzazione liquida
- se hai manuali in ePub sei fortunato perché pur essendo una visualizzazione liquida è lo stesso autore che decide la formattazione quindi il codice resta leggibile, le tabelle anche, le formule pure, potresti avere problemi di panning con schemi grafici grandi
In genere io faccio così... scarico i manuali e me li vedo sull'ebook reader. Se vedo che quel manuale mi serve spesso o devo leggermelo tutto compro la versione cartacea. Se invece devo consultarlo saltuariamente o a quel manuale non ci tengo granché allora me lo tengo così com'è e trovo un compromesso.
Per i racconti invece il lettore di ebook è insuperabile.