On Tue, 2010-05-25 at 23:27 +0200, Andrea Gasparini wrote: > Come ti ho già scritto, non ho ben chiaro cosa intendi per use-case. > Ok, sono d'accordo con tutto quelllo che avete scritto, ma per 'use-case' > intendo qualcosa di un po' piu' concreto. > Se vogliamo partire da qui pensiamo a casi più specifici possibili, tipo: > « Andrea (nome a caso:P) vuole fare una presentazione, prende il fighissimo > programmello A4, e ha bisogno di fare in fretta, senza pensare a tutto. > Butta giù le idee principali: "Mele, Pere e Banane", poi passa a dettagliare: > ha bisogno di inserire la ricetta per lo strudel di mele, metterci due foto, > e > già che ci siamo un video che mostra la procedura per la cottura. Passa in > modalità 'ordinamento' e decide la lista » > Per fare le cose fatte per bene poi bisognerebbe dettagliare ogni punto con > domande tipo "cosa usa Andrea per fare l'azione X? Come si aspetta di fare la > cosa Y? Come farebbe in un altro programma? Come si potrebbe cambiare questo > comportamento per migliorarlo?". > > Chiaro che è una gran rottura di balle. Ne vale veramente la pena? E' quel > che > stavate pensando? [ magari non ho capito un cavolo, eh ]
L'esempio che hai citato è un po' troppo specifico rispetto a quello che
vorrei fare adesso. Però comunque è qualcosa che avrei proposto di fare
più avanti.
> Anche perchè *non* siamo veramente utenti, e *non* abbiamo una base di
> utenti.
> Nè dei clienti che ci chiedono come fare il nostro prodotto.
Non sono pienamente d'accordo con te. Un giornalista che scrive un
articolo deve sempre pensare al pubblico che ha davanti, anche se di
fatto non è un lettore. Non può inserire termini tecnici senza sapere se
il suo pubblico conosce il loro significato.
Così anche uno sviluppatore non può creare un programma senza sapere se
quello che sta facendo è completo ed utile. Ti faccio degli esempi.
* Noi dovremmo fornire un editor per le presentazioni o lasciare che
l'utente debba scriversi il codice XML da solo? Senza sapere cosa è
più comodo per l'utente (e soprattutto cosa è in grado di fare)
rischieremmo di non implementare una parte molto consistente del
programma.
Questo esempio è volutamente banale, ma prova a pensare al seguente,
molto più concreto:
* Dovremmo lasciare all'utente la possibilità di personalizzare le
animazioni? Se sì: l'utente sarà in grado di farlo? Se no: l'utente
sarà contento? Senza saperlo, quali informazioni dovremmo scrivere nel
file della presentazione?
Se il programma è troppo complicato per la gente o non soddisfa le loro
esigenze, è chiaro che non lo userà quasi nessuno, così come un articolo
di giornale pieno di paroloni verrà letto da pochi.
Non so se così mi sono spiegato meglio, ma sentiti libero di dirmi che
ho scritto delle grandi cretinate se non sei d'accordo. ;-)
> In ogni caso, qualche idea possiamo provare a buttarla giù, in maniera magari
> piu' sintetica. Ad esempio, a me piacerebbe usare questo programma anche per
> buttare giù delle MindMap, mi viene abbastanza semplice associare la stessa
> interfaccia per fare entrambe le cose (semplicemente non assegnando un path
> predefinito alla presentazione e muovendosi per zoomare e spostarsi tra gli
> elementi.
Ebbene, dicendo questo hai già contribuito al mio "piano d'azione". Hai
proposto una feature (a mio parere davvero molto interessante) che
potrebbe entrare tra i nostri obiettivi principali. Se avessi proposto
questa cosa più tardi, probabilmente avremmo dovuto riscrivere gran
parte del codice.
> Intanto farei comunque qualche pensata anche sui punti "tecnologici", che
> tipo
> di architettura pensare e che tipo di formato di dati utilizzare.
> ( mi pare che il formato sia la cosa più problematica... sulla grafica ci si
> arrangia, ci sono mille toolkit, framework, librerie... )
Suppongo che siamo tutti d'accordo sul fatto che una presentazione
consisterà in varie aree (quelle che Prezi chiama "frames") contenenti
vari widgets su cui si sposta la vista (seguendo un percorso fisso nel
caso standard, con un percorso scelto dall'utente nel caso di MindMaps).
Quindi se nessuno ha niente di nuovo da proporre, credo che su questo
potremmo iniziare a pensarci.
> Altra considerazione, comincerei a fare qualche provettina su problemi più
> semplici. Se progettiamo tutto e poi si rivela una cosa troppo impegnativa
> rischiamo di non avere nulla di utilizzabile.
Non capisco cosa intendi con "troppo impegnativa". Intendi "troppo lunga
da implementare"? Se è così, non credo che lo sarà mai (in fondo si
tratta di un programmino che visualizza dei widgets). Al contrario,
penso che se facciamo tante prove procedendo per tentativi credo che
butteremo via del tempo e probabilmente ignoreremmo alcune decisioni
interessanti. Naturalmente, in my opinion.
> Invece non mi dispiacerebbe avere come prima Milestone un player che mi
> permetta di navigare un'immagine creata con qualcos'altro (per dire Inkscape,
> se il formato più adatto si rivela SVG).
> Questa cosa potrebbe già essere rilasciabile, impacchettabile, e usabile.
OK, per quanto riguarda la roadmap sono d'accordo con te.
> Quindi, riassumendo tutto questo popò di roba, propongo contemporaneamente di:
> - cominciare a buttar giù qualche pensiero su cosa ci si aspetta da un
> programma del genere.
È proprio quello che sto proponendo io. Scusa se non sono stato
chiaro. :-(
On Wed, 2010-05-26 at 09:36 +0200, Andrea Colangelo wrote:
> Cominciamo a scendere sul tecnico: il formato a cui si pensava
> inizialmente era SVG. Altre idee? Gaspa: hai scoperto qualcosa di più
> su pySVG?
Le GTK supportano già SVG. Con GtkPixbuf possiamo ruotare e zoommare
l'immagine, mentre lo spostamento lo possiamo fare normalmente come lo
faremmo per un altro widget.
Per quanto riguarda il path da seguire (ed eventualmente le animazioni
che sceglie l'utente): potremmo creare dentro il file SVG un widget
nascosto contenente le tutte le informazioni necessarie in formato JSON.
Esempio:
<text-widget visible="False" id="presentation-information">
{"path": ["frame-1", "frame-2", "frame-3"],
"presentation-name": "something",
"other-information": "something else",
...}
</text-widget>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mailing list: https://launchpad.net/~a4-dev Post to : a4-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~a4-dev More help : https://help.launchpad.net/ListHelp
