Skip to topic | Skip to bottom
Home

Tesi
Tesi.BehaviorPatternsTemplater1.8 - 23 Oct 2008 - 22:25 - ElenaSarti?topic end

Start of topic | Skip to actions

BehaviorPatternsTemplate

Obiettivo della tesi è creare un ambiente di authoring per comportamenti dinamici... -- FabioVitali - 29 Sep 2008

Punto di partenza…

L'approccio che ho adottato è stato quello di analizzare il problema inizialmente da un punto di vista del tutto astratto. Il sistema che devo andare a "completare" gestisce un file Word creando una o più pagine html e codice Javascript. La struttura quindi prevede una contesto unico che è poi suddiviso in pagine. Procedere con questa divisione concettuale è utile per svolgere la mia analisi sugli effetti e sulle animazioni che possono essere inserite, in quanto è necessario identificare su cosa questi effetti verranno realmente applicati. Continuando quindi su questa linea di ragionamento possiamo identificare un livello inferiore al concetto di pagina, cioè una sezione di una pagina, per arrivare infine ad un unico elemento al suo interno, come un testo, un'immagine ecc...

intero contesto alcune pagine pagina (pagina html normale o popup) sezione di pagina (div, span...) elemento (testo, immagini, table, form...)

Questi quattro sono come gli "oggetti" su cui l'utente può agire, dopo averli creati, ognuno ha un range di funzionalità ed effetti a disposizione.

Questa separazione concettuale può ricordare un albero gerarchico, quindi nasce il problema di gestione della "gerarchia" dei comandi. Senza entrare già nei dettagli, mi si è posto un interrogativo: dopo aver definito a che livello applicare un effetto (pagina, elemento...) come si gestisce l'esistenza di due comandi su una stessa cosa che sono contradditori tra loro? E' nata qui l'idea di un parallelismo tra questo e i css, la soluzione a questo problema è risolta dalla proprietà a cascata, quindi in caso di regole contradditorie vale quella definita a livello minore. Ad esempio se c'è un conflitto tra pagina ed elemento, vale la regola definita per l'elemento.

Per tutti gli altri tipi di problemi sono solo l'interfaccia e i controlli a livello di applicazione che devono prevenire l'errore, impedendo all'utente di definire regole che non possono coesistere, come uno scorrimento di un testo che parte da destra, e uno che parte da sinistra.

Ora entro più nel dettaglio, ecco alcune macroaree degli elementi a disposizione:

- testo: la formattazione del testo è fornita dallo stesso Word, le cose che si possono aggiungere sono effetti di movimento, come lo scorrimento in entrata dalle varie direzioni, e gli effetti grafici come il testo lampeggiante, sfumato e simili.

- link: testuali bottoni

- immagine

Ecco ora alcuni esempi di sezioni di pagina, che in alcuni casi possono essere aggregati di elementi singoli elencati in precedenza:

- galleria immagini: slideshow (fade, scorrimento in entrata....) popup cross-browser per mostrare lo zoom di miniature testo alternativo

- form / drag and drop (es. trascinamento di un prodotto in un carrello): sono entrambi modi per selezionare qualcosa ed eventualmente inviare informazioni attraverso l'utilizzo di un metodo Post. I form comportano l'utilizzo di menu a tendina, select...

Gli effetti e le animazioni in generale comportano l'analisi di alcune proprietà ad essi associati, in particolare ci sono due ambiti:

Fattore tempo:

- durata

- ripetizione o no

- evento (tempo 0, tempo x, conseguenza di un'azione o di un evento)

- velocità

Fattore spazio:

- area di azione delimitata

- traiettoria di movimento

- visibilità iniziale e finale

- sovrapposizione o no?

Con la sovrapposizione nasce il concetto di livello (come in Photoshop), questo fa aumentare molto il livello di complessità dell'applicazione, non solo dal punto di vista implementativo, ma anche dal punto di vista di usabilità, quindi di interazione uomo-macchina. E' molto importante decidere se gestire anche questa cosa, ma questa è una decisione che credo possa essere presa solo a un livello di avanzamento maggiore della tesi, quando ci si è già scontrati con i problemi a livello più basso.

La vera domanda da porsi a inizio lavoro è il target di utenti e non utenti a cui rivolgere l'applicazione...si prevede che gli utenti abbiamo un certo livello di conoscenza informatica e se sì a che livello? Da non dimenticare che: "Non esiste l'utente medio".

-- ElenaSarti? - 30 Sep 2008

  • schema gerarchico:
    schema gerarchico

Discorsi in sospeso:

Abbiamo introdotto il discorso dei percorsi alternativi attraverso la metadatazione.

Per le mappe l'idea è quella di utilizzare l'editor grafico di word per permettere all'utente di selezionare le aree, queste forme devono poi essere distinte dalle altre nate dalla funzionalità classica, ad esempio utilizzando un tratta speciale come a puntini e un colore particolare.

Punto della situazione al 23 Ottobre:

E' necessario valutare in quale modo gli aspetti dinamici possano essere applicati a porzioni di documento. Ci sono due modi possibili da "implementare": atraverso una macro (barra degli strumenti, maschere...) oppure attraverso annotazioni direttamente nel codice. La barra degli strumenti comprende semplice pulsanti oppure maschere che permettono l'inserimento e scelta di parametri e valori.

Uno dei dubbi che nasce immediatamente riguarda la differenza tra questi due metodi; come e' facile da intuire, utilizzare annotazioni e' una cosa rischiosa in quanto porta con se' un certa complessita' e facilita' di errore. Le annotazioni possono essere paragonate un po' alla programmazione, se il presupposto e' che gli utenti non abbiamo competenze particolari, e quindi lo scopo sia fornire uno strumento accessibile a tutti, l'utilizzo di queste annotazioni deve essere facilitato e resa intuitivo. In alcuni effetti i parametri in gioco sono tanti, e attraverso maschere e' accettabile dare la possibilita' all'utente di definire almeno in buona parte queste variabili. Come presupposto importante c'e' comunque l'idea di settare sempre un valore di default per non appensantire necessariamente l'utilizzo dell'utente. Traslando questo comportamento nell'altro metodo di definizioni degli effetti, cioe' le annotazioni, nascono un po' di problemi; non e' possibile conciliare la semplicita' con l'elasticita', vista com potere decisionale dell'utente sulle variabili in gioco. Credo che sia necessario arrivare ad un compromesso, cioe' l'utilizzo di annotazioni, ma cevitando la gestione delle variabili in gioco da parte dell'utente. A questo viene in aiuto il discorso fatto in precedenza sui valori di default, in caso di annotazione le variabili dei comportamenti avranno assumeranno il valore di default senza possibilita' di modifica. Questa scelta puo' essere il compromesso migliore per avere un servizio che risponda bene ai requisiti di accessibilita'.

Deciso quindi la doppia implementazione è necessario avere una linea di ragionamento equivalente per entrambi i metodi. Prima si tutto è necessario capire come annotare in mezzo al codice che crea Word i nostri riferimenti.

Studiando lo standard utilizzato in Word 2007 ci sono alcune cose che potrebbero fare il caso nostro. Quella a cui sembra meglio dare più attenzione è l'elemento "CustomXml"; questo elemento permette di taggare una parte di contenuto e identificarla univocamente attraverso un Uri e un attributo chiamato Element. E' anche possibile aggiungere altri attributi in modo da poter annotare tutte le informazioni che ci servono in fase di implementazione e che l'utente puo' settare.

Si tratta ad esempio di un tipo di effetto piuttosto che un altro nella comparsa di un contenuto, oppure la dimensione di un'immagine ingrandita attraverso lo zoom ecc... Usando questo strumento è possibile associare a Word un nostro xml schema e quindi avere il pieno controllo delle annotazioni che facilita molto la fase di implementazione e parsing all'interno di Isa del documento salvato in word.

Questo è sicuramente possibile in Word 2007, e dovrebbe esserlo anche nel 2003, infatti sarebbe ragionevole utilizzare lo stesso strumento di annotazione per entrambi, sia per coerenza che per riutilizzo del codice che parserà le informazioni.

Abbiamo ora un possibile strumento, è necessario vedere se calza bene sia nel caso dell'utilizzo di macro, sia nelle semplici annotazioni manuali.

In caso di macro ovviamente funziona perfettamente, in quanto attraverso pulsanti e maschere il codice viene fatto da "noi", quindi non ci sono problemi.

Nel caso si annotazioni invece la situazione si complica, un'utente deve avere la capacità e le intuizioni di aprire e chiudere un tag per delimitare un contenuto; questo non credo sia una cosa usabile.

Una seconda proposta che ovvia a questo problema è usare i commenti, sia Word 2003 che 2007 permettono di selezionare codice e allegare un commento a questo. Usando questo strumento l'utilizzo con le macro non cambia, ma cambia notevolmente la prospettiva per le annotazioni manuali senza nessuna toolbar.

Word traduce questi commenti in un modo non molto "elegante", come era facile aspettarselo, al contrario del metodo precedente in cui tutto segue un nostro schema xml, ma comunque parsabile senza troppe difficoltà.

Per le annotazioni manuali risulta molto più facile e intuitivo utilizzare i commenti attraverso una semplice sintassi.

Ecco in seguito un breve esempio:

effetto:tipo (parametri)

Effetto è un requisito fondamentale ovviamente, mentre tipo e parametri sono opzionali. Facciamo un esempio pratico in cui ho una lista e voglio far comparire i contenuti in modo sequenziale. Voglio che il contenuto sostituisca il precedente e che la comparsa avvenga con un effetto sfumato; l'annotazione sarà:

sequenza:sostituzione (sfumato)

In questo breve documento ho mostrato il punto della situazione di ciò che abbiamo analizzato fin'ora con pro e contro, bisogna ora valutare quali siano le scelte migliori e che siano più compatibili con l'idea che avete del mio lavoro. Forse è necessario identificare per bene un utente di riferimento da cui partire.

Mi scuso per l'italiano, ma ho scritto un po' di fretta. stick out tongue

-- ElenaSarti? - 23 Oct 2008
to top

I Attachment sort Action Size Date Who Comment
schemaoggettitesi.JPG manage 23.1 K 30 Sep 2008 - 16:04 ElenaSarti? schema gerarchico
esEffetti.zip manage 619.5 K 15 Oct 2008 - 10:33 ElenaSarti?  
esvideoflash.rar manage 5.6 K 13 Oct 2008 - 22:29 ElenaSarti? esempi di implementazioni

You are here: Tesi > BehaviorPatternsTemplate

to top

Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Fabio's Wiki? Send feedback