Pulsante 'Salva' nella nostra app Web (20-30 caselle di testo), il cliente è preoccupato che gli utenti dimenticheranno di fare clic e perdere i propri dati [chiuso]

Di recente mi trovavo nella stessa situazione in cui il client non desiderava avere il pulsante Salva , anche se i moduli erano abbastanza semplici e si adattavano tutti allo schermo con Salva e Annulla .

Sono riuscito a creare un semplice modulo con funzionalità di salvataggio automatico ed a condurre un test con un paio di i loro utenti del mondo reale e la conclusione è stata più del 30% delle volte che le persone cambiano idea dopo modifica dei dati - desideri annullare le modifiche e quasi l'80% di esse non ha notato all'inizio che si tratta di un modulo Salvataggio automatico .

Quindi gli argomenti principali qui sono:

• Hai bisogno di una funzionalità di annullamento, perché le persone potrebbero cambiare idea o modificare la scheda errata, ecc.

• Hai bisogno di una funzione Annulla tutte le modifiche , per lo stesso motivo di cui sopra - immagina se hai cambiato i dati del profilo di un altro cliente e te ne rendi conto dopo aver modificato un paio di campi.

La soluzione finale che abbiamo trovato è stata:

• Per avere una piccola notifica quando qualcosa è stato salvato sul server,
• E un pulsante Annulla accanto alla notifica,
• Più un pulsante Annulla modifiche che reimposta tutte le modifiche e carica la versione aggiornata - prima di qualsiasi modifica, tuttavia questo è disponibile solo se non si finisce e si esce dalla pagina. Dopo che i dati sono stati aggiornati in modo permanente e non sarà possibile eseguire il rollback.

Poiché si trattava di un'app Node.js , ho usato Socket.io , ma ciò è perfettamente possibile anche con Ajax . Anche per le Annulla modifiche ho semplicemente mantenuto una copia dei dati dei moduli in formato JSON, quindi è una sorta di copia cartacea dei dati del modulo che non verranno modificati, quindi in qualsiasi momento l'utente cambia idea, può semplicemente eseguire il rollback sui nuovi dati inizialmente caricati nel modulo. Come ho detto ancora, perderai questi dati dopo aver lasciato quel modulo.

Perché ritieni che tu abbia ragione e che il tuo cliente abbia torto?

• O hai una conoscenza sufficiente nel campo UX ; in questo caso, non sarà difficile per te trovare il motivo per cui, nel caso specifico dell'applicazione a cui stai lavorando, avere un pulsante Salva è un must e come spiegarlo in modo non tecnico termini per il cliente.

  Ad esempio, potresti trovarti in un caso in cui l'utente finale non desidera che le sue modifiche vengano visualizzate immediatamente online e può avere senso trascorrere una buona quantità di tempo modificando il contenuto prima di premere il pulsante Salva. È esattamente ciò che accade in questo momento: sto modificando la mia risposta, e mentre è possibile tecnicamente rendere le modifiche visibili a tutti in tempo reale (tramite WebSockets), Stack Exchange consente a me di decidere quando considera la mia risposta è finita e dovrebbe diventare visibile al pubblico.

• O esiste un vincolo tecnico che rende difficile o impossibile implementare una soluzione AJAX . Anche in questo caso, spiegalo al cliente, spiega il costo aggiuntivo e lascia che sia la persona a decidere.

  Ad esempio, l'aggiunta di AJAX ad ogni modulo in questa fase avrebbe un costo aggiuntivo di $ 20.000. Anche se ritieni che il ROI di questo cambiamento sia particolarmente basso, il tuo cliente potrebbe avere un'opinione molto diversa sull'argomento.

Non dare per scontato che i clienti stiano sbagliando, soprattutto se hai bisogno di chiedere su un sito Web di Q & un argomento per supportare il tuo punto di vista.

Ci sono casi in cui gli errori dei clienti sono evidenti: in quei casi, potrebbe non essere facile trovare il modo di spiegare l'errore al cliente, ma almeno gli argomenti sotto la loro forma tecnica sono abbondanti ed evidenti. Come professionista, spetta a te quindi guidare il tuo cliente verso una soluzione migliore.

Esempio:

Customer: I was reading that in order to avoid issues with Unicode, data should be stored in Base64. Please, can you store everything in the database in Base64?

You: Base64 increases the size of the data with a ratio of 4:3. This means that for every 3 GB of data, you'll actually store waste 4 GB of space. Also, storing the data in this format will make it much more difficult to manipulate the data by hand during the debug and testing phase. Finally, I'm using Microsoft SQL Server and a C# application; both have a good support for Unicode. I also worked on this project and that one which used Unicode extensively, so I know pretty well how to handle Unicode and avoid the usual pitfalls.

Ci sono anche casi in cui la tua opinione è diversa da quella del cliente e nessuna è giusta o sbagliata. In tal caso, ricorda che:

• Il cliente ha l'ultima parola sui requisiti.

• Hai l'ultima parola sul prezzo.

Esempio:

Customer: Great. Finally, I want it to be done in PHP.

You: Frankly, I don't enjoy PHP too much. Ruby or Python can do the job too, and your server is fully compatible with both.

Customer: I know. But I still prefer you do it in PHP.

You: Is it because you have somebody in your company who knows PHP better?

Customer: No. But several programmers I know told me PHP is great.

You: Ok. But since I program mostly with Ruby and haven't used PHP for the last four years, I'll have to spend some time relearning stuff, and I would be a bit slower than if I were coding in Ruby. Is it ok for you to increase the cost of the project from $25,000 to $28,500, and move the deadline from August 10^th to September 10^th?

Questa è una priorità.

Ci sono due priorità in competizione.

1. Gli utenti perdono i loro dati e devono ridigitare tutto o diventare frustrati e interrompere il processo. Questo è potenzialmente un NUMERO CRITICO in un'app di vendita, perché "interrompere il processo" in questo caso significa non pagare il cliente.
2. Errori che si insinuano a causa del salvataggio di dati indesiderati e dei costi associati al carico del server. Questo può o meno essere un problema critico, a seconda della robustezza del sistema, della quantità di carico coinvolto e della quantità di denaro che viene lanciata. (Vorrei sottolineare che un pulsante Salva non ti protegge in alcun modo da nessuno di questi problemi, in quanto le persone in genere salvano informazioni errate e se perdi i loro dati e ripartono, è anche carico del server)

Il peso che attribuisci a queste priorità è fino al cliente . Se semplicemente non si rendono conto che la soluzione risolverà il loro problema in modo soddisfacente, è compito tuo dimostrare loro che lo farà. Se la tua soluzione considera la loro preoccupazione come "non un vero problema", allora hai frainteso il tuo lavoro . Il tuo compito è di risolvere il loro problema del mondo reale ("Qualcuno deve fornirci 30 diversi dati e buttare via il computer dalla finestra se riempiono 29 articoli e poi si perde quando il browser si blocca E, cosa più importante, non compreranno da noi. ") A meno che non risolvi quel problema, non stai facendo il tuo lavoro.

La cosa fondamentale da fare qui è prototype . Se la soluzione preferita è facile da prototipare, la si prototipa e si può mostrare al cliente come si risolve il problema oppure possono mostrare come la soluzione non risolve il problema. Se non lo è, stai "preferendo" una soluzione che è difficile da codificare e non fa necessariamente ciò che il cliente vuole. Non preferire questo, non è preferibile.

In questo periodo di età di Google Documenti che aggiorna automaticamente il server con i dati durante la digitazione, non credo che sia irragionevole che 30 caselle di testo vengano scritte sul server periodicamente (o anche ogni volta che l'utente cambia l'attenzione da una a un altro).

Potresti usare ajax, ma la mia soluzione preferita sarebbe aprire un websocket al server e inviare semplicemente i dati della casella di testo relativa ogni volta che l'utente inserisce il testo in uno.

Nel trattare con il cliente - non è al di fuori dello scopo del progetto in quanto questo è parte delle sue esigenze, quindi è in ambito. Siate contenti di avere un cliente progressista che vuole migliorare le capacità di interazione web come questa e abbracciare la sfida.