punti esclamativi nei messaggi di errore [chiuso]

13

Cosa ne pensi dell'utilizzo dei punti esclamativi nei messaggi di errore? cioè "L'indirizzo non è valido!".

Personalmente, penso che non aggiunga nulla, insulti l'utente e faccia sembrare il prodotto come se fosse stato scritto in TRS-80 BASIC da un dodicenne.

error-messages

— JoelFan
fonte

2

O ancora meglio ... che dire quando vengono utilizzati non per errori, ma per operazioni riuscite (nel qual caso probabilmente l'intera finestra di dialogo dovrebbe essere eliminata), come "File salvato con successo!" ... niente come realizzare il tuo software sembra scioccato che sia effettivamente riuscito a fare qualcosa

— JoelFan,

16

Sui messaggi di errore destinati ad essere visualizzati per l'utente? Sì, sono con te. Tutto ciò che fa sentire l'utente come se la sua macchina stesse urlando contro di loro per essere un idiota dovrebbe essere archiviato sotto "Bad Idea".

Ma i messaggi di errore da inviare al file di registro, in particolare sul server? So che dovresti mantenere ancora un senso di professionalità, perché quelli possono ancora finire sullo schermo dell'utente. Ma devo ammettere che snarking è terribilmente allettante ...

— BlairHippo
fonte

2

Esattamente. I messaggi di errore visibili all'utente non dovrebbero mai essere allarmanti. Tuttavia, supporto pienamente i messaggi di debug snarky. "Nessuna riga dell'oggetto o corpo del messaggio, spero che vada bene ..."

— TMN,

In un file di registro potrebbe essere utile se stai cercando di attirare l'attenzione della gente su di loro, ma le probabilità sono se l'errore è abbastanza grave da giustificare un punto esclamativo (ad es. Errore fatale!) Ma stai comunque cercando di ottenere la stringa.

— rjzii,

Ho visto casi in cui messaggi di errore sciocchi hanno causato problemi legali e certamente perso affari. Qui era dove il cliente / altra società non avrebbero mai dovuto vedere l'applicazione che generava i messaggi. Alcuni esperti di marketing hanno pensato che sarebbe stata una buona idea lasciare che il cliente avesse qualche utilità in casa e WOW, ne è seguita la terza guerra mondiale.

— uɐɪ

13

Il guru dell'usabilità Jakob Nielsen scoraggia il loro uso. La maggior parte dei consigli sull'usabilità si basa sulla ricerca. Ecco perché tendo a preferire questi consigli rispetto alle opinioni personali.

— LennyProgrammers
fonte

4

Sono quasi cattivi quanto la parola "per favore" nei dialoghi. Dump em!

— JohnFx
fonte

1

Perché "per favore" è una cosa negativa? Per me "inserisci il tuo nome" suona burbero rispetto a "inserisci il tuo nome".

— foraidt,

1

Un'interfaccia utente deve essere concisa, soprattutto quando si prevede che gli utenti leggano qualcosa. È abbastanza difficile convincerli a leggere le finestre di dialogo quando ne hai davvero bisogno, ma un modo per esacerbare il problema è addestrarli affinché l'interfaccia utente sia piena di testo estraneo. Nell'esempio che hai specificato direi che anche "inserisci il tuo nome" è troppo. Vai con un campo di testo e un'etichetta "Nome:" L'utente sa cosa fare in quella situazione.

— JohnFx,

3

Mi piace audace, TUTTE LE MAIUSCOLE ED ESCLUSIONI!

— Gratzy
fonte

5

... perché nulla dice "Good User Experience" come la sensazione che il tuo programma sia in realtà un bambino di sette anni dopo quattro colpi di espresso Pixie Stix. ;-)

— BlairHippo il

@BlairHippo Adoro l'analogia che era perfetta.

— Gratzy,

Perfetto, tranne per il fatto che hai incluso solo un'esclamazione

— JoelFan,

0

Bene, se è una finestra di dialogo standard di Windows, potrebbe già avere un punto esclamativo in un triangolo rosso o in un cerchio blu, a seconda dei parametri passati al metodo API Win32 che lo visualizza. Quindi perché duplicare l'urgenza?

— Jesse C. Slicer
fonte

Perché la tua ragazza potrebbe scaricarti se non lo fai. ( youtube.com/watch?v=3rd7j-aSqFU )

— JohnFx

Non ho mai conosciuto i pericoli. Ma ancora una volta, stai prendendo in considerazione l'idea che i programmatori abbiano delle ragazze come regola generale (sto scherzando!)

— Jesse C. Slicer,