FlowSharp

Da motore a prodotto

Titoli comprensibili, moduli e aiuti contestuali: FlowSharp affronta le piccole difficoltà che separano un motore funzionante da un prodotto usabile.

FlowSharp: Da motore a prodotto. Illustrazione editoriale del Diario.

Per creare una nuova lavorazione chiedevo all’utente di compilare del JSON.

Scriverlo qui mi mette un po’ in imbarazzo. Per me era un modo rapido di passare dei dati. Per la persona che avrebbe dovuto usarlo, era una lingua da imparare prima ancora di cominciare il proprio lavoro.

Questa settimana il comando «Nuovo item» ha ricevuto un modulo. È una modifica semplice da raccontare, ma dice molto del punto in cui si trova il progetto.

Dare un nome alle cose

Ho aggiunto i titoli dinamici per le pratiche, anche con il contributo dell’AI.

Un elenco di identificativi è sufficiente al motore. A chi lo apre serve riconoscere il lavoro: un cliente, un ordine, il riferimento che usa in ufficio. Se devo entrare in ogni riga per capire di che cosa si tratta, la mia interfaccia sta scaricando una fatica sulla persona.

Sono dettagli che avevo rimandato perché il sistema sapeva già creare e muovere gli elementi. Ora mi accorgo che «saperlo fare» descrive soprattutto il mio punto di vista.

Capire perché qualcosa non procede

La diagnostica dei flussi, Flow Doctor, aiuta a trovare configurazioni problematiche. Le regole possono riguardare il flusso intero e non soltanto la singola fase.

Ho lavorato anche sul Support Agent e sulla guida dentro l’app, accessibile attraverso i punti interrogativi. Vorrei che una persona potesse trovare una spiegazione nel momento in cui le serve, senza dover interrompere tutto e cercare altrove.

Nelle misure sono emersi tempi medi sbagliati. Anche qui ho dovuto tornare sul percorso reale: un indicatore presentato bene non smette di essere sbagliato perché è facile da leggere.

Le rifiniture cambiano l’esperienza

Duecentoventinove commit e otto rilasci, dalla v0.85.5 alla v0.85.12.

Rispetto ad altre settimane ho poche novità da raccontare in una frase. Ho soprattutto meno ostacoli da giustificare.

Mi sembra un passaggio importante. Finché costruisco il motore posso chiedermi se ogni pezzo faccia il suo dovere. Quando provo a farne un prodotto, devo chiedermi quanto lavoro sto chiedendo alla persona per riuscire a usarlo.

Quel modulo al posto del JSON è un buon promemoria. Vorrei accorgermi prima delle prossime cose altrettanto ovvie.

Argomentibuild-in-publicflowsharpuxoperatoridiagnostica