NoteCards (1985)

NoteCards venne sviluppato come progetto di ricerca presso lo Xerox PARC tra il 1983 ed il 1986 da Frank Halasz, Randy Trigg e Tom Moran. Successivamente divenne un prodotto commerciale della Xerox.

L’interfaccia utente di NoteCards era grafica, con più finestre contemporaneamente aperte relative a:

	i singoli nodi dell’ipertesto (note card), con testo e/o grafica che potevano scorrere nelle finestre;
	finestre relativi ai link presenti in ciascun nodo;
	una vista complessiva grafica dell’ipertesto (browser card);
	una finestra per l’organizzazione gerarchica dei nodi (filebox).

Grazie alla disponibilità di un ambiente programmabile tramite Lisp, le funzionalità di NoteCards potevano essere notevolmente personalizzate. Un esempio di queste personalizzazioni è stato l’Instructional Design Environment (IDE), che permetteva la realizzazioni di strutture di base di ipertesti a partire da degli schemi predefiniti per applicazioni didattiche.

Come psicologo (da Stanford), Halasz si è focalizzato essenzialmente sugli aspetti di interazione uomo macchina. Alla conferenza Hypertext-87, Halasz presentò un articolo [HAL] nel quale venivano presentati sette punti da sviluppare nei nuovi sistemi ipertestuali, che sono:

1. miglioramento delle funzionalità di interrogazione e ricerca: un ipertesto è sostanzialmente un modo per navigare tra link. L’utilizzo della sola navigazione tra link, però, può essere ritenuta sufficiente solo per applicazioni che ricadono in tre categorie: authoring cooperativo di piccoli ipertesti, sistemi di visualizzazione, presentazioni interattive. La navigazione, invece, non è sufficiente a reperire le informazioni d’interesse su grossi ipertesti, se non è accompagnata da strumenti di interrogazione e ricerca, sia per quanto riguarda i contenuti (es.: ricerca per parole chiave), sia per quanto riguarda la struttura (es.: ricerca di link a questionari);
2. capacità di definire oggetti composti come collezione di nodi e link: per semplificare la struttura di ipertesti di grosse dimensioni diventa essenziale non dover vedere allo stesso livello tutti i nodi di un ipertesto, ma poter organizzare gerarchicamente le informazioni tramite la realizzazione di oggetti "contenitori" di nodi di livello gerarchico inferiore;
3. strutture dinamiche virtuali: gli ipertesti soffrono di problemi legati all’aggiornamento dei contenuti, con le conseguenti ripercussioni a livello di struttura. Dato che l’informazione viene rappresentata da nodi legati da una rete statica di link la cui struttura può non essere evidente a chi aggiorna i contenuti, la probabilità di avere una rete di link inconsistente man mano che si aggiornano le informazioni è elevata. Questo è tanto più vero quanto più prematura è la definizione della struttura dell’ipertesto. Una soluzione a questo problema potrebbe essere la sostituzione della rete statica di link con funzionalità di ricerca sulla struttura per gruppi di nodi, caratterizzati da un certo autore, data, ecc.. Questo è analogo a quanto avviene con le "viste" di un database, ed è stato implementato in sistemi quali SuperBook o il Canon Cat di Jeff Raskin;
4. capacità di calcolo nelle reti ipermediali: la rete di link di un ipertesto è tipicamente statico. Sarebbe, invece, utile poter definire la struttura di link visibili da un certo nodo in funzione di informazioni legate allo stato, all’utente, ecc.. Ad esempio, per un sistema di formazione, sarebbe utile poter definire i link visibili in funzione dei risultati di un questionario. Questo concetto fa confluire le attività sugli ipertesti e quelli legati ai sistemi esperti, knowledge management, ecc.;
5. gestione delle versioni: dato un ipertesto con una rete statica di link, il suo aggiornamento richiede la sostituzione dei nodi preesistenti con nuovi nodi. La perdita dei precedenti nodi non sempre risulta conveniente, sia per permettere "ripensamenti" nella realizzazione dell’ipertesto, sia per conservare la storia delle informazioni presentate. Ancora una volta, quindi, è necessario prevedere una rete "intelligente" di link, che permetta l’authoring e la lettura dell’ipertesto nelle sue diverse versioni;
6. supporto al lavoro cooperativo: sin dall’idea iniziale di Bush, un ipertesto doveva prevedere la possibilità di avere versioni diverse per ciascun utente, prevedendo la possibilità, ad esempio, di aggiungere annotazioni personali. Questo è presente in forma parziale in alcuni sistemi (es.: Intermedia), ma la gestione completa della concorrenza richiede la gestione dei diritti di accesso, dell’atomicità delle transazioni, la notifica delle variazioni a tutti gli utenti dell’iperteso, ecc., riportando nel contesto degli ipertesti quanto sviluppato per i data base;
7. estensibilità ed adattabilità: un ipertesto è solo una collezione di link e nodi, svincolati dal loro significato. Se questo da un lato permette di utilizzare questo strumento in contesti differenti, d’altra parte non lo rende specifico per nessuno di essi. Non è, quindi, evidente come realizzare un ipertesto adatto ad un particolare compito. Un primo modo per superare questa difficoltà potrebbe essere quello di prevedere un’interfaccia utente programmabile, in modo da definire, con semplicità, per ciascun utente delle funzionalità differenti.

A seguito delle esperienze e dei risultati via via maturati nel mondo degli ipertesti, nel 91 Halasz rivide i suoi punti [HAL2], affiancando ai sette precedenti esposti, principalmente basati su aspetti tecnologici, tre aspetti di mercato. Da questo elenco scompare il requisito sul supporto del versioning, considerato importante, ma di peso inferiore. I nuovi punti, quindi diventano:

1. fine della tirannia dei link: riprende i primi tre punti della precedente classificazione, ribadendo la necessità di eliminare la struttura statica di link sostituendola con funzionalità di ricerca;
2. supporto per il lavoro cooperativo: come nella precedente classificazione;
3. estensibilità ed adattabilità: come nella precedente classificazione;
4. capacità di calcolo nelle reti ipermediali: come nella precedente classificazione, ma ridotta di priorità.
5. realizzazione di sistemi aperti: la necessità di accedere a grandi basi di conoscenza richiede che sia possibile scomporre ipertesti complessi in moduli e permetterne un accesso da contesti diversi, tramite interfacce standard;
6. realizzazione di interfacce utente per grandi spazi informativi: non è possibile pensare di rappresentare la struttura di un ipertesto con centinaia di nodi rappresentando la rete di link, che diventerebbe una ragnatela indecifrabile e con tempi inaccettabili di manipolazione, rappresentazione e navigazione;
7. gestione di ipertesti di grandi dimensioni: è necessario iniziare a trovare soluzioni per la gestione delle grosse basi di informazioni che iniziano ad essere richieste da applicazioni reali;
8. definizione del mercato degli ipertesti: è il primo dei requisiti di mercato. Fino ad allora il settore degli ipertesti è stato "technology driven". E’ necessario iniziare ad analizzare rapporti costo/benefici nell’utilizzo degli ipertesti;
9. definizione di standard aperti: l’adozione di sistemi aperti è essenziale per ampliare il mercato dei possibili utenti, ma è necessario prevedere standard facilmente aggiornabili e legati ad esigenze concrete dei settori applicativi;
10. pubblicazione degli ipertesti: è necessario iniziare ad avere ipertesti pubblicati per far crescere la domanda.

Questa serie di punti ha segnato la storia della successiva evoluzione del settore degli ipertesti. Nel 1986, Halasz si spostò alla MCC (Microelectronics and Computer Technology Corp.) al progetto HyperActivity per l’integrazione di ipertesti e ingegneria del software.

Halasz è anche autore, con Mayer Schwartz, del Dexter Hypertext Reference Model [HS90], che fissa una struttura e delle funzionalità standard per i sistemi ipermediali.