Fornire agli utenti informazioni sulla cronologia delle revisioni del programma?

8

Una limitazione di un programma che sostengo è che gli utenti finali spesso non sanno quali modifiche sono state apportate. Per rimediare a questo vorrei mostrare ai miei utenti un elenco semplificato delle modifiche apportate al loro programma. C'è una buona metodologia / approccio da seguire che creerebbe un elenco facile da aggiornare che potrebbe essere inserito nell'interfaccia utente?

Ad esempio: dovrei memorizzare tutto in un file XML che viene letto in un modulo? La cronologia delle modifiche dovrebbe essere inserita in un database?

Nota: il programma è Winforms (C # 4.0).

Aggiorna

Sulla base dell'ottimo feedback, ho deciso di utilizzare SQLite come archiviazione delle informazioni e fornirò agli utenti un elenco cronologico delle modifiche in un controllo TreeView.

    
posta John M 12.10.2011 - 15:50
fonte

3 risposte

13

Gli utenti generalmente non si preoccupano delle cose nello stesso modo in cui lo fai tu. Mentre puoi essere pigro e pubblicare semplicemente la tua lista di bug, è molto meglio se ti concedi un po 'di tempo ed evidenzia le modifiche nella lingua dell'utente.

Ciò significa perdere i dettagli. Per quelli che desiderano tutti i dettagli, potresti includere un elenco completo dei problemi affrontati, ma in generale le tue note di rilascio dovrebbero solo mostrare, in questo ordine:

  1. Maggiore nuova funzionalità, nella lingua dell'utente .
  2. Cambiamenti nel flusso di lavoro, possibilmente con una giustificazione. Es .: "La finestra di dialogo di stampa è stata semplificata, ora è possibile trovare le opzioni di layout di pagina nella pagina di stampa anziché la loro posizione precedente in Opzioni documento."
  3. Correzioni di bug importanti, nella lingua dell'utente . Ad es .: "Arresti anomali sono meno frequenti quando si aprono file oltre 2 GB" anziché "Risolto buffer overflow in mt_file_read per gli input > 2 GB"
  4. Un riassunto di eventuali modifiche minori al flusso di lavoro e nuove funzionalità minime
  5. In generale, gli utenti non si preoccupano di correzioni di bug minori, quindi basta dire "e correzioni di bug" o simili. Di nuovo, puoi fornire un link ai dettagli completi per i programmatori nel pubblico. ;)

Questo è più lavoro, e i tuoi utenti apprezzeranno davvero l'attenzione ai dettagli.

    
risposta data 12.10.2011 - 16:10
fonte
5

Qualsiasi tracker di problemi decente genera note di rilascio (basate sulle storie chiuse in una versione). Incorporalo come file di testo e mostralo ovunque nella tua app.

    
risposta data 12.10.2011 - 16:02
fonte
2

La prima domanda a cui devi rispondere è se i tuoi utenti si preoccupano. Non è necessario implementare alcuna funzionalità o componenti dell'interfaccia utente per aggiungere qualcosa che gli utenti non desiderano o non hanno bisogno. Questo è solo più codice che deve essere testato e convalidato. Se non è necessario che queste informazioni vengano visualizzate nell'applicazione, sei solo doratura dei requisiti - un antipattern noto.

Se i tuoi utenti desiderano queste informazioni, devi determinare come renderle disponibili. Questo dovrebbe essere guidato dagli utenti, attraverso i requisiti che forniscono. Sembra che tu voglia presentarlo come uno strumento accessibile attraverso l'interfaccia utente. Tuttavia, ci sono molte altre opzioni che dovrebbero essere considerate e discusse con i tuoi utenti (o sottoinsieme di utenti che potrebbero volere queste informazioni). Le opzioni possibili includono "modifiche dall'ultima release" nel README o nel manuale dell'utente, un file di modifiche logiche accanto al README o nel manuale dell'utente o una pagina Web sul sito Web del prodotto che descrive le modifiche nell'ultima versione con la possibilità di visualizzare le modifiche tra ultime versioni. A seconda del formato di file che si utilizza per le modifiche, è possibile aprire tale file utilizzando l'applicazione specificata dal sistema operativo o analizzare il file e visualizzarlo in un'interfaccia utente.

Indipendentemente da come lo si consegna, non farlo perché lo si desidera, ma perché lo vogliono gli utenti. Altrimenti, stai solo creando lavoro per te che non aggiunge valore al tuo prodotto.

    
risposta data 12.10.2011 - 16:12
fonte

Leggi altre domande sui tag