SketchFlow: realizzare prototipi “multi-user”

Penso che a tutti voi sia potuto capitare di dover progettare un’applicazione che preveda la fruizione da parte dell’utente in più modalità/utenti diversi. Mi spiego meglio, uno dei requisiti progettuali potrebbe essere quello di ipotizzare a seconda che un utente si sia loggato come “Administrator” e/o utente “Standard” di abilitare funzionalità e schermate diverse dell’applicazione.
Una delle difficoltà che si potrebbero incontrare nel progettare un’applicazione di questo tipo, potrebbe essere quella di non riuscire a prototipizzare in modo dinamico ed efficace le funzionalità che dovranno essere poi implementate nel progetto finale. Sempre inerente a queste funzionalità, riprendo un mio post di settimana scorsa in cui segnalavo la disponibilità di alcuni “bahavior” utili per abilitare in un progetto SketchFlow le funzionalità di “Conditional Navigation”, vi ricordate? Si modificava il comportamento collegato ad un “button” a seconda che si interagiva o meno su un “checkBox” prima di cliccare sul button.
Trovate l’esempio visualizzabile attraverso lo SketchFlow Player a questo link.

Ma torniamo a questo nuovo scenario, in questo caso il tutto risulta implementato attraverso l’uso degli “states” e del “Visual States Manager”. Attraverso una serie di behavior lo SketchFlow Player sarà in grado di “registrare e memorizzare” il comportamento dell’utente e proporre dei contenuti specifici a seconda del profilo attivato.

Vi invito a visualizzare un semplice esempio con il prototipo implementato disponibile a questo link.
Mentre il progetto completo in Blend 3 e i behavior utilizzati nel progetto nei rispettivi link. 

Come illustrato, se selezionate una o l’altra modalità di accesso interagendo con i “radio Button” [bullet 1], viene memorizzato in questo caso lo "states" con cui state accedendo [bullet 2] e nel momento in cui accedete sullo “Screen 2” [bullet 3 all’interno dello SketchFlow Player] vi verrà attivato il contenuto definito all’interno dello “states” corrispondente definito attraverso il Visual State Manager - nello specifico un "ComponentScreen" definito in un file XAML esterno (“StandardUI.XAML” e “AdminUI.XAML”).

Per capire la logica dell’esempio vi invito a guardare insieme l’interazione definita attraverso l’uso dei behavior che dietro le quinte non fa altro che memorizzare o meno lo “states” in cui si trova l’applicazione e a seconda dell’interazione dell’utente attivare o meno gli “states” ad esso associati.

Iniziamo analizzando l’”Object Tree” dello “Screen 1”. Come vedete allo “UserControl” principale è applicato un behavior “SetGlobalStateAsVisualState” che associa al Loaded dell’applicazione un GlobalStateTag “Default”. Per rendere la cosa più comprensibile, ho creato uno screen shot dove sono rappresentati “side by side” i due panel.

Se andiamo avanti con l’analisi degli elementi che costituiscono l’applicazione, notate che hai 2 radioButton sono associati altri due behavior che non fanno altro che “memorizzare” come attivo lo stato associato al behavior.

Osservate il pannello degli “States” [1] associati a questa pagina e definiti all’interno del Visual States Manager, noterete che sono attualmente presenti due stati “Standard” e “Admin”, i quali non fanno altro che attivare e/o disattivare il “radioButton”. Banalmente nello “states” è stata associata la proprietà “radioButton” IsChecked [2].

Infine potete notare, sempre dall’Object Tree, alle due label in alto a destra dell’interfaccia sono associati 2 semplici behavior “ChangePropertyAction” [1] che non fanno altro che modificare la property “foreground” dei due controlli “TextBlock” sempre in relazione al “GlobalState” attivato. In questo caso è stata modificata anche la tipologia di Trigger (TriggerType) che viene proposta di base dal behavior interagendo sul bottone “NEW” [2].

 Nell’immagine qui sotto potete vedere la maschera per definire il nuovo “TriggerType”.


Passiamo quindi velocemente ad analizzare come sono strutturati i behavior e i controlli che caratterizzano “Screen 2”. Rappresentato nella SketchFlowMap, a “Screen 2” sono agganciati due “ComponentScreen” il cui comportamento viene gestito attraverso il “Visual States Manager”.



Se andiamo ad analizzare gli elementi contenuti nell’Object Tree, vi renderete conto che in questo caso il tutto è molto più semplice. Nel Visual States Manager sono stati definiti i 3 stati che non fanno altro che attivare e disattivare i ComponentScreen e le label (TextBlock) che indicano in quale “user mode” l’utente sta fruendo dei contenuti. Selezionando uno stato o l’altro - vi consiglio di fare attenzione al pannello delle “Opacity”, noterete che a seconda che sia attivato/disattivata una modalità di navigazione “Standard/Admin” viene modificata la proprietà di “Opacity” associata. Nello “screenshot” riportato qui sotto, stato attivato lo states “Admin” [1] e se selezioniamo sull’ObjectTree il “ComponentScreen” standardUI [2] risulta applicata una properties di “Opacity=0”.



Per concludere, se andiamo a vedere le proprietà associate ai due behavior sullo UserControl principale, “MapGlobalStateToState” - in relazione al GlobalState che viene ereditato dalla scelta che l’utente ha fatto sullo “Screen 1” si attiva lo “states” corrispondente nel VisualStatesManager.

Vi invito quindi a fare il download dell’esempio, disponibile a questo link e ad aprirlo con Blend per provare dal vivo le funzionalità descritte in questo articolo. Facendo [F5] da tastiera vi verrà caricato lo SketckFlow Player all’interno del browser di testing.

Colgo l'occasione per ringraziare inoltre il mio collega Christian Schormann da cui ho preso ispirazione per scrivere questo post, sul suo blog trovate una serie di dettagli in più sull'esempio dal punto di vista dello sviluppo.