L'oggetto nella scrivania

Interfaccia e semplificazione del lavoro con OS/2

In collaborazione con JustWarp - La prima e-zine dedicata a OS/2 Warp

di Andrea Resmini

Lavorare con un personal computer e' qualcosa di completamente differente dall'utilizzare strumenti tradizionali, e diversi gradi di integrazione tra tecniche e tecnologie successive di uso spesso si sedimentano nell'utilizzo quotidiano, per comodita' o per la relativa sicurezza, in quanto provate, che offrono. Quanti di coloro che utilizzano OS/2 Warp ancora si portano alla linea di comando ed alla affidabilita' di uno dei tanti cloni del Commander di Peter Norton quando devono copiare files, ad esempio?
Tanti direi, e io stesso fra questi.
Il fatto e' che le abitudini profondamente radicate sono dure a smettersi, anche quando sono apertamente improduttive od addirittura dannose. E se comunque avere una visione da command line della propria macchina aiuta la comprensione di certi meccanismi di funzionamento, non e' stata altrettanto positiva l'identificazione GUI/Microsoft ed il conseguente modo d'approccio all'uso delle interfaccie grafiche prodotto dall'enorme diffusione di Win 3.x.
Le interfaccie grafiche, al di la' di inesistenti meriti di democratizzazione plausibili solo per chi possa pensare che alla stessa stregua il cambio sincronizzato ed il servosterzo abbiano democratizzato le automobili, hanno portato enormi vantaggi concettuali nella concretizzazione del modo di utilizzare il personal computer e nelle metafore astratte (object-oriented, client-server, distributed networking) che guidano lo sviluppo e del software e dell'hardware, di cui sono ad un tempo effetto e volano.
Ma da una linea di comando io ho due possibilita': digitare un comando comprensibile al SO o digitare qualcosa di errato, e nient'altro. Le cose con una interfaccia grafica si complicano notevolmente, dal momento che il flusso di informazioni ricevute e trasmesse tra operatore e sistema aumenta esponenzialmente.
E se un errato modo d'uso di un sistema operativo da linea di comando puo' portare a malfunzionamenti e perdite di dati, raramente portera' alla insoddisfazione ed improduttivita' di un sistema con una GUI mal realizzata o mal utilizzata.
Ma allora che cosa differenzia buone e cattive interfaccie, da un punto di vista di puro utilizzo?
Una buona interfaccia non e' "intuitiva", qualunque cosa questo significhi vista l'aleatorieta' del termine: una buona interfaccia avra' una curva di apprendimento gradevole per l'utente, ma l'avra'. Non esiste l'interfaccia a grado zero di difficolta', perche' qualsiasi compito per essere eseguito necessita di una conoscenza delle regole tramite le quali puo' essere svolto.
Assimilatene le regole diviene probabilmente "intuitivo". Siamo accerchiati da articoli di costume sulla complessita' dei telecomandi tv di nuova generazione, e personalmente, utilizzandola poco, trovo tutt'altro che semplice il pannello comandi della mia lavatrice.
Una buona interfaccia non e' nemmeno fortemente caratterizzata, perche' e' uno strumento, non un fine, e ogni bravo artigiano avrebbe difficolta' a dire dove finisce la mano e dove inizia lo strumento: la buona interfaccia tende a diventare invisibile.
Una buona interfaccia e' sicuramente configurabile dall'utente secondo preferenze personali, sufficientemente robusta da reggere un uso errato od improprio da parte di chi sta imparando, e offre un sistema d'uso coerente in ogni sua parte; ma soprattutto una buona interfaccia e' aperta ad un utilizzo che si fa via via piu' esperto, sicuro e complesso mano a mano che si sale lungo la curva di apprendimento.
Questi criteri escludono il mainstream programming di Windows.
La piu' grave responsabilita' infatti che puo' essere imputata a Microsoft e' sicuramente quella di avere banalizzato lo sviluppo e l'utilizzo delle interfaccie ad icone in un ampio segmento del mercato del personal computer, con un impatto, per mera forza dei numeri, destinato a durare e ad influenzarne per diverso tempo le strategie produttive ed il pensiero critico.
Per preciso calcolo o per semplice inadeguatezza l'approccio rivoluzionario introdotto dal Macintosh e di cui IBM ha fatto buona scuola nel progettare OS/2 Warp e' divenuto per molti utenti di personal computer quell'incubo bidimensionale che va sotto il nome di Program Manager, una shell costruita per ordinare una sempre piu' dispersiva collezione di programmi multifunzione e che sostituisce semplicemente all brutalita' di un cursore lampeggiante l'altrettanto ignava icona da cliccare.
Dove si era prefigurata una innovativa associazione tra oggetti hardware e oggetti software (icona del floppy, addirittura guidato via software, icona della stampante, cestino) ed un nuovo pensiero dell'interazione tra uomo e computer abbiamo avuto, su di un vasto mercato di massa, una derivazione deprivata e inconsistente, in cui l'approccio visivo e' solo un miglior presentare lo stesso modus logico, in cui la modalita' grafica e' solo un ausilio alla standardizzazione della programmazione e della visualizzazione.
Se muoversi tra directories alla ricerca di un certo programma non era facile od agevole dalla linea di comando, incomincia a divenire quanto meno dispersivo anche l'identificarne l'icona tra altre cento scarsamente dissimili.
Oppure infilarsi nei menu concatenati di una start-up bar che mostra in sequenza start/programs/myprograms/mmedia /paint/psp/Paintshop. Utilizzare soluzioni rigidamente codificate, quali che siano, porta ad una rapida perdita di controllo non appena viene oltrepassato il limite teorico di complessita' del sistema: digitare "dir" per discriminare tra cinque files e' pratico, ma lo e' molto meno se i files sono cinquecento. Avro' allora switches per modificare l'output del comando "dir", per data, estensione, dimensione: si aumenta il grado di complessita' del comando per risemplificarne il risultato.
Le cose non cambiano poi molto utilizzando la nostra start-up bar: ottimale per avere accessibili dieci - venti funzioni, assolutamente improduttiva quando menu si aggiunge a sottomenu di un sottomenu di un menu con lista di files. Ecco il discorso di crescita della complessita' d'uso, di cui si puo' avere una rapida valutazione comparando il certo meno efficace graficamente SmartCenter di Warp 4 e la start bar di Windows 95: se in quest' ultima il concatenarsi di menu su menu e l'incremento di voci tendono rapidamente alla saturazione della capacita' di discernimento dell'utente, nel primo il pur semplice utilizzo di "trays", cioe' cassetti configurabili presentati in ciclo e non tutti insieme, consente di mantenere sotto controllo, ed eventualmente eliminare, il complicarsi dei riferimenti.
Purtroppo, complice l'enorme diffusione delle soluzioni Win 3.x e Win95 (che, per inciso, condividono in tutto e per tutto l'impostazione e la filosofia di base, almeno a livello di integrazione tra interfaccia e sistema, quasi inesistente), e' diventato patrimonio comune il pensare a qualsiasi tipo di interfaccia utente/computer in termini win-like, termini se non esclusivi almeno comparativi. Il problema e' che questo tipo di approccio e', per gli utenti di OS/2 Warp, estremamente riduttivo.

Programma e documento

OS/2 infatti, abbastanza stranamente e per fortuna nostra, non ha un Program Manager. Questo e' un enorme vantaggio strutturale che deve essere sfruttato, perche' e' l'indice piu' visibile di una diversa concezione dell'interfaccia che solo ora e con molta fatica Microsoft sta cercando di imitare. Ovviamente banalizzando.
Dal punto di vista dell'utente, che colloquia con il computer utilizzando l'interfaccia (e per comodita' mi riferisco alla sola interfaccia software), i modelli di organizzazione dell'interazione sono riconducibili a due, diametralmente opposti tra loro: il modello programma ed il modello documento.
Esemplificando, utilizzo il primo quando il mio modo di procedere segue una logica "programma=>file", cioe' lancio un word processor, cerco un file documento, lo apro, lo edito, lo chiudo, apro un secondo file e via dicendo. Uso il secondo quando invece ragiono in termini di obiettivi e non di mezzi: cosa devo fare e non con cosa o come devo farlo.
In questo modello il file/documento/oggetto e' il centro e non lo e' il programma specifico che uso per compiere l'azione richiesta.
Il primo e' paradigmatico in Win 3.x / Win95, il secondo e' tipico tra gli altri di OS/2 Warp e del Macintosh.
Il fatto e' che la Workplace Shell (WPS), l'interfaccia grafica di Warp, non e' una replica a migliore tecnologia del Program Manager di Windows, ma un potente strumento di lavoro OO, un "document oriented desktop" estremamente flessibile e configurabile che poggia su di una robusta struttura ad oggetti (SOM) che consente una facilita' di configurazione ed una molteplicita' di modi di uso tali per cui difficilmente due workstation Warp non out-of-the-box possono assomigliarsi, e nell'apparenza grafica, poiche' fonts, colori, icone e bitmap sono assegnabili dall'utente oggetto per oggetto, e nelle procedure operative, poiche' il drag and drop tra tutte le componenti di sistema, la accessibilita' dei menu contestuali, l'uso delle workareas, la creazione di oggetti ad hoc per compiti specifici, siano essi stampanti, templates o sessioni DOS/Win VDM, offrono piu' di un modo di compiere un lavoro.
La prima e piu' banale richiesta che spesso mi sono personalmente sentito fare da utenti, professionali e non, posti di fronte al desktop di Warp e' stata: "e il File Manager, dov'e'?". Recentemente, grazie alla rivoluzione tecnologica di Windows 95, la domanda viene di solito riformulata in "e la Gestione Risorse, dov'e'?".
Ammetto di considerare la domanda spiazzante, perche' questo tipo di approccio e' inconsistente, o largamente riduttivo, della logica con cui e' stata progettata l'interfaccia utente di Warp. Warp non necessita di un "programma file manager", poiche' tutte le operazioni possibii su files possono essere svolte elegantemente e con estrema efficacia utilizzando gli oggetti della WPS e gli oggetti drives in particolare.
Se volete, il file manager e' inglobato, affogato nel sistema, per fornire le funzioni che servono dove servono, ed e' questo un punto di forza di OS/2 spesso non adeguatamente sfruttato da utenti e sviluppatori allo stesso modo. Il miglior prodotto per Warp e' un prodotto quasi trasparente, che non si vede e che non e' intrusivo.
Un esempio tipico, ottimo ed incompiuto, e' l'integrazione FTP di Warp 4. Ottimo perche' perfettamente aderente alla logica ad oggetti della WPS, incompiuto perche' purtroppo ancora privo di funzioni fondamentali quali il reget e terribilmente avaro di informazioni sulle transazioni in atto, niente transfer rates e sopratutto niente che avverta l'utente dello stato percentuale di download/upload. Probabilmente chi ha sviluppato il codice aveva in mente un client connesso in rete, con nessun problema di tempi e delays, piu' che un utente TCP/IP su linea telefonica.

Fig. 1 - Il folder Connections di Warp 4: drives locali e drives remoti ed il folder FTP di Hobbes aperto e connesso

I folder FTP creati sul desktop non sono altro che cartelle speciali la cui apertura connette all'host remoto, mostrando il contenuto esattamente come un drive folder locale, consentendo tree views o icon o details views, filtering, drag and drop da/per il sistema locale.
Microsoft ha recentemente annunciato che una futura release di Internet Explorer operera' esattamente secondo questa logica, integrando file system locale e remoto, ovviamente sottolineando quel carattere innovativo che IBM si e' ben guardata dal valorizzare nel suo prodotto, gia' sul mercato da circa sei mesi.
Un ottimo esempio esterno ad IBM di modello ad oggetti e' rappresentato da Object Desktop di Stardock, o dalle innumerevoli utilities shareware e freeware che incrementano o modificano le prestazioni o le capacita' della Workplace Shell, come Desktop Wizard o WPS Scheduler.
Le funzioni e le possibilita' accessorie fornite da questi software ad oggetti sono integrate a livello di WPS, nuove opzioni sul drag and drop, menu contestuali, nuove classi di oggetti per gestire nuove periferiche o nuovi formati di files: ad una prima occhiata dopo l'installazione non sembra cambiato nulla, il pacchetto non conteneva eseguibili ma solo DLLs, nel folder creato dal programma sono non molte icone quasi tutte deputate alla configurazione o alla documentazione. Poi si comincia a lavorare e si vede che il settanta per cento di quanto serve c'e' solo ed effettivamente quando serve: ma ora quel file .ZIP o .RAR funziona come un folder, utilizzando la stessa metafora, ora posso vedere o stampare quel file .CDR di CorelDraw senza avere nemmeno il programma installato e senza lanciare nessun file viewer. Le aggiunte sono trasparenti.

Fig. 1 - Un file .DOC di Word con una voce menu per la visualizzazione e la stampa dovuta a Object Desktop Pro e due voci per il salvataggio e l'upload create mediante template

Associazioni, menu e templates

Siamo abituati a considerare i files come "proprieta'" di uno o piu' programmi che ne riconoscono il formato e lo interpretano correttamente per fornirci il foglio di calcolo o l'immagine che ci serve. Warp non solo consente di avere associazioni tra files e programmi come Win 3.x / Win95, consentendo associazioni multiple tra un certo tipo di files e piu' programmi di editing, ma fa un uso di questo tipo di link logico molto piu' estensivo.
I files sono concretizzazioni singole degli oggetti e delle classi gestite dal sistema via WPS, e come tali non hanno nessuna necessita' di avere per esempio una estensione ".ext" nel nome: le applicazioni OS/2 riconoscono i "loro" documenti basandosi su firme binarie scritte negli attributi estesi del file, col risultato che i documenti

  
     lettera.sdw
     lettera del 2502 alla ditta
     letteraditta.2502.copia

scritti con StarDivision StarWriter sono, per quanto riguarda la capacita' del word processor di identificarli come "propri", tra loro equivalenti. E' ovvio che non tutti possono trovare comodo o utile abbandonare lo schema 8.3, ma questa possibilita' esiste, ed e' una possibilita' che muove via dal programma, che gestisce le associazioni in modo trasparente per l'utente, e verso il documento.
Come oggetti, i files e ogni componente del sistema, sottolineo ogni, possono avere funzioni "private" associate al proprio menu contestuale.
Il mio drive X:, uno Iomega ZIP esterno, ha una voce di menu che dice "download backup" e che, tramite uno script Rexx non piu' complicato di un batch DOS, effettua la copia da una mia personale directory /incoming su hard disk al floppy ZIP. Ovviamente, copia solo i files scaricati nell'ultima giornata.
Se e' possibile aggiustare i menu dei miei oggetti, siano di sistema o per cosi' dire personali, non c'e' nessun bisogno di mantenere un oggetto, o una shadow, di ogni programma sul desktop, cosa che porta tra l'altro, oltre che ad una scrivania alquanto ingorgata, a rallentamenti del refresh video, a patto che dei due modelli organizzativi si utilizzi quello che abbiamo definito documento.
E' che la metafora della scrivania ci ha probabilmente deviato o traviato piu' del dovuto e del necessario.
Sulla scrivania abbiamo la penna per scrivere e il telefono per parlare col mondo: questo non e' necessario nello spazio virtuale del nostro desktop video. Qui e' possibile, io aggiungo auspicabile, avere metaforicamente la carta per scrivere e la "telefonata" o la "persona da chiamare", la "conversazione" per telefonare. Il modello ad oggetti e' un modello astratto, che guarda piu' al procedimento logico che ai dati fattuali relativi al compiere una determinata operazione: ma questo e' d'altronde vero anche per il modello programma, seppure piu' limitatamente e con un certo numero di compromessi.
Ho ricevuto da amici e colleghi, utilizzatori di OS/2 come di Windows, diverse domande incuriosite, spesso diffidenti, circa la mia personale abitudine di rinominare (a volte) e cambiare icona (quasi sempre) ai programmi installati sul mio PC. Per quanto questa sia una deprecabile abitudine privata che non consiglierei certamente a tutti e per la quale spero mi vorrete perdonare, ha una sua logica che e' coerente al nostro anzidefinito modello documento.
Io, come molti, non ho dieci wordprocessors, quattro programmi di posta elettronica, tre fogli di calcolo, o perlomeno non tutti in uso (tengo certo programmi aggiuntivi in prova, ma separati da quello che e' il work desktop). Scrivo pero' lettere, articoli, progetti, spedisco email su Internet e Fidonet: ho quindi un wordprocessor ed un mail writer.
Come si chiamino e' pero' dal mio punto di vista relativamente ininfluente, ed averli identificati con la loro icona personale a volte addirittura fuorviante.
In un certo senso associare al mio programma di posta una icona decisa da me, visto che il SO mi offre questa facilita', costante, una busta, una casella postale, mi garantisce che qualora io decida di comprare un nuovo mail writer (o che lo sviluppatore effettui un minimo di restyling) continuero' ad associare funzione ed icona, con un buon riflesso pavloviano.
Questo comporta certamente una buona cura ed una pianificazione del desktop che ad alcuni puo' sembrare eccessiva o inutile, ma ripaga ampiamente in termini di produttivita' chi ha necessita' di una interfaccia stabile e "uncluttered".
Ovviamente, immagino ce lo si potesse aspettare, questo non e' il massimo di astrazione possibile.
Il passo successivo, molto piu' aderente alla logica object-oriented di Warp, e' quello di eliminare il passaggio per il programma e di creare uno o piu' folders di templates (maschere) rispondenti alle esigenze di lavoro: se necessita uno schema estremamente preciso, o semplicemente devono essere automatizzate operazioni per larga parte ripetitive, avro' piu' templates associati ad una stessa applicazione, ognuno predisposto per i ristretti scopi definiti. Un template per un certo tipo di lettera, un template per un certo tipo di immagine, un template per la stampante e un template per i folder di smistamento dei downloads. Templates e workareas, folders contenitori speciali la cui apertura/chiusura provoca la apertura/chiusura di tutto quanto in essi contenuto (ls WPS e' una workarea ad esempio), sono una potente combinazione di lavoro. Con un saggio uso delle shadows degli oggetti d'uso comune, siano essi stampanti o files, si e' in grado di creare desktops di lavoro pronti con un click, indipendentemente dal numero di operazioni che sarebbero necessari ogni volta per rendere attivi i programmi richiesti uno ad uno.
Il mio folder "the Net", figura 3, e' una workarea, ad esempio. Con la sua apertura vengono attivati automaticamente uno script Rexx che effettua la connessione ad internet utilizzando il PPP di Warp, il mailer ed il folder FTP di Hobbes, ed il software di comunicazione vocale InterCOM. Due folder contenenti links e shadows di files utili vengono aperti a fianco. La chiusura della workarea chiude il collegamento, i programmi ed i folder.

Fig. 3 - La workarea "the Net".

E', all'ennesima potenza ed applicato al sistema operativo nel suo complesso, quello a cui molti sono abituati lavorando con un word processor, nel quale utilizzano un modello preparato per i fax, uno per le lettere private, uno per i manuali.
Il grosso vantaggio, pratico ma anche di organizzazione logica, di questo modello documento e' la semplificazione che avvia nella strutturazione del desktop, e semplificazione, in un mondo sempre piu' connesso ed interpiattaforma, e' una parola d'oro.

Prestazionismo

Questo mi porta a spendere una breve nota sul prestazionismo.
Il prestazionismo ("featurism") strisciante di molte applicazioni Windows, che vivono un mercato nel quale la corsa verso l'ultimo applet e la feature dei sogni ("ultimate", "definitive", "feature rich" sono le parole piu' frequenti dei frequenti ads che le pubblicizzano o recensiscono) e' ormai parossistica ed insensata, ha condotto a prodotti nei quali la apparente semplificazione delle operazioni e' unicamente riduzione prestazionale (un esempio tipico sono i wizards, agenti software con un quoziente intellettivo alquanto deficitario) e le centinaia di funzioni disponibili si perdono in muri di bottoni, drop lists, selection boxes.
Forse Wordstar 1.0 aveva meno funzioni della media degli ipertrofici word processor di oggi, ma certo veniva utilizzato al novanta per cento delle sue possibilita'. Oggi il gioco sembra quello di offrire valori aggiunti inutilizzabili per mero surplus di informazioni o per precoce obsolescenza.
Ho recentemente visto una shell Windows per PKWare PKZip. Non ne faccio il nome, perche' il programma e' un buon programma, in grado persino di agire come un editor di testo, come un file manager e chissa' che altro.Ha talmente tante funzioni che duplicano quelle di sistema o di altri programmi ad appesantirlo ("bonus add on", probabilmente) che ci si dimentica del suo scopo primario, aprire file compressi per accedere al contenuto.
Non e' che questo tipo di programmazione non esista nell'angolo di mondo di Warp, esiste eccome: le insegne ed i lustrini della concorrenza a volte sono meglio che gli specchi per le allodole. Ma il fatto e' che e' possibile, come per l'uso dell'estensione dei files, farne a meno. Una scelta che non e' data (forse nella prossima release, direbbe certamente l'addetto stampa) a chi usa piattaforme Win 3.x o Win95.
Il programma ideale e' non intrusivo, possibilmente modulare, mimetizzato nell'interfaccia e coerente con essa. Ma chi usa Warp non deve, per fortuna, attendere la prossima release. Si puo' fare anche senza File Manager.

Andrea Resmini è raggiungibile su Internet tramite JustWarp, la prima e-zine dedicata a OS/2 Warp.