it-swarm.it

Ho davvero bisogno di un pulsante di accesso?

Abbiamo avuto una discussione in ufficio intorno a una pagina di accesso che stiamo sviluppando per una nuova applicazione web. L'applicazione Web si trova in un'applicazione basata su Intranet ed è utilizzata principalmente dagli utenti che devono utilizzare le applicazioni Telnet come 80% del lavoro quotidiano.

Ho creato il design della pagina iniziale in Photoshop, di cui abbiamo discusso e approvato tutti. Tuttavia, ora l'ho dato a uno degli altri sviluppatori per iniziare a costruire, ha notato che non c'era un pulsante di accesso (o altro) sulla pagina - ha semplicemente due campi; uno per il nome utente e l'altro per la password. Dopo averlo interrogato con me, ho dichiarato che era intenzionale, poiché non ne vedevo la necessità - la maggior parte delle persone avrebbe semplicemente premuto Invio, poiché è quello che devono fare nella loro applicazione Telnet. Quindi è iniziata la discussione ...

Sono stati fatti diversi punti fino a quando "se non c'è un pulsante, non sapranno cosa fare" e "si aspetteranno il pulsante e aumenteranno le chiamate di supporto sulla pagina che non funziona". Ci sono stati anche suggerimenti secondo cui gli utenti si sarebbero semplicemente "seduti lì" senza sapere cosa fare.

Ora .. la mia domanda è: Gli utenti hanno davvero bisogno di un pulsante di accesso?

Sono sinceramente interessato a sapere quale percentuale di utenti finali sarebbe in grado di far fronte a una semplice pagina di accesso che richiedeva loro di premere Invio dopo aver inserito i propri dettagli per continuare. È importante notare che non ci sarebbe alcun prompt sullo schermo per premere invio: vedrebbero un suggerimento sulla password che indica cosa fare, ma è tutto!

(Escludi gli utenti mobili dalla mischia - semplicemente prendendo di mira desktop run-of-the-mill e utenti laptop :))

Un esempio della casella di accesso:

the screen

44
Sk93

In definitiva, probabilmente non è una buona idea percorrere questa strada senza seri test a causa delle aspettative degli utenti basate su convenzioni esistenti.

Questo è un punto importante, perché quello che sto togliendo dalla tua descrizione è che questo non è attualmente testato e hai progettato questa interfaccia utente partendo dal presupposto che i tuoi utenti avrebbero capito. Questa è generalmente una cattiva idea: ottieni sempre feedback dal tuo pubblico, specialmente quando stai provando qualcosa di nuovo, e soprattutto in un'area centrale come il login.

Il tuo argomento telnet è qualcosa da prendere in considerazione, ma anche capire che stai costruendo un'app Web qui e probabilmente avrai a che fare con le aspettative degli utenti delle app Web, non di Telnet. Il tuo cervello si sposta tra i contesti: quando usi un'app Web, ti aspetti di fare un singolo clic sugli elementi per seguirli, mentre nelle app desktop potresti aspettarti di fare doppio clic. Riconoscere il modello mentale che gli utenti hanno quando stanno usando la tua app web invece di uno spazio diverso come telnet è un aspetto importante nella progettazione di un'interfaccia utente.

Tuttavia, stanno emergendo alcuni schemi che stanno iniziando a divergere un po 'rispetto alla convenzione standard "accedi o registrati". Ognuna di queste deve affrontare le stesse sfide: cosa si aspettano gli utenti e come costruisci fiducia, aspettativa e rilevabilità attorno ad alcune di queste nuove idee? Ad esempio, StackExchange utilizza il single sign on, il che può creare confusione per gli utenti che non hanno familiarità con quel modello. Amazon (con successo) integra la registrazione e il login in un unico modulo, anche se resta da vedere quanto questo schema sarebbe efficace su altri siti.

Il punto è quando infrangi la convenzione, ti stai dirigendo in un territorio sconosciuto e devi realizzare l'effetto che può avere sulle persone. Se stai pensando di farlo, ti consiglio di prendere un po 'di "run of the mill utenti desktop e laptop" dal tuo ambiente immediato (ad esempio, il responsabile dell'ufficio e qualcuno dall'ufficio dall'altra parte della strada) e chiedere loro di accedere Imparerai molto. Potresti imparare che il tuo presupposto iniziale era corretto. Ma almeno avrai i dati per dimostrarlo, anziché solo il presupposto. :-)


Modifica: come hai menzionato in un commento in una risposta alla tua domanda sui programmatori, "mettere in discussione la validità della convenzione" è un buon punto di partenza, ma dovresti assicurarti che la tua risposta a questa domanda sia fondata sui dati. Chiunque può mettere in discussione le convenzioni, ma le convenzioni sono diventate convenzioni per un motivo: sono soluzioni efficaci al problema. Allontanarsi da quelli senza una buona ragione (e una buona ragione nel mondo dell'interfaccia utente significa avere dati o una qualche forma di metrica) di solito farà più male che bene.

59
Rahul

Al lavoro abbiamo un sistema di sviluppo del personale che visualizza il pulsante di accesso solo se stai navigando in Firefox. Ogni volta che si tiene una lezione, il nostro helpdesk riceve chiamate da persone che non sono in grado di accedere. Ogni chiamata ha a che fare con il fatto che non vedono un pulsante di accesso. Ora dobbiamo fare di tutto per dire agli utenti che devono premere Invio per accedere.

I tuoi utenti potrebbero essere un po 'più esperti di computer, ma suppongo che avrai un sacco di chiamate di supporto a riguardo se lasci il pulsante fuori.

31
LoganGoesPlaces

Mi piace molto la risposta di Rahul, ma aggiungerò i miei 2 centesimi. Sono diventato estremamente titubante nell'utilizzare il tasto Invio su qualsiasi modulo Web a causa dell'incertezza sulla sua funzione predefinita. Non sono sicuro di cosa farà! Alcune persone non sono così attente ai loro sforzi di sviluppo e non riescono a specificare correttamente i pulsanti predefiniti per un modulo, confondendo gli utenti che fanno premere invio da abitudine.

Di conseguenza, mi sono allenato a premere Tab e quindi Spacebar, aspettandomi che il controllo successivo dopo la casella della password sarà il pulsante Accedi (o possibilmente la password di salvataggio casella di controllo), poiché la barra spaziatrice equivale effettivamente a fare clic con il mouse su un pulsante senza dover prendere il tempo di sollevare le mani dalla tastiera e posizionare il mouse su un elemento dell'interfaccia utente.

Il punto è, suppongo, includere un pulsante, ma assicurati che sia l'azione predefinita del modulo, e che sia correttamente impostato per essere il prossimo nell'ordine di tabulazione dopo la casella della password. In questo modo si soddisfano entrambi i gruppi di utenti.

16
Matt DiTrolio

Se hai utenti non vedenti, l'aspettativa sarà un pulsante di qualche tipo. Altrimenti, non ci saranno indicazioni su come accedere, a meno che tu non rilevi in ​​qualche modo uno screen reader e consenti un pulsante in questo caso specifico.

12
Stefan Kendall

Hai considerato gli utenti che non hanno una tastiera fisica? Le persone che usano un iPad o un telefono con un touch-screen?

11
Tommy Carlier

Che dire dell'opzione per consentire agli utenti di salvare le informazioni di accesso? Sarebbe comunque ragionevole omettere il pulsante di accesso? In questo modo come utente dovrei spostare la mia mano dal mouse alla tastiera per accedere e poi di nuovo al mouse per interagire ulteriormente con l'applicazione.

Quindi direi: sì, ne hai bisogno.

6
JochemKempe

Quando si tratta di elementi presenti in ogni altra applicazione Web, puoi provare a trovare una risorsa modello e vedere cosa dicono: http://www.welie.com/patterns/showPattern.php?patternID= login

"Gli utenti possono utilizzare il tasto TAB per passare dal campo del nome utente al campo della password e premere INVIO anziché selezionare il pulsante 'Accedi'".

Di solito, le azioni sono rappresentate tramite pulsanti/collegamenti e l'interazione aggiuntiva con la tastiera è secondaria e vista come per gli utenti "avanzati".

Se sei preoccupato per motivi di usabilità/accessibilità, dovresti anche avere un pulsante: in questo modo gli utenti possono interagire con il modulo solo con mouse/dispositivi di puntamento (copia/incolla le voci | premi il pulsante) o solo con la tastiera.

Quando ho letto la tua domanda per la prima volta, ho pensato al caso "Casella di ricerca". http://www.welie.com/patterns/showPattern.php?patternID=search Lo schema dice che dovrebbe avere un pulsante, ma col tempo (uso della produzione) quel pulsante è diventato un'icona della lente d'ingrandimento/pulsante nell'angolo destro dell'input, e successivamente si è trasformato in un'icona allineata a sinistra identificativa. Con l'avanzamento delle tendenze (Google Instant) il pulsante di ricerca diventa sempre meno utilizzato (ma ancora presente).

Esiste una differenza tra Ricerca e Accesso, innanzitutto perché Accesso richiede 2 input, quindi se si tenta di aggiungere ad esempio un'icona Accesso, anziché il pulsante (proprio come il caso Cerca), dove lo si inserirà, nel primo input, nell'ultimo o in entrambi?

Come sviluppatore, la risposta ovvia è nell'ultima, perché ogni utente avrebbe dovuto inserire il nome utente, quindi la password e quindi premere invio. Quindi nel tuo caso ascolti Enter per l'ultimo input, ma cosa succede se l'utente preme Enter nel primo input (nome utente uno)? Per motivi di coerenza dovresti ascoltare entrambi gli input, anche perché ci sono casi in cui l'utente vede che ha fatto un errore e torna all'input del nome utente.

Penso che il tuo tipo di utenti supererà i test e accederà con successo, ma questo tipo di modulo non è ottimo per tutti (hai anche menzionato gli utenti di cellulari).

Esempi di moduli di accesso: http://www.smileycat.com/design_elements/login_forms/

4
Ecaterina Moraru

Prima di tutto, sono arrivato a questo tramite Twitter e non sono un programmatore, ma ho una ragionevole competenza informatica.

Proposta interessante poiché da tempo ho abbandonato il pulsante Accedi quando utilizzo i siti Web - la maggior parte che uso mi sembra felice di premere Invio.

Un paio di punti: il test per i bambini della scuola è stato interessante, anche se sospetto che troverebbero i moduli web molto più intuitivi degli utenti adulti, in particolare quelli che non stavano usando computer (ZX/C64/BBC) per crescere. Conosco alcuni dei miei amici che avrebbero trascorso un paio di momenti (almeno) riflettendo sul pulsante mancante - e queste sono persone che usano i computer ogni giorno per lavoro, ma sanno solo come lavorare con le applicazioni che usano.

Dato che il pulsante non è presente, qual è l'azione del modulo quando si preme Invio sul campo nome utente? O meno probabilmente, cosa succede se hanno inserito prima la password e premuto Invio? Potrebbe essere necessario qualcosa che ha un'azione Tab fino a quando entrambi i campi non sono completi.

Ho appena bloccato il mio PC Windows (macchina da lavoro, non ho scelta), eseguendo nuovamente l'accesso, il pulsante "login" nel campo password è meno ovvio e non etichettato. Ancora una volta uso semplicemente invio.

Ecco qua, una prospettiva insensibile;)

4
PawnSacrifice

Se mi imbattessi in una pagina simile, potrei pensare che il sito Web non sia stato caricato completamente o che ci sia qualche bug nello script lato server. Perché rischiare la possibilità che un utente si allontani dal sito?

Inoltre, nei tuoi test, hai considerato che potresti ottenere percentuali di successo più elevate rispetto a quelle che potresti ottenere quando il sito diventa attivo? Quando le persone sentono di essere sottoposte a test, potrebbero aspettarsi di superare una sorta di sfida (ad esempio un pulsante di accesso mancante) come se fosse un test QI di qualche tipo. Tuttavia, se si trovano sul proprio browser Web a casa, probabilmente avrebbero una mentalità completamente diversa e agirebbero diversamente (ad es. Non si aspetterebbero di superare qualsiasi sfida, e in effetti potrebbero aspettarsi l'esatto contrario. aspettarsi che il sito web farebbe tutto il possibile per accogliere tutti gli utenti e rendere più semplice l'accesso poiché il sito Web ovviamente vuole che molti utenti siano felici).

Fondamentalmente il tuo scenario di test non è simile al 100% a quello che sperimenteranno gli utenti reali (cioè i tuoi soggetti sanno che sono in fase di test e/o test qualcosa), a meno che tu non possa riprodurre le stesse condizioni esatte (cioè non far sapere ai soggetti che questo è un test), puoi trarre conclusioni inaccurate sulla base di test imprecisi.

Non sono sicuro di come tu stia conducendo i test, ma un'altra cosa che potrebbe influire sulla qualità dei test è se gli altri studenti vedono che nessun altro ha problemi/domande e sono in grado di accedere correttamente. Ciò potrebbe indurli a provare cose diverse (ad esempio, premere il pulsante "Invio") fino a quando non ottengono gli stessi risultati dei loro colleghi. Pertanto, potresti voler isolare anche i soggetti.

Test accurati possono essere un compito molto difficile poiché devi assicurarti che tutte le variabili siano esattamente le stesse tranne la variabile per cui stai testando. Da quel poco tempo che ho passato a pensare a questo problema, ho già identificato altre due variabili che potrebbero influire sulla precisione del test. Potrebbero essercene altri a cui non ho pensato.

3
Senseful

Fai alcuni test di usabilità e scopri cosa fanno gli utenti. Capisco che è un progetto, ma se è importante, conta abbastanza da testarlo.

3
Bryan

Do Both

Chiedi al modulo di presentarsi non appena qualcuno preme Invio (ed entrambi i campi sono stati compilati) e anche hanno un pulsante da premere per le persone che amano usando il mouse.

In entrambi i casi, l'utente è felice di fare ciò a cui è abituato.

3

Direi che la cosa migliore da fare sarebbe qualcosa del genere:

mockup

download bmml source - Wireframe creati con Balsamiq Mockups

Potresti anche fare una piccola freccia fuori dal campo di testo, come fatto nella schermata di accesso a Windows 7 .

Probabilmente vorrai ridisegnare il pulsante ... magari facendolo confluire nella casella di testo fino a quando non ci passi sopra.

L'unico aspetto negativo di all'interno di il campo password è difficile da modificare se si dispone di una password lunga. Assicurati solo di non trascurare questo!

2

In definitiva, come altre risposte suggeriscono che devi chiedere chi è il tuo pubblico. Il tuo test sui bambini della scuola, sebbene interessante, in realtà non ti fornisce abbastanza valore per dire "Il mio test ha dimostrato che non è necessario".

Se dovessi rimuovere il pulsante di accesso, queste sono alcune delle cose che dovresti combattere:

  • Problemi di accessibilità
  • Cosa si aspetterebbe l'utente
  • Dispositivi touch based in futuro (Windows 7 e tablet)

Lavoro personalmente con le applicazioni Web in Flash Builder e come parte della dimostrazione del concetto passiamo attraverso i test di usabilità. Come designer/sviluppatori non puoi sottovalutare il livello di intelligenza di alcuni dei tuoi utenti. Come regola generale, direi sempre di fornire ai tuoi utenti ciò che si aspetterebbero. Solo in circostanze eccezionali dovresti allontanarti da una convenzione che è diventata così ampiamente utilizzata.

Se un utente impiega un paio di secondi per capire cosa fare dopo, è necessario rivalutare il modo in cui è stata presentata l'interfaccia utente.

Con la tecnologia touchscreen sempre più diffusa, non vedo che questo particolare modello cambierà presto. Potrebbe evolversi ma il nucleo probabilmente rimarrà lo stesso.

Come consiglio, manterrei personalmente il pulsante di accesso e consentire all'utente di premere il tasto Invio per procedere, includendo un pulsante di accesso su cui è possibile fare clic tramite la scheda del mouse e selezionare il pulsante di accesso utilizzando solo la tastiera.

Ciò copre quindi gli utenti avanzati, le regole di accessibilità e gli utenti IT analfabeti mantenendo l'impostazione standard per una schermata di accesso.

Come nota a margine - Ottima risposta di Rahul kudos!

2
Michael Henley

Una delle preoccupazioni è assicurarsi di non ricevere troppe chiamate di supporto per la modifica di pulsanti/design mancanti e di non confondere gli utenti.

Per risolvere ciò, aggiungerei il seguente messaggio

Press Enter key to login 

proprio sotto il campo della password.

Questo aiuterà gli utenti (che potrebbero aspettarsi che un pulsante di accesso faccia clic per accedere) sapere che possono premere il tasto Invio per accedere dopo aver letto il messaggio. Potrebbe essere imbarazzante per loro per la prima volta, ma almeno non si confonderanno e chiameranno il supporto, e la prossima volta che visiteranno il sito Web, sapranno cosa fare.

Gli occhi degli utenti esperti ignoreranno il messaggio perché stanno già utilizzando il tasto Invio per accedere.

2
N30

Una soluzione senza pulsante non consentirebbe all'utente di effettuare 5 tentativi di accesso prima di bloccare la password.

Pertanto il tuo sistema è aperto a un attacco di forza bruta poiché un hacker potrebbe avere tentativi illimitati di indovinare la password?

È possibile aggiungere logica all'accesso per impedire tale hack, ma è qualcosa che dovresti prendere in considerazione.

2
Techboy

Non so quanto sia rilevante, ma ero piuttosto incuriosito da questo e ho creato una pagina molto simile al tuo screenshot e poi ho chiesto a mia moglie di provarlo.

è riuscita ad accedere correttamente senza dover chiedere aiuto, ma ho notato che dopo aver digitato la sua password, ha scelto di usare il mouse e ha iniziato a cercare un pulsante. Solo quando non lo trovò, si fermò per alcuni istanti e poi provò a premere Invio, lasciandola entrare.

Chiedendole cosa ne pensasse, prima ha detto che era ok e semplicemente normale, ma dopo averle chiesto cosa pensava del pulsante mancante, ha detto che era un po 'confusa, ma ha pensato che se avesse premuto Invio, avrebbe potuto passare alla schermata successiva come quando si desidera una nuova pagina in Word.

Non sono del tutto sicuro di cosa significhi, ma il risultato è stato che è riuscita a entrare senza aiuto, anche se ha trascorso un momento alla ricerca di un pulsante.

2
Rodger

Ho visto un tipo simile di approccio nel software in cui non richiedono un invio per verificare le credenziali. Dopo aver inserito le credenziali e aver smesso di digitare, controllano immediatamente la validità di tali credenziali.

Se le tue credenziali sono sbagliate, si genera automaticamente un messaggio di errore molto visibile che ti informa che cosa è andato storto e semplicemente inserisci nuovamente o prova nuove credenziali e il processo si ripete fino a quando non hai effettuato l'accesso.

2
Matt Warner

Direi che hai bisogno di un pulsante di accesso, per una serie di motivi:

  1. La maggior parte delle app che ho usato riporta il focus sul primo campo quando hai finito di inserire i dati nell'ultimo campo. Ora, questa potrebbe essere una vecchia pratica superata da nuove preferenze, ma è certamente come mi aspetto che si comporti una forma.

  2. Supponendo che la tua app abbia altri moduli, è probabile che siano più complicati del modulo di accesso e richiedono la presenza di un pulsante INVIA, che in realtà è tutto il tuo pulsante di accesso. Dato che queste forme avranno bisogno del pulsante, ha senso avere il pulsante su tutte le forme, per evitare confusione.

  3. Non tutti i browser trattano il tasto INVIO allo stesso modo. Ancora una volta, questo potrebbe essere un problema di vecchia scuola, ma ricordo di aver avuto problemi con il comportamento del tasto INVIO quando c'era un solo campo. Su alcuni browser era uguale a INVIA, su altri browser era ancora necessario fare clic sul pulsante INVIA. Il loro punto chiave era, non era controllato dalla tua app, era controllato dal browser. Così ho imparato molto tempo fa a non assumere mai nulla riguardo al tasto INVIO e a fare sempre affidamento su INVIA. Ancora una volta, questo potrebbe non essere più un problema, ma non ho mai avuto problemi aderendo a questo principio, quindi non vedo alcun motivo per cambiare.

1

Per le nostre app Web utilizzate internamente, abbiamo utilizzato una funzione di accesso automatico.

L'utente digita semplicemente l'indirizzo o fa clic sul preferito/preferito di Brwoser e vengono automaticamente riconosciuti e ammessi. Come abbiamo fatto, non sono sicuro perché sono il graphic designer residente.

Potrebbe essere stato fatto come parte dell'amministratore creando profili, sicurezza e autorizzazioni per i dipendenti noti? Forse dal loro IP?

Come qualcuno che accedeva regolarmente all'app per verificare il design, è stato bello non dover accedere ogni volta.

Ancora una volta, sono un designer, quindi potrei non prendere in considerazione alcune cose, ma per i dipendenti noti che lavorano nelle app interne, è stato piuttosto bello.

1
Tomas

Penso che la risposta qui sia gli script. Se un utente non preme invio entro un periodo di tempo prestabilito, avvisa che deve premere invio per accedere, perché è probabile che non l'abbia capito. Per le poche persone che hanno gli script disabilitati, potresti rilevarlo in vari modi e dare loro un pulsante.

0
Ponkadoodle