La funzione UNDO

  • Gli UNDO rudimentali sono sempre presenti: nei word processor l'utente può sottoporre un UNDO per recuperare da un errore (il sistema cancellerà l'ultimo carattere digitato).
  • Per tutti i caratteri digitati, in un text-editor, vi è la possibilità di effettuare un UNDO.
  • Ci sono, comunque, delle limitazionida: non è possibile effettuare un UNDO o digitare un carattere al di fuori rispetto la linea corrente.
    La funzione UNDO in un Text-Editor

  • Tutti gli utenti commettono degli errori. I text-editor abilitano gli utenti a correggerli (ancge se alcuni errori possono essere rivelati dopo un lungo tempo).
  • I text-editor consentono all'utente di correggere un numero di errori analogo a quelli commessi (se così non fosse, tali sistemi non aiuterebbero a scrivere un testo corretto).
  • Qualche volta si commettono errori correggendo errori (in questo caso si avrà bisogno di un REDOING).
  • Qualche volta il testo è interpretato dal programma. Se il testo è sbagliato anche la sua interpretazione lo sarà. Pertanto sorge una domanda: come fa l'utente a correggere un comando eseguito erroneamente?
    Cambiamenti nel tempo

  • Se il sistema tiene una traccia della interazione ci sono vantaggi sia per il progettista che per l'utente. La traccia può essere usata esplicitamente.
  • Si potrebbe pensare alla realizzazione di un METAEDITOR ? Per far questo, perchè non compilare la storia dell'interazione dell'utente?
  • La traccia è fatta di una sequenza di comandi registrati nel modo in cui sono stati emessi, possiamo compilare tale sequenza e fare degli UNDO su alcune componenti della sequenza.
  • Per una interfaccia grafica la traccia può essere di tipo testuale o grafico a seconda degli oggetti considerati.
  • La traccia incrementa la sicurezza: se il sistema cade in crash, la sequenza registrata viene rieseguita ottenendo i stessi risultati raggiunti.
  • L'ultimo comando, che ha provocato il crash, non deve essere eseguito.
  • I comandi sono suddivisi in due categorie: 1) convenzionale (eseguito come sottoposto) e 2) registrazione nella traccia: quando viene fatto un UNDO l'utente cambia la traccia, il sistema azzera l'ultimo controllo e riesegue la traccia includendo le modifiche apportate dall'utente.
  • L'esecuzione di un UNDO talvolta richiede un tempo elevato.
    Necessità legate all'interfaccia utente

  • Gli utenti possono essere programmatori o no, pertanto il comando UNDO deve adempiere ai bisogni di utenti casuali.
  • Il comando UNDO deve essere semplice: dovrebbe essere più semplice del comando di reversibilità del comando sbagliato.
  • Alcuni comandi dovrebbero avere degli UNDO specifici. In altri casi l'UNDO dovrebbe essere "più agile e veloce": se si è digitato un carattere non voluto si potrebbe preferire usare il comando DELETE che una procedura standard di UNDO.
  • Il comando UNDO dovrebbe essere generale, inoltre dovrebbe poter essere sempre eseguito e non solo per certi casi (es: dopo che si è scoperto un errore).
  • Per l'UNDO devono essere fatte limitazioni chiare e sensate. Alcuni comandi possono inibire gli UNDO seguenti.
  • Lo scopo di UNDO non dovrebbe avere restrizione, in quanto non sempre si individuano gli errori immediatamente. Inoltre il numero di funzioni di UNDO possibili deve essere almeno pari a quello dei comandi presenti.
  • Gli UNDO più utili devono essere identificati da un nome costante in tutte le parti del sistema o della tastiera (come ESCAPE o CONTROL).
    Il copione di Archer, Conway, Schneider

  • L'utente esegue dei comandi, ogni azione viene scritta nel copione, ed in seguito viene sottoposta per l'esecuzione. La sequenza di comandi può essere manipolabile.
  • L'utente sottopone il comando c1 poi c2 poi c3 ; l'utente ricorderà che la sua storia dell'interazione è:
    "...c1 c2 c3"
    Archer, Conway, Schneider

  • Se si esegue il comando c3 e poi si vuole togliere, si potragrave; utilizzare un UNDO e si ritornerà "come se " la sequenza fosse c1 c2. Abbiamo utilizzato il "come se" in quanto la sequenza reale è:
    c1 c2 c3 undo
  • Storia: nota completa di quello che l'utente ha fatto (c1 c2 c3 undo).
  • Copione: nota di interazione che il sistema tratta come la sua storia effettiva. La scrittura dipende dal sistema e può essere più semplice o più complessa della Storia.
  • Stato: l'equivalenza classificata di scritture (es: c1 c2 c3 undo è equivalente ad undo c2; la storia ed il copione sono diversi ma lo stato finale è lo stesso.
  • Arciere, Conway e Schneider nel 1984, suggerirono un modello di copione che considera l'utente come un "costruttore/autore del copione" ed il sistema come un "interprete della scrittura).
  • L'interfaccia ruota tra l'editing e l'interpretazione del copione; il primo generalmente termina con ENTER mentre il secondo termina quando il controllo è a ridosso dell'utente.
    Capire l'ACS

  • L'utente "gioca" con il copione, appende e cambia quello che è stato digitato. Di soliti effettua due tipi di operazione la compila e l'esecuzione: in primo luogo, l'utente sottopone n comandi, poi crea il copione S:
    c1 c2 c3.......cn.
  • Il sistema può eseguire fino a un comando intermedio, ci-1 così che la sequenza si spezzi in:
    c1,c2,.....,ci-1 e ci,ci+1,...., cn.
    comando eseguito E comando pendente P
  • P.s.: i comandi possono essere lettere, parole, click del mouse, funzioni associate al testo...
    Modifiche

  • Alla notazione sopra vista possiamo aggiungere la nozione di testo modificato M e non modificato (U). Potremmo avere, per esempio, il caso:
    S'=c1....cn
    c1 c2...cj-1 and c'j c'j+1...c'n'
    cioè: S' = U'M'
    Strategie dell'esecuzione

    Abbiamo che:
  • La strategia dell'esecuzione è completa se alla fine l'esecuzione avremo: P vuoto ed E=S.
  • La strategia dell'esecuzione è parziale se P è non vuoto o E diverso da S
  • Le strategie dell'esecuzione possono essere complete o parziali.
  • Nel caso non vi sia un UNDO U' non sarà uguale ad S ed M' sarà una dilazione S.
  • Vi è un copione preffissato se all'utente è negata la possibilità di cambiarlo.
  • La strategia della modifica della scrittura si estende se alla fine di ogni compilazione avremo U'= S.
    Il concetto di consistenza

  • Se si parte da uno stato in cui E non è un prefisso di U' M', tale stato verrà detto: stato incoerente.
  • Possiamo cambiare il copione e non la storia.
    Modifiche di scrittura

  • Riguardo gli editor si possono fare alcune restizioni: al minimo l'utente può solo appendere al copione, al massimo può aggiungere e rimuovere qualche comando.
  • Un sistema capace di maneggiare il copione, in modo arbitrario, è detto essere completo.
  • Un sistema con un checkpoint viene definito come modificatore di un blocco-traccia: dopo la modifica M' è vuoto ed U' deve finire con un checkpoint.
  • Alcuni sistemi permettono di avere checkpoint multipli altri considerano l'origine come un unico checkpoint.
  • Il sistema dovrebbe amministrare il checkpoint (consentire modifiche in zone non riservate).
  • Una singola-traccia permette di aggiungere un comando (appendere) o annullare l'ultimo comando.
  • Una traccia è comoda se l'operazione di recupero viene eseguita sull'ultimo comando (la traccia può, essere esageratamente grande e recuperare un comando a monte risulta essere impresa non sempre facile).
  • L'uso della traccia aiuta ad un basso utilizzo dell'STM.
    Riguardo la classificazione

  • Questa classificazione non presume un UNDO omogeneo (che raramente esiste, es.: HyperDoc), alcuni comandi possono essere soppressi semplicemente (inserzione della lettera), altri sono più difficili (blocco cancella), altri sono impossibili (spostamento e formattazione del testo nei vecchi word processor).
  • Un trucco comune è queelo di provvedere ad singolo-traccia con un comando UNDO che consenta di appendere al copione in tal caso avremo un FLIP-UNDO (l'ultimo UNDO annula l'effetto dell'UNDO precedentemente effettuato).
    Osservazioni

  • Un FLIP UNDO ha senso se "tutti comandi devono essere trattati in maniera uguale". Tutti i comandi devono essere recuperati compreso l'UNDO stesso.
  • La ragione perchè UNDO non venga trattato uniformemente è dovuta a scelte fatte dai progettisti che ritengono un UNDO relativo solamente all'ultimo comado immesso.
  • Perchè UNDO non vale per tutti i comandi ?
    Osservazioni su UNDO

  • L'UNDO può essere simbolico: l'utente specifica un UNDO di molti comandi; oppure un UNDO manipolativo: viene manipolato il copione.
  • Si può mostrare il nome del comando fino al quale l'utente vuole fare un UNDO oppure mostrare contemporaneamente tutto l'iter dei comandi immessi.
  • Si può mostrare una versione della sessione sia per l'UNDO (indietro di un comando) che per il REDO (avanti di un comando).
    Side effect

  • UNDO lavora correttamente se non viene cambiato alcuna cosa del sistema, alcuni comandi sono molto difficili da recuperare (per esempio nelle e-mail: dopo una SEND, per l'invio della posta elettronica, l'utente non può più recuperare a tale comando).
  • I comandi tempo-dipendenti, in particolare, hanno side effects: non si può tornare indietro nel tempo !
  • I comandi tempo-dipendenti dovrebbero essere valutati in modalità lazy. Se viene richiesto un UNDO, la modalità lazy consente di sospendere l'operazione prima ancora di elaborare i dati/comandi.
  • Un aimplementazione laziness può differire l'azione reale per cambiare la sequenza di comandi.
    Parametri impliciti ed espliciti dei comandi

  • UNDO e REDO dovrebbe lavorare come parametri espliciti. Ci sono dei comandi, al contrario, come default dell'uso, azioni legate allo stato corrente, ec... che rendono un operazione di REDO molto confusa.
  • Esempio: richiediamo un UNDO sull'ultimo comando (un cancella linea "corrente" - dove "corrente" è dipendente dallo stato e dato come comando implicito) poi digitiamo altrove nel testo una nuova linea, infine si compie un REDO. Quale linea sarà cancellata?
    La definizione di "corrente" è obbligatorio.
  • Per fare un REDO senza ambiguità dobbiamo legare parametri a oggetti o valori e non a nomi ("corrente", "più spesso", ecc...).
  • Alcuni sistemi grafici usano coordinate relative/assolute che qualche volta sono implicite (o forse sono nei file di preferenze).
    Undo Skip Redo

  • Il modello del copione proposto da A.C.S. non è adeguato per un completo utilizzo di UNDO/REDO.
    Consideriamo il copione: c1c2c3
    facciamo un UNDO dei comandi c3 e c2 (salvati in uno stack tampone atto per eventuali REDO) allora sottoponiamo c4 ad comando e REDO c2 c3
    il risultato è un copione come:c1c4c2c3
    Si supponga, ora, di voler tornare a c1c2.Il modello ACS consentirà di fare i passi descritti nella figura che segue:
    Undo Skip Redo

  • Lo stato precedente c1c2 non può mediante UNDO e REDO. Il modello ACS non soddisfa queste carratteristiche in quanto propone un copione "lineare"
  • Il problema è stato risolto nel 1984 da Vitter che introdusse le funzioni UNDO, SKIP e REDO, il cui acronimo può essere:
    U S e R
    Vitter

  • Un particolare comando può essere rieseguito in tempi diversi. I comandi sono visti come nodi e la successione dei comadi viene registrata nei percorsi del grafo.
  • Vitter utilizza un grafo aciclico diretto (DAG).
  • Il copione di Vitter risulta essere un DAG che rappresenta solamente il percorso dei comandi successivi che vogliono essere eseguiti e non la storia completa.
  • L'utente sceglie quale figlio aggiungere ad un nodo padre, evitando di immagazzinare tutte le scelte possibili dell'utente.
  • Il modello di Vitter può risolvere la sequenza c1c2
    All'inizio abbiamo c1c2c3 il segno di quadri indica l'ultimo comando sottoposto:

    la storia mostra la sequenza completa dei comandi sottoposti; la scrittura mostra il DAG del modello Vitter con lo stato corrente del sistema; infine verrà segnalato lo stato. Operando due UNDO otterremo l'annullamento dei comandi c3 e c2 come risulta in:

    il comando UNDO non è presente nel copione di Vitter, Il copione di Vitter semplifica la storia di quello che l'utente ha fatto ed lo stato che l'utente ha raggiunto.
    L'utente si trova nello stato c1 proprio come se l'utente avesse sottoposto solamente comando c1!
    Presumiamo ora che l'utente digiti il comando c4, ottenendo:

    L'Utente può essere aiutato lasciandogli la possibilità del modo in cui ordinare i figli di un nodo (più, recente, più, frequente, ecc...)
    Cercare di recuperare

    Ora l'utente sottopone due redo ottenendo:
    Undoing

    Ora l'utente vuole tornare a c1 c2.
    Redoing

    Prima scelta

    Generalità del modello

  • In ogni caso questo modello non è tanto generale per consentire la cancellazione o sostituzione dei comandi; si supponga che l'utente voglia raggiungere stato c1 c3.
  • Si desidera un resubmit. Si usa un redo e ci si accorge che il problema è nel fatto che c3 non è un successore (solamentw c2 e c4 sono successori).
  • Si richiede pertanto un comando di salto (SKIP) che consenta all'utente che abbia fatto un undo fino a c1, di saltare il comando c2 per scegliere il figlio di c2 (e non c4). A questo punto basterà fare un redo per appendere il comado c3.
    Skipping

    Proprietà di Undo Skip Redo

  • Le scelte offerte all'utente sfruttano le modalità inerziali: il redo di solito è in relazione all'ultimo undo eseguito.
  • Effettuare n undo ed in seguito n redos porterà il sistema allo stesso stato.
  • Gli utenti possono recuperare facilmente ai propri errori. Se il sistema è lento il redo può non essere sincronizzato e può non funzionare correttamente, l'utente riconoscerà rapidamente di questo malfunzionamento e farà di nuovo un undo.
  • I redo non scompaiono dal copione (altra proprietà inerziale). Il copione non si restinge mai.
    Migliorare interfaccia undo skip redo

  • L'utente può sapere cosa vuole ottenere, ma l' informazione disponibile al nodo corrente è insufficiente per scegliere una giusta direzione.
  • Lo stato può essere rappresentato esplicitamente mediante una mappa: una rappresentazione concreta dell'albero della storia ed il percorso dello stato.
  • A volte, però, una rappresentazione articolata può dare, all'utente, l'impressione che l'utente possa agire senza limitazioni.
    Assunzioni nella storia

  • A volte undo/redo possono sembrare inutili o creare confusione agli utenti.
  • A volte skip e redo assumono una importanza maggiore rispetto all'undo, rivoluzionando il concetto "edita a buon mercato" interagendo con un copione.
  • C'è il pericolo di creeping-features.
    UNDO/REDO

  • In alcuni casi (giochi, lavori artistici, ecc...) gli utenti non vorrebbero recuperare gli errori.
  • Quasi tutta la complessità di undo/redo sorgono dalla differenza tra il copione, lo stato e la riluttanza a scartare storia.
  • A volte l'utente non vuole recuperare l'ultimo comando per default.
    UNDO SKIP REDO

  • Se generalizziamo le azioni compiute dall'utente (quello che l'utente fa) possiamo volere che il sistema usi la storia per predire le operazioni future (concetto di adattività).
  • Alcuni studi mostrano che a volte sono preferibili comandi espliciti di funzioni di recupero. Questo aiuta a fissare strategie inerziali per la creazione di sistemi interattivi validi.
    Le scelte UNDO SKIP REDO

  • Una valida scelta potrebbe essere quella di riusare quello che è stato raggiunto invece di ripetere tutti comandi (per correggere la lettera di una parola è più facile fare un DELETE piuttosto che un UNDO).
  • Questa scelta decrescerebbe i problemi di default- il contesto è lo stesso perciò il significato di comandi è quello usato quando il compito iniziale era [acomplished].
    UNDO non storico

    UNDO/SKIP/REDO provvede una interfaccia uniforme per contenere l'esplosione combinatoria di storie alternative; ci sono 2 problemi concettuali per l'utente:
  • La storia ed il copione sono due cose differenti e non ci possono essere alcuna guep semplice per interpretarli.
  • La rappresentazione del copione può essere contorta e complessa graficamente: l'utente può non capire le vie per navigare e/o cambiare.
    Manipolare lo stato ?

  • In alcuni casi- manipolare lo stato può essere concettualmente più facile di manipolare il copione- lo stato è riferito semplicemente ai comandi di quale è una funzione come nel testo di un word processor.
  • Quando viene battututa la sequenza [abcdef] di comandi, lo stato può essere la rappresentazione di chi ha creato il testo, vale a dire abcdef.
  • Se l'utente sposta il cursore dopo la lettera b, avrà un suffisso ab ed un prefisso cdef (usando i termini della modellistica dell'ACS), evidentemente in un text editor il testo rappresenta lo stato (ma questo è un caso particolare).
    Scrittura/Stato

    La corrispondenza tra copione e stato potrebbe essere usata per aggiungere nuove idee per la progettazione:
  • Se un editor presenta le caratteristiche DELETE e UNDO per cancellare l'ultimo carattere editato vale il principio di chiusura.
  • Solamente i comandi che cancellano l'informazione sono un problema per annullamento finché l'informazione può essere persa, un modo è di immagazzinarla invece di rendere irreversibile il comando.
    Ultime informazioni

  • Può essere possibile mostrare questa informazione 'discarded', anche forma compatta o come 'delta' (variazioni di informazione) .
  • In un text editor (foglio elettronico bianco), si può supporre che tutta l'informazione corrente sia scritta in nero; quella da cancellare sia scritta in bianco e quella corretta/da rivedere sia segnata in blu.
  • Bisogna dire che siamo passati da una sequenza temporale di cancellature ad un ordine spaziale dell'informazione perduta.
  • Ci sono molti modi per immagazzinare informazione: per linea, per paragrafo, ecc...
    [Precedente] [Home Page] [Successivo]