8. Considerazioni sull'interfaccia utente (User Interface Considerations)
Il numero di apparenza assegnato a una chiamata è un concetto importante che consente alle chiamate di essere gestite da più dispositivi con interfacce utente eterogenee in modo tale da permettere comunque agli utenti di vedere un modello coerente. Un trattamento attento del numero di apparenza è essenziale per soddisfare le aspettative degli utenti. Inoltre, è importante anche il rendering del corretto stato di chiamata/apparenza agli utenti.
8.1. Rendering del numero di apparenza (Appearance Number Rendering)
Poiché diversi UA hanno diverse capacità di interfaccia utente, è comune scoprire che alcuni UA hanno restrizioni che altri non hanno. Una perfetta interoperabilità tra tutti gli UA non è chiaramente possibile, ma con un'attenta progettazione, l'interoperabilità fino ai limiti di ciascun UA può essere raggiunta.
Le seguenti linee guida suggeriscono come il numero di apparenza dovrebbe essere gestito in tre tipiche implementazioni di interfaccia utente.
8.1.1. UA a singola apparenza (Single Appearance UAs)
Questi dispositivi sono limitati dal fatto di avere solo la capacità di visualizzare indicazioni di stato per una singola apparenza. L'UA DOVREBBE (SHOULD) comunque inviare messaggi annotati con il numero di apparenza "1". Qualsiasi indicazione di chiamata per apparenze diverse dal numero "1" DOVREBBE (SHOULD) essere rifiutata con una risposta 480 (Temporarily Unavailable, temporaneamente non disponibile) o 486 (Busy Here, occupato). Si noti che questo significa che un UA a singola apparenza non può rispondere alla propria chiamata all'AOR condiviso, poiché questa chiamata userebbe un secondo numero di apparenza.
8.1.2. UA a doppia apparenza (Dual Appearance UAs)
Questi dispositivi sono essenzialmente telefoni a singola apparenza che implementano l'avviso di chiamata. Hanno un'interfaccia utente molto semplice che consente loro di passare tra due apparenze (interruttore o flash hook) e forse toni udibili per indicare lo stato dell'altra apparenza. Solo i numeri di apparenza "1" e "2" saranno utilizzati da questi UA.
8.1.3. UA ad apparenza condivisa con numero di apparenza fisso (Shared Appearance UAs with Fixed Appearance Number)
Questo UA è il tipico telefono fisso di "classe aziendale". Un certo numero di apparenze sono tipicamente configurate staticamente ed etichettate sui pulsanti, e le chiamate possono essere gestite utilizzando queste apparenze configurate. Qualsiasi chiamata al di fuori di questo intervallo dovrebbe essere rifiutata e non mappata su un pulsante libero. Gli utenti di questi dispositivi spesso si appropriano di numeri di apparenza specifici per le chiamate in uscita, e l'UA dovrà appropriarsi del numero di apparenza e attendere la conferma dall'agente di apparenza prima di procedere con le chiamate.
8.1.4. UA ad apparenza condivisa con numeri di apparenza variabili (Shared Appearance UAs with Variable Appearance Numbers)
Questo UA è tipicamente un softphone o un telefono fisso con interfaccia utente graficamente ricca. In questi casi, anche l'idea di un indice di apparenza può sembrare non necessaria. Tuttavia, affinché questi telefoni possano interoperare con successo con altri tipi di telefoni, è importante che continuino a utilizzare l'indice di apparenza per governare l'ordine di apparizione delle chiamate in corso. Non viene fornita alcuna guida specifica sulla presentazione, tranne che l'ordine dovrebbe essere coerente. Questi dispositivi possono tipicamente effettuare chiamate senza attendere la conferma dall'agente di apparenza sul numero di apparenza.
8.1.5. Esempi di problemi di interfaccia utente (Example User Interface Issues)
I problemi affrontati da ogni stile di interfaccia utente sono facilmente visibili in questo esempio:
-
Una chiamata arriva al gruppo di apparenza condivisa e viene assegnato il numero di apparenza "1". Tutti gli UA dovrebbero essere in grado di rendere all'utente l'arrivo di questa chiamata.
-
Un'altra chiamata arriva al gruppo di apparenza condivisa e viene assegnato il numero di apparenza "2". L'UA a singola apparenza non dovrebbe presentare questa chiamata all'utente. Altri UA non dovrebbero avere problemi a presentare questa chiamata in modo distinto dalla prima chiamata.
-
La prima chiamata si conclude, rilasciando il numero di apparenza "1". L'UA a singola apparenza dovrebbe ora indicare nessuna chiamata poiché è incapace di gestire chiamate diverse dalla prima apparenza. Entrambi gli UA ad apparenza condivisa dovrebbero mostrare chiaramente che il numero di apparenza "1" è ora libero, ma che c'è ancora una chiamata sul numero di apparenza "2".
-
Una terza chiamata arriva e viene assegnato il numero di apparenza "1". Tutti gli UA dovrebbero essere in grado di rendere all'utente l'arrivo di questa nuova chiamata. Gli UA a più apparenze dovrebbero continuare a indicare la presenza della seconda chiamata, e dovrebbero anche assicurarsi che l'ordine di presentazione sia correlato al numero di apparenza e non all'ordine di arrivo delle chiamate.
8.2. Rendering dello stato della chiamata (Call State Rendering)
Gli UA che implementano la funzionalità di apparenze condivise hanno tipicamente un'interfaccia utente che fornisce lo stato di altre apparenze nel gruppo. Quando vengono elaborate le NOTIFY di stato del dialogo dall'agente di apparenza, queste informazioni possono essere renderizzate. Anche l'interfaccia utente più semplice ha tipicamente tre stati: inattivo, attivo e in attesa. Lo stato inattivo, solitamente indicato da lampada spenta, è indicato per un'apparenza quando il numero di apparenza non è associato ad alcun dialogo, come riportato dall'agente di apparenza. Lo stato attivo, solitamente indicato da lampada accesa, significa che un numero di apparenza è associato ad almeno un dialogo, come riportato dall'agente di apparenza. Lo stato in attesa, spesso indicato da una lampada lampeggiante, significa che lo stato della chiamata dal punto di vista dell'UA nel gruppo di apparenza condivisa è in attesa. Questo può essere determinato dalla presenza del tag di funzionalità "+sip.rendering=no" [RFC3840] con l'URI target locale. Si noti che lo stato in attesa dell'URI target remoto non è rilevante per questa visualizzazione. Per i dialoghi uniti, lo stato viene renderizzato come in attesa solo se tutti gli URI target locali sono indicati con il tag di funzionalità "+sip.rendering=no".