Le reazioni degli utenti sono state immediatamente divise tra coloro che subito se ne sono innamorati, tessendo le lodi della GUI e dei suoi dettagli curati, e coloro che, invece, hanno cominciato ad indicare in direzione dei suoi innumerevoli bugs e del marketing hype attorno alla applicazione spingendosi fino alla posa pseudo-geek della esaltazione vuota della mera funzionalità a scapito dei dettagli grafici della GUI.
Diciamo subito che ingenerare hype non è ipso facto male se a questo segue un prodotto degno del battage pubblicitario. Non concordo, né mai concorderò, con coloro che, per spirito di illusorio elitarismo, tendono a denigrare senza fondamento un prodotto, qualsiasi prodotto, solo in base ai riscontri di marketing.
Non é poi affatto male considerare una applicazione anche dal punto di vista di mera cura dei dettagli grafici. E' un elemento fondamentale nella User Experience e non va mai tralasciato (come spesso vedo fare, su Windows soprattutto).
Il problema qui è che a tutto questo hype e alla innegabile cura dei particolari non corrisponde un prodotto all'altezza. Questo, sia bene inteso, non per gli innumerevoli bugs che affliggono l'applicazione (siamo oramai abituati ad essere beta testers paganti) ma per una scelta ben precisa di Interface Design che, pretendendo di innovare, butta nel cestino la usabilità.
L'approccio mono-window che Flow persegue non si adatta al task per il quale si propone che é non la semplice esplorazione e manipolazione di cartelle in remoto ma la interazione tra la copia locale e quella in remoto degli stessi files.
Storicamente questo approccio ha un genitore che possiamo vedere in azione in qualsiasi software destinato alla operazione di diff/merge su files.
Apple FileMerge, ad esempio.
Qui il file viene comparato linea per linea con il proprio antecedente o conseguente in cerca di variazioni che si andranno opportunamente a incorporare nella versione che andremo a considerare definitiva.
Il task che viene associato ad un client FTP è proprio quello della navigazione sincronizzata, un primo controllo delle versioni tra locale e remoto, l'upload ed il download di files verso e da remoto. In altre parole, la interazione tra locale e remoto. Per questa semplice ragione, Flow fallisce il suo compito in quanto costringe l'utente ad avere un'altra applicazione esterna aperta ed attiva per portare a termine con successo quello che dovrebbe essere il suo fine primario.
Occorre infatti avere una finestra del Finder in supporto altrimenti l'utente sarà impossibilitato a fare nient'altro che operazioni sulle cartella in remoto a partire dalla cartella in remoto, in modo chiuso ed esclusivo.
L'utente quindi si trova intrappolato nella applicazione e per trovare una via efficace di uscita dall'impasse deve ricorrere ad ancore di salvataggio esterne.
Questo è cattivo Interface Design in quanto una cosa è cercare appoggio in applicazioni specifiche per task specifici che esulano dal compito primario della applicazione (aprire un file testuale per modificarlo dal client ftp stesso, ad esempio), un'altra é ricorrere ad aiuti esterni per portare a termine la operazione primaria per il quale un client ftp esiste.
Scrivo questo dopo aver tenuto Flow in test per tutto il periodo di prova e ciò che salta immediatamente all'occhio é confermato nell'uso quotidiano.
Innovare nell'Interface Design non é 'famolo strano' né prendere, come in questo caso, un paradigma da una applicazione (in questo caso il Finder stesso, le iApps etc) e trasportarlo senza residui su di un task diverso.
La contaminazione, quando possibile, occorre filtrarla e tirar fuori solo quello che può essere utile rigettando ciò che, a livello di usabilità, ingenera disfunzioni nella efficacia della UI.
Ben venga dunque la cura dei particolari della UI ma che venga dopo un attento studio sul pattern comportamentale dell'utente della propria applicazione e sul task e sub-task che occorre portare a termine.
Molto rumore per meno che nulla, potremmo dire.