Perché è necessario il pulsante Salva?

Question

Un software come OneNote ha dimostrato che il salvataggio automatico può essere implementato e funziona altrettanto bene (o meglio) come il pulsante di salvataggio manuale/CTRL + S.

In ogni caso, tutto ciò su cui si lavora si desidera salvare. È solo se stai provando qualcosa di distruttivo che potresti chiudere senza salvare.

Quindi, da un punto di vista di programmatori/usabilità, perché la funzionalità di "salvataggio" manuale è ancora presente in quasi tutti i software oggi? Perché tutti sono troppo pigri per implementare il "salvataggio automatico" ogni volta che i dati vengono modificati?

Ed è una buona idea implementare il salvataggio automatico, almeno per avviare una certa trazione nel nostro settore specifico e tra i nostri concorrenti?

Answer 1

Il pulsante di salvataggio è una funzionalità di interfaccia utente nota e confortevole che tutti, da Jon Skeet alla nonna, hanno familiarità con. Se te ne liberi, sarebbe come rimuovere il pulsante di chiusura su una finestra per alcune persone. Certo, alla fine ci si abituerebbero, ma alcune persone non capirebbero che i loro dati sono stati salvati automaticamente.

Inoltre, se si sta salvando automaticamente sul Web, non solo si sta occupando molto spazio sul server con tutte queste istanze, si sta anche utilizzando molta larghezza di banda con salvataggi periodici. Almeno con il salvataggio manuale, si sta usando lo spazio e la larghezza di banda solo quando l'utente intende, che può essere più raro, risparmiando così la larghezza di banda. Il vantaggio, ovviamente, per l'autoscatto è la conservazione del lavoro in caso qualcosa vada storto.

Verificare la definizione di "skeuomorph" :)

Answer 2

salva automaticamente in genere su un intervallo definito. Cosa succede se si desidera salvare tra una pausa e l'altra?

È necessario implementare un salvataggio manuale per rimanere consenzienti con altre applicazioni nell'ambiente.

Le persone si aspettano file -> salva, o CTRL + S per esistere.

Answer 3

Dovrebbe essere taggato soggettivo forse?

Come sviluppatore, sono sempre un po 'a disagio per le app in questo modo. I come avere il controllo su quando i miei dati vengono salvati, anche se forse questo è solo anni di condizionamento al lavoro. Prendo quel piccolo "uh oh" sensazione ogni volta che chiudo una finestra in cui ho inserito i dati senza premere esplicitamente un pulsante di chiusura (o una scorciatoia).

Detto questo, sono stato "addestrato" ad accettarlo in determinate situazioni. OneNote, ad esempio, o Tomboy. Un gran numero di app per OS X seguono questo schema, in particolare le app di utilità come gli strumenti della GUI del server DB.

Quindi, in breve, diversi strumenti per situazioni diverse. IMO, la maggior parte dei software in questi giorni non trarrebbe beneficio da un passaggio da un salvataggio manuale a un salvataggio automatico.

Answer 4

Inoltre con un "salvataggio" esiste comunemente "salva come ...". Entrambi danno all'utente la sensazione di controllo e sicurezza. Sapendo di aver fatto clic su Save, gli consente di sapere a quale stato possono aspettarsi i propri dati quando lo ricaricano.

Answer 5

Penso che la risposta a questo è che 'dipende'!

È necessario considerare non solo le aspettative dell'utente in termini di coerenza con altre applicazioni, ma anche il modo in cui l'utente utilizzerà la propria applicazione.

Un caso di utilizzo molto comune per OneNote è che qualcuno lo apre per scaricare alcune informazioni quasi a parte per quello su cui stanno lavorando. Hanno bisogno di entrare e uscire rapidamente. Qualsiasi suggerimento sul salvataggio sarebbe una seccatura.

Applicazioni come Word, d'altra parte, si aspettano che gli utenti trascorrano una quantità di tempo concordata lavorando su un documento. In questo caso, il compito di salvare e rispondere manualmente alle caselle di conferma ecc sarà considerato un compito relativamente piccolo.

Answer 6

Non è difficile implementare il salvataggio automatico: basta implementare un normale salvataggio e chiamarlo quando è necessario o solo in un timer (se si è pigri).

I pulsanti di salvataggio sono comuni a causa del modello comune appreso dagli utenti per decenni.

1. Carica dati o file da una memoria persistente nella memoria principale.
2. Modificare i dati nella memoria principale.
3. Salvare i dati modificati in una memoria permanente.

Questo schema deriva dalla vecchia distinzione tra unità harde e memoria principale. Se ci pensate in un altro modo (come fanno alcuni sistemi operativi sperimentali), non c'è bisogno di caricare e salvare i file - basti pensare a un disco fisso come memoria principale e alla memoria principale come un altro livello di cache per il disco rigido . Di conseguenza, tutti i file (non sui supporti rimovibili) sono sempre in memoria e non sarà più necessario caricare o salvare i file.

Ma fare questo cambiamento non è facile perché gli utenti sono abituati al vecchio modello da anni. Inoltre il vecchio schema di caricamento e salvataggio è un modo molto semplice per ottenere una sorta di sistema di annullamento delle primitive.

Il salvataggio automatico richiede anche un sistema di annullamento e non è così semplice crearne uno. Essenzialmente se si esegue l'editing di immagini, audio o video e si stanno producendo molti dati è difficile trovare un buon compromesso tra memoria e tempo. E c'è il rischio che l'utente proverà a annullare le cose chiudendo l'applicazione e quindi riconoscerà che ciò non ha funzionato. Quindi potrebbe anche essere una buona idea perseguire l'annullamento delle informazioni per proteggere gli utenti da questo errore o salvare modifiche indesiderate in caso di arresto anomalo.

Quindi, sì, mi piacerebbe davvero vedere i pulsanti di salvataggio (e caricamento) per scomparire. Mi piacerebbe avere informazioni di annullamento persistenti o addirittura completare le storie di modifica. Ma non penso che questo cambiamento possa accadere tra qualche anno, se mai.

Answer 7

Si tratta davvero di questo: un pulsante Salva è meno costoso da implementare e gestire rispetto Annulla.

Answer 8

Dal punto di vista dei programmatori l'implementazione del salvataggio automatico non sarebbe un grosso problema. Hai appena impostato un timer e la richiamata farebbe il salvataggio.

Tuttavia, dal punto di vista dell'usabilità il salvataggio automatico è molto problematico. Prima di tutto gli utenti sono abituati ad avere un salvataggio manuale e non offrirlo a loro confonderebbero la maggior parte degli utenti e prenderebbero il controllo.

Un problema ancora più grande sarebbe che il salvataggio automatico sovrascrive il contenuto del file di sottostrato indipendentemente dal fatto che lo si volesse o meno. Naturalmente è possibile salvare la funzione di salvataggio automatico su file temporaneo, ma la decisione di sovrascrivere il documento originale deve sempre provenire dall'utente, non dal software. E perché comunque avresti bisogno che l'utente avvii almeno un salvataggio manuale, perché non abilitare il salvataggio manuale sempre disponibile?

Answer 9

Risposta breve: "auto save" = "auto destroy"/"auto <expletive>".

Answer 10

Io lavoro nel campo medico e ci sono situazioni in cui si desidera l'utente ad assumersi la responsabilità per il salvataggio qualcosa. Se si dispone di una CCE e si sta inserendo una prescrizione per un paziente, non necessariamente lo si vuole salvare automaticamente: si desidera che l'utente sia consapevole e si assuma la responsabilità delle proprie azioni. Inoltre, salvataggio automatico un valore in un sistema critico come questo potrebbe essere disastroso per ovvi motivi ...

Answer 11

Una funzione di salvataggio automatico è grande quando si tratta di un documento. Che dire di un'applicazione aziendale? Se modifico l'account di un cliente, dovrebbe aggiornare l'account mentre registro i campi modificati? In tal caso, cosa dovrebbe fare quando l'account è in uno stato non valido? Quando imponi le regole aziendali e come le imponi? Come si comporterà quando è necessario tenere conto delle regole aziendali su ogni modifica?

Si può certamente costruire un applicazione che vi porterà una qualsiasi di queste considerazioni, ma si è stati vale la pena extra?

Quindi dovremmo sbarazzarci del pulsante Salva? Dipende.

Answer 12

Per un progetto in università, il mio gruppo e io abbiamo creato un'applicazione senza salvataggio esplicito come esperimento.

Abbiamo implementato uno stack di annullamento infinito e serializzato lo stack di annullamento con i dati effettivi in ​​modo che, anche se si chiudesse l'app e la si riaprisse, è sempre possibile annullare l'ultima operazione. Ogni operazione ha scritto una nuova voce nella lista delle azioni su disco in modo che il file fosse sempre coerente (beh, soprattutto ...), anche se la potenza non andava a buon fine. Era un po 'un incrocio tra un sistema di controllo delle versioni e un file system di journaling.

Ci

sono due problemi: uno, non abbiamo avuto il tempo di farlo completamente a destra (ah, arroganza giovanile); due, tutti (compagni di studio e, soprattutto, gli AT) lo detestavano, a causa di tutti i motivi già menzionati.

A volte, per tutte le vostre migliori intenzioni, basta non può ignorare i comportamenti radicati.