Ragazzi vi porto la mia esperienza nella pianificazione dei nodi.Personalmente 
ho sempre notato che l'inserimento o meno del parametro dell'altitudine non mi 
sia servito mai a nulla nel verificare la fattibilità di un link, mentre 
l'unica cosa che mi è sempre servita e che ha portato al goal sono stati due 
fattori indispensabili : 
1) che la posizione dei nodi fosse molto molto precisa, sia di quelli già 
attivi che dei potenziali;2) che su entrambi i nodi venissero fatte delle 
accurate foto panoramiche, non necessariamente un'unica foto panoramica, fatta 
dalla più alta sommità del proprio palazzo.
Secondo me se non si usano uno di questi due parametri al posto di un'altro, ad 
esempio si sostituiscono le foto al s.l.m. automaticamente non si ha la 
percezione di com'è messo il palazzo del potenziale rispetto ad un altro o 
rispetto ad un nodo già attivo e quindi ci potrebbero essere casi in cui 
entrambi i nodi siano su palazzi molto alti ma tra di loro ci siano ostruzioni 
non capibili bene dalle mappe, metti caso alberi, tralicci, altri palazzi più 
alti ecc.ecc.ecc.
Molto meglio, secondo me, installare subito un palo con una bella bandiera 
distinguibile da lontano con un binocolo.Su alcuni nodi di roma prendiamo come 
punti di riferimento grossi edifici colorati o particolari per poi piano piano 
con un binocolo andarci a ritrovare il palazzo e l'antenna.
Un buon sopralluogo è l'unico modo per pianificare un buon nodo !
Federico.

Date: Sat, 3 Jan 2015 11:09:52 +0100
From: stefana...@gmail.com
To: wireless@ml.ninux.org
Subject: Re: [Ninux-Wireless] Elevazione (sulla mappa)

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.
 
Stefanauss.
 
[1] http://zachholman.com/posts/shit-work/
[2] http://en.wikipedia.org/wiki/Principle_of_least_astonishment
 

_______________________________________________
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless                                   
  
_______________________________________________
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Rispondere a