[Python] scrivere app python con layout grafico in html5?

[Giovanni Porcari]

> Il giorno 25/giu/2015, alle ore 18:28, Gian Mario Tagliaretti <g.tagliaretti a gmail.com> ha scritto:
> 
> Il 25 giugno 2015 17:29, Giovanni Porcari
> <giovanni.porcari a softwell.it> ha scritto:
> 
>>> Il giorno 25/giu/2015, alle ore 17:18, Gian Mario Tagliaretti <g.tagliaretti a 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
> 
> 


Prima di tutto ti ringrazio per il tempo che hai speso per darmi questi esempi.
Devo dire che sono più che altro impressionanti per la mole di dati presentata
allo stesso tempo. Immagino che gli utenti usino monitor molto grandi ;)

Però ho utenti che lavorano quotidianamente su web application molto complesse.

Giusto per darti un esempio, una società di autotrasporti con depositi nel nord Ialia
ha un pannello di gestione (planning) dove in tempo reale arrivano le richieste
visualizzate in una prima griglia per linea di trasporto dove sono mostrati il numero
delle richieste, i metricubi e i quintali prer ogni linea. Cliccando su una riga di questa prima grid
nella grid alla sua destra si presentano le richieste di trasporto di quella riga con i dati relativi
(peso, tipo merce luogo di partenza, luogo di arrivo ecc).
Nella parte sottostante c’è una griglia dei viaggi allocati nel giorno corrente
e nei giorni seguenti sempre in funzione della linea selezionata nella prima riga.
Per ogni viaggio oltre ai dati del mezzo ( Telonato, con sponde, portata ecc) ci sono
i dati dell’autista (con relativi permessi per merci pericolose) il totale di peso e volume
già allocato sul viaggio e cliccando sul viaggio nella griglia a fianco si vedono
le righe di borderò già allocate. L’operatore dragga dalla griglia superiore una o più
righe sul viaggio desiderato e tutto si aggiorna in tempo reale su ogni utente collegato.
Il tutto è estremamente dinamico e gli operatori sono assolutamente felici della facilità
con cui allocano i trasporti e hanno tutto sotto mano in una sola videata.

https://www.dropbox.com/s/y8ccwegmkxh1w3a/planning.png?dl=0

Abbiamo moltissime applicazioni di analoga complessità e quindi mi piaceva l’idea di confrontarmi
con chi deve gestire realtà complesse per capire i limiti del nostro strumento.

Grazie ancora 

G