Un'eccellente domanda che ogni sviluppatore di applicazioni utilizzando i dati degli utenti dovrebbe chiedere, e, purtroppo molto pochi lo fanno :(
In realtà, ci sono due questioni completamente indipendenti qui:
Ed ecco alcune analisi per ciascuna delle domande. Per favore, scusami la mia passione in più proveniente dalla mia esperienza di "utente frustrato". :)
Q1 è una pura domanda di usabilità. A cui la risposta è in realtà ovvia:
- Evitare o ritardare per forzare l'accesso dell'utente il più possibile!
Anche la necessità di salvare lo stato non è una motivazione sufficiente. Se io sono come utente non interessato a salvare quello stato, quindi non costringermi a firmare! Per favore!
L'unica ragione per voi (come sito web) per giustificare costringendomi a segno è quando ho (come utente) voglio salvare i miei dati per un uso successivo. Qui parlo come utente che ha perso tempo a firmare solo per trovare il sito inutile. Se vuoi sbarazzarti di troppi utenti, è la strada giusta. In ogni altro caso, per favore, rimandalo il più possibile!
Perché così tanti siti di ignorare completamente una regola ovvia? Le possibili ragioni che possono vedere:
R1- sviluppatore amichevole vs user friendly. Sì, è lo sviluppatore amichevole per richiedere segno subito, in modo che non c'è bisogno di perdere tempo con la concorrenza (Q2). Quindi possiamo risparmiare costi di sviluppo, tempo ecc. Ma ogni risparmio ha un costo! Che in questo caso si chiama User Experience. Quale non è necessariamente dove vorresti cercare il salvataggio. Soprattutto, poiché la soluzione non dovrebbe essere così difficile (vedi sotto).
R2 - o Gestione prendendo la decisione è un "appassionato di coperta" :) Vive vita felice circondato da computer super-veloci di connessione internet super-veloce e non può immaginare che canta up può essere difficile per qualsiasi utente. Allora, perché è un grosso problema? Tanti motivi:
Mi si spezza il flusso dell'applicazione. I siti che vivono nel secolo precedente sostituiscono ancora l'intero schermo con forme talvolta piuttosto lunghe. Alcune forme sono mal progettate, alcune hanno istruzioni errate, altre semplicemente non funzionano. Alcuni hanno pulsanti di invio che per qualche motivo sono disabilitati nel browser utilizzato. qualche forma progettisti hanno un'idea geniale per bloccare alcuni campi con cambio appena percettibile o colore. Allora non mostrarmi il campo se non vuoi che lo riempia!
Se il sito è sul serio i dati degli utenti, è necessario mail di richiesta e deve verity esso! Perché? In quale altro modo dovrei tornare all'utente che ha dimenticato tutte le altre credenziali? Perché verificare? Cosa succede se l'utente non ha digitato correttamente l'e-mail? Se non lo verifica, la prossima volta che l'utente tenta di recuperare la password con la sua email corretta, il ripristino non riesce e tutti i dati vengono persi! Ovvio, ma ci sono ancora dei siti là fuori che non lo fanno.Quindi devo aspettare che venga ricevuta l'email di verifica e fare clic su, si spera, un link ben formattato e univocamente identificabile che non si rompa nel mio browser, né ottenere caratteri divertenti a causa del rilevamento della codifica non funzionante, rendendo inutilizzabile l'intero link.
La connessione Internet può essere lenta o interrotta, rendendo ogni ulteriore passaggio un dolore. Anche con una buona connessione, accade qui e là che la pagina impiega molto più tempo a caricarsi. Anche l'email potrebbe non arrivare subito. Quindi l'utente impaziente si avvia furiosamente facendo clic sul link "reinvia verifica". In tal caso il 90% dei siti invia nuovamente il proprio collegamento con un nuovo token, ma disabilita anche tutti i token precedenti. Poi diverse e-mail arrivano in ordine imprevedibile e l'utente povero deve indovinare invano, quale (e solo) è ancora valido. Ora, perché quei siti trovano così difficile mantenere attivi diversi token, solo per questo caso, va oltre la mia comprensione.
Infine c'è ancora così difficile da disorientare l'abitudine per i siti di insistere sul cosiddetto "nome utente". Quindi ora, oltre alla mia e-mail, devo riflettere seriamente per trovare questo unico nome utente, diverso da qualsiasi utente precedente! Grazie mille per aver reso dolce e facile! Il mio modo di affrontarlo è usare la mia email come username. Purtroppo, ci sono ancora siti che non lo accettano! E se poi un tipo divertente usasse la mia email come nome utente? Non è così irrealistico se la tua email è [email protected] Ma perché semplicemente non usare Email e Password per evitare tutto questo casino?
Ecco alcune possibili linee guida per alleviare il dolore dell'utente:
mi vigore solo per accedere a/a se è assolutamente necessario e mi danno la possibilità di scegliere di non!
Crea un modulo di una pagina, quindi so cosa sono e, inutile dire, utilizzare il minor numero possibile di campi di input. Idealmente solo email e password (probabilmente due volte), nessun nome utente!
Mostra il tuo segno di accesso come piccola finestra in cima alla tua pagina senza ricaricare, e permettimi di liberarmene con un solo clic di distanza da quella finestra. Non costringermi a cercare il pulsante "chiudi" o, peggio ancora, l'icona che potrei confondere per qualcos'altro!
Account per l'utente per fare clic su/indietro e pulsanti di ricarica. Non cancellare il modulo dopo la ricarica! Non mettere affatto il bottone chiaro! È troppo facile fare clic per errore. I dati che mi chiedi di compilare non dovrebbero essere così lunghi al primo posto, che non potrei rientrarci senza la necessità di "assistenza" per cancellare.
Ora a mettere in discussione Q2. Qui abbiamo un noto problema di risoluzione dei conflitti che si verifica ogni volta che è necessario unire due dati. Ad esempio, i dati anonimi e i dati utente registrati, ma anche ogni volta che due utenti modificano gli stessi dati, oppure lo stesso utente lo modifica da dispositivi diversi in momenti diversi, oppure i dati memorizzati localmente sono in conflitto con i dati del server e così via.
Ma qualunque sia la fonte, il problema è sempre lo stesso. Abbiamo due dati, diciamo due oggetti $ obj1 e $ obj2 e devi produrre il tuo singolo oggetto unito $ obj3. La logica può essere semplice come la regola che l'oggetto del server vince sempre, o che l'ultimo oggetto modificato vince sempre, o che le ultime chiavi dell'oggetto modificato vincono sempre o una logica più complicata. Questo dipende molto dalla natura della tua applicazione. Ma in ogni caso, tutto ciò che devi fare è scrivere la tua funzione logica con gli argomenti $ obj1, $ obj2 che restituisce $ obj3.
Una soluzione che potrebbe funzionare in molti casi è quella di memorizzare la data/ora su ciascun attributo dell'oggetto (chiave) e lasciare che l'ultima chiave modificata vince al momento della sincronizzazione. Tale account, ad es. per la situazione in cui lo stesso utente modifica attributi diversi quando è anonimo da dispositivi diversi.
Immagina di aver modificato i tasti A e B sul dispositivo AA ieri, quindi ho effettuato l'accesso oggi dal dispositivo BB per inserire un altro B e l'ho salvato sul server, quindi sono tornato al mio dispositivo AA, dove sono anonimo, per entrare ancora un'altra A senza cambiare la vecchia B di ieri, e poi ho realizzato che volevo accedere e sincronizzarmi. Quindi il mio B locale è ovviamente vecchio e non dovrebbe chiaramente sovrascrivere il valore di B che ho modificato più recentemente sul dispositivo BB. In questo caso apparentemente complicato, le soluzioni di cui sopra funzionano perfettamente ed efficacemente. Al contrario, mettere il timestamp solo su interi oggetti sarebbe sbagliato.
Ora in alcuni casi, potrebbe avere senso conservare entrambi gli oggetti e, ad es. distinguerli aggiungendo proprietà extra, come nel caso 1 suggerito nella domanda di Radek. Ad esempio, Dropbox aggiunge qualcosa come "copia in conflitto per utente X" alla fine del file. Come nel case Dropbox, questo è sensato nel caso di app di collaborazione, in cui gli utenti preferiscono avere il controllo della versione. Tuttavia, in questi casi, come sviluppatore è sufficiente salvare due copie e lasciare che gli utenti affrontino il problema.
Se invece si deve scrivere una logica complicata basata sui dati dell'utente, avere due copie diverse in giro può essere un incubo. In tal caso, dividerei dati in due gruppi (ad esempio, crea due oggetti su uno). Il primo gruppo ha dati che rappresentano lo stato dell'applicazione nel suo complesso, che è importante essere unici. Per quei dati vorrei usare la risoluzione del conflitto come sopra o simile. Quindi il secondo gruppo è specifico per l'utente, dove memorizzerei entrambi i dati come due voci separate nel database, li contrassegno correttamente (come fa Dropbox) e quindi permetto agli utenti di gestire l'elenco di due (o più) voci del loro progetto . Infine, se questa ulteriore complicazione della gestione del database rende lo sviluppatore a disagio, e dal momento che Radek ha chiesto di fornire un riferimento risorsa, voglio "uccidere due mosche con un colpo" citando il blog StackMob offline Sync, la cui soluzione fornisce sia funzionalità di gestione del database e degli utenti e quindi allevia lo sviluppatore da quel dolore. Sicuramente ci sono molte più informazioni da trovare durante la ricerca di concurrence dei dati, risoluzione dei conflitti e simili.
Per concludere, devo aggiungere il disclaimer obbligatorio, che tutti qui scritti sono solo i miei pensieri e suggerimenti, che ognuno dovrebbe usare a proprio rischio e non ritenermi responsabile se improvvisamente si fanno troppi utenti felici che fanno il tuo sistema si blocca :)
Mentre sto lavorando a un'app, dove sto implementando tutti questi aspetti, sono certamente molto interessato ad ascoltare altre opinioni e cos'altro hanno da dire in proposito.
Vai su Amazon, accedi, metti qualcosa nel carrello, apri un altro browser e metti qualcos'altro. Ora vai alla cassa. – Gonfva