Di designer non ne vogliamo.

Non è una cosa per professionisti, o anzi, non è una cosa professionale.

YouTube ha avuto un clamoroso e meritatissimo successo perchè ha dato la possibilità a chiunque di improvvisarsi video maker, creatore di contenuti. Con risultati che ovviamente non sono paragonabili a niente di professionale dal punto di vista tecnico, ma è bello proprio per quello. È la creatività il motivo per cui andiamo su youtube, non la qualità delle riprese e del montaggio.

Questo è il fattore virale. Se fossimo rivolti a dei professionisti del design al pc varremmo meno di zero.

L’utente medio deve avere l’illusione che grazie alla tecnologia possa diventare anche lui un artista come quelli seduti sullo sgabello in piazza a Montmartre. Quello è lo stereotipo che va modernizzato nella testa degli utenti.

Ci siamo. È online su 20segmenti.it/socialart

È stato strafico veder comparire qualcosa fatto in diretta da Pat!

Ovviamente mi rendo subito conto che prima di essere pronto per un grande numero di utenti ci sono enormi problemi da risolvere, sia tecnici che ergonomici.

Ma intanto posso farlo vedere agli amici vicini e chiedere il loro parere. Non so per il discorso di lasciare il trasparente al posto del bianco. Per ora mi limiterò a mettere un bg al canvas che dia l’effetto trasparente, così da invitare gli utenti a mettere bianco dove vogliono bianco. Poi in futuro potrei adottare soluzioni migliori per aggiungere io il bianco dove desiderato. Immagino possa far incazzare parecchio vedere il proprio disegno rovinato da qualcosa al di sotto.

Ora sono al livello di tutte le altre demo che ho visto online! Faccio le stesse cose offerte dal chrome experiment, ma con la parte editor migliore! (e con qualche bug in più ehm ehm).

Ma che Figata! Giorno importante il 19 maggio 2015. Parte la versione Alpha di Social.Art!

Ordunque… da quando le coordinate hanno smesso di essere un problema si è passati a discutere sull’esperienza utente :D

ColorPicker tanto per cominciare, che in fin dei conti costituirà da solo il 50% dell’esperienza utente in fase di disegno.

La vecchia versione comprendeva un pop up per scegliere il colore, altrimenti sempre random. Poi Ricca durante la creazione di quello che passerà alla storia come il primo disegno creato su Social.Art mi ha fatto notare qualche punto sconveniente secondo lui:

– non sai quale colore ti ritroverai ad usare in modalità casuale, e non puoi cambiarlo;

– per rimettere colore casuale sarebbe intuitivo un bottone sempre a portata di 1 click, invece che aprire il popup, click sul bottone, chiudi il popup;

– non è strettamente necessario aprire un popup per avere un solo strumento, perché potremmo mettere il ColorPicker sempre a schermo in un angolo e dimezzare i click necessari per la creazione di un disegno “con cognizione di causa”;

Tutte cose veramente intelligenti che in effetti è importante aver pensato. Le ho subito implementate tutte ottenendo meno elementi nel dom, ed una creazione dei disegni semplificata. Ma forse in questo senso mi sento di dire Troppo semplificata.

Lo so, è strano. Mi spiego. Ora il ColorPicker è li bello bello in basso a dx dello schermo, ed il pulsante 5 (tra l’altro con una nuova e bellissima icona “random color” con un dado che su ogni faccia ha diversi colori) permette di selezionare il “colore casuale” e ogni volta che viene premuto ne riseleziona uno diverso. E l’anteprima del prossimo colore è visibile nella preview del CP. Il random è migliorato, ma ora passa in secondo piano rispetto al CP. Cioè, ti ritrovi a voler selezionare un colore specifico, o anche a voler testare il CP, e poi non ne esci più. A quel punto diventa più intuitivo rimanere sullo stesso colore o ricacciare sul CP per selezionarne uno nuovo. E addio random. Addio magia della semplicità con cui chiunque può creare qualcosa di figo. Addio effetto “zero sbatti”.

Quindi credo che farò comunque un passo indietro, mantenendo un passaggio in più per visualizzare il CP e selezionare un colore (tipo la preview sempre visibile, e su click compare il CP o qualcosa del genere), ma col pulsante numero 5 specificatamente dedicato al Random.

Conversione alle coordinate assolute completata.

Per affrontare il problema di visualizzazione alle buone coordinate avevo seguito la strada di convertire e mantenere aggiornate nella memoria locale tutte le coordinate assolute in px dello schermo. Ora che la visualizzazione funziona correttamente l’ho modificata per farla funzionare utilizzando solo coordinate assolute.

In questo modo devo fare molti meno calcoli su drag per mantenere aggiornata la cache locale. Ho comunque conservato il codice commentato perché potrebbe rivelarsi la soluzione migliore per individuare il disegno non trasparente indicato dal cursore.

Ciao a tutti!

Finalmente funziona!

Sono stato sveglio fino alle 5, ma ne è valsa la pena! Un test illuminante (che avrei anche potuto pensare prima…) mi ha mostrato che il punto di origine rimane fisso. Se solo lo avessi saputo fin dall’inizio avrei evitato mille pippe mentali su quel fottuto punto. È stato più complicato da trovare del misterioso punto G di una figa nuova.

In effetti sono settimane che non faccio altro che interrogarmi sull’origine del punto G. Anche informaticamente  parlando, viva la figa.

Comunque, ora posso avanzare col progetto. Ci sono ancora dei piccoli problemi di arrotondamento, e avendo finalmente compreso come funziona la tecnologia che sto usando posso valutare di tornare ad avere solo coordinate assolute per semplificarmi i lavoro JS. Ma le coordinate sono comunque date per fatte.

Ora devo separare versione Dev e versione Beta pubblica, con due db diversi, due url e due versione del codice, e lasciare sempre attivo il servizio backend della Beta. E si comincia!

Ho dato una letta ed una pulita al progetto su Trello, ed ho ritrovato un sacco di idee fighe veloci da implementare. Credo che nel breve periodo mi dedicherò a queste aggiunte di nuove funzionalità per ritrovare un po il piacere di programmare e veder avanzare il progetto, sparando una raffica di commit.

News veloce veloce.

Mi sfugge il perché, ma ora sembra proprio che il punto di origine di ogni immagine aggiunta in futuro sia il punto di origine della prima immagine, che essendo inserita quando il tag g è vuoto parte dal punto di origine dell,svg, che nella dashboard è l’origine dello schermo.

Quindi _groupCoordX e Y partono da (0, 0) e devono subire lo stesso trattamento di drag e zoom delle coordinate delle singole immagini, e dovrebbe funzionare.

Stay Tuned, e porcoddio finchè non funziona.

OOOOOttimi passi avanti!

Ovviamente non funziona ancora, ma questa volta davvero si vede la luce in fondo al tunnel.

Ora posso dire con assoluta certezza (ahahaha come no) che i calcoli sono corretti! Pxx Pxy risultano sempre coerenti.

Il solo problema è che ancora una volta il funzionamento del tag g non è quello che mi aspettavo, e trovare documentazione su come cambia il sistema di coordinate relativo all’interno del tag g non è facile. Ma non si tratta più di un problema di calcoli o di algoritmo! Ora devo solo capire da che punto applicare le coordinate dei disegni e poi tutto funziona.

Sembrerebbe che il tag g viene inizializzato meno volte possibile, significa che finché il primo disegno è presente, sarà lui a determinare il punto di origine di tutto il tag g. Finora se volevo aggiungere 3 disegni alle coordinate x assolute -1 -5  e -10, li visualizzavo passando -1 -4 e -5, perché pensavo che ogni nuovo disegno ridefinisse le coordinate dell’intero gruppo. Invece devo richiamarli con -1 -4 e -9, perché l’origine è stata settata solo la prima volta.

Questo almeno finchè il disegno di origine non viene rimosso. In quel caso il nuovo punto di origine diventa il px più in alto a sinistra di tutti i disegni del gruppo. Potrei cercare di stare dietro a tutti questi cambiamenti, ma troppo sbatti.

Quindi la nuova idea è di aggiungere un elemento fasullo al tag g, tipo un rect di 1 px X 1 px (meglio 0 X 0 se funziona comunque) nella funzione GoToXY, e non rimuoverlo mai. Così dovrei avere un punto di riferimento fisso per sempre, fino al prossimo salto ad un altro punto della lavagna. E se lo imposto alle coordinate correnti della lavagna mi semplifico di molto i calcoli perché potrei usare direttamente la x e la y assolute che ricevo dal server moltiplicandole per lo scale. Potrebbe funzionare! E semplificarmi di molto la vita.

Santo Graal delle bestemmie trovato!

Come ho fatto a non pensarci prima. I px all’interno del tag G sono sempre da intendersi con scale = 1! Quindi è ovvio che ragionare in px dello schermo non va bene, perché all’esterno del tag G 1 px della variabile = 1 px dello schermo, ma all’interno del G 1 px della variabile = (1 / scale) px dello schermo.

Non sono sicuro che questo risolva tutti i problemi, ma di sicuro in quando non correggo questo problema non potrà funzionare.

Come fare… mmm.. dunque

Ho comunque bisogno di coordinate in cache in px schermo di ogni disegno per quando implementerò il click sulla dashboard (magari in futuro questa idea si rivelerà una cazzata ed eliminerò parecchio codice su drag e zoom, ma per ora lo tengo), quindi continuo con gli _updateCacheForDrag e _updateCacheForZoom. Ma al momento della visualizzazione oltre che sottrarre le attuali coordinate in px generali del gruppo, devo anche moltiplicare per lo scale.

E fine, speriamo che funzioni e che non ci sia altro.

Ho modificato anche il socket backend per non inviare 2 volte lo stesso disegno allo stesso client. Quando implementerò la cache client che elimina i disegni vecchi, dovrò comunicare al server che in caso di bisogno devono essere trasferiti di nuovo.

Le idee esposte nell’articolo precedente sono state implementate. Non so se alla perfezione perché non ho avuto molto interesse nel testarle bene visti i continui problemi, ma sembra comunque risolto il problema del tag <g>.

Non capisco per quale fottuto motivo ma i disegni e le loro coordinate sono sfasati nel tempo. Sono asincroni, perché le coordinate alle quali vengono visualizzati dipende da quanto zoom /drag hai fatto da quando hai richiesto il disegno. Ciò è palese con lo zoom: compaiono in posti diversi in base a quanto velocemente hai zoomato.

Ovviamente so il punto della logica del codice dove questo problema, perché sono pochi i punti del codice in cui vengono richiamate funzioni sincronicamente rispetto al resto dell’esecuzione. Ma cazzo il calcolo di dove visualizzarli avviene appunto dopo queste chiamate, quindi in modo sincrono rispetto alla reale aggiunta alla dashboard.

Quindi che cazzo gliene frega al codice se quando ho richiesto il disegno dal server avevo un livello di zoom  e coordinate assolute diverse?

1) mouseWheel

2) “quando hai tempo” fai lo zoom

3) zoom della dashboard attuale e richiesta dei disegni nuovi

4) “quando ricevo un disegno” calcolo dove visualizzarlo in base alle coordinate / zoom attuali.

Che cazzo me ne frega se ci sono passaggi asincroni? Tanto dal server ricevo sempre le coordinate assolute, e la conversione a relative è fatta solo al momento della reale visualizzazione, in base allo stato della dashboard in quel momento.

Che cazzo ne so

Comunque una news interessante oggi c’è. A lavoro mi stanno insegnando parecchio su come testare le reali performance di ogni parte del codice, l’utilizzo di memoria, e tempi di esecuzione di ogni funzione grazie ai tool di chrome. Quando sarà il momento di ottimizzare il codice verrà fuori un prodotto eccezionale.

Eccomi di ritorno.

Mi son preso una pausa tra vacanzina in italia e depressione per i mille bug riscontrati.

I bug sono tanti, ma le madonne sono ancora di più. Vinceremo noi

In pratica cosa ho deciso di fare:

• In cache ogni oggetto avrà x , y , w , h , come valori assoluti in base alle coordinate della dashboard, e pxx pxy pxw pxh che saranno tarati in funzione dei px dello schermo, ed un flag isVisible;
• su drag e zoom aggiornerò i 4 parametri px di tutta la cache, ed il flag isVisibile, ed anche l’array _imagesVisibleIds;
• creo due array con tutte le coordinate pxx e pxy di tutti i disegni visibili sulla dashboard:
  • su aggiunta e rimozione di un disegno sarà sufficiente aggiungere / rimuovere la sua coordinata dagli array
  • su drag e zoom dopo aver aggiornato tutta la cache, ricreo questi array con tutte le coordinate dei disegni isVisible === true
• quando devo aggiungere un nuovo disegno uso le coordinate minime di questi array come coordinate del tag <g>
• e su _appendDraw devo sistemare che vengano impilati correttamente in ordine di ID

Dovrebbe funzionate, ma ormai meglio non illudersi più