Newsgroup: it.comp.lang.javascript
Titolo: navigazione con gli indici di tabulazione

ho prodotto questa piccola web-app per la gestione della classifica di
una gara di pattinaggio:
http://www.cloc3.net/pattinaggio/
 
 
su firefox, il programmino ha raggiunto un buon grado di stabilità e
implementa bene tutte le funzioni fondamentali.
come prossimo passaggio (prima di curare la compatibilità cross-
browser), desidero migliorare il funzionamento della navigazione con
il tasto di tabulazione durante l'inserimento dei punteggi.
 
al momento, il tasto di tabulazione sposta il focus sequenzialmente,
senza consentire salti in verticale tra una colonna e la successiva.
 
anche l'uso del tag select, nella configurazione di default di
firefox, manifesta dei comportamenti un po' strani.
se l'utente digita due volte il tasto 5, ad esempio, non viene
selezionato il numero 55 ma il numero 50, ed è necessario spostarsi al
55 in progressione sequenziale.
 
ho provato a sovrapporre al sistema degli eventi personalizzati, con
delle chiamate addEventListener, ma sto incontrando più di qualche
contrattempo. ad esempio, ho scoperto che certi eventi, come il
keydown, possono entrare in conflitto con alcune funzioalità
automatiche del browser (vedi la ricerca automatica).
 
vorrei sapere quali sono gli strumenti che mi conviene utilizzare per
raggiungere il mio scopo e a quali specifiche mi conviene far
riferimento.

 riferimento.
 
https://developer.mozilla.org/en-US/
 
 
 


mi limito a discutere un singolo problema alla volta.
questo non va bene per niente, perché confonde l'utente che si attende
un comportamento uniforme per il 55 o per il 56.
per poter fare l'override di questo comportamento dovrei prima di
tutto capire qual'è il nome con cui viene classificato nelle
documentazioni.
:)
un aiutino?

 :)
 
Non capisco cosa intendi. Non è "classificato" in alcun modo; è il
comportamento di default. Come dire che quando clicchi su un link ti
apre la pagina.
 
Devi semplicemente intercettare i tasti premuti (eventi keypress,
keydown) sulla select, implementare la tua logica, ed evitare il
comportamento di default (`preventDefault`, come già avevi visto).
 

 comportamento di default (`preventDefault`, come già avevi visto).
 
Ho fatto un piccolo test, sembra che Firefox – e solo Firefox – si
comporti diversamente con le select. Ho aperto un bug su bugzilla,
vediamo come procede. Dubito però tu possa implementare alcun
workaround, in questo caso.


intanto grazie per il problema del 55. così adesso possiamo discutere
di tabulazioni.
 
nella mia web-app i select sono organizzati in una comunissima table.
per spostarsi da un select al successivo, l'utente può usare il tasto
tab, o può anche retrocedere sequenzialmente con la combinazione tab-
maiuscolo (che tuttavia l'utente non conosce o non ama).
Sarebbe meglio aggiungere l'uso delle freccie.
bisogna osservare che, al momento, sia le freccie su,giù, destra,
sinistra, sia i tasti di PagUp PagDown sono riservati allo scorrimento
sequenziale tra le opzioni del singolo select (che tra l'altro è
servito anche dalla rotellina del mouse e dalla ricerca diretta -
voglio dire il meccanismo del 55 che abbiamo criticato prima).
esiste un evidente squilibrio.
io credo che sarebbe meglio preservare la funzionalità dei PagUp
PagDown e modificare quella delle freccette, per realizzare una
navigazione est-sud-ovest-nord.
 
questo significa che, oltre a modificare i tasti, è necessario
stabilire delle relazioni tra righe successive.
avevo provato a costruire dei criteri di organizzazione dei select in
righe, ma senza approdare a nulla di utile.

 stabilire delle relazioni tra righe successive.
 
Questo è il meno.
 


proprio nell'altro post abbiamo constatato che il comportamento di
default era buggato.
e non a caso è stato la prima cosa di cui gli utenti si sono lamentati
quando hanno provato il programmino.
 
purtroppo, nei siti web, l'uso della tastiera è fortemente scoraggiato
e non esiste una educazione diffusa né negli utenti né negli
sviluppatori a farne un uso appropriato. a volte, mi capita di pensare
che certi limiti e certe difficoltà siano volutamente progettate dalle
stese major che definiscono gli standard per potersi litigare tra
loro. ce ne siamo accorti insieme, ad esempio, in quel post in cui
abbiamo discusso i limiti del salvataggio di un buffer di ram. in quel
caso la colpa era dell'estensore della specifica standard che si era
pensato un protocollo con la chiave data: ma senza la chiave
filename:. può essere semplice ingenuità?
allo stesso modo, ritengo che sia virtuoso riferirsi ai comportamenti
di default ovunque possibile, ma con un grado adeguato di libertà
intellettuale.
 
la mia necessaità, infatti, nasce da una osservazione precisa
sull'usabilità della mia web-app, che ho reso esplicita in precedenza.
i default mi assegnano un numero sproporzionato di accessi per
navigare in profondità tra le option e pochissimi accessi per navigare
orizzontalmente nella tabella. qual è l'euristica di design che mi
impedisce di avere dei desideri diversi?
 
potrei essere un po' più daccordo con te se nelle altre applicazioni i
default fossero gli stessi che mi piacerebbe cambiare.
ma se solo provi ad aprire un qualunque foglio di calcolo, scopri che
le freccette navigano nelle quattro direzioni cardinali.
 
piuttosto. comincio a farmi domande sulla reale possibilità tecnica di
ottenere quello che desidero. adesso che comincio a comprendere un po'
meglio il concetto di focus, mi viene il sospetto che, una volta
selezionato l'elemento select, il comportamento della tastiera si
attivi in un modo non sovrascrivibile. aggiungendo un listener si può
aggiungere una nuova azione, ma non bloccare quella precedente.
la funzione preventDefault() sembra partire dardivamente. per esempio,
questo codice è inefficace:
 
function azione(evt) {
  var keyCode=evt.keyCode;
  if (keyCode==39) {
    evt.preventDefault();
    alert(keyCode);
  }
}
 
quando la freccia destra viene premuta, il browser eseguirebbe prima
l'azione di default associata al select e solo dopo l'azione del mio
listener, quando oramai non c'è più nulla da prevenire.
di conseguenza, se in quello che dico non c'è qualcosa di sbagliato (e
lo spero molto), per ottenere quello che voglio, sarei costretto a
riprogettare completamente il select, trasformandolo in una semplice
lista <ul>, da riprogrammare interamente.

 lista <ul>, da riprogrammare interamente.
 
Secondo me dovresti comunque non usare le select, ma una input box con
autocompletamento o simile, oppure un foglio di calcolo (a giro ne trovi
a iosa), dato che le tue necessità mal si sposano con i comportamenti di
default delle select; quindi oltre che violare l'euristica di cui sopra,
non saresti comunque in grado di farlo su Firefox. Ma questo te l'ho già
scritto nel mio penultimo post.
 


la mia impressione personale è che sia il comportamento di default
delle select a disattendere questa regola, non io che lo voglio
modificare.
http://www.far.unito.it/usabilita/Cap5.htm
 
come può un utente attendersi che un 55 o un 56 determino effetti
tanto diversi?
oppure, se voglio rispettare la regola 5, come posso pretendere che
l'utente conosca la combinazione di tasti maiuscolo-TAB (è l'unica
possibilità per tornare indietro)?
 
tuttavia se la tua tesi porta a ricercare un percorso strutturalmente
diverso, credo che tu abbia ragione.
purtroppo ho dei vincoli che non sono assicurano di disporre
concretamente del tempo necessario a imparare questa cosa nuova.
valuterò comunque la possibiltà di implementare una input box o un
foglio di calcolo nel modo che dici.

 foglio di calcolo nel modo che dici.
 
Mi viene da pensare che il foglio di calcolo, per quello che vuoi fare
tu, sia la cosa migliore. Anche perché appunto, in Firefox con le select
al momento più di tanto non puoi fare.
Sicuramente porta via più tempo, ma vi sono diverse cose a giro che puoi
sfruttare – va visto quanto si adattano alle tue casistiche.


oramai abbiamo esaurito largamente la disanima di questo argomento.
tuttavia, concedimi ancora un domanda, fosse pure un po' futile e di
limitata utllità pratica.
 
abbiamo concluso che il comportamento di ricerca delle select è un
default condiviso da tutti i browser. ma si può anche dire che
corrisponda a un vero e proprio standard, ratificato da qualche
specifica previsione normativa autorevole. davvero qualcuno ha scritto
che le select debbano essere abbinate a un motore di ricerca che
capisce 50 quando l'utente digita 55?
 
da buon programmatore nubbio, mi sono rivolto alle select perché, a
norma delle specifiche html401, del 24 dic 1999, rappresentano lo
strumento atto a servire a buon mercato un menù di scelta in un
insieme predeterminato di opzioni. trovo spiacevole vedermi costretto
a cercare una tecnologia alternativa a causa del mero algoritmo di
ricerca abbinato. in questo modo si capisce come mai molti
sviluppatori, in circostanze simili, finiscano per rivolgersi
all'ennesima risorsa ActiveX-only, puntualmente coperta da copyright
che grida vendetta ed è spacciata smaccatamente come ineggabile
vantaggio tecnologico di quell'altro so.
 
:)
ma grazie, e alla prossima.

 ma grazie, e alla prossima.
 
Prego. :)
 
 

alle fine è bastato trasformare i select in input.
 
con gli input l'istruzione preventDefault funziona correttamente.
semmai, è sorto qualche nuovo problema di compatibilità cross-browser
tra firefox e chrome, perché i due browser raccolgono in modo diverso
certi eventi di tastiera.
ma questo è un problema che tratterò successivamente.
 
non ho battuto la strada del foglio di calcolo perché i prodotti
disponibili in rete possiedono caratteristiche sofisticate del tutto
estranee alle mie esigenze. tra l'altro, l'algoritmo con cui elaboro i
dati è particolarmente ostico da trattare con i fogli di calcolo.
 
alla fine il tutto mi è costato meno fatica di quanto credessi. in
fondo, una volta che un programma è impostato in un certo modo, le
modifche locali non ne stravolgono la struttura.
per fortuna che esiste il javascript, non fosse per i bisticci delle
major che fanno di tutto per rovinarti la vita.

 ricerca abbinato.
 
Il discorso e' diverso, quello che vuoi fare tu e' il tipico comportamento dell'autocompletamento, poi con i css lo puoi pure far somigliare ad una select, che vuoi di piu'?
 
E' come lamentarsi di una macchina che' non gallegia solo per il mero algoritmo del fondo non stagno (o del peso, o entrambi.. che ne so).
 
L'idea di base e' che gli strumenti vanno usati il piu' possibile per quello che si e' abituati, pensando sempre che l'utente non pensa e non legge, in un interfaccia reagisce solo quando qualcosa non va nel verso giusto (cioe' atteso).
 
Ripeto non "utonto", ma utente, ogni utente.
 
E' un po' come il concetto di soddisfazione che non e' basato sul risultato effettivo ma dal rapporto attesa/risultato.
Magari la tua idea e' mille volte migliore, ma non e' quello che l'utente si aspetterebbe, quindi la utlilizzerebbe bestemmiando e imprecando contro il programmatore.
 
 
 
 
J.