On 01/03/2015 11:09 AM, Stefano De Carlo wrote: > Il 03/01/2015 10:22, Elena ``of Valhalla'' ha scritto: >> On 2015-01-02 at 23:30:32 +0100, Giuliano G wrote: >>> Io sposterei l'attenzione su quale parametro sia più comodo da inserire per >>> l'utente, tanto poi prendendo l'altitudine s.l.m. da db esterni si può >>> ricavare sia altezza del nodo dal suolo che quella s.l.m. >>> >>> Credo quindi che l'altezza dal suolo del nodo sia più semplice da inserire >>> x l'utente. >> ma così l'utente che vuole sapere a che altezza sia il nodo deve >> poi fare più fatica per andare a prendere l'altitudine s.l.m. e sommarla >> all'altezza dal suolo inserita, e così come idea mi pare che >> il dato venga inserito una volta e letto tante, non è meglio ottimizzare >> per la lettura? >> >> (mi chiedo se valga la pena di mettere i due campi e ciascuno inserisce >> quello che si sente di inserire, ma almeno si sa che dato sia) > Inserimento: > - Altezza s.l.m., dato recuperabile con precisione da risorse esterne in > funzione di un input *già fornito* dall'utente, ovvero le coordinate. > Richiedere in input manuale un dato con precisione arbitraria, quando lo > stesso è dato è reperibile automaticamente, con precisione nota e coerente, è > pessima UX. [1] > - Altezza rispetto suolo, è sia il dato che più ovviamente [2] l'utente si > aspetta di *poter* inserire, sia quello più utile ad eventuali funzionalità > aggiuntive come il calcolo della fattibilità del link (perché non reperibile > in modi diversi rispetto all'input dell'utente). > - Elaborando su quanto prima: la percentuale di utenti che NON inserisce > alcun dato sull'altitudine è infinitamente superiore al combinato di chi > inserisce l'altitudine (qualsiasi tipo). Anche posto che qualcuno sia deciso > sul significato della richiesta (che è ambigua), rispondere richiedere il > lavoro extra di reperire l'altitudine. Che la maggior parte, basta cliccare a > caso 10 volte sui nodi del map server per vederlo, non intraprende. Un > inserimento dell'altitudine rispetto al suolo è estremamente più triviale per > l'utente e pertanto credo che porterebbe ad un maggior uso della > funzionalità, con conseguenti lampanti benefici per il map server e eventuali > feature aggiuntive. > - La mia implementazione preferita sarebbe un dropdown di equivalenza del tipo > Livello Suolo / 0-4 metri > Primo Piano / 4-8 metri > Secondo Piano / 8-12 metri > [...] > Tetto / [casella] metri > in modo da evitare tutte le possibili diverse nomenclature che ci sono > attualmente (pt, piano, metri, mt., m, ecc, balcone, terrazzo) e poter > parsare il contenuto se serve.
Bella, quello che posso fare senza complicare troppo le cose è precompilare il form di aggiunta di un nuovo nodo con l'altezza del suolo preso da un webservice esterno - così come sulla nuova versione di nodeshot avviene già con l'indirizzo -, in modo che l'utente possa poi addizionare in modo approssimativo l'altezza del palazzo, ma si presuppone che quando si monteranno le antenne si inseriranno i dati precisi di come le antenne saranno posizionate (incluso azimuth), anche se la possibilità di gestire queste informazioni nel frontend verranno sviluppate in una fase successiva quindi eviterei di scendere nel dettaglio in questo momento. All'inizio era abbastanza frequente controllare ed inserire quel campo aiutandosi anche con il GPS mentre si montavano le antenne, poi però abbiamo perso l'abitudine perchè in effetti oggi come oggi avere quell'informazione o non averla non cambia molto la vita, mentre se potessimo far fare dei calcoli automatici o fare delle rappresentazioni su mappe 3D saremmo pù motivati ad inserire valori corretti. Un passo alla volta però... Nemesis
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless