Il 25 giugno 2015 17:29, Giovanni Porcari <giovanni.porc...@softwell.it> ha scritto:
>> Il giorno 25/giu/2015, alle ore 17:18, Gian Mario Tagliaretti >> <g.tagliare...@gmail.com> ha scritto: >> Ci sono comunque casi (nicchia sono il primo ad ammetterlo) in cui è >> impossibile con la tecnologia attuale replicare la UI in maniera >> accettabile, o meglio alcuni controlli della UI. ciao Giovanni, > Hai mica un esempio a portata di mano ? celo! te ne riporto un paio, come ho scritto prima sono casistiche di nicchia, per spiegare bene devo essere un po' prolisso, scusate in anticipo. La prima è un'applicazione che distrubuisce i dati all'interno di un progetto, qui di seguito un minimo di background del perchè nasce questo software per meglio spiegare le necessità. In genere nel mondo dell'ingegneria impiantistica (ma non solo), tutti i dati di progetto sono gestiti tramite spreadsheets che vivono su filesystem, quando questi dati devono essere condivisi con i colleghi che partecipano al progetto la condivisione avviene tramite posta elettronica, il file viene spedito come allegato ed i riceventi copiano/incollano i dati nel loro spreadsheet, generalmente prendendono solo parti. Va aggiunto che in genere tutti questi dati sono griglie dove il capostipite di ciascuna riga è un ITEM univoco all'interno di un progetto, il tag di una valvola, il tag di un serbatoio, etc... ogni dipartimenti ha dati in parte in comune con gli altri, in parte propri in aggiunta, etc... questo per dire che lo spreadsheet è proprio il tipo di controllo adeguato. Nascono ovviamente dei problemi con il workflow tanti spreadsheet e condivisione per email, dati che si perdono nei meandri delle email non lette con conseguente utilizzo di dati obsoleti, copia/incolla assassini che portano allo scarrucolamento dei dati con conseguenze disastrose a volte, etc.... La nostra applicazione cerca (come tutte le applicazioni del resto) di risolvere questo problema presentando una UI che replica lo spreadsheet il più possibile, ogni cella è però salvata sul DB ed oltre al dato ricorda tutta una serie di dati, proprietario del dato, tipo dato, ogni volta che cambia il valore viene fatto un storico, etc... chiaramente il dato anche se compare in diversi spreadsheet è lo stesso sul db (legato all'item menzionato prima). Tutto sto pippone per dire che una UI spreadsheet like è indispensabile, se l'applicazione venisse trasformata in una web-app andrebbe ripensata completamente, anzi probabimente non sarebbe nemmeno possibile replicare le stesse funzionalità, per degli screenshot [1] (il nostro sito fa cagare lo so) :) Il secondo esempio (con pippone più piccolo) è un'applicazione che mostra dati di progress del progetto, è una UI decisamente ricca ma è l'unico modo (che mi è noto), di poter rappresentare diverse serie di progress, early, late, forecast early e late, etc.... ho messo uno screensot su dropbox [2][3], sul sito ci sono solo gli screenshot dei report. Sempre nella stessa applicazione c'è una parte di collezione del progress di progetto che usa una piccola UI spreadsheet like, stesso controllo di prima [4] anche in questo caso sarebbe un inferno replicare la stessa cosa. (anche se più fattibile dell'esempio precedente) [1] http://www.cla-it.com/spiderDetails-screenshots.html [2] https://dl.dropboxusercontent.com/u/969502/main_WS.png [3] https://dl.dropboxusercontent.com/u/969502/progress_view.png [4] https://dl.dropboxusercontent.com/u/969502/work_class_progress.png ciao -- Gian Mario Tagliaretti GNOME Foundation member gia...@gnome.org _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
